draft-ietf-ccamp-path-key-ero-03.txt   draft-ietf-ccamp-path-key-ero-04.txt 
Networking Working Group A. Farrel (Ed.) Networking Working Group A. Farrel (Ed.)
Internet-Draft Old Dog Consulting Internet-Draft Old Dog Consulting
Intended Status: Standards Track R. Bradford Intended Status: Standards Track R. Bradford
Created: January 8, 2009 JP. Vasseur Created: March 7, 2009 JP. Vasseur
Expires: July 8, 2009 Cisco Systems, Inc. Expires: September 7, 2009 Cisco Systems, Inc.
RSVP Extensions for Path Key Support 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 Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79. the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other and may be updated, replaced, or obsoleted by other documents at any
documents at any time. It is inappropriate to use Internet-Drafts time. It is inappropriate to use Internet-Drafts as reference
as reference material or to cite them other than as "work in material or to cite them other than as "work in progress."
progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
The paths taken by Multiprotocol Label Switching (MPLS) and The paths taken by Multiprotocol Label Switching (MPLS) and
skipping to change at page 2, line 30 skipping to change at page 2, line 30
Traffic Engineering (TE) Label Switched Paths (LSPs) are signaled Traffic Engineering (TE) Label Switched Paths (LSPs) are signaled
using the TE extensions to the Resource Reservation Protocol using the TE extensions to the Resource Reservation Protocol
(RSVP-TE) [RFC3209], [RFC3473]. The routes followed by MPLS and (RSVP-TE) [RFC3209], [RFC3473]. The routes followed by MPLS and
GMPLS TE LSPs may be computed by Path Computation Elements (PCEs) GMPLS TE LSPs may be computed by Path Computation Elements (PCEs)
[RFC4655]. [RFC4655].
Where the TE LSP crosses multiple domains [RFC4726], such as Where the TE LSP crosses multiple domains [RFC4726], such as
Autonomous Systems (ASes), the path may be computed by multiple PCEs Autonomous Systems (ASes), the path may be computed by multiple PCEs
that cooperate, with each responsible for computing a segment of the that cooperate, with each responsible for computing a segment of the
path. To preserve confidentiality of topology with each AS, 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 hide the contents of a segment of a path, called the Confidential
Path Segment (CPS), by encoding the contents as a Path Key Path Segment (CPS), by encoding the contents as a Path Key
Subobject (PKS) [PCE-PKS]. Subobject (PKS) [PCE-PKS].
This document defines RSVP-TE protocol extensions necessary to This document defines RSVP-TE protocol extensions necessary to
support the use of Path Key Subobjects in MPLS and GMPLS signaling by support the use of Path Key Subobjects in MPLS and GMPLS signaling by
including them in Explicit Route Objects (EROs) and Record Route including them in Explicit Route Objects (EROs) and Record Route
Object (RROs) so as to facilitate confidentiality in the signaling of Object (RROs) so as to facilitate confidentiality in the signaling of
inter-domain TE LSPs. inter-domain TE LSPs.
skipping to change at page 6, line 32 skipping to change at page 6, line 32
- If an LSR strips all local sub-objects from an ERO carried in a - If an LSR strips all local sub-objects from an ERO carried in a
Path message (according to the procedures in [RFC3209]) and finds Path message (according to the procedures in [RFC3209]) and finds
that the next subobject is a PKS it MUST attempt to resolve the PKS that the next subobject is a PKS it MUST attempt to resolve the PKS
to a CPS. to a CPS.
Resolution of the PKS MAY take any of the following forms or use Resolution of the PKS MAY take any of the following forms or use
some other technique subject to local policy and network some other technique subject to local policy and network
implementation. implementation.
- The LSR can use the PCE-ID contained in the PKS to contact the - 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. expanded.
- The LSR can contact any PCE using PCEP [PCEP] to request that the - The LSR can contact any PCE using PCEP [RFC5440] to request that
PKS be expanded relying on cooperation between the PCEs. the PKS be expanded relying on cooperation between the PCEs.
- The LSR can use the information in the PKS to index a CPS - The LSR can use the information in the PKS to index a CPS
previously supplied to it by the PCE that originated the PKS. previously supplied to it by the PCE that originated the PKS.
If a CPS is derived, the path fragment SHOULD be inserted into the 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 ERO of the Path message as a direct replacement for the PKS. Other
processing of the CPS and ERO are permitted as described in processing of the CPS and ERO are permitted as described in
[RFC3209]. [RFC3209].
This processing can give rise to the following error cases: This processing can give rise to the following error cases:
skipping to change at page 8, line 14 skipping to change at page 8, line 14
segment. In the latter case, the Path Key and its expansion SHOULD be 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 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 lifetime of the LSP. In both cases, the expansion of the PKS SHOULD
be made available to diagnostic tools under the control of local be made available to diagnostic tools under the control of local
policy. policy.
4. Security Considerations 4. Security Considerations
The protocol interactions required by the mechanisms described in The protocol interactions required by the mechanisms described in
this document are point to point and can be authenticated and made 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 interactions for PCEP are listed in [PCE-PKS], while general
considerations for securing RSVP-TE in MPLS-TE and GMPLS networks can considerations for securing RSVP-TE in MPLS-TE and GMPLS networks can
be found in [MPLS-SEC]. be found in [MPLS-SEC].
Thus, the security issues can be dealt with using standard techniques Thus, the security issues can be dealt with using standard techniques
for securing and authenticating point-to-point communications. In for securing and authenticating point-to-point communications. In
addition, it is RECOMMENDED that the PCE providing a PKS expansion addition, it is RECOMMENDED that the PCE providing a PKS expansion
checks that the LSR that issued the request for PKS expansion is the checks that the LSR that issued the request for PKS expansion is the
head end of the resulting CPS. head end of the resulting CPS.
skipping to change at page 9, line 14 skipping to change at page 9, line 14
MAY simply use the error code/value "Policy Control Failure"/ MAY simply use the error code/value "Policy Control Failure"/
"Inter-domain policy failure" in all cases. "Inter-domain policy failure" in all cases.
- Authenticity of the path key. A concern is that the path key in the - 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 PKS will be altered or faked leading to erroneous path key
expansion and the use of the wrong CPS. The consequence would be a 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 bad ERO in a Path message causing the LSP to be set up incorrectly
resulting in incorrect network resource usage, diversion of traffic resulting in incorrect network resource usage, diversion of traffic
to where it can be intercepted, or failure to set up the LSP. These to where it can be intercepted, or failure to set up the LSP. These
problems can be prevented by protecting the protocol exchanges in 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] path key expansion requests - this issue is addressed in [PCE-PKS]
and is out of scope for this document. A further attack might and is out of scope for this document. A further attack might
consist of sending a flood of RSVP-TE Path messages with consist of sending a flood of RSVP-TE Path messages with
deliberately spurious PKSs. This attack is prevented by ensuring deliberately spurious PKSs. This attack is prevented by ensuring
the integrity of the Path messages using standard RSVP-TE security the integrity of the Path messages using standard RSVP-TE security
mechanisms, and by enforcing the RSVP-TE chain of trust security mechanisms, and by enforcing the RSVP-TE chain of trust security
model. model.
5. Manageability Considerations 5. Manageability Considerations
skipping to change at page 12, line 28 skipping to change at page 12, line 28
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. 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. RFC3473, January 2003.
7.2. Informational References 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 [RFC4655] Farrel, A., Vasseur, J.P., and Ash, J., "Path Computation
Element (PCE) Architecture", RFC 4655, August 2006. Element (PCE) Architecture", RFC 4655, August 2006.
[RFC4726] Farrel, A., Vasseur, J.P., and Ayyangar, A., "A Framework [RFC4726] Farrel, A., Vasseur, J.P., and Ayyangar, A., "A Framework
for Inter-Domain Multiprotocol Label Switching Traffic for Inter-Domain Multiprotocol Label Switching Traffic
Engineering", RFC 4726, November 2006. Engineering", RFC 4726, November 2006.
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L. and Ash, J., [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L. and Ash, J.,
"Policy-Enabled Path Computation Framework", RFC 5394, "Policy-Enabled Path Computation Framework", RFC 5394,
December 2008. 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: 8. Authors' Addresses:
Adrian Farrel Adrian Farrel
Old Dog Consulting Old Dog Consulting
EMail: adrian@olddog.co.uk EMail: adrian@olddog.co.uk
Rich Bradford Rich Bradford
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Avenue 1414 Massachusetts Avenue
Boxborough, MA - 01719 Boxborough, MA - 01719
USA USA
Email: rbradfor@cisco.com Email: rbradfor@cisco.com
J.-P Vasseur Jean-Philippe Vasseur
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Avenue 1414 Massachusetts Avenue
Boxborough, MA - 01719 Boxborough, MA - 01719
USA USA
Email: jpv@cisco.com 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 Intellectual Property
The IETF Trust takes no position regarding the validity or scope of The IETF Trust takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might be any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the technology claimed to pertain to the implementation or use of the technology
described in any IETF Document or the extent to which any license described in any IETF Document or the extent to which any license
under such rights might or might not be available; nor does it under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any represent that it has made any independent effort to identify any
such rights. such rights.
skipping to change at line 655 skipping to change at page 14, line 20
considered to be definitive versions of these Legal Provisions. considered to be definitive versions of these Legal Provisions.
For the avoidance of doubt, each Contributor to the IETF Standards For the avoidance of doubt, each Contributor to the IETF Standards
Process licenses each Contribution that he or she makes as part of Process licenses each Contribution that he or she makes as part of
the IETF Standards Process to the IETF Trust pursuant to the the IETF Standards Process to the IETF Trust pursuant to the
provisions of RFC 5378. No language to the contrary, or terms, provisions of RFC 5378. No language to the contrary, or terms,
conditions or rights that differ from or are inconsistent with the conditions or rights that differ from or are inconsistent with the
rights and licenses granted under RFC 5378, shall have any effect and rights and licenses granted under RFC 5378, shall have any effect and
shall be null and void, whether published or posted by such shall be null and void, whether published or posted by such
Contributor, or included with or in such Contribution. 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.
 End of changes. 15 change blocks. 
51 lines changed or deleted 29 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/