< draft-ietf-mobileip-mipv6-ha-ipsec-04.txt   draft-ietf-mobileip-mipv6-ha-ipsec-05.txt >
Network Working Group J. Arkko Network Working Group J. Arkko
Internet-Draft Ericsson Internet-Draft Ericsson
Expires: September 18, 2003 V. Devarapalli Expires: November 24, 2003 V. Devarapalli
Nokia Research Center Nokia Research Center
F. Dupont F. Dupont
ENST Bretagne ENST Bretagne
March 20, 2003 May 26, 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-04.txt draft-ietf-mobileip-mipv6-ha-ipsec-05.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 September 18, 2003. This Internet-Draft will expire on November 24, 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 2, line 13 skipping to change at page 2, line 13
implementations can process the packets in the right order. implementations can process the packets in the right order.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 8 3. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 8
3.1 Binding Updates and Acknowledgements . . . . . . . . . 8 3.1 Binding Updates and Acknowledgements . . . . . . . . . 8
3.2 Return Routability Signaling . . . . . . . . . . . . . 9 3.2 Return Routability Signaling . . . . . . . . . . . . . 9
3.3 Prefix Discovery . . . . . . . . . . . . . . . . . . . 10 3.3 Prefix Discovery . . . . . . . . . . . . . . . . . . . 10
3.4 Payload Packets . . . . . . . . . . . . . . . . . . . 10 3.4 Payload Packets . . . . . . . . . . . . . . . . . . . 11
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1 Mandatory Support . . . . . . . . . . . . . . . . . . 12 4.1 Mandatory Support . . . . . . . . . . . . . . . . . . 12
4.2 Policy Requirements . . . . . . . . . . . . . . . . . 12 4.2 Policy Requirements . . . . . . . . . . . . . . . . . 12
4.3 IPsec Protocol Processing . . . . . . . . . . . . . . 14 4.3 IPsec Protocol Processing . . . . . . . . . . . . . . 15
4.4 Dynamic Keying . . . . . . . . . . . . . . . . . . . . 16 4.4 Dynamic Keying . . . . . . . . . . . . . . . . . . . . 17
5. Example Configurations . . . . . . . . . . . . . . . . . . . 18 5. Example Configurations . . . . . . . . . . . . . . . . . . . 19
5.1 Format . . . . . . . . . . . . . . . . . . . . . . . . 18 5.1 Format . . . . . . . . . . . . . . . . . . . . . . . . 19
5.2 Manual Configuration . . . . . . . . . . . . . . . . . 19 5.2 Manual Configuration . . . . . . . . . . . . . . . . . 20
5.2.1 Binding Updates and Acknowledgements . . . . . . 19 5.2.1 Binding Updates and Acknowledgements . . . . . . 20
5.2.2 Return Routability Signaling . . . . . . . . . . 20 5.2.2 Return Routability Signaling . . . . . . . . . . 21
5.2.3 Prefix Discovery . . . . . . . . . . . . . . . . 21 5.2.3 Prefix Discovery . . . . . . . . . . . . . . . . 22
5.2.4 Payload Packets . . . . . . . . . . . . . . . . 22 5.2.4 Payload Packets . . . . . . . . . . . . . . . . 23
5.3 Dynamic Keying . . . . . . . . . . . . . . . . . . . . 24 5.3 Dynamic Keying . . . . . . . . . . . . . . . . . . . . 25
5.3.1 Binding Updates and Acknowledgements . . . . . . 24 5.3.1 Binding Updates and Acknowledgements . . . . . . 25
5.3.2 Return Routability Signaling . . . . . . . . . . 25 5.3.2 Return Routability Signaling . . . . . . . . . . 26
5.3.3 Prefix Discovery . . . . . . . . . . . . . . . . 26 5.3.3 Prefix Discovery . . . . . . . . . . . . . . . . 27
5.3.4 Payload Packets . . . . . . . . . . . . . . . . 26 5.3.4 Payload Packets . . . . . . . . . . . . . . . . 27
6. Processing Steps within a Node . . . . . . . . . . . . . . . 28 6. Processing Steps within a Node . . . . . . . . . . . . . . . 29
6.1 Binding Update to the Home Agent . . . . . . . . . . . 28 6.1 Binding Update to the Home Agent . . . . . . . . . . . 29
6.2 Binding Update from the Mobile Node . . . . . . . . . 29 6.2 Binding Update from the Mobile Node . . . . . . . . . 30
6.3 Binding Acknowledgement to the Mobile Node . . . . . . 29 6.3 Binding Acknowledgement to the Mobile Node . . . . . . 31
6.4 Binding Acknowledgement from the Home Agent . . . . . 30 6.4 Binding Acknowledgement from the Home Agent . . . . . 32
6.5 Home Test Init to the Home Agent . . . . . . . . . . . 31 6.5 Home Test Init to the Home Agent . . . . . . . . . . . 32
6.6 Home Test Init from the Mobile Node . . . . . . . . . 32 6.6 Home Test Init from the Mobile Node . . . . . . . . . 33
6.7 Home Test to the Mobile Node . . . . . . . . . . . . . 32 6.7 Home Test to the Mobile Node . . . . . . . . . . . . . 33
6.8 Home Test from the Home Agent . . . . . . . . . . . . 33 6.8 Home Test from the Home Agent . . . . . . . . . . . . 34
6.9 Prefix Solicitation Message to the Home Agent . . . . 33 6.9 Prefix Solicitation Message to the Home Agent . . . . 35
6.10 Prefix Solicitation Message from the Mobile Node . . . 33 6.10 Prefix Solicitation Message from the Mobile Node . . . 35
6.11 Prefix Advertisement Message to the Mobile Node . . . 33 6.11 Prefix Advertisement Message to the Mobile Node . . . 35
6.12 Prefix Advertisement Message from the Home Agent . . . 34 6.12 Prefix Advertisement Message from the Home Agent . . . 35
6.13 Payload Packet to the Home Agent . . . . . . . . . . . 34 6.13 Payload Packet to the Home Agent . . . . . . . . . . . 35
6.14 Payload Packet from the Mobile Node . . . . . . . . . 34 6.14 Payload Packet from the Mobile Node . . . . . . . . . 35
6.15 Payload Packet to the Mobile Node . . . . . . . . . . 34 6.15 Payload Packet to the Mobile Node . . . . . . . . . . 35
6.16 Payload Packet from the Home Agent . . . . . . . . . . 34 6.16 Payload Packet from the Home Agent . . . . . . . . . . 35
6.17 Establishing New Security Associations . . . . . . . . 34 6.17 Establishing New Security Associations . . . . . . . . 35
6.18 Rekeying Security Associations . . . . . . . . . . . . 35 6.18 Rekeying Security Associations . . . . . . . . . . . . 36
6.19 Movements and Dynamic Keying . . . . . . . . . . . . . 36 6.19 Movements and Dynamic Keying . . . . . . . . . . . . . 37
7. Implementation Considerations . . . . . . . . . . . . . . . 38 7. Implementation Considerations . . . . . . . . . . . . . . . 39
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 40 7.1 IPsec . . . . . . . . . . . . . . . . . . . . . . . . 39
9. Security Considerations . . . . . . . . . . . . . . . . . . 41 7.2 IKE . . . . . . . . . . . . . . . . . . . . . . . . . 40
Normative References . . . . . . . . . . . . . . . . . . . . 42 7.3 Bump-in-the-Stack . . . . . . . . . . . . . . . . . . 40
Informative References . . . . . . . . . . . . . . . . . . . 43 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 43 9. Security Considerations . . . . . . . . . . . . . . . . . . 43
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44 Normative References . . . . . . . . . . . . . . . . . . . . 44
B. Changes from Previous Version . . . . . . . . . . . . . . . 45 Informative References . . . . . . . . . . . . . . . . . . . 45
Intellectual Property and Copyright Statements . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 45
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 47
B. Changes from Previous Version . . . . . . . . . . . . . . . 48
Intellectual Property and Copyright Statements . . . . . . . 50
1. Introduction 1. Introduction
This document illustrates the use of IPsec in securing control This document illustrates the use of IPsec in securing Mobile IPv6
traffic relating to Mobile IPv6 [8]. In Mobile IPv6, a mobile node [8] traffic between mobile nodes and home agents. In Mobile IPv6, a
is always expected to be addressable at its home address, whether it mobile node is always expected to be addressable at its home address,
is currently attached to its home link or is away from home. The whether it is currently attached to its home link or is away from
"home address" is an IP address assigned to the mobile node within home. The "home address" is an IP address assigned to the mobile
its home subnet prefix on its home link. While a mobile node is at node within its home subnet prefix on its home link. While a mobile
home, packets addressed to its home address are routed to the mobile node is at home, packets addressed to its home address are routed to
node's home link. the mobile node's home link.
While a mobile node is attached to some foreign link away from home, While a mobile node is attached to some foreign link away from home,
it is also addressable at a care-of addresses. A care-of address is it is also addressable at a care-of addresses. A care-of address is
an IP address associated with a mobile node that has the subnet an IP address associated with a mobile node that has a subnet prefix
prefix of a particular foreign link. The association between a from a particular foreign link. The association between a mobile
mobile node's home address and care-of address is known as a node's home address and care-of address is known as a "binding" for
"binding" for the mobile node. While away from home, a mobile node the mobile node. While away from home, a mobile node registers its
registers its primary care-of address with a router on its home link, primary care-of address with a router on its home link, requesting
requesting this router to function as the "home agent" for the mobile this router to function as the "home agent" for the mobile node. The
node. The mobile node performs this binding registration by sending mobile node performs this binding registration by sending a "Binding
a "Binding Update" message to the home agent. The home agent replies Update" message to the home agent. The home agent replies to the
to the mobile node by returning a "Binding Acknowledgement" message. mobile node by returning a "Binding Acknowledgement" message.
Any other nodes communicating with a mobile node are referred to as Any other nodes communicating with a mobile node are referred to as
"correspondent nodes". Mobile nodes can provide information about "correspondent nodes". Mobile nodes can provide information about
their current location to correspondent nodes, again using Binding their current location to correspondent nodes, again using Binding
Updates and Acknowledgements. Additionally, return routability test Updates and Acknowledgements. Additionally, return routability test
is performed between the mobile node, home agent, and the is performed between the mobile node, home agent, and the
correspondent node in order to authorize the establishment of the correspondent node in order to authorize the establishment of the
binding. Packets between the mobile node and the correspondent node binding. Packets between the mobile node and the correspondent node
are either tunneled via the home agent, or sent directly if a binding are either tunneled via the home agent, or sent directly if a binding
exists in the correspondent node for the current location of the exists in the correspondent node for the current location of the
skipping to change at page 4, line 52 skipping to change at page 4, line 52
replaced by IPsec tunnels [2]. replaced by IPsec tunnels [2].
Mobile IPv6 also provides support for the reconfiguration of the home Mobile IPv6 also provides support for the reconfiguration of the home
network. Here the home subnet prefixes may change over time. Mobile network. Here the home subnet prefixes may change over time. Mobile
nodes can learn new information about home subnet prefixes through nodes can learn new information about home subnet prefixes through
the "prefix discovery" mechanism. the "prefix discovery" mechanism.
This document discusses security mechanisms for the control traffic This document discusses security mechanisms for the control traffic
between the mobile node and the home agent. If this traffic is not between the mobile node and the home agent. If this traffic is not
protected, mobile nodes and correspondent nodes are vulnerable to protected, mobile nodes and correspondent nodes are vulnerable to
Man-in-the-Middle, Hijacking, Confidentiality, Impersonation, and man-in-the-middle, hijacking, passive wiretapping, impersonation, and
Denial-of-Service attacks. Any third parties are also vulnerable to denial-of-service attacks. Any third parties are also vulnerable to
Denial-of-Service attacks. These threats are discussed in more denial-of-service attacks, for instance if an attacker could direct
detail in Section 15.1 of the Mobile IPv6 base specification [8]. the traffic flowing through the home agent to a innocent third party.
These attacks are discussed in more detail in Section 15.1 of the
Mobile IPv6 base specification [8].
In order to avoid these attacks, the base specification uses IPsec In order to avoid these attacks, the base specification uses IPsec
[2] to protect control traffic between the home agent and the mobile Encapsulating Security Payload (ESP) [4] to protect control traffic
node. This control traffic consists of various messages carried by between the home agent and the mobile node. This control traffic
the Mobility Header protocol in IPv6 [6]. The traffic takes the consists of various messages carried by the Mobility Header protocol
following forms: in IPv6 [6]. The traffic takes the following forms:
o Binding Update and Acknowledgement messages exchanged between the o Binding Update and Acknowledgement messages exchanged between the
mobile node and the home agent, as described in Sections 10.3.1, mobile node and the home agent, as described in Sections 10.3.1,
10.3.2, 11.7.1, and 11.7.3 of the base specification [8]. 10.3.2, 11.7.1, and 11.7.3 of the base specification [8].
o Return routability messages Home Test Init and Home Test that pass o Return routability messages Home Test Init and Home Test that pass
through the home agent on their way to a correspondent node, as through the home agent on their way to a correspondent node, as
described in Section 10.4.6 of the base specification [8]. described in Section 10.4.6 of the base specification [8].
o ICMPv6 messages exchanged between the mobile node and the home o ICMPv6 messages exchanged between the mobile node and the home
skipping to change at page 5, line 34 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
replay protection. The mobile node and the home agent must have a optional anti-replay protection. The mobile node and the home agent
security association to protect this traffic. Furthermore, great must have a security association to protect this traffic. In
care is needed when using IKE [5] to establish security associations addition, Mobile IPv6 messages assist in ensuring correct ordering,
to Mobile IPv6 home agents. The right kind of addresses must be used as IPsec can only provide protection against replayed messages. Full
for transporting IKE. This is necessary to avoid circular protection against replay and ordering attacks is possible only when
dependencies in which the use of a Binding Update triggers the need IKE is used, however.
for an IKE exchange that cannot complete prior to the Binding Update
having been completed. Great care is needed when using IKE [5] to establish security
associations to Mobile IPv6 home agents. The right kind of addresses
must be used for transporting IKE. This is necessary to avoid
circular dependencies in which the use of a Binding Update triggers
the need for an IKE exchange that cannot complete prior to the
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
traffic. This document discusses these requirements in more depth, traffic. This document discusses these requirements in more depth,
illustrates the used packet formats, describes suitable configuration illustrates the used packet formats, describes suitable configuration
procedures, and shows how implementations can process the packets in procedures, and shows how implementations can process the packets in
the right order. the right order.
We begin our description by showing the required wire formats for the We begin our description by showing the required wire formats for the
protected packets in Section 3. Section 4 describes rules which protected packets in Section 3. Section 4 describes rules which
associated Mobile IPv6, IPsec, and IKE implementations must observe. associated Mobile IPv6, IPsec, and IKE implementations must observe.
Section 5 discusses how IPsec can be configured to use either manual Section 5 discusses how to configure either manually keyed IPsec
or automatically established security associations. Section 6 shows security associations or how to configure IKE to establish them
examples of how packets are processed within the nodes. automatically. Section 6 shows examples of how packets are processed
within the nodes.
All implementations of Mobile IPv6 mobile node and home agent MUST All implementations of Mobile IPv6 mobile node and home agent MUST
support at least the formats described in Section 3 and obey the support at least the formats described in Section 3 and obey the
rules in Section 4. The configuration and processing sections are rules in Section 4. Note that in addition to the use of ESP as
informative, and should only be considered as one possible way of specified here, it may also be possible to use Authentication Header
providing the required functionality. (AH) [3], but for brevity this is not discussed in this
specification.
The configuration and processing sections are informative, and should
only be considered as one possible way of providing the required
functionality.
Note that where this document indicates a feature MUST be supported
and SHOULD be used, this implies that all implementations must be
capable of using the specified feature, but there may be cases where,
for instance, a configuration option disables to use of the feature
in a particular situation.
2. Terminology 2. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The keywords "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 RFC 2119 [1]. document are to be interpreted as described in RFC 2119 [1].
3. Packet Formats 3. Packet Formats
3.1 Binding Updates and Acknowledgements 3.1 Binding Updates and Acknowledgements
When the mobile node is away from its home, the BUs sent by it to the When the mobile node is away from its home, the BUs sent by it to the
home agent MUST support at least the following headers in the home agent MUST support at least the following headers in the
following order: following order:
IPv6 header (source = care-of address, IPv6 header (source = care-of address,
destination = home agent) destination = home agent)
Destination Options header Destination Options header
Home Address option (home address) Home Address option (home address)
ESP header ESP header in transport mode
Mobility header Mobility header
Binding Update Binding Update
Alternate Care-of Address option (care-of address) Alternate Care-of Address option (care-of address)
Note that the Alternate Care-of Address option is used to ensure that Note that the Alternate Care-of Address option is used to ensure that
the care-of address is protected by ESP. The home agent considers the care-of address is protected by ESP. The home agent considers
the address within this option as the current care-of address for the the address within this option as the current care-of address for the
mobile node. mobile node. The home address is not protected by ESP directly, but
the use of a specific home address with a specific security
association is required by policy.
The Binding Acknowledgements sent back to the mobile node when it is The Binding Acknowledgements sent back to the mobile node when it is
away from home MUST support at least the following headers in the away from home MUST support at least the following headers in the
following order: following order:
IPv6 header (source = home agent, IPv6 header (source = home agent,
destination = care-of address) destination = care-of address)
Routing header (type 2) Routing header (type 2)
home address home address
ESP header ESP header in transport mode
Mobility header Mobility header
Binding Acknowledgement Binding Acknowledgement
When the mobile node is at home, the above rules are different as the When the mobile node is at home, the above rules are different as the
mobile node can use its home address as a source address. This mobile node can use its home address as a source address. This
typically happens for the de-registration Binding Update when the typically happens for the de-registration Binding Update when the
mobile is returning home. In this situation, the Binding Updates mobile is returning home. In this situation, the Binding Updates
MUST support at least the following headers in the following order: MUST support at least the following headers in the following order:
IPv6 header (source = home address, IPv6 header (source = home address,
destination = home agent) destination = home agent)
ESP header ESP header in transport mode
Mobility header Mobility header
Binding Update Binding Update
The Binding Acknowledgement messages sent to the home address MUST The Binding Acknowledgement messages sent to the home address MUST
support at least the following headers in the following order: support at least the following headers in the following order:
IPv6 header (source = home agent, IPv6 header (source = home agent,
destination = home address) destination = home address)
ESP header ESP header in transport mode
Mobility header Mobility header
Binding Acknowledgement Binding Acknowledgement
3.2 Return Routability Signaling 3.2 Return Routability Signaling
When the Home Test Init messages tunneled to the home agent are When the Home Test Init messages tunneled to the home agent are
protected by IPsec, they MUST support at least the following headers protected by IPsec, they MUST support at least the following headers
in the following order: in the following order:
IPv6 header (source = care-of address, IPv6 header (source = care-of address,
destination = home agent) destination = home agent)
ESP header ESP header in tunnel mode
IPv6 header (source = home address, IPv6 header (source = home address,
destination = correspondent node) destination = correspondent node)
Mobility Header Mobility Header
Home Test Init Home Test Init
This format assumes that the mobile node's current care-of address is This format assumes that the mobile node's current care-of address is
used as one of the gateway addresses in the security association. As used as the outer header destination address in the security
discussed in Section 4.3, this requires the home agent to update the association. As discussed in Section 4.3, this requires the home
gateway address when the mobile node moves. Policy entries and agent to update the destination address when the mobile node moves.
security association selectors stay the same, however, as the inner Policy entries and security association selectors stay the same,
packets do not change upon movements. however, as the inner packets do not change upon movements.
Note that there are trade-offs in using care-of addresses as the
destination addresses versus using the home address and attaching an
additional Home Address destination option and/or Routing header to
the packets. The basis for requiring support for at least the
care-of address case has been discussed in Section 7.
Similarly, when the Home Test messages tunneled from the home agent Similarly, when the Home Test messages tunneled from the home agent
are protected by IPsec, they MUST support at least the following are protected by IPsec, they MUST support at least the following
headers in the following order: headers in the following order:
IPv6 header (source = home agent, IPv6 header (source = home agent,
destination = care-of address) destination = care-of address)
ESP header ESP header in tunnel mode
IPv6 header (source = correspondent node, IPv6 header (source = correspondent node,
destination = home address) destination = home address)
Mobility Header Mobility Header
Home Test Home Test
The format used to protect return routability packets relies on the The format used to protect return routability packets relies on the
destination of the tunnel packets to change for the mobile node as it destination of the tunnel packets to change for the mobile node as it
moves. The home agent's address stays the same, but the mobile moves. The home agent's address stays the same, but the mobile
node's address changes upon movements, as if the security node's address changes upon movements, as if the security
association's tunnel gateway address had changed. When the mobile association's outer header destination address had changed. When the
node adopts a new care-of address, its source address selection rules mobile node adopts a new care-of address, it adopts also a new source
will automatically adopt a new source address for outgoing tunnel address for outgoing tunnel packets. The home agent accepts packets
packets. (The home agent accepts packets sent like this, as the sent like this, as the outer source address in tunnel packets is not
outer source address in tunnel packets is not checked.) checked according to the rules in RFC 2401. (We note, however, that
some implementations are known to make source address checks.) For a
discussion of the role of source addresses in outer tunnel headers,
see Section 5.1.2.1 of RFC 2401 [2]. Note also that the home agent
requires the packets to be authenticated regardless of the source
address change, hence the "new" sender must possess the same keys for
the security association as the it had in the previous location.
This proves that the sender is the same entity, regardless of the
changes in the addresses.
The process is more complicated in the home agent side, as the home The process is more complicated in the home agent side, as the home
agent has stored the previous care-of address in its Security agent has stored the previous care-of address in its Security
Association Database as the gateway address. When IKE is being used, Association Database as the outer header destination address. When
the mobile node runs it on top of its then current care-of address, IKE is being used, the mobile node runs it on top of its current
and the resulting tunnel-mode security associations will use the same care-of address, and the resulting tunnel-mode security associations
addresses as IKE was transported on. In order for the home agent to will use the same addresses as IKE run over. In order for the home
be able to tunnel a Home Test message to the mobile node, it uses the agent to be able to tunnel a Home Test message to the mobile node, it
current care-of address as the destination of the tunnel packets, as uses the current care-of address as the destination of the tunnel
if the home agent had modified the gateway address of the security packets, as if the home agent had modified the outer header
association used for this protection. This implies that the same destination address in the security association used for this
security association can be used in multiple locations, and no new protection. This implies that the same security association can be
configuration or IKE rekeying is needed per movement. used in multiple locations, and no new configuration or
re-establishment of IKE phases is needed per movement. Section 5.2.2
discusses the security policy and security association database
entries that are needed to accomplish this.
3.3 Prefix Discovery 3.3 Prefix Discovery
If IPsec is used to protect prefix discovery, requests for prefixes If IPsec is used to protect prefix discovery, requests for prefixes
from the mobile node to the home agent MUST support at least the from the mobile node to the home agent MUST support at least the
following headers in the following order. following headers in the following order.
IPv6 header (source = care-of address, IPv6 header (source = care-of address,
destination = home agent) destination = home agent)
Destination Options header Destination Options header
Home Address option (home address) Home Address option (home address)
ESP header ESP header in transport mode
ICMPv6 ICMPv6
Mobile Prefix Solicitation Mobile Prefix Solicitation
Again if IPsec is used, solicited and unsolicited prefix information Again if IPsec is used, solicited and unsolicited prefix information
advertisements from the home agent to the mobile node MUST support at advertisements from the home agent to the mobile node MUST support at
least the following headers in the following order. least the following headers in the following order.
IPv6 header (source = home agent, IPv6 header (source = home agent,
destination = care-of address) destination = care-of address)
Routing header (type 2) Routing header (type 2)
home address home address
ESP header ESP header in transport mode
ICMPv6 ICMPv6
Mobile Prefix Advertisement Mobile Prefix Advertisement
3.4 Payload Packets 3.4 Payload Packets
If IPsec is used to protect payload packets tunneled to the home If IPsec is used to protect payload packets tunneled to the home
agent from the mobile node, a similar format is used as in the case agent from the mobile node, a similar format is used as in the case
of tunneled Home Test Init messages. However, instead of the of tunneled Home Test Init messages. However, instead of the
Mobility Header these packets may contain any legal IPv6 protocol(s): Mobility Header these packets may contain any legal IPv6 protocol(s):
IPv6 header (source = care-of address, IPv6 header (source = care-of address,
destination = home agent) destination = home agent)
ESP header ESP header in tunnel mode
IPv6 header (source = home address, IPv6 header (source = home address,
destination = correspondent node) destination = correspondent node)
Any protocol Any protocol
Similarly, when the payload packets are tunneled from the home agent Similarly, when the payload packets are tunneled from the home agent
to the mobile node with IPsec protection, they MUST support at least to the mobile node with ESP encapsulation, they MUST support at least
the following headers in the following order: the following headers in the following order:
IPv6 header (source = home agent, IPv6 header (source = home agent,
destination = care-of address) destination = care-of address)
ESP header ESP header in tunnel mode
IPv6 header (source = correspondent node, IPv6 header (source = correspondent node,
destination = home address) destination = home address)
Any protocol Any protocol
4. Requirements 4. Requirements
This section describes mandatory rules for all Mobile IPv6 mobile This section describes mandatory rules for all Mobile IPv6 mobile
nodes and home agents. These rules are necessary in order for it to nodes and home agents. These rules are necessary in order for it to
be possible to enable IPsec communications despite movements, be possible to enable IPsec communications despite movements,
guarantee sufficient security, and to ensure correct processing order guarantee sufficient security, and to ensure correct processing order
skipping to change at page 12, line 22 skipping to change at page 12, line 22
The rules in the following sections apply only to the communications The rules in the following sections apply only to the communications
between home agents and mobile nodes. They should not be taken as between home agents and mobile nodes. They should not be taken as
requirements on how IPsec in general is used by mobile nodes. requirements on how IPsec in general is used by mobile nodes.
4.1 Mandatory Support 4.1 Mandatory Support
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 security associations MUST be supported. o Manual configuration of IPsec security associations MUST be
The configuration of the keys is expected to take place supported. The configuration of the keys is expected to take
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, even if it is expected that
the next version of IKE can also be used and that it offers the next version of IKE can also be used and that it offers
several improvements in this specific application. several improvements in this specific application.
o IPsec protection for 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 IPsec protection for 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 IPsec protection for 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.
o IPsec protection of the payload packets tunneled between the o ESP encapsulation of the payload packets tunneled between the
mobile node and home agent MAY be supported and used. mobile node and home agent MAY be supported and used.
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 When a packet 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 MUST be considered as the source
address of the packet. address of the packet.
Note that the home address option appears before IPsec headers.
Section 11.3.2 of the base specification [8] describes one
possible implementation approach for this: The IPsec policy
operations can be performed at the time when the packet has not
yet been modified per Mobile IPv6 rules, or has been brought back
to its normal form after Mobile IPv6 processing. That is, the
processing of the Home Address option is seen as a fixed
transformation of the packets that does not affect IPsec
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 MUST be
considered as the destination address of the packet, when a packet considered as the destination address of the packet, when a packet
is matched against IPsec security policy or selectors of a is matched against IPsec security policy or selectors of a
security association. security association.
Similar implementation considers apply to the Routing header
processing as was described above for the Home Address destination
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, the security policy database entries SHOULD be payload packets, this protection MUST only be applied to the
defined specifically for the tunnel interface between the mobile return routability packets entering the IPv6 encapsulated tunnel
node and the home agent. That is, the policy entries are not interface between the mobile node and the home agent. This can be
generally applied on all traffic on the physical interface(s) of achieved, for instance, by defining the security policy database
the nodes, but rather only on traffic that enters this tunnel. entries specifically for the tunnel interface. That is, the
policy entries are not generally applied on all traffic on the
physical interface(s) of the nodes, but rather only on traffic
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.
o When the mobile node returns home and de-registers with the Home o When the mobile node returns home and de-registers with the Home
Agent, the tunnel between the home agent and the mobile node's Agent, the tunnel between the home agent and the mobile node's
care-of address is torn down. The SPD entries, which were used care-of address is torn down. The security policy entries, which
for protecting tunneled traffic between the mobile node and the were used for protecting tunneled traffic between the mobile node
home agent become inactive. The corresponding security and the home agent MUST be made inactive (for instance, by
associations could be stored or deleted depending on how they were removing them and installing them back later through an API). The
created. If the security associations were created dynamically corresponding security associations could be kept as they are or
using IKE, they are automatically deleted when they expire. If deleted depending on how they were created. If the security
the security associations were created through manual associations were created dynamically using IKE, they are
configuration, they MUST be retained and used later when the automatically deleted when they expire. If the security
mobile node moves aways from home again. The security associations were created through manual configuration, they MUST
associations protecting Binding Updates and Acknowledgements, and be retained and used later when the mobile node moves aways from
prefix discovery SHOULD not be deleted as they do not depend on home again. The security associations protecting Binding Updates
care-of addresses and can be used again. and Acknowledgements, and prefix discovery SHOULD NOT be deleted
as they do not depend on care-of addresses and can be used again.
The following rules apply to mobile nodes: The following rules apply to mobile nodes:
o The mobile node MUST use the Home Address destination option in o The mobile node MUST use the Home Address destination option in
Binding Updates and Mobile Prefix Solicitations, sent to the home Binding Updates and Mobile Prefix Solicitations, sent to the home
agent from a care-of address. agent from a care-of address.
o When the mobile node receives a changed set of prefixes from the o When the mobile node receives a changed set of prefixes from the
home agent during prefix discovery, there is a need to configure home agent during prefix discovery, there is a need to configure
new security policy entries, and there may be a need to configure new security policy entries, and there may be a need to configure
skipping to change at page 14, line 23 skipping to change at page 14, line 44
o The home agent MUST use the Type 2 Routing header in Binding o The home agent MUST use the Type 2 Routing header in Binding
Acknowledgements and Mobile Prefix Advertisements sent to the Acknowledgements and Mobile Prefix Advertisements sent to the
mobile node, again due to the need to have the home address mobile node, again due to the need to have the home address
visible when the policy checks are made. visible when the policy checks are made.
o It is necessary to avoid the possibility that a mobile node could o It is necessary to avoid the possibility that a mobile node could
use its security association to send a Binding Update on behalf of use its security association to send a Binding Update on behalf of
another mobile node using the same home agent. In order to do another mobile node using the same home agent. In order to do
this, the security policy database entries MUST unequivocally this, the security policy database entries MUST unequivocally
identify a single security association for any given home address identify a single security association for protecting Binding
and home agent when manual keying is used. When dynamic keying is Updates between any given home address and home agent when
used, the security policy database entries MUST unequivocally manually keyed IPsec security associations are used. When dynamic
identify the IKE phase 1 credentials which can be used to keying is used, the security policy database entries MUST
authorize the creation of security associations for a particular unequivocally identify the IKE phase 1 credentials which can be
home address. How these mappings are maintained is outside the used to authorize the creation of security associations for
scope of this specification, but they may be maintained, for protecting Binding Updates for a particular home address. How
instance, as a locally administered table in the home agent. If these mappings are maintained is outside the scope of this
the phase 1 identity is a FQDN, secure forms of DNS may also be specification, but they may be maintained, for instance, as a
used. locally administered table in the home agent. If the phase 1
identity is a Fully Qualified Domain Name (FQDN), secure forms of
DNS may also be used.
o When the set of prefixes advertised by the home agent changes, o When the set of prefixes advertised by the home agent changes,
there is a need to configure new security policy entries, and there is a need to configure new security policy entries, and
there may be a need to configure new security associations. It is there may be a need to configure new security associations. It is
outside the scope of this specification to discuss automatic outside the scope of this specification to discuss automatic
methods for this, if new home addresses are required. methods for this, if new home addresses are required.
4.3 IPsec Protocol Processing 4.3 IPsec Protocol Processing
The following requirements apply to both home agents and mobile The following requirements apply to both home agents and mobile
nodes: nodes:
o When securing Binding Updates, Binding Acknowledgements, and o When securing Binding Updates, Binding Acknowledgements, and
prefix discovery, both the mobile nodes and the home agents SHOULD prefix discovery, both the mobile nodes and the home agents MUST
use the Encapsulating Security Payload (ESP) [4] header in support and SHOULD use the Encapsulating Security Payload (ESP)
transport mode and MUST use a non-null payload authentication [4] header in transport mode and MUST use a non-null payload
algorithm to provide data origin authentication, connectionless authentication algorithm to provide data origin authentication,
integrity and optional anti-replay protection. Note that connectionless integrity and optional anti-replay protection.
Authentication Header (AH) [3] is also possible but for brevity is
not discussed in this specification.
Mandatory support for encryption and integrity protection Mandatory support for encryption and integrity protection
algorithms is as defined in RFC 2401 [2], RFC 2402 [3], and RFC algorithms is as defined in RFC 2401 [2], RFC 2402 [3], and RFC
2406 [4]. Care is needed when selecting suitable encryption 2406 [4]. Care is needed when selecting suitable encryption
algorithms for ESP, however. Currently available integrity algorithms for ESP, however. Currently available integrity
protection algorithms are in general considered to be secure. The protection algorithms are in general considered to be secure. The
encryption algorithm, DES, mandated by the current IPsec standards encryption algorithm, DES, mandated by the current IPsec standards
is not, however. This is particularly problematic when security is not, however. This is particularly problematic when IPsec
associations are configured manually, as the same key is used for security associations are configured manually, as the same key is
a long time. used for a long time.
o Tunnel mode IPsec ESP MUST be supported and SHOULD be used for the o Tunnel mode IPsec ESP MUST be supported and SHOULD be used for the
protection of packets belonging to the return routability protection of packets belonging to the return routability
procedure. A non-null encryption transform and authentication procedure. A non-null encryption transform and a non-null
algorithm MUST be applied. authentication algorithm MUST be applied.
o IPsec AH [3] authenticator calculation MUST be performed as if a Note that the return routability procedure involves two message
packet with a Type 2 Routing header would have the home address in exchanges from the mobile node to the correspondent node. The
the IPv6 destination address field and the care-of address in the purpose of these exchanges is to assure that the mobile node is
Routing header. Type 2 Routing header should be treated by IPsec live at the claimed home and care-of addresses. One of the
in the same manner as Type 0 Routing header. exchanges is sent directly to and from the correspondent node,
while another one is tunneled through the home agent. If an
attacker is on the mobile node's link and the mobile node's
current link is an unprotected wireless link, the attacker would
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
specification [8]. One can prevent the attack by making sure that
the packets tunneled through the home agent are encrypted.
o Similarly, the authenticator calculation MUST be performed as if a Note that this specification concerns itself only with on-the-wire
packet with a Home Address destination option would have the home formats, and does not dictate specific implementations mechanisms.
address in the IPv6 source address field and the care-of address In the case of IPsec tunnel mode, the use of IP-in-IP
in the destination option. encapsulation followed by IPsec transport mode encapsulation may
also be possible. The trade-offs related to the use of tunnel
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. As a result, the attacker would have redirected the tampered with. As a result, the attacker would have redirected
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
Address mobility option in registrations sent to the home agent. Address mobility option in Binding Updates sent by mobile nodes
(Note that AH protects also the IPv6 header, and some while away from home. The exception to this is when the mobile
implementations might avoid the option if they know AH is being node returns home and sends a Binding Update to the home agent in
used.) order to de-register. In this case no Alternate Care-of Address
option is needed, as described in Section 3.1.
o When IPsec is used to protect return routability signaling or o When IPsec is used to protect return routability signaling or
payload packets, the mobile node MUST set the source address it payload packets, the mobile node MUST set the source address it
uses for the outgoing tunnel packets to the current primary uses for the outgoing tunnel packets to the current primary
care-of address. The mobile node starts to use a new primary care-of address. The mobile node starts to use a new primary
care-of address immediately after sending a Binding Update to the care-of address immediately after sending a Binding Update to the
home agent to register this new address. home agent to register this new address. Similarly, it starts to
use the new address as the required destination address of
tunneled packets received from the home agent.
The following rules apply to home agents: The following rules apply to home agents:
o When IPsec is used to protect return routability signaling or o When IPsec is used to protect return routability signaling or
payload packets, IPsec security associations are needed to provide payload packets, IPsec security associations are needed to provide
this protection. When the care-of address for the mobile node this protection. When the care-of address for the mobile node
changes as a result of an accepted Binding Update, special changes as a result of an accepted Binding Update, special
treatment is needed for the next packets sent using these security treatment is needed for the next packets sent using these security
associations. The home agent MUST set the new care-of address as associations. The home agent MUST set the new care-of address as
the destination address of these packets, as if the destination the destination address of these packets, as if the outer header
gateway address in the security association had changed. destination address in the security association had changed.
Similarly, the home agent starts to expect the new source address
in the tunnel packets received from the mobile node.
Such address changes can be implemented, for instance, through an
API from the Mobile IPv6 implementation to the IPsec
implementation. It should be noted that the use of such an API
and the address changes MUST only be done based on the Binding
Updates received by the home agent and protected by the use of
IPsec. Address modifications based on other sources, such as
Binding Updates to the correspondent nodes protected by return
routability, or open access to an API from any application may
result in security vulnerabilities.
4.4 Dynamic Keying 4.4 Dynamic Keying
The following requirements apply to both home agents and mobile The following requirements apply to both home agents and mobile
nodes: nodes:
o If replay protection is required, dynamic keying MUST be used. o If anti-replay protection is required, dynamic keying MUST be
IPsec can provide replay protection only if dynamic keying is used. IPsec can provide anti-replay protection only if dynamic
used. This may not always be possible, and manual keying would be keying is used (which may not always be the case). IPsec also
preferred in some cases. IPsec also does not guarantee correct does not guarantee correct ordering of packets, only that they
ordering of packets, only that they have not been replayed. have not been replayed. Because of this, sequence numbers within
Because of this, sequence numbers within the Mobile IPv6 messages the Mobile IPv6 messages are used to ensure correct ordering.
ensure correct ordering. However, if a home agent reboots and However, if the 16 bit Mobile IPv6 sequence number space is cycled
loses its state regarding the sequence numbers, replay attacks through, or the home agent reboots and loses its state regarding
become possible. The use of a key management mechanism together the sequence numbers, replay and reordering attacks become
with IPsec can be used to prevent such replay attacks. possible. The use of dynamic keying, IPsec anti-replay
protection, and the Mobile IPv6 sequence numbers can together
prevent such attacks.
o If IKE version 1 is used with preshared secrets in main mode, it o If IKE version 1 is used with preshared secrets in main mode, it
determines the shared secret to use from the IP address of the determines the shared secret to use from the IP address of the
peer. With Mobile IPv6, however, this may be a care-of address peer. With Mobile IPv6, however, this may be a care-of address
and does not indicate which mobile node attempts to contact the and does not indicate which mobile node attempts to contact the
home agent. Therefore, if preshared secret authentication is used home agent. Therefore, if preshared secret authentication is used
in IKEv1 between the mobile node and the home agent then in IKEv1 between the mobile node and the home agent then
aggressive mode MUST be used. Note also that care needs to be aggressive mode MUST be used. Note also that care needs to be
taken with phase 1 identity selection. Where the ID_IPV6_ADDR taken with phase 1 identity selection. Where the ID_IPV6_ADDR
Identity Payloads is used, unambiguous mapping of identities to Identity Payloads is used, unambiguous mapping of identities to
keys is not possible. (The next version of IKE may not have these keys is not possible. (The next version of IKE may not have these
limitations.) limitations.)
Note that the difficulties with main mode and preshared secrets in
IKE version 1 are well known for dynamic addresses. With static
addresses, there has not been a problem. With Mobile IPv6,
however, the use of the care-of addresses to run IKE to the home
agent presents a problem even when the home address stays stable.
Further discussion about the use of care-of addresses in this way
appears in Section 7.
The following rules apply to mobile nodes: The following rules apply to mobile nodes:
o Where dynamic keying is used, the key management protocol MUST use o In addition to the rules above, if dynamic keying is used, the key
the care-of address as the source address in the protocol management protocol MUST use the care-of address as the source
exchanges with the mobile node's home agent. address in the protocol exchanges with the mobile node's home
agent.
o Conversely, the IPsec security associations with the mobile node's o However, the IPsec security associations with the mobile node's
home agent MUST be requested from the key management protocol with home agent use home addresses. That is, the IPsec security
the home address as the mobile node's address. associations MUST be requested from the key management protocol
using the home address of the mobile node as the client identity.
The security associations for protecting Binding Updates and The security associations for protecting Binding Updates and
Acknowledgements are requested for the Mobility header protocol in Acknowledgements are requested for the Mobility header protocol in
transport mode and for specific IP addresses as endpoints. transport mode and for specific IP addresses as endpoints. No
Similarly, the security associations for protecting prefix other selectors are used. Similarly, the security associations
discovery are requested for the ICMPv6 protocol. Security for protecting prefix discovery are requested for the ICMPv6
associations for payload and return routability protection are protocol and the specific IP addresses, again without other
requested for a specific tunnel interface and either the payload selectors. Security associations for payload and return
protocol or the Mobility header protocol, in tunnel mode. In this routability protection are requested for a specific tunnel
case one requested endpoint is an IP address and another one is a interface and either the payload protocol or the Mobility header
wildcard. protocol, in tunnel mode. In this case one requested endpoint is
an IP address and the other one is a wildcard, and there are no
other selectors.
o If the mobile node has used IKE to establish security associations o If the mobile node has used IKE version 1 to establish security
with its home agent, it should follow the procedures discussed in associations with its home agent, it should follow the procedures
Section 11.7.1 and 11.7.3 of the base specification to determine discussed in Section 11.7.1 and 11.7.3 of the base specification
whether the IKE endpoints can be moved or if rekeying is needed. [8] to determine whether the IKE endpoints can be moved or if IKE
phase 1 has to be re-established.
The following rules apply to home agents: The following rules apply to home agents:
o If the home agent has used IKE to establish security associations o If the home agent has used IKE version 1 to establish security
with the mobile node, it should follow the procedures discussed in associations with the mobile node, it should follow the procedures
Section 10.3.1 and 10.3.2 of the base specification to determine discussed in Section 10.3.1 and 10.3.2 of the base specification
whether the IKE endpoints can be moved or if rekeying is needed. [8] to determine whether the IKE endpoints can be moved or if IKE
phase 1 has to be re-established.
5. Example Configurations 5. Example Configurations
In the following we describe the Security Policy Database (SPD) and In the following we describe the Security Policy Database (SPD) and
Security Association Database (SAD) entries necessary to protect Security Association Database (SAD) entries necessary to protect
Binding Updates and Binding Acknowledgements exchanged between the Binding Updates and Binding Acknowledgements exchanged between the
mobile node and the home agent. Our examples assume the use of ESP, mobile node and the home agent.
but a similar configuration could also be used to protect the
messages with AH.
Section 5.1 introduces the format we use in the description of the Section 5.1 introduces the format we use in the description of the
SPD and the SAD. Section 5.2 describes how to configure manually SPD and the SAD. Section 5.2 describes how to configure manually
keyed security associations, and Section 5.3 describes how to use keyed IPsec security associations without dynamic keying, and Section
dynamic keying. 5.3 describes how to use dynamic keying.
5.1 Format 5.1 Format
The format used in the examples is as follows. The SPD description The format used in the examples is as follows. The SPD description
has the format has the format
<node> "SPD OUT:" <node> "SPD OUT:"
"-" <spdentry> "-" <spdentry>
"-" <spdentry> "-" <spdentry>
... ...
skipping to change at page 18, line 39 skipping to change at page 19, line 37
<node> "SPD IN:" <node> "SPD IN:"
"-" <spdentry> "-" <spdentry>
"-" <spdentry> "-" <spdentry>
... ...
"-" <spdentry> "-" <spdentry>
Where <node> represents the name of the node, and <spdentry> has the Where <node> represents the name of the node, and <spdentry> has the
following format: following format:
"IF" <condition> "THEN USE" <sa> | "IF" <condition> "THEN USE SA " <sa> |
"IF" <condition> "THEN CREATE" <pattern> | "IF" <condition> "THEN USE SA " <pattern> |
Where <condition> is an boolean expression about the fields of the Where <condition> is a boolean expression about the fields of the
IPv6 packet, <sa> is the name of a security association, and IPv6 packet, <sa> is the name of a specific security association, and
<pattern> is a specification for a security association to be <pattern> is a specification for a security association to be
negotiated via IKE [5]. The SAD description has the format negotiated via IKE [5]. The SAD description has the format
<node> "SAD:" <node> "SAD:"
"-" <sadentry> "-" <sadentry>
"-" <sadentry> "-" <sadentry>
... ...
"-" <sadentry> "-" <sadentry>
Where <node> represents the name of the node, and <sadentry> has the Where <node> represents the name of the node, and <sadentry> has the
following format: following format:
<sa> "(" <dir> "," <sa> "(" <dir> ","
<spi> "," <spi> ","
<destination> "," <destination> ","
<ahesp> "," <ipsec-proto> ","
<mode> ")" ":" <mode> ")" ":"
<selectors> <rule>
Where <dir> is "IN" or "OUT", <spi> is the SPI of the security Where <dir> is "IN" or "OUT", <spi> is the SPI of the security
association, <destination> is its destination, <ahesp> is normally association, <destination> is its destination, <ipsec-proto> is in
"ESP" in our case but could also be "AH", <mode> is either "TUNNEL" our case "ESP", <mode> is either "TUNNEL" or "TRANSPORT", and <rule>
or "TRANSPORT", and <selectors> is a boolean expression about the is an expression which describes the IPsec selectors, i.e., which
fields of the IPv6 packet. fields of the IPv6 packet must have which values.
We will be using an example mobile node in this section with the home We will be using an example mobile node in this section with the home
address "home_address_1". The user's identity in this mobile node is address "home_address_1". The user's identity in this mobile node is
"user_1". The home agent's address is "home_agent_1". "user_1". The home agent's address is "home_agent_1".
5.2 Manual Configuration 5.2 Manual Configuration
5.2.1 Binding Updates and Acknowledgements 5.2.1 Binding Updates and Acknowledgements
Here are the contents of the SPD and SAD for protecting Binding Here are the contents of the SPD and SAD for protecting Binding
Updates and Acknowledgements: Updates and Acknowledgements:
mobile node SPD OUT: mobile node SPD OUT:
- IF source = home_address_1 & destination = home_agent_1 & - IF source = home_address_1 & destination = home_agent_1 &
proto = MH proto = MH
THEN USE SA1 THEN USE SA SA1
mobile node SPD IN: mobile node SPD IN:
- IF source = home_agent_1 & destination = home_address_1 & - IF source = home_agent_1 & destination = home_address_1 &
proto = MH proto = MH
THEN USE SA2 THEN USE SA SA2
mobile node SAD: mobile node SAD:
- SA1(OUT, spi_a, home_agent_1, ESP, TRANSPORT): - SA1(OUT, spi_a, home_agent_1, ESP, TRANSPORT):
source = home_address_1 & destination = home_agent_1 & source = home_address_1 & destination = home_agent_1 &
proto = MH proto = MH
- SA2(IN, spi_b, home_address_1, ESP, TRANSPORT): - SA2(IN, spi_b, home_address_1, ESP, TRANSPORT):
source = home_agent_1 & destination = home_address_1 & source = home_agent_1 & destination = home_address_1 &
proto = MH proto = MH
home agent SPD OUT: home agent SPD OUT:
- IF source = home_agent_1 & destination = home_address_1 & - IF source = home_agent_1 & destination = home_address_1 &
proto = MH proto = MH
THEN USE SA2 THEN USE SA SA2
home agent SPD IN: home agent SPD IN:
- IF source = home_address_1 & destination = home_agent_1 & - IF source = home_address_1 & destination = home_agent_1 &
proto = MH proto = MH
THEN USE SA1 THEN USE SA SA1
home agent SAD: home agent SAD:
- SA2(OUT, spi_b, home_address_1, ESP, TRANSPORT): - SA2(OUT, spi_b, home_address_1, ESP, TRANSPORT):
source = home_agent_1 & destination = home_address_1 & source = home_agent_1 & destination = home_address_1 &
proto = MH proto = MH
- SA1(IN, spi_a, home_agent_1, ESP, TRANSPORT): - SA1(IN, spi_a, home_agent_1, ESP, TRANSPORT):
source = home_address_1 & destination = home_agent_1 & source = home_address_1 & destination = home_agent_1 &
proto = MH proto = MH
In the above, "MH" refers to the protocol number for the Mobility In the above, "MH" refers to the protocol number for the Mobility
Header [8]. Header [8].
5.2.2 Return Routability Signaling 5.2.2 Return Routability Signaling
In the following we describe the necessary SPD and SAD entries to In the following we describe the necessary SPD and SAD entries to
protect return routability signaling between the mobile node and the protect return routability signaling between the mobile node and the
home agent. Note that the rules in the SPD are ordered, and the ones home agent. Note that the rules in the SPD are ordered, and the ones
in the previous section must take precedence over these ones: in the previous section must take precedence over these ones. In
other words, the higher precedence entries must occur first in the
RFC 2401 [2] ordered list of SPD entries.
mobile node SPD OUT: mobile node SPD OUT:
- IF interface = tunnel to home_agent_1 & - IF interface = IPv6 IPv6 tunnel to home_agent_1 &
source = home_address_1 & destination = any & source = home_address_1 & destination = any &
proto = MH proto = MH
THEN USE SA3 THEN USE SA SA3
mobile node SPD IN: mobile node SPD IN:
- IF interface = tunnel from home_agent_1 & - IF interface = IPv6 tunnel from home_agent_1 &
source = any & destination = home_address_1 & source = any & destination = home_address_1 &
proto = MH proto = MH
THEN USE SA4 THEN USE SA SA4
mobile node SAD: mobile node SAD:
- SA3(OUT, spi_c, home_agent_1, ESP, TUNNEL): - SA3(OUT, spi_c, home_agent_1, ESP, TUNNEL):
source = home_address_1 & destination = any & proto = MH source = home_address_1 & destination = any & proto = MH
- SA4(IN, spi_d, home_address_1, ESP, TUNNEL): - SA4(IN, spi_d, care_of_address_1, ESP, TUNNEL):
source = any & destination = home_address_1 & proto = MH source = any & destination = home_address_1 & proto = MH
home agent SPD OUT: home agent SPD OUT:
- IF interface = tunnel to home_address_1 & - IF interface = IPv6 tunnel to home_address_1 &
source = any & destination = home_address_1 & source = any & destination = home_address_1 &
proto = MH proto = MH
THEN USE SA4 THEN USE SA SA4
home agent SPD IN: home agent SPD IN:
- IF interface = tunnel from home_address_1 & - IF interface = IPv6 tunnel from home_address_1 &
source = home_address_1 & destination = any & source = home_address_1 & destination = any &
proto = MH proto = MH
THEN USE SA3 THEN USE SA SA3
home agent SAD: home agent SAD:
- SA4(OUT, spi_d, home_address_1, ESP, TUNNEL): - SA4(OUT, spi_d, care_of_address_1, ESP, TUNNEL):
source = any & destination = home_address_1 & proto = MH source = any & destination = home_address_1 & proto = MH
- SA3(IN, spi_c, home_agent_1, ESP, TUNNEL): - SA3(IN, spi_c, home_agent_1, ESP, TUNNEL):
source = home_address_1 & destination = any & proto = MH source = home_address_1 & destination = any & proto = MH
The security association from the home agent to the mobile node uses
the current care-of address as the destination. As discussed
earlier, this address is updated in the SAD as the mobile node moves.
It can be initialized to the home address before the mobile node has
registered.
5.2.3 Prefix Discovery 5.2.3 Prefix Discovery
In the following we describe some additional SPD and SAD entries to In the following we describe some additional SPD and SAD entries to
protect prefix discovery. protect prefix discovery. Note that the SPDs described above protect
all ICMPv6 traffic between the mobile node and the home agent, as
IPsec may not have the ability to distinguish between different
ICMPv6 types.
mobile node SPD OUT: mobile node SPD OUT:
- IF source = home_address_1 & destination = home_agent_1 & - IF source = home_address_1 & destination = home_agent_1 &
proto = ICMPv6 proto = ICMPv6
THEN USE SA5. THEN USE SA SA5.
mobile node SPD IN: mobile node SPD IN:
- IF source = home_agent_1 & destination = home_address_1 & - IF source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6 proto = ICMPv6
THEN USE SA6 THEN USE SA SA6
mobile node SAD: mobile node SAD:
- SA5(OUT, spi_e, home_agent_1, ESP, TRANSPORT): - SA5(OUT, spi_e, home_agent_1, ESP, TRANSPORT):
source = home_address_1 & destination = home_agent_1 & source = home_address_1 & destination = home_agent_1 &
proto = ICMPv6 proto = ICMPv6
- SA6(IN, spi_f, home_address_1, ESP, TRANSPORT): - SA6(IN, spi_f, home_address_1, ESP, TRANSPORT):
source = home_agent_1 & destination = home_address_1 & source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6 proto = ICMPv6
home agent SPD OUT: home agent SPD OUT:
- IF source = home_agent_1 & destination = home_address_1 & - IF source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6 proto = ICMPv6
THEN USE SA6 THEN USE SA SA6
home agent SPD IN: home agent SPD IN:
- IF source = home_address_1 & destination = home_agent_1 & - IF source = home_address_1 & destination = home_agent_1 &
proto = ICMPv6 proto = ICMPv6
THEN USE SA5 THEN USE SA SA5
home agent SAD: home agent SAD:
- SA6(OUT, spi_f, home_address_1, ESP, TRANSPORT): - SA6(OUT, spi_f, home_address_1, ESP, TRANSPORT):
source = home_agent_1 & destination = home_address_1 & source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6 proto = ICMPv6
- SA5(IN, spi_e, home_agent_1, ESP, TRANSPORT): - SA5(IN, spi_e, home_agent_1, ESP, TRANSPORT):
source = home_address_1 & destination = home_agent_1 & source = home_address_1 & destination = home_agent_1 &
proto = ICMPv6 proto = ICMPv6
Note that the SPDs described above protect all ICMPv6 traffic between
the mobile node and the home agent.
5.2.4 Payload Packets 5.2.4 Payload Packets
It is also possible to perform some additional, optional, protection It is also possible to perform some additional, optional, protection
of tunneled payload packets. This protection takes place in a of tunneled payload packets. This protection takes place in a
similar manner to the return routability protection above, but similar manner to the return routability protection above, but
requires a different value for the protocol field. The necessary SPD requires a different value for the protocol field. The necessary SPD
and SAD entries are shown below. It is assumed that the entries for and SAD entries are shown below. It is assumed that the entries for
protecting Binding Updates and Acknowledgements, and the entries to protecting Binding Updates and Acknowledgements, and the entries to
protect Home Test Init and Home Test messages take precedence over protect Home Test Init and Home Test messages take precedence over
these entries. these entries.
mobile node SPD OUT: mobile node SPD OUT:
- IF interface = tunnel to home_agent_1 & - IF interface = IPv6 tunnel to home_agent_1 &
source = home_address_1 & destination = any & source = home_address_1 & destination = any &
proto = X proto = X
THEN USE SA7 THEN USE SA SA7
mobile node SPD IN: mobile node SPD IN:
- IF interface = tunnel from home_agent_1 & - IF interface = IPv6 tunnel from home_agent_1 &
source = any & destination = home_address_1 & source = any & destination = home_address_1 &
proto = X proto = X
THEN USE SA8 THEN USE SA SA8
mobile node SAD: mobile node SAD:
- SA7(OUT, spi_g, home_agent_1, ESP, TUNNEL): - SA7(OUT, spi_g, home_agent_1, ESP, TUNNEL):
source = home_address_1 & destination = any & proto = X source = home_address_1 & destination = any & proto = X
- SA8(IN, spi_h, home_address_1, ESP, TUNNEL): - SA8(IN, spi_h, care_of_address_1, ESP, TUNNEL):
source = any & destination = home_address_1 & proto = X source = any & destination = home_address_1 & proto = X
home agent SPD OUT: home agent SPD OUT:
- IF interface = tunnel to home_address_1 & - IF interface = IPv6 tunnel to home_address_1 &
source = any & destination = home_address_1 & source = any & destination = home_address_1 &
proto = X proto = X
THEN USE SA8 THEN USE SA SA8
home agent SPD IN: home agent SPD IN:
- IF interface = tunnel from home_address_1 & - IF interface = IPv6 tunnel from home_address_1 &
source = home_address_1 & destination = any & source = home_address_1 & destination = any &
proto = X proto = X
THEN USE SA7 THEN USE SA SA7
home agent SAD: home agent SAD:
- SA8(OUT, spi_h, home_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 [12] need to be protected, these packets may use a link-local MLDv2 [13] 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 24, line 24 skipping to change at page 25, line 24
negotiate security associations. negotiate security associations.
5.3.1 Binding Updates and Acknowledgements 5.3.1 Binding Updates and Acknowledgements
Here are the contents of the SPD for protecting Binding Updates and Here are the contents of the SPD for protecting Binding Updates and
Acknowledgements: Acknowledgements:
mobile node SPD OUT: mobile node SPD OUT:
- IF source = home_address_1 & destination = home_agent_1 & - IF source = home_address_1 & destination = home_agent_1 &
proto = MH proto = MH
THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user_1 THEN USE SA ESP TRANSPORT: local phase 1 identity = user_1
mobile node SPD IN: mobile node SPD IN:
- IF source = home_agent_1 & destination = home_address_1 & - IF source = home_agent_1 & destination = home_address_1 &
proto = MH proto = MH
THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user_1 THEN USE SA ESP TRANSPORT: local phase 1 identity = user_1
home agent SPD OUT: home agent SPD OUT:
- IF source = home_agent_1 & destination = home_address_1 & - IF source = home_agent_1 & destination = home_address_1 &
proto = MH proto = MH
THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user_1 THEN USE SA ESP TRANSPORT: peer phase 1 identity = user_1
home agent SPD IN: home agent SPD IN:
- IF source = home_address_1 & destination = home_agent_1 & - IF source = home_address_1 & destination = home_agent_1 &
proto = MH proto = MH
THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user_1 THEN USE SA ESP TRANSPORT: peer phase 1 identity = user_1
We have omitted details of the proposed transforms in the above, and We have omitted details of the proposed transforms in the above, and
all details related to the particular authentication method such as all details related to the particular authentication method such as
certificates beyond listing a specific identity that must be used. certificates beyond listing a specific identity that must be used.
We require IKE to be run using the care-of addresses but still We require IKE version 1 to be run using the care-of addresses but
negotiate IPsec SAs that use home addresses. The extra conditions still negotiate IPsec SAs that use home addresses. The extra
set by the home agent SPD for the peer phase 1 identity to be conditions set by the home agent SPD for the peer phase 1 identity to
"user_1" must be verified by the home agent. The purpose of the be "user_1" must be verified by the home agent. The purpose of the
condition is to ensure that the IKE phase 2 negotiation for a given condition is to ensure that the IKE phase 2 negotiation for a given
user's home address can't be requested by another user. In the user's home address can't be requested by another user. In the
mobile node, we simply set our local identity to be "user_1". mobile node, we simply set our local identity to be "user_1".
These checks also imply that the configuration of the home agent is These checks also imply that the configuration of the home agent is
user-specific: every user or home address requires a specific user-specific: every user or home address requires a specific
configuration entry. It would be possible to alleviate the configuration entry. It would be possible to alleviate the
configuration tasks by using certificates that have home addresses in configuration tasks by using certificates that have home addresses in
the Subject AltName field. However, it isn't clear if all IKE the Subject AltName field. However, it isn't clear if all IKE
implementations allow one address to be used for carrying the IKE implementations allow one address to be used for carrying the IKE
negotiations when another address is mentioned in the used negotiations when another address is mentioned in the used
certificates. In any case, even this approach would have required certificates. In any case, even this approach would have required
user-specific tasks in the certificate authority. user-specific tasks in the certification authority.
5.3.2 Return Routability Signaling 5.3.2 Return Routability Signaling
Protection for the return routability signaling can be configured in Protection for the return routability signaling can be configured in
a similar manner as above. a similar manner as above.
mobile node SPD OUT: mobile node SPD OUT:
- IF interface = tunnel to home_agent_1 & - IF interface = IPv6 tunnel to home_agent_1 &
source = home_address_1 & destination = any & source = home_address_1 & destination = any &
proto = MH proto = MH
THEN CREATE ESP TUNNEL SA: gateway = home_agent_1 & THEN USE SA ESP TUNNEL: outer destination = home_agent_1 &
local phase 1 identity = user_1 local phase 1 identity = user_1
mobile node SPD IN: mobile node SPD IN:
- IF interface = tunnel from home_agent_1 & - IF interface = IPv6 tunnel from home_agent_1 &
source = any & destination = home_address_1 & source = any & destination = home_address_1 &
proto = MH proto = MH
THEN CREATE ESP TUNNEL SA: gateway = home_agent_1 & THEN USE SA ESP TUNNEL: outer destination = home_agent_1 &
local phase 1 identity = user_1 local phase 1 identity = user_1
home agent SPD OUT: home agent SPD OUT:
- IF interface = tunnel to home_address_1 & - IF interface = IPv6 tunnel to home_address_1 &
source = any & destination = home_address_1 & source = any & destination = home_address_1 &
proto = MH proto = MH
THEN CREATE ESP TUNNEL SA: gateway = home_address_1 & THEN USE SA ESP TUNNEL: outer destination = home_address_1 &
peer phase 1 identity = user_1 peer phase 1 identity = user_1
home agent SPD IN: home agent SPD IN:
- IF interface = tunnel from home_address_1 & - IF interface = IPv6 tunnel from home_address_1 &
source = home_address_1 & destination = any & source = home_address_1 & destination = any &
proto = MH proto = MH
THEN CREATE ESP TUNNEL SA: gateway = home_address_1 & THEN USE SA ESP TUNNEL: outer destination = home_address_1 &
peer phase 1 identity = user_1 peer phase 1 identity = user_1
Here we specified the gateway address for the security association as The security association from the home agent to the mobile node uses
the home address for the mobile node. However, as required by the current care-of address as the destination. As discussed
Section 4.3 the packets will actually be sent to the current care-of earlier, this address is updated in the SAD as the mobile node moves.
address. In order to avoid writing dynamically changing information The SPD entries can be written using the home address (as above), if
to the SPD entries, the above has been written with the home address the care-of address update in the SAD is also done upon the creation
as the gateway. of security associations.
5.3.3 Prefix Discovery 5.3.3 Prefix Discovery
In the following we describe some additional SPD entries to protect In the following we describe some additional SPD entries to protect
prefix discovery with IKE. (Note that when actual new prefixes are prefix discovery with IKE. (Note that when actual new prefixes are
discovered, there may be a need to enter new manually configured SPD discovered, there may be a need to enter new manually configured SPD
entries to specify the authorization policy for the resulting new entries to specify the authorization policy for the resulting new
home addresses.) home addresses.)
mobile node SPD OUT: mobile node SPD OUT:
- IF source = home_address_1 & destination = home_agent_1 & - IF source = home_address_1 & destination = home_agent_1 &
proto = ICMPv6 proto = ICMPv6
THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user_1 THEN USE SA ESP TRANSPORT: local phase 1 identity = user_1
mobile node SPD IN: mobile node SPD IN:
- IF source = home_agent_1 & destination = home_address_1 & - IF source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6 proto = ICMPv6
THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user_1 THEN USE SA ESP TRANSPORT: local phase 1 identity = user_1
home agent SPD OUT: home agent SPD OUT:
- IF source = home_agent_1 & destination = home_address_1 & - IF source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6 proto = ICMPv6
THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user_1 THEN USE SA ESP TRANSPORT: peer phase 1 identity = user_1
home agent SPD IN: home agent SPD IN:
- IF source = home_address_1 & destination = home_agent_1 & - IF source = home_address_1 & destination = home_agent_1 &
proto = ICMPv6 proto = ICMPv6
THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user_1 THEN USE SA ESP TRANSPORT: peer phase 1 identity = user_1
5.3.4 Payload Packets 5.3.4 Payload Packets
Protection for the payload packets happens similarly to the Protection for the payload packets happens similarly to the
protection of return routability signaling. As in the manually keyed protection of return routability signaling. As in the manually keyed
case, these SPD entries have lower priority than the above ones. case, these SPD entries have lower priority than the above ones.
mobile node SPD OUT: mobile node SPD OUT:
- IF interface = tunnel to home_agent_1 & - IF interface = IPv6 tunnel to home_agent_1 &
source = home_address_1 & destination = any & source = home_address_1 & destination = any &
proto = X proto = X
THEN CREATE ESP TUNNEL SA: gateway = home_agent_1 & THEN USE SA ESP TUNNEL: outer destination = home_agent_1 &
local phase 1 identity = user_1 local phase 1 identity = user_1
mobile node SPD IN: mobile node SPD IN:
- IF interface = tunnel from home_agent_1 & - IF interface = IPv6 tunnel from home_agent_1 &
source = any & destination = home_address_1 & source = any & destination = home_address_1 &
proto = X proto = X
THEN CREATE ESP TUNNEL SA: gateway = home_agent_1 & THEN USE SA ESP TUNNEL: outer destination = home_agent_1 &
local phase 1 identity = user_1 local phase 1 identity = user_1
home agent SPD OUT: home agent SPD OUT:
- IF interface = tunnel to home_address_1 & - IF interface = IPv6 tunnel to home_address_1 &
source = any & destination = home_address_1 & source = any & destination = home_address_1 &
proto = X proto = X
THEN CREATE ESP TUNNEL SA: gateway = home_address_1 & THEN USE SA ESP TUNNEL: outer destination = home_address_1 &
peer phase 1 identity = user_1 peer phase 1 identity = user_1
home agent SPD IN: home agent SPD IN:
- IF interface = tunnel from home_address_1 & - IF interface = IPv6 tunnel from home_address_1 &
source = home_address_1 & destination = any & source = home_address_1 & destination = any &
proto = X proto = X
THEN CREATE ESP TUNNEL SA: gateway = home_address_1 & THEN USE SA ESP TUNNEL: outer destination = home_address_1 &
peer phase 1 identity = user_1 peer phase 1 identity = user_1
6. Processing Steps within a Node 6. Processing Steps within a Node
6.1 Binding Update to the Home Agent 6.1 Binding Update to the Home Agent
Step 1. At the mobile node, Mobile IPv6 module first produces the Step 1. At the mobile node, Mobile IPv6 module first produces the
following packet: following packet:
IPv6 header (source = home address, IPv6 header (source = home address,
destination = home agent) destination = home agent)
Mobility header Mobility header
Binding Update Binding Update
Step 2. This packet is matched against the IPsec policy data base on Step 2. This packet is matched against the IPsec SPD on the mobile
the mobile node and we make a note that IPsec must be applied. node and we make a note that IPsec must be applied.
Step 3. Then, we add the necessary Mobile IPv6 options but do not Step 3. Then, we add the necessary Mobile IPv6 options but do not
change the addresses yet, as described in Section 11.2.2 of the base change the addresses yet, as described in Section 11.2.2 of the base
specification [8]. This results in: specification [8]. This results in:
IPv6 header (source = home address, IPv6 header (source = home address,
destination = home agent) destination = home agent)
Destination Options header Destination Options header
Home Address option (care-of address) Home Address option (care-of address)
Mobility header Mobility header
skipping to change at page 28, line 42 skipping to change at page 29, line 42
authenticator values are calculated: authenticator values are calculated:
IPv6 header (source = home address, IPv6 header (source = home address,
destination = home agent) destination = home agent)
Destination Options header Destination Options header
Home Address option (care-of address) Home Address option (care-of address)
ESP header (SPI = spi_a) ESP header (SPI = spi_a)
Mobility header Mobility header
Binding Update Binding Update
Here spi_a is the SPI value that was either configured manually, or
agreed upon in an earlier IKE negotiation.
Step 5. Before sending the packet, the addresses in the IPv6 header Step 5. Before sending the packet, the addresses in the IPv6 header
and the Destination Options header are changed: and the Destination Options header are changed:
IPv6 header (source = care-of address, IPv6 header (source = care-of address,
destination = home agent) destination = home agent)
Destination Options header Destination Options header
Home Address option (home address) Home Address option (home address)
ESP header (SPI = spi_a) ESP header (SPI = spi_a)
Mobility header Mobility header
Binding Update Binding Update
skipping to change at page 29, line 36 skipping to change at page 30, line 44
Step 3. ESP header is processed next, resulting in Step 3. ESP header is processed next, resulting in
IPv6 header (source = home address, IPv6 header (source = home address,
destination = home agent) destination = home agent)
Destination Options header Destination Options header
Home Address option (care-of address) Home Address option (care-of address)
Mobility header Mobility header
Binding Update Binding Update
Step 4. This packet matches the security association selectors Step 4. This packet matches the policy required for this security
(source = home address, destination = home agent, proto = MH). association (source = home address, destination = home agent, proto =
MH).
Step 5. Mobile IPv6 processes the Binding Update. The Binding Step 5. Mobile IPv6 processes the Binding Update. The Binding
Update is delivered to the Mobile IPv6 module. Update is delivered to the Mobile IPv6 module.
Step 6. If there are any security associations in the security
association database for the protection of return routability or
payload packets for this mobile node, those security associations are
updated with the new care-of address.
6.3 Binding Acknowledgement to the Mobile Node 6.3 Binding Acknowledgement to the Mobile Node
Step 1. Mobile IPv6 produces the following packet: Step 1. Mobile IPv6 produces the following packet:
IPv6 header (source = home agent, IPv6 header (source = home agent,
destination = home address) destination = home address)
Mobility header Mobility header
Binding Acknowledgement Binding Acknowledgement
Step 2. This packet matches the IPsec policy entries, and we Step 2. This packet matches the IPsec policy entries, and we
skipping to change at page 31, line 4 skipping to change at page 32, line 18
IPv6 header (source = home agent, IPv6 header (source = home agent,
destination = care-of address) destination = care-of address)
Routing header (type 2) Routing header (type 2)
home address home address
ESP header (SPI = spi_b) ESP header (SPI = spi_b)
Mobility header Mobility header
Binding Acknowledgement Binding Acknowledgement
Step 2. After the routing header is processed the packet becomes Step 2. After the routing header is processed the packet becomes
IPv6 header (source = home agent, IPv6 header (source = home agent,
destination = home address) destination = home address)
Routing header (type 2) Routing header (type 2)
care-of address care-of address
ESP header (SPI = spi_b) ESP header (SPI = spi_b)
Mobility header Mobility header
Binding Acknowledgement Binding Acknowledgement
Step 3. ESP header is processed next, resulting in: Step 3. ESP header is processed next, resulting in:
IPv6 header (source = home agent, IPv6 header (source = home agent,
destination = home address) destination = home address)
Routing header (type 2) Routing header (type 2)
care-of address care-of address
Mobility header Mobility header
Binding Acknowledgement Binding Acknowledgement
Step 4. This packet matches the security association selectors Step 4. This packet matches the policy required for this security
(source = home agent, destination = home address, proto = MH). association (source = home agent, destination = home address, proto =
MH).
Step 5. The Binding Acknowledgement is delivered to the Mobile IPv6 Step 5. The Binding Acknowledgement is delivered to the Mobile IPv6
module. module.
6.5 Home Test Init to the Home Agent 6.5 Home Test Init to the Home Agent
Step 1. The mobile node constructs a Home Test Init message: Step 1. The mobile node constructs a Home Test Init message:
IPv6 header (source = home address, IPv6 header (source = home address,
destination = correspondent node) destination = correspondent node)
skipping to change at page 32, line 5 skipping to change at page 33, line 20
care-of address as a source address for the tunnel packet. care-of address as a source address for the tunnel packet.
IPv6 header (source = care-of address, IPv6 header (source = care-of address,
destination = home agent) destination = home agent)
ESP header (SPI = spi_c) ESP header (SPI = spi_c)
IPv6 header (source = home address, IPv6 header (source = home address,
destination = correspondent node) destination = correspondent node)
Mobility header Mobility header
Home Test Init Home Test Init
Step 5. The packet no longer satisfies the criteria that made it Step 5. The packet is sent directly to the home agent using IPsec
enter the tunnel, and it is sent directly to the home agent. encapsulation.
6.6 Home Test Init from the Mobile Node 6.6 Home Test Init from the Mobile Node
Step 1. The home agent receives the following packet: Step 1. The home agent receives the following packet:
IPv6 header (source = care-of address, IPv6 header (source = care-of address,
destination = home agent) destination = home agent)
ESP header (SPI = spi_c) ESP header (SPI = spi_c)
IPv6 header (source = home address, IPv6 header (source = home address,
destination = correspondent node) destination = correspondent node)
Mobility Header Mobility Header
Home Test Init Home Test Init
Step 2. IPsec processing is performed, resulting in: Step 2. IPsec processing is performed, resulting in:
IPv6 header (source = home address, IPv6 header (source = home address,
destination = correspondent node) destination = correspondent node)
Mobility Header Mobility Header
Home Test Init Home Test Init
Step 3. The resulting packet matches the selectors and the packet Step 3. The resulting packet matches the policy required for this
can be processed further. security association and the packet can be processed further.
Step 4. The packet is then forwarded to the correspondent node. Step 4. The packet is then forwarded to the correspondent node.
6.7 Home Test to the Mobile Node 6.7 Home Test to the Mobile Node
Step 1. The home agent receives a Home Test packet from the Step 1. The home agent receives a Home Test packet from the
correspondent node: correspondent node:
IPv6 header (source = correspondent node, IPv6 header (source = correspondent node,
destination = home address) destination = home address)
skipping to change at page 32, line 50 skipping to change at page 34, line 18
Home Test Init Home Test Init
Step 2. The home agent determines that this packet is destined to a Step 2. The home agent determines that this packet is destined to a
mobile node that is away from home, and decides to tunnel it. mobile node that is away from home, and decides to tunnel it.
Step 3. The packet matches the IPsec policy entries for the tunnel Step 3. The packet matches the IPsec policy entries for the tunnel
interface, and we note that IPsec needs to be applied. interface, and we note that IPsec needs to be applied.
Step 4. IPsec is applied, resulting in a new packet. Note that the Step 4. IPsec is applied, resulting in a new packet. Note that the
home agent must keep track of the location of the mobile node, and home agent must keep track of the location of the mobile node, and
update the tunnel gateway address in the security association(s) update the tunnel endpoint address in the security association(s)
accordingly. accordingly.
IPv6 header (source = home agent, IPv6 header (source = home agent,
destination = care-of address) destination = care-of address)
ESP header (SPI = spi_d) ESP header (SPI = spi_d)
IPv6 header (source = correspondent node, IPv6 header (source = correspondent node,
destination = home address) destination = home address)
Mobility Header Mobility Header
Home Test Init Home Test Init
Step 5. The packet no longer satisfies the criteria that made it Step 5. The packet is sent directly to the care-of address using
enter the tunnel, and it is sent directly to the care-of address. IPsec encapsulation.
6.8 Home Test from the Home Agent 6.8 Home Test from the Home Agent
Step 1. The mobile node receives the following packet: Step 1. The mobile node receives the following packet:
IPv6 header (source = home agent, IPv6 header (source = home agent,
destination = care-of address) destination = care-of address)
ESP header (SPI = spi_d) ESP header (SPI = spi_d)
IPv6 header (source = correspondent node, IPv6 header (source = correspondent node,
destination = home address) destination = home address)
Mobility Header Mobility Header
Home Test Init Home Test Init
Step 2. IPsec is processed, resulting in: Step 2. IPsec is processed, resulting in:
IPv6 header (source = correspondent node, IPv6 header (source = correspondent node,
destination = home address) destination = home address)
Mobility Header Mobility Header
Home Test Init Home Test Init
Step 3. This matches the security association selectors (source = Step 3. This matches the policy required for this security
any, destination = home address). association (source = any, destination = home address).
Step 4. The packet is given to Mobile IPv6 processing. Step 4. The packet is given to Mobile IPv6 processing.
6.9 Prefix Solicitation Message to the Home Agent 6.9 Prefix Solicitation Message to the Home Agent
This procedure is similar to the one presented in Section 6.1. This procedure is similar to the one presented in Section 6.1.
6.10 Prefix Solicitation Message from the Mobile Node 6.10 Prefix Solicitation Message from the Mobile Node
This procedure is similar to the one presented in Section 6.2. This procedure is similar to the one presented in Section 6.2.
skipping to change at page 34, line 36 skipping to change at page 35, line 50
Step 1. The mobile node wishes to send a Binding Update to the home Step 1. The mobile node wishes to send a Binding Update to the home
agent. agent.
IPv6 header (source = home address, IPv6 header (source = home address,
destination = home agent) destination = home agent)
Mobility header Mobility header
Binding Update Binding Update
Step 2. There is no existing security association to protect the Step 2. There is no existing security association to protect the
Binding Update, so IKE is initiated. The IKE packets are sent as Binding Update, so the mobile node initiates IKE. The IKE packets
shown in the following examples. The first packet is an example of are sent as shown in the following examples. The first packet is an
an IKE packet sent from the mobile node, and the second one is from example of an IKE packet sent from the mobile node, and the second
the home agent. The examples shows also that the phase 1 identity one is from the home agent. The examples shows also that the phase 1
used for the mobile node is a FQDN. identity used for the mobile node is a FQDN.
IPv6 header (source = care-of address, IPv6 header (source = care-of address,
destination = home agent) destination = home agent)
UDP UDP
IKE IKE
... IDii = ID_FQDN mn123.ha.net ... ... IDii = ID_FQDN mn123.ha.net ...
IPv6 header (source = home agent IPv6 header (source = home agent
destination = care-of address) destination = care-of address)
UDP UDP
IKE IKE
... IDir = ID_FQDN ha.net ... ... IDir = ID_FQDN ha.net ...
Step 3. IKE phase 1 completes, and phase 2 is initiated to request Step 3. IKE phase 1 completes, and phase 2 is initiated to request
security associations for protecting traffic between the mobile security associations for protecting traffic between the mobile
node's home address and the home agent. This involves sending and node's home address and the home agent. These addresses will be used
receiving additional IKE packets. The below example shows again one as selectors. This involves sending and receiving additional IKE
packet sent by the mobile node and another sent by the home agent. packets. The below example shows again one packet sent by the mobile
The example shows also that the phase 2 identity used for the mobile node and another sent by the home agent. The example shows also that
node is the mobile node's home address. the phase 2 identity used for the mobile node is the mobile node's
home address.
IPv6 header (source = care-of address, IPv6 header (source = care-of address,
destination = home agent) destination = home agent)
UDP UDP
IKE IKE
... IDci = ID_IPV6_ADDR home address ... ... IDci = ID_IPV6_ADDR home address ...
IPv6 header (source = home agent, IPv6 header (source = home agent,
destination = care-of address) destination = care-of address)
UDP UDP
skipping to change at page 36, line 27 skipping to change at page 37, line 42
movement with IKE-based security associations. In the initial state, movement with IKE-based security associations. In the initial state,
the mobile node is not registered in any location and has no security the mobile node is not registered in any location and has no security
associations with the home agent. Depending on whether the peers associations with the home agent. Depending on whether the peers
will be able to move IKE endpoints to new care-of addresses, the will be able to move IKE endpoints to new care-of addresses, the
actions taken in Step 9 and 10 are different. actions taken in Step 9 and 10 are different.
Step 1. Mobile node with the home address A moves to care-of address Step 1. Mobile node with the home address A moves to care-of address
B. B.
Step 2. Mobile node runs IKE from care-of address B to the home Step 2. Mobile node runs IKE from care-of address B to the home
agent, establishing a phase 1. agent, establishing a phase 1. The home agent can only act as the
responder before it knows the current location of the mobile node.
Step 3. Protected by this phase 1, mobile node establishes a pair of Step 3. Protected by this phase 1, mobile node establishes a pair of
security associations for protecting Mobility Header traffic to and security associations for protecting Mobility Header traffic to and
from the home address A. from the home address A.
Step 4. Mobile node sends a Binding Update and receives a Binding Step 4. Mobile node sends a Binding Update and receives a Binding
Acknowledgement using the security associations created in Step 3. Acknowledgement using the security associations created in Step 3.
Step 5. Mobile node establishes a pair of security associations for Step 5. Mobile node establishes a pair of security associations for
protecting return routability packets. These security associations protecting return routability packets. These security associations
skipping to change at page 37, line 4 skipping to change at page 38, line 20
Step 6. The mobile node uses the security associations created in Step 6. The mobile node uses the security associations created in
Step 5 to run return routability. Step 5 to run return routability.
Step 7. The mobile node moves to a new location and adopts a new Step 7. The mobile node moves to a new location and adopts a new
care-of address C. care-of address C.
Step 8. Mobile node sends a Binding Update and receives a Binding Step 8. Mobile node sends a Binding Update and receives a Binding
Acknowledgement using the security associations created in Step 3. Acknowledgement using the security associations created in Step 3.
The home agent ensures that the next packets sent using the security The home agent ensures that the next packets sent using the security
associations created in Step 5 will have the new care-of address as associations created in Step 5 will have the new care-of address as
their destination address, as if the destination gateway address in their destination address, as if the outer header destination address
the security association had changed. in the security association had changed.
Step 9. If the mobile node and the HA have the capability to change Step 9. If the mobile node and the HA have the capability to change
the IKE endpoints, they change the address to C. If they dont have the IKE endpoints, they change the address to C. If they dont have
the capability, both nodes remove their phase 1 connections created the capability, both nodes remove their phase 1 connections created
on top of the care-of address B and establish a new IKE phase 1 on on top of the care-of address B and will establish a new IKE phase 1
top of the care-of address C. This capability to change the IKE on top of the care-of address C. This capability to change the IKE
phase 1 end points is indicated through setting the Key Management phase 1 end points is indicated through setting the Key Management
Mobility Capability (K) flag [8] in the Binding Update and Binding Mobility Capability (K) flag [8] in the Binding Update and Binding
Acknowledgement messages. Acknowledgement messages.
Step 10. If a new IKE phase 1 connection was setup after movement, Step 10. If a new IKE phase 1 connection was setup after movement,
the MN will not be able to receive any notifications delivered on top the MN will not be able to receive any notifications delivered on top
of the old IKE phase 1 security association. Notifications delivered of the old IKE phase 1 security association. Notifications delivered
on top of the new security association are received and processed on top of the new security association are received and processed
normally. If the mobile node and HA were able to update the IKE normally. If the mobile node and HA were able to update the IKE
endpoints, they can continue using the same IKE phase 1 connection. endpoints, they can continue using the same IKE phase 1 connection.
7. Implementation Considerations 7. Implementation Considerations
7.1 IPsec
Note that packet formats and header ordering discussed in Section 3
must be supported, but implementations may also support other
formats. In general, the use of formats not required here may lead
to incorrect processing of the packets by the peer (such as silently
discarding them), unless support for these formats has been verified
off-line. Such verification can take place at the same time the
parameters of the security associations are agreed upon. In some
cases, however, basic IPv6 specifications call for support of options
not discussed here. In these cases such verification step might be
unnecessary as long as the peer fully supports the relevant IPv6
specifications. However, no claims are made in this document about
the validity of these other formats in the context of Mobile IPv6.
It is also likely that systems that support Mobile IPv6 have been
tested more extensively with the required formats.
We have chosen to require an encapsulation format for return We have chosen to require an encapsulation format for return
routability and payload packet protection which can only be realized routability and payload packet protection which can only be realized
if the destination of the IPsec packets sent from the home agent can if the destination of the IPsec packets sent from the home agent can
be changed as the mobile node moves. One of the main reasons for be changed as the mobile node moves. One of the main reasons for
choosing such a format is that it removes the overhead of twenty four choosing such a format is that it removes the overhead of twenty four
bytes when a home address option or routing header is added to the bytes when a home address option or routing header is added to the
tunneled packet. What is needed is that the home agent must act as tunneled packet. Such an overhead would not be significant for the
if the gateway address of a security association to the mobile node protection of the return routability packets, but would create an
would have changed. Implementations are free to choose any additional overhead if IPsec is used to protect the tunneling of
particular method to make this change, such as using an API to the payload packets to the home agent. This overhead may be significant
IPsec implementation to change the parameters of the security for real-time traffic. Given that the use of the shorter packet
association, removing the security association and installing a new formats for any traffic requires the existence of suitable APIs, we
one, or modification of the packet after it has gone through IPsec have chosen to require support for the shorter packet formats both
processing. The only requirement is that after registering a new for payload and return routability packets.
binding at the home agent, the next IPsec packets sent on this
security association will be addressed to the new care-of address.
We have also chosen to require that a dynamic key management protocol
must be able to make an authorization decision for IPsec security
association creation with different addresses than with what the key
management protocol is run. We expect this to be done typically by
configuring the allowed combinations of phase 1 user identities and
home addresses.
The base Mobile IPv6 specification sets high requirements for a In order to support the care-of address as the destination address on
so-called Bump-In-The-Stack (BITS) implementation model of IPsec. As the mobile node side, the home agent must act as if the outer header
Mobile IPv6 specific modifications of the packets are required after destination address in the security association to the mobile node
IPsec processing, the BITS implementation has to perform also some would have changed upon movements. Implementations are free to
tasks related to mobility. This may increase the complexity of the choose any particular method to make this change, such as using an
implementation, even if it already performs some tasks of the IP API to the IPsec implementation to change the parameters of the
layer (such as fragmentation). security association, removing the security association and
installing a new one, or modification of the packet after it has gone
through IPsec processing. The only requirement is that after
registering a new binding at the home agent, the next IPsec packets
sent on this security association will be addressed to the new
care-of address.
We have chosen to require policy entries that are specific to a We have chosen to require policy entries that are specific to a
tunnel interface. This means that implementations have to regard the tunnel interface. This means that implementations have to regard the
Home Agent - Mobile Node tunnel as a separate interface on which Home Agent - Mobile Node tunnel as a separate interface on which
IPsec SPDs can be based. IPsec SPDs can be based. A further complication of the IPsec
processing on a tunnel interface is that this requires access to the
BITS implementation before the packet actually goes out.
A further complication of the IPsec processing on a tunnel interface 7.2 IKE
is that this requires access to the BITS implementation before the
packet actually goes out. We have chosen to require that a dynamic key management protocol must
be able to make an authorization decision for IPsec security
association creation with different addresses than with what the key
management protocol is run. We expect this to be done typically by
configuring the allowed combinations of phase 1 user identities and
home addresses.
When certificate authentication is used, IKE fragmentation can be When certificate authentication is used, IKE fragmentation can be
encountered. This can occur when certificate chains are used, or encountered. This can occur when certificate chains are used, or
even with single certificates if they are large. Many firewalls do even with single certificates if they are large. Many firewalls do
not handle fragments properly, and may drop them. Routers in the not handle fragments properly, and may drop them. Routers in the
path may also discard fragments after the initial one, since they path may also discard fragments after the initial one, since they
typically will not contain full IP headers that can be compared typically will not contain full IP headers that can be compared
against an access list. Where fragmentation occurs, the endpoints against an access list. Where fragmentation occurs, the endpoints
will not always be able to establish a security association. will not always be able to establish a security association.
Fortunately, typical Mobile IPv6 deployment uses short certificate Fortunately, typical Mobile IPv6 deployment uses short certificate
chains, as the mobile node is communicating directly with its home chains, as the mobile node is communicating directly with its home
network. Nevertheless, where the problem appears, one solution is to network. Where the problem appears, it may be difficult (at least
replace the firewalls or routers with equipment that can properly away from home) to replace the firewalls or routers with equipment
support fragments. If this cannot be done, it may help to store the that can properly support fragments. It may help to store the peer
peer certificates locally, or to obtain them through other means. certificates locally, or to obtain them through other means.
7.3 Bump-in-the-Stack
Mobile IPv6 sets high requirements for a so-called Bump-In-The-Stack
(BITS) implementation model of IPsec. As Mobile IPv6 specific
modifications of the packets are required before or after IPsec
processing, the BITS implementation has to perform also some tasks
related to mobility. This may increase the complexity of the
implementation, even if it already performs some tasks of the IP
layer (such as fragmentation).
Specifically, Bump-in-the-Stack implementations may have to deal with
the following issues:
o Processing the Home Address destination option and Routing header
type 2 to a form suitable for IPsec processing to take place.
This is needed, among other things, for the security association
and policy lookups. While relatively straightforward, the
required processing may have a hardware effect in BITS
implementations, if they use hardware support beyond the
cryptographic operations.
o Detecting packets sent between the mobile node and its home agent
using IPv6 encapsulation.
o Offering the necessary APIs for updating the IPsec and IKE
security association endpoints.
8. IANA Considerations 8. IANA Considerations
No IANA actions are necessary based on this document. IANA actions No IANA actions are necessary based on this document. IANA actions
for the Mobile IPv6 protocol itself have been covered in [8]. for the Mobile IPv6 protocol itself have been covered in [8].
9. Security Considerations 9. Security Considerations
The Mobile IPv6 base specification [8] requires strong security The Mobile IPv6 base specification [8] requires strong security
between the mobile node and the home agent. This memo discusses how between the mobile node and the home agent. This memo discusses how
that security can be arranged in practice, using IPsec. that security can be arranged in practice, using IPsec. The security
considerations related to this are documented in the base
specification, including a discussion of the implications of using
either manual or dynamic keying.
Normative References Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Kent, S. and R. Atkinson, "Security Architecture for the [2] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
[3] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, [3] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
skipping to change at page 42, 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-21 (work in progress), February IPv6", draft-ietf-mobileip-ipv6-22 (work in progress), May 2003.
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] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 [12] Touch, J. and L. Eggert, "Use of IPsec Transport Mode for
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 43, line 39 skipping to change at page 46, line 4
EMail: jari.arkko@ericsson.com EMail: jari.arkko@ericsson.com
Vijay Devarapalli Vijay Devarapalli
Nokia Research Center Nokia Research Center
313 Fairchild Drive 313 Fairchild Drive
Mountain View CA 94043 Mountain View CA 94043
USA USA
EMail: vijayd@iprg.nokia.com EMail: vijayd@iprg.nokia.com
Francis Dupont Francis Dupont
ENST Bretagne ENST Bretagne
Campus de Rennes 2, rue de la Chataigneraie Campus de Rennes 2, rue de la Chataigneraie
BP 78 BP 78
Cesson-Sevigne Cedex 35512 Cesson-Sevigne Cedex 35512
France France
EMail: Francis.Dupont@enst-bretagne.fr EMail: Francis.Dupont@enst-bretagne.fr
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, and Gabriel Miles, Cheryl Madson, Bernard Aboba, Erik Nordmark, Gabriel
Montenegro for interesting discussions in this problem space. Montenegro, Steven Kent, and Santeri Paavolainen for interesting
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
02: 04:
o The wire format for de-registration when returning home has been o Implications for Bumb-in-the-Stack implementations have been more
updated. The Alternate Care-of Address option is no longer used extensively discussed (tracked issue 307).
in this situation (tracked issue 270).
o An IANA considerations section has been added (tracked issue 265). 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 IPsec protocol and mode requirements have now been stated as o The required IPsec SPD checks have been clarified. While it is
minimal requirements and no longer prevent the use of other required that policy checks be based on the home address (from the
protocols (AH) and modes (tracked issue 228). 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 Some editorial modifications have been performed. 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
of IPsec tunnel mode versus the use of IP-in-IP encapsulation
(tracked issue 284).
o The draft clarifies the implications of either using or not using
IKE (tracked issue 282).
o Some editorial modifications have been performed (tracked issues
287 and 292).
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. 153 change blocks. 
385 lines changed or deleted 602 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/