< draft-ietf-mip6-cn-ipsec-06.txt		draft-ietf-mip6-cn-ipsec-07.txt >
	MIP6 Working Group F. Dupont		MIP6 Working Group F. Dupont
	Internet-Draft ISC		Internet-Draft ISC
	Expires: May 17, 2008 J-M. Combes		Expires: August 26, 2008 J-M. Combes
	Orange Labs/France Telecom R&D		Orange Labs/France Telecom R&D
	November 14, 2007		February 23, 2008
	Using IPsec between Mobile and Correspondent IPv6 Nodes		Using IPsec between Mobile and Correspondent IPv6 Nodes
	draft-ietf-mip6-cn-ipsec-06.txt		draft-ietf-mip6-cn-ipsec-07.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 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	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."
	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.
	This Internet-Draft will expire on May 17, 2008.		This Internet-Draft will expire on August 26, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	Abstract		Abstract
	Mobile IPv6 uses IPsec to protect signaling between the Mobile Node		Mobile IPv6 uses IPsec to protect signaling between the Mobile Node
	and the Home Agent. This document defines how IPsec can be used		and the Home Agent. This document defines how IPsec can be used
	between the Mobile Node and Correspondent Nodes for Home Address		between the Mobile Node and Correspondent Nodes for Home Address
	Option validation and protection of mobility signaling for Route		Option validation and protection of mobility signaling for Route
	Optimization. The configuration details for IPsec and IKE are also		Optimization. The configuration details for IPsec and IKE are also
	provided.		provided.
	skipping to change at page 2, line 29 ¶		skipping to change at page 2, line 29 ¶
	configuration guidelines for common cases.		configuration guidelines for common cases.
	Note when the design goal of the return routability procedure was to		Note when the design goal of the return routability procedure was to
	be "not worse than the current Internet", the design goal of this		be "not worse than the current Internet", the design goal of this
	document is "not worse than deployed IPsec".		document is "not worse than deployed IPsec".
	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] [IKEv2bis].
	2. Applicability		2. Applicability
	The purpose of this document is not to replace the return routability		The purpose of this document is not to replace the return routability
	procedure, specified in [RFC3775], by the use of IPsec/IKE. It is		procedure, specified in [RFC3775], by the use of IPsec/IKE. It is
	unrealistic to expect credentials to be available today for strong		unrealistic to expect credentials to be available today for strong
	authentication between any pair of Internet nodes.		authentication between any pair of Internet nodes.
	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), when		IPsec when it is already in use (i.e., comes at no extra cost), when
	skipping to change at page 4, line 40 ¶		skipping to change at page 4, line 40 ¶
	on sending a Binding Update or Binding Acknowledgment, and ignored on		on sending a Binding Update or Binding Acknowledgment, and ignored on
	receipt.		receipt.
	Note that a relatively long lifetime compatible with the IPsec policy		Note that a relatively long lifetime compatible with the IPsec policy
	(i.e., by default up to the IPsec Security Association lifetime) MAY		(i.e., by default up to the IPsec Security Association lifetime) MAY
	be used with correspondent registrations, in contrast to the short		be used with correspondent registrations, in contrast to the short
	lifetime required by standard RFC 3775 mechanisms.		lifetime required by standard RFC 3775 mechanisms.
	6. IKE configurations		6. IKE configurations
	With mobility the Mobile Node uses at least two addresses so if in		6.1. Introduction
	general an address of the Mobile Node has to be the Home Address
	(this section is mostly about such requirements), it is not always
	the case: for instance when the Mobile Node uses its Home Address as
	the source of an IKE message, the source address in the IP header it-
	self can be a Care-of Address.
	There is place where the Correspondent Node always gets the Home		This section should be understandable (so applicable) from both the
	Address, it is the Mobile Node address in the Traffic Selectors (note		mobility and IPsec/IKE points of view:
	this is not a new requirement, just a direct consequence of		- IKE is an application like any other, mobility is not directly
	Section 3.) The Mobile Node MUST put its Home Address in its Traffic		visible by IKE. This is different and simpler than the Mobile
	Selector payload and the Correspondent Node SHALL get the Home		Node - Home Agent [RFC3776] [RFC4877] situation.
	Address as the only address of its peer, the Mobile Node, in the peer		- the key point in the use of IKE by the mobility is to enforce the
	Traffic Selector payload.		Section 3 requirements.
			In particular, it is REQUIRED the Home Address of the Mobile Node
			matches exclusively the address of the Mobile Node in the Traffic
			Selector. So this section can use one of these two terms to indicate
			this address.
			6.2. Requirements
	Addresses IKE runs over (aka. the peer addresses) are the addresses		Addresses IKE runs over (aka. the peer addresses) are the addresses
	seen at the transport or application layer. With this definition,		seen at the transport or application layer. With this definition,
	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.
	Note the PKI profile for IKE [RFC4945] applies so when the Mobile		Note the PKI profile for IKE [RFC4945] applies so when the Mobile
	Node uses an Identification payload with the ID_IPV6_ADDR type, the		Node uses an Identification payload with the ID_IPV6_ADDR type, the
	Mobile Node MUST put the Home Address in it and the Correspondent		Mobile Node MUST put the Home Address in it and the Correspondent
	Node MUST verify that the address in the Identification payload will		Node MUST verify that the address in the Identification payload will
	be the Home Address.		be the Home Address.
	When an address appears in a Peer Authorization Database (the PAD,		6.3. Authorization
	[RFC4301]) related object for the Mobile Node, the Correspondent Node
	MUST verify the address or one of these addresses is the same than
	the Home Address, so the third requirement of Section 3 applies only
	to authorized Home Addresses.
	For instance, this check is REQUIRED when the Home Address can be the		The IPsec/IKE configuration MUST constraint the authorized traffic,
	address in an iPAddress field in the SubjectAltName extension		in particular the Child SA Authorization Data [RFC4301] [IKEv2bis]
	[RFC3280] of the Mobile Node certificate; or when the Home Address		SHOULD authorize the Home Addresses per Mobile Node and per Address.
	can be the address used to lookup a pre-shared key.		This requirement applies to the whole IPsec/IKE configuration, not
			only the mobility related part.
	If the Home Address is not assigned dynamically by the Home Agent,		The Correspondent Node MUST verify the authorization of the Home
	the Home Address SHOULD appears in such a PAD related object for the		Address, and it MUST refuse to established IPsec SAs with a not-
	Mobile Node. Note that the PAD was designed to provide such binding		authorized Home Address. For instance, this check is REQUIRED when
	of addresses to peers ([RFC4301] at the end of the section 4.4.3.4)		the Home Address can be the address in an iPAddress field in the
	and this can be described directly in the PAD or indirectly by peer		SubjectAltName extension [RFC3280] of the Mobile Node certificate; or
	authentication/authorization data like an transmitted end system		when the Home Address can be the address used to lookup a pre-shared
	valid certificate.		key.
			Dynamically assigned Home Addresses are not known a priori so it is
			not possible to individually authorize them. In this case the
			authorization SHOULD be done using the ranges of the possible
			dynamically assigned Home Addresses.
	7. IANA Considerations		7. IANA Considerations
	This document makes no request of IANA.		This document makes no request of IANA.
	Note to RFC Editor: this section may be removed on publication as an		Note to RFC Editor: this section may be removed on publication as an
	RFC.		RFC.
	8. Security Considerations		8. Security Considerations
	skipping to change at page 6, line 46 ¶		skipping to change at page 7, line 4 ¶
	the mobile node will not launch flooding attacks against a third		the mobile node will not launch flooding attacks against a third
	party as described in [RFC4225]. Without such trust the only		party as described in [RFC4225]. Without such trust the only
	protection comes from the application of ingress filtering in the		protection comes from the application of ingress filtering in the
	network where the attacker resides. However, at the moment ingress		network where the attacker resides. However, at the moment ingress
	filtering has not been universally deployed. This mechanism is		filtering has not been universally deployed. This mechanism is
	vulnerable to flooding attacks as it does not verify the validity of		vulnerable to flooding attacks as it does not verify the validity of
	a claimed new care-of address. Note, however, the following:		a claimed new care-of address. Note, however, the following:
	- The attacker has to be the Mobile Node itself, i.e., the IPsec/IKE		- The attacker has to be the Mobile Node itself, i.e., the IPsec/IKE
	peer, which is supposed to be the subject of a minimal level of		peer, which is supposed to be the subject of a minimal level of
	trust.		trust.
	- The attack can be easily traced back to the Mobile Node.		- The attack can be easily traced back to the Mobile Node.
	In order to avoid granting extra privileges by a side effect, the		In order to avoid granting extra privileges by a side effect, the
	application of this mechanism must not lead to allowing any new,		application of this mechanism must not lead to allowing any new,
	previously unauthorized traffic to flow between the peers beyond		previously unauthorized traffic to flow between the peers beyond
	mobility signaling with the Mobility Header (MH) protocol. The IPsec		mobility signaling with the Mobility Header (MH) protocol. The IPsec
	peer policy MAY also restrict IPsec Security Associations to the		peer policy MAY also restrict IPsec Security Associations to the
	protection of Mobile IPv6 signaling, i.e., restrict the Traffic		protection of Mobile IPv6 signaling, i.e., restrict the Traffic
	Selectors to MH with at least Binding Update and Binding		Selectors to MH with at least Binding Update and Binding
	Acknowledgment message types.		Acknowledgment message types.
	Although the protection of static addresses is not mandatory in IPsec		Although the protection of static addresses is not mandatory in IPsec
	or Home Addresses do not introduce a specific issue, this document		or Home Addresses do not introduce a specific issue, this document
	requires authorized Home Addresses when the check is possible, and		requires authorized Home Addresses, and recommends individual or
	recommends to make the check possible for static Home Addresses.		range authorization according to what is possible. This protects a
	This protects a Mobile Node using a static so likely known Home		Mobile Node using a static so likely known Home Address against the
	Address against the theft of its Home Address, both when the security		theft of its Home Address, both when the security associations are
	associations are established and without limitations when they are		established and without limitations when they are used. Dynamic
	used.		addresses are not protected against spoofing but the spoofing is
			limited to the dynamic address ranges, i.e., Mobile Nodes using
			dynamically assigned Home Addresses can be attacked between them.
			Finally the authorization requirement applies to the whole
			configuration so mobility is protected against other usages of IPsec.
	9. Acknowledgments		9. 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. Thanks to Mohan		where Home Addresses are derived from public keys. Thanks to Mohan
	Parthasarathy for the peer address clarification.		Parthasarathy for the peer address clarification and to Jari Arkko
			for the time he spent to improve the document.
	10. Possible enhancements		10. Possible enhancements
	A number of potential enhancements of this method are possible,		A number of potential enhancements of this method are possible,
	including, for instance, various mechanisms for verification of		including, for instance, various mechanisms for verification of
	Care-of Addresses or use of addresses bound to keys. [RFC4651]		Care-of Addresses or use of addresses bound to keys. [RFC4651]
	describes many proposals for the general Route Optimization problem.		describes many proposals for the general Route Optimization problem.
	[I-D.dupont-mipv6-rrcookie] is an alternate approach to testing		[I-D.dupont-mipv6-rrcookie] is an alternate approach to testing
	Care-of Addresses.		Care-of Addresses.
	skipping to change at page 9, line 11 ¶		skipping to change at page 9, line 20 ¶
	MIPv6 using a State Cookie",		MIPv6 using a State Cookie",
	draft-dupont-mipv6-rrcookie-05.txt (work in progress),		draft-dupont-mipv6-rrcookie-05.txt (work in progress),
	November 2007.		November 2007.
	[I-D.laganier-ike-ipv6-cga]		[I-D.laganier-ike-ipv6-cga]
	Laganier, J. and G. Montenegro, "Using IKE with IPv6		Laganier, J. and G. Montenegro, "Using IKE with IPv6
	Cryptographically Generated Addresses",		Cryptographically Generated Addresses",
	draft-laganier-ike-ipv6-cga-02.txt (work in progress),		draft-laganier-ike-ipv6-cga-02.txt (work in progress),
	July 2007.		July 2007.
			[IKEv2bis]
			Kaufman, C., Hoffman, P., and P. Eronen, "Internet Key
			Exchange Protocol: IKEv2", draft-hoffman-ikev2bis-02.txt
			(work in progress), November 2007.
	[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",		[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
	RFC 3972, March 2005.		RFC 3972, March 2005.
	[RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.		[RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
	Nordmark, "Mobile IP Version 6 Route Optimization Security		Nordmark, "Mobile IP Version 6 Route Optimization Security
	Design Background", RFC 4225, December 2005.		Design Background", RFC 4225, December 2005.
	[RFC4651] Vogt, C. and J. Arkko, "A Taxonomy and Analysis of		[RFC4651] Vogt, C. and J. Arkko, "A Taxonomy and Analysis of
	Enhancements to Mobile IPv6 Route Optimization", RFC 4651,		Enhancements to Mobile IPv6 Route Optimization", RFC 4651,
	February 2007.		February 2007.
	skipping to change at page 10, line 4 ¶		skipping to change at page 10, line 11 ¶
	- the establishment of transport mode IPsec Security Association		- the establishment of transport mode IPsec Security Association
	using the Home Address as the Mobile Node Traffic Selector raises		using the Home Address as the Mobile Node Traffic Selector raises
	a policy / authorization issue as IKE runs over another address.		a policy / authorization issue as IKE runs over another address.
	Authors' Addresses		Authors' Addresses
	Francis Dupont		Francis Dupont
	ISC		ISC
	Email: Francis.Dupont@fdupont.fr		Email: Francis.Dupont@fdupont.fr
	Jean-Michel Combes		Jean-Michel Combes
	Orange Labs/France Telecom R&D		Orange Labs/France Telecom R&D
	38 rue du General Leclerc		38 rue du General Leclerc
	92794 Issy-les-Moulineaux Cedex 9		92794 Issy-les-Moulineaux Cedex 9
	France		France
	Email: jeanmichel.combes@gmail.com		Email: jeanmichel.combes@gmail.com
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
End of changes. 17 change blocks.
	43 lines changed or deleted		59 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/