draft-ietf-mobileip-mipv6-ha-ipsec-05.txt		draft-ietf-mobileip-mipv6-ha-ipsec-06.txt
Network Working Group J. Arkko		Network Working Group J. Arkko
Internet-Draft Ericsson		Internet-Draft Ericsson
Expires: November 24, 2003 V. Devarapalli		Expires: December 29, 2003 V. Devarapalli
Nokia Research Center		Nokia Research Center
F. Dupont		F. Dupont
ENST Bretagne		ENST Bretagne
May 26, 2003		June 30, 2003
Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and		Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and
Home Agents		Home Agents
draft-ietf-mobileip-mipv6-ha-ipsec-05.txt		draft-ietf-mobileip-mipv6-ha-ipsec-06.txt
Status of this Memo		Status of this Memo
This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
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		other groups may also distribute working documents as
Internet-Drafts.		Internet-Drafts.
Skipping to change at page 1, line 36:
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 http://		The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.		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 November 24, 2003.		This Internet-Draft will expire on December 29, 2003.
Copyright Notice		Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.		Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract		Abstract
Mobile IPv6 uses IPsec to protect signaling between the home agent		Mobile IPv6 uses IPsec to protect signaling between the home agent
and the mobile node. Mobile IPv6 base document defines the main		and the mobile node. Mobile IPv6 base document defines the main
requirements these nodes must follow. This document discusses these		requirements these nodes must follow. This document discusses these
Skipping to change at page 3, line 11:
6.19 Movements and Dynamic Keying . . . . . . . . . . . . . 37		6.19 Movements and Dynamic Keying . . . . . . . . . . . . . 37
7. Implementation Considerations . . . . . . . . . . . . . . . 39		7. Implementation Considerations . . . . . . . . . . . . . . . 39
7.1 IPsec . . . . . . . . . . . . . . . . . . . . . . . . 39		7.1 IPsec . . . . . . . . . . . . . . . . . . . . . . . . 39
7.2 IKE . . . . . . . . . . . . . . . . . . . . . . . . . 40		7.2 IKE . . . . . . . . . . . . . . . . . . . . . . . . . 40
7.3 Bump-in-the-Stack . . . . . . . . . . . . . . . . . . 40		7.3 Bump-in-the-Stack . . . . . . . . . . . . . . . . . . 40
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 42		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 42
9. Security Considerations . . . . . . . . . . . . . . . . . . 43		9. Security Considerations . . . . . . . . . . . . . . . . . . 43
Normative References . . . . . . . . . . . . . . . . . . . . 44		Normative References . . . . . . . . . . . . . . . . . . . . 44
Informative References . . . . . . . . . . . . . . . . . . . 45		Informative References . . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 45		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 45
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 47		A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46
B. Changes from Previous Version . . . . . . . . . . . . . . . 48		B. Changes from Previous Version . . . . . . . . . . . . . . . 47
Intellectual Property and Copyright Statements . . . . . . . 50		Intellectual Property and Copyright Statements . . . . . . . 48
1. Introduction		1. Introduction
This document illustrates the use of IPsec in securing Mobile IPv6		This document illustrates the use of IPsec in securing Mobile IPv6
[8] traffic between mobile nodes and home agents. In Mobile IPv6, a		[8] traffic between mobile nodes and home agents. In Mobile IPv6, a
mobile node is always expected to be addressable at its home address,		mobile node is always expected to be addressable at its home address,
whether it is currently attached to its home link or is away from		whether it is currently attached to its home link or is away from
home. The "home address" is an IP address assigned to the mobile		home. The "home address" is an IP address assigned to the mobile
node within its home subnet prefix on its home link. While a mobile		node within its home subnet prefix on its home link. While a mobile
node is at home, packets addressed to its home address are routed to		node is at home, packets addressed to its home address are routed to
Skipping to change at page 5, line 36:
Sections 10.6 and 11.4 of the base specification [8].		Sections 10.6 and 11.4 of the base specification [8].
The nodes may also optionally protect payload traffic passing through		The nodes may also optionally protect payload traffic passing through
the home agent, as described in Section 5.3 of the base specification		the home agent, as described in Section 5.3 of the base specification
[8]. If multicast group membership control protocols or stateful		[8]. If multicast group membership control protocols or stateful
address autoconfiguration protocols are supported, payload data		address autoconfiguration protocols are supported, payload data
protection support is required.		protection support is required.
The control traffic between the mobile node and the home agent		The control traffic between the mobile node and the home agent
requires message authentication, integrity, correct ordering and		requires message authentication, integrity, correct ordering and
optional anti-replay protection. The mobile node and the home agent		anti-replay protection. The mobile node and the home agent must have
must have a security association to protect this traffic. In		an IPsec security association to protect this traffic. IPsec does
addition, Mobile IPv6 messages assist in ensuring correct ordering,		not proving correct ordering of messages. Correct ordering of the
as IPsec can only provide protection against replayed messages. Full		control traffic is ensured by a sequence number in the Binding Update
protection against replay and ordering attacks is possible only when		and Binding Acknowledgement messages. The sequence number in the
IKE is used, however.		Binding Updates also provides protection to a certain extent. It
		fails in some scenarios, for example, if the Home Agent loses the
		Binding Cache state. Full protection against replay attacks is
		possible only when IKE is used.
