idnits 2.17.1 draft-bradford-ccamp-path-key-ero-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 320. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 331. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 338. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 344. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Feb 23, 2008) is 5878 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group Rich Bradford (Ed) 3 Internet-Draft JP Vasseur 4 Cisco Systems, Inc. 5 Adrian Farrel 6 Old Dog Consulting 8 Intended Status: Standards Track 9 Expires: Aug 23, 2008 10 Feb 23, 2008 12 draft-bradford-ccamp-path-key-ero-01.txt 14 RSVP Extensions for Path Key Support 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that 19 any applicable patent or other IPR claims of which he or she is 20 aware have been or will be disclosed, and any of which he or she 21 becomes aware will be disclosed, in accordance with Section 6 of 22 BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other 31 documents at any time. It is inappropriate to use Internet-Drafts 32 as reference material or to cite them other than as "work in 33 progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 Abstract 43 Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) 44 Traffic Engineering (TE) Label Switched Paths (LSPs) may be 45 computed by Path Computation Elements (PCEs). Where the TE LSP 46 crosses multiple domains, such as Autonomous Systems (ASes), the 47 path may be computed by multiple PCEs that cooperate, with each 48 responsible for computing a segment of the path. To preserve 49 confidentiality of topology with each AS, the PCE supports a 50 mechanism to hide the contents of a segment of a path, called the 51 Confidential Path Segment (CPS), by encoding the contents as a 52 Path Key Subobject (PKS). This document describes the addition of 53 this information to Resource Reservation Protocol (RSVP) signaling 54 by inclusion in the Explicit Route Object (ERO) and Record Route 55 Object (RRO). 57 Table of contents 58 To be Added 60 Conventions used in this document 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 63 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 64 "OPTIONAL" in this document are to be interpreted as described in 65 RFC-2119 [RFC2119]. 67 1. Introduction 69 Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) 70 Traffic Engineering (TE) Label Switched Paths (LSPs) are signaled 71 using the TE extensions to the Resource Reservation Protocol 72 (RSVP-TE) [RFC3209], [RFC3473]. The routes followed by MPLS and 73 GMPLS TE LSPs may be computed by Path Computation Elements (PCEs) 74 [RFC4655]. 76 Where the TE LSP crosses multiple domains, such as Autonomous 77 Systems (ASes), the path may be computed by multiple PCEs that 78 cooperate, with each responsible for computing a segment of the 79 path. To preserve confidentiality of topology with each AS, the 80 PCE Communications Protocol (PCEP) [PCEP] supports a mechanism to 81 hide the contents of a segment of a path, called the Confidential 82 Path Segment (CPS), by encoding the contents as a Path Key 83 Subobject (PKS) [PCE-PKS]. 85 This document defines RSVP-TE protocol extensions necessary to 86 support the use of Path Key Segments in MPLS and GMPLS signaling. 88 2. Terminology 90 CPS: Confidential Path Segment. A segment of a path that contains 91 nodes and links that the AS policy requires to not be disclosed 92 outside the AS. 94 PCE: Path Computation Element: an entity (component, application 95 or network node) that is capable of computing a network path or 96 route based on a network graph and applying computational 97 constraints. 99 PKS: Path Key Subobject. A subobject of an Explicit Route Object 100 which encodes a CPS, so as to preserve confidentiality. 102 3. RSVP-TE Path Key Subobject 104 The Path Key Subobject (PKS) may be carried in the Explicit Route 105 Object (ERO) of a RSVP-TE Path message [RFC3209]. The PKS is a 106 fixed-length subobject containing a Path-Key and a PCE-ID. The 107 Path Key is an identifier, or token used to represent the CPS 108 within the context of the PCE identified by the PCE-ID. The PCE-ID 109 identifies the PCE that can decode the Path Key using a reachable 110 IPv4 or IPv6 address of the PCE. In most cases, the decoding PCE 111 is also the PCE that computed the Path Key and the associated 112 path. Because of the IPv4 and IPv6 variants, two subobjects are 113 defined as follows. 115 0 1 2 3 116 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 |L| Type | Length | Path Key | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | PCE ID (4 bytes) | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 L 125 The L bit SHOULD NOT be set, so that the subobject 126 represents a strict hop in the explicit route. 128 Type 130 Subobject Type for a Path Key with 32-bit PCE ID as 131 assigned by IANA. 133 Length 134 The Length contains the total length of the subobject in 135 bytes, including the Type and Length fields. The Length 136 is always 8. 138 PCE ID 140 A 32-bit identifier of the PCE that can decode this key. 141 The identifier MUST be unique within the scope of the 142 domain that the CPS crosses, and MUST be understood by 143 the LSR that will act as PCC for the expansion of the 144 PKS. The interpretation of the PCE-ID is subject to 145 domain-local policy. It MAY be an IPv4 address of the PCE 146 that is always reachable, and MAY be an address that is 147 restricted to the domain in which the LSR that is called 148 upon to expand the CPS lies. Other values that have no 149 meaning outside the domain (for example, the Router ID of 150 the PCE) MAY be used to increase security or 151 confidentiality. 153 0 1 2 3 154 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 |L| Type | Length | Path Key | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | PCE ID (16 bytes) | 159 | | 160 | | 161 | | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 L 166 As above. 168 Type 170 Subobject Type for a Path Key with 128-bit PCE ID as 171 assigned by IANA. 173 Length 175 The Length contains the total length of the subobject in 176 bytes, including the Type and Length fields. The Length 177 is always 20. 179 PCE ID 181 A 128-bit identifier of the PCE that can decode this key. 182 The identifier MUST be unique within the scope of the 183 domain that the CPS crosses, and MUST be understood by the 184 LSR that will act as PCC for the expansion of the PKS. The 185 interpretation of the PCE-ID is subject to domain-local 186 policy. It MAY be an IPv6 address of the PCE that is 187 always reachable, but MAY be an address that is restricted 188 to the domain in which the LSR that is called upon to 189 expand the CPS lies. Other values that have no meaning 190 outside the domain (for example, the IPv6 TE Router ID) 191 MAY be used to increase security (see Section 5). 193 Note: The twins of these sub-objects are carried in PCEP messages 194 as defined in [PCE-PKS]. Ideally, IANA assignment of the subobject 195 types will be identical. 197 3.1. Explicit Route Object Processing Rules 199 This section to be completed in a future release. 201 3.2. Reporting Path Key Segments in Record Route Objects 203 This section to be completed in a future release. 205 4. Security Considerations 207 - Confidentiality of the CPS (can other network elements probe for 208 expansion of path-keys, possibly at random?). 210 - Authenticity of the path-key (resilience to alteration by 211 intermediaries, resilience to fake expansion of path-keys). 213 - Resilience from DNS attacks (insertion of spurious path-keys; 214 flooding of bogus path-key expansion requests). 216 Most of the interactions required by this extension are point to 217 point, can be authenticated and made secure as described in [PCEP] 218 and [RFC3209]. These interactions are listed in [PCE-PKS] 220 Thus, the major security issues can be dealt with using standard 221 techniques for securing and authenticating point-to-point 222 communications. In addition, it is recommended that the PCE 223 providing a decode response should check that the LSR that issued 224 the decode request is the head end of the decoded ERO segment. 226 Further protection can be provided by using a PCE ID to identify 227 the decoding PCE that is only meaningful within the domain that 228 contains the LSR at the head of the CPS. This may be an IP address 229 that is only reachable from within the domain, or some not-address 230 value. The former requires configuration of policy on the PCEs, 231 the latter requires domain-wide policy. 233 5. Manageability Considerations 235 5.1. Control of Function Through Configuration and Policy 237 The treatment of a path segment as a CPS, and its substitution in 238 a PCReq ERO with a PKS, is a function that SHOULD be under 239 operator and policy control where a PCE supports the function. The 240 operator SHOULD be given the ability to specify which path 241 segments are to be replaced and under what circumstances. For 242 example, an operator might set a policy that states that every 243 path segment for the operator's domain will be replaced by a PKS 244 when the PCReq has been issued from outside the domain. 246 6. IANA considerations 248 The IANA section will be detailed in further revision of this 249 document. 251 It will include code point requests for the three new ERO sub- 252 objects, and a new ErrorSpec Error Code. 254 Note: The twins of these sub-objects are be carried in PCEP 255 messages as defined in [PCE-PKS]. Ideally, IANA assignment of the 256 subobject types will be identical. 258 7. References 260 7.1. Normative References 262 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 263 Requirement Levels", BCP 14, RFC 2119, March 1997. 265 [PCEP] Vasseur, J.P., Le Roux, J.L., Ayyangar, A., Oki, E., 266 Ikejiri, A., Atlas, A., Dolganow, A., "Path Computation Element 267 (PCE) communication Protocol (PCEP)", draft-ietf-pce-pcep, 268 work in progress. 270 7.2. Informational References 272 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. 273 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 274 3209, December 2001. 276 [RFC3473] Berger, L., et al. "GMPLS Singlaling RSVP-TE 277 extensions", RFC3473, January 2003. 279 [PCE-PKS] Bradford, R., Vasseur, J.P., Farrel, A., "Preserving 280 Topology Confidentiality in Inter-Domain Path Computation Using a 281 Key-Based Mechanism", draft-ietf-pce-path-key, 282 work in progress. 284 [RFC4655] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation 285 Element (PCE) Architecture", RFC 4655, August 2006. 287 8. Authors' Addresses: 289 Rich Bradford (Editor) 290 Cisco Systems, Inc. 291 1414 Massachusetts Avenue 292 Boxborough, MA - 01719 293 USA 294 Email: rbradfor@cisco.com 296 J.-P Vasseur 297 Cisco Systems, Inc. 298 1414 Massachusetts Avenue 299 Boxborough, MA - 01719 300 USA 301 Email: jpv@cisco.com 302 Adrian Farrel 303 Old Dog Consulting 304 EMail: adrian@olddog.co.uk 306 Full Copyright Statement 308 Copyright (C) The IETF Trust (2008). 310 This document is subject to the rights, licenses and restrictions 311 contained in BCP 78, and except as set forth therein, the authors 312 retain all their rights. 314 This document and the information contained herein are provided on an 315 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 316 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 317 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 318 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 319 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 320 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 322 Intellectual Property 324 The IETF takes no position regarding the validity or scope of any 325 Intellectual Property Rights or other rights that might be claimed to 326 pertain to the implementation or use of the technology described in 327 this document or the extent to which any license under such rights 328 might or might not be available; nor does it represent that it has 329 made any independent effort to identify any such rights. Information 330 on the procedures with respect to rights in RFC documents can be 331 found in BCP 78 and BCP 79. 333 Copies of IPR disclosures made to the IETF Secretariat and any 334 assurances of licenses to be made available, or the result of an 335 attempt made to obtain a general license or permission for the use of 336 such proprietary rights by implementers or users of this 337 specification can be obtained from the IETF on-line IPR repository at 338 http://www.ietf.org/ipr. 340 The IETF invites any interested party to bring to its attention any 341 copyrights, patents or patent applications, or other proprietary 342 rights that may cover technology that may be required to implement 343 this standard. Please address the information to the IETF at 344 ietf-ipr@ietf.org.