idnits 2.17.1 draft-ietf-pce-path-key-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 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 835. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 846. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 853. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 859. 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Once a path-key has been discarded, the path-key value SHOULD not be immediately available for re-use for a new CPS since this might -- 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 (September 12, 2007) is 6064 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 (~~), 2 warnings (==), 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: March 12, 2008 10 September 12, 2007 12 draft-ietf-pce-path-key-01.txt 14 Preserving Topology Confidentiality in Inter-Domain Path 15 Computation Using a Key-Based Mechanism 17 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on March 12, 2008. 41 Bradford, Vasseur and Farrel 1 42 Draft-ietf-pce-path-key-01.txt September 2007 44 Copyright Notice 46 Copyright (C) The IETF Trust (2007). All rights reserved. 48 Abstract 50 Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) 51 Traffic Engineering (TE) Label Switched Paths (LSPs) may be 52 computed by Path Computation Elements (PCEs). Where the TE LSP 53 crosses multiple domains, such as Autonomous Systems (ASes), the 54 path may be computed by multiple PCEs that cooperate, with each 55 responsible for computing a segment of the path. However, in some 56 cases (e.g. when ASes are administered by separate Service 57 Providers), it would break confidentiality rules for a PCE to 58 supply a path segment to a PCE in another domain, thus disclosing 59 internal topology information. This issue may be circumvented by 60 returning a loose hop and by invoking a new path computation from 61 the domain boundary LSR during TE LSP setup as the signaling 62 message enters the second domain, but this technique has several 63 issues including the problem of maintaining path diversity. 65 This document defines a mechanism to hide the contents of a 66 segment of a path, called the Confidential Path Segment (CPS). The 67 CPS may be replaced by a path-key that can be conveyed in the PCE 68 Communication Protocol (PCEP) and signaled within in a Resource 69 Reservation Protocol TE (RSVP-TE) explicit route object. 71 Table of contents 72 1. Terminology..................................................3 73 2. Introduction.................................................4 74 3. Path-Key Solution............................................5 75 3.1. Mode of Operation...........................................6 76 4. PCEP Protocol Extensions.....................................7 77 4.1. PATH-KEY Object.............................................7 78 4.2. PKS subobject...............................................7 79 4.3. Path Key Bit...............................................10 80 5. PCEP Mode of Operation......................................10 81 6. Security Considerations.....................................11 82 7. Manageability Considerations................................12 83 7.1. Control of Function Through Configuration and Policy.......12 84 7.2. Information and Data Models................................13 85 7.3. Liveness Detection and Monitoring..........................13 86 7.4. Verifying Correct Operation................................14 87 7.5. Requirements on Other Protocols and Functional Components..14 88 7.6. Impact on Network Operation................................14 90 Bradford, Vasseur, and Farrel 2 91 Draft-ietf-pce-path-key-01.txt September 2007 93 8. IANA Considerations.........................................15 94 8.1. New Subobjects for the ERO Object..........................15 95 8.2. New PCEP Object............................................15 96 8.3. New RP Object Bit Flag.....................................16 97 9. Intellectual Property Considerations........................16 98 10. References.................................................17 99 10.1. Normative References.....................................17 100 10.2. Informational References.................................17 101 11. Authors' Addresses:........................................18 103 Conventions used in this document 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 106 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 107 "OPTIONAL" in this document are to be interpreted as described in 108 RFC-2119 [RFC2119]. 110 1. Terminology 112 AS: Autonomous System. 114 ASBR: Autonomous System Border Routers used to connect to another 115 AS of a different or the same Service Provider via one or more 116 links inter-connecting between ASes. 118 CPS: Confidential Path Segment. A segment of a path that contains 119 nodes and links that the AS policy requires to not be disclosed 120 outside the AS. 122 Inter-AS TE LSP: A TE LSP that crosses an AS boundary. 124 LSR: Label Switching Router. 126 LSP: Label Switched Path. 128 PCC: Path Computation Client: Any client application requesting a 129 path computation to be performed by a Path Computation Element. 131 PCE: Path Computation Element: An entity (component, application 132 or network node) that is capable of computing a network path or 134 Bradford, Vasseur, and Farrel 3 135 Draft-ietf-pce-path-key-01.txt September 2007 137 route based on a network graph and applying computational 138 constraints. 140 TE LSP: Traffic Engineering Label Switched Path 142 2. Introduction 144 Path computation techniques using the Path Computation Element 145 (PCE) are described in [RFC4655] and allow for path computation of 146 inter-domain Multiprotocol Label Switching (MPLS) Traffic 147 Engineering (TE) and Generalized MPLS (GMPLS) Label Switched Paths 148 (LSPs). 150 An important element of inter-domain TE is that TE information is 151 not shared between domains for scalability and confidentiality 152 reasons ([RFC4105] and [RFC4216]). Therefore, a single PCE is 153 unlikely to be able to compute a full inter-domain path. 155 Two path computation scenarios can be used for inter-domain TE 156 LSPs: one using per-domain path computation (defined in [PD-PATH- 157 COMP]), and the other using a PCE-based path computation technique 158 with cooperation between PCEs (as described in [RFC4655]). In this 159 second case, paths for inter-domain LSPs can be computed by 160 cooperation between PCEs each of which computes a segment of the 161 path across one domain. Such a path computation procedure is 162 described in [BRPC]. 164 If confidentiality is required between domains (such as would very 165 likely be the case between ASes belonging to different Service 166 Providers) then cooperating PCEs cannot exchange path segments or 167 else the receiving PCE and the Path Computation Client (PCC) will 168 be able to see the individual hops through another domain thus 169 breaking the confidentiality requirement stated in [RFC4105] and 170 [RFC4216]. We define the part of the path which we wish to keep 171 confidential as the Confidential Path Segment (CPS). 173 One mechanism for preserving the confidentiality of the CPS is for 174 the PCE to return a path containing a loose hop in place of the 175 segment that must be kept confidential. The concept of loose and 176 strict hops for the route of a TE LSP is described in [RFC3209]. 177 The Path Computation Element Communication Protocol (PCEP) defined 178 in [PCEP] supports the use of paths with loose hops, and it is a 179 local policy decision at a PCE whether it returns a full explicit 180 path with strict hops or uses loose hops. Note that a Path 181 computation Request may request an explicit path with strict hops 182 or may allow loose hops as detailed in [PCEP]. 184 Bradford, Vasseur, and Farrel 4 185 Draft-ietf-pce-path-key-01.txt September 2007 187 The option of returning a loose hop in place of the CPS can be 188 achieved without further extensions to PCEP or the signaling 189 protocol. If loose hops are used, the TE LSPs are signaled as 190 normal ([RFC3209]), and when a loose hop is encountered in the 191 explicit route it is resolved by performing a secondary path 192 computation to reach the resource or set of resources identified 193 by the loose hop. Given the nature of the cooperation between PCEs 194 in computing the original path, this secondary computation occurs 195 at or on behalf of a Label Switching Router (LSR) at a domain 196 boundary (i.e., an ABR or ASBR) and the path is expanded as 197 described in [PD-PATH-COMP]. 199 The PCE-based computation model is particularly useful for 200 determining mutually disjoint inter-domain paths such as might be 201 required for service protection [INTER-DOM-REC]. A single path 202 computation request is used. However, if loose hops are returned, 203 the path of each TE LSP must be recomputed at the domain 204 boundaries as the TE LSPs are signaled, and since the TE LSP 205 signaling proceeds independently for each TE LSP, disjoint paths 206 cannot be guaranteed since the LSRs in charge of expanding the 207 EROs are not synchronized. Therefore, if the loose hop technique 208 is used without further extensions, path segment confidentiality 209 and path diversity are mutually incompatible requirements. 211 This document defines the notion of a Path Key that is a token 212 that replaces a path segment in an explicit route. The Path Key is 213 encoded as a Path Key Subobject (PKS) returned in the PCEP Path 214 Computation Reply message (PCRep) ([PCEP]). Upon receiving the 215 computed path, the PKS will be carried in an RSVP-TE Path message 216 (RSVP-TE [RFC3209] and [RSVP-PKS]) during signaling. 218 3. Path-Key Solution 220 The Path-Key solution may be applied in the PCE-based path 221 computation context as follows. A PCE computes a path segment 222 related to a particular domain and replaces any CPS in the path 223 reported to the requesting PCC (or another PCE) by one or more 224 subobjects referred to as PKSes. The entry boundary LSR of each 225 CPS SHOULD be specified as a hop in the returned path immediately 226 preceding the CPS, but where two PKSes are supplied in sequence 227 with no intervening nodes, the entry node to the second CPS MAY be 228 part of the first CPS and does not need to be explicitly present 229 in the returned path. The exit node of a CPS MAY be present as a 230 strict hop immediately following the PKS. 232 Bradford, Vasseur, and Farrel 5 233 Draft-ietf-pce-path-key-01.txt September 2007 235 3.1. Mode of Operation 237 During path computation, when local policy dictates that 238 confidentiality must be preserved for all or part of the path 239 segment being computed or if explicitly requested by the Path 240 Computation Request, the PCE associates a path-key with the 241 computed path for the CPS, places its own identifier (its PCE ID 242 as defined in section 4.2. ) along with the path-key in a PKS, and 243 inserts the PKS object in the path returned to the requesting PCC 244 or PCE immediately after the IPv4 subobject defined in [RFC3209] 245 subobject that identifies the LSR that will expand the PKS into a 246 explicit path hops. This will usually be the LSR that is the start 247 point of the CPS. The PCE that generates a PKS SHOULD store the 248 computed path segment and the path-key for later retrieval. A 249 local policy SHOULD be used to determine for how long to retain 250 such stored information, and whether to discard the information 251 after it has been queried using the procedures described below. It 252 is RECOMMENDED for a PCE to store the PKS for a period of 10 253 minutes. 255 A path-key value is scoped to the PCE that computed it as 256 identified by the PCE-ID carried in the PKS. A PCE MUST NOT re-use 257 a path-key value to represent a new CPS for at least 30 minutes 258 after discarding the previous use of the same path-key. A PCE that 259 is unable to retain information about previously used path-key 260 values over a restart SHOULD use some other mechanism to guarantee 261 uniqueness of path-key values such as embedding a timestamp or 262 version number in the path-key. 264 A head-end LSR that is a PCC converts the path returned by a PCE 265 into an explicit route object (ERO) that it includes in the 266 Resource Reservation Protocol (RSVP) Path message. If the path 267 returned by the PCE contains a PKS, this is included in the ERO. 268 Like any other subobjects, the PKS is passed transparently from 269 hop to hop, until it becomes the first subobject in the ERO. This 270 will occur at the start of the CPS which will usually be the 271 domain boundary. The PKS MUST be preceded by an ERO subobject that 272 identifies the LSR that must expand the PKS, so the PKS will not 273 be encountered in ERO processing until the LSR that can process 274 it. 276 An LSR that encounters a PKS when trying to identify the next-hop 277 retrieves the PCE-ID from the PKS and sends a Path Computation 278 Request (PCReq) message as defined in [PCEP] to the PCE identified 279 by the PCE-ID that contains the path-key object . 281 Bradford, Vasseur, and Farrel 6 282 Draft-ietf-pce-path-key-01.txt September 2007 284 Upon receiving the PCReq message, the PCE identifies the computed 285 path segment using the supplied path-key, and returns the 286 previously computed path segment in the form of explicit hops 287 using an ERO object contained in the Path Computation Reply 288 (PCReqp) to the requesting node as defined in [PCEP]. The 289 requesting node inserts the explicit hops into the ERO and 290 continues to process the TE LSP setup as per [RFC3209]. 292 4. PCEP Protocol Extensions 294 4.1. PATH-KEY Object 295 When a PCC needs to expand a path-key in order to expand a CPS it 296 issues a path computation request (PCReq) to the PCE identified in the 297 PKS in the RSVP-TE ERO that it is processing. The PCC supplies the PKS 298 to be expanded in a PATH-KEY Object in the PCReq message. 300 The PATH-KEY Object is defined as follows. 302 PATH-KEY Object-Class is to be assigned by IANA (recommended 303 value=16) 305 Path Key Object-Type is to be assigned by IANA (recommended value=1) 307 The PATH-KEY Object MUST contain at least one Path Key Subobject 308 (see Section 4.2). The first PKS MUST be processed by the PCE. 309 Subsequent subobjects SHOULD be ignored. 311 4.2. PKS subobject 313 The PKS is identical in format to that defined for RSVP-TE 314 signaling in [RSVP-PKS], but is redefined in the context of this 315 document since a PCEP codepoint is required. 317 The PKS is a fixed-length subobject containing a Path-Key and a 318 PCE-ID. The Path Key is an identifier, or token used to represent 319 the CPS within the context of the PCE identified by the PCE-ID. 320 The PCE-ID identifies the PCE that can decode the Path Key using 322 Bradford, Vasseur, and Farrel 7 323 Draft-ietf-pce-path-key-01.txt September 2007 325 an identifier that is unique within the domain that the PCE 326 serves. The PCE-ID has to be mapped to a reachable IPv4 or IPv6 327 address of the PCE by the first node of the CPS (usually a domain 328 border router) and a PCE MAY use one of its reachable IP addresses 329 as its PCE-ID. Alternatively and to provide greater security (see 330 Section 6), according to domain-local policy, the PCE MAY use some 331 other identifier that is scoped only within the domain. 333 To allow IPv4 and IPv6 addresses to be carried, two subobjects are 334 defined as follows. 336 The Path Key Subobject may be present in the PCEP ERO or the PCEP 337 PATH-KEY object. 339 PKS with 32-bit PCE ID 341 The PKS with 32-bit PCE ID Type is to be assigned by IANA 342 (recommended value 64) 344 0 1 2 3 345 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 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 |L| Type | Length | Path Key | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | PCE ID (4 bytes) | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 L 354 The L bit SHOULD NOT be set, so that the subobject 355 represents a strict hop in the explicit route. 357 Type 359 TBD Path Key with 32-bit PCE ID 361 Length 363 The Length contains the total length of the subobject in 364 bytes, including the Type and Length fields. The Length 365 is always 8. 367 PCE ID 369 Bradford, Vasseur, and Farrel 8 370 Draft-ietf-pce-path-key-01.txt September 2007 372 A 32-bit identifier of the PCE that can decode this key. The 373 identifier MUST be unique within the scope of the domain 374 that the CPS crosses, and MUST be understood by the LSR that 375 will act as PCC for the expansion of the PKS. The 376 interpretation of the PCE-ID is subject to domain-local 377 policy. It MAY be an IPv4 address of the PCE that is always 378 reachable, and MAY be an address that is restricted to the 379 domain in which the LSR that is called upon to expand the 380 CPS lies. Other values that have no meaning outside the 381 domain (for example, the Router ID) MAY be used to increase 382 security (see Section 6). 384 PKS with 128-bit PCE ID 386 The PKS with 128-bit PCE ID Type is to be assigned by IANA 387 (recommended value 65) 389 0 1 2 3 390 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 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 |L| Type | Length | Path Key | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | PCE ID (16 bytes) | 395 | | 396 | | 397 | | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 L 402 As above. 404 Type 406 TBD Path Key with 128-bit PCE ID 408 Length 410 The Length contains the total length of the subobject in 411 bytes, including the Type and Length fields. The Length 412 is always 20. 414 PCE ID 416 Bradford, Vasseur, and Farrel 9 417 Draft-ietf-pce-path-key-01.txt September 2007 419 A 128-bit identifier of the PCE that can decode this key. 420 The identifier MUST be unique within the scope of the 421 domain that the CPS crosses, and MUST be understood by the 422 LSR that will act as PCC for the expansion of the PKS. The 423 interpretation of the PCE-ID is subject to domain-local 424 policy. It MAY be an IPv6 address of the PCE that is 425 always reachable, but MAY be an address that is restricted 426 to the domain in which the LSR that is called upon to 427 expand the CPS lies. Other values that have no meaning 428 outside the domain (for example, the IPv6 TE Router ID) 429 MAY be used to increase security (see Section 6). 431 4.3. Path Key Bit 432 [PCEP] defines the Request Parameters (RP) object that is used to 433 specify various characteristics of the path computation request. 435 In this document we define a new bit named the Path Key bit 436 defined as follow: 438 Path Key (P-bit - 1 bit - Value=0x80): When set, the requesting 439 PCC requires the retrieval of a strict path segment that 440 corresponds to a PKS carried in a PATH_KEY object in the path 441 computation request. The Path Key bit MUST be cleared when the 442 path computation request is not related to a CPS retrieval. 444 5. PCEP Mode of Operation 446 The retrieval of the explicit path (the CPS) associated with a PKS 447 by a PCC is no different than any other path computation request 448 with the exception that the PCReq message MUST contain a PATH_KEY 449 object and the Path Key bit of the RP object MUST the set. 451 If the receiving PCE does not recognize itself as identified by the 452 PCE ID carried in the PKS it MAY forward the PCReq message to 453 another PCE according to local policy. If the PCE does not forward 454 such a PCReq, it MUST respond with a PCRep message containing a NO- 455 PATH object. 457 If the receiving PCE recognizes itself, but cannot find the 458 related CPS, or if the retrieval of the CPS is not allowed by 459 policy, the PCE MUST send a PCRep message that contains a NO-PATH 460 object. 462 Bradford, Vasseur, and Farrel 10 463 Draft-ietf-pce-path-key-01.txt September 2007 465 Upon receipt of a negative reply, the requesting LSR MUST fail the 466 LSP setup and SHOULD use the procedures associated with loose hop 467 expansion failure [RFC3209]. 469 6. Security Considerations 471 This document describes tunneling confidential path information 472 across an untrusted domain (such as an AS). There are many 473 security considerations that apply to PCEP and RSVP-TE. 475 Issues include: 476 - Confidentiality of the CPS (can other network elements probe for 477 expansion of path-keys, possibly at random?). 479 - Authenticity of the path-key (resilience to alteration by 480 intermediaries, resilience to fake expansion of path-keys). 482 - Resilience from DNS attacks (insertion of spurious path-keys; 483 flooding of bogus path-key expansion requests). 485 Most of the interactions required by this extension are point to 486 point, can be authenticated and made secure. These interactions 487 include the: 488 - PCC->PCE request 489 - PCE->PCE request(s) 490 - PCE->PCE response(s) 491 - PCE->PCC response 492 - LSR->LSR request and response (Note that a rogue LSR could 493 modify the ERO and insert or modify Path Keys. This would 494 result in an LSR (which is downstream in the ERO) sending 495 decode requests to a PCE. This is actually a larger problem 496 with RSVP. The rogue LSR is an existing issue with RSVP and 497 will not be addressed here. 498 - LSR->PCE request. Note that the PCE can check that the LSR 499 requesting the decode is the LSR at the head of the Path Key. 500 This largely contains the previous problem to DoS rather than 501 a security issue. A rogue LSR can issue random decode 502 requests, but these will amount only to DoS. 503 - PCE->LSR response. 505 Bradford, Vasseur, and Farrel 11 506 Draft-ietf-pce-path-key-01.txt September 2007 508 Thus, the major security issues can be dealt with using standard 509 techniques for securing and authenticating point-to-point 510 communications. In addition, it is recommended that the PCE 511 providing a decode response should check that the LSR that issued 512 the decode request is the head end of the decoded ERO segment. 514 Further protection can be provided by using a PCE ID to identify the 515 decoding PCE that is only meaningful within the domain that contains 516 the LSR at the head of the CPS. This may be an IP address that is only 517 reachable from within the domain, or some not-address value. The former 518 requires configuration of policy on the PCEs, the latter requires 519 domain-wide policy. 521 7. Manageability Considerations 523 7.1. Control of Function Through Configuration and Policy 525 The treatment of a path segment as a CPS, and its substitution in 526 a PCReq ERO with a PKS, is a function that MUST be under operator 527 and policy control where a PCE supports the function. The operator 528 MUST be given the ability to specify which path segments are to be 529 replaced and under what circumstances. For example, an operator 530 might set a policy that states that every path segment for the 531 operator's domain will be replaced by a PKS when the PCReq has 532 been issued from outside the domain. 534 The operation of the PKS extensions require that path-keys are 535 retained by the issuing PCE to be available for retrieval by an 536 LSR (acting as a PCC) at a later date. But it is possible that the 537 retrieval request will never be made, so good housekeeping 538 requires that a timer is run to discard unwanted path-keys. A 539 default value for this timer is suggested in the body of this 540 document. Implementations SHOULD provide the ability for this 541 value to be over-ridden through operator configuration or policy. 543 After a PKS has been expanded in response to a retrieval request, 544 it may be valuable to retain the path-key and CPS for debug 545 purposes. Such retention SHOULD NOT be the default behavior of an 546 implementation, but MAY be available in response to operator 547 request. 549 Once a path-key has been discarded, the path-key value SHOULD not 550 be immediately available for re-use for a new CPS since this might 552 Bradford, Vasseur, and Farrel 12 553 Draft-ietf-pce-path-key-01.txt September 2007 555 lead to accidental misuse. A default timer value is suggested in 556 the body of this document. Implementations SHOULD provide the 557 ability for this value to be over-ridden through operator 558 configuration or policy. 560 A PCE must set a PCE-ID value in each PKS it creates so that PCCs 561 can correctly identify it and send PCReq messages to expand the 562 PKS to a path segment. A PCE implementation SHOULD allow operator 563 or policy control of the value to use as the PCE-ID. If the PCE 564 allows PCE-ID values that are not routable addresses to be used, 565 the PCCs MUST be configurable (by the operator or through policy) 566 to allow them to map from the PCE-ID to a routable address of the 567 PCE. Such mapping may be algorithmic, procedural (for example, 568 mapping a PCE-ID equal to the IGP Router ID into a routable 569 address), or configured through a local or remote mapping table. 571 7.2. Information and Data Models 573 A MIB module for PCEP is already defined in [PCEP-MIB]. The 574 configurable items listed in Section 7.1 MUST be added as readable 575 objects in the module and SHOULD be added as writable objects. 577 A new MIB module MUST be created to allow inspection of path-keys. 578 For a given PCE, this MIB module MUST provide a mapping from path- 579 key to path segment (that is, a list of hops), and MUST supply 580 other information including: 582 - The identity of the PCC that issued the original request that 583 led to the creation of the path-key. 584 - The request ID of the original PCReq. 585 - Whether the path-key has been retrieved yet, and if so, by which 586 PCC. 587 - How long until the path segment associated with the path-key 588 will be discarded. 589 - How long until the path-key will be available for re-use. 591 7.3. Liveness Detection and Monitoring 593 The procedures in this document extend PCEP, but do not introduce 594 new interactions between network entities. Thus, no new liveness 595 detection or monitoring is required. 597 It is possible that a head-end LSR that has be given a path 598 including PKSs replacing specific CPSs will want to know whether 599 the path-keys are still valid (or have timed out). However, rather 601 Bradford, Vasseur, and Farrel 13 602 Draft-ietf-pce-path-key-01.txt September 2007 604 than introduce a mechanism to poll the PCE that is responsible for 605 the PKS, it is considered pragmatic to simply signal the 606 associated LSP. 608 7.4. Verifying Correct Operation 610 The procedures in this document extend PCEP, but do not introduce 611 new interactions between network entities. Thus, no new tools for 612 verifying correct operation are required. 614 A PCE SHOULD maintain counters and logs of the following events 615 that might indicate incorrect operation (or might indicate 616 security issues). 618 - Attempts to expand an unknown path-key. 619 - Attempts to expand an expired path-key. 620 - Duplicate attempts to expand the same path-key. 621 - Expiry of path-key without attempt to expand it. 623 7.5. Requirements on Other Protocols and Functional Components 625 The procedures described in this document require that the LSRs 626 signal PKSs as defined in [RSVP-PKS]. Note that the only changes 627 to LSRs are at the PCCs. Specifically, changes are only needed at 628 the head-end LSRs that build RSVP-TE Path messages containing 629 Path-Key Subobjects in their EROs, and the LSRs that discover such 630 subobjects as next hops and must expand them. Other LSRs in the 631 network, even if they are on the path of the LSP, will not be 632 called upon to process the PKS. 634 7.6. Impact on Network Operation 636 As well as the security and confidentiality aspects addressed by 637 the use of the PKS, there may be some scaling benefits associated 638 with the procedures described in this document. For example, a 639 single PKS in an explicit route may substitute for many subobjects 640 and can reduce the overall message size correspondingly. In some 641 circumstances, such as when the explicit route contains multiple 642 subobjects for each hop (including node IDs, TE link IDs, 643 component link IDs for each direction of a bidirectional LSP, and 644 label IDs for each direction of a bidirectional LSP) or when the 645 LSP is a point-to-multipoint LSP, this scaling improvement may be 646 very significant. 648 Bradford, Vasseur, and Farrel 14 649 Draft-ietf-pce-path-key-01.txt September 2007 651 Note that a PCE will not supply a PKS unless it is knows that the 652 LSR that will receive the PKS through signaling will be able to 653 handle it. Furthermore, as noted in Section 7.5, only those LSRs 654 specifically called upon to expand the PKS will be required to 655 process the subobjects during signaling. Thus, the only backward 656 compatibility issues associated with the procedures introduced in 657 this document arise when a head-end LSR receives a PCRep with an 658 ERO containing a PKS and does not know how to encode this into 659 signaling. 661 Since the PCE that inserted the PKS requires to keep the CPS 662 confidential, the legacy head-end LSR cannot be protected. It must 663 either fail the LSP setup, or request a new path computation 664 avoiding the domain that has supplied it with unknown subobjects. 666 8. IANA Considerations 668 IANA assigns value to PCEP parameters in registries defined in 669 [PCEP]. IANA is requested to make the following additional 670 assignments. 672 8.1. New Subobjects for the ERO Object 674 IANA has previously assigned an Object-Class and Object-Type to 675 the ERO carried in PCEP messages [PCEP]. IANA also maintains a 676 list of subobject types valid for inclusion in the ERO. 678 IANA is requested to assign two new subobject types for inclusion 679 in the ERO as follows: 681 7 ERO 1 Explicit route [PCEP] 683 Subobject Type 684 64 Path Key with 32-bit PCE ID [This.I-D] 685 65 Path Key with 128-bit PCE ID [This.I-D] 687 8.2. New PCEP Object 689 IANA is requested to assign a new object class in the registry of 690 PCEP Objects as follows. 692 Bradford, Vasseur, and Farrel 15 693 Draft-ietf-pce-path-key-01.txt September 2007 695 Object Name Object Name Reference 696 Class Type 698 16 PATH-KEY 1 Path Key [This.I-D] 700 Subobjects 701 This object may carry the following subobjects as defined 702 for the ERO object. 704 64 Path Key with 32-bit PCE ID [This.I-D] 705 65 Path Key with 128-bit PCE ID [This.I-D] 707 8.3. New RP Object Bit Flag 709 IANA maintains a registry of bit flags carried in the PCEP RP 710 object as defined in [PCEP]. IANA is requested to define a new bit 711 flag as follows: 713 Bit Hex Name Reference 714 Number 715 09 0x0080 Path Key (P-bit) [This.I-D] 717 9. Intellectual Property Considerations 719 The IETF takes no position regarding the validity or scope of any 720 Intellectual Property Rights or other rights that might be claimed 721 to pertain to the implementation or use of the technology 722 described in this document or the extent to which any license 723 under such rights might or might not be available; nor does it 724 represent that it has made any independent effort to identify any 725 such rights. Information on the procedures with respect to rights 726 in RFC documents can be found in BCP 78 and BCP 79. 728 Copies of IPR disclosures made to the IETF Secretariat and any 729 assurances of licenses to be made available, or the result of an 730 attempt made to obtain a general license or permission for the use 731 of such proprietary rights by implementers or users of this 732 specification can be obtained from the IETF on-line IPR repository 733 at http://www.ietf.org/ipr. 735 The IETF invites any interested party to bring to its attention 736 any copyrights, patents or patent applications, or other 737 proprietary rights that may cover technology that may be required 738 to implement this standard. Please address the information to the 739 IETF at ietf-ipr@ietf.org. 741 Bradford, Vasseur, and Farrel 16 742 Draft-ietf-pce-path-key-01.txt September 2007 744 10. References 746 10.1. Normative References 748 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 749 Requirement Levels", BCP 14, RFC 2119, March 1997. 751 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. 752 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 753 3209, December 2001. 755 [PCEP] Vasseur, J.P., Le Roux, J.L., Ayyangar, A., Oki, E., 756 Ikejiri, A., Atlas, A., Dolganow, A., "Path Computation Element 757 (PCE) communication Protocol (PCEP)", draft-ietf-pce-pcep, 758 work in progress. 760 10.2. Informational References 761 [RSVP-PKS] Bradford, R., Vasseur, J.P., Farrel, A., "RSVP 762 Extensions for Path Key Support", draft-bradford-ccamp-path-key- 763 ero, work in progress. 765 [RFC4655] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation 766 Element (PCE) Architecture", RFC4655, September 2006. 768 [PD-PATH-COMP] Vasseur, J., et al "A Per-domain path computation 769 method for establishing Inter-domain Traffic Engineering (TE) 770 Label 771 Switched Paths (LSPs)", draft-ietf-ccamp-inter-domain-pd-path- 772 comp, work in progress. 774 [BRPC] Vasseur, J., et al "A Backward Recursive PCE-based 775 Computation 776 (BRPC) procedure to compute shortest inter-domain Traffic 777 Engineering Label Switched Path", draft-ietf-pce-brpc, work in 778 progress. 780 [RFC4105] Le Roux, J., Vasseur, JP, Boyle, J., "Requirements 781 for Support of Inter-Area and Inter-AS MPLS Traffic Engineering", 782 RFC 4105, June 2005. 784 [RFC4216] Zhang, R., Vasseur, JP., et. al., "MPLS Inter-AS 785 Traffic Engineering requirements", RFC 4216, November 2005. 787 Bradford, Vasseur, and Farrel 17 788 Draft-ietf-pce-path-key-01.txt September 2007 790 [INTER-DOM-REC] Takeda, T., et al, "Analysis of Inter-domain Label 791 Switched Path (LSP) Recovery", draft-ietf-ccamp-inter-domain- 792 recovery-analysis, work in progress. 794 [PCEP-MIB] Kiran Koushik, A., and Stephan, E., "PCE communication 795 protocol (PCEP) Management Information Base", draft-kkoushik-pce- 796 pcep-mib, work in progress. 798 11. Authors' Addresses: 800 Rich Bradford (Editor) 801 Cisco Systems, Inc. 802 1414 Massachusetts Avenue 803 Boxborough, MA - 01719 804 USA 805 EMail: rbradfor@cisco.com 807 J.-P Vasseur 808 Cisco Systems, Inc. 809 1414 Massachusetts Avenue 810 Boxborough, MA - 01719 811 USA 812 EMail: jpv@cisco.com 814 Adrian Farrel 815 Old Dog Consulting 816 EMail: adrian@olddog.co.uk 818 Bradford, Vasseur, and Farrel 18 819 Draft-ietf-pce-path-key-01.txt September 2007 821 Full Copyright Statement 823 Copyright (C) The IETF Trust (2007). 825 This document is subject to the rights, licenses and restrictions 826 contained in BCP 78, and except as set forth therein, the authors 827 retain all their rights. 829 This document and the information contained herein are provided on an 830 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 831 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 832 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 833 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 834 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 835 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 837 Intellectual Property 839 The IETF takes no position regarding the validity or scope of any 840 Intellectual Property Rights or other rights that might be claimed to 841 pertain to the implementation or use of the technology described in 842 this document or the extent to which any license under such rights 843 might or might not be available; nor does it represent that it has 844 made any independent effort to identify any such rights. Information 845 on the procedures with respect to rights in RFC documents can be 846 found in BCP 78 and BCP 79. 848 Copies of IPR disclosures made to the IETF Secretariat and any 849 assurances of licenses to be made available, or the result of an 850 attempt made to obtain a general license or permission for the use of 851 such proprietary rights by implementers or users of this 852 specification can be obtained from the IETF on-line IPR repository at 853 http://www.ietf.org/ipr. 855 The IETF invites any interested party to bring to its attention any 856 copyrights, patents or patent applications, or other proprietary 857 rights that may cover technology that may be required to implement 858 this standard. Please address the information to the IETF at 859 ietf-ipr@ietf.org. 861 Bradford, Vasseur, and Farrel 19