draft-ietf-mip6-cn-ipsec-03.txt		cn-ipsec-03-edits.txt
	MIP6 Working Group F. Dupont		MIP6 Working Group F. Dupont
	Internet-Draft CELAR		Internet-Draft CELAR
	Intended status: Informational J-M. Combes		Intended status: Informational J-M. Combes
	Expires: February 4, 2007 France Telecom DR&D		Expires: February 4, 2007 France Telecom DR&D
	August 3, 2006		August 3, 2006
	Using IPsec between Mobile and Correspondent IPv6 Nodes		Using IPsec between Mobile and Correspondent IPv6 Nodes
	draft-ietf-mip6-cn-ipsec-03.txt		draft-ietf-mip6-cn-ipsec-03-edits.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		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		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.		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
	skipping to change at page 2, line 11		skipping to change at page 2, line 11
	option validation (aka. triangular routing) and protection of		option validation (aka. triangular routing) and protection of
	mobility signaling for route optimizations. The configuration		mobility signaling for route optimizations. The configuration
	details for IPsec and IKE are also provided.		details for IPsec and IKE are also provided.
	1. Introduction		1. Introduction
	Mobile IPv6 documents [RFC3775][RFC3776] specifies IPsec [RFC4301]		Mobile IPv6 documents [RFC3775][RFC3776] specifies IPsec [RFC4301]
	for the protection of the signaling between the mobile node (MN) and		for the protection of the signaling between the mobile node (MN) and
	its home agent (HA), and the return routability procedure between the		its home agent (HA), and the return routability procedure between the
	mobile node and its correspondent nodes (CN) for routing		mobile node and its correspondent nodes (CN) for routing
	optimization. But any stronger mechanism (i.e., more secure than the		optimization. This document defines an alternative mechanism based on
	return routability procedure) may be used, including of course IPsec		strong authentication and IPsec.
	(cf. [RFC3775] Appendix 3 "New Authorization Methods").
	This document specifies which IPsec configurations can be useful in a		This document specifies which IPsec configurations can be useful in a
	Mobile IPv6 context and how they can validate home address options		Mobile IPv6 context and how they can validate home address options
	(enabling triangular routing) and protect mobility signaling		(enabling triangular routing) and protect mobility signaling
	(enabling routing optimization). It gives detailed IKE		(enabling routing optimization). It gives detailed IKE
	[RFC2409][RFC4306] configuration guidelines for common cases.		[RFC2409][RFC4306] configuration guidelines for common cases.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	IKE terminology is copied from IKEv2 [RFC4306].		IKE terminology is copied from IKEv2 [RFC4306].
	2. Applicability		2. Applicability
	The purpose of this document is not to replace the [RFC3775] return		The purpose of this document is not to replace the [RFC3775] return
	routability procedure by the use of IPsec/IKE which has some		routability procedure by the use of IPsec/IKE. It is unrealistic to
	authentication requirements which make its universal deployment more		expect credentials to be available for strong authentication between
	than unrealistic.		any pair of communication hosts.
	The idea is to enable the use of the superior security provided by		The idea is to enable the use of the superior security provided by
	IPsec when it is already in use (i.e., comes at no extra cost),		IPsec when it is already in use (i.e., comes at no extra cost),
	obstacles (i.e., authentication) to its use no more stand in the way,		obstacles (i.e., authentication) to its use no more stand in the way,
	or simply when it can be considered as highly desirable.		or simply when it can be considered as highly desirable.
			This mechanism should only be turned on by explicit configuration
			between specific peers. The mechanism does not support automatic
			capability negotiation at this time.
	3. IPsec in a Mobile IPv6 context		3. IPsec in a Mobile IPv6 context
	This document considers only suitable IPsec security associations,		This document considers only suitable IPsec security associations,
	i.e., anything which does not fulfill the following requirements is		i.e., anything which does not fulfill the following requirements is
	out of scope:		out of scope:
	- IPsec security association pairs MUST be between the mobile node		- IPsec security association pairs MUST be between the mobile node
	and one of its correspondent nodes.		and one of its correspondent nodes.
	- origin authentication, payload integrity and anti-replay services		- origin authentication, payload integrity and anti-replay services
	MUST be selected.		MUST be selected.
	- the traffic selectors MUST match exclusively the home address of		- the traffic selectors MUST match exclusively the home address of
	skipping to change at page 3, line 45		skipping to change at page 3, line 45
	CN does the home address option validation by successful IPsec		CN does the home address option validation by successful IPsec
	processing of the packet. The care-of address in the source address		processing of the packet. The care-of address in the source address
	field of the IPv6 header is not used by IPsec at all as the IPsec		field of the IPv6 header is not used by IPsec at all as the IPsec
	policy checks happen against the home address. The CN continues to		policy checks happen against the home address. The CN continues to
	send the packets via the home network until a binding update is		send the packets via the home network until a binding update is
	processed.		processed.
	5. Routing Optimization		5. Routing Optimization
	A suitable IPsec security association can protect binding updates and		A suitable IPsec security association can protect binding updates and
	acknowledgments. In binding updates the new requirements are:		acknowledgments. In Binding Updates the new requirements are:
	- the H (home registration) and K (key management mobility		- Nonce Indices and Binding Authorization Data options SHOULD NOT be
	capability) bits MUST be cleared.
	- Nonce indices and binding authorization data options SHOULD NOT be
	sent by the mobile node and MUST be ignored by the correspondent		sent by the mobile node and MUST be ignored by the correspondent
	node.		node.
	- when an alternate care-of address option is present and is not		- When an Alternate Care-of Address option is present, the alternate
	checked using the state cookie mechanism [COOKIE], the alternate
	care-of address MUST match the source address in the IP header or		care-of address MUST match the source address in the IP header or
	the home address itself. Any binding update which does not		the home address itself. Any Binding Update which does not
	fulfill this requirement MUST be rejected.		fulfill this requirement MUST be rejected.
	- as ESP can only protect the payload, an alternate care-of address
	option MUST be used in conjunction with ESP (cf. [RFC3775] section
	11.7.1).
	In binding acknowledgments the new requirements are:		In Binding Acknowledgments the new requirements are:
	- the K (key management mobility capability) bit MUST be cleared.		- Binding Authorization Data option SHOULD NOT be sent by the
	- binding authorization data option SHOULD NOT be sent by the
	correspondent node and MUST be ignored by the mobile node.		correspondent node and MUST be ignored by the mobile node.
	- "long" lifetime compatible with the IPsec policy (i.e., by default
	up to the IPsec security association lifetime) MAY be granted.		The use of the K (Key Management Mobility Capability) bit with
			correspondent nodes is not defined. This bit is always set to zero
			on sending a Binding Update or Acknowledgment, and ignored on
			receipt.
			Note that a relatively "long" lifetime compatible with the IPsec
			policy (i.e., by default up to the IPsec security association
			lifetime) MAY be used with correspondent registrations, in
			contrast to the short lifetime required by standard RFC 3775
			mechanisms.
	6. IKE configurations		6. IKE configurations
	This document considers only IKE where it is used for mobility		This document considers only IKE where it is used for mobility
	purpose. Peer addresses (addresses IKE runs over) are the addresses		purpose. Peer addresses (addresses IKE runs over) are the addresses
	seen at the transport or application layer, i.e., when the mobile		seen at the transport or application layer, i.e., when the mobile
	node uses its home address as the source of an IKE message, the		node uses its home address as the source of an IKE message, the
	source address in the IP header can (should!) be a care-of address.		source address in the IP header can (should!) be a care-of address.
	IKE MUST be run over the home address for the mobile node side when		IKE MUST be run over the home address for the mobile node side when
	the home address is usable. The case where the home address in		the home address is usable. The case where the home address in
	unusable is the subject of Appendix A.		unusable is the subject of Appendix A.
	The home address MAY be used in (phase 1) mobile node Identification		The home address MAY be used in (phase 1) mobile node Identification
	payloads. But this does not work well with dynamic home addresses,		payloads. But this does not work well with dynamic home addresses,
	so when it is acceptable by the correspondent node policy, name based		so when it is acceptable by the correspondent node policy, name based
	Identification (i.e., of type ID_FQDN or ID_RFC822_ADDR, [RFC4306]		Identification (i.e., of type ID_FQDN or ID_RFC822_ADDR, [RFC4306]
	section 3.5) payloads SHOULD be used by the mobile node.		section 3.5) payloads SHOULD be used by the mobile node.
	When the home address is bound to a public key, for instance when the
	home address is a Cryptographically Generated Addresses [RFC3972],
	the strong authentication MAY be replaced by an address ownership
	proof as described for instance in [IKECGA].
	The IKE peer policy MAY restrict IPsec security associations to the
	protection of Mobile IPv6 signaling, i.e., restrict the traffic
	selectors to the mobility header "upper protocol" with at least
	binding update and acknowledgment message types. This SHOULD be the
	default policy when authentication or authorization can be considered
	as being weak, for instance when the previous paragraph is applied.
	7. Security Considerations		7. Security Considerations
	IPsec is far more secure than the return routability procedure, thus		Where the means to create suitable IPsec security associations
	it should be used where it is applicable. So this document can		exist, this mechanism provides origin authentication, integrity
	increase at least the overall security of Mobile IPv6.		protection, replay protection and optional confidentiality services
			for the Mobile IPv6 signalling. This improves the security over
			RFC 3775 route optimization, as the signaling packets in the latter
			are vulnerable to man-in-the-middle attacks. The implications of
			this vulnerability are subtle, however, given that an attacker in
			the same position is also capable of seeing all the payload packets
			and could launch other attacks with similar implications. For
			instance, such an attacker could see or modify the contents of
			payload packets not protected with end-to-end security and cause
			denial-of-service for others. However, the RFC 3775 mechanism
			allows such attacks in a short time window even after the attacker
			is no longer in a position to see the payload packets
			themselves. The mechanism defined in this specification removes
			this vulnerability, and is also secure independently of the
			possible vulnerabilities related to payload packets.
	Two points are worthy of special considerations:		However, unlike RFC 3775 this mechanism should only be used when
	- no care-of address test is required when ingress filtering can		the correspondent node has good reason to trust the actions of the
	reject fake care-of addresses from a rogue mobile node but a		mobile node. In particular, the correspondent node needs to be
	correspondent node can use the return routability state cookie		certain that the mobile node will not launch flooding attacks
	procedure to get extra insurance as well as for the support of		against a third party as described in [RODESIGN]. Without such
	real alternate care-of addresses.		trust the only protection comes from the application of ingress
	- in order to avoid granting any extra privilege by a side effect of		filtering in the network where the attacker resides. However, at
	using IPsec, the peers (i.e., the mobile and correspondent nodes)		the moment ingress filtering has not been universally deployed.
	may restrict the traffic selectors to the protection of mobility		This mechanism is vulnerable to flooding attacks as it does not
	signaling only. This should be applied to any dubious cases,		verify the validity of a claimed new care-of address.
	including by default when security administration is known to be
	too light.		In order to avoid granting extra privileges by a side effect this
			mechanism, the application of this mechanism must not lead to
			allowing any new, previously unauthorized traffic to flow between
			the peers beyond mobility signaling with the Mobility Header (MH)
			protocol. The IKE peer policy MAY also restrict IPsec security
			associations to the protection of Mobile IPv6 signaling, i.e.,
			restrict the traffic selectors to MH with at least Binding Update
			and Acknowledgment message types.
	8. Acknowledgments		8. Acknowledgments
	The authors would like to thank many people for believing in IPsec as		The authors would like to thank many people for believing in IPsec as
	a right way to secure Mobile IPv6. Special thanks to Wassim Haddad		a right way to secure Mobile IPv6. Special thanks to Wassim Haddad
	and Claude Castelluccia for keeping our attention to special cases		and Claude Castelluccia for keeping our attention to special cases
	where home addresses are derived from public keys.		where home addresses are derived from public keys.
	9. Changes from previous versions		9. Possible Enhancements
			A number of potential future enhancements of this method are
			possible, including, for instance, use of addresses bound to keys
			to avoid configuration effort or various mechanisms for the
			verification of care of addresses. See [IKECGA, COOKIE, ROENH] for
			some of these and related ideas.
			10. Changes from previous versions
	To be removed prior to publication as an RFC.		To be removed prior to publication as an RFC.
	An applicability section was added.		An applicability section was added.
	The IKE running over a care-of address was moved to an appendix as it		The IKE running over a care-of address was moved to an appendix as it
	is not at all the standard case.		is not at all the standard case.
	The care-of address test annex was moved to its own document		The care-of address test annex was moved to its own document
	[COOKIE].		[COOKIE].
	Peer address clarification (thanks to Mohan Parthasarathy). Change		Peer address clarification (thanks to Mohan Parthasarathy). Change
	SHOULD/MAY to MUST/MUST for mobile node peer address.		SHOULD/MAY to MUST/MUST for mobile node peer address.
	10. References		11. References
	10.1. Normative References		10.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", RFC 2119, BCP 14, March 1997.		Requirement Levels", RFC 2119, BCP 14, March 1997.
	[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange		[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
	(IKE)", RFC 2409, November 1998.		(IKE)", RFC 2409, November 1998.
	[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support		[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
	skipping to change at page 6, line 46		skipping to change at page 6, line 46
	June 2003.		June 2003.
	[ORCHID] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix		[ORCHID] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix
	for Overlay Routable Cryptographic Hash Identifiers		for Overlay Routable Cryptographic Hash Identifiers
	(ORCHID)", draft-laganier-ipv6-khi-02.txt (work in		(ORCHID)", draft-laganier-ipv6-khi-02.txt (work in
	progress), June 2006.		progress), June 2006.
	[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",		[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
	RFC 3972, March 2005.		RFC 3972, March 2005.
			[ROENH] Vogt, C., and Arkko, J. "A Taxonomy and Analysis of
			Enhancements to Mobile IPv6 Route Optimization",
			draft-irtf-mobopts-ro-enhancements-08.txt (work in
			progress), November 2006.
			[RODESIGN] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and
			E. Nordmark, "Mobile IP Version 6 Route Optimization
			Security Design Background", RFC 4226, December 2005.
	Appendix A. IKE running over a care-of address		Appendix A. IKE running over a care-of address
	In special circumstances where the home address can be unusable, like		In special circumstances where the home address can be unusable, like
	when the home address is ORCHID [ORCHID] based and not routable, IKE		when the home address is ORCHID [ORCHID] based and not routable, IKE
	must be run over a care-of address but this has many known drawbacks:		must be run over a care-of address but this has many known drawbacks:
	- a care-of address can not be used for authentication nor		- a care-of address can not be used for authentication nor
	authorization.		authorization.
	- security associations do not survive handoffs.		- security associations do not survive handoffs.
	- the establishment of transport mode IPsec security association		- the establishment of transport mode IPsec security association
End of changes. 16 change blocks.
	51 lines changed or deleted		82 lines changed or added
This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/