Network Working Group Jari Arkko
INTERNET-DRAFT Ericsson
Category: Standards Track Vijay Devarapalli
<draft-ietf-mobileip-mipv6-ha-ipsec-00.txt> Nokia
Francis Dupont
ENST Bretagne
20 September 2002
Using IPsec to Protect Mobile IPv6 Signaling between
Mobile Nodes and Home Agents
1. Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026. Internet-Drafts are
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
months and may be updated, replaced, or made obsolete 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 current Internet-Drafts may be found at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories may be found at
http://www.ietf.org/shadow.html.
The distribution of this memo is unlimited. It is filed as
<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
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 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.
Arkko et al [Page 1]
INTERNET-DRAFT Home Agent IPsec 20 September 2002
3. Contents
1. Status of this Memo..................................1
2. Abstract.............................................1
3. Contents.............................................2
4. Introduction.........................................3
5. Packet Formats.......................................4
5.1. Binding Updates and Acknowledgements.................4
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
8. Processing Steps within a Node.......................17
8.1. Binding Update to the Home Agent.....................17
8.2. Binding Update from the Mobile Node..................17
8.3. Binding Acknowledgement to the Mobile Node...........18
8.4. Binding Acknowledgement from the Home Agent..........19
8.5. Home Test Init to the Home Agent.....................19
8.6. Home Test Init from the Mobile Node..................20
8.7. Home Test to the Mobile Node.........................20
8.8. Home Test from the Home Agent........................21
8.9. Prefix Solicitation Message to the Home Agent........21
8.10. Prefix Solicitation Message from the Mobile Node.....21
8.11. Prefix Advertisement Message to the Mobile Node......21
8.12. Prefix Advertisement Message from the Home Agent.....22
8.13. Payload Packet to the Home Agent.....................22
8.14. Payload Packet from the Mobile Node..................22
8.15. Payload Packet to the Mobile Node....................22
8.16. Payload Packet from the Home Agent...................22
9. Security Considerations..............................23
10. Open Issues..........................................24
11. References...........................................25
12. Acknowledgements.....................................26
13. Author's Address.....................................27
Arkko et al [Page 2]
INTERNET-DRAFT Home Agent IPsec 20 September 2002
4. Introduction
Mobile IPv6 [1] uses IPsec [2] to protect signaling between the
home agent and the mobile node. This signaling consists of vari-
ous messages carried by the Mobility Header protocol in IPv6.
This signaling traffic takes the following forms:
(1) Binding Update and Acknowledgement messages exchanged
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
the home agent on their way to a correspondent node, as
described in Section 10.7 of [1].
(3) ICMPv6 messages exchanged between the mobile node and
the home agent for the purposes of prefix discovery, as
described in Sections 10.9.3., 11.3.3, and 11.3.4 of [1].
The nodes MAY also optionally protect payload traffic passing
through the home agent, as described in Section 5.3 of [1].
Signaling 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 signaling. Authentication
Header (AH) or Encapsulating Security Payload (ESP) can be used.
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 configu-
ration 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 5. Section 6 describes rules
which associated Mobile IPv6, IPsec, and IKE implementations must
observe. Section 7 discusses how IPsec can be configured to use
either manual or automatically established security associations.
Section 8 shows examples of how packets are processed within the
nodes.
All implementations of Mobile IPv6 mobile node and home agent
MUST support the formats described in Section 5 and obey the
rules in Section 6.
Arkko et al [Page 3]
INTERNET-DRAFT Home Agent IPsec 20 September 2002
5. Packet Formats
In this section we describe the order of headers within the pro-
tected and tunneled packets over the wire. Support for the
described ordering is mandatory for nodes that implement Mobile
IPv6 mobile node or home agent functionality.
5.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
Home Address option (home address)
ESP header or AH header
Mobility header
Binding Update
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:
IPv6 header (source = home agent, destination = care-of address)
Routing header (type 2)
home address
ESP header or AH header
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 have at least the following headers in the following
order:
IPv6 header (source = home address, destination = home agent)
ESP header or AH header
Mobility header
Binding Update
The Binding Acknowledgement messages sent to the home address
MUST have at least the following headers in the following order:
IPv6 header (source = home agent, destination = home address)
ESP header or AH header
Mobility header
Binding Acknowledgement
Arkko et al [Page 4]
INTERNET-DRAFT Home Agent IPsec 20 September 2002
5.2. Return Routability Signaling
When the Home Test Init messages tunneled to the home agent are
protected by IPsec, they MUST have at least the following headers
in the following order:
IPv6 header (source = care-of address, destination = home agent)
ESP header
IPv6 header (source = home address, destination = correspondent node)
Mobility Header
Home Test Init
Similarly, when the Home Test messages tunneled from the home
agent are protected by IPsec, they MUST have at least the follow-
ing headers in the following order:
IPv6 header (source = home agent, destination = care-of address)
ESP header
IPv6 header (source = correspondent node, destination = home address)
Mobility Header
Home Test
Note that these formats rely on the SA destination address (tun-
nel gateway address) to change for the mobile node as it moves.
This is discussed further in the requirements in Section 6.
5.3. Prefix Discovery
If IPsec is used to protect prefix discovery, requests for prefix
from the mobile node 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
Home Address option (home address)
ESP header or AH header
ICMPv6
Mobile Prefix Solicitation
Again if IPsec is used, solicited and unsolicited prefix informa-
tion advertisements from the home agent to the mobile node MUST
have 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 or AH header
ICMPv6
Mobile Prefix Advertisement
5.4. Payload Packets
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
Arkko et al [Page 5]
INTERNET-DRAFT Home Agent IPsec 20 September 2002
case of tunneled Home Test Init messages. However, instead of the
Mobility Header these packets may contain any legal IPv6 proto-
col(s), and it is possible to use both AH and ESP for the protec-
tion:
IPv6 header (source = care-of address, destination = home agent)
ESP header or AH header
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 IPsec protection, they MUST have at
least the following headers in the following order:
IPv6 header (source = home agent, destination = care-of address)
ESP header or AH header
IPv6 header (source = correspondent node, destination = home address)
Any protocol
Arkko et al [Page 6]
INTERNET-DRAFT Home Agent IPsec 20 September 2002
6. 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.
We will start with the main requirements:
- IPsec protection for Binding Updates and Acknowledgements
between the mobile node and home agent MUST be supported and
MUST be used.
- IPsec protection for the Home Test Init and Home Test mes-
sages tunneled between the mobile node and home agent MUST
be supported and SHOULD be used.
- IPsec protection for the ICMPv6 messages related to prefix
discovery MUST be supported and SHOULD be used.
- IPsec protection of the payload packets tunneled between
the mobile node and home agent MAY be supported and used.
- Manual configuration of security associations MUST be sup-
ported and dynamic establishment MAY be supported.
The following rules apply to both home agents and mobile nodes:
- When ESP is used for protecting ICMPv6 or Mobility Header
messages, a non-null authentication algorithm MUST be
applied.
- When ESP is used for protecting tunneled Home Test Init
and Home Test messages, a non-null encryption algorithm and
non-null authentication algorithm MUST be applied.
- If replay protection is required, dynamic keying MUST be
used. IPsec can easily 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.
- IPsec AH 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.
Arkko et al [Page 7]
INTERNET-DRAFT Home Agent IPsec 20 September 2002
- 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.
- When a packet is matched against IPsec security policy, an
address appearing in a Home Address destination option MUST
be considered as the source address of the packet.
- Similarly, a home address within a Type 2 Routing header
MUST be considered as the destination address of the packet.
- When IPsec is used to protect return routability signaling
or payload packets, the security association from the home
agent to the mobile node MUST change its destination address
when the care-of address for the mobile node changes. At the
home agent, this modification takes place when a the care-of
address in a binding changes. At the mobile node, this modi-
fication takes place immediately after movement.
- When IPsec is used to protect return routability signaling
or payload packets, the security policy database entries
MUST be defined specifically for the tunnel interface
between the mobile node and the home agent. That is, the
policy entries are not generally applied on all traffic on
the physical interface(s) of the nodes, but rather only on
traffic that enters this tunnel.
The following rules apply to mobile nodes:
- The mobile node MUST use the Home Address destination
option in Binding Updates and Mobile Prefix Solicitations,
sent to the home agent from a care-of address.
- If the mobile node tunnels Home Test Init messages or pay-
load packets via the home agent with IPsec protection, the
mobile node MUST use the Home Address destination and IPsec
tunnel mode encapsulation.
Depending on whether IPsec AH or ESP is used the protection
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
MUST use the care-of address as the source address in the
Arkko et al [Page 8]
INTERNET-DRAFT Home Agent IPsec 20 September 2002
protocol exchanges.
- Conversely, the IPsec SAs MUST be requested from the key
management protocol with the home address as the mobile
node's address.
The following rules apply to home agents:
- The home agent MUST use the Type 2 Routing header in Bind-
ing Acknowledgements and Mobile Prefix Advertisements sent
to the mobile node, again due to the need to have the home
address visible when the policy checks are made.
- If the home agent tunnels Home Test messages or payload
packets to the mobile node with IPsec protection, the home
agent MUST use the Type 2 Routing header and IPsec tunnel
mode encapsulation.
- We need to avoid the possibility that a mobile node could
use its security association to send a Binding Update on
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 par-
ticular home address.
Arkko et al [Page 9]
INTERNET-DRAFT Home Agent IPsec 20 September 2002
7. Example Configurations
In the following we describe the Security Policy Database (SPD)
and Security Association Database (SAD) entries necessary to pro-
tect 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 7.1 introduces the format we use in the description of
the SPD and the SAD. Section 7.2 describes how to configure man-
ually keyed security associations, and Section 7.3 describes how
to use dynamic keying.
7.1. Format
The format used in the examples is as follows. The SPD descrip-
tion has the format
<node> "SPD OUT:"
"-" <spdentry>
"-" <spdentry>
...
"-" <spdentry>
<node> "SPD IN:"
"-" <spdentry>
"-" <spdentry>
...
"-" <spdentry>
Where <node> represents the name of the node, and <spdentry> has
the following format:
"IF" <condition> "THEN USE" <sa> |
"IF" <condition> "THEN CREATE" <pattern> |
Where <condition> is an boolean expression about the fields of
the IPv6 packet, <sa> is the name of an SA, and <pattern> is a
specification for an SA to be negotiated via IKE. The SAD
description has the format
<node> "SAD:"
"-" <sadentry>
"-" <sadentry>
...
"-" <sadentry>
Where <node> represents the name of the node, and <sadentry> has
the following format:
<sa> "(" <dir> "," <spi> "," <destination> "," <ahesp> "," <mode> ")" ":"
<selectors>
Arkko et al [Page 10]
INTERNET-DRAFT Home Agent IPsec 20 September 2002
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.
7.2. Manual Configuration
7.2.1. Binding Updates and Acknowledgements
Here are the contents of the SPD and SAD for protecting Binding
Updates and Acknowledgements in the mobile node mobile node and
home agent home agent:
mobile node SPD OUT:
- IF source = home address & destination = home agent & proto = MH
THEN USE SA1
mobile node SPD IN:
- IF source = home agent & destination = home address & proto = MH
THEN USE SA2
mobile node SAD:
- SA1(OUT, 5001, home agent, ESP, TRANSPORT):
source = home address & destination = home agent & proto = MH
- SA2(IN, 5002, home address, ESP, TRANSPORT):
source = home agent & destination = home address & proto = MH
home agent SPD OUT:
- IF source = home agent & destination = home address & proto = MH
THEN USE SA2
home agent SPD IN:
- IF source = home address & destination = home agent & proto = MH
THEN USE SA1
home agent SAD:
- SA2(OUT, 5002, home address, ESP, TRANSPORT):
source = home agent & destination = home address & proto = MH
- SA1(IN, 5001, home agent, ESP, TRANSPORT):
source = home address & destination = home agent & proto = MH
7.2.2. Return Routability Signaling
In the following we describe the necessary SPD and SAD entries to
protect return routability signaling between the mobile node and
the home agent. Note that the rules in the SPD are ordered, and
the ones in the previous section must take precedence over these
ones:
mobile node SPD OUT:
- IF interface = tunnel to home agent & source = home address &
destination = any & proto = MH
THEN USE SA3
Arkko et al [Page 11]
INTERNET-DRAFT Home Agent IPsec 20 September 2002
mobile node SPD IN:
- IF interface = tunnel from home agent & source = any &
destination = home address & proto = MH
THEN USE SA4
mobile node SAD:
- SA3(OUT, 5003, home agent, ESP, TUNNEL):
source = home address & destination = any & proto = MH
- SA4(IN, 5004, home address, ESP, TUNNEL):
source = any & destination = home address & proto = MH
home agent SPD OUT:
- IF interface = tunnel to mobile node & source = any &
destination = home address & proto = MH
THEN USE SA4
home agent SPD IN:
- IF interface = tunnel from mobile node & source = home address &
destination = any & proto = MH
THEN USE SA3
home agent SAD:
- SA4(OUT, 5004, home address, ESP, TUNNEL):
source = any & destination = home address & proto = MH
- SA3(IN, 5003, home agent, ESP, TUNNEL):
source = home address & destination = any & proto = MH
7.2.3. Prefix Discovery
In the following we describe some additional SPD and SAD entries
to protect prefix discovery. (Note that when actual new prefixes
are discovered, there may be a need to enter new manually config-
ured SAs to protect Binding Updates.)
mobile node SPD OUT:
- IF source = home address & destination = home agent & proto = ICMPv6
THEN USE SA5
mobile node SPD IN:
- IF source = home agent & destination = home address & proto = ICMPv6
THEN USE SA6
mobile node SAD:
- SA5(OUT, 5005, home agent, ESP, TRANSPORT):
source = home address & destination = home agent & proto = ICMPv6
- SA6(IN, 5006, home address, ESP, TRANSPORT):
source = home agent & destination = home address & proto = ICMPv6
home agent SPD OUT:
- IF source = home agent & destination = home address & proto = ICMPv6
THEN USE SA6
home agent SPD IN:
- IF source = home address & destination = home agent & proto = ICMPv6
Arkko et al [Page 12]
INTERNET-DRAFT Home Agent IPsec 20 September 2002
THEN USE SA5
home agent SAD:
- SA6(OUT, 5006, home address, ESP, TRANSPORT):
source = home agent & destination = home address & proto = ICMPv6
- SA5(IN, 5005, home agent, ESP, TRANSPORT):
source = home address & destination = home agent & proto = ICMPv6
7.2.4. Payload Packets
It is also possible to perform some additional, optional, protec-
tion of tunneled payload packets. This protection takes place in
a similar manner to the return routability protection above, but
requires a different value for the protocol field. The necessary
SPD and SAD entries are shown below. It is assumed that the
entries for protecting Binding Updates and Acknowledgements, and
the entries to protect Home Test Init and Home Test messages take
precedence over these entries.
mobile node SPD OUT:
- IF interface = tunnel to home agent & source = home address
&
destination = any & proto = any
THEN USE SA7
mobile node SPD IN:
- IF interface = tunnel from home agent & source = any &
destination = home address & proto = any
THEN USE SA8
mobile node SAD:
- SA7(OUT, 5007, home agent, ESP, TUNNEL):
source = home address & destination = any & proto = any
- SA8(IN, 5008, home address, ESP, TUNNEL):
source = any & destination = home address & proto = any
home agent SPD OUT:
- IF interface = tunnel to mobile node & source = any &
destination = home address & proto = any
THEN USE SA8
home agent SPD IN:
- IF interface = tunnel from mobile node & source = home
address &
destination = any & proto = any
THEN USE SA7
home agent SAD:
- SA8(OUT, 5008, home address, ESP, TUNNEL):
source = any & destination = home address & proto = any
- SA7(IN, 5007, home agent, ESP, TUNNEL):
source = home address & destination = any & proto = any
Arkko et al [Page 13]
INTERNET-DRAFT Home Agent IPsec 20 September 2002
7.3. Dynamic Keying
In this section we show an example configuration that uses IKE to
negotiate security associations.
7.3.1. Binding Updates and Acknowledgements
Here are the contents of the SPD for protecting Binding Updates
and Acknowledgements:
mobile node SPD OUT:
- IF source = home address & destination = home agent & proto = MH
THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user1
mobile node SPD IN:
- IF source = home agent & destination = home address & proto = MH
THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user1
home agent SPD OUT:
- IF source = home agent & destination = home address & proto = MH
THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user1
home agent SPD IN:
- IF source = home address & destination = home agent & proto = MH
THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user1
(We have omitted details of the proposed transforms in the
above.)
We require IKE to be run using the care-of addresses but still
negotiate IPsec SAs that use home addresses. Note the extra con-
ditions set by the home agent SPD for the peer phase 1 identity.
These are needed, and must be verified by the home agent. The
purpose of the condition is to ensure that the IKE phase 2 nego-
tiation for a given user's home address can't be requested by
another user.
These checks also imply that the configuration of the home agent
is user-specific: every user or home address requires a specific
configuration entry. It would be possible to alleviate the con-
figuration tasks by using certificates that have home addresses
in the Subject AltName field. However, it isn't clear if all IKE
implementations allow one address to be used for carrying the IKE
negotiations when another address is mentioned in the used cer-
tificates. In any case, even this approach would have required
user-specific tasks in the certificate authority.
7.3.2. Return Routability Signaling
Protection for the return routability signaling can be configured
in a similar manner as above.
mobile node SPD OUT:
- IF interface = tunnel to home agent &
Arkko et al [Page 14]
INTERNET-DRAFT Home Agent IPsec 20 September 2002
source = home address & destination = any & proto = MH
THEN CREATE ESP TUNNEL SA: gateway = home agent &
local phase 1 identity = user1
mobile node SPD IN:
- IF interface = tunnel from home agent &
source = any & destination = home address & proto = MH
THEN CREATE ESP TUNNEL SA: gateway = home agent &
local phase 1 identity = user1
home agent SPD OUT:
- IF interface = tunnel to mobile node &
source = any & destination = home address & proto = MH
THEN CREATE ESP TUNNEL SA: gateway = home address &
peer phase 1 identity = user1
home agent SPD IN:
- IF interface = tunnel from mobile node &
source = home address & destination = any & proto = MH
THEN CREATE ESP TUNNEL SA: gateway = home address &
peer phase 1 identity = user1
One difference to the above is that we specified the tunnel gate-
way address, as we need to use a different address for that than
those appearing in the packets.
Note that this specification has still the same problems as the
manual protection for return routability signaling had.
7.3.3. Prefix Discovery
In the following we describe some additional SPD entries to pro-
tect prefix discovery with IKE. (Note that when actual new pre-
fixes are discovered, there may be a need to enter new manually
configured SPD entries to specify the authorization policy for
the resulting new home addresses.)
mobile node SPD OUT:
- IF source = home address & destination = home agent & proto = ICMPv6
THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user1
mobile node SPD IN:
- IF source = home agent & destination = home address & proto = ICMPv6
THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user1
home agent SPD OUT:
- IF source = home agent & destination = home address & proto = ICMPv6
THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user1
home agent SPD IN:
- IF source = home address & destination = home agent & proto = ICMPv6
THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user1
Arkko et al [Page 15]
INTERNET-DRAFT Home Agent IPsec 20 September 2002
7.3.4. Payload Packets
Protection for the payload packets happens similarly to the pro-
tection of return routability signaling. As in the manually keyed
case, these SPD entries have lower priority than the above ones.
mobile node SPD OUT:
- IF interface = tunnel to home agent &
source = home address & destination = any & proto = any
THEN CREATE ESP TUNNEL SA: gateway = home agent &
local phase 1 identity = user1
mobile node SPD IN:
- IF interface = tunnel from home agent &
source = any & destination = home address & proto = any
THEN CREATE ESP TUNNEL SA: gateway = home agent &
local phase 1 identity = user1
home agent SPD OUT:
- IF interface = tunnel to mobile node &
source = any & destination = home address & proto = any
THEN CREATE ESP TUNNEL SA: gateway = home address &
peer phase 1 identity = user1
home agent SPD IN:
- IF interface = tunnel from mobile node &
source = home address & destination = any & proto = any
THEN CREATE ESP TUNNEL SA: gateway = home address &
peer phase 1 identity = user1
Arkko et al [Page 16]
INTERNET-DRAFT Home Agent IPsec 20 September 2002
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
Step 1. At the mobile node, Mobile IPv6 module first produces the
following packet
IPv6 header (source = home address, destination = home agent)
Mobility header
Binding Update
Step 2. This packet is matched against the IPsec policy data base
on the mobile node and we make a note that IPsec must be applied.
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].
This results in:
IPv6 header (source = home address, destination = home agent)
Destination Options header
Home Address option (care-of address)
Mobility header
Binding Update
Step 4. Finally, IPsec headers are added and the necessary
authenticator values are calculated:
IPv6 header (source = home address, destination = home agent)
Destination Options header
Home Address option (care-of address)
ESP header (SPI = 5001)
Mobility header
Binding Update
Step 5. Before forwarding the packet, the addresses in the IPv6
header and the Destination Options header are changed:
IPv6 header (source = care-of address, destination = home agent)
Destination Options header
Home Address option (home address)
ESP header (SPI = 5001)
Mobility header
Binding Update
8.2. Binding Update from the Mobile Node
Step 1. The following packet is received at the home agent:
Arkko et al [Page 17]
INTERNET-DRAFT Home Agent IPsec 20 September 2002
IPv6 header (source = care-of address, destination = home agent)
Destination Options header
Home Address option (home address)
ESP header (SPI = 5001)
Mobility header
Binding Update
Step 2. The home address option is processed first, which results
in
IPv6 header (source = home address, destination = home agent)
Destination Options header
Home Address option (care-of address)
ESP header (SPI = 5001)
Mobility header
Binding Update
Step 3. ESP header is processed next, resulting in
IPv6 header (source = home address, destination = home agent)
Destination Options header
Home Address option (care-of address)
Mobility header
Binding Update
Step 4. This packet matches the SA selectors (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.
8.3. Binding Acknowledgement to the Mobile Node
Step 1. Mobile IPv6 produces the following packet:
IPv6 header (source = home agent, destination = home address)
Mobility header
Binding Acknowledgement
Step 2. This packet matches the IPsec policy entries, and we
remember that IPsec has to be applied.
Step 3. Then, we add the necessary Route Headers but do not
change the addresses yet, as described in Section 9.6 in [1].
This results in:
IPv6 header (source = home agent, destination = home address)
Routing header (type 2)
care-of address
Mobility header
Binding Acknowledgement
Step 4. We apply IPsec:
Arkko et al [Page 18]
INTERNET-DRAFT Home Agent IPsec 20 September 2002
IPv6 header (source = home agent, destination = home address)
Routing header (type 2)
care-of address
ESP header (SPI = 5002)
Mobility header
Binding Acknowledgement
Step 5. Finally, before sending the packet out we change the
addresses in the IPv6 header and the Route header:
IPv6 header (source = home agent, destination = care-of address)
Routing header (type 2)
home address
ESP header (SPI = 5002)
Mobility header
Binding Acknowledgement
8.4. Binding Acknowledgement from the Home Agent
Step 1. The following packet is received at the mobile node
IPv6 header (source = home agent, destination = care-of address)
Routing header (type 2)
home address
ESP header (SPI = 5002)
Mobility header
Binding Acknowledgement
Step 2. After the routing header is processed the packet becomes
IPv6 header (source = home agent, destination = home address)
Routing header (type 2)
care-of address
ESP header (SPI = 5002)
Mobility header
Binding Acknowledgement
Step 3. ESP header is processed next, resulting in:
IPv6 header (source = home agent, destination = home address)
Routing header (type 2)
care-of address
Mobility header
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
IPv6 module.
8.5. Home Test Init to the Home Agent
Step 1. The mobile node constructs a Home Test Init message:
Arkko et al [Page 19]
INTERNET-DRAFT Home Agent IPsec 20 September 2002
IPv6 header (source = home address, destination = correspondent node)
Mobility header
Home Test Init
Step 2. Mobile IPv6 determines that this packet should go to the
tunnel to the home agent.
Step 3. The packet is matched against IPsec policy entries for
the interface, and we find that IPsec needs to be applied.
Step 4. IPsec tunnel mode headers are added. Note that we use a
care-of address as a source address for the tunnel packet.
IPv6 header (source = care-of address, destination = home agent)
ESP header (SPI = 5003)
IPv6 header (source = home address, destination = correspondent node)
Mobility header
Home Test Init
Step 5. The packet no longer satisfies the criteria that made it
enter the tunnel, and it is routed directly to the home agent.
8.6. Home Test Init from the Mobile Node
Step 1. The home agent receives the following packet:
IPv6 header (source = care-of address, destination = home agent)
ESP header (SPI = 5003)
IPv6 header (source = home address, destination = correspondent node)
Mobility Header
Home Test Init
Step 2. IPsec processing is performed, resulting in:
IPv6 header (source = home address, destination = correspondent node)
Mobility Header
Home Test Init
Step 3. The resulting packet matches the selectors and the packet
can be processed further.
Step 4. The packet is then forwarded towards the correspondent
node.
8.7. Home Test to the Mobile Node
Step 1. The home agent receives a Home Test packet from the cor-
respondent node:
IPv6 header (source = correspondent node, destination = home address)
Mobility Header
Home Test Init
Arkko et al [Page 20]
INTERNET-DRAFT Home Agent IPsec 20 September 2002
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 tun-
nel interface, and we note that IPsec needs to be applied.
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 asso-
ciation(s) accordingly.
IPv6 header (source = home agent, destination = care-of address)
ESP header (SPI = 5004)
IPv6 header (source = correspondent node, destination = home address)
Mobility Header
Home Test Init
Step 5. The packet no longer satisfies the criteria that made it
enter the tunnel, and it is routed directly to the care-of
address.
8.8. Home Test from the Home Agent
Step 1. The mobile node receives the following packet:
IPv6 header (source = home agent, destination = care-of address)
ESP header (SPI = 5004)
IPv6 header (source = correspondent node, destination = home address)
Mobility Header
Home Test Init
Step 2. IPsec is processed, resulting in:
IPv6 header (source = correspondent node, destination = home address)
Mobility Header
Home Test Init
Step 3. This matches the SA selectors (source = any, destination
= home address).
Step 4. The packet is given to Mobile IPv6 processing.
8.9. Prefix Solicitation Message to the Home Agent
This procedure is similar to the one presented in Section 8.1.
8.10. Prefix Solicitation Message from the Mobile Node
This procedure is similar to the one presented in Section 8.2.
8.11. Prefix Advertisement Message to the Mobile Node
This procedure is similar to the one presented in Section 8.3.
Arkko et al [Page 21]
INTERNET-DRAFT Home Agent IPsec 20 September 2002
8.12. Prefix Advertisement Message from the Home Agent
This procedure is similar to the one presented in Section 8.4.
8.13. Payload Packet to the Home Agent
This procedure is similar to the one presented in Section 8.5.
8.14. Payload Packet from the Mobile Node
This procedure is similar to the one presented in Section 8.6.
8.15. Payload Packet to the Mobile Node
This procedure is similar to the one presented in Section 8.7.
8.16. Payload Packet from the Home Agent
This procedure is similar to the one presented in Section 8.8.
Arkko et al [Page 22]
INTERNET-DRAFT Home Agent IPsec 20 September 2002
9. Security Considerations
The Mobile IPv6 base specification [1] requires strong security
between the mobile node and the home agent. This memo discusses
how that security can be arranged in practise, using IPsec.
Arkko et al [Page 23]
INTERNET-DRAFT Home Agent IPsec 20 September 2002
10. Open Issues
The following issues should be highlighted as potentially contro-
versial:
- We have chosen to require an encapsulation format for
return routability and payload packet protection which can
only be realized if the IPsec implementation can be con-
trolled via an API. We expect to change the gateway address
of a security association towards the mobile node as the
mobile node moves.
- The base Mobile IPv6 specification sets high requirements
for a so-called Bumb-In-The-Wire (BITS) implementation model
of IPsec. As Mobile IPv6 specific modifications of the pack-
ets are required after IPsec processing, the BITS implemen-
tation has to perform also some tasks related to mobility.
This may increase the complexity of the implementation, even
if it already performs some tasks of the IP layer (such as
fragmentation).
- We have chosen to require policy entries that are specific
to a tunnel interface. While this seems to be required in
the definition of an "interface" in [4], in practise imple-
mentations don't often do this.
- A further complication of the IPsec processing on a tunnel
interface is that this requires access to the BITS implemen-
tation before the packet actually goes out.
- We have chosen to use the MAY keyword in the requirement
for dynamic key management support.
- We have chosen to require that a dynamic key management
protocol must be able to make an authorization decision for
IPsec SA creation with different addresses than where the
key management protocol is run. We expect this to be done
typically by configuring the allowed combinations of phase 1
user identities and home addresses.
- Mobile IPv6 base specification needs to be synchronized
with what is stated in this document. There are also certain
ambiguities in the specification, e.g., what the order of
processing is for reverse tunneling, what the home agent's
procedures are, and so on.
- Compatibility with IPsec remote access VPNs has not been
discussed.
Arkko et al [Page 24]
INTERNET-DRAFT Home Agent IPsec 20 September 2002
11. References
[1] D. Johnson, C. Perkins, J. Arkko "Mobility Support for IPv6",
Internet Draft draft-ietf-mobileip-ipv6-19.txt. (Work In
Progress.) September 2002.
[2] S. Kent, R. Atkinson "Security Architecture for the Internet
Protocol" RFC 2401, BBN Corp, @Home Network, November 1998.
[3] D. Harkins and D. Carrel "The Internet Key Exchange", RFC
2409, Cisco Systems, November 1998.
Arkko et al [Page 25]
INTERNET-DRAFT Home Agent IPsec 20 September 2002
12. Acknowledgements
The authors would like to thank Erik Nordmark, Gabriel Montene-
gro, Kevin Miles, and Cheryl Madson for interesting discussions
in this problem space.
Arkko et al [Page 26]
INTERNET-DRAFT Home Agent IPsec 20 September 2002
13. Author's Address
Jari Arkko
Oy LM Ericsson Ab
02420 Jorvas
Finland
EMail: Jari.Arkko@ericsson.com
Vijay Devarapalli
Nokia Research Center
313 Fairchild Drive
Mountain View, CA 94043
EMail: vijayd@iprg.nokia.com
Francis Dupont
ENST Bretagne
Campus de Rennes 2, rue de la Chataigneraie
BP 78
35512 Cesson-Sevigne Cedex
France
EMail: Francis.Dupont@enst-bretagne.fr
Arkko et al [Page 27]
