draft-ietf-mobileip-mipv6-ha-ipsec-02.txt   draft-ietf-mobileip-mipv6-ha-ipsec-03.txt 
Network Working Group J. Arkko Network Working Group J. Arkko
Internet-Draft Ericsson Internet-Draft Ericsson
Expires: July 21, 2003 V. Devarapalli Expires: August 19, 2003 V. Devarapalli
Nokia Research Center Nokia Research Center
F. Dupont F. Dupont
ENST Bretagne ENST Bretagne
January 20, 2003 February 18, 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-02.txt draft-ietf-mobileip-mipv6-ha-ipsec-03.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 July 21, 2003. This Internet-Draft will expire on August 19, 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 draft discusses these requirements these nodes must follow. This document discusses these
requirements in more depth, illustrates the used packet formats, requirements in more depth, illustrates the used packet formats,
describes suitable configuration procedures, and shows how describes suitable configuration procedures, and shows how
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. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 7 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1 Binding Updates and Acknowledgements . . . . . . . . . 7 3. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Return Routability Signaling . . . . . . . . . . . . . 8 3.1 Binding Updates and Acknowledgements . . . . . . . . . 8
2.3 Prefix Discovery . . . . . . . . . . . . . . . . . . . 9 3.2 Return Routability Signaling . . . . . . . . . . . . . 9
2.4 Payload Packets . . . . . . . . . . . . . . . . . . . 9 3.3 Prefix Discovery . . . . . . . . . . . . . . . . . . . 10
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 11 3.4 Payload Packets . . . . . . . . . . . . . . . . . . . 10
3.1 Mandatory Support . . . . . . . . . . . . . . . . . . 11 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2 Policy Requirements . . . . . . . . . . . . . . . . . 11 4.1 Mandatory Support . . . . . . . . . . . . . . . . . . 12
3.3 IPsec Protocol Processing . . . . . . . . . . . . . . 13 4.2 Policy Requirements . . . . . . . . . . . . . . . . . 12
3.4 Dynamic Keying . . . . . . . . . . . . . . . . . . . . 15 4.3 IPsec Protocol Processing . . . . . . . . . . . . . . 14
4. Example Configurations . . . . . . . . . . . . . . . . . . . 17 4.4 Dynamic Keying . . . . . . . . . . . . . . . . . . . . 16
4.1 Format . . . . . . . . . . . . . . . . . . . . . . . . 17 5. Example Configurations . . . . . . . . . . . . . . . . . . . 18
4.2 Manual Configuration . . . . . . . . . . . . . . . . . 18 5.1 Format . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2.1 Binding Updates and Acknowledgements . . . . . . 18 5.2 Manual Configuration . . . . . . . . . . . . . . . . . 19
4.2.2 Return Routability Signaling . . . . . . . . . . 19 5.2.1 Binding Updates and Acknowledgements . . . . . . 19
4.2.3 Prefix Discovery . . . . . . . . . . . . . . . . 20 5.2.2 Return Routability Signaling . . . . . . . . . . 20
4.2.4 Payload Packets . . . . . . . . . . . . . . . . 21 5.2.3 Prefix Discovery . . . . . . . . . . . . . . . . 21
4.3 Dynamic Keying . . . . . . . . . . . . . . . . . . . . 23 5.2.4 Payload Packets . . . . . . . . . . . . . . . . 22
4.3.1 Binding Updates and Acknowledgements . . . . . . 23 5.3 Dynamic Keying . . . . . . . . . . . . . . . . . . . . 24
4.3.2 Return Routability Signaling . . . . . . . . . . 24 5.3.1 Binding Updates and Acknowledgements . . . . . . 24
4.3.3 Prefix Discovery . . . . . . . . . . . . . . . . 24 5.3.2 Return Routability Signaling . . . . . . . . . . 25
4.3.4 Payload Packets . . . . . . . . . . . . . . . . 25 5.3.3 Prefix Discovery . . . . . . . . . . . . . . . . 26
5. Processing Steps within a Node . . . . . . . . . . . . . . . 27 5.3.4 Payload Packets . . . . . . . . . . . . . . . . 26
5.1 Binding Update to the Home Agent . . . . . . . . . . . 27 6. Processing Steps within a Node . . . . . . . . . . . . . . . 28
5.2 Binding Update from the Mobile Node . . . . . . . . . 28 6.1 Binding Update to the Home Agent . . . . . . . . . . . 28
5.3 Binding Acknowledgement to the Mobile Node . . . . . . 28 6.2 Binding Update from the Mobile Node . . . . . . . . . 29
5.4 Binding Acknowledgement from the Home Agent . . . . . 29 6.3 Binding Acknowledgement to the Mobile Node . . . . . . 29
5.5 Home Test Init to the Home Agent . . . . . . . . . . . 30 6.4 Binding Acknowledgement from the Home Agent . . . . . 30
5.6 Home Test Init from the Mobile Node . . . . . . . . . 31 6.5 Home Test Init to the Home Agent . . . . . . . . . . . 31
5.7 Home Test to the Mobile Node . . . . . . . . . . . . . 31 6.6 Home Test Init from the Mobile Node . . . . . . . . . 32
5.8 Home Test from the Home Agent . . . . . . . . . . . . 32 6.7 Home Test to the Mobile Node . . . . . . . . . . . . . 32
5.9 Prefix Solicitation Message to the Home Agent . . . . 32 6.8 Home Test from the Home Agent . . . . . . . . . . . . 33
5.10 Prefix Solicitation Message from the Mobile Node . . . 32 6.9 Prefix Solicitation Message to the Home Agent . . . . 33
5.11 Prefix Advertisement Message to the Mobile Node . . . 32 6.10 Prefix Solicitation Message from the Mobile Node . . . 33
5.12 Prefix Advertisement Message from the Home Agent . . . 33 6.11 Prefix Advertisement Message to the Mobile Node . . . 33
5.13 Payload Packet to the Home Agent . . . . . . . . . . . 33 6.12 Prefix Advertisement Message from the Home Agent . . . 34
5.14 Payload Packet from the Mobile Node . . . . . . . . . 33 6.13 Payload Packet to the Home Agent . . . . . . . . . . . 34
5.15 Payload Packet to the Mobile Node . . . . . . . . . . 33 6.14 Payload Packet from the Mobile Node . . . . . . . . . 34
5.16 Payload Packet from the Home Agent . . . . . . . . . . 33 6.15 Payload Packet to the Mobile Node . . . . . . . . . . 34
5.17 Establishing New Security Associations . . . . . . . . 33 6.16 Payload Packet from the Home Agent . . . . . . . . . . 34
5.18 Rekeying Security Associations . . . . . . . . . . . . 34 6.17 Establishing New Security Associations . . . . . . . . 34
5.19 Movements and Dynamic Keying . . . . . . . . . . . . . 35 6.18 Rekeying Security Associations . . . . . . . . . . . . 35
6. Implementation Considerations . . . . . . . . . . . . . . . 37 6.19 Movements and Dynamic Keying . . . . . . . . . . . . . 36
7. Security Considerations . . . . . . . . . . . . . . . . . . 39 7. Implementation Considerations . . . . . . . . . . . . . . . 38
Normative References . . . . . . . . . . . . . . . . . . . . 40 8. Security Considerations . . . . . . . . . . . . . . . . . . 40
Informative References . . . . . . . . . . . . . . . . . . . 41 Normative References . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 41 Informative References . . . . . . . . . . . . . . . . . . . 42
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 42
B. Changes from Previous Version . . . . . . . . . . . . . . . 43 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43
Intellectual Property and Copyright Statements . . . . . . . 44 B. Changes from Previous Version . . . . . . . . . . . . . . . 44
Intellectual Property and Copyright Statements . . . . . . . 45
1. Introduction 1. Introduction
This draft illustrates the use of IPsec in securing control traffic This document illustrates the use of IPsec in securing control
relating Mobile IPv6 [7]. In Mobile IPv6, a mobile node is always traffic relating to Mobile IPv6 [8]. In Mobile IPv6, a mobile node
expected to be addressable at its home address, whether it is is always expected to be addressable at its home address, whether it
currently attached to its home link or is away from home. The "home is currently attached to its home link or is away from home. The
address" is an IP address assigned to the mobile node within its home "home address" is an IP address assigned to the mobile node within
subnet prefix on its home link. While a mobile node is at home, its home subnet prefix on its home link. While a mobile node is at
packets addressed to its home address are routed to the mobile node's home, packets addressed to its home address are routed to the mobile
home link. 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 the subnet
prefix of a particular foreign link. The association between a prefix of a particular foreign link. The association between a
mobile node's home address and care-of address is known as a mobile node's home address and care-of address is known as a
"binding" for the mobile node. While away from home, a mobile node "binding" for the mobile node. While away from home, a mobile node
registers its primary care-of address with a router on its home link, registers its primary care-of address with a router on its home link,
requesting this router to function as the "home agent" for the mobile requesting this router to function as the "home agent" for the mobile
node. The mobile node performs this binding registration by sending node. The mobile node performs this binding registration by sending
skipping to change at page 4, line 41 skipping to change at page 4, line 41
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
mobile node. mobile node.
Mobile IPv6 tunnels payload packets between the mobile node and the Mobile IPv6 tunnels payload packets between the mobile node and the
home agent in both directions. This tunneling uses IPv6 home agent in both directions. This tunneling uses IPv6
encapsulation [6]. Where these tunnels need to be secured, they are encapsulation [7]. Where these tunnels need to be secured, they are
replaced by IPsec tunnels [1]. 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 draft 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, Confidentiality, 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. These threats are discussed in more
detail in Section 15.1 of the Mobile IPv6 base specification [7]. 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
[1] to protect control traffic between the home agent and the mobile [2] to protect control traffic between the home agent and the mobile
node. This control traffic consists of various messages carried by node. This control traffic consists of various messages carried by
the Mobility Header protocol in IPv6 [5]. The traffic takes the the Mobility Header protocol in IPv6 [6]. The traffic takes the
following forms: 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 [7]. 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 [7]. 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
agent for the purposes of prefix discovery, as described in agent for the purposes of prefix discovery, as described in
Sections 10.6 and 11.4 of the base specification [7]. 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
[7]. 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 an replay protection. The mobile node and the home agent must have a
security association to protect this traffic. Furthermore, the great security association to protect this traffic. Furthermore, great
care is needed when using IKE [4] to establish security associations care is needed when using IKE [5] to establish security associations
to Mobile IPv6 home agents. The right kind of addresses must used to Mobile IPv6 home agents. The right kind of addresses must be used
for transporting IKE. This is necessary to ensure that a Binding for transporting IKE. This is necessary to avoid circular
Update is not needed before the IKE exchange which is needed for dependencies in which the use of a Binding Update triggers the need
securing the Binding Update. for an IKE exchange that cannot complete prior to the Binding Update
having been completed.
Mobile IPv6 base document defines the main requirements the mobile The mobile IPv6 base document defines the main requirements the
nodes and home agents must follow when securing the above traffic. mobile nodes and home agents must follow when securing the above
This draft discusses these requirements in more depth, illustrates traffic. This document discusses these requirements in more depth,
the used packet formats, describes suitable configuration procedures, illustrates the used packet formats, describes suitable configuration
and shows how implementations can process the packets in the right procedures, and shows how implementations can process the packets in
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 2. Section 3 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 4 discusses how IPsec can be configured to use either manual or automatically established security associations. Section 6 shows
or automatically established security associations. Section 5 shows
examples of how packets are processed within the nodes. 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 2 and obey the support at least the formats described in Section 3 and obey the
rules in Section 3. The configuration and processing sections are rules in Section 4. The configuration and processing sections are
informative, and should only be considered as one possible way of informative, and should only be considered as one possible way of
providing the required functionality. providing the required functionality.
2. Packet Formats 2. Terminology
2.1 Binding Updates and Acknowledgements The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
3. Packet Formats
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 have at least the following headers in the following home agent MUST support at least the following headers in the
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
Mobility header Mobility header
Binding Update Binding Update
Alternative Care-of Address option (care-of address) Alternative Care-of Address option (care-of address)
skipping to change at page 7, line 43 skipping to change at page 8, line 43
Routing header (type 2) Routing header (type 2)
home address home address
ESP header ESP header
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 have 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
Mobility header Mobility header
Binding Update Binding Update
Alternative Care-of Address option (care-of address) Alternative Care-of Address option (care-of address)
The Binding Acknowledgement messages sent to the home address MUST The Binding Acknowledgement messages sent to the home address MUST
have 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
Mobility header Mobility header
Binding Acknowledgement Binding Acknowledgement
2.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 have at least the following headers in protected by IPsec, they MUST support at least the following headers
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
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
used as one of the gateway addresses in the security association. As
discussed in Section 4.3, this requires the home agent to update the
gateway address when the mobile node moves. Policy entries and
security association selectors stay the same, however, as the inner
packets do not change upon movements.
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 have at least the following headers are protected by IPsec, they MUST support at least the following
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
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 tunnel gateway address had changed. When the mobile
node adopts a new care-of address, its source address selection rules node adopts a new care-of address, its source address selection rules
will automatically adopt a new source address for outgoing tunnel will automatically adopt a new source address for outgoing tunnel
packets. packets. (The home agent accepts packets sent like this, as the
outer source address in tunnel packets is not checked.)
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 gateway address. When IKE is being used,
the mobile node runs it on top of its then current care-of address, the mobile node runs it on top of its then current care-of address,
and the resulting tunnel-mode security associations will use the same and the resulting tunnel-mode security associations will use the same
addresses as IKE was transported on. In order for the home agent to addresses as IKE was transported on. In order for the home agent to
be able to tunnel a Home Test message to the mobile node, it uses the be able to tunnel a Home Test message to the mobile node, it uses the
current care-of address as the destination of the tunnel packets, as current care-of address as the destination of the tunnel packets, as
if the home agent had modified the gateway address of the security if the home agent had modified the gateway address of the security
association used for this protection. This implies that the same association used for this protection. This implies that the same
security association can be used in multiple locations, and no new security association can be used in multiple locations, and no new
configuration or IKE rekeying is needed per movement. configuration or IKE rekeying is needed per movement.
2.3 Prefix Discovery 3.3 Prefix Discovery
If IPsec is used to protect prefix discovery, requests for prefix If IPsec is used to protect prefix discovery, requests for prefixes
from the mobile node to the home agent MUST have 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
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 have 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
ICMPv6 ICMPv6
Mobile Prefix Advertisement Mobile Prefix Advertisement
2.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
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 have at least the to the mobile node with IPsec protection, they MUST support at least
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
IPv6 header (source = correspondent node, IPv6 header (source = correspondent node,
destination = home address) destination = home address)
Any protocol Any protocol
3. 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
of packets. of packets.
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, and should not be taken as between home agents and mobile nodes. They should not be taken as
requirements on IPsec in generally is used by mobile nodes. requirements on how IPsec in general is used by mobile nodes.
3.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 security associations MUST be supported.
The configuration of the keys is expected to take place The configuration of the keys is expected to take place
out-of-band, for instance at the time the mobile node is 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 [4] 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 IPsec protection for 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 IPsec protection for 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 IPsec protection for the ICMPv6 messages related to prefix
discovery SHOULD be supported and used. discovery MUST be supported and SHOULD be used.
o IPsec protection of the payload packets tunneled between the o IPsec protection 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. protection MUST be supported for those protocols.
3.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.
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
skipping to change at page 12, line 23 skipping to change at page 13, line 23
is matched against IPsec security policy or selectors of a is matched against IPsec security policy or selectors of a
security association. security association.
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, the security policy database entries SHOULD be
defined specifically for the tunnel interface between the mobile defined specifically for the tunnel interface between the mobile
node and the home agent. That is, the policy entries are not node and the home agent. That is, the policy entries are not
generally applied on all traffic on the physical interface(s) of generally applied on all traffic on the physical interface(s) of
the nodes, but rather only on traffic that enters this tunnel. the nodes, but rather only on traffic that enters this tunnel.
o IP layer implementations are, in general, unable to ensure that a o The authentication of mobile nodes MAY be based either on machine
particular address of the machine is only used by the user or user credentials. Note that multi-user operating systems
authorized to use that address. Therefore, this specification typically allow all users of a node to use any of the IP addresses
requires that mobile nodes and home agents SHOULD use credentials assigned to the node. This limits the capability of the home
that are authorized to control all addresses given to the node. agent to restrict the use of a home address to a particular user
in such environment. Where user credentials are applied in a
multi-user environment, the configuration should authorize all
users of the node to control all home addresses assigned to the
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 SPD entries, which were used
for protecting tunneled traffic between the mobile node and the for protecting tunneled traffic between the mobile node and the
home agent become inactive. The corresponding security home agent become inactive. The corresponding security
associations could be stored or deleted depending on how they were associations could be stored or deleted depending on how they were
created. If the security associations were created dynamically created. If the security associations were created dynamically
using IKE, they are automatically deleted when they expire. If using IKE, they are automatically deleted when they expire. If
the security associations were created through manual the security associations were created through manual
skipping to change at page 12, line 50 skipping to change at page 14, line 6
associations protecting Binding Updates and Acknowledgements, and associations protecting Binding Updates and Acknowledgements, and
prefix discovery SHOULD not be deleted as they do not depend on prefix discovery SHOULD not be deleted as they do not depend on
care-of addresses and can be used again. 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 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
new security associations. It is outside the scope of this new security associations. It is outside the scope of this
specification to discuss automatic methods for this. specification to discuss automatic methods for this.
The following rules apply to home agents: The following rules apply to home agents:
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
skipping to change at page 13, line 34 skipping to change at page 14, line 38
home address. How these mappings are maintained is outside the home address. How these mappings are maintained is outside the
scope of this specification, but they may be maintained, for scope of this specification, but they may be maintained, for
instance, as a locally administered table in the home agent. If instance, as a locally administered table in the home agent. If
the phase 1 identity is a FQDN, secure forms of DNS may also be the phase 1 identity is a FQDN, secure forms of DNS may also be
used. 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. methods for this, if new home addresses are required.
3.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 SHOULD
use the Encapsulating Security Payload (ESP) [3] header in use the Encapsulating Security Payload (ESP) [4] header in
transport mode and MUST use a non-null payload authentication transport mode and MUST use a non-null payload authentication
algorithm to provide data origin authentication, connectionless algorithm to provide data origin authentication, connectionless
integrity and optional anti-replay protection. Note that integrity and optional anti-replay protection. Note that
Authentication Header (AH) [2] is also possible but for brevity Authentication Header (AH) [3] is also possible but for brevity is
not discussed in this specification. not discussed in this specification.
Care is needed when selecting suitable encryption algorithms for Mandatory support for encryption and integrity protection
ESP. Currently available integrity protection algorithms are in algorithms is as defined in RFC 2401 [2], RFC 2402 [3], and RFC
general considered to be secure. The encryption algorithm, DES, 2406 [4]. Care is needed when selecting suitable encryption
mandated by the current IPsec standards is not, however. This is algorithms for ESP, however. Currently available integrity
particularly problematic when security associations are configured protection algorithms are in general considered to be secure. The
manually, as the same key is used for a long time. encryption algorithm, DES, mandated by the current IPsec standards
is not, however. This is particularly problematic when security
associations are configured manually, as the same key is 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 authentication
algorithm MUST be applied. algorithm MUST be applied.
o IPsec AH [2] authenticator calculation MUST be performed as if a o IPsec AH [3] authenticator calculation MUST be performed as if a
packet with a Type 2 Routing header would have the home address in packet with a Type 2 Routing header would have the home address in
the IPv6 destination address field and the care-of address in the the IPv6 destination address field and the care-of address in the
Routing header. Type 2 Routing header should be treated by IPsec Routing header. Type 2 Routing header should be treated by IPsec
in the same manner as Type 0 Routing header. in the same manner as Type 0 Routing header.
o Similarly, the authenticator calculation MUST be performed as if a o Similarly, the authenticator calculation MUST be performed as if a
packet with a Home Address destination option would have the home packet with a Home Address destination option would have the home
address in the IPv6 source address field and the care-of address address in the IPv6 source address field and the care-of address
in the destination option. in the destination option.
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. As a result, the attacker would have redirected the
mobile node's traffic to another address. In order to prevent mobile node's traffic to another address. In order to prevent
this, Mobile IPv6 implementations SHOULD use the Alternate Care-of this, Mobile IPv6 implementations MUST use the Alternate Care-of
Address mobility option in all Binding Updates sent to the home Address mobility option in all Binding Updates sent to the home
agent. (Note that AH protects also the IPv6 header, and some agent. (Note that AH protects also the IPv6 header, and some
implementations might avoid the option if they know AH is being implementations might avoid the option if they know AH is being
used.) used.)
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.
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, special treatment is needed for the next packets sent changes as a result of an accepted Binding Update, special
using these security associations. The home agent MUST set the treatment is needed for the next packets sent using these security
new care-of address as the destination address of these packets, associations. The home agent MUST set the new care-of address as
as if the destination gateway address in the security association the destination address of these packets, as if the destination
had changed. gateway address in the security association had changed.
3.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 replay protection is required, dynamic keying MUST be used.
IPsec can provide replay protection only if dynamic keying is IPsec can provide replay protection only if dynamic keying is
used. This may not always be possible, and manual keying would be used. This may not always be possible, and manual keying would be
preferred in some cases. IPsec also does not guarantee correct preferred in some cases. IPsec also does not guarantee correct
ordering of packets, only that they have not been replayed. ordering of packets, only that they have not been replayed.
Because of this, sequence numbers within the Mobile IPv6 messages Because of this, sequence numbers within the Mobile IPv6 messages
ensure correct ordering. However, if a home agent reboots and ensure correct ordering. However, if a home agent reboots and
loses its state regarding the sequence numbers, replay attacks loses its state regarding the sequence numbers, replay attacks
become possible. The use of a key management mechanism together become possible. The use of a key management mechanism together
with IPsec can be used to prevent such replay attacks. with IPsec can be used to prevent such replay 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
determine 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.)
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 Where dynamic keying is used, the key management protocol MUST use
the care-of address as the source address in the protocol the care-of address as the source address in the protocol
exchanges with the mobile node's home agent. exchanges with the mobile node's home agent.
o Conversely, the IPsec security associations with the mobile node's o Conversely, the IPsec security associations with the mobile node's
home agent MUST be requested from the key management protocol with home agent MUST be requested from the key management protocol with
the home address as the mobile node's address. the home address as the mobile node's address.
The security associations for protecting Binding Updates and
Acknowledgements are requested for the Mobility header protocol in
transport mode and for specific IP addresses as endpoints.
Similarly, the security associations for protecting prefix
discovery are requested for the ICMPv6 protocol. Payload and
return routability protection requests security associations for a
specific tunnel interface and either the payload protocol or the
Mobility header protocol, in tunnel mode. In this case one
requested endpoint is an IP address and another one is a wildcard.
o If the mobile node has used IKE to establish security associations o If the mobile node has used IKE to establish security associations
with its home agent, it should follow the procedures discussed in with its home agent, it should follow the procedures discussed in
Section 11.7.1 and 11.7.3 of the base specification to determine Section 11.7.1 and 11.7.3 of the base specification to determine
whether the IKE endpoints can be moved or if rekeying is needed. whether the IKE endpoints can be moved or if rekeying is needed.
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 to establish security associations
with the mobile node, it should follow the procedures discussed in with the mobile node, it should follow the procedures discussed in
Section 10.3.1 and 10.3.2 of the base specification to determine Section 10.3.1 and 10.3.2 of the base specification to determine
whether the IKE endpoints can be moved or if rekeying is needed. whether the IKE endpoints can be moved or if rekeying is needed.
4. 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. Our examples assume the use of ESP,
but a similar configuration could also be used to protect the but a similar configuration could also be used to protect the
messages with AH. messages with AH.
Section 4.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 4.2 describes how to configure manually SPD and the SAD. Section 5.2 describes how to configure manually
keyed security associations, and Section 4.3 describes how to use keyed security associations, and Section 5.3 describes how to use
dynamic keying. dynamic keying.
4.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>
... ...
"-" <spdentry> "-" <spdentry>
skipping to change at page 17, line 44 skipping to change at page 18, line 44
"-" <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> |
"IF" <condition> "THEN CREATE" <pattern> | "IF" <condition> "THEN CREATE" <pattern> |
Where <condition> is an boolean expression about the fields of the Where <condition> is an 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 security association, and
<pattern> is a specification for an SA to be negotiated via IKE [4]. <pattern> is a specification for a security association to be
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> ","
skipping to change at page 18, line 24 skipping to change at page 19, line 24
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, <ahesp> is normally
"ESP" in our case but could also be "AH", <mode> is either "TUNNEL" "ESP" in our case but could also be "AH", <mode> is either "TUNNEL"
or "TRANSPORT", and <selectors> is a boolean expression about the or "TRANSPORT", and <selectors> is a boolean expression about the
fields of the IPv6 packet. fields of the IPv6 packet.
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".
4.2 Manual Configuration 5.2 Manual Configuration
4.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 in the mobile node mobile node and home Updates and Acknowledgements:
agent home agent:
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 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 SA2
skipping to change at page 19, line 41 skipping to change at page 20, line 41
THEN USE SA1 THEN USE 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
4.2.2 Return Routability Signaling In the above, "MH" refers to the protocol number for the Mobility
Header [8].
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:
mobile node SPD OUT: mobile node SPD OUT:
- IF interface = tunnel to home_agent_1 & - IF interface = tunnel to home_agent_1 &
source = home_address_1 & destination = any & source = home_address_1 & destination = any &
proto = MH proto = MH
skipping to change at page 20, line 41 skipping to change at page 21, line 41
source = home_address_1 & destination = any & source = home_address_1 & destination = any &
proto = MH proto = MH
THEN USE SA3 THEN USE SA3
home agent SAD: home agent SAD:
- SA4(OUT, spi_d, home_address_1, ESP, TUNNEL): - SA4(OUT, spi_d, home_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
4.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.
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 SA5.
mobile node SPD IN: mobile node SPD IN:
skipping to change at page 21, line 44 skipping to change at page 22, line 44
- 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 Note that the SPDs described above protect all ICMPv6 traffic between
the mobile node and the home agent. the mobile node and the home agent.
4.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.
skipping to change at page 22, line 42 skipping to change at page 23, line 42
source = home_address_1 & destination = any & source = home_address_1 & destination = any &
proto = X proto = X
THEN USE SA7 THEN USE SA7
home agent SAD: home agent SAD:
- SA8(OUT, spi_h, home_address_1, ESP, TUNNEL): - SA8(OUT, spi_h, home_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 [8] or If multicast group membership control protocols such as MLDv1 [9] or
MLDv2 [11] need to be protected, these packets may use a link-local MLDv2 [12] need to be protected, these packets may use a link-local
address rather than the home address of the mobile node. In this address rather than the home address of the mobile node. In this
case the source and destination can be left as a wildcard and the SPD case the source and destination can be left as a wildcard and the SPD
entries will work solely based on the used interface and the entries will work solely based on the used interface and the
protocol, which is ICMPv6 for both MLDv1 and MLDv2. protocol, which is ICMPv6 for both MLDv1 and MLDv2.
Similar problems are encountered when stateful address Similar problems are encountered when stateful address
autoconfiguration protocols such as DHCPv6 [9] 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.
4.3 Dynamic Keying Support for multiple layers of encapsulation (such as ESP
encapsulated in ESP) is not required by RFC 2401 [2] and is also
otherwise often problematic. It is therefore useful to avoid setting
the protocol X in the above entries to either AH or ESP.
5.3 Dynamic Keying
In this section we show an example configuration that uses IKE to In this section we show an example configuration that uses IKE to
negotiate security associations. negotiate security associations.
4.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 CREATE ESP TRANSPORT SA: local phase 1 identity = user_1
mobile node SPD IN: mobile node SPD IN:
skipping to change at page 24, line 10 skipping to change at page 25, line 15
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 certificate authority.
4.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 = 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 CREATE ESP TUNNEL SA: gateway = home_agent_1 &
local phase 1 identity = user_1 local phase 1 identity = user_1
skipping to change at page 24, line 43 skipping to change at page 25, line 48
THEN CREATE ESP TUNNEL SA: gateway = home_address_1 & THEN CREATE ESP TUNNEL SA: gateway = 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 = 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 CREATE ESP TUNNEL SA: gateway = home_address_1 &
peer phase 1 identity = user_1 peer phase 1 identity = user_1
One difference to the above is that we specified the tunnel gateway Here we specified the gateway address for the security association as
address, as we need to use a different address for that than those the home address for the mobile node. However, as required by
appearing in the packets. Section 4.3 the packets will actually be sent to the current care-of
address. In order to avoid writing dynamically changing information
to the SPD entries, the above has been written with the home address
as the gateway.
4.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
skipping to change at page 25, line 27 skipping to change at page 26, line 34
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 CREATE ESP TRANSPORT SA: 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 CREATE ESP TRANSPORT SA: peer phase 1 identity = user_1
4.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 = 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 CREATE ESP TUNNEL SA: gateway = home_agent_1 &
skipping to change at page 27, line 5 skipping to change at page 28, line 5
THEN CREATE ESP TUNNEL SA: gateway = home_address_1 & THEN CREATE ESP TUNNEL SA: gateway = 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 = 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 CREATE ESP TUNNEL SA: gateway = home_address_1 &
peer phase 1 identity = user_1 peer phase 1 identity = user_1
5. Processing Steps within a Node 6. Processing Steps within a Node
5.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 policy data base on
the mobile node and we make a note that IPsec must be applied. the mobile 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 [7]. 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
Binding Update Binding Update
Step 4. Finally, IPsec headers are added and the necessary Step 4. Finally, IPsec headers are added and the necessary
authenticator values are calculated: authenticator values are calculated:
skipping to change at page 28, line 5 skipping to change at page 29, line 5
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
5.2 Binding Update from the Mobile Node 6.2 Binding Update from the Mobile Node
Step 1. The following packet is received at the home agent: Step 1. The following packet is received at the home agent:
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 28, line 42 skipping to change at page 29, line 42
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 security association selectors
(source = home address, destination = home agent, proto = MH). (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.
5.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
remember that IPsec has to be applied. remember that IPsec has to be applied.
Step 3. Then, we add the necessary Route Headers but do not change Step 3. Then, we add the necessary Route Headers but do not change
the addresses yet, as described in Section 9.6 of the base the addresses yet, as described in Section 9.6 of the base
specification [7]. This results in: specification [8]. This results 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. We apply IPsec: Step 4. We apply IPsec:
skipping to change at page 29, line 37 skipping to change at page 30, line 37
addresses in the IPv6 header and the Route header: addresses in the IPv6 header and the Route header:
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
5.4 Binding Acknowledgement from the Home Agent 6.4 Binding Acknowledgement from the Home Agent
Step 1. The following packet is received at the mobile node Step 1. The following packet is received at the mobile node
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
skipping to change at page 30, line 27 skipping to change at page 31, line 27
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 security association selectors
(source = home agent, destination = home address, proto = MH). (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.
5.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)
Mobility header Mobility header
Home Test Init Home Test Init
Step 2. Mobile IPv6 determines that this packet should go to the Step 2. Mobile IPv6 determines that this packet should go to the
tunnel to the home agent. tunnel to the home agent.
skipping to change at page 31, line 7 skipping to change at page 32, line 7
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 no longer satisfies the criteria that made it
enter the tunnel, and it is sent directly to the home agent. enter the tunnel, and it is sent directly to the home agent.
5.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
skipping to change at page 31, line 31 skipping to change at page 32, line 31
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 selectors and the packet
can be processed further. 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.
5.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)
Mobility Header Mobility Header
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
skipping to change at page 32, line 16 skipping to change at page 33, line 16
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 no longer satisfies the criteria that made it
enter the tunnel, and it is sent directly to the care-of address. enter the tunnel, and it is sent directly to the care-of address.
5.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
skipping to change at page 32, line 40 skipping to change at page 33, line 40
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 security association selectors (source =
any, destination = home address). any, destination = home address).
Step 4. The packet is given to Mobile IPv6 processing. Step 4. The packet is given to Mobile IPv6 processing.
5.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 5.1. This procedure is similar to the one presented in Section 6.1.
5.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 5.2. This procedure is similar to the one presented in Section 6.2.
5.11 Prefix Advertisement Message to the Mobile Node 6.11 Prefix Advertisement Message to the Mobile Node
This procedure is similar to the one presented in Section 5.3. This procedure is similar to the one presented in Section 6.3.
5.12 Prefix Advertisement Message from the Home Agent 6.12 Prefix Advertisement Message from the Home Agent
This procedure is similar to the one presented in Section 5.4. This procedure is similar to the one presented in Section 6.4.
5.13 Payload Packet to the Home Agent 6.13 Payload Packet to the Home Agent
This procedure is similar to the one presented in Section 5.5. This procedure is similar to the one presented in Section 6.5.
5.14 Payload Packet from the Mobile Node 6.14 Payload Packet from the Mobile Node
This procedure is similar to the one presented in Section 5.6. This procedure is similar to the one presented in Section 6.6.
5.15 Payload Packet to the Mobile Node 6.15 Payload Packet to the Mobile Node
This procedure is similar to the one presented in Section 5.7. This procedure is similar to the one presented in Section 6.7.
5.16 Payload Packet from the Home Agent 6.16 Payload Packet from the Home Agent
This procedure is similar to the one presented in Section 5.8. This procedure is similar to the one presented in Section 6.8.
5.17 Establishing New Security Associations 6.17 Establishing New Security Associations
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 IKE is initiated. The IKE packets are sent as
shown in the following examples. The first packet is an example of shown in the following examples. The first packet is an example of
an IKE packet sent from the mobile node, and the second one is frokm an IKE packet sent from the mobile node, and the second one is from
the home agent. The examples shows also that the phase 1 identity the home agent. The examples shows also that the phase 1 identity
used for the mobile node is a FQDN. 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
skipping to change at page 34, line 26 skipping to change at page 35, line 26
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
IKE IKE
... IDcr = ID_IPV6_ADDR home agent ... ... IDcr = ID_IPV6_ADDR home agent ...
Step 4. The remaining steps are as shown in Section 5.1. Step 4. The remaining steps are as shown in Section 6.1.
5.18 Rekeying Security Associations 6.18 Rekeying Security Associations
Step 1. The mobile node and the home agent have existing security Step 1. The mobile node and the home agent have existing security
associations. Either side may decide at any time that the security associations. Either side may decide at any time that the security
associations need to be rekeyed, for instance, because the specified associations need to be rekeyed, for instance, because the specified
lifetime is approaching. lifetime is approaching.
Step 2. Mobility header packets sent during rekey may be protected Step 2. Mobility header packets sent during rekey may be protected
by the existing security associations. by the existing security associations.
Step 3. When the rekeying is finished, new security associations are Step 3. When the rekeying is finished, new security associations are
skipping to change at page 35, line 14 skipping to change at page 36, line 14
Since cryptographic acceleration hardware may only be able to handle Since cryptographic acceleration hardware may only be able to handle
a limited number of active security associations, security a limited number of active security associations, security
associations may be deleted via IKE in order to keep the number of associations may be deleted via IKE in order to keep the number of
active cryptographic contexts to a minimum. Such deletions should active cryptographic contexts to a minimum. Such deletions should
not be interpreted as a sign of losing a contact to the peer or as a not be interpreted as a sign of losing a contact to the peer or as a
reason to remove a binding. Rather, if additional traffic needs to reason to remove a binding. Rather, if additional traffic needs to
be sent, it is preferable to bring up another security association to be sent, it is preferable to bring up another security association to
protect it. protect it.
5.19 Movements and Dynamic Keying 6.19 Movements and Dynamic Keying
In this section we describe the sequence of events that relate to In this section we describe the sequence of events that relate to
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.
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 MH traffic to and from the home security associations for protecting Mobility Header traffic to and
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
are in tunnel mode and their endpoint in the mobile node side is are in tunnel mode and their endpoint in the mobile node side is
care-of address B. For the purposes of our example, this step uses care-of address B. For the purposes of our example, this step uses
the phase 1 connection established in Step 2. Multiple phase 1 the phase 1 connection established in Step 2. Multiple phase 1
connections are also possible. connections are also possible.
skipping to change at page 36, line 13 skipping to change at page 37, line 13
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 destination gateway address in
the security association had changed. 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 establish a new IKE phase 1 on
top of the care-of address C. This capability to change the IKE 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 [7] in the Binding Update and Binding Mobility Capability (K) flag [8] in the Binding Update and Binding
Acknowledgement messages. Acknowledgement messages.
Step 11. 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.
6. Implementation Considerations 7. Implementation Considerations
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. What is needed is that the home agent must act as
if the gateway address of a security association to the mobile node if the gateway address of a security association to the mobile node
would have changed. Implementations are free to choose any would have changed. Implementations are free to choose any
skipping to change at page 39, line 5 skipping to change at page 40, line 5
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. Nevertheless, where the problem appears, one solution is to
replace the firewalls or routers with equipment that can properly replace the firewalls or routers with equipment that can properly
support fragments. If this cannot be done, it may help to store the support fragments. If this cannot be done, it may help to store the
peer certificates locally, or to obtain them through other means. peer certificates locally, or to obtain them through other means.
7. Security Considerations 8. Security Considerations
The Mobile IPv6 base specification [7] 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.
Normative References Normative References
[1] Kent, S. and R. Atkinson, "Security Architecture for the [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
[2] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, [3] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998. November 1998.
[3] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload [4] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998. (ESP)", RFC 2406, November 1998.
[4] 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.
[5] 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.
[6] 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.
[7] 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-20 (work in progress), January IPv6", draft-ietf-mobileip-ipv6-21 (work in progress), February
2003. 2003.
Informative References Informative References
[8] 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.
[9] 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.
[10] 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.
[11] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 [12] 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 42, line 7 skipping to change at page 43, line 7
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 Michael Thomas, Kevin Miles, Cheryl The authors would like to thank Greg O'Shea, Michael Thomas, Kevin
Madson, Bernard Aboba, Erik Nordmark, and Gabriel Montenegro for Miles, Cheryl Madson, Bernard Aboba, Erik Nordmark, and Gabriel
interesting discussions in this problem space. Montenegro 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 draft from version 1: The following changes have been made to this document from version
02:
o The validation of a Home Address destination option in the
presense of a Binding Update and IPsec encapsulation has been
specified (tracked issue 216).
o The requirements for the IKE phase 2 authorization check have been o It is now better explained why the mobile node can change its
made explicit (tracked issue 216). source address in security associations before such a change is
told to the home agent (tracked issue 249).
o More details have been provided on how IKE processing takes place o The support for protecting prefix discovery with IPsec has been
(tracked issue 195). made mandatory, but use is still a SHOULD (tracked issue 249).
o Requirements for treating necessary policy and security o Requirements for security association and policy configuration for
association modifications upon new prefixes have been explained new home addresses received through prefix discovery have been
better (tracked issue 195). specified (tracked issue 243).
o The Key Management Movement Capability (K) bit has been added to o IPsec protocol and mode requirements have now been stated as
the Binding Update and Acknowledgement messages (tracked issue minimal requirements and no longer prevent the use of other
194). protocols (AH) and modes (tracked issue 228).
o More details have been provided on how IKE end-points change o The specification explicitly discourages the use of nested IPsec
during movements (tracked issue 194). encapsulation (tracked issue 219).
o The results of the security review have been adopted (tracked o The different types of requests for phase 2 security associations
issue 189). The modifications include specifying only the use of have been explained in the requirements section. This relates to
ESP for protecting signaling. using IKE for creating security associations for Binding Update
protection or other tasks (tracked issue 219).
o Many editorial modifications. o Many editorial modifications have been performed.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
 End of changes. 

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