draft-ietf-mobileip-mipv6-ha-ipsec-01.txt   draft-ietf-mobileip-mipv6-ha-ipsec-02.txt 
Network Working Group Jari Arkko Network Working Group J. Arkko
INTERNET-DRAFT Ericsson Internet-Draft Ericsson
Category: Standards Track Vijay Devarapalli Expires: July 21, 2003 V. Devarapalli
<draft-ietf-mobileip-mipv6-ha-ipsec-01.txt> Nokia Nokia Research Center
Francis Dupont F. Dupont
ENST Bretagne ENST Bretagne
15 October 2002 January 20, 2003
Using IPsec to Protect Mobile IPv6 Signaling between Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and
Mobile Nodes and Home Agents Home Agents
draft-ietf-mobileip-mipv6-ha-ipsec-02.txt
1. Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance This document is an Internet-Draft and is in full conformance with
with all provisions of Section 10 of RFC2026. Internet-Drafts are all provisions of Section 10 of RFC2026.
working documents of the Internet Engineering Task Force (IETF),
its areas, and its working groups. Note that other groups may
also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are working documents of the Internet Engineering
months and may be updated, replaced, or made obsolete by other Task Force (IETF), its areas, and its working groups. Note that
documents at any time. It is inappropriate to use Internet- other groups may also distribute working documents as
Drafts as reference material or to cite them other than as work Internet-Drafts.
in progress.
The list of current Internet-Drafts may be found at Internet-Drafts are draft documents valid for a maximum of six months
http://www.ietf.org/ietf/1id-abstracts.txt and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of Internet-Draft Shadow Directories may be found at The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
The distribution of this memo is unlimited. It is filed as This Internet-Draft will expire on July 21, 2003.
<draft-ietf-mobileip-mipv6-haipsec-00.txt>, and expires March
10, 2003. Please send comments to the author or to the Mobile IP
working group mailing list.
2. Abstract Copyright Notice
Mobile IPv6 uses IPsec to protect signaling between the home Copyright (C) The Internet Society (2003). All Rights Reserved.
agent and the mobile node. Mobile IPv6 base document defines the
main requirements these nodes must follow. This draft discusses
these requirements in more depth, illustrates the used packet
formats, describes suitable configuration procedures, and shows
how implementations can process the packets in the right order.
3. Contents Abstract
1. Status of this Memo..................................1 Mobile IPv6 uses IPsec to protect signaling between the home agent
2. Abstract.............................................1 and the mobile node. Mobile IPv6 base document defines the main
3. Contents.............................................2 requirements these nodes must follow. This draft discusses these
4. Introduction.........................................3 requirements in more depth, illustrates the used packet formats,
5. Packet Formats.......................................4 describes suitable configuration procedures, and shows how
5.1. Binding Updates and Acknowledgements.................4 implementations can process the packets in the right order.
5.2. Return Routability Signaling.........................5
5.3. Prefix Discovery.....................................5
5.4. Payload Packets......................................5
6. Requirements.........................................7
7. Example Configurations...............................10
7.1. Format...............................................10
7.2. Manual Configuration.................................11
7.3. Dynamic Keying.......................................14
7.4. Mobile Node Returning Home...........................17
8. Processing Steps within a Node.......................18
8.1. Binding Update to the Home Agent.....................18
8.2. Binding Update from the Mobile Node..................18
8.3. Binding Acknowledgement to the Mobile Node...........19
8.4. Binding Acknowledgement from the Home Agent..........20
8.5. Home Test Init to the Home Agent.....................20
8.6. Home Test Init from the Mobile Node..................21
8.7. Home Test to the Mobile Node.........................21
8.8. Home Test from the Home Agent........................22
8.9. Prefix Solicitation Message to the Home Agent........22
8.10. Prefix Solicitation Message from the Mobile Node.....22
8.11. Prefix Advertisement Message to the Mobile Node......22
8.12. Prefix Advertisement Message from the Home Agent.....23
8.13. Payload Packet to the Home Agent.....................23
8.14. Payload Packet from the Mobile Node..................23
8.15. Payload Packet to the Mobile Node....................23
8.16. Payload Packet from the Home Agent...................23
9. Implementation Considerations........................24
10. Security Considerations..............................25
11. References...........................................26
12. Acknowledgements.....................................27
13. Author's Address.....................................28
4. Introduction Table of Contents
Mobile IPv6 [1] uses IPsec [2] to protect signaling between the 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
home agent and the mobile node. This signaling consists of 2. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 7
various messages carried by the Mobility Header protocol in 2.1 Binding Updates and Acknowledgements . . . . . . . . . 7
IPv6. This signaling traffic takes the following forms: 2.2 Return Routability Signaling . . . . . . . . . . . . . 8
2.3 Prefix Discovery . . . . . . . . . . . . . . . . . . . 9
2.4 Payload Packets . . . . . . . . . . . . . . . . . . . 9
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1 Mandatory Support . . . . . . . . . . . . . . . . . . 11
3.2 Policy Requirements . . . . . . . . . . . . . . . . . 11
3.3 IPsec Protocol Processing . . . . . . . . . . . . . . 13
3.4 Dynamic Keying . . . . . . . . . . . . . . . . . . . . 15
4. Example Configurations . . . . . . . . . . . . . . . . . . . 17
4.1 Format . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2 Manual Configuration . . . . . . . . . . . . . . . . . 18
4.2.1 Binding Updates and Acknowledgements . . . . . . 18
4.2.2 Return Routability Signaling . . . . . . . . . . 19
4.2.3 Prefix Discovery . . . . . . . . . . . . . . . . 20
4.2.4 Payload Packets . . . . . . . . . . . . . . . . 21
4.3 Dynamic Keying . . . . . . . . . . . . . . . . . . . . 23
4.3.1 Binding Updates and Acknowledgements . . . . . . 23
4.3.2 Return Routability Signaling . . . . . . . . . . 24
4.3.3 Prefix Discovery . . . . . . . . . . . . . . . . 24
4.3.4 Payload Packets . . . . . . . . . . . . . . . . 25
5. Processing Steps within a Node . . . . . . . . . . . . . . . 27
5.1 Binding Update to the Home Agent . . . . . . . . . . . 27
5.2 Binding Update from the Mobile Node . . . . . . . . . 28
5.3 Binding Acknowledgement to the Mobile Node . . . . . . 28
5.4 Binding Acknowledgement from the Home Agent . . . . . 29
5.5 Home Test Init to the Home Agent . . . . . . . . . . . 30
5.6 Home Test Init from the Mobile Node . . . . . . . . . 31
5.7 Home Test to the Mobile Node . . . . . . . . . . . . . 31
5.8 Home Test from the Home Agent . . . . . . . . . . . . 32
5.9 Prefix Solicitation Message to the Home Agent . . . . 32
5.10 Prefix Solicitation Message from the Mobile Node . . . 32
5.11 Prefix Advertisement Message to the Mobile Node . . . 32
5.12 Prefix Advertisement Message from the Home Agent . . . 33
5.13 Payload Packet to the Home Agent . . . . . . . . . . . 33
5.14 Payload Packet from the Mobile Node . . . . . . . . . 33
5.15 Payload Packet to the Mobile Node . . . . . . . . . . 33
5.16 Payload Packet from the Home Agent . . . . . . . . . . 33
5.17 Establishing New Security Associations . . . . . . . . 33
5.18 Rekeying Security Associations . . . . . . . . . . . . 34
5.19 Movements and Dynamic Keying . . . . . . . . . . . . . 35
6. Implementation Considerations . . . . . . . . . . . . . . . 37
7. Security Considerations . . . . . . . . . . . . . . . . . . 39
Normative References . . . . . . . . . . . . . . . . . . . . 40
Informative References . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 41
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42
B. Changes from Previous Version . . . . . . . . . . . . . . . 43
Intellectual Property and Copyright Statements . . . . . . . 44
(1) Binding Update and Acknowledgement messages exchanged 1. Introduction
between the mobile node and the home agent, as described in
Sections 10.2, 10.3, 11.6.1, and 11.6.3 of [1].
(2) Home Test Init and Home Test messages that pass through This draft illustrates the use of IPsec in securing control traffic
the home agent on their way to a correspondent node, as relating Mobile IPv6 [7]. In Mobile IPv6, a mobile node is always
described in Section 10.7 of [1]. expected to be addressable at its home address, whether it is
currently attached to its home link or is away from home. The "home
address" is an IP address assigned to the mobile node within its home
subnet prefix on its home link. While a mobile node is at home,
packets addressed to its home address are routed to the mobile node's
home link.
(3) ICMPv6 messages exchanged between the mobile node and While a mobile node is attached to some foreign link away from home,
the home agent for the purposes of prefix discovery, as it is also addressable at a care-of addresses. A care-of address is
described in Sections 10.9.3., 11.3.3, and 11.3.4 of [1]. an IP address associated with a mobile node that has the subnet
prefix of a particular foreign link. The association between 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
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
node. The mobile node performs this binding registration by sending
a "Binding Update" message to the home agent. The home agent replies
to the mobile node by returning a "Binding Acknowledgement" message.
The nodes MAY also optionally protect payload traffic passing Any other nodes communicating with a mobile node are referred to as
through the home agent, as described in Section 5.3 of [1]. "correspondent nodes". Mobile nodes can provide information about
their current location to correspondent nodes, again using Binding
Updates and Acknowledgements. Additionally, return routability test
is performed between the mobile node, home agent, and the
correspondent node in order to authorize the establishment of the
binding. Packets between the mobile node and the correspondent node
are either tunneled via the home agent, or sent directly if a binding
exists in the correspondent node for the current location of the
mobile node.
Signaling between the mobile node and the home agent requires Mobile IPv6 tunnels payload packets between the mobile node and the
message authentication, integrity, correct ordering and replay home agent in both directions. This tunneling uses IPv6
protection. The mobile node and the home agent must have an encapsulation [6]. Where these tunnels need to be secured, they are
security association to protect this signaling. replaced by IPsec tunnels [1].
Mobile IPv6 base document defines the main requirements the Mobile IPv6 also provides support for the reconfiguration of the home
mobile nodes and home agents must follow when securing the above network. Here the home subnet prefixes may change over time. Mobile
traffic. This draft discusses these requirements in more depth, nodes can learn new information about home subnet prefixes through
illustrates the used packet formats, describes suitable the "prefix discovery" mechanism.
configuration procedures, and shows how implementations can
process the packets in the right order.
We begin our description by showing the required wire formats for This draft discusses security mechanisms for the control traffic
the protected packets in Section 5. Section 6 describes rules between the mobile node and the home agent. If this traffic is not
which associated Mobile IPv6, IPsec, and IKE implementations must protected, mobile nodes and correspondent nodes are vulnerable to
observe. Section 7 discusses how IPsec can be configured to use Man-in-the-Middle, Hijacking, Confidentiality, Impersonation, and
either manual or automatically established security associations. Denial-of-Service attacks. Any third parties are also vulnerable to
Section 8 shows examples of how packets are processed within the Denial-of-Service attacks. These threats are discussed in more
nodes. detail in Section 15.1 of the Mobile IPv6 base specification [7].
All implementations of Mobile IPv6 mobile node and home agent In order to avoid these attacks, the base specification uses IPsec
MUST support the formats described in Section 5 and obey the [1] to protect control traffic between the home agent and the mobile
rules in Section 6. node. This control traffic consists of various messages carried by
the Mobility Header protocol in IPv6 [5]. The traffic takes the
following forms:
5. Packet Formats o Binding Update and Acknowledgement messages exchanged between the
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].
In this section we describe the order of headers within the o Return routability messages Home Test Init and Home Test that pass
protected and tunneled packets over the wire. Support for the through the home agent on their way to a correspondent node, as
described ordering is mandatory for nodes that implement Mobile described in Section 10.4.6 of the base specification [7].
IPv6 mobile node or home agent functionality.
5.1. Binding Updates and Acknowledgements o ICMPv6 messages exchanged between the mobile node and the home
agent for the purposes of prefix discovery, as described in
Sections 10.6 and 11.4 of the base specification [7].
When the mobile node is away from its home, the BUs sent by it to The nodes may also optionally protect payload traffic passing through
the home agent MUST have at least the following headers in the the home agent, as described in Section 5.3 of the base specification
following order: [7]. If multicast group membership control protocols or stateful
address autoconfiguration protocols are supported, payload data
protection support is required.
IPv6 header (source = care-of address, destination = home agent) The control traffic between the mobile node and the home agent
requires message authentication, integrity, correct ordering and
replay protection. The mobile node and the home agent must have an
security association to protect this traffic. Furthermore, the great
care is needed when using IKE [4] to establish security associations
to Mobile IPv6 home agents. The right kind of addresses must used
for transporting IKE. This is necessary to ensure that a Binding
Update is not needed before the IKE exchange which is needed for
securing the Binding Update.
Mobile IPv6 base document defines the main requirements the mobile
nodes and home agents must follow when securing the above traffic.
This draft discusses these requirements in more depth, illustrates
the used packet formats, describes suitable configuration procedures,
and shows how implementations can process the packets in the right
order.
We begin our description by showing the required wire formats for the
protected packets in Section 2. Section 3 describes rules which
associated Mobile IPv6, IPsec, and IKE implementations must observe.
Section 4 discusses how IPsec can be configured to use either manual
or automatically established security associations. Section 5 shows
examples of how packets are processed within the nodes.
All implementations of Mobile IPv6 mobile node and home agent MUST
support at least the formats described in Section 2 and obey the
rules in Section 3. The configuration and processing sections are
informative, and should only be considered as one possible way of
providing the required functionality.
2. Packet Formats
2.1 Binding Updates and Acknowledgements
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
order:
IPv6 header (source = care-of address,
destination = home agent)
Destination Options header Destination Options header
Home Address option (home address) Home Address option (home address)
ESP header or AH header ESP header
Mobility header Mobility header
Binding Update Binding Update
Alternative Care-of Address option (care-of address)
The Binding Acknowledgements sent back to the mobile node when it Note that the Alternative Care-of Address option is used to ensure
is away from home MUST have at least the following headers in the that the care-of address is protected by ESP. The home agent
considers the address within this option as the current care-of
address for the mobile node.
The Binding Acknowledgements sent back to the mobile node when it is
away from home MUST have at least the following headers in the
following order: following order:
IPv6 header (source = home agent, destination = care-of address) IPv6 header (source = home agent,
destination = care-of address)
Routing header (type 2) Routing header (type 2)
home address home address
ESP header or AH header ESP header
Mobility header Mobility header
Binding Acknowledgement Binding Acknowledgement
When the mobile node is at home, the above rules are different as When the mobile node is at home, the above rules are different as the
the mobile node can use its home address as a source address. mobile node can use its home address as a source address. This
This typically happens for the de-registration Binding Update typically happens for the de-registration Binding Update when the
when the mobile is returning home. In this situation, the Binding mobile is returning home. In this situation, the Binding Updates
Updates MUST have at least the following headers in the following MUST have at least the following headers in the following order:
order:
IPv6 header (source = home address, destination = home agent) IPv6 header (source = home address,
ESP header or AH header destination = home agent)
ESP header
Mobility header Mobility header
Binding Update Binding Update
Alternative Care-of Address option (care-of address)
The Binding Acknowledgement messages sent to the home address The Binding Acknowledgement messages sent to the home address MUST
MUST have at least the following headers in the following order: have at least the following headers in the following order:
IPv6 header (source = home agent, destination = home address) IPv6 header (source = home agent,
ESP header or AH header destination = home address)
ESP header
Mobility header Mobility header
Binding Acknowledgement Binding Acknowledgement
5.2. Return Routability Signaling 2.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 protected by IPsec, they MUST have at least the following headers in
in the following order: the following order:
IPv6 header (source = care-of address, destination = home agent) IPv6 header (source = care-of address,
destination = home agent)
ESP header ESP header
IPv6 header (source = home address, destination = correspondent node) IPv6 header (source = home address,
destination = correspondent node)
Mobility Header Mobility Header
Home Test Init Home Test Init
Similarly, when the Home Test messages tunneled from the home Similarly, when the Home Test messages tunneled from the home agent
agent are protected by IPsec, they MUST have at least the are protected by IPsec, they MUST have at least the following headers
following headers in the following order: in the following order:
IPv6 header (source = home agent, destination = care-of address) IPv6 header (source = home agent,
destination = care-of address)
ESP header ESP header
IPv6 header (source = correspondent node, destination = home address) IPv6 header (source = correspondent node,
destination = home address)
Mobility Header Mobility Header
Home Test Home Test
Note that these formats rely on the SA destination address The format used to protect return routability packets relies on the
(tunnel gateway address) to change for the mobile node as it destination of the tunnel packets to change for the mobile node as it
moves. This is discussed further in the requirements in Section 6. moves. The home agent's address stays the same, but the mobile
node's address changes upon movements, as if the security
association's tunnel gateway address had changed. When the mobile
node adopts a new care-of address, its source address selection rules
will automatically adopt a new source address for outgoing tunnel
packets.
5.3. Prefix Discovery The process is more complicated in the home agent side, as the home
agent has stored the previous care-of address in its Security
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,
and the resulting tunnel-mode security associations will use the same
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
current care-of address as the destination of the tunnel packets, as
if the home agent had modified the gateway address of the security
association used for this protection. This implies that the same
security association can be used in multiple locations, and no new
configuration or IKE rekeying is needed per movement.
2.3 Prefix Discovery
If IPsec is used to protect prefix discovery, requests for prefix If IPsec is used to protect prefix discovery, requests for prefix
from the mobile node to the home agent MUST have at least the from the mobile node to the home agent MUST have at least the
following headers in the following order. following headers in the following order.
IPv6 header (source = care-of address, destination = home agent) IPv6 header (source = care-of address,
destination = home agent)
Destination Options header Destination Options header
Home Address option (home address) Home Address option (home address)
ESP header or AH header ESP header
ICMPv6 ICMPv6
Mobile Prefix Solicitation Mobile Prefix Solicitation
Again if IPsec is used, solicited and unsolicited prefix Again if IPsec is used, solicited and unsolicited prefix information
information advertisements from the home agent to the mobile node advertisements from the home agent to the mobile node MUST have at
MUST have at least the following headers in the following order. least the following headers in the following order.
IPv6 header (source = home agent, destination = care-of address) IPv6 header (source = home agent,
destination = care-of address)
Routing header (type 2) Routing header (type 2)
home address home address
ESP header or AH header ESP header
ICMPv6 ICMPv6
Mobile Prefix Advertisement Mobile Prefix Advertisement
5.4. Payload Packets 2.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 agent from the mobile node, a similar format is used as in the case
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 Mobility Header these packets may contain any legal IPv6 protocol(s):
protocol(s), and it is possible to use both AH and ESP for the
protection:
IPv6 header (source = care-of address, destination = home agent) IPv6 header (source = care-of address,
ESP header or AH header destination = home agent)
IPv6 header (source = home address, destination = correspondent node) ESP header
IPv6 header (source = home address,
destination = correspondent node)
Any protocol Any protocol
Similarly, when the payload packets are tunneled from the home Similarly, when the payload packets are tunneled from the home agent
agent to the mobile node with IPsec protection, they MUST have at to the mobile node with IPsec protection, they MUST have at least the
least the following headers in the following order: following headers in the following order:
IPv6 header (source = home agent, destination = care-of address) IPv6 header (source = home agent,
ESP header or AH header destination = care-of address)
IPv6 header (source = correspondent node, destination = home address) ESP header
IPv6 header (source = correspondent node,
destination = home address)
Any protocol Any protocol
6. Requirements 3. 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 nodes and home agents. These rules are necessary in order for it to
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 guarantee sufficient security, and to ensure correct processing order
order of packets. of packets.
We will start with the main requirements: The rules in the following sections apply only to the communications
between home agents and mobile nodes, and should not be taken as
requirements on IPsec in generally is used by mobile nodes.
- IPsec protection for Binding Updates and Acknowledgements 3.1 Mandatory Support
between the mobile node and home agent MUST be supported and
MUST be used.
- IPsec protection for the Home Test Init and Home Test The following requirements apply to both home agents and mobile
messages tunneled between the mobile node and home agent nodes:
MUST be supported and SHOULD be used.
- IPsec protection for the ICMPv6 messages related to prefix o Manual configuration of security associations MUST be supported.
discovery MUST be supported and SHOULD be used. The configuration of the keys is expected to take place
out-of-band, for instance at the time the mobile node is
configured to use its home agent.
- IPsec protection of the payload packets tunneled between o Automatic key management with IKE [4] MAY be supported. Only
the mobile node and home agent MAY be supported and used. 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
several improvements in this specific application.
- Manual configuration of security associations MUST be o IPsec protection for Binding Updates and Acknowledgements between
supported and dynamic establishment MAY be supported. the mobile node and home agent MUST be supported and MUST be used.
The following rules apply to both home agents and mobile nodes: o IPsec protection for the Home Test Init and Home Test messages
tunneled between the mobile node and home agent MUST be supported
and SHOULD be used.
- When ESP is used for protecting ICMPv6 or Mobility Header o IPsec protection for the ICMPv6 messages related to prefix
messages, a non-null authentication algorithm MUST be discovery SHOULD be supported and used.
applied.
- When ESP is used for protecting tunneled Home Test Init o IPsec protection of the payload packets tunneled between the
and Home Test messages, a non-null encryption algorithm and mobile node and home agent MAY be supported and used.
non-null authentication algorithm MUST be applied.
- If replay protection is required, dynamic keying MUST be o If multicast group membership control protocols or stateful
used. IPsec can easily provide replay protection only if address autoconfiguration protocols are supported, payload data
dynamic keying is used. This may not always be possible, protection MUST be supported.
and manual keying would be preferred in some cases. IPsec
also does not guarantee correct ordering of packets, only
that they have not been replayed. Because of this, sequence
numbers within the Mobile IPv6 messages ensure correct
ordering. However, if a home agent reboots and loses its
state regarding the sequence numbers, replay attacks become
possible. The use of a key management mechanism together
with IPsec can be used to prevent such replay attacks.
- IPsec AH authenticator calculation MUST be performed as if 3.2 Policy Requirements
a 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 Routing header. Type 2 Routing header
should be treated by IPsec in the same manner as Type 0
Routing header.
- Similarly, the authenticator calculation MUST be performed The following requirements apply to both home agents and mobile
as if a packet with a Home Address destination option would nodes:
have the home address in the IPv6 source address field and
the care-of address in the destination option.
- 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 selectors of a security association, an address appearing in a
a Home Address destination option MUST be considered as the Home Address destination option MUST be considered as the source
source address of the packet. address of the packet.
- Similarly, a home address within a Type 2 Routing header o Similarly, a home address within a Type 2 Routing header MUST be
MUST be considered as the destination address of the packet, considered as the destination address of the packet, when a packet
when a packet is matched against IPsec security policy or is matched against IPsec security policy or selectors of a
selectors of a security association. security association.
- When IPsec is used to protect return routability signaling o When IPsec is used to protect return routability signaling or
or payload packets, the security association between the payload packets, the security policy database entries SHOULD be
home agent and the mobile node MUST change its destination defined specifically for the tunnel interface between the mobile
address (tunneled gateway address) when the care-of address node and the home agent. That is, the policy entries are not
for the mobile node changes. At the home agent, this generally applied on all traffic on the physical interface(s) of
modification takes place when a the care-of address in a the nodes, but rather only on traffic that enters this tunnel.
binding changes. At the mobile node, this modification takes
place immediately after movement.
- When IPsec is used to protect return routability signaling o IP layer implementations are, in general, unable to ensure that a
or payload packets, the security policy database entries particular address of the machine is only used by the user
SHOULD be defined specifically for the tunnel interface authorized to use that address. Therefore, this specification
between the mobile node and the home agent. That is, the requires that mobile nodes and home agents SHOULD use credentials
policy entries are not generally applied on all traffic on that are authorized to control all addresses given to the node.
the physical interface(s) of the nodes, but rather only on
traffic that enters this tunnel. 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
care-of address is torn down. The SPD entries, which were used
for protecting tunneled traffic between the mobile node and the
home agent become inactive. The corresponding security
associations could be stored or deleted depending on how they were
created. If the security associations were created dynamically
using IKE, they are automatically deleted when they expire. If
the security associations were created through manual
configuration, they MUST be retained and used later when the
mobile node moves aways from home again. The security
associations protecting Binding Updates and Acknowledgements, and
prefix discovery SHOULD not be deleted as they do not depend on
care-of addresses and can be used again.
The following rules apply to mobile nodes: The following rules apply to mobile nodes:
- The mobile node MUST use the Home Address destination o The mobile node MUST use the Home Address destination option in
option in Binding Updates and Mobile Prefix Solicitations, Binding Updates and Mobile Prefix Solicitations, sent to the home
sent to the home agent from a care-of address. agent from a care-of address.
- If IPsec is used to protect return routability signaling o When the mobile node receives changed set of prefixes from the
or payload packets tunneled via the home agent, IPsec tunnel home agent during prefix discovery, there is a need to configure
mode encapsulation MUST be used. new security policy entries, and there may be a need to configure
new security associations. It is outside the scope of this
specification to discuss automatic methods for this.
- Depending on whether IPsec AH or ESP is used the protec- The following rules apply to home agents:
tion offered for the Binding Updates is slightly different.
AH protects also the IPv6 header and any extension headers.
It is important for the home agent to verify that the care-
of address has not been tampered. If ESP is used, the IPv6
header where this information resides could potentially have
been modified by attackers on the path. As a result, the
attacker would have redirected the mobile node's traffic to
another address. In order to prevent this, Mobile IPv6
implementations MUST use the Alternate Care-of Address
mobility option when ESP is used, or when the implementation
does not know whether AH or ESP is used.
- Where dynamic keying is used, the key management protocol o The home agent MUST use the Type 2 Routing header in Binding
MUST use the care-of address as the source address in the Acknowledgements and Mobile Prefix Advertisements sent to the
protocol exchanges. mobile node, again due to the need to have the home address
visible when the policy checks are made.
- Conversely, the IPsec SAs MUST be requested from the key o It is necessary to avoid the possibility that a mobile node could
management protocol with the home address as the mobile use its security association to send a Binding Update on behalf of
node's address. another mobile node using the same home agent. In order to do
this, the security policy database entries MUST unequivocally
identify a single security association for any given home address
and home agent when manual keying is used. When dynamic keying is
used, the security policy database entries MUST unequivocally
identify the IKE phase 1 credentials which can be used to
authorize the creation of security associations for a particular
home address. How these mappings are maintained is outside the
scope of this specification, but they may be maintained, for
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
used.
o When the set of prefixes advertised by the home agent changes,
there is 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 specification to discuss automatic
methods for this.
3.3 IPsec Protocol Processing
The following requirements apply to both home agents and mobile
nodes:
o When securing Binding Updates, Binding Acknowledgements, and
prefix discovery, both the mobile nodes and the home agents SHOULD
use the Encapsulating Security Payload (ESP) [3] header in
transport mode and MUST use a non-null payload authentication
algorithm to provide data origin authentication, connectionless
integrity and optional anti-replay protection. Note that
Authentication Header (AH) [2] is also possible but for brevity
not discussed in this specification.
Care is needed when selecting suitable encryption algorithms for
ESP. Currently available integrity protection algorithms are in
general considered to be secure. The 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
protection of packets belonging to the return routability
procedure. A non-null encryption transform and authentication
algorithm MUST be applied.
o IPsec AH [2] authenticator calculation MUST be performed as if a
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
Routing header. Type 2 Routing header should be treated by IPsec
in the same manner as Type 0 Routing header.
o Similarly, the authenticator calculation MUST be performed as if a
packet with a Home Address destination option would have the home
address in the IPv6 source address field and the care-of address
in the destination option.
The following rules apply to mobile nodes:
o When ESP is used to protect Binding Updates, there is no
protection for the care-of address which appears in the IPv6
header outside the area protected by ESP. It is important for the
home agent to verify that the care-of address has not been
tampered. As a result, the attacker would have redirected the
mobile node's traffic to another address. In order to prevent
this, Mobile IPv6 implementations SHOULD use the Alternate Care-of
Address mobility option in all Binding Updates sent to the home
agent. (Note that AH protects also the IPv6 header, and some
implementations might avoid the option if they know AH is being
used.)
o When IPsec is used to protect return routability signaling or
payload packets, the mobile node MUST set the source address it
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 immediately after sending a Binding Update to the
home agent to register this new address.
The following rules apply to home agents: The following rules apply to home agents:
- The home agent MUST use the Type 2 Routing header in o When IPsec is used to protect return routability signaling or
Binding Acknowledgements and Mobile Prefix Advertisements payload packets, IPsec security associations are needed to provide
sent to the mobile node, again due to the need to have the this protection When the care-of address for the mobile node
home address visible when the policy checks are made. changes, special treatment is needed for the next packets sent
using these security associations. The home agent MUST set the
new care-of address as the destination address of these packets,
as if the destination gateway address in the security association
had changed.
- If IPsec is used to protect return routability signaling 3.4 Dynamic Keying
or payload packets tunneled to and from the mobile node,
IPsec tunnel mode encapsulation MUST be used.
- We need to avoid the possibility that a mobile node could The following requirements apply to both home agents and mobile
use its security association to send a Binding Update on nodes:
behalf of another mobile node using the same home agent. In
order to do this, the security policy database entries MUST
unequivocally identify a single SA for any given home
address and home agent when manual keying is used. When
dynamic keying is used, the security policy database entries
MUST unequivocally identify the IKE phase 1 credentials
which can be used to create security associations for a
particular home address.
7. Example Configurations o If replay protection is required, dynamic keying MUST be used.
IPsec can provide replay protection only if dynamic keying is
used. This may not always be possible, and manual keying would be
preferred in some cases. IPsec also does not guarantee correct
ordering of packets, only that they have not been replayed.
Because of this, sequence numbers within the Mobile IPv6 messages
ensure correct ordering. However, if a home agent reboots and
loses its state regarding the sequence numbers, replay attacks
become possible. The use of a key management mechanism together
with IPsec can be used to prevent such replay attacks.
In the following we describe the Security Policy Database (SPD) o If IKE version 1 is used with preshared secrets in main mode, it
and Security Association Database (SAD) entries necessary to determine the shared secret to use from the IP address of the
protect Binding Updates and Binding Acknowledgements exchanged peer. With Mobile IPv6, however, this may be a care-of address
between the mobile node and the home agent. Our examples assume and does not indicate which mobile node attempts to contact the
the use of ESP, but a similar configuration could also be used to home agent. Therefore, if preshared secret authentication is used
protect the messages with AH. in IKEv1 between the mobile node and the home agent then
aggressive mode MUST be used. Note also that care needs to be
taken with phase 1 identity selection. Where the ID_IPV6_ADDR
Identity Payloads is used, unambiguous mapping of identities to
keys is not possible. (The next version of IKE may not have these
limitations.)
Section 7.1 introduces the format we use in the description of The following rules apply to mobile nodes:
the SPD and the SAD. Section 7.2 describes how to configure
manually keyed security associations, and Section 7.3 describes
how to use dynamic keying.
7.1. Format o Where dynamic keying is used, the key management protocol MUST use
the care-of address as the source address in the protocol
exchanges with the mobile node's home agent.
The format used in the examples is as follows. The SPD o Conversely, the IPsec security associations with the mobile node's
description has the format home agent MUST be requested from the key management protocol with
the home address as the mobile node's address.
o If the mobile node has used IKE to establish security associations
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
whether the IKE endpoints can be moved or if rekeying is needed.
The following rules apply to home agents:
o If the home agent has used IKE to establish security associations
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
whether the IKE endpoints can be moved or if rekeying is needed.
4. Example Configurations
In the following we describe the Security Policy Database (SPD) and
Security Association Database (SAD) entries necessary to protect
Binding Updates and Binding Acknowledgements exchanged between the
mobile node and the home agent. Our examples assume the use of ESP,
but a similar configuration could also be used to protect the
messages with AH.
Section 4.1 introduces the format we use in the description of the
SPD and the SAD. Section 4.2 describes how to configure manually
keyed security associations, and Section 4.3 describes how to use
dynamic keying.
4.1 Format
The format used in the examples is as follows. The SPD description
has the format
<node> "SPD OUT:" <node> "SPD OUT:"
"-" <spdentry> "-" <spdentry>
"-" <spdentry> "-" <spdentry>
... ...
"-" <spdentry> "-" <spdentry>
<node> "SPD IN:" <node> "SPD IN:"
"-" <spdentry> "-" <spdentry>
"-" <spdentry> "-" <spdentry>
... ...
"-" <spdentry> "-" <spdentry>
Where <node> represents the name of the node, and <spdentry> has Where <node> represents the name of the node, and <spdentry> has the
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 Where <condition> is an boolean expression about the fields of the
the IPv6 packet, <sa> is the name of an SA, and <pattern> is a IPv6 packet, <sa> is the name of a security association, and
specification for an SA to be negotiated via IKE. The SAD <pattern> is a specification for an SA to be negotiated via IKE [4].
description has the format 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
following format:
Where <node> represents the name of the node, and <sadentry> has <sa> "(" <dir> ","
the following format: <spi> ","
<destination> ","
<sa> "(" <dir> "," <spi> "," <destination> "," <ahesp> "," <mode> ")" ":" <ahesp> ","
<mode> ")" ":"
<selectors> <selectors>
Where <dir> is "IN" or "OUT", <spi> is the SPI of the SA, <desti-
nation> is the destination of the SA, <ahesp> is either "AH" or
"ESP", <mode> is either "TUNNEL" or "TRANSPORT", and <selectors>
is a boolean expression about the fields of the IPv6 packet.
We will be using an example mobile node in this section with the Where <dir> is "IN" or "OUT", <spi> is the SPI of the security
home address "home_address_1". The user's identity in this mobile association, <destination> is its destination, <ahesp> is normally
node is "user_1". The home agent's address is "home_agent_1". "ESP" in our case but could also be "AH", <mode> is either "TUNNEL"
or "TRANSPORT", and <selectors> is a boolean expression about the
fields of the IPv6 packet.
7.2. Manual Configuration 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
"user_1". The home agent's address is "home_agent_1".
7.2.1. Binding Updates and Acknowledgements 4.2 Manual Configuration
4.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 Updates and Acknowledgements in the mobile node mobile node and home
home agent home agent: 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 12, line 5 skipping to change at page 19, 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
7.2.2. Return Routability Signaling 4.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 protect return routability signaling between the mobile node and the
the home agent. Note that the rules in the SPD are ordered, and home agent. Note that the rules in the SPD are ordered, and the ones
the ones in the previous section must take precedence over these in the previous section must take precedence over these ones:
ones:
mobile node SPD OUT: mobile node SPD OUT:
- IF interface = tunnel to home_agent_1 & source = home_address_1 & - IF interface = tunnel to home_agent_1 &
destination = any & proto = MH source = home_address_1 & destination = any &
proto = MH
THEN USE SA3 THEN USE SA3
mobile node SPD IN: mobile node SPD IN:
- IF interface = tunnel from home_agent_1 & source = any & - IF interface = tunnel from home_agent_1 &
destination = home_address_1 & proto = MH source = any & destination = home_address_1 &
proto = MH
THEN USE SA4 THEN USE SA4
mobile node SAD: mobile node SAD:
- SA3(OUT, spi_c, home_agent_1, ESP, TUNNEL): - SA3(OUT, spi_c, home_agent_1, ESP, TUNNEL):
source = home_address_1 & destination = any & proto = MH source = home_address_1 & destination = any & proto = MH
- SA4(IN, spi_d, home_address_1, ESP, TUNNEL): - SA4(IN, spi_d, home_address_1, ESP, TUNNEL):
source = any & destination = home_address_1 & proto = MH source = any & destination = home_address_1 & proto = MH
home agent SPD OUT: home agent SPD OUT:
- IF interface = tunnel to home_address_1 & source = any & - IF interface = tunnel to home_address_1 &
destination = home_address_1 & proto = MH source = any & destination = home_address_1 &
proto = MH
THEN USE SA4 THEN USE SA4
home agent SPD IN: home agent SPD IN:
- IF interface = tunnel from home_address_1 & source = home_address_1 & - IF interface = tunnel from home_address_1 &
destination = any & proto = MH source = home_address_1 & destination = any &
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
7.2.3. Prefix Discovery 4.2.3 Prefix Discovery
In the following we describe some additional SPD and SAD entries In the following we describe some additional SPD and SAD entries to
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:
- IF source = home_agent_1 & destination = home_address_1 & - IF source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6 proto = ICMPv6
THEN USE SA6 THEN USE SA6
skipping to change at page 13, line 30 skipping to change at page 21, line 41
THEN USE SA5 THEN USE SA5
home agent SAD: home agent SAD:
- SA6(OUT, spi_f, home_address_1, ESP, TRANSPORT): - SA6(OUT, spi_f, home_address_1, ESP, TRANSPORT):
source = home_agent_1 & destination = home_address_1 & source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6 proto = ICMPv6
- SA5(IN, spi_e, home_agent_1, ESP, TRANSPORT): - SA5(IN, spi_e, home_agent_1, ESP, TRANSPORT):
source = home_address_1 & destination = home_agent_1 & source = home_address_1 & destination = home_agent_1 &
proto = ICMPv6 proto = ICMPv6
Note that the SPDs described above protect all ICMPv6 traffic Note that the SPDs described above protect all ICMPv6 traffic between
between the mobile node and the home agent. the mobile node and the home agent.
When new prefixes are advertised by the home agent, the MN MAY
configure additional new home addresses. There may be a need to
create new security associations, if the mobile node intends to
use any of these home addresses to send a Binding Update to the
home agent.
7.2.4. Payload Packets 4.2.4 Payload Packets
It is also possible to perform some additional, optional, It is also possible to perform some additional, optional, protection
protection of tunneled payload packets. This protection takes of tunneled payload packets. This protection takes place in a
place in a similar manner to the return routability protection similar manner to the return routability protection above, but
above, but requires a different value for the protocol field. The requires a different value for the protocol field. The necessary SPD
necessary SPD and SAD entries are shown below. It is assumed that and SAD entries are shown below. It is assumed that the entries for
the entries for protecting Binding Updates and Acknowledgements, protecting Binding Updates and Acknowledgements, and the entries to
and the entries to protect Home Test Init and Home Test messages protect Home Test Init and Home Test messages take precedence over
take precedence over these entries. these entries.
mobile node SPD OUT: mobile node SPD OUT:
- IF interface = tunnel to home_agent_1 & source = - IF interface = tunnel to home_agent_1 &
home_address_1 & source = home_address_1 & destination = any &
destination = any & proto = X proto = X
THEN USE SA7 THEN USE SA7
mobile node SPD IN: mobile node SPD IN:
- IF interface = tunnel from home_agent_1 & source = any & - IF interface = tunnel from home_agent_1 &
destination = home_address_1 & proto = X source = any & destination = home_address_1 &
proto = X
THEN USE SA8 THEN USE SA8
mobile node SAD: mobile node SAD:
- SA7(OUT, spi_g, home_agent_1, ESP, TUNNEL): - SA7(OUT, spi_g, home_agent_1, ESP, TUNNEL):
source = home_address_1 & destination = any & proto = X source = home_address_1 & destination = any & proto = X
- SA8(IN, spi_h, home_address_1, ESP, TUNNEL): - SA8(IN, spi_h, home_address_1, ESP, TUNNEL):
source = any & destination = home_address_1 & proto = X source = any & destination = home_address_1 & proto = X
home agent SPD OUT: home agent SPD OUT:
- IF interface = tunnel to home_address_1 & source = any & - IF interface = tunnel to home_address_1 &
destination = home_address_1 & proto = X source = any & destination = home_address_1 &
proto = X
THEN USE SA8 THEN USE SA8
home agent SPD IN: home agent SPD IN:
- IF interface = tunnel from home_address_1 & source = - IF interface = tunnel from home_address_1 &
home_address_1 & source = home_address_1 & destination = any &
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
7.3. Dynamic Keying If multicast group membership control protocols such as MLDv1 [8] or
MLDv2 [11] need to be protected, these packets may use a link-local
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
entries will work solely based on the used interface and the
protocol, which is ICMPv6 for both MLDv1 and MLDv2.
Similar problems are encountered when stateful address
autoconfiguration protocols such as DHCPv6 [9] are used. The same
approach is applicable for DHCPv6 as well. DHCPv6 uses the UDP
protocol.
4.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.
7.3.1. Binding Updates and Acknowledgements 4.3.1 Binding Updates and Acknowledgements
Here are the contents of the SPD for protecting Binding Updates Here are the contents of the SPD for protecting Binding Updates and
and Acknowledgements: Acknowledgements:
mobile node SPD OUT: mobile node SPD OUT:
- IF source = home_address_1 & destination = home_agent_1 & proto = MH - IF source = home_address_1 & destination = home_agent_1 &
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:
- IF source = home_agent_1 & destination = home_address_1 & proto = MH - IF source = home_agent_1 & destination = home_address_1 &
proto = MH
THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user_1 THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user_1
home agent SPD OUT: home agent SPD OUT:
- IF source = home_agent_1 & destination = home_address_1 & proto = MH - IF source = home_agent_1 & destination = home_address_1 &
proto = MH
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 & proto = MH - IF source = home_address_1 & destination = home_agent_1 &
proto = MH
THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user_1 THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user_1
We have omitted details of the proposed transforms in the above, We have omitted details of the proposed transforms in the above, and
and all details related to the particular authentication method all details related to the particular authentication method such as
such as certificates beyond listing a specific identity that must certificates beyond listing a specific identity that must be used.
be used.
We require IKE to be run using the care-of addresses but still We require IKE to be run using the care-of addresses but still
negotiate IPsec SAs that use home addresses. The extra conditions negotiate IPsec SAs that use home addresses. The extra conditions
set by the home agent SPD for the peer phase 1 identity to be set by the home agent SPD for the peer phase 1 identity to be
"user_1" must be verified by the home agent. The purpose of the "user_1" must be verified by the home agent. The purpose of the
condition is to ensure that the IKE phase 2 negotiation for a condition is to ensure that the IKE phase 2 negotiation for a given
given user's home address can't be requested by another user. In user's home address can't be requested by another user. In the
the mobile node, we simply set our local identity to be "user_1". mobile node, we simply set our local identity to be "user_1".
These checks also imply that the configuration of the home agent These checks also imply that the configuration of the home agent is
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 configuration tasks by using certificates that have home addresses in
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 cer- negotiations when another address is mentioned in the used
tificates. 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.
7.3.2. Return Routability Signaling 4.3.2 Return Routability Signaling
Protection for the return routability signaling can be configured Protection for the return routability signaling can be configured in
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 & proto = MH source = home_address_1 & destination = any &
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
mobile node SPD IN: mobile node SPD IN:
- IF interface = tunnel from home_agent_1 & - IF interface = tunnel from home_agent_1 &
source = any & destination = home_address_1 & proto = MH source = any & destination = home_address_1 &
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
home agent SPD OUT: home agent SPD OUT:
- IF interface = tunnel to home_address_1 & - IF interface = tunnel to home_address_1 &
source = any & destination = home_address_1 & proto = MH source = any & destination = home_address_1 &
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
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 & proto = MH source = home_address_1 & destination = any &
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 One difference to the above is that we specified the tunnel gateway
gateway address, as we need to use a different address for that address, as we need to use a different address for that than those
than those appearing in the packets. appearing in the packets.
7.3.3. Prefix Discovery 4.3.3 Prefix Discovery
In the following we describe some additional SPD entries to In the following we describe some additional SPD entries to protect
protect prefix discovery with IKE. (Note that when actual new prefix discovery with IKE. (Note that when actual new prefixes are
prefixes are discovered, there may be a need to enter new discovered, there may be a need to enter new manually configured SPD
manually configured SPD entries to specify the authorization entries to specify the authorization policy for the resulting new
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 & proto = ICMPv6 - IF source = home_address_1 & destination = home_agent_1 &
proto = ICMPv6
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:
- IF source = home_agent_1 & destination = home_address_1 & proto = ICMPv6 - IF source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6
THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user_1 THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user_1
home agent SPD OUT: home agent SPD OUT:
- IF source = home_agent_1 & destination = home_address_1 & proto = ICMPv6 - IF source = home_agent_1 & destination = home_address_1 &
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 & proto = ICMPv6 - IF source = home_address_1 & destination = home_agent_1 &
proto = ICMPv6
THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user_1 THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user_1
7.3.4. Payload Packets 4.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 protection of return routability signaling. As in the manually keyed
keyed case, these SPD entries have lower priority than the above case, these SPD entries have lower priority than the above ones.
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 & proto = X source = home_address_1 & destination = any &
proto = X
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
mobile node SPD IN: mobile node SPD IN:
- IF interface = tunnel from home_agent_1 & - IF interface = tunnel from home_agent_1 &
source = any & destination = home_address_1 & proto = X source = any & destination = home_address_1 &
proto = X
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
home agent SPD OUT: home agent SPD OUT:
- IF interface = tunnel to home_address_1 & - IF interface = tunnel to home_address_1 &
source = any & destination = home_address_1 & proto = X source = any & destination = home_address_1 &
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
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 & proto = X source = home_address_1 & destination = any &
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
7.4. Mobile Node Returning Home 5. Processing Steps within a Node
When the MN returns home and deregisters with the Home Agent, the
tunnel between the home agent and the MN's CoA is torn down. The
SPD entries, which were used for protecting tunneled traffic
between the MN and the HA become inactive. The corresponding SAs
could be stored or deleted depending on how they were created. If
the SAs were created dynamically using IKE, they are
automatically deleted when they expire. If the SAs were created
through manual configuration, they can be retained and used later
if the MN moves aways from home.
The SAs created for BU/BA protection SHOULD not be deleted as
they do not depend on care-of addresses and can be used again.
8. Processing Steps within a Node
In this section we give examples of what processing steps node
can take to achieve the required packet formats and satisfy the
requirements. These example are for illustration purposes only,
and implementations are free to choose other strategies as long
as the results stay the same on the wire.
8.1. Binding Update to the Home Agent 5.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, destination = home agent) IPv6 header (source = home address,
destination = home agent)
Mobility header Mobility header
Binding Update Binding Update
Step 2. This packet is matched against the IPsec policy data base Step 2. This packet is matched against the IPsec policy data base on
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 in [1]. change the addresses yet, as described in Section 11.2.2 of the base
This results in: specification [7]. This results in:
IPv6 header (source = home address, destination = home agent) IPv6 header (source = home address,
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:
IPv6 header (source = home address, destination = home agent) IPv6 header (source = home address,
destination = home agent)
Destination Options header Destination Options header
Home Address option (care-of address) Home Address option (care-of address)
ESP header (SPI = spi_a) ESP header (SPI = spi_a)
Mobility header Mobility header
Binding Update Binding Update
Step 5. Before sending the packet, the addresses in the IPv6 Step 5. Before sending the packet, the addresses in the IPv6 header
header and the Destination Options header are changed: and the Destination Options header are changed:
IPv6 header (source = care-of address, destination = home agent) IPv6 header (source = care-of address,
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
8.2. Binding Update from the Mobile Node 5.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, destination = home agent) IPv6 header (source = care-of address,
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
Step 2. The home address option is processed first, which results Step 2. The home address option is processed first, which results in
in
IPv6 header (source = home address, destination = home agent) IPv6 header (source = home address,
destination = home agent)
Destination Options header Destination Options header
Home Address option (care-of address) Home Address option (care-of address)
ESP header (SPI = spi_a) ESP header (SPI = spi_a)
Mobility header Mobility header
Binding Update Binding Update
Step 3. ESP header is processed next, resulting in Step 3. ESP header is processed next, resulting in
IPv6 header (source = home address, destination = home agent) IPv6 header (source = home address,
destination = home agent)
Destination Options header Destination Options header
Home Address option (care-of address) Home Address option (care-of address)
Mobility header Mobility header
Binding Update Binding Update
Step 4. This packet matches the SA selectors (source = home Step 4. This packet matches the security association selectors
address, destination = home agent, proto = MH). (source = home address, destination = home agent, proto = MH).
Step 5. Mobile IPv6 processes the Binding Update.
The Binding Update is delivered to the Mobile IPv6 module. Step 5. Mobile IPv6 processes the Binding Update. The Binding
Update is delivered to the Mobile IPv6 module.
8.3. Binding Acknowledgement to the Mobile Node 5.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, destination = home address) IPv6 header (source = home agent,
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 Step 3. Then, we add the necessary Route Headers but do not change
change the addresses yet, as described in Section 9.6 in [1]. the addresses yet, as described in Section 9.6 of the base
This results in: specification [7]. This results in:
IPv6 header (source = home agent, destination = home address)
IPv6 header (source = home agent,
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:
IPv6 header (source = home agent, destination = home address) IPv6 header (source = home agent,
destination = home address)
Routing header (type 2) Routing header (type 2)
care-of address care-of address
ESP header (SPI = spi_b) ESP header (SPI = spi_b)
Mobility header Mobility header
Binding Acknowledgement Binding Acknowledgement
Step 5. Finally, before sending the packet out we change the Step 5. Finally, before sending the packet out we change the
addresses in the IPv6 header and the Route header: addresses in the IPv6 header and the Route header:
IPv6 header (source = home agent, destination = care-of address) IPv6 header (source = home agent,
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
8.4. Binding Acknowledgement from the Home Agent 5.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, destination = care-of address) IPv6 header (source = home agent,
destination = care-of address)
Routing header (type 2) Routing header (type 2)
home address home address
ESP header (SPI = spi_b) ESP header (SPI = spi_b)
Mobility header Mobility header
Binding Acknowledgement Binding Acknowledgement
Step 2. After the routing header is processed the packet becomes Step 2. After the routing header is processed the packet becomes
IPv6 header (source = home agent,
IPv6 header (source = home agent, destination = home address) destination = home address)
Routing header (type 2) Routing header (type 2)
care-of address care-of address
ESP header (SPI = spi_b) ESP header (SPI = spi_b)
Mobility header Mobility header
Binding Acknowledgement Binding Acknowledgement
Step 3. ESP header is processed next, resulting in: Step 3. ESP header is processed next, resulting in:
IPv6 header (source = home agent, destination = home address) IPv6 header (source = home agent,
destination = home address)
Routing header (type 2) Routing header (type 2)
care-of address care-of address
Mobility header Mobility header
Binding Acknowledgement Binding Acknowledgement
Step 4. This packet matches the SA selectors (source = home
agent, destination = home address, proto = MH).
Step 5. The Binding Acknowledgement is delivered to the Mobile Step 4. This packet matches the security association selectors
IPv6 module. (source = home agent, destination = home address, proto = MH).
8.5. Home Test Init to the Home Agent Step 5. The Binding Acknowledgement is delivered to the Mobile IPv6
module.
5.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, destination = correspondent node) IPv6 header (source = home address,
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.
Step 3. The packet is matched against IPsec policy entries for Step 3. The packet is matched against IPsec policy entries for the
the interface, and we find that IPsec needs to be applied. interface, and we find that IPsec needs to be applied.
Step 4. IPsec tunnel mode headers are added. Note that we use a Step 4. IPsec tunnel mode headers are added. Note that we use a
care-of address as a source address for the tunnel packet. care-of address as a source address for the tunnel packet.
IPv6 header (source = care-of address, destination = home agent) IPv6 header (source = care-of address,
destination = home agent)
ESP header (SPI = spi_c) ESP header (SPI = spi_c)
IPv6 header (source = home address, destination = correspondent node) IPv6 header (source = home address,
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.
8.6. Home Test Init from the Mobile Node 5.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, destination = home agent) IPv6 header (source = care-of address,
destination = home agent)
ESP header (SPI = spi_c) ESP header (SPI = spi_c)
IPv6 header (source = home address, destination = correspondent node) IPv6 header (source = home address,
destination = correspondent node)
Mobility Header Mobility Header
Home Test Init Home Test Init
Step 2. IPsec processing is performed, resulting in: Step 2. IPsec processing is performed, resulting in:
IPv6 header (source = home address, destination = correspondent node) IPv6 header (source = home address,
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 towards the correspondent Step 4. The packet is then forwarded to the correspondent node.
node.
8.7. Home Test to the Mobile Node 5.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, destination = home address) IPv6 header (source = correspondent node,
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 mobile node that is away from home, and decides to tunnel it.
Step 3. The packet matches the IPsec policy entries for the Step 2. The home agent determines that this packet is destined to a
tunnel interface, and we note that IPsec needs to be applied. mobile node that is away from home, and decides to tunnel it.
Step 4. IPsec is applied, resulting in a new packet. Note that Step 3. The packet matches the IPsec policy entries for the tunnel
the home agent must keep track of the location of the mobile interface, and we note that IPsec needs to be applied.
node, and update the tunnel gateway address in the security
association(s) accordingly.
IPv6 header (source = home agent, destination = care-of address) Step 4. IPsec is applied, resulting in a new packet. Note that the
home agent must keep track of the location of the mobile node, and
update the tunnel gateway address in the security association(s)
accordingly.
IPv6 header (source = home agent,
destination = care-of address)
ESP header (SPI = spi_d) ESP header (SPI = spi_d)
IPv6 header (source = correspondent node, destination = home address) IPv6 header (source = correspondent node,
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.
8.8. Home Test from the Home Agent 5.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, destination = care-of address) IPv6 header (source = home agent,
destination = care-of address)
ESP header (SPI = spi_d) ESP header (SPI = spi_d)
IPv6 header (source = correspondent node, destination = home address) IPv6 header (source = correspondent node,
destination = home address)
Mobility Header Mobility Header
Home Test Init Home Test Init
Step 2. IPsec is processed, resulting in: Step 2. IPsec is processed, resulting in:
IPv6 header (source = correspondent node, destination = home address) IPv6 header (source = correspondent node,
destination = home address)
Mobility Header Mobility Header
Home Test Init Home Test Init
Step 3. This matches the SA selectors (source = any, destination Step 3. This matches the security association selectors (source =
= 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.
8.9. Prefix Solicitation Message to the Home Agent 5.9 Prefix Solicitation Message to the Home Agent
This procedure is similar to the one presented in Section 8.1. This procedure is similar to the one presented in Section 5.1.
8.10. Prefix Solicitation Message from the Mobile Node 5.10 Prefix Solicitation Message from the Mobile Node
This procedure is similar to the one presented in Section 8.2. This procedure is similar to the one presented in Section 5.2.
8.11. Prefix Advertisement Message to the Mobile Node 5.11 Prefix Advertisement Message to the Mobile Node
This procedure is similar to the one presented in Section 8.3. This procedure is similar to the one presented in Section 5.3.
8.12. Prefix Advertisement Message from the Home Agent 5.12 Prefix Advertisement Message from the Home Agent
This procedure is similar to the one presented in Section 8.4. This procedure is similar to the one presented in Section 5.4.
8.13. Payload Packet to the Home Agent 5.13 Payload Packet to the Home Agent
This procedure is similar to the one presented in Section 8.5. This procedure is similar to the one presented in Section 5.5.
8.14. Payload Packet from the Mobile Node 5.14 Payload Packet from the Mobile Node
This procedure is similar to the one presented in Section 8.6. This procedure is similar to the one presented in Section 5.6.
8.15. Payload Packet to the Mobile Node 5.15 Payload Packet to the Mobile Node
This procedure is similar to the one presented in Section 8.7. This procedure is similar to the one presented in Section 5.7.
8.16. Payload Packet from the Home Agent 5.16 Payload Packet from the Home Agent
This procedure is similar to the one presented in Section 8.8. This procedure is similar to the one presented in Section 5.8.
9. Implementation Considerations 5.17 Establishing New Security Associations
Step 1. The mobile node wishes to send a Binding Update to the home
agent.
IPv6 header (source = home address,
destination = home agent)
Mobility header
Binding Update
Step 2. There is no existing security association to protect the
Binding Update, so IKE is initiated. The IKE packets are sent as
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
the home agent. The examples shows also that the phase 1 identity
used for the mobile node is a FQDN.
IPv6 header (source = care-of address,
destination = home agent)
UDP
IKE
... IDii = ID_FQDN mn123.ha.net ...
IPv6 header (source = home agent
destination = care-of address)
UDP
IKE
... IDir = ID_FQDN ha.net ...
Step 3. IKE phase 1 completes, and phase 2 is initiated to request
security associations for protecting traffic between the mobile
node's home address and the home agent. This involves sending and
receiving additional IKE packets. The below example shows again one
packet sent by the mobile node and another sent by the home agent.
The example shows also that the phase 2 identity used for the mobile
node is the mobile node's home address.
IPv6 header (source = care-of address,
destination = home agent)
UDP
IKE
... IDci = ID_IPV6_ADDR home address ...
IPv6 header (source = home agent,
destination = care-of address)
UDP
IKE
... IDcr = ID_IPV6_ADDR home agent ...
Step 4. The remaining steps are as shown in Section 5.1.
5.18 Rekeying Security Associations
Step 1. The mobile node and the home agent have existing security
associations. Either side may decide at any time that the security
associations need to be rekeyed, for instance, because the specified
lifetime is approaching.
Step 2. Mobility header packets sent during rekey may be protected
by the existing security associations.
Step 3. When the rekeying is finished, new security associations are
established. In practice there is a time interval during which an
old, about-to-expire security association and newly established
security association will both exist. The new ones should be used as
soon as they become available.
Step 4. A notification of the deletion of the old security
associations is received. After this, only the new security
associations can be used.
Note that there is no requirement that the existence of the IPsec and
IKE security associations is tied to the existence of bindings. It
is not necessary to delete a security association if a binding is
removed, as a new binding may soon be established after this.
Since cryptographic acceleration hardware may only be able to handle
a limited number of active security associations, security
associations may be deleted via IKE in order to keep the number of
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
reason to remove a binding. Rather, if additional traffic needs to
be sent, it is preferable to bring up another security association to
protect it.
5.19 Movements and Dynamic Keying
In this section we describe the sequence of events that relate to
movement with IKE-based security associations. In the initial state,
the mobile node is not registered in any location and has no security
associations with the home agent. Depending on whether the peers
will be able to move IKE endpoints to new care-of addresses, the
actions taken in Step 9 and 10 are different.
Step 1. Mobile node with the home address A moves to care-of address
B.
Step 2. Mobile node runs IKE from care-of address B to the home
agent, establishing a phase 1.
Step 3. Protected by this phase 1, mobile node establishes a pair of
security associations for protecting MH traffic to and from the home
address A.
Step 4. Mobile node sends a Binding Update and receives a Binding
Acknowledgement using the security associations created in Step 3.
Step 5. Mobile node establishes a pair of security associations for
protecting return routability packets. These security associations
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
the phase 1 connection established in Step 2. Multiple phase 1
connections are also possible.
Step 6. The mobile node uses the security associations created in
Step 5 to run return routability.
Step 7. The mobile node moves to a new location and adopts a new
care-of address C.
Step 8. Mobile node sends a Binding Update and receives a Binding
Acknowledgement using the security associations created in Step 3.
The home agent ensures that the next packets sent using the security
associations created in Step 5 will have the new care-of address as
their destination address, as if the destination gateway address in
the security association had changed.
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 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
top of the care-of address C. This capability to change the IKE
phase 1 end points is indicated through setting the Key Management
Mobility Capability (K) flag [7] in the Binding Update and Binding
Acknowledgement messages.
Step 11. If a new IKE phase 1 connection was setup after movement,
the MN will not be able to receive any notifications delivered on top
of the old IKE phase 1 security association. Notifications delivered
on top of the new security association are received and processed
normally. If the mobile node and HA were able to update the IKE
endpoints, they can continue using the same IKE phase 1 connection.
6. 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 routability and payload packet protection which can only be realized
realized if the IPsec implementation can be controlled via an if the destination of the IPsec packets sent from the home agent can
API. One of the main reasons for choosing such a format is that be changed as the mobile node moves. One of the main reasons for
it removes the overhead of twenty four bytes when a home address choosing such a format is that it removes the overhead of twenty four
option or routing header is added to the tunneled packet. The API bytes when a home address option or routing header is added to the
should minimally support changing the gateway address of a tunneled packet. What is needed is that the home agent must act as
security association towards the mobile node as the mobile node if the gateway address of a security association to the mobile node
moves. Implementations are free to choose other methods to update would have changed. Implementations are free to choose any
a security association. This includes deleting the current SA particular method to make this change, such as using an API to the
and adding a new SA. IPsec implementation to change the parameters of the security
association, removing the security association and installing a new
one, or modification of the packet after it has gone through IPsec
processing. The only requirement is that after registering a new
binding at the home agent, the next IPsec packets sent on this
security association will be addressed to the new care-of address.
We have also chosen to require that a dynamic key management We have also chosen to require that a dynamic key management protocol
protocol must be able to make an authorization decision for IPsec must be able to make an authorization decision for IPsec security
SA creation with different addresses than with what the key association creation with different addresses than with what the key
management protocol is run. We expect this to be done typically by management protocol is run. We expect this to be done typically by
configuring the allowed combinations of phase 1 user identities configuring the allowed combinations of phase 1 user identities and
and home addresses. home addresses.
The base Mobile IPv6 specification sets high requirements for a The base Mobile IPv6 specification sets high requirements for a
so-called Bump-In-The-Stack (BITS) implementation model of IPsec. so-called Bump-In-The-Stack (BITS) implementation model of IPsec. As
As Mobile IPv6 specific modifications of the packets are required Mobile IPv6 specific modifications of the packets are required after
after IPsec processing, the BITS implementation has to perform IPsec processing, the BITS implementation has to perform also some
also some tasks related to mobility. This may increase the tasks related to mobility. This may increase the complexity of the
complexity of the implementation, even if it already performs implementation, even if it already performs some tasks of the IP
some tasks of the IP layer (such as fragmentation). layer (such as fragmentation).
We have chosen to require policy entries that are specific to a We have chosen to require policy entries that are specific to a
tunnel interface. This means that implementations have to regard tunnel interface. This means that implementations have to regard the
the Home Agent - Mobile Node tunnel as a separate interface on Home Agent - Mobile Node tunnel as a separate interface on which
which IPsec SPDs can be based. IPsec SPDs can be based.
A further complication of the IPsec processing on a tunnel A further complication of the IPsec processing on a tunnel interface
interface is that this requires access to the BITS implementation is that this requires access to the BITS implementation before the
before the packet actually goes out. packet actually goes out.
10. Security Considerations When certificate authentication is used, IKE fragmentation can be
encountered. This can occur when certificate chains are used, or
even with single certificates if they are large. Many firewalls do
not handle fragments properly, and may drop them. Routers in the
path may also discard fragments after the initial one, since they
typically will not contain full IP headers that can be compared
against an access list. Where fragmentation occurs, the endpoints
will not always be able to establish a security association.
The Mobile IPv6 base specification [1] requires strong security Fortunately, typical Mobile IPv6 deployment uses short certificate
between the mobile node and the home agent. This memo discusses chains, as the mobile node is communicating directly with its home
how that security can be arranged in practise, using IPsec. network. Nevertheless, where the problem appears, one solution is to
replace the firewalls or routers with equipment that can properly
support fragments. If this cannot be done, it may help to store the
peer certificates locally, or to obtain them through other means.
11. References 7. Security Considerations
[1] D. Johnson, C. Perkins, J. Arkko, "Mobility Support for The Mobile IPv6 base specification [7] requires strong security
IPv6", Internet Draft draft-ietf-mobileip-ipv6-19.txt. (Work In between the mobile node and the home agent. This memo discusses how
Progress.) September 2002. that security can be arranged in practice, using IPsec.
[2] S. Kent, R. Atkinson, "Security Architecture for the Normative References
Internet Protocol" RFC 2401, BBN Corp, @Home Network, November 1998.
[3] D. Harkins and D. Carrel, "The Internet Key Exchange", RFC [1] Kent, S. and R. Atkinson, "Security Architecture for the
2409, Cisco Systems, November 1998. Internet Protocol", RFC 2401, November 1998.
[4] S. Deering and R. Hinden, "Internet Protocol, Version 6 [2] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
(IPv6) Specification", RFC 2460, December 1998. November 1998.
12. Acknowledgements [3] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
The authors would like to thank Erik Nordmark, Gabriel [4] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
Montenegro, Kevin Miles, Cheryl Madson and Jari T. Malinen for RFC 2409, November 1998.
interesting discussions in this problem space.
13. Author's Address [5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[6] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6
Specification", RFC 2473, December 1998.
[7] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support in
IPv6", draft-ietf-mobileip-ipv6-20 (work in progress), January
2003.
Informative References
[8] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener
Discovery (MLD) for IPv6", RFC 2710, October 1999.
[9] Droms, R., "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", draft-ietf-dhc-dhcpv6-28 (work in progress),
November 2002.
[10] Kivinen, T., Huttunen, A., Swander, B. and V. Volpe,
"Negotiation of NAT-Traversal in the IKE",
draft-ietf-ipsec-nat-t-ike-04 (work in progress), November
2002.
[11] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", draft-vida-mld-v2-06 (work in progress),
December 2002.
Authors' Addresses
Jari Arkko Jari Arkko
Oy LM Ericsson Ab Ericsson
02420 Jorvas Jorvas 02420
Finland Finland
EMail: Jari.Arkko@ericsson.com EMail: jari.arkko@ericsson.com
Vijay Devarapalli Vijay Devarapalli
Nokia Research Center Nokia Research Center
313 Fairchild Drive 313 Fairchild Drive
Mountain View, CA 94043 Mountain View CA 94043
USA
EMail: vijayd@iprg.nokia.com EMail: vijayd@iprg.nokia.com
Francis Dupont Francis Dupont
ENST Bretagne ENST Bretagne
Campus de Rennes 2, rue de la Chataigneraie Campus de Rennes 2, rue de la Chataigneraie
BP 78 BP 78
35512 Cesson-Sevigne Cedex Cesson-Sevigne Cedex 35512
France France
EMail: Francis.Dupont@enst-bretagne.fr EMail: Francis.Dupont@enst-bretagne.fr
Appendix A. Acknowledgements
The authors would like to thank Michael Thomas, Kevin Miles, Cheryl
Madson, Bernard Aboba, Erik Nordmark, and Gabriel Montenegro for
interesting discussions in this problem space.
Appendix B. Changes from Previous Version
The following changes have been made to this draft from version 1:
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
made explicit (tracked issue 216).
o More details have been provided on how IKE processing takes place
(tracked issue 195).
o Requirements for treating necessary policy and security
association modifications upon new prefixes have been explained
better (tracked issue 195).
o The Key Management Movement Capability (K) bit has been added to
the Binding Update and Acknowledgement messages (tracked issue
194).
o More details have been provided on how IKE end-points change
during movements (tracked issue 194).
o The results of the security review have been adopted (tracked
issue 189). The modifications include specifying only the use of
ESP for protecting signaling.
o Many editorial modifications.
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

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