--- 1/draft-ietf-ccamp-path-key-ero-03.txt 2009-03-07 12:12:03.000000000 +0100 +++ 2/draft-ietf-ccamp-path-key-ero-04.txt 2009-03-07 12:12:03.000000000 +0100 @@ -1,36 +1,35 @@ Networking Working Group A. Farrel (Ed.) Internet-Draft Old Dog Consulting Intended Status: Standards Track R. Bradford -Created: January 8, 2009 JP. Vasseur -Expires: July 8, 2009 Cisco Systems, Inc. +Created: March 7, 2009 JP. Vasseur +Expires: September 7, 2009 Cisco Systems, Inc. RSVP Extensions for Path Key Support - draft-ietf-ccamp-path-key-ero-03.txt + draft-ietf-ccamp-path-key-ero-04.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. - Internet-Drafts are draft documents valid for a maximum of six - months and may be updated, replaced, or obsoleted by other - documents at any time. It is inappropriate to use Internet-Drafts - as reference material or to cite them other than as "work in - progress." + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The paths taken by Multiprotocol Label Switching (MPLS) and @@ -65,21 +64,21 @@ Traffic Engineering (TE) Label Switched Paths (LSPs) are signaled using the TE extensions to the Resource Reservation Protocol (RSVP-TE) [RFC3209], [RFC3473]. The routes followed by MPLS and GMPLS TE LSPs may be computed by Path Computation Elements (PCEs) [RFC4655]. Where the TE LSP crosses multiple domains [RFC4726], such as Autonomous Systems (ASes), the path may be computed by multiple PCEs that cooperate, with each responsible for computing a segment of the path. To preserve confidentiality of topology with each AS, the - PCE Communications Protocol (PCEP) [PCEP] supports a mechanism to + PCE Communications Protocol (PCEP) [RFC5440] supports a mechanism to hide the contents of a segment of a path, called the Confidential Path Segment (CPS), by encoding the contents as a Path Key Subobject (PKS) [PCE-PKS]. This document defines RSVP-TE protocol extensions necessary to support the use of Path Key Subobjects in MPLS and GMPLS signaling by including them in Explicit Route Objects (EROs) and Record Route Object (RROs) so as to facilitate confidentiality in the signaling of inter-domain TE LSPs. @@ -255,25 +254,25 @@ - If an LSR strips all local sub-objects from an ERO carried in a Path message (according to the procedures in [RFC3209]) and finds that the next subobject is a PKS it MUST attempt to resolve the PKS to a CPS. Resolution of the PKS MAY take any of the following forms or use some other technique subject to local policy and network implementation. - The LSR can use the PCE-ID contained in the PKS to contact the - identified PCE using PCEP [PCEP] and request that the PKS be + identified PCE using PCEP [RFC5440] and request that the PKS be expanded. - - The LSR can contact any PCE using PCEP [PCEP] to request that the - PKS be expanded relying on cooperation between the PCEs. + - The LSR can contact any PCE using PCEP [RFC5440] to request that + the PKS be expanded relying on cooperation between the PCEs. - The LSR can use the information in the PKS to index a CPS previously supplied to it by the PCE that originated the PKS. If a CPS is derived, the path fragment SHOULD be inserted into the ERO of the Path message as a direct replacement for the PKS. Other processing of the CPS and ERO are permitted as described in [RFC3209]. This processing can give rise to the following error cases: @@ -335,21 +334,21 @@ segment. In the latter case, the Path Key and its expansion SHOULD be retained by the LSR that performs the substitution for at least the lifetime of the LSP. In both cases, the expansion of the PKS SHOULD be made available to diagnostic tools under the control of local policy. 4. Security Considerations The protocol interactions required by the mechanisms described in this document are point to point and can be authenticated and made - secure as described in [PCEP] and [RFC3209]. The protocol + secure as described in [RFC5440] and [RFC3209]. The protocol interactions for PCEP are listed in [PCE-PKS], while general considerations for securing RSVP-TE in MPLS-TE and GMPLS networks can be found in [MPLS-SEC]. Thus, the security issues can be dealt with using standard techniques for securing and authenticating point-to-point communications. In addition, it is RECOMMENDED that the PCE providing a PKS expansion checks that the LSR that issued the request for PKS expansion is the head end of the resulting CPS. @@ -383,23 +382,24 @@ MAY simply use the error code/value "Policy Control Failure"/ "Inter-domain policy failure" in all cases. - Authenticity of the path key. A concern is that the path key in the PKS will be altered or faked leading to erroneous path key expansion and the use of the wrong CPS. The consequence would be a bad ERO in a Path message causing the LSP to be set up incorrectly resulting in incorrect network resource usage, diversion of traffic to where it can be intercepted, or failure to set up the LSP. These problems can be prevented by protecting the protocol exchanges in - PCEP and RSVP-TE using standard security techniques. + PCEP and RSVP-TE using the security techniques described in + [RFC5440], [RFC3209], and [MPLS-SEC]. - - Resilience to DNS attacks. A PCE can be attacked through a flood of + - Resilience to DoS attacks. A PCE can be attacked through a flood of path key expansion requests - this issue is addressed in [PCE-PKS] and is out of scope for this document. A further attack might consist of sending a flood of RSVP-TE Path messages with deliberately spurious PKSs. This attack is prevented by ensuring the integrity of the Path messages using standard RSVP-TE security mechanisms, and by enforcing the RSVP-TE chain of trust security model. 5. Manageability Considerations @@ -534,90 +534,68 @@ 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. - [RFC3473] Berger, L., et al. "GMPLS Singlaling RSVP-TE extensions", + [RFC3473] Berger, L., et al. "GMPLS Singaling RSVP-TE extensions", RFC3473, January 2003. 7.2. Informational References - [MPLS-SEC] Fang, L., et al., "Security Framework for MPLS and GMPLS - Networks", draft-ietf-mpls-mpls-and-gmpls-security- - framework, work in progress. - - [PCEP] J.P. Vasseur, et al., "Path Computation Element (PCE) - Communication Protocol (PCEP)", draft-ietf-pce-pcep, work - in progress. - - [PCE-PKS] Bradford, R., Vasseur, J.P., and Farrel, A., "Preserving - Topology Confidentiality in Inter-Domain Path Computation - Using a Key-Based Mechanism", draft-ietf-pce-path-key, - work in progress. - [RFC4655] Farrel, A., Vasseur, J.P., and Ash, J., "Path Computation Element (PCE) Architecture", RFC 4655, August 2006. [RFC4726] Farrel, A., Vasseur, J.P., and Ayyangar, A., "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, November 2006. [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L. and Ash, J., "Policy-Enabled Path Computation Framework", RFC 5394, December 2008. + [RFC5440] J.P. Vasseur, et al., "Path Computation Element (PCE) + Communication Protocol (PCEP)", RFC 5440, March 2009. + + [MPLS-SEC] Fang, L., et al., "Security Framework for MPLS and GMPLS + Networks", draft-ietf-mpls-mpls-and-gmpls-security- + framework, work in progress. + + [PCE-PKS] Bradford, R., Vasseur, J.P., and Farrel, A., "Preserving + Topology Confidentiality in Inter-Domain Path Computation + Using a Key-Based Mechanism", draft-ietf-pce-path-key, + work in progress. + 8. Authors' Addresses: Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk Rich Bradford Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA - 01719 USA Email: rbradfor@cisco.com - J.-P Vasseur + Jean-Philippe Vasseur Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA - 01719 USA Email: jpv@cisco.com -Full Copyright Statement - - Copyright (c) 2009 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with respect - to this document. - - All IETF Documents and the information contained therein are provided - on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE - REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE - IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL - WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY - WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE - ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS - FOR A PARTICULAR PURPOSE. - Intellectual Property The IETF Trust takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in any IETF Document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. @@ -645,10 +623,44 @@ considered to be definitive versions of these Legal Provisions. For the avoidance of doubt, each Contributor to the IETF Standards Process licenses each Contribution that he or she makes as part of the IETF Standards Process to the IETF Trust pursuant to the provisions of RFC 5378. No language to the contrary, or terms, conditions or rights that differ from or are inconsistent with the rights and licenses granted under RFC 5378, shall have any effect and shall be null and void, whether published or posted by such Contributor, or included with or in such Contribution. + +Disclaimer of Validity + + All IETF Documents and the information contained therein are provided + on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE + REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE + IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL + WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY + WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE + ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS + FOR A PARTICULAR PURPOSE. + +Full Copyright Statement + + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents in effect on the date of + publication of this document (http://trustee.ietf.org/license-info). + Please review these documents carefully, as they describe your + rights and restrictions with respect to this document. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) + controlling the copyright in such materials, this document may not + be modified outside the IETF Standards Process, and derivative + works of it may not be created outside the IETF Standards Process, + except to format it for publication as an RFC or to translate it + into languages other than English.