Great care is needed when using IKE [5] to establish security		Great care is needed when using IKE [5] to establish security
associations to Mobile IPv6 home agents. The right kind of addresses		associations to Mobile IPv6 home agents. The right kind of addresses
must be used for transporting IKE. This is necessary to avoid		must be used for transporting IKE. This is necessary to avoid
circular dependencies in which the use of a Binding Update triggers		circular dependencies in which the use of a Binding Update triggers
the need for an IKE exchange that cannot complete prior to the		the need for an IKE exchange that cannot complete prior to the
Binding Update having been completed.		Binding Update having been completed.
The mobile IPv6 base document defines the main requirements the		The mobile IPv6 base document defines the main requirements the
mobile nodes and home agents must follow when securing the above		mobile nodes and home agents must follow when securing the above
Skipping to change at page 12, line 28:
The following requirements apply to both home agents and mobile		The following requirements apply to both home agents and mobile
nodes:		nodes:
o Manual configuration of IPsec security associations MUST be		o Manual configuration of IPsec security associations MUST be
supported. The configuration of the keys is expected to take		supported. The configuration of the keys is expected to take
place out-of-band, for instance at the time the mobile node is		place out-of-band, for instance at the time the mobile node is
configured to use its home agent.		configured to use its home agent.
o Automatic key management with IKE [5] MAY be supported. Only		o Automatic key management with IKE [5] MAY be supported. Only
IKEv1 is discussed in this document, even if it is expected that		IKEv1 is discussed in this document. Other automatic key
the next version of IKE can also be used and that it offers		management mechanisms exist and will appear beyond IKEv1, but this
several improvements in this specific application.		document does not address the issues related to them.
o ESP encapsulation of Binding Updates and Acknowledgements between		o ESP encapsulation of Binding Updates and Acknowledgements between
the mobile node and home agent MUST be supported and MUST be used.		the mobile node and home agent MUST be supported and MUST be used.
o ESP encapsulation of the Home Test Init and Home Test messages		o ESP encapsulation of the Home Test Init and Home Test messages
tunneled between the mobile node and home agent MUST be supported		tunneled between the mobile node and home agent MUST be supported
and SHOULD be used.		and SHOULD be used.
o ESP encapsulation of the ICMPv6 messages related to prefix		o ESP encapsulation of the ICMPv6 messages related to prefix
discovery MUST be supported and SHOULD be used.		discovery MUST be supported and SHOULD be used.
Skipping to change at page 13, line 6:
o If multicast group membership control protocols or stateful		o If multicast group membership control protocols or stateful
address autoconfiguration protocols are supported, payload data		address autoconfiguration protocols are supported, payload data
protection MUST be supported for those protocols.		protection MUST be supported for those protocols.
4.2 Policy Requirements		4.2 Policy Requirements
The following requirements apply to both home agents and mobile		The following requirements apply to both home agents and mobile
nodes:		nodes:
o When a packet is matched against IPsec security policy or		o As required in the base specification [8], when a packet destined
		to the receiving node is matched against IPsec security policy or
