idnits 2.17.1 draft-ietf-pce-path-key-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Networking Working Group Rich Bradford (Ed) 2 Internet-Draft JP Vasseur 3 Intended Status: Standards Track Cisco Systems, Inc. 4 Created: March 7, 2009 Adrian Farrel 5 Expires: September 7, 2009 Old Dog Consulting 7 Preserving Topology Confidentiality in Inter-Domain Path 8 Computation Using a Key-Based Mechanism 10 draft-ietf-pce-path-key-06.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with 15 the provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) 36 Traffic Engineering (TE) Label Switched Paths (LSPs) may be 37 computed by Path Computation Elements (PCEs). Where the TE LSP 38 crosses multiple domains, such as Autonomous Systems (ASes), the 39 path may be computed by multiple PCEs that cooperate, with each 40 responsible for computing a segment of the path. However, in some 41 cases (e.g., when ASes are administered by separate Service 42 Providers), it would break confidentiality rules for a PCE to 43 supply a path segment to a PCE in another domain, thus disclosing 44 AS-internal topology information. This issue may be circumvented 45 by returning a loose hop and by invoking a new path computation 46 from the domain boundary Label Switching Router (LSR) during TE 47 LSP setup as the signaling message enters the second domain, but 48 this technique has several issues including the problem of 49 maintaining path diversity. 51 This document defines a mechanism to hide the contents of a 52 segment of a path, called the Confidential Path Segment (CPS). The 53 CPS may be replaced by a path-key that can be conveyed in the PCE 54 Communication Protocol (PCEP) and signaled within in a Resource 55 Reservation Protocol TE (RSVP-TE) explicit route object. 57 Conventions used in this document 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 60 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 61 "OPTIONAL" in this document are to be interpreted as described in 62 RFC-2119 [RFC2119]. 64 Table of contents 66 1. Introduction.................................................3 67 1.1. Terminology.................................................4 68 2. Path-Key Solution............................................5 69 2.1. Mode of Operation...........................................5 70 2.2. Example.....................................................6 71 3. PCEP Protocol Extensions.....................................7 72 3.1. Path Keys in PCRep Messages.................................7 73 3.1.1. PKS with 32-bit PCE ID....................................8 74 3.1.2. PKS with 128-bit PCE ID...................................9 75 3.2. Unlocking Path Keys.........................................9 76 3.2.1. Path Key Bit.............................................10 77 3.2.2. PATH-KEY Object..........................................10 78 3.2.3. Path Computation Request (PCReq) message with Path Key...10 79 4. PCEP Mode of Operation for Path Key Expansion...............11 80 5. Security Considerations.....................................12 81 6. Manageability Considerations................................13 82 6.1. Control of Function Through Configuration and Policy.......13 83 6.2. Information and Data Models................................14 84 6.3. Liveness Detection and Monitoring..........................14 85 6.4. Verifying Correct Operation................................14 86 6.5. Requirements on Other Protocols and Functional Components..15 87 6.6. Impact on Network Operation................................15 88 7. IANA Considerations.........................................15 89 7.1. New Subobjects for the ERO Object..........................15 90 7.2. New PCEP Object............................................16 91 7.3. New RP Object Bit Flag.....................................16 92 7.4. New NO-PATH-VECTOR TLV Bit Flag............................16 93 8. Normative References........................................17 94 9. Informational References....................................17 95 10. Acknowledgements...........................................18 96 11. Authors' Addresses.........................................18 98 1. Introduction 100 Path computation techniques using the Path Computation Element 101 (PCE) are described in [RFC4655] and allow for path computation of 102 inter-domain Multiprotocol Label Switching (MPLS) Traffic 103 Engineering (TE) and Generalized MPLS (GMPLS) Label Switched Paths 104 (LSPs). 106 An important element of inter-domain TE is that TE information is 107 not shared between domains for scalability and confidentiality 108 reasons ([RFC4105] and [RFC4216]). Therefore, a single PCE is 109 unlikely to be able to compute a full inter-domain path. 111 Two path computation scenarios can be used for inter-domain TE 112 LSPs: one using per-domain path computation (defined in [RFC5152]), 113 and the other using a PCE-based path computation technique with 114 cooperation between PCEs (as described in [RFC4655]). In this second 115 case, paths for inter-domain LSPs can be computed by cooperation 116 between PCEs each of which computes a segment of the path across one 117 domain. Such a path computation procedure is described in [BRPC]. 119 If confidentiality is required between domains (such as would very 120 likely be the case between Autonomous Systems (ASes) belonging to 121 different Service Providers) then cooperating PCEs cannot exchange 122 path segments or else the receiving PCE and the Path Computation 123 Client (PCC) will be able to see the individual hops through 124 another domain thus breaking the confidentiality requirement 125 stated in [RFC4105] and [RFC4216]. We define the part of the path 126 which we wish to keep confidential as the Confidential Path 127 Segment (CPS). 129 One mechanism for preserving the confidentiality of the CPS is for 130 the PCE to return a path containing a loose hop in place of the 131 segment that must be kept confidential. The concept of loose and 132 strict hops for the route of a TE LSP is described in [RFC3209]. 133 The Path Computation Element Communication Protocol (PCEP) defined 134 in [RFC5440] supports the use of paths with loose hops, and it is a 135 local policy decision at a PCE whether it returns a full explicit 136 path with strict hops or uses loose hops. Note that a Path 137 computation Request may request an explicit path with strict hops 138 or may allow loose hops as detailed in [RFC5440]. 140 The option of returning a loose hop in place of the CPS can be 141 achieved without further extensions to PCEP or the signaling 142 protocol. If loose hops are used, the TE LSPs are signaled as 143 normal ([RFC3209]), and when a loose hop is encountered in the 144 explicit route it is resolved by performing a secondary path 145 computation to reach the resource or set of resources identified 146 by the loose hop. Given the nature of the cooperation between PCEs 147 in computing the original path, this secondary computation occurs 148 at or on behalf of a Label Switching Router (LSR) at a domain 149 boundary (i.e., an Area Border Router (ABR) or an AS Border Router 150 (ASBR)) and the path is expanded as described in [RFC5152]. 152 The PCE-based computation model is particularly useful for 153 determining mutually disjoint inter-domain paths such as might be 154 required for service protection [RFC5298]. A single path computation 155 request is used. However, if loose hops are returned, the path of 156 each TE LSP must be recomputed at the domain boundaries as the TE 157 LSPs are signaled, and since the TE LSP signaling proceeds 158 independently for each TE LSP, disjoint paths cannot be guaranteed 159 since the LSRs in charge of expanding the EROs are not synchronized. 160 Therefore, if the loose hop technique is used without further 161 extensions, path segment confidentiality and path diversity are 162 mutually incompatible requirements. 164 This document defines the notion of a Path Key that is a token 165 that replaces a path segment in an explicit route. The Path Key is 166 encoded as a Path Key Subobject (PKS) returned in the PCEP Path 167 Computation Reply message (PCRep) ([RFC5440]). Upon receiving the 168 computed path, the PKS will be carried in an RSVP-TE Path message 169 (RSVP-TE [RFC3209] and [RSVP-PKS]) during signaling. 171 The BNF in this document follows the format described in [RBNF]. 173 1.1. Terminology 175 This document makes use of the following terminology and acronyms. 177 AS: Autonomous System. 179 ASBR: Autonomous System Border Routers used to connect to another 180 AS of a different or the same Service Provider via one or more 181 links inter-connecting between ASes. 183 CPS: Confidential Path Segment. A segment of a path that contains 184 nodes and links that the AS policy requires to not be disclosed 185 outside the AS. 187 Inter-AS TE LSP: A TE LSP that crosses an AS boundary. 189 LSR: Label Switching Router. 191 LSP: Label Switched Path. 193 PCC: Path Computation Client: Any client application requesting a 194 path computation to be performed by a Path Computation Element. 196 PCE: Path Computation Element: An entity (component, application 197 or network node) that is capable of computing a network path or 198 route based on a network graph and applying computational 199 constraints. 201 TE LSP: Traffic Engineering Label Switched Path 203 2. Path-Key Solution 205 The Path-Key solution may be applied in the PCE-based path 206 computation context as follows. A PCE computes a path segment 207 related to a particular domain and replaces any CPS in the path 208 reported to the requesting PCC (or another PCE) by one or more 209 subobjects referred to as PKSes. The entry boundary LSR of each 210 CPS SHOULD be specified using its TE Router Id as a hop in the 211 returned path immediately preceding the CPS, and other sub-objects 212 MAY be included in the path immediately before the hop identifying 213 the boundary LSR to indicate link and label choices. Where two 214 PKSes are supplied in sequence with no intervening nodes, the 215 entry node to the second CPS MAY be part of the first CPS and does 216 not need to be explicitly present in the returned path. The exit 217 node of a CPS MAY be present as a strict hop immediately following 218 the PKS. 220 2.1. Mode of Operation 222 During path computation, when local policy dictates that 223 confidentiality must be preserved for all or part of the path 224 segment being computed or if explicitly requested by the Path 225 Computation Request, the PCE associates a path-key with the 226 computed path for the CPS, places its own identifier (its PCE ID 227 as defined in Section 3.1) along with the path-key in a PKS, and 228 inserts the PKS object in the path returned to the requesting PCC 229 or PCE immediately after the subobject that identifies (using the 230 TE Router Id) the LSR that will expand the PKS into explicit path 231 hops.This will usually be the LSR that is the start point of the 232 CPS. The PCE that generates a PKS SHOULD store the computed path 233 segment and the path-key for later retrieval. A local policy 234 SHOULD be used to determine for how long to retain such stored 235 information, and whether to discard the information after it has 236 been queried using the procedures described below. It is 237 RECOMMENDED for a PCE to store the PKS for a period of 10 minutes. 239 A path-key value is scoped to the PCE that computed it as 240 identified by the PCE-ID carried in the PKS. A PCE MUST NOT re-use 241 a path-key value to represent a new CPS for at least 30 minutes 242 after discarding the previous use of the same path-key. A PCE that 243 is unable to retain information about previously used path-key 244 values over a restart SHOULD use some other mechanism to guarantee 245 uniqueness of path-key values such as embedding a timestamp or 246 version number in the path-key. 248 A head-end LSR that is a PCC converts the path returned by a PCE 249 into an explicit route object (ERO) that it includes in the 250 Resource Reservation Protocol (RSVP) Path message. If the path 251 returned by the PCE contains a PKS, this is included in the ERO. 252 Like any other subobjects, the PKS is passed transparently from 253 hop to hop, until it becomes the first subobject in the ERO. This 254 will occur at the start of the CPS which will usually be the 255 domain boundary. The PKS MUST be preceded by an ERO subobject that 256 identifies the LSR that must expand the PKS. This means that 257 (following the rules for ERO processing set out in [RFC3209]) 258 the PKS will not be encountered in ERO processing until the ERO is 259 being processed by the LSR that is capable of correctly handling the 260 PKS. 262 An LSR that encounters a PKS when trying to identify the next-hop 263 retrieves the PCE-ID from the PKS and sends a Path Computation 264 Request (PCReq) message as defined in [RFC5440] to the PCE identified 265 by the PCE-ID that contains the path-key object . 267 Upon receiving the PCReq message, the PCE identifies the computed 268 path segment using the supplied path-key, and returns the 269 previously computed path segment in the form of explicit hops 270 using an ERO object contained in the Path Computation Reply 271 (PCReqp) to the requesting node as defined in [RFC5440]. The 272 requesting node inserts the explicit hops into the ERO and 273 continues to process the TE LSP setup as per [RFC3209]. 275 2.2. Example 277 Figure 1 shows a simple two-AS topology with a PCE responsible 278 for the path computations in each AS. An LSP is requested from 279 the ingress LSR in one AS to the egress LSR in the other AS. The 280 ingress, acting as PCC, sends a path computation request to PCE- 281 1. PCE-1 is unable to compute an end-to-end path and invokes PCE- 282 2 (possibly using the techniques described in [BRPC]). PCE-2 283 computes a path segment from ASBR-2 to the egress as {ASBR-2, C, 284 D, Egress}. It could pass this path segment back to PCE-1 in 285 full, or it could send back the path {ASBR-2, Egress} where the 286 second hop is a loose hop. 288 However, in order to protect the confidentiality of the topology 289 in the second AS while still specifying the path in full, PCE-2 290 may send PCE-1 a path segment expressed as {ASBR-2, PKS, Egress} 291 where the PKS is a Path Key Subobject as defined in this 292 document. In this case, PCE-2 has identified the segment {ASBR-2, 293 C, D, Egress} as a Confidential Path Segment (CPS). PCE-1 will 294 compute the path segment that it is responsible for, and will 295 supply the full path to the PCC as {Ingress, A, B, ASBR-1, ASBR- 296 2, PKS, Egress}. 298 Signaling proceeds in the first AS as normal, but when the Path 299 message reaches ASBR-2 the next hop is the PKS, and this must be 300 expanded before signaling can progress further. ASBR-2 uses the 301 information in the PKS to request PCE-2 for a path segment, and 302 PCE-2 will return the segment {ASBR-2, C, D, Egress} allowing 303 signaling to continue to set up the LSP. 305 ----------------------------- ---------------------------- 306 | ------- | | ------- | 307 | | PCE-1 |<---------------+--+-->| PCE-2 | | 308 | ------- | | ------- | 309 | ^ | | ^ | 310 | | | | | | 311 | v | | v | 312 | ------- ---- | | ---- | 313 | | PCC | - - |ASBR| | | |ASBR| - - ------ | 314 | |Ingress|--|A|--|B|--| 1 |-+--+-| 2 |--|C|--|D|--|Egress| | 315 | ------- - - ----- | | ---- - - ------ | 316 | | | | 317 ----------------------------- ---------------------------- 319 Figure 1 : A Simple network to demonstrate the use of the PKS 321 3. PCEP Protocol Extensions 323 3.1. Path Keys in PCRep Messages 325 Path Keys are carried in PCReq and PCRep messages as part of the 326 various objects that carry path definitions. In particular, a Path 327 Key is carried in the Explicit Route Object (ERO) on PCRep 328 messages. 330 In all cases, the Path Key is carried in a Path Key Subobject 331 (PKS). 333 The PKS is a fixed-length subobject containing a Path-Key and a 334 PCE-ID. The Path Key is an identifier, or token used to represent 335 the CPS within the context of the PCE identified by the PCE-ID. 336 The PCE-ID identifies the PCE that can decode the Path Key using 337 an identifier that is unique within the domain that the PCE 338 serves. The PCE-ID has to be mapped to a reachable IPv4 or IPv6 339 address of the PCE by the first node of the CPS (usually a domain 340 border router) and a PCE MAY use one of its reachable IP addresses 341 as its PCE-ID. Alternatively and to provide greater security (see 342 Section 5) or increased confidentiality, according to domain-local 343 policy, the PCE MAY use some other identifier that is scoped only 344 within the domain. 346 To allow IPv4 and IPv6 addresses to be carried, two subobjects are 347 defined in the following subsections. 349 The Path Key Subobject may be present in the PCEP ERO or the PCEP 350 PATH-KEY object (see Section 3.2). 352 3.1.1. PKS with 32-bit PCE ID 354 The Subobject Type for the PKS with 32-bit PCE ID is to be 355 assigned by IANA (recommended value 64). The format of this 356 subobject is as follows: 358 0 1 2 3 359 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 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 |L| Type | Length | Path Key | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | PCE ID (4 bytes) | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 L 368 The L bit SHOULD NOT be set, so that the subobject represents a 369 strict hop in the explicit route. 371 Type 373 Subobject Type for a Path Key with 32-bit PCE ID as assigned by 374 IANA. 376 Length 378 The Length contains the total length of the subobject in bytes, 379 including the Type and Length fields. The Length is always 8. 381 PCE ID 383 A 32-bit identifier of the PCE that can decode this key. The 384 identifier MUST be unique within the scope of the domain that 385 the CPS crosses, and MUST be understood by the LSR that will 386 act as PCC for the expansion of the PKS. The interpretation of 387 the PCE-ID is subject to domain-local policy. It MAY be an IPv4 388 address of the PCE that is always reachable, and MAY be an 389 address that is restricted to the domain in which the LSR that 390 is called upon to expand the CPS lies. Other values that have 391 no meaning outside the domain (for example, the Router ID of 392 the PCE) MAY be used to increase security or confidentiality 393 (see Section 5). 395 3.1.2. PKS with 128-bit PCE ID 397 The Subobject Type for the PKS with 128-bit PCE ID is to be 398 assigned by IANA (recommended value 65). The format of the 399 subobject is as follows. 401 0 1 2 3 402 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 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 |L| Type | Length | Path Key | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | PCE ID (16 bytes) | 407 | | 408 | | 409 | | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 L 414 As above. 416 Type 418 Subobject Type for a Path Key with 128-bit PCE ID as assigned 419 by IANA. 421 Length 423 The Length contains the total length of the subobject in bytes, 424 including the Type and Length fields. The Length is always 20. 426 PCE ID 428 A 128-bit identifier of the PCE that can decode this key. The 429 identifier MUST be unique within the scope of the domain that 430 the CPS crosses, and MUST be understood by the LSR that will 431 act as PCC for the expansion of the PKS. The interpretation of 432 the PCE-ID is subject to domain-local policy. It MAY be an IPv6 433 address of the PCE that is always reachable, but MAY be an 434 address that is restricted to the domain in which the LSR that 435 is called upon to expand the CPS lies. Other values that have 436 no meaning outside the domain (for example, the IPv6 TE Router 437 ID) MAY be used to increase security (see Section 5). 439 3.2. Unlocking Path Keys 441 When a network node needs to decode a Path Key so that it can 442 continue signaling for an LSP, it must send a PCReq to the 443 designated PCE. The PCReq defined in [RFC5440] needs to be modified 444 to support this usage which differs from the normal path 445 computation request. To that end, a new flag is defined to show 446 that the PCReq relates to the expansion of a PKS, and a new object 447 is defined to carry the PKS in the PCReq. These result in an 448 update to the BNF for the message. The BNF used in this document is 449 as described in [RBNF]. 451 3.2.1. Path Key Bit 453 [RFC5440] defines the Request Parameters (RP) object that is used to 454 specify various characteristics of the path computation request 455 (PCReq). 457 In this document we define a new bit named the Path Key bit as 458 follows. See Section 7.3 for the IANA assignment of the 459 appropriate bit number. 461 Path Key bit: When set, the requesting PCC requires the retrieval 462 of a Confidential Path Segment that corresponds to the PKS carried 463 in a PATH_KEY object in the path computation request. The Path Key 464 bit MUST be cleared when the path computation request is not 465 related to a CPS retrieval. 467 3.2.2. PATH-KEY Object 469 When a PCC needs to expand a path-key in order to expand a CPS it 470 issues a path computation request (PCReq) to the PCE identified in 471 the PKS in the RSVP-TE ERO that it is processing. The PCC supplies 472 the PKS to be expanded in a PATH-KEY Object in the PCReq message. 474 The PATH-KEY Object is defined as follows. 476 PATH-KEY Object-Class is to be assigned by IANA (recommended 477 value=16) 479 Path Key Object-Type is to be assigned by IANA (recommended 480 value=1) 482 The PATH-KEY Object MUST contain at least one Path Key Subobject 483 (see Section 3.1). The first PKS MUST be processed by the PCE. 484 Subsequent subobjects SHOULD be ignored. 486 3.2.3. Path Computation Request (PCReq) message with Path Key 488 The format of a PCReq message including a PATH-KEY object is 489 unchanged as follows: 491 ::= 492 [] 493 495 where: 496 ::=[] 497 ::=[] 499 To support the use of the message to expand a PKS, the definition 500 of is modified as follows : 502 ::= 503 | 505 where: 506 ::= 507 [] 508 [] 509 [] 510 [] 511 [] 512 [] 513 [] 514 ::= 516 Thus, the format of the message for use in normal path computation 517 is unmodified. 519 4. PCEP Mode of Operation for Path Key Expansion 521 The retrieval of the explicit path (the CPS) associated with a PKS 522 by a PCC is no different than any other path computation request 523 with the exception that the PCReq message MUST contain a PATH_KEY 524 object and the Path Key bit of the RP object MUST the set. On 525 receipt of a PCRep containing a CPS, the requesting PCC SHOULD 526 use insert the CPS into the ERO that it will signal, in accordance 527 with local policy. 529 If the receiving PCE does not recognize itself as identified by the 530 PCE ID carried in the PKS it MAY forward the PCReq message to 531 another PCE according to local policy. If the PCE does not forward 532 such a PCReq, it MUST respond with a PCRep message containing a NO- 533 PATH object. 535 If the receiving PCE recognizes itself, but cannot find the 536 related CPS, or if the retrieval of the CPS is not allowed by 537 policy, the PCE MUST send a PCRep message that contains a NO-PATH 538 object. The NO-PATH-VECTOR TLV SHOULD be used as described in 539 [RFC5440] and a new bit-number (see Section 7.4) is assigned to 540 indicate "Cannot expand PKS". 542 Upon receipt of a negative reply, the requesting LSR MUST fail the 543 LSP setup and SHOULD use the procedures associated with loose hop 544 expansion failure [RFC3209]. 546 5. Security Considerations 548 This document describes tunneling confidential path information 549 across an untrusted domain (such as an AS). There are many 550 security considerations that apply to PCEP and RSVP-TE. 552 Issues include: 554 - Confidentiality of the CPS (can other network elements probe for 555 expansion of path-keys, possibly at random?). 557 - Authenticity of the path-key (resilience to alteration by 558 intermediaries, resilience to fake expansion of path-keys). 560 - Resilience from DoS attacks (insertion of spurious path-keys; 561 flooding of bogus path-key expansion requests). 563 Most of the interactions required by this extension are point to 564 point, can be authenticated and made secure as described in [RFC5440] 565 and [RFC3209]. These interactions include the: 567 - PCC->PCE request 568 - PCE->PCE request(s) 569 - PCE->PCE response(s) 570 - PCE->PCC response 571 - LSR->LSR request and response (Note that a rogue LSR could 572 modify the ERO and insert or modify Path Keys. This would 573 result in an LSR (which is downstream in the ERO) sending 574 decode requests to a PCE. This is actually a larger problem 575 with RSVP. The rogue LSR is an existing issue with RSVP and 576 will not be addressed here. 577 - LSR->PCE request. Note that the PCE can check that the LSR 578 requesting the decode is the LSR at the head of the Path Key. 579 This largely contains the previous problem to DoS rather than 580 a security issue. A rogue LSR can issue random decode 581 requests, but these will amount only to DoS. 582 - PCE->LSR response. 584 Thus, the major security issues can be dealt with using standard 585 techniques for securing and authenticating point-to-point 586 communications. In addition, it is recommended that the PCE 587 providing a decode response should check that the LSR that issued 588 the decode request is the head end of the decoded ERO segment. 590 Further protection can be provided by using a PCE ID to identify 591 the decoding PCE that is only meaningful within the domain that 592 contains the LSR at the head of the CPS. This may be an IP address 593 that is only reachable from within the domain, or some not-address 594 value. The former requires configuration of policy on the PCEs, 595 the latter requires domain-wide policy. 597 6. Manageability Considerations 599 6.1. Control of Function Through Configuration and Policy 601 The treatment of a path segment as a CPS, and its substitution in 602 a PCReq ERO with a PKS, is a function that MUST be under operator 603 and policy control where a PCE supports the function. The operator 604 MUST be given the ability to specify which path segments are to be 605 replaced and under what circumstances. For example, an operator 606 might set a policy that states that every path segment for the 607 operator's domain will be replaced by a PKS when the PCReq has 608 been issued from outside the domain. 610 The operation of the PKS extensions require that path-keys are 611 retained by the issuing PCE to be available for retrieval by an 612 LSR (acting as a PCC) at a later date. But it is possible that the 613 retrieval request will never be made, so good housekeeping 614 requires that a timer is run to discard unwanted path-keys. A 615 default value for this timer is suggested in Section 2.1. 616 Implementations SHOULD provide the ability for this value to be over- 617 ridden through operator configuration or policy. 619 After a PKS has been expanded in response to a retrieval request, 620 it may be valuable to retain the path-key and CPS for debug 621 purposes. Such retention SHOULD NOT be the default behavior of an 622 implementation, but MAY be available in response to operator request. 624 Once a path-key has been discarded, the path-key value SHOULD NOT 625 be immediately available for re-use for a new CPS since this might 626 lead to accidental misuse. A default timer value is suggested in 627 Section 2.1. Implementations SHOULD provide the ability for this 628 value to be over-ridden through operator configuration or policy. 630 A PCE must set a PCE-ID value in each PKS it creates so that PCCs 631 can correctly identify it and send PCReq messages to expand the 632 PKS to a path segment. A PCE implementation SHOULD allow operator 633 or policy control of the value to use as the PCE-ID. If the PCE 634 allows PCE-ID values that are not routable addresses to be used, 635 the PCCs MUST be configurable (by the operator or through policy) 636 to allow them to map from the PCE-ID to a routable address of the 637 PCE. Such mapping may be algorithmic, procedural (for example, 638 mapping a PCE-ID equal to the IGP Router ID into a routable 639 address), or configured through a local or remote mapping table. 641 6.2. Information and Data Models 643 A MIB module for PCEP is already defined in [PCEP-MIB]. The 644 configurable items listed in Section 6.1 MUST be added as readable 645 objects in the module and SHOULD be added as writable objects. 647 A new MIB module MUST be created to allow inspection of path-keys. 648 For a given PCE, this MIB module MUST provide a mapping from path- 649 key to path segment (that is, a list of hops), and MUST supply 650 other information including: 652 - The identity of the PCC that issued the original request that 653 led to the creation of the path-key. 654 - The request ID of the original PCReq. 655 - Whether the path-key has been retrieved yet, and if so, by which 656 PCC. 657 - How long until the path segment associated with the path-key 658 will be discarded. 659 - How long until the path-key will be available for re-use. 661 6.3. Liveness Detection and Monitoring 663 The procedures in this document extend PCEP, but do not introduce 664 new interactions between network entities. Thus, no new liveness 665 detection or monitoring is required. 667 It is possible that a head-end LSR that has be given a path 668 including PKSs replacing specific CPSs will want to know whether 669 the path-keys are still valid (or have timed out). However, rather 670 than introduce a mechanism to poll the PCE that is responsible for 671 the PKS, it is considered pragmatic to simply signal the 672 associated LSP. 674 6.4. Verifying Correct Operation 676 The procedures in this document extend PCEP, but do not introduce 677 new interactions between network entities. Thus, no new tools for 678 verifying correct operation are required. 680 A PCE SHOULD maintain counters and logs of the following events 681 that might indicate incorrect operation (or might indicate 682 security issues). 684 - Attempts to expand an unknown path-key. 685 - Attempts to expand an expired path-key. 686 - Duplicate attempts to expand the same path-key. 687 - Expiry of path-key without attempt to expand it. 689 6.5. Requirements on Other Protocols and Functional Components 691 The procedures described in this document require that the LSRs 692 signal PKSs as defined in [RSVP-PKS]. Note that the only changes 693 to LSRs are at the PCCs. Specifically, changes are only needed at 694 the head-end LSRs that build RSVP-TE Path messages containing 695 Path-Key Subobjects in their EROs, and the LSRs that discover such 696 subobjects as next hops and must expand them. Other LSRs in the 697 network, even if they are on the path of the LSP, will not be 698 called upon to process the PKS. 700 6.6. Impact on Network Operation 702 As well as the security and confidentiality aspects addressed by 703 the use of the PKS, there may be some scaling benefits associated 704 with the procedures described in this document. For example, a 705 single PKS in an explicit route may substitute for many subobjects 706 and can reduce the overall message size correspondingly. In some 707 circumstances, such as when the explicit route contains multiple 708 subobjects for each hop (including node IDs, TE link IDs, 709 component link IDs for each direction of a bidirectional LSP, and 710 label IDs for each direction of a bidirectional LSP) or when the 711 LSP is a point-to-multipoint LSP, this scaling improvement may be 712 very significant. 714 Note that a PCE will not supply a PKS unless it is knows that the 715 LSR that will receive the PKS through signaling will be able to 716 handle it. Furthermore, as noted in Section 6.5, only those LSRs 717 specifically called upon to expand the PKS will be required to 718 process the subobjects during signaling. Thus, the only backward 719 compatibility issues associated with the procedures introduced in 720 this document arise when a head-end LSR receives a PCRep with an 721 ERO containing a PKS and does not know how to encode this into 722 signaling. 724 Since the PCE that inserted the PKS requires to keep the CPS 725 confidential, the legacy head-end LSR cannot be protected. It must 726 either fail the LSP setup, or request a new path computation 727 avoiding the domain that has supplied it with unknown subobjects. 729 7. IANA Considerations 731 IANA assigns values to PCEP parameters in registries defined in 732 [RFC5440]. IANA is requested to make the following additional 733 assignments. 735 7.1. New Subobjects for the ERO Object 737 IANA has previously assigned an Object-Class and Object-Type to 738 the ERO carried in PCEP messages [RFC5440]. IANA also maintains a 739 list of subobject types valid for inclusion in the ERO. 741 IANA is requested to assign two new subobject types for inclusion 742 in the ERO as follows: 744 Subobject Type 745 64 Path Key with 32-bit PCE ID [This.I-D] 746 65 Path Key with 128-bit PCE ID [This.I-D] 748 7.2. New PCEP Object 750 IANA is requested to assign a new object class in the registry of 751 PCEP Objects as follows. 753 Object Name Object Name Reference 754 Class Type 756 16 PATH-KEY 1 Path Key [This.I-D] 758 Subobjects 759 This object may carry the following subobjects as defined 760 for the ERO object. 762 64 Path Key with 32-bit PCE ID [This.I-D] 763 65 Path Key with 128-bit PCE ID [This.I-D] 765 7.3. New RP Object Bit Flag 767 IANA maintains a registry of bit flags carried in the PCEP RP 768 object as defined in [RFC5440]. IANA is requested to assign a new bit 769 flag as follows: 771 Bit Hex Name Reference 772 Number 773 15 0x000100 Path Key (P-bit) [This.I-D] 775 7.4. New NO-PATH-VECTOR TLV Bit Flag 777 IANA maintains a registry of bit flags carried in the PCEP NO- 778 PATH-VECTOR TLV in the PCEP NO-PATH object as defined in [RFC5440]. 779 IANA is requested to assign a new bit flag as follows: 781 Bits Number Name Flag Reference 782 1 PKS expansion failure [This.I-D] 784 8. Normative References 786 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 787 Requirement Levels", BCP 14, RFC 2119, March 1997. 789 [RFC5440] Vasseur, J.P., Le Roux, J.L., Ayyangar, A., Oki, E., 790 Ikejiri, A., Atlas, A., Dolganow, A., "Path Computation 791 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 792 March 2009. 794 9. Informative References 796 [RFC3209] Awduche, Berger, Gan, Li, Srinivasan and Swallow, "RSVP-TE: 797 Extensions to RSVP for LSP Tunnels", RFC 3209, December 798 2001. 800 [RFC4105] Le Roux, J., Vasseur, JP., Boyle, J., "Requirements for 801 Support of Inter-Area and Inter-AS MPLS Traffic 802 Engineering", RFC 4105, June 2005. 804 [RFC4216] Zhang, R., Vasseur, JP., et. al., "MPLS Inter-AS Traffic 805 Engineering requirements", RFC 4216, November 2005. 807 [RFC4655] Farrel, Vasseur, & Ash, "A Path Computation Element (PCE)- 808 Based Architecture", RFC 4655, August 2006. 810 [RFC5152] Vasseur, JP., et al "A Per-Domain Path Computation Method 811 for Establishing Inter-Domain Traffic Engineering (TE) 812 Label Switched Paths (LSPs)", RFC 5152, Fenruary 2008. 814 [RFC5298] Takeda, T., et al, "Analysis of Inter-domain Label 815 Switched Path (LSP) Recovery", RFC 5298, August 2008. 817 [RSVP-PKS] Bradford, R., Vasseur, JP., Farrel, A., "RSVP Extensions 818 for Path Key Support", draft-ietf-ccamp-path-key-ero, 819 work in progress. 821 [BRPC] Vasseur, JP., et al "A Backward Recursive PCE-based 822 Computation (BRPC) procedure to compute shortest inter- 823 domain Traffic Engineering Label Switched Path", draft- 824 ietf-pce-brpc, work in progress. 826 [PCEP-MIB] Kiran Koushik, A., and Stephan, E., "PCE communication 827 protocol (PCEP) Management Information Base", draft- 828 ietf-pce-pcep-mib, work in progress. 830 [RBNF] Farrel, A., "Reduced Backus-Naur Form (RBNF) A Syntax Used 831 in Various Protocol Specifications", draft-farrel-rtg- 832 common-bnf, work in progress. 834 10. Acknowledgements 836 The authors would like to thank Eiji Oki, Ben Campbell, and Ross 837 Callon for their comments on this document. 839 11. Authors' Addresses 841 Rich Bradford (Editor) 842 Cisco Systems, Inc. 843 1414 Massachusetts Avenue 844 Boxborough, MA - 01719 845 USA 846 EMail: rbradfor@cisco.com 848 Jean-Philippe Vasseur 849 Cisco Systems, Inc. 850 1414 Massachusetts Avenue 851 Boxborough, MA - 01719 852 USA 853 EMail: jpv@cisco.com 855 Adrian Farrel 856 Old Dog Consulting 857 EMail: adrian@olddog.co.uk 859 Intellectual Property 861 The IETF Trust takes no position regarding the validity or scope of 862 any Intellectual Property Rights or other rights that might be 863 claimed to pertain to the implementation or use of the technology 864 described in any IETF Document or the extent to which any license 865 under such rights might or might not be available; nor does it 866 represent that it has made any independent effort to identify any 867 such rights. 869 Copies of Intellectual Property disclosures made to the IETF 870 Secretariat and any assurances of licenses to be made available, or 871 the result of an attempt made to obtain a general license or 872 permission for the use of such proprietary rights by implementers or 873 users of this specification can be obtained from the IETF on-line IPR 874 repository at http://www.ietf.org/ipr 876 The IETF invites any interested party to bring to its attention any 877 copyrights, patents or patent applications, or other proprietary 878 rights that may cover technology that may be required to implement 879 any standard or specification contained in an IETF Document. Please 880 address the information to the IETF at ietf-ipr@ietf.org. 882 The definitive version of an IETF Document is that published by, or 883 under the auspices of, the IETF. Versions of IETF Documents that are 884 published by third parties, including those that are translated into 885 other languages, should not be considered to be definitive versions 886 of IETF Documents. The definitive version of these Legal Provisions 887 is that published by, or under the auspices of, the IETF. Versions of 888 these Legal Provisions that are published by third parties, including 889 those that are translated into other languages, should not be 890 considered to be definitive versions of these Legal Provisions. 892 For the avoidance of doubt, each Contributor to the IETF Standards 893 Process licenses each Contribution that he or she makes as part of 894 the IETF Standards Process to the IETF Trust pursuant to the 895 provisions of RFC 5378. No language to the contrary, or terms, 896 conditions or rights that differ from or are inconsistent with the 897 rights and licenses granted under RFC 5378, shall have any effect and 898 shall be null and void, whether published or posted by such 899 Contributor, or included with or in such Contribution. 901 Disclaimer of Validity 903 All IETF Documents and the information contained therein are provided 904 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 905 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 906 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 907 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 908 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 909 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 910 FOR A PARTICULAR PURPOSE. 912 Full Copyright Statement 914 Copyright (c) 2009 IETF Trust and the persons identified as the 915 document authors. All rights reserved. 917 This document is subject to BCP 78 and the IETF Trust's Legal 918 Provisions Relating to IETF Documents in effect on the date of 919 publication of this document (http://trustee.ietf.org/license-info). 920 Please review these documents carefully, as they describe your 921 rights and restrictions with respect to this document. 923 This document may contain material from IETF Documents or IETF 924 Contributions published or made publicly available before November 925 10, 2008. The person(s) controlling the copyright in some of this 926 material may not have granted the IETF Trust the right to allow 927 modifications of such material outside the IETF Standards Process. 928 Without obtaining an adequate license from the person(s) 929 controlling the copyright in such materials, this document may not 930 be modified outside the IETF Standards Process, and derivative 931 works of it may not be created outside the IETF Standards Process, 932 except to format it for publication as an RFC or to translate it 933 into languages other than English.