Request for Comments: 3776 Ericsson
Category: Standards Track V. Devarapalli
Nokia Research Center
F. Dupont
GET/ENST Bretagne
June 2004
Using IPsec to Protect Mobile IPv6 Signaling Between
Mobile Nodes and Home Agents
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
Mobile IPv6 uses IPsec to protect signaling between the home agent
and the mobile node. Mobile IPv6 base document defines the main
requirements these nodes must follow. This document 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Binding Updates and Acknowledgements . . . . . . . . . 5
3.2 Return Routability Signaling . . . . . . . . . . . . . 7
3.3 Prefix Discovery . . . . . . . . . . . . . . . . . . . 8
3.4 Payload Packets . . . . . . . . . . . . . . . . . . . 9
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1 Mandatory Support . . . . . . . . . . . . . . . . . . 10
4.2 Policy Requirements . . . . . . . . . . . . . . . . . 10
4.3 IPsec Protocol Processing . . . . . . . . . . . . . . 13
4.4 Dynamic Keying . . . . . . . . . . . . . . . . . . . . 15
5. Example Configurations . . . . . . . . . . . . . . . . . . . 16
5.1 Format . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2 Manual Configuration . . . . . . . . . . . . . . . . . 18
5.2.1 Binding Updates and Acknowledgements . . . . . . 18
5.2.2 Return Routability Signaling . . . . . . . . . . 19
5.2.3 Prefix Discovery . . . . . . . . . . . . . . . . 20
5.2.4 Payload Packets . . . . . . . . . . . . . . . . 21
5.3 Dynamic Keying . . . . . . . . . . . . . . . . . . . . 22
5.3.1 Binding Updates and Acknowledgements . . . . . . 22
5.3.2 Return Routability Signaling . . . . . . . . . . 23
5.3.3 Prefix Discovery . . . . . . . . . . . . . . . . 24
5.3.4 Payload Packets . . . . . . . . . . . . . . . . 25
6. Processing Steps within a Node . . . . . . . . . . . . . . . 25
6.1 Binding Update to the Home Agent . . . . . . . . . . . 25
6.2 Binding Update from the Mobile Node . . . . . . . . . 26
6.3 Binding Acknowledgement to the Mobile Node . . . . . . 27
6.4 Binding Acknowledgement from the Home Agent . . . . . 28
6.5 Home Test Init to the Home Agent . . . . . . . . . . . 29
6.6 Home Test Init from the Mobile Node . . . . . . . . . 30
6.7 Home Test to the Mobile Node . . . . . . . . . . . . . 30
6.8 Home Test from the Home Agent . . . . . . . . . . . . 31
6.9 Prefix Solicitation Message to the Home Agent . . . . 31
6.10 Prefix Solicitation Message from the Mobile Node . . . 31
6.11 Prefix Advertisement Message to the Mobile Node . . . 32
6.12 Prefix Advertisement Message from the Home Agent . . . 32
6.13 Payload Packet to the Home Agent . . . . . . . . . . . 32
6.14 Payload Packet from the Mobile Node . . . . . . . . . 32
6.15 Payload Packet to the Mobile Node . . . . . . . . . . 32
6.16 Payload Packet from the Home Agent . . . . . . . . . . 32
6.17 Establishing New Security Associations . . . . . . . . 32
6.18 Rekeying Security Associations . . . . . . . . . . . . 33
6.19 Movements and Dynamic Keying . . . . . . . . . . . . . 34
7. Implementation Considerations . . . . . . . . . . . . . . . 35
7.1 IPsec . . . . . . . . . . . . . . . . . . . . . . . . 35
7.2 IKE . . . . . . . . . . . . . . . . . . . . . . . . . 36
7.3 Bump-in-the-Stack . . . . . . . . . . . . . . . . . . 37
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 37
9. Security Considerations . . . . . . . . . . . . . . . . . . 37
10 References . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.1 Normative References . . . . . . . . . . . . . . . . . 38
10.2 Informative References . . . . . . . . . . . . . . . . 38
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
12. Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . 39
13. Full Copyright Statement . . . . . . . . . . . . . . . . . . 40
1. Introduction
This document illustrates the use of IPsec in securing Mobile IPv6
[7] traffic between mobile nodes and home agents. In Mobile IPv6, a
mobile node is always expected to be addressable at its home address,
whether it is currently attached to its home link or is away from
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.
While a mobile node is attached to some foreign link away from home,
it is also addressable at a care-of address. A care-of address is an
IP address associated with a mobile node that has a subnet prefix
from 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.
Any other nodes communicating with a mobile node are referred to as
"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.
Mobile IPv6 tunnels payload packets between the mobile node and the
home agent in both directions. This tunneling uses IPv6
encapsulation [6]. Where these tunnels need to be secured, they are
replaced by IPsec tunnels [2].
Mobile IPv6 also provides support for the reconfiguration of the home
network. Here, the home subnet prefixes may change over time.
Mobile nodes can learn new information about home subnet prefixes
through the "prefix discovery" mechanism.
This document discusses security mechanisms for the control traffic
between the mobile node and the home agent. If this traffic is not
protected, mobile nodes and correspondent nodes are vulnerable to
man-in-the-middle, hijacking, passive wiretapping, impersonation, and
denial-of-service attacks. Any third parties are also vulnerable to
denial-of-service attacks, for instance if an attacker could direct
the traffic flowing through the home agent to a innocent third party.
These attacks are discussed in more detail in Section 15.1 of the
Mobile IPv6 base specification [7].
In order to avoid these attacks, the base specification uses IPsec
Encapsulating Security Payload (ESP) [3] to protect control traffic
between the home agent and the mobile node. This control traffic
consists of various messages carried by the Mobility Header protocol
in IPv6 [5]. The traffic takes the following forms:
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].
o Return routability messages Home Test Init and Home Test that pass
through the home agent on their way to a correspondent node, as
described in Section 10.4.6 of the base specification [7].
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].
The nodes may also optionally protect payload traffic passing through
the home agent, as described in Section 5.5 of the base specification
[7]. If multicast group membership control protocols or stateful
address autoconfiguration protocols are supported, payload data
protection support is required.
The control traffic between the mobile node and the home agent
requires message authentication, integrity, correct ordering and
anti-replay protection. The mobile node and the home agent must have
an IPsec security association to protect this traffic. IPsec does
not proving correct ordering of messages. Correct ordering of the
control traffic is ensured by a sequence number in the Binding Update
and Binding Acknowledgement messages. The sequence number in the
Binding Updates also provides protection to a certain extent. It
fails in some scenarios, for example, if the Home Agent loses the
Binding Cache state. Full protection against replay attacks is
possible only when IKE is used.
Great care is needed when using IKE [4] to establish security
associations to Mobile IPv6 home agents. The right kind of addresses
must be used for transporting IKE. This is necessary to avoid
circular dependencies in which the use of a Binding Update triggers
the need for an IKE exchange that cannot complete prior to the
Binding Update having been completed.
The mobile IPv6 base document defines the main requirements the
mobile nodes and home agents must follow when securing the above
traffic. This document 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 3. Section 4 describes rules which
associated Mobile IPv6, IPsec, and IKE implementations must observe.
Section 5 discusses how to configure either manually keyed IPsec
security associations or how to configure IKE to establish them
automatically. Section 6 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 3 and obey the
rules in Section 4.
The configuration and processing sections are informative, and should
only be considered as one possible way of providing the required
functionality.
Note that where this document indicates a feature MUST be supported
and SHOULD be used, this implies that all implementations must be
capable of using the specified feature, but there may be cases where,
for instance, a configuration option disables to use of the feature
in a particular situation.
2. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
3. Packet Formats
3.1. Binding Updates and Acknowledgements
When the mobile node is away from its home, the BUs sent by it to the
home agent MUST support at least the following headers in the
following order:
IPv6 header (source = care-of address,
destination = home agent)
Destination Options header
Home Address option (home address)
ESP header in transport mode
Mobility header
Binding Update
Alternate Care-of Address option (care-of address)
Note that the Alternate Care-of Address option is used to ensure that
the care-of address is protected by ESP. The home agent considers
the address within this option as the current care-of address for the
mobile node. The home address is not protected by ESP directly, but
the use of a specific home address with a specific security
association is required by policy.
The Binding Acknowledgements sent back to the mobile node when it is
away from home MUST support at least the following headers in the
following order:
IPv6 header (source = home agent,
destination = care-of address)
Routing header (type 2)
home address
ESP header in transport mode
Mobility header
Binding Acknowledgement
When the mobile node is at home, the above rules are different as the
mobile node can use its home address as a source address. This
typically happens for the de-registration Binding Update when the
mobile is returning home. In this situation, the Binding Updates
MUST support at least the following headers in the following order:
IPv6 header (source = home address,
destination = home agent)
ESP header in transport mode
Mobility header
Binding Update
The Binding Acknowledgement messages sent to the home address MUST
support at least the following headers in the following order:
IPv6 header (source = home agent,
destination = home address)
ESP header in transport mode
Mobility header
Binding Acknowledgement
3.2. Return Routability Signaling
When the Home Test Init messages tunneled to the home agent are
protected by IPsec, they MUST support at least the following headers
in the following order:
IPv6 header (source = care-of address,
destination = home agent)
ESP header in tunnel mode
IPv6 header (source = home address,
destination = correspondent node)
Mobility Header
Home Test Init
This format assumes that the mobile node’s current care-of address is
used as the outer header destination address in the security
association. As discussed in Section 4.3, this requires the home
agent to update the destination address when the mobile node moves.
Policy entries and security association selectors stay the same,
however, as the inner packets do not change upon movements.
Note that there are trade-offs in using care-of addresses as the
destination addresses versus using the home address and attaching an
additional Home Address destination option and/or Routing header to
the packets. The basis for requiring support for at least the
care-of address case has been discussed in Section 7.
Similarly, when the Home Test messages tunneled from the home agent
are protected by IPsec, they MUST support at least the following
headers in the following order:
IPv6 header (source = home agent,
destination = care-of address)
ESP header in tunnel mode
IPv6 header (source = correspondent node,
destination = home address)
Mobility Header
Home Test
The format used to protect return routability packets relies on the
destination of the tunnel packets to change for the mobile node as it
moves. The home agent’s address stays the same, but the mobile
node’s address changes upon movements, as if the security
association’s outer header destination address had changed. When the
mobile node adopts a new care-of address, it adopts also a new source
address for outgoing tunnel packets. The home agent accepts packets
sent like this, as the outer source address in tunnel packets is not
checked according to the rules in RFC 2401. (We note, however, that
some implementations are known to make source address checks.) For a
discussion of the role of source addresses in outer tunnel headers,
see Section 5.1.2.1 of RFC 2401 [2]. Note also that the home agent
requires the packets to be authenticated regardless of the source
address change, hence the "new" sender must possess the same keys for
the security association as it had in the previous location. This
proves that the sender is the same entity, regardless of the changes
in the addresses.
The process is more complicated in the home agent side, as the home
agent has stored the previous care-of address in its Security
Association Database as the outer header destination address. When
IKE is being used, the mobile node runs it on top of its current
care-of address, and the resulting tunnel-mode security associations
will use the same addresses as IKE run over. 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 outer header
destination address in 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
re-establishment of IKE phases is needed per movement. Section 5.2.2
discusses the security policy and security association database
entries that are needed to accomplish this.
3.3. Prefix Discovery
If IPsec is used to protect prefix discovery, requests for prefixes
from the mobile node to the home agent MUST support at least the
following headers in the following order.
IPv6 header (source = care-of address,
destination = home agent)
Destination Options header
Home Address option (home address)
ESP header in transport mode
ICMPv6
Mobile Prefix Solicitation
Again if IPsec is used, solicited and unsolicited prefix information
advertisements from the home agent to the mobile node MUST support at
least the following headers in the following order.
IPv6 header (source = home agent,
destination = care-of address)
Routing header (type 2)
home address
ESP header in transport mode
ICMPv6
Mobile Prefix Advertisement
3.4. Payload Packets
If IPsec is used to protect payload packets tunneled to the home
agent from the mobile node, we use a format similar to the one in
Section 3.2. However, instead of the MobilityHeader, these packets
may contain any legal IPv6 protocol(s):
IPv6 header (source = care-of address,
destination = home agent)
ESP header in tunnel mode
IPv6 header (source = home address,
destination = correspondent node)
Any protocol
Similarly, when the payload packets are tunneled from the home agent
to the mobile node with ESP encapsulation, they MUST support at least
the following headers in the following order:
IPv6 header (source = home agent,
destination = care-of address)
ESP header in tunnel mode
IPv6 header (source = correspondent node,
destination = home address)
Any protocol
4. Requirements
This section describes mandatory rules for all Mobile IPv6 mobile
nodes and home agents. These rules are necessary in order for it to
be possible to enable IPsec communications despite movements,
guarantee sufficient security, and to ensure correct processing order
of packets.
The rules in the following sections apply only to the communications
between home agents and mobile nodes. They should not be taken as
requirements on how IPsec in general is used by mobile nodes.
4.1. Mandatory Support
The following requirements apply to both home agents and mobile
nodes:
o Manual configuration of IPsec security associations MUST be
supported. 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.
o Automatic key management with IKE [4] MAY be supported. Only
IKEv1 is discussed in this document. Other automatic key
management mechanisms exist and will appear beyond IKEv1, but this