draft-ietf-pce-path-key-03.txt   draft-ietf-pce-path-key-04.txt 
Networking Working Group Rich Bradford (Ed) Networking Working Group Rich Bradford (Ed)
Internet-Draft JP Vasseur Internet-Draft JP Vasseur
Intended Status: Standards Track Cisco Systems, Inc. Intended Status: Standards Track Cisco Systems, Inc.
Created: May 12, 2008 Adrian Farrel Created: November 17, 2008 Adrian Farrel
Expires: November 12, 2008 Old Dog Consulting Expires: May 17, 2009 Old Dog Consulting
Preserving Topology Confidentiality in Inter-Domain Path Preserving Topology Confidentiality in Inter-Domain Path
Computation Using a Key-Based Mechanism Computation Using a Key-Based Mechanism
draft-ietf-pce-path-key-03.txt draft-ietf-pce-path-key-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with
applicable patent or other IPR claims of which he or she is aware the provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
skipping to change at page 4, line 10 skipping to change at page 4, line 10
explicit route it is resolved by performing a secondary path explicit route it is resolved by performing a secondary path
computation to reach the resource or set of resources identified computation to reach the resource or set of resources identified
by the loose hop. Given the nature of the cooperation between PCEs by the loose hop. Given the nature of the cooperation between PCEs
in computing the original path, this secondary computation occurs in computing the original path, this secondary computation occurs
at or on behalf of a Label Switching Router (LSR) at a domain at or on behalf of a Label Switching Router (LSR) at a domain
boundary (i.e., an Area Border Router (ABR) or an AS Border Router boundary (i.e., an Area Border Router (ABR) or an AS Border Router
(ASBR)) and the path is expanded as described in [RFC5152]. (ASBR)) and the path is expanded as described in [RFC5152].
The PCE-based computation model is particularly useful for The PCE-based computation model is particularly useful for
determining mutually disjoint inter-domain paths such as might be determining mutually disjoint inter-domain paths such as might be
required for service protection [INTER-DOM-REC]. A single path required for service protection [RFC5298]. A single path computation
computation request is used. However, if loose hops are returned, request is used. However, if loose hops are returned, the path of
the path of each TE LSP must be recomputed at the domain each TE LSP must be recomputed at the domain boundaries as the TE
boundaries as the TE LSPs are signaled, and since the TE LSP LSPs are signaled, and since the TE LSP signaling proceeds
signaling proceeds independently for each TE LSP, disjoint paths independently for each TE LSP, disjoint paths cannot be guaranteed
cannot be guaranteed since the LSRs in charge of expanding the since the LSRs in charge of expanding the EROs are not synchronized.
EROs are not synchronized. Therefore, if the loose hop technique Therefore, if the loose hop technique is used without further
is used without further extensions, path segment confidentiality extensions, path segment confidentiality and path diversity are
and path diversity are mutually incompatible requirements. mutually incompatible requirements.
This document defines the notion of a Path Key that is a token This document defines the notion of a Path Key that is a token
that replaces a path segment in an explicit route. The Path Key is that replaces a path segment in an explicit route. The Path Key is
encoded as a Path Key Subobject (PKS) returned in the PCEP Path encoded as a Path Key Subobject (PKS) returned in the PCEP Path
Computation Reply message (PCRep) ([PCEP]). Upon receiving the Computation Reply message (PCRep) ([PCEP]). Upon receiving the
computed path, the PKS will be carried in an RSVP-TE Path message computed path, the PKS will be carried in an RSVP-TE Path message
(RSVP-TE [RFC3209] and [RSVP-PKS]) during signaling. (RSVP-TE [RFC3209] and [RSVP-PKS]) during signaling.
1.1. Terminology 1.1. Terminology
skipping to change at page 6, line 9 skipping to change at page 6, line 9
version number in the path-key. version number in the path-key.
A head-end LSR that is a PCC converts the path returned by a PCE A head-end LSR that is a PCC converts the path returned by a PCE
into an explicit route object (ERO) that it includes in the into an explicit route object (ERO) that it includes in the
Resource Reservation Protocol (RSVP) Path message. If the path Resource Reservation Protocol (RSVP) Path message. If the path
returned by the PCE contains a PKS, this is included in the ERO. returned by the PCE contains a PKS, this is included in the ERO.
Like any other subobjects, the PKS is passed transparently from Like any other subobjects, the PKS is passed transparently from
hop to hop, until it becomes the first subobject in the ERO. This hop to hop, until it becomes the first subobject in the ERO. This
will occur at the start of the CPS which will usually be the will occur at the start of the CPS which will usually be the
domain boundary. The PKS MUST be preceded by an ERO subobject that domain boundary. The PKS MUST be preceded by an ERO subobject that
identifies the LSR that must expand the PKS, so the PKS will not identifies the LSR that must expand the PKS. This means that
be encountered in ERO processing until the LSR that can process (following the rules for ERO processing set out in [RFC3209])
it. the PKS will not be encountered in ERO processing until the ERO is
being processed by the LSR that is capable of correctly handling the
PKS.
An LSR that encounters a PKS when trying to identify the next-hop An LSR that encounters a PKS when trying to identify the next-hop
retrieves the PCE-ID from the PKS and sends a Path Computation retrieves the PCE-ID from the PKS and sends a Path Computation
Request (PCReq) message as defined in [PCEP] to the PCE identified Request (PCReq) message as defined in [PCEP] to the PCE identified
by the PCE-ID that contains the path-key object . by the PCE-ID that contains the path-key object .
Upon receiving the PCReq message, the PCE identifies the computed Upon receiving the PCReq message, the PCE identifies the computed
path segment using the supplied path-key, and returns the path segment using the supplied path-key, and returns the
previously computed path segment in the form of explicit hops previously computed path segment in the form of explicit hops
using an ERO object contained in the Path Computation Reply using an ERO object contained in the Path Computation Reply
skipping to change at page 11, line 33 skipping to change at page 11, line 33
<path-key-expansion> ::= <PATH-KEY> <path-key-expansion> ::= <PATH-KEY>
Thus, the format of the message for use in normal path computation Thus, the format of the message for use in normal path computation
is unmodified. is unmodified.
4. PCEP Mode of Operation for Path Key Expansion 4. PCEP Mode of Operation for Path Key Expansion
The retrieval of the explicit path (the CPS) associated with a PKS The retrieval of the explicit path (the CPS) associated with a PKS
by a PCC is no different than any other path computation request by a PCC is no different than any other path computation request
with the exception that the PCReq message MUST contain a PATH_KEY with the exception that the PCReq message MUST contain a PATH_KEY
object and the Path Key bit of the RP object MUST the set. object and the Path Key bit of the RP object MUST the set. On
receipt of a PCRep containing a CPS, the requesting PCC SHOULD
use insert the CPS into the ERO that it will signal, in accordance
with local policy.
If the receiving PCE does not recognize itself as identified by the If the receiving PCE does not recognize itself as identified by the
PCE ID carried in the PKS it MAY forward the PCReq message to PCE ID carried in the PKS it MAY forward the PCReq message to
another PCE according to local policy. If the PCE does not forward another PCE according to local policy. If the PCE does not forward
such a PCReq, it MUST respond with a PCRep message containing a NO- such a PCReq, it MUST respond with a PCRep message containing a NO-
PATH object. PATH object.
If the receiving PCE recognizes itself, but cannot find the If the receiving PCE recognizes itself, but cannot find the
related CPS, or if the retrieval of the CPS is not allowed by related CPS, or if the retrieval of the CPS is not allowed by
policy, the PCE MUST send a PCRep message that contains a NO-PATH policy, the PCE MUST send a PCRep message that contains a NO-PATH
skipping to change at page 12, line 19 skipping to change at page 12, line 19
security considerations that apply to PCEP and RSVP-TE. security considerations that apply to PCEP and RSVP-TE.
Issues include: Issues include:
- Confidentiality of the CPS (can other network elements probe for - Confidentiality of the CPS (can other network elements probe for
expansion of path-keys, possibly at random?). expansion of path-keys, possibly at random?).
- Authenticity of the path-key (resilience to alteration by - Authenticity of the path-key (resilience to alteration by
intermediaries, resilience to fake expansion of path-keys). intermediaries, resilience to fake expansion of path-keys).
- Resilience from DNS attacks (insertion of spurious path-keys; - Resilience from DoS attacks (insertion of spurious path-keys;
flooding of bogus path-key expansion requests). flooding of bogus path-key expansion requests).
Most of the interactions required by this extension are point to Most of the interactions required by this extension are point to
point, can be authenticated and made secure as described in [PCEP] point, can be authenticated and made secure as described in [PCEP]
and [RFC3209]. These interactions include the: and [RFC3209]. These interactions include the:
- PCC->PCE request - PCC->PCE request
- PCE->PCE request(s) - PCE->PCE request(s)
- PCE->PCE response(s) - PCE->PCE response(s)
- PCE->PCC response - PCE->PCC response
skipping to change at page 13, line 23 skipping to change at page 13, line 23
replaced and under what circumstances. For example, an operator replaced and under what circumstances. For example, an operator
might set a policy that states that every path segment for the might set a policy that states that every path segment for the
operator's domain will be replaced by a PKS when the PCReq has operator's domain will be replaced by a PKS when the PCReq has
been issued from outside the domain. been issued from outside the domain.
The operation of the PKS extensions require that path-keys are The operation of the PKS extensions require that path-keys are
retained by the issuing PCE to be available for retrieval by an retained by the issuing PCE to be available for retrieval by an
LSR (acting as a PCC) at a later date. But it is possible that the LSR (acting as a PCC) at a later date. But it is possible that the
retrieval request will never be made, so good housekeeping retrieval request will never be made, so good housekeeping
requires that a timer is run to discard unwanted path-keys. A requires that a timer is run to discard unwanted path-keys. A
default value for this timer is suggested in the body of this default value for this timer is suggested in Section 2.1.
document. Implementations SHOULD provide the ability for this Implementations SHOULD provide the ability for this value to be over-
value to be over-ridden through operator configuration or policy. ridden through operator configuration or policy.
After a PKS has been expanded in response to a retrieval request, After a PKS has been expanded in response to a retrieval request,
it may be valuable to retain the path-key and CPS for debug it may be valuable to retain the path-key and CPS for debug
purposes. Such retention SHOULD NOT be the default behavior of an purposes. Such retention SHOULD NOT be the default behavior of an
implementation, but MAY be available in response to operator implementation, but MAY be available in response to operator request.
request.
Once a path-key has been discarded, the path-key value SHOULD not Once a path-key has been discarded, the path-key value SHOULD NOT
be immediately available for re-use for a new CPS since this might be immediately available for re-use for a new CPS since this might
lead to accidental misuse. A default timer value is suggested in lead to accidental misuse. A default timer value is suggested in
the body of this document. Implementations SHOULD provide the Section 2.1. Implementations SHOULD provide the ability for this
ability for this value to be over-ridden through operator value to be over-ridden through operator configuration or policy.
configuration or policy.
A PCE must set a PCE-ID value in each PKS it creates so that PCCs A PCE must set a PCE-ID value in each PKS it creates so that PCCs
can correctly identify it and send PCReq messages to expand the can correctly identify it and send PCReq messages to expand the
PKS to a path segment. A PCE implementation SHOULD allow operator PKS to a path segment. A PCE implementation SHOULD allow operator
or policy control of the value to use as the PCE-ID. If the PCE or policy control of the value to use as the PCE-ID. If the PCE
allows PCE-ID values that are not routable addresses to be used, allows PCE-ID values that are not routable addresses to be used,
the PCCs MUST be configurable (by the operator or through policy) the PCCs MUST be configurable (by the operator or through policy)
to allow them to map from the PCE-ID to a routable address of the to allow them to map from the PCE-ID to a routable address of the
PCE. Such mapping may be algorithmic, procedural (for example, PCE. Such mapping may be algorithmic, procedural (for example,
mapping a PCE-ID equal to the IGP Router ID into a routable mapping a PCE-ID equal to the IGP Router ID into a routable
skipping to change at page 17, line 44 skipping to change at page 17, line 44
domain Traffic Engineering Label Switched Path", draft- domain Traffic Engineering Label Switched Path", draft-
ietf-pce-brpc, work in progress. ietf-pce-brpc, work in progress.
[RFC4105] Le Roux, J., Vasseur, JP, Boyle, J., "Requirements for [RFC4105] Le Roux, J., Vasseur, JP, Boyle, J., "Requirements for
Support of Inter-Area and Inter-AS MPLS Traffic Support of Inter-Area and Inter-AS MPLS Traffic
Engineering", RFC 4105, June 2005. Engineering", RFC 4105, June 2005.
[RFC4216] Zhang, R., Vasseur, JP., et. al., "MPLS Inter-AS Traffic [RFC4216] Zhang, R., Vasseur, JP., et. al., "MPLS Inter-AS Traffic
Engineering requirements", RFC 4216, November 2005. Engineering requirements", RFC 4216, November 2005.
[INTER-DOM-REC] Takeda, T., et al, "Analysis of Inter-domain Label [RFC5298] Takeda, T., et al, "Analysis of Inter-domain Label
Switched Path (LSP) Recovery", draft-ietf-ccamp-inter- Switched Path (LSP) Recovery", RFC 5298, August 2008.
domain-recovery-analysis, work in progress.
[PCEP-MIB] Kiran Koushik, A., and Stephan, E., "PCE communication [PCEP-MIB] Kiran Koushik, A., and Stephan, E., "PCE communication
protocol (PCEP) Management Information Base", draft- protocol (PCEP) Management Information Base", draft-
kkoushik-pce-pcep-mib, work in progress. kkoushik-pce-pcep-mib, work in progress.
10. Acknowledgements 10. Acknowledgements
The authors would like to thank Eiji Oki for his comments on this The authors would like to thank Eiji Oki for his comments on this
document. document.
skipping to change at page 18, line 32 skipping to change at page 18, line 32
Boxborough, MA - 01719 Boxborough, MA - 01719
USA USA
EMail: jpv@cisco.com EMail: jpv@cisco.com
Adrian Farrel Adrian Farrel
Old Dog Consulting Old Dog Consulting
EMail: adrian@olddog.co.uk EMail: adrian@olddog.co.uk
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (c) 2008 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to the rights, licenses and restrictions This document is subject to BCP 78 and the IETF Trust's Legal
contained in BCP 78, and except as set forth therein, the authors Provisions Relating to IETF Documents
retain all their rights. (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.
This document and the information contained herein are provided on an All IETF Documents and the information contained therein are provided
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF Trust takes no position regarding the validity or scope of
Intellectual Property Rights or other rights that might be claimed to any Intellectual Property Rights or other rights that might be
pertain to the implementation or use of the technology described in claimed to pertain to the implementation or use of the technology
this document or the extent to which any license under such rights described in any IETF Document or the extent to which any license
might or might not be available; nor does it represent that it has under such rights might or might not be available; nor does it
made any independent effort to identify any such rights. Information represent that it has made any independent effort to identify any
on the procedures with respect to rights in RFC documents can be such rights.
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of Intellectual Property disclosures made to the IETF
assurances of licenses to be made available, or the result of an Secretariat and any assurances of licenses to be made available, or
attempt made to obtain a general license or permission for the use of the result of an attempt made to obtain a general license or
such proprietary rights by implementers or users of this permission for the use of such proprietary rights by implementers or
specification can be obtained from the IETF on-line IPR repository at users of this specification can be obtained from the IETF on-line IPR
http://www.ietf.org/ipr. repository at http://www.ietf.org/ipr
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at any standard or specification contained in an IETF Document. Please
ietf-ipr@ietf.org. address the information to the IETF at ietf-ipr@ietf.org.
The definitive version of an IETF Document is that published by, or
under the auspices of, the IETF. Versions of IETF Documents that are
published by third parties, including those that are translated into
other languages, should not be considered to be definitive versions
of IETF Documents. The definitive version of these Legal Provisions
is that published by, or under the auspices of, the IETF. Versions of
these Legal Provisions that are published by third parties, including
those that are translated into other languages, should not be
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.
 End of changes. 18 change blocks. 
58 lines changed or deleted 62 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/