--- 1/draft-ietf-ccamp-path-key-ero-02.txt 2009-01-08 02:12:04.000000000 +0100 +++ 2/draft-ietf-ccamp-path-key-ero-03.txt 2009-01-08 02:12:04.000000000 +0100 @@ -1,28 +1,25 @@ Networking Working Group A. Farrel (Ed.) Internet-Draft Old Dog Consulting Intended Status: Standards Track R. Bradford -Created: October 31, 2008 JP. Vasseur -Expires: April 30, 2009 Cisco Systems, Inc. +Created: January 8, 2009 JP. Vasseur +Expires: July 8, 2009 Cisco Systems, Inc. RSVP Extensions for Path Key Support - draft-ietf-ccamp-path-key-ero-02.txt + draft-ietf-ccamp-path-key-ero-03.txt Status of this Memo - By submitting this Internet-Draft, each author represents that - any applicable patent or other IPR claims of which he or she is - aware 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. + 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 @@ -296,21 +293,21 @@ - The PCE is unable to decode the PKS, perhaps because the Path Key has expired. The LSR sends a PathErr message with the error code "Routing Problem" and a new error value "Unknown Path Key for PKS expansion" (see Section 6.3). - PKS cannot be decoded for policy reasons. The LSR sends a PathErr message with the error code "Policy - Control Failure" and a the error value "Inter-domain policy + Control Failure" and the error value "Inter-domain policy failure". - Addition of CPS to ERO causes Path message to become too large. The LSR MAY replace part of the ERO with loose hops [RFC3209] or with a further PKS according to local policy if the loss in specifics within the explicit path is acceptable. If the LSR is unable to take steps to reduce the size of the ERO it MUST send a PathErr message with the error code "Routing Problem" and a new error value "ERO too large for MTU" (see Section 6.3). @@ -359,26 +356,26 @@ Further protection can be provided by using a PCE ID to identify the decoding PCE that is only meaningful within the domain that contains the LSR at the head of the CPS. This may be an IP address that is only reachable from within the domain, or some non-address value. The former requires configuration of policy on the PCEs, the latter requires domain-wide policy. The following specific security issues need to be considered. - Confidentiality of the CPS. The question to be answered is whether - other network elements can probe for a PCE for the expansion of - PKSs, possibly generating path keys at random. This can be - protected against by only allowing PKS expansion to be successfully - completed if requested by the LSR that is at the head end of the - resulting CPS. Under specific circumstances, PKS expansion might - also be allowed by configured management stations. + other network elements can probe a PCE for the expansion of PKSs, + possibly generating path keys at random. This can be protected + against by only allowing PKS expansion to be successfully completed + if requested by the LSR that is at the head end of the resulting + CPS. Under specific circumstances, PKS expansion might also be + allowed by configured management stations. The CPS itself may be kept confidential as it is exchanged in the PCEP and RSVP-TE protocols using standard security mechanisms defined for those protocols. - Determination of information by probing. In addition to the probing described above, a node might deduce information from the error responses generated when PKS expansion fails as described in Section 3.1. Any LSR that considers that supplying one of the detailed error codes described in Section 3.1 might provide too @@ -410,55 +407,55 @@ Policy forms an important part of the use of PKSs in EROs and RROs. There are local and domain-wide policies that SHOULD be available for configuration in an implementation. - Handling of an ERO containing a PKS. As described in Section 3.1 an LSR that receives a Path message containing a PKS can be configured to reject the Path message according to policy. - Handling of PKS requests at a PCE. As described in Section 3.1, in - [PCE-PKS], and in [PCE-POLICY] a PCE can be configured with policy + [PCE-PKS], and in [RFC5394] a PCE can be configured with policy about how it should handle requests for PKS expansion. - PKS expansion. Section 3.1 explains that the PKS can be expanded by the local LSR, the specific PCE identified in the PKS, any PCE acting as a proxy, or by some other method. The behavior of the LSR needs to be locally configurable, but is subject the domain-wide policy. - Interpretation of PCE-ID. The interpretation of the PCE-ID component of PKSs is subject to domain-local policy and needs to be configurable as such. See Section 3 and Section 4 for the options. - ERO too large. The behavior of an LSR when it finds that adding a - CS to the ERO causes the Path message to be too large, is an + CPS to the ERO causes the Path message to be too large, is an implementation choice. However, implementations may choose to provide configuration of behavior as described in Section 3.1. - Masking of RRO. As described in Section 3.2, a border router can choose to mask segments of the path by replacing them with PKSs. This behavior needs to be configurable with the default being to not hide any part of the RRO. - Inspection / decode of PKS by diagnostic tools. A PCE can allow access from management or diagnostic tools to request the expansion of a PKS. Note that this must be regulated with the security and confidentiality behavior described in Section 4. - Hiding of reason codes. An LSR can support the configuration of local policy to hide reason codes associated with the failure to expand a PKS, and as described in Section 4, report all errors as policy failures. The treatment of a path segment as a CPS, and its substitution in - a PCReq ERO with a PKS, is a PCE function and is described in + a PCRep ERO with a PKS, is a PCE function and is described in [PCE-PKS]. 6. IANA considerations 6.1. Explicit Route Object Subobjects IANA maintains a registry called "Resource Reservation Protocol (RSVP) Parameters" with a subregistry called "Class Names, Class Numbers, and Class Types". @@ -555,31 +552,31 @@ [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. - [PCE-POLICY] Bryskin, I., Papadimitriou, D., Berger, L. and Ash, G., - "Policy-Enabled Path Computation Framework", draft-ietf- - pce-policy-enabled-path-comp, 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. + 8. Authors' Addresses: Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk Rich Bradford Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA - 01719 @@ -588,47 +585,70 @@ J.-P Vasseur Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA - 01719 USA Email: jpv@cisco.com Full Copyright Statement - Copyright (C) The IETF Trust (2008). + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. + 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. - This document and the information contained herein 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + 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 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 - this 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. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. + 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. - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. + Copies of Intellectual Property disclosures made to the IETF + Secretariat and any assurances of licenses to be made available, or + the result of an attempt made to obtain a general license or + permission for the use of such proprietary rights by implementers or + users of this specification can be obtained from the IETF on-line IPR + repository at http://www.ietf.org/ipr The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. + any standard or specification contained in an IETF Document. Please + 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.