draft-ietf-ccamp-path-key-ero-02.txt		draft-ietf-ccamp-path-key-ero-03.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: October 31, 2008 JP. Vasseur		Created: January 8, 2009 JP. Vasseur
	Expires: April 30, 2009 Cisco Systems, Inc.		Expires: July 8, 2009 Cisco Systems, Inc.
	RSVP Extensions for Path Key Support		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		Status of this Memo
	By submitting this Internet-Draft, each author represents that		This Internet-Draft is submitted to IETF in full conformance with
	any applicable patent or other IPR claims of which he or she is		the provisions of BCP 78 and BCP 79.
	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.
	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 and may be updated, replaced, or obsoleted by other		months and may be updated, replaced, or obsoleted by other
	documents at any time. It is inappropriate to use Internet-Drafts		documents at any time. It is inappropriate to use Internet-Drafts
	as reference material or to cite them other than as "work in		as reference material or to cite them other than as "work in
	skipping to change at page 7, line 21		skipping to change at page 7, line 21
	- The PCE is unable to decode the PKS, perhaps because the Path Key		- The PCE is unable to decode the PKS, perhaps because the Path Key
	has expired.		has expired.
	The LSR sends a PathErr message with the error code "Routing		The LSR sends a PathErr message with the error code "Routing
	Problem" and a new error value "Unknown Path Key for PKS		Problem" and a new error value "Unknown Path Key for PKS
	expansion" (see Section 6.3).		expansion" (see Section 6.3).
	- PKS cannot be decoded for policy reasons.		- PKS cannot be decoded for policy reasons.
	The LSR sends a PathErr message with the error code "Policy		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".		failure".
	- Addition of CPS to ERO causes Path message to become too large.		- 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		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		with a further PKS according to local policy if the loss in
	specifics within the explicit path is acceptable. If the LSR is		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		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		PathErr message with the error code "Routing Problem" and a new
	error value "ERO too large for MTU" (see Section 6.3).		error value "ERO too large for MTU" (see Section 6.3).
	skipping to change at page 8, line 35		skipping to change at page 8, line 35
	Further protection can be provided by using a PCE ID to identify		Further protection can be provided by using a PCE ID to identify
	the decoding PCE that is only meaningful within the domain that		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		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		that is only reachable from within the domain, or some non-address
	value. The former requires configuration of policy on the PCEs,		value. The former requires configuration of policy on the PCEs,
	the latter requires domain-wide policy.		the latter requires domain-wide policy.
	The following specific security issues need to be considered.		The following specific security issues need to be considered.
	- Confidentiality of the CPS. The question to be answered is whether		- Confidentiality of the CPS. The question to be answered is whether
	other network elements can probe for a PCE for the expansion of		other network elements can probe a PCE for the expansion of PKSs,
	PKSs, possibly generating path keys at random. This can be		possibly generating path keys at random. This can be protected
	protected against by only allowing PKS expansion to be successfully		against by only allowing PKS expansion to be successfully completed
	completed if requested by the LSR that is at the head end of the		if requested by the LSR that is at the head end of the resulting
	resulting CPS. Under specific circumstances, PKS expansion might		CPS. Under specific circumstances, PKS expansion might also be
	also be allowed by configured management stations.		allowed by configured management stations.
	The CPS itself may be kept confidential as it is exchanged in the		The CPS itself may be kept confidential as it is exchanged in the
	PCEP and RSVP-TE protocols using standard security mechanisms		PCEP and RSVP-TE protocols using standard security mechanisms
	defined for those protocols.		defined for those protocols.
	- Determination of information by probing. In addition to the probing		- Determination of information by probing. In addition to the probing
	described above, a node might deduce information from the error		described above, a node might deduce information from the error
	responses generated when PKS expansion fails as described in		responses generated when PKS expansion fails as described in
	Section 3.1. Any LSR that considers that supplying one of the		Section 3.1. Any LSR that considers that supplying one of the
	detailed error codes described in Section 3.1 might provide too		detailed error codes described in Section 3.1 might provide too
	skipping to change at page 9, line 38		skipping to change at page 9, line 38
	Policy forms an important part of the use of PKSs in EROs and RROs.		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		There are local and domain-wide policies that SHOULD be available for
	configuration in an implementation.		configuration in an implementation.
	- Handling of an ERO containing a PKS. As described in Section 3.1 an		- 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		LSR that receives a Path message containing a PKS can be configured
	to reject the Path message according to policy.		to reject the Path message according to policy.
	- Handling of PKS requests at a PCE. As described in Section 3.1, in		- 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.		about how it should handle requests for PKS expansion.
	- PKS expansion. Section 3.1 explains that the PKS can be expanded by		- 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		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		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		needs to be locally configurable, but is subject the domain-wide
	policy.		policy.
	- Interpretation of PCE-ID. The interpretation of the PCE-ID		- Interpretation of PCE-ID. The interpretation of the PCE-ID
	component of PKSs is subject to domain-local policy and needs to be		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.		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		- 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		implementation choice. However, implementations may choose to
	provide configuration of behavior as described in Section 3.1.		provide configuration of behavior as described in Section 3.1.
	- Masking of RRO. As described in Section 3.2, a border router can		- 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.		choose to mask segments of the path by replacing them with PKSs.
	This behavior needs to be configurable with the default being to		This behavior needs to be configurable with the default being to
	not hide any part of the RRO.		not hide any part of the RRO.
	- Inspection / decode of PKS by diagnostic tools. A PCE can allow		- Inspection / decode of PKS by diagnostic tools. A PCE can allow
	access from management or diagnostic tools to request the expansion		access from management or diagnostic tools to request the expansion
	of a PKS. Note that this must be regulated with the security and		of a PKS. Note that this must be regulated with the security and
	confidentiality behavior described in Section 4.		confidentiality behavior described in Section 4.
	- Hiding of reason codes. An LSR can support the configuration of		- Hiding of reason codes. An LSR can support the configuration of
	local policy to hide reason codes associated with the failure to		local policy to hide reason codes associated with the failure to
	expand a PKS, and as described in Section 4, report all errors as		expand a PKS, and as described in Section 4, report all errors as
	policy failures.		policy failures.
	The treatment of a path segment as a CPS, and its substitution in		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].		[PCE-PKS].
	6. IANA considerations		6. IANA considerations
	6.1. Explicit Route Object Subobjects		6.1. Explicit Route Object Subobjects
	IANA maintains a registry called "Resource Reservation Protocol		IANA maintains a registry called "Resource Reservation Protocol
	(RSVP) Parameters" with a subregistry called "Class Names, Class		(RSVP) Parameters" with a subregistry called "Class Names, Class
	Numbers, and Class Types".		Numbers, and Class Types".
	skipping to change at page 12, line 46		skipping to change at page 12, line 46
	[PCEP] J.P. Vasseur, et al., "Path Computation Element (PCE)		[PCEP] J.P. Vasseur, et al., "Path Computation Element (PCE)
	Communication Protocol (PCEP)", draft-ietf-pce-pcep, work		Communication Protocol (PCEP)", draft-ietf-pce-pcep, work
	in progress.		in progress.
	[PCE-PKS] Bradford, R., Vasseur, J.P., and Farrel, A., "Preserving		[PCE-PKS] Bradford, R., Vasseur, J.P., and Farrel, A., "Preserving
	Topology Confidentiality in Inter-Domain Path Computation		Topology Confidentiality in Inter-Domain Path Computation
	Using a Key-Based Mechanism", draft-ietf-pce-path-key,		Using a Key-Based Mechanism", draft-ietf-pce-path-key,
	work in progress.		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		[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.,
			"Policy-Enabled Path Computation Framework", RFC 5394,
			December 2008.
	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
	skipping to change at page 13, line 31		skipping to change at page 13, line 31
	J.-P Vasseur		J.-P 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		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		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. 16 change blocks.
	47 lines changed or deleted		48 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/