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 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 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 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 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 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 MUST be o Similarly, a home address within a Type 2 Routing header destined
considered as the destination address of the packet, when a packet to the receiving node is considered as the destination address of
is matched against IPsec security policy or selectors of a the packet, when a packet is matched against IPsec security policy
security association. or selectors of a 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 skipping to change at page 16, line 9
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 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 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 skipping to change at page 47, 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 o It has been clarified that, as required by the base specification,
Mobile IPv6 should and should not be used (tracked issue 284). the Home Address destination option and type 2 Routing header
affect policy checks only with respect to the nodes that are the
original senders or final receivers of the packet (tracked issue
319).
o The draft clarifies now the requirements with respect to the use o Text regarding other protocols than IKEv1 has been aligned with
of IPsec tunnel mode versus the use of IP-in-IP encapsulation the text in the base specification, which does not claim treatment
(tracked issue 284). 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
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/