selectors of a security association, an address appearing in a		selectors of a security association, an address appearing in a
Home Address destination option MUST be considered as the source		Home Address destination option is considered as the source
address of the packet.		address of the packet.
Note that the home address option appears before IPsec headers.		Note that the home address option appears before IPsec headers.
Section 11.3.2 of the base specification [8] describes one		Section 11.3.2 of the base specification describes one possible
possible implementation approach for this: The IPsec policy		implementation approach for this: The IPsec policy operations can
operations can be performed at the time when the packet has not		be performed at the time when the packet has not yet been modified
yet been modified per Mobile IPv6 rules, or has been brought back		per Mobile IPv6 rules, or has been brought back to its normal form
to its normal form after Mobile IPv6 processing. That is, the		after Mobile IPv6 processing. That is, the processing of the Home
processing of the Home Address option is seen as a fixed		Address option is seen as a fixed transformation of the packets
transformation of the packets that does not affect IPsec		that does not affect IPsec processing.
processing.
		o Similarly, a home address within a Type 2 Routing header destined
o Similarly, a home address within a Type 2 Routing header MUST be		to the receiving node is considered as the destination address of
considered as the destination address of the packet, when a packet		the packet, when a packet is matched against IPsec security policy
is matched against IPsec security policy or selectors of a		or selectors of a security association.
security association.
Similar implementation considers apply to the Routing header		Similar implementation considers apply to the Routing header
processing as was described above for the Home Address destination		processing as was described above for the Home Address destination
option.		option.
o When IPsec is used to protect return routability signaling or		o When IPsec is used to protect return routability signaling or
payload packets, this protection MUST only be applied to the		payload packets, this protection MUST only be applied to the
return routability packets entering the IPv6 encapsulated tunnel		return routability packets entering the IPv6 encapsulated tunnel
interface between the mobile node and the home agent. This can be		interface between the mobile node and the home agent. This can be
achieved, for instance, by defining the security policy database		achieved, for instance, by defining the security policy database
entries specifically for the tunnel interface. That is, the		entries specifically for the tunnel interface. That is, the
policy entries are not generally applied on all traffic on the		policy entries are not generally applied on all traffic on the
physical interface(s) of the nodes, but rather only on traffic		physical interface(s) of the nodes, but rather only on traffic
that enters this tunnel.		that enters this tunnel.
Note that this requirement is similar to the approach taken in
dynamically routed VPNs [12].
o The authentication of mobile nodes MAY be based either on machine		o The authentication of mobile nodes MAY be based either on machine
or user credentials. Note that multi-user operating systems		or user credentials. Note that multi-user operating systems
typically allow all users of a node to use any of the IP addresses		typically allow all users of a node to use any of the IP addresses
assigned to the node. This limits the capability of the home		assigned to the node. This limits the capability of the home
agent to restrict the use of a home address to a particular user		agent to restrict the use of a home address to a particular user
in such environment. Where user credentials are applied in a		in such environment. Where user credentials are applied in a
multi-user environment, the configuration should authorize all		multi-user environment, the configuration should authorize all
users of the node to control all home addresses assigned to the		users of the node to control all home addresses assigned to the
node.		node.
Skipping to change at page 16, line 11:
current link is an unprotected wireless link, the attacker would		current link is an unprotected wireless link, the attacker would
able to see both sets of messages, and launch attacks based on it		able to see both sets of messages, and launch attacks based on it
(these attacks are discussed further in Section 15.4 of the base		(these attacks are discussed further in Section 15.4 of the base
specification [8]. One can prevent the attack by making sure that		specification [8]. One can prevent the attack by making sure that
the packets tunneled through the home agent are encrypted.		the packets tunneled through the home agent are encrypted.
Note that this specification concerns itself only with on-the-wire		Note that this specification concerns itself only with on-the-wire
formats, and does not dictate specific implementations mechanisms.		formats, and does not dictate specific implementations mechanisms.
In the case of IPsec tunnel mode, the use of IP-in-IP		In the case of IPsec tunnel mode, the use of IP-in-IP
encapsulation followed by IPsec transport mode encapsulation may		encapsulation followed by IPsec transport mode encapsulation may
also be possible. The trade-offs related to the use of tunnel		also be possible.
mode and IP-in-IP encapsulation have been discussed in [12].
The following rules apply to mobile nodes:		The following rules apply to mobile nodes:
o When ESP is used to protect Binding Updates, there is no		o When ESP is used to protect Binding Updates, there is no
protection for the care-of address which appears in the IPv6		protection for the care-of address which appears in the IPv6
header outside the area protected by ESP. It is important for the		header outside the area protected by ESP. It is important for the
home agent to verify that the care-of address has not been		home agent to verify that the care-of address has not been
tampered with. As a result, the attacker would have redirected		tampered with. As a result, the attacker would have redirected
the mobile node's traffic to another address. In order to prevent		the mobile node's traffic to another address. In order to prevent
this, Mobile IPv6 implementations MUST use the Alternate Care-of		this, Mobile IPv6 implementations MUST use the Alternate Care-of
Skipping to change at page 24, line 43:
proto = X		proto = X
THEN USE SA SA7		THEN USE SA SA7
home agent SAD:		home agent SAD:
- SA8(OUT, spi_h, care_of_address_1, ESP, TUNNEL):		- SA8(OUT, spi_h, care_of_address_1, ESP, TUNNEL):
source = any & destination = home_address_1 & proto = X		source = any & destination = home_address_1 & proto = X
- SA7(IN, spi_g, home_agent_1, ESP, TUNNEL):		- SA7(IN, spi_g, home_agent_1, ESP, TUNNEL):
source = home_address_1 & destination = any & proto = X		source = home_address_1 & destination = any & proto = X
If multicast group membership control protocols such as MLDv1 [9] or		If multicast group membership control protocols such as MLDv1 [9] or
MLDv2 [13] need to be protected, these packets may use a link-local		MLDv2 [12] need to be protected, these packets may use a link-local
address rather than the home address of the mobile node. In this		address rather than the home address of the mobile node. In this
case the source and destination can be left as a wildcard and the SPD		case the source and destination can be left as a wildcard and the SPD
entries will work solely based on the used interface and the		entries will work solely based on the used interface and the
protocol, which is ICMPv6 for both MLDv1 and MLDv2.		protocol, which is ICMPv6 for both MLDv1 and MLDv2.
Similar problems are encountered when stateful address		Similar problems are encountered when stateful address
autoconfiguration protocols such as DHCPv6 [10] are used. The same		autoconfiguration protocols such as DHCPv6 [10] are used. The same
approach is applicable for DHCPv6 as well. DHCPv6 uses the UDP		approach is applicable for DHCPv6 as well. DHCPv6 uses the UDP
protocol.		protocol.
Skipping to change at page 44, line 29:
[5] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",		[5] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.		RFC 2409, November 1998.
[6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)		[6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.		Specification", RFC 2460, December 1998.
[7] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6		[7] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6
Specification", RFC 2473, December 1998.		Specification", RFC 2473, December 1998.
[8] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support in		[8] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support in
IPv6", draft-ietf-mobileip-ipv6-22 (work in progress), May 2003.		IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), June
		2003.
Informative References		Informative References
[9] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener		[9] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener
Discovery (MLD) for IPv6", RFC 2710, October 1999.		Discovery (MLD) for IPv6", RFC 2710, October 1999.
[10] Droms, R., "Dynamic Host Configuration Protocol for IPv6		[10] Droms, R., "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", draft-ietf-dhc-dhcpv6-28 (work in progress),		(DHCPv6)", draft-ietf-dhc-dhcpv6-28 (work in progress),
November 2002.		November 2002.
[11] Kivinen, T., Huttunen, A., Swander, B. and V. Volpe,		[11] Kivinen, T., Huttunen, A., Swander, B. and V. Volpe,
"Negotiation of NAT-Traversal in the IKE",		"Negotiation of NAT-Traversal in the IKE",
draft-ietf-ipsec-nat-t-ike-04 (work in progress), November		draft-ietf-ipsec-nat-t-ike-04 (work in progress), November
2002.		2002.
[12] Touch, J. and L. Eggert, "Use of IPsec Transport Mode for		[12] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
Dynamic Routing", draft-touch-ipsec-vpn-04 (work in progress),
June 2002.
[13] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", draft-vida-mld-v2-06 (work in progress),		(MLDv2) for IPv6", draft-vida-mld-v2-06 (work in progress),
December 2002.		December 2002.
Authors' Addresses		Authors' Addresses
Jari Arkko		Jari Arkko
Ericsson		Ericsson
Jorvas 02420		Jorvas 02420
Finland		Finland
Skipping to change at page 48, line 8:
Appendix A. Acknowledgements		Appendix A. Acknowledgements
The authors would like to thank Greg O'Shea, Michael Thomas, Kevin		The authors would like to thank Greg O'Shea, Michael Thomas, Kevin
Miles, Cheryl Madson, Bernard Aboba, Erik Nordmark, Gabriel		Miles, Cheryl Madson, Bernard Aboba, Erik Nordmark, Gabriel
Montenegro, Steven Kent, and Santeri Paavolainen for interesting		Montenegro, Steven Kent, and Santeri Paavolainen for interesting
discussions in this problem space.		discussions in this problem space.
Appendix B. Changes from Previous Version		Appendix B. Changes from Previous Version
The following changes have been made to this document from version		The following changes have been made to this document from version
04:		05:
o Implications for Bumb-in-the-Stack implementations have been more
extensively discussed (tracked issue 307).
o The required policy checks for protecting return routability
packets have been clarified; the language now allows different
implementations as long as the end result is the same (tracked
issue 306).
o The required IPsec SPD checks have been clarified. While it is
required that policy checks be based on the home address (from the
Home Address destination option), this does not imply a change in
the IPsec SPD entries. Instead, this is a mere processing order
issue (tracked issue 292).
o Justifications have been added to explain why return routability
packets require protection (tracked issue 292).
o The precise meaning of "inactive" SPD entries and SAs has been
clarified (tracked issue 292).
o The IKE text has been made more precise with respect to the IKE
version the text applies to (tracked issue 292).
o "Manual keying" has been clarified to mean manually created IPsec
security associations, not the configuration of preshared secret
in IKE (tracked issue 296).
o Most of AH discussion has been left out from the document, and
replaced with a note in the introduction (tracked issue 296).
o Section 7 no longer recommends replacing routers in the face of
certificate fragmentation problems (tracked issue 287).
o The draft now explains the background for the decision to use
care-of addresses as the source address for IKE and in the tunnel
packets from the mobile node (tracked issue 284).
o The draft now explains that the decision to use care-of addresses
in IKE implies that shared secrets cannot be used with Main Mode
even where a static (home) address is available (tracked issue
284).
o The draft now explains where the API between the IPsec and the
Mobile IPv6 should and should not be used (tracked issue 284).
o The draft clarifies now the requirements with respect to the use		o It has been clarified that, as required by the base specification,
of IPsec tunnel mode versus the use of IP-in-IP encapsulation		the Home Address destination option and type 2 Routing header
(tracked issue 284).		affect policy checks only with respect to the nodes that are the
		original senders or final receivers of the packet (tracked issue
		319).
		o Text regarding other protocols than IKEv1 has been aligned with
		the text in the base specification, which does not claim treatment
		of the issues beyond IKEv1 (tracked issue 319).
o The draft clarifies the implications of either using or not using		o This document no longer references draft-touch-ipsec-vpn (tracked
IKE (tracked issue 282).		issue 312).
o Some editorial modifications have been performed (tracked issues		o The replay protection requirements of this document have been
287 and 292).		clarified (tracked issue 311).
Intellectual Property Statement		Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to		intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it		might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the		has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and		IETF's procedures with respect to rights in standards-track and