idnits 2.17.1 draft-ietf-pce-interas-pcecp-reqs-06.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 658. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 634. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 641. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 647. 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Nabil Bitar 2 Internet Draft Verizon 3 Intended Status: Informational Raymond Zhang 4 Created: May 7, 2008 BT 5 Expires: October 7, 2008 Kenji Kumaki 6 KDDI Corporation 8 Inter-AS Requirements for the Path Computation Element 9 Communication Protocol (PCEP) 11 draft-ietf-pce-interas-pcecp-reqs-06.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire in October 2008. 38 Abstract 40 Multiprotocol Label Switching Traffic Engineered (MPLS TE) Label 41 Switched Paths (LSPs) may be established wholly within an Autonomous 42 System (AS) or may cross AS boundaries. 44 The Path Computation Element (PCE) is a component that is capable of 45 computing constrained paths for (G)MPLS TE LSPs. The PCE 46 Communication Protocol(PCEP) is defined to allow communication 47 between Path Computation Clients (PCCs) and PCEs, and between PCEs. 48 The PCEP is used to request constrained paths and to supply computed 49 paths in response. Generic requirements for the PCEP are set out in 50 "Path Computation Element (PCE) Communication Protocol Generic 51 Requirements", RFC 4657. This document extends those requirements to 52 cover the use of PCEP in support of inter-AS MPLS TE. 54 Conventions Used in This Document 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 58 document are to be interpreted as described in RFC 2119. 60 Table of Contents 62 1. Introduction....................................................2 63 2. Terminology.....................................................3 64 3. Reference Model.................................................4 65 3.1 Scope of Deployment Model......................................5 66 4. Detailed PCEP Requirements for Inter-AS Computation.............6 67 4.1 PCE Communication Protocol Requirements........................6 68 4.1.1 Requirements for Path Computation Requests...................6 69 4.1.2 Requirements for Path Computation Responses..................7 70 4.2 Scalability and Performance Considerations.....................8 71 4.3 Management Considerations......................................8 72 4.4 Confidentiality................................................9 73 4.5 Policy Controls Affecting Inter-AS PCEP........................9 74 4.5.1 Inter-AS PCE Peering Policy Controls.........................9 75 4.5.2 Inter-AS PCE Re-interpretation Policies.....................10 76 5. Security Considerations........................................10 77 5.1 Use and Distribution of Keys..................................11 78 5.2 Application of Policy.........................................11 79 5.3 Confidentiality...............................................11 80 5.4 Falsification of Information..................................12 81 6. IANA Considerations............................................12 82 7. Acknowledgments................................................12 83 8. Authors' Addresses.............................................12 84 9. Normative References...........................................13 85 10. Informative References........................................13 87 1. Introduction 89 [RFC4216] defines the scenarios motivating the deployment of inter-AS 90 Multiprotocol Label Switching Traffic Engineering (MPLS TE) and 91 specifies the requirements for inter-AS MPLS TE when the ASes are 92 under the administration of one Service Provider (SP) or the 93 administration of different SPs. 95 Three signaling options are defined for setting up an inter-AS TE 96 LSP: 97 1) contiguous TE LSP as documented in [RFC5151]; 98 2) stitched inter-AS TE LSP discussed in [RFC5150]; 99 3) nested TE LSP as in [RFC4206]. 101 [RFC5152] defines mechanisms for the computation of inter-domain TE 102 Label Switched Paths (LSPs) using network elements along the 103 signaling paths to compute per-domain constrained path segments. The 104 mechanisms in [RFC5152] do not guarantee an optimum constrained path 105 across multiple ASes where an optimum path for an TE LSP is one that 106 has the smallest cost, according to a normalized TE metric (based 107 upon a TE metric or Interior Gateway Protocol (IGP) metric adopted 108 in each transit AS) among all possible paths that satisfy the LSP TE 109 constraints. 111 The Path Computation Element (PCE) [RFC4655] is a component that is 112 capable of computing paths for MPLS TE and Generalized Multiprotcol 113 Label Switching Protocol ((G)MPLS TE) LSPs. The requirements for a 114 PCE have come from SP demands to compute optimum constrained paths 115 across multiple areas and/or domains, and to be able to separate the 116 path computation elements from the forwarding elements. 118 The PCE Communication Protocol (PCEP) is defined to allow 119 communication between Path Computation Clients (PCCs) and PCEs, and 120 between PCEs. The PCEP is used to request (G)MPLS TE paths and to 121 supply computed paths in response. Generic requirements for the 122 PCEP are discussed in [RFC4657]. This document provides a set of 123 PCEP requirements that are specific to inter-AS (G)MPLS TE path 124 computation. 126 2. Terminology 128 This document adopts the definitions and acronyms defined in Section 129 3 of [RFC4216] and Section 2 of [RFC4655]. In addition, we use the 130 following terminology: 132 PCEP: PCE Communication Protocol 134 Inter-AS (G)MPLS TE: MPLS or Generalized MPLS Traffic Engineering 136 Inter-AS (G)MPLS TE path: An MPLS TE or Generalized MPLS (GMPLS) 137 path that traverses two or more ASes. 139 Intra-AS (G)MPLS TE path: An MPLS TE or GMPLS path that is confined 140 to a single AS. It may traverse one or more IGP areas. 142 Intra-AS PCE: A PCE responsible for computing (G)MPLS TE paths 143 remaining within a single AS. 145 Inter-AS PCE: A PCE responsible for computing inter-AS (G)MPLS paths 146 or path segments, possibly by cooperating with intra-AS PCEs. 148 3. Reference Model 150 Figure 1 depicts the reference model for PCEs in an inter-AS 151 application. We refer to two types of PCE functions in this 152 document: inter-AS PCEs and intra-AS PCEs. Inter-AS PCEs perform the 153 procedures needed for inter-AS (G)MPLS TE path computation while 154 intra-AS PCEs perform the functions needed for intra-AS (G)MPLS TE 155 path computation. 157 Let's follow a scenario that illustrates the interaction among PCCs, 158 inter-AS PCEs and intra-AS PCEs as shown Figure 1. R1 in AS1 wants 159 to setup a (G)MPLS TE path, call it LSP1, with certain constraints 160 to R7 in AS3. R1 determines, using mechanisms out of the scope of 161 this document, that R7 is an inter-AS route and that it needs to 162 contact its Inter-AS PCE1 to compute the path. R1, as a PCC, sends a 163 PCEP path computation request to PCE1. PCE1 determines that R7 is 164 reachable via AS2 and that PCE2 is the PCE to ask for path 165 computation across AS2. PCE1 sends a PCEP path computation request 166 to PCE2. Inter-AS PCE2, in turn, sends a PCEP path computation 167 request to Intra-AS PCE R4 to compute a path within AS2 (in certain 168 cases, the same router such as R3 can assume both inter-AS and 169 intra-AS path computation functions). R4 may for instance return a 170 PCEP path computation response to PCE2 with ASBR3 as the entry 171 point to AS2 from AS1 and ASBR7 as the exit point to AS3. PCE2 then 172 sends a PCEP path computation request to PCE3 to compute the path 173 segment across AS3, starting at ASBR7 and terminating at R7. PCE3 174 returns a PCEP path computation response to PCE2 with the path 175 segment ASBR7-R7. PCE2 then return path ASBR3-ASBR5-ASBR7-R7 to PCE1 176 which, in turn, returns path ASBR1-ASBR3-ASBR5-ASBR7-R7 to PCC R1. 178 As described in the above scenario, in general, a PCC may contact an 179 inter-AS PCE to request the computation of an inter-AS path, and 180 that PCE may supply the path itself, or may solicit the services of 181 other PCEs which may, themselves be inter-AS PCEs, or may be intra- 182 AS PCEs with the responsibility for computing path segments within 183 just one AS. 185 This document describes the PCE Communication Protocol requirements 186 for inter-AS path computation. That is, for PCCs to communicate path 187 computation requests for inter-AS (G)MPLS TE path to a PCE, and for 188 the PCE to respond. It also includes the requirements for PCEs to 189 communicate inter-AS path computation requests and responses. 191 Inter-AS Inter-AS Inter-AS 192 PCC <-->PCE1<--------->PCE2<---------------->PCE3 193 :: :: :: :: 194 :: :: :: :: 195 R1----ASBR1====ASBR3---R3---ASBR5====ASBR7---R5---R7 196 | | | | | | 197 | | | | | | 198 R2----ASBR2====ASBR4---R4---ASBR6====ASBR8---R6---R8 199 :: 200 :: 201 Intra-AS 202 PCE 204 <==AS1==> <=====AS2=====> <====AS3====> 206 Figure 1 Inter and Intra-AS PCE Reference Model 208 3.1. Scope of Deployment Model 210 All attempts to predict future deployment scopes within the Internet 211 have proven fruitless. Nevertheless, it may be helpful to provide 212 some discussion of the scope of the inter-AS deployment model as 213 envisioned at the time of writing. 215 It is expected that most, if not all, inter-AS PCEP-based 216 communications will be between PCEs operating in the cooperative PCE 217 model described in [RFC4655]. Clearly, in this model, the requesting 218 PCE acts as a PCC for the purpose of issuing a path computation 219 request, but nevertheless, the requesting node fills the wider role 220 of a PCE in its own AS. It is currently considered unlikely that a 221 PCC (for example, a normal Label Switching Router) will make a path 222 computation request to a PCE outside its own AS. This means that the 223 PCEP relationships between ASes are limited to at most n-squared 224 where n is the number of peering PCEs in the various ASes 225 (considered to be no greater than 100 in [RFC4657]). In practice, 226 however, it is likely that only a few PCEs in one AS will be 227 designated for PCEP communications with a PCE in an adjacent AS, 228 and each of these will only have a few PCEs in the adjacent AS to 229 choose from. A deployment model might place the PCEs as co-resident 230 with the ASBRs, resulting in a manageable scaling of the PCE-PCE 231 relationships. Scaling considerations (Section 4.2), manageability 232 considerations (Section 4.3), and security considerations (Section 233 5) should be examined in the light of these deployment expectations. 235 4. Detailed PCEP Requirements for Inter-AS Computation 237 This section discusses detailed PCEP requirements for inter-AS 238 (G)MPLS TE LSPs. Depending on the deployment environment, some or 239 all of the requirements described here may be utilized. 240 Specifically, some requirements are more applicable to inter- 241 provider inter-AS (G)MPLS TE perations than to intra-provider 242 operations. 244 4.1. PCE Communication Protocol Requirements 246 Requirements specific to inter-AS PCEP path computation requests 247 and responses are discussed in the following sections. 249 4.1.1. Requirements for Path Computation Requests 251 The following are inter-AS specific requirements for PCEP requests 252 for path computation: 254 1. [RFC4657] states the requirement for a priority level to be 255 associated with each path computation request. This document does 256 not change that requirement. However, PCEP should include a 257 mechanism that enables an inter-AS PCE to inform the requesting 258 inter-AS PCE of a change in the request priority level that may 259 have resulted from the application of a local policy. 261 2. A path computation request by an inter-AS PCE or a PCC to another 262 inter-AS PCE MUST be able to specify the sequence of ASes and/or 263 ASBRs across the network by providing ASBRs and/or ASes as hops in 264 the desired path of the TE LSP to the destination. For instance, 265 an inter-AS PCE MUST be able to specify to the inter-AS PCE 266 serving the neighboring AS a preferred ASBR for exiting to that AS 267 and reach the destination. That is, where multiple ASBRs exist, 268 the requester MUST be able to indicate a preference for one of 269 them. The PCE must be able to indicate whether the specified ASBR 270 or AS as mandatory or non-mandatory to be on the (G)MPLS TE path. 272 3. PCEP MUST allow a requester to provide a list of ASes and/or 273 ASBRs to be excluded from the computed path. 275 4. A PCEP path computation request from one inter-AS PCE to another 276 MUST include the AS number of the requesting AS to enable the 277 correct application of local policy at the second inter-AS PCE. 279 5. A path computation request from a PCC to an inter-AS PCE or an 280 inter-AS PCE to another MUST be able to specify the need for 281 protection against node, link, or SRLG failure using 1:1 detours 282 or facility backup. It MUST be possible to request protection 283 across all ASes or across specific ASes. 285 6. PCEP MUST support the disjoint path requirements as specified in 286 [RFC4657]. In addition, it MUST allow the specification of AS- 287 diversity for the computation of a set of two or more paths. 289 7. A PCEP path computation request message MUST be able to identify 290 the scope of diversified path computation to be end-to-end (i.e., 291 between the endpoints of the (G)MPLS TE tunnel) or to be limited 292 to a specific AS. 294 4.1.2. Requirements for Path Computation Responses 296 The following are inter-AS specific requirements for PCEP responses 297 for path computation: 299 1. A PCEP path computation response from one inter-AS PCE to another 300 MUST be able to include both ASBRs and ASes in the computed path 301 while preserving path segment and topology confidentiality. 303 2. A PCEP path computation response from one inter-AS PCE to the 304 requesting inter-AS PCE MUST be able to carry an identifier for a 305 path segment it computes to preserve path segment and topology 306 confidentiality. The objective of the identifier is to be included 307 in the TE LSP signaling, whose mechanism is out of scope of this 308 document, to be used for path expansion during LSP signaling. 310 3. If a constraint for a desired ASBR (see Section 4.1.1, 311 requirement 2) cannot be satisfied by a PCE, PCEP SHOULD allow the 312 PCE to notify the requester of that fact as an error in a path 313 computation response. 315 4. A PCEP path computation from an inter-AS PCE to a requesting 316 inter-AS PCE or a PCC MUST be able to carry a cumulative inter-AS 317 path cost. Path cost normalization across ASes is out of scope of 318 this document. 320 5. A PCEP path computation response from an inter-AS PCE to a PCC 321 SHOULD be able to carry the intra-AS cost of the path segment 322 within the PCC AS. 324 6. A PCEP path computation response MUST be able to identify 325 diversified paths for the same (G)MPLS TE LSP. End-to-end (i.e., 326 between the two endpoints of the (G)MPLS TE tunnel) disjoint paths 327 are paths that do not share nodes, links or SRLGs except for the 328 LSP head-end and tail-end. In cases where diversified path 329 segments are desired within one or more ASes, the disjoint path 330 segments may share only the ASBRs of the first AS and the ASBR of 331 the last AS across these ASes. 333 4.2. Scalability and Performance Considerations 335 PCEP design for use in the inter-AS case SHOULD consider the 336 following criteria: 338 - PCE message processing load. 339 - Scalability as a function of the following parameters: 340 - number of PCCs within the scope of an inter-AS PCE 341 - number of intra-AS PCEs within the scope of an inter-AS PCE 342 - number of peering inter-AS PCEs per inter-AS PCE 343 - Added complexity caused by inter-AS features. 345 4.3. Management Considerations 347 [RFC4657] specifies generic requirements for PCEP management. This 348 document addresses new requirements that apply to inter-AS 349 operations. 351 The PCEP MIB module MUST provide objects to control the behavior of 352 PCEP in inter-AS applications. They include the ASes within the 353 scope of an inter-AS PCE, Inter-AS PCEs in neighboring ASes to which 354 the requesting PCE will or will not communicate, confidentiality and 355 policies. 357 The built-in diagnostic tools MUST enable failure detection and 358 status checking of PCC/PCE-PCE PCEP. Diagnostic tools include 359 statistics collection on the historical behavior of PCEP as 360 specified in [RFC4657], but additionally it MUST be possible to 361 analyze this statistics on a neighboring AS basis (i.e., across the 362 inter-AS PCEs that belong to a neighboring AS). 364 The MIB module MUST support trap functions when thresholds are 365 crossed or when important events occur as stated in [RFC4657]. These 366 thresholds SHOULD be specifiable per neighbor AS as well as per peer 367 inter-AS PCE, and traps should be accordingly generated. 369 Basic liveliness detection for PCC/PCE-PCE PCEP is described in 370 [RFC4657]. The PCEP MIB module SHOULD allow control of liveliness 371 check behavior by providing a liveliness message frequency MIB 372 object and this frequency object SHOULD be specified per inter-AS 373 PCE peer. In addition, there SHOULD be a MIB object that specifies 374 the dead-interval as a multiplier of the liveliness message 375 frequency so that if no liveliness message is received within that 376 time from an inter-AS PCE, the inter-AS PCE is declared unreachable. 378 4.4. Confidentiality 380 Confidentiality mainly applies to inter-provider (inter-AS) PCE 381 communication. It is about protecting the information exchanged 382 between PCEs and about protecting the topology information within an 383 SP's network. Confidentiality rules may also apply among ASes owned 384 by a single SP. Each SP will in most cases designate some PCEs for 385 inter-AS (G)MPLS TE path computation within its own administrative 386 domain and some other PCEs for inter-provider inter-AS (G)MPLS TE 387 path computation. Among the inter-provider-scoped inter-AS PCEs in 388 each SP domain, there may also be a subset of the PCEs specifically 389 enabled for path computation across a specific set of ASes of 390 different peer SPs. 392 PCEP MUST allow an SP to hide from other SPs the set of hops within 393 its own ASes that are traversed by an inter-AS inter-provider TE LSP 394 (c.f., Section 5.2.1 of [RFC4216]). In a multi-SP administrative 395 domain environment, SPs may want to hide their network topologies 396 for security or commercial reasons. Thus, for each inter-AS TE LSP 397 path segment an inter-AS PCE computes, it may return to the 398 requesting inter-AS PCE an inter-AS TE LSP path segment from its own 399 ASes without detailing the explicit intra-AS hops. As stated 400 earlier, PCEP responses SHOULD be able to carry path-segment 401 identifiers that replace the details of that path segment. The 402 potential use of that identifier for path expansion, for instance, 403 during LSP signaling is out of scope of this document. 405 4.5. Policy Controls Affecting Inter-AS PCEP 407 Section 5.2.2 of [RFC4216] discusses the policy control requirements 408 for inter-AS RSVP-TE signaling at the AS boundaries for the 409 enforcement of interconnect agreements, attribute/parameter 410 translation and security hardening. 412 This section discusses those policy control requirements that are 413 similar to what are discussed in section 5.2.2 of [RFC4216] for 414 PCEP. Please note that SPs may still require policy controls during 415 signaling of TE LSPs to enforce their bilateral or multi-lateral 416 agreements at AS boundaries, but signaling is out of scope for this 417 document. 419 4.5.1. Inter-AS PCE Peering Policy Controls 421 An inter-AS PCE sends path computation requests to its neighboring 422 inter-AS PCEs, and an inter-AS PCE that receives such a request 423 enforces policies applicable to the sender of the request. These 424 policies may include rewriting some of the parameters, or rejecting 425 requests based on parameter values. Such policies may be applied for 426 PCEs belonging to different SPs or to PCEs responsible for ASes 427 within a single SP administrative domain. Parameters that might be 428 subject to policy include bandwidth, setup/holding priority, Fast 429 Reroute request, Differentiated Services Traffic Engineering (DS-TE) 430 Class Type (CT), and others as specified in section 5.2.2.1 of 431 [RFC4216]. 433 For path computation requests that are not compliant with locally 434 configured policies, PCEP SHOULD enable a PCE to send an error 435 message to the requesting PCC or PCE indicating that the request has 436 been rejected because a specific parameter did not satisfy the local 437 policy. 439 4.5.2. Inter-AS PCE Re-interpretation Policies 441 Each SP may have different definitions in its use of, for example, 442 DS-TE TE classes. An inter-AS PCE receiving a path computation 443 request needs to interpret the parameters and constraints and adapt 444 them to the local environment. Specifically, a request constructed 445 by a PCC or PCE in one AS may have parameters and constraints that 446 should be interpreted differently or translated by the receiving PCE 447 that is in a different AS. A list of signaling parameters subject 448 to policy re-interpretation at AS borders can be found in section 449 5.2.2.2 of [RFC4216], and the list for path computation request 450 parameters and constraints is the same. In addition, the transit SPs 451 along the inter-AS TE path may be GMPLS transport providers which 452 may require re-interpretation of MPLS specific PCEP path computation 453 request objects to enable path computation over a GMPLS network or 454 vice versa. 456 5. Security Considerations 458 The PCEP is a communications protocol for use between potentially 459 remote entities (PCCs and PCEs) over an IP network. Security 460 concerns arise in order to protect the PCC and PCE, and the 461 information they exchange. [RFC4758] specifies requirements on the 462 PCEP to protect against spoofing, snooping, and DoS attacks. That 463 document is concerned with general protocol requirements applicable 464 to the basic use of the PCEP. This document is specific to the 465 application of the PCE architecture in an inter-AS environment, and 466 so it is appropriate to highlight the security considerations that 467 apply in that environment. 469 Security requirements that exist within a single administrative 470 domain become critical in the multi-AS case when the control of IP 471 traffic and access to the network may leave the authority of a 472 single administration. 474 5.1. Use and Distribution of Keys 476 How the participants in a PCEP session discover each other and the 477 need for the session is out of scope of this document. It may be 478 through configuration or automatic discovery. However, when a PCEP 479 session is established, the PCEP speakers MUST have mechanisms to 480 authenticate each other's identities and validate the data the 481 exchange. They also SHOULD have mechanisms protect the data that 482 they exchange via encryption. Such mechanisms usually require the 483 use of keys, and so the PCEP MUST describe techniques for the 484 exchange and use of security keys. Where inter-AS PCE discovery is 485 used, and PCEP security is required, automated key distribution 486 mechanisms MUST also be used. Since such key exchange must 487 (necessarily) operate over an AS boundary, proper consideration needs 488 to be given to how inter-AS key exchanges may be carried out and how 489 the key exchange, itself, may be secured. Key distribution mechanisms 490 MUST be defined with consideration of [RFC4107]. Where a PCEP 491 session is configured between a pair of inter-AS PCEs, a security key 492 may be manually set for that session. 494 5.2. Application of Policy 496 Policy forms an important part of the operation of PCEs in an 497 inter-AS environment as described in Section 4.5, especially when 498 ASes are administrated by different SPs. A wider discussion of the 499 application of policy to the PCE architecture can be found in 500 [PCE-POLICY]. 502 Policy may also form part of the security model for the PCEP and may 503 be particularly applicable to inter-AS path computation requests. A 504 fundamental element of the application of policy at a PCE is the 505 identity of the requesting PCC/PCE. This makes the use of 506 authentication described in Section 5.1 particularly important. 507 Where policy information is exchanged as part of the computation 508 request and/or response, the policy object is transparent to the 509 PCEP being delivered un-inspected and unmodified to the policy 510 component of a PCE or PCC. Therefore, the policy components are 511 responsible for protecting (for example, encrypting) the policy 512 information and using additional identification and authentication 513 if a higher level of validation is required than is provided by the 514 base protocol elements of the PCEP. 516 5.3. Confidentiality 518 The PCEP MUST provide a mechanism to preserve the confidentiality of 519 path segments computed by a PCE in one AS and provided in a 520 computation response to another AS. 522 Furthermore, a PCE SHOULD be provided with a mechanism to mask its 523 identity such that its presence in the path computation chain in a 524 cooperative PCE model (such as described in [BRPC]) cannot be 525 derived from the computed path. This will help to protect the PCE 526 from targeted attacks. Clearly, such confidentiality does not extend 527 to the PCEP peer (i.e., a PCC or another PCE) that invokes the PCE 528 with a path computation request. 530 5.4. Falsification of Information 532 In the PCE architecture, when PCEs cooperate, one PCE may return a 533 path computation result that is composed of multiple path segments 534 each computed by a different PCE. In the inter-AS case, each PCE may 535 belong to a different administrative domain, and the source PCC might 536 not know about the downstream PCEs, nor fully trust them. Although it 537 is possible and RECOMMENDED to establish a chain of trust between 538 PCEs, this might not always be possible. In this case, it becomes 539 necessary to guard against a PCE changing the information provided by 540 another downstream PCE. Some mechanism MUST be available in the 541 PCEP, and echoed in the corresponding signaling, that allows an AS 542 to verify that the signaled path conforms to the path segment 543 computed by the local PCE and returned on the path computation 544 request. 546 6. IANA Considerations 548 This document makes no requests for IANA action. 550 7. Acknowledgments 552 We would like to thank Adrian Farrel, Jean-Philippe Vasseur, and Jean 553 Louis Le Roux for their useful comments and suggestions. Pasi Eronen 554 and Sandy Murphy provided valuable early Security Directorate 555 reviews. Adrian Farrel re-wrote the Security Considerations section. 557 8. Authors' Addresses 559 Nabil Bitar 560 Verizon 561 117 West Street 562 Waltham, MA 02451 563 Email: nabil.n.bitar@verizon.com 565 Kenji Kumaki 566 KDDI Corporation 567 Garden Air Tower 568 Iidabashi, Chiyoda-ku, 569 Tokyo 102-8460, JAPAN 570 Phone: +81-3-6678-3103 571 Email: ke-kumaki@kddi.com 572 Raymond Zhang 573 BT 574 2160 E. Grand Ave. 575 El Segundo, CA 90245 USA 576 Email: Raymond_zhang@bt.com 578 9. Normative References 580 [RFC4107] Bellovin, S., and Housley, R., "Guidelines for 581 Cryptographic Key Management", BCP 107, RFC 4107, 582 June 2005. 584 [RFC4216] Zhang. R., and Vasseur, JP., "MPLS Inter-AS Traffic 585 Engineering Requirements", RFC 4216, November 2005. 587 [RFC4655] Farrel, A.. Vasseur, JP., and Ash, J., "A Path Computation 588 Element (PCE)-Based Architecture", RFC 4755, August 2006. 590 [RFC4657] Ash, J., Le Roux, JL., et al., "PCE Communication Protocol 591 Generic Requirements", RFC 4657, September 2006. 593 10. Informative References 595 [BRPC] Vasseur, JP., et. al, "A Backward Recursive PCE-based 596 Computation (BRPC) Procedure To Compute Shortest 597 Constrained Inter-domain Traffic Engineering Label Switched 598 paths", draft-ietf-pce-brpc, work in progress. 600 [RFC4206] Kompella, K., and Rekhter, Y., "Label switched Paths(LSP) 601 Hierarchy with Generalized MPLS TE", RFC4206, October 2005. 603 [RFC4758] Mystroem, M., "Cryptographic Token Key Initialization 604 Protocol (CT-KIP) Version 1.0 Revision 1", RFC 4758, 605 November 2006. 607 [RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and Farrel, A., 608 "Label Switched Path Stitching with Generalized MPLS 609 Traffic Engineering (GMPLS TE)", RFC 5150, February 2008. 611 [RFC5151] Farrel, A., Ayyangar, A., and Vasseur, JP., "Inter domain 612 MPLS and GMPLS Traffic Engineering Resource Reservation 613 Protocol-Traffic Engineering (RSVP-TE) extensions", RFC 614 5151, February 2008. 616 [RFC5152] Vasseur, JP., Ayyangar, A., and Zhang, R., "A Per-domain 617 path computation method for Establishing Inter-domain 618 Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 619 5152, February 2008. 621 [PCE-POLICY] Bryskin, I., Berger, L. and Ash, J., "Policy-Enabled 622 Path Computation Framework", draft-ietf-pce-policy-enabled- 623 path-comp, work in progress. 625 Intellectual Property Statement 627 The IETF takes no position regarding the validity or scope of any 628 Intellectual Property Rights or other rights that might be claimed 629 to pertain to the implementation or use of the technology described 630 in this document or the extent to which any license under such 631 rights might or might not be available; nor does it represent that 632 it has made any independent effort to identify any such rights. 633 Information on the procedures with respect to rights in RFC 634 documents can be found in BCP 78 and BCP 79. 636 Copies of IPR disclosures made to the IETF Secretariat and any 637 assurances of licenses to be made available, or the result of an 638 attempt made to obtain a general license or permission for the use 639 of such proprietary rights by implementers or users of this 640 specification can be obtained from the IETF on-line IPR repository 641 at http://www.ietf.org/ipr. 643 The IETF invites any interested party to bring to its attention any 644 copyrights, patents or patent applications, or other proprietary 645 rights that may cover technology that may be required to implement 646 this standard. Please address the information to the IETF at ietf- 647 ipr@ietf.org. 649 Disclaimer of Validity 651 This document and the information contained herein are provided 652 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 653 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 654 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 655 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 656 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 657 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 658 FOR A PARTICULAR PURPOSE. 660 Copyright Statement 662 Copyright (C) The IETF Trust (2008). This document is subject 663 to the rights, licenses and restrictions contained in BCP 78, and 664 except as set forth therein, the authors retain all their rights.