draft-ietf-mobileip-mipv6-ha-ipsec-00.txt   draft-ietf-mobileip-mipv6-ha-ipsec-01.txt 
Network Working Group Jari Arkko Network Working Group Jari Arkko
INTERNET-DRAFT Ericsson INTERNET-DRAFT Ericsson
Category: Standards Track Vijay Devarapalli Category: Standards Track Vijay Devarapalli
<draft-ietf-mobileip-mipv6-ha-ipsec-00.txt> Nokia <draft-ietf-mobileip-mipv6-ha-ipsec-01.txt> Nokia
Francis Dupont Francis Dupont
ENST Bretagne ENST Bretagne
20 September 2002 15 October 2002
Using IPsec to Protect Mobile IPv6 Signaling between Using IPsec to Protect Mobile IPv6 Signaling between
Mobile Nodes and Home Agents Mobile Nodes and Home Agents
1. Status of this Memo 1. 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 all provisions of Section 10 of RFC2026. Internet-Drafts are with all provisions of Section 10 of RFC2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), working documents of the Internet Engineering Task Force (IETF),
its areas, and its working groups. Note that other groups may its areas, and its working groups. Note that other groups may
skipping to change at page 2, line 21 skipping to change at page 2, line 21
5. Packet Formats.......................................4 5. Packet Formats.......................................4
5.1. Binding Updates and Acknowledgements.................4 5.1. Binding Updates and Acknowledgements.................4
5.2. Return Routability Signaling.........................5 5.2. Return Routability Signaling.........................5
5.3. Prefix Discovery.....................................5 5.3. Prefix Discovery.....................................5
5.4. Payload Packets......................................5 5.4. Payload Packets......................................5
6. Requirements.........................................7 6. Requirements.........................................7
7. Example Configurations...............................10 7. Example Configurations...............................10
7.1. Format...............................................10 7.1. Format...............................................10
7.2. Manual Configuration.................................11 7.2. Manual Configuration.................................11
7.3. Dynamic Keying.......................................14 7.3. Dynamic Keying.......................................14
8. Processing Steps within a Node.......................17 7.4. Mobile Node Returning Home...........................17
8.1. Binding Update to the Home Agent.....................17 8. Processing Steps within a Node.......................18
8.2. Binding Update from the Mobile Node..................17 8.1. Binding Update to the Home Agent.....................18
8.3. Binding Acknowledgement to the Mobile Node...........18 8.2. Binding Update from the Mobile Node..................18
8.4. Binding Acknowledgement from the Home Agent..........19 8.3. Binding Acknowledgement to the Mobile Node...........19
8.5. Home Test Init to the Home Agent.....................19 8.4. Binding Acknowledgement from the Home Agent..........20
8.6. Home Test Init from the Mobile Node..................20 8.5. Home Test Init to the Home Agent.....................20
8.7. Home Test to the Mobile Node.........................20 8.6. Home Test Init from the Mobile Node..................21
8.8. Home Test from the Home Agent........................21 8.7. Home Test to the Mobile Node.........................21
8.9. Prefix Solicitation Message to the Home Agent........21 8.8. Home Test from the Home Agent........................22
8.10. Prefix Solicitation Message from the Mobile Node.....21 8.9. Prefix Solicitation Message to the Home Agent........22
8.11. Prefix Advertisement Message to the Mobile Node......21 8.10. Prefix Solicitation Message from the Mobile Node.....22
8.12. Prefix Advertisement Message from the Home Agent.....22 8.11. Prefix Advertisement Message to the Mobile Node......22
8.13. Payload Packet to the Home Agent.....................22 8.12. Prefix Advertisement Message from the Home Agent.....23
8.14. Payload Packet from the Mobile Node..................22 8.13. Payload Packet to the Home Agent.....................23
8.15. Payload Packet to the Mobile Node....................22 8.14. Payload Packet from the Mobile Node..................23
8.16. Payload Packet from the Home Agent...................22 8.15. Payload Packet to the Mobile Node....................23
9. Security Considerations..............................23 8.16. Payload Packet from the Home Agent...................23
10. Open Issues..........................................24 9. Implementation Considerations........................24
11. References...........................................25 10. Security Considerations..............................25
12. Acknowledgements.....................................26 11. References...........................................26
13. Author's Address.....................................27 12. Acknowledgements.....................................27
13. Author's Address.....................................28
4. Introduction 4. Introduction
Mobile IPv6 [1] uses IPsec [2] to protect signaling between the Mobile IPv6 [1] uses IPsec [2] to protect signaling between the
home agent and the mobile node. This signaling consists of vari- home agent and the mobile node. This signaling consists of
ous messages carried by the Mobility Header protocol in IPv6. various messages carried by the Mobility Header protocol in
This signaling traffic takes the following forms: IPv6. This signaling traffic takes the following forms:
(1) Binding Update and Acknowledgement messages exchanged (1) Binding Update and Acknowledgement messages exchanged
between the mobile node and the home agent, as described in 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]. 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 (2) Home Test Init and Home Test messages that pass through
the home agent on their way to a correspondent node, as the home agent on their way to a correspondent node, as
described in Section 10.7 of [1]. described in Section 10.7 of [1].
(3) ICMPv6 messages exchanged between the mobile node and (3) ICMPv6 messages exchanged between the mobile node and
the home agent for the purposes of prefix discovery, as 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]. described in Sections 10.9.3., 11.3.3, and 11.3.4 of [1].
The nodes MAY also optionally protect payload traffic passing The nodes MAY also optionally protect payload traffic passing
through the home agent, as described in Section 5.3 of [1]. through the home agent, as described in Section 5.3 of [1].
Signaling between the mobile node and the home agent requires Signaling between the mobile node and the home agent requires
message authentication, integrity, correct ordering and replay message authentication, integrity, correct ordering and replay
protection. The mobile node and the home agent must have an protection. The mobile node and the home agent must have an
security association to protect this signaling. Authentication security association to protect this signaling.
Header (AH) or Encapsulating Security Payload (ESP) can be used.
Mobile IPv6 base document defines the main requirements the Mobile IPv6 base document defines the main requirements the
mobile nodes and home agents must follow when securing the above mobile nodes and home agents must follow when securing the above
traffic. This draft discusses these requirements in more depth, traffic. This draft discusses these requirements in more depth,
illustrates the used packet formats, describes suitable configu- illustrates the used packet formats, describes suitable
ration procedures, and shows how implementations can process the configuration procedures, and shows how implementations can
packets in the right order. process the packets in the right order.
We begin our description by showing the required wire formats for We begin our description by showing the required wire formats for
the protected packets in Section 5. Section 6 describes rules the protected packets in Section 5. Section 6 describes rules
which associated Mobile IPv6, IPsec, and IKE implementations must which associated Mobile IPv6, IPsec, and IKE implementations must
observe. Section 7 discusses how IPsec can be configured to use observe. Section 7 discusses how IPsec can be configured to use
either manual or automatically established security associations. either manual or automatically established security associations.
Section 8 shows examples of how packets are processed within the Section 8 shows examples of how packets are processed within the
nodes. nodes.
All implementations of Mobile IPv6 mobile node and home agent All implementations of Mobile IPv6 mobile node and home agent
MUST support the formats described in Section 5 and obey the MUST support the formats described in Section 5 and obey the
rules in Section 6. rules in Section 6.
5. Packet Formats 5. Packet Formats
In this section we describe the order of headers within the pro- In this section we describe the order of headers within the
tected and tunneled packets over the wire. Support for the protected and tunneled packets over the wire. Support for the
described ordering is mandatory for nodes that implement Mobile described ordering is mandatory for nodes that implement Mobile
IPv6 mobile node or home agent functionality. IPv6 mobile node or home agent functionality.
5.1. Binding Updates and Acknowledgements 5.1. Binding Updates and Acknowledgements
When the mobile node is away from its home, the BUs sent by it to 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 the home agent MUST have at least the following headers in the
following order: following order:
IPv6 header (source = care-of address, destination = home agent) IPv6 header (source = care-of address, destination = home agent)
skipping to change at page 5, line 18 skipping to change at page 5, line 18
protected by IPsec, they MUST have at least the following headers protected by IPsec, they MUST have at least the following headers
in the following order: in 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 are protected by IPsec, they MUST have at least the follow- agent are protected by IPsec, they MUST have at least the
ing 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, 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 (tun- Note that these formats rely on the SA destination address
nel gateway address) to change for the mobile node as it moves. (tunnel gateway address) to change for the mobile node as it
This is discussed further in the requirements in Section 6. moves. This is discussed further in the requirements in Section 6.
5.3. Prefix Discovery 5.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 or AH header
ICMPv6 ICMPv6
Mobile Prefix Solicitation Mobile Prefix Solicitation
Again if IPsec is used, solicited and unsolicited prefix informa- Again if IPsec is used, solicited and unsolicited prefix
tion advertisements from the home agent to the mobile node MUST information advertisements from the home agent to the mobile node
have at least the following headers in the following order. MUST have at 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 or AH header
ICMPv6 ICMPv6
Mobile Prefix Advertisement Mobile Prefix Advertisement
5.4. Payload Packets 5.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 of tunneled Home Test Init messages. However, instead of the case of tunneled Home Test Init messages. However, instead of the
Mobility Header these packets may contain any legal IPv6 proto- Mobility Header these packets may contain any legal IPv6
col(s), and it is possible to use both AH and ESP for the protec- protocol(s), and it is possible to use both AH and ESP for the
tion: protection:
IPv6 header (source = care-of address, destination = home agent) IPv6 header (source = care-of address, destination = home agent)
ESP header or AH header ESP header or AH header
IPv6 header (source = home address, destination = correspondent node) 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 to the mobile node with IPsec protection, they MUST have at agent to the mobile node with IPsec protection, they MUST have at
least the following headers in the following order: least the following headers in the following order:
skipping to change at page 7, line 19 skipping to change at page 7, line 19
to be possible to enable IPsec communications despite movements, to 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 of packets. order of packets.
We will start with the main requirements: We will start with the main requirements:
- IPsec protection for Binding Updates and Acknowledgements - IPsec protection for Binding Updates and Acknowledgements
between the mobile node and home agent MUST be supported and between the mobile node and home agent MUST be supported and
MUST be used. MUST be used.
- IPsec protection for the Home Test Init and Home Test mes- - IPsec protection for the Home Test Init and Home Test
sages tunneled between the mobile node and home agent MUST messages tunneled between the mobile node and home agent
be supported and SHOULD be used. MUST be supported and SHOULD be used.
- IPsec protection for the ICMPv6 messages related to prefix - IPsec protection for the ICMPv6 messages related to prefix
discovery MUST be supported and SHOULD be used. discovery MUST be supported and SHOULD be used.
- IPsec protection of the payload packets tunneled between - IPsec protection of the payload packets tunneled between
the mobile node and home agent MAY be supported and used. the mobile node and home agent MAY be supported and used.
- Manual configuration of security associations MUST be sup- - Manual configuration of security associations MUST be
ported and dynamic establishment MAY be supported. supported and dynamic establishment MAY be supported.
The following rules apply to both home agents and mobile nodes: The following rules apply to both home agents and mobile nodes:
- When ESP is used for protecting ICMPv6 or Mobility Header - When ESP is used for protecting ICMPv6 or Mobility Header
messages, a non-null authentication algorithm MUST be messages, a non-null authentication algorithm MUST be
applied. applied.
- When ESP is used for protecting tunneled Home Test Init - When ESP is used for protecting tunneled Home Test Init
and Home Test messages, a non-null encryption algorithm and and Home Test messages, a non-null encryption algorithm and
non-null authentication algorithm MUST be applied. non-null authentication algorithm MUST be applied.
skipping to change at page 7, line 57 skipping to change at page 7, line 57
that they have not been replayed. Because of this, sequence that they have not been replayed. Because of this, sequence
numbers within the Mobile IPv6 messages ensure correct numbers within the Mobile IPv6 messages ensure correct
ordering. However, if a home agent reboots and loses its ordering. However, if a home agent reboots and loses its
state regarding the sequence numbers, replay attacks become state regarding the sequence numbers, replay attacks become
possible. The use of a key management mechanism together possible. The use of a key management mechanism together
with IPsec can be used to prevent such replay attacks. with IPsec can be used to prevent such replay attacks.
- IPsec AH authenticator calculation MUST be performed as if - IPsec AH authenticator calculation MUST be performed as if
a packet with a Type 2 Routing header would have the home a packet with a Type 2 Routing header would have the home
address in the IPv6 destination address field and the care- address in the IPv6 destination address field and the care-
of address in the Routing header. 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 - Similarly, the authenticator calculation MUST be performed
as if a packet with a Home Address destination option would as if a packet with a Home Address destination option would
have the home address in the IPv6 source address field and have the home address in the IPv6 source address field and
the care-of address in the destination option. the care-of address in the destination option.
- When a packet is matched against IPsec security policy, an - When a packet is matched against IPsec security policy or
address appearing in a Home Address destination option MUST selectors of a security association, an address appearing in
be considered as the source address of the packet. 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 - Similarly, a home address within a Type 2 Routing header
MUST be considered as the destination address of the packet. MUST be considered as the destination address of the packet,
when a packet is matched against IPsec security policy or
selectors of a security association.
- When IPsec is used to protect return routability signaling - When IPsec is used to protect return routability signaling
or payload packets, the security association from the home or payload packets, the security association between the
agent to the mobile node MUST change its destination address home agent and the mobile node MUST change its destination
when the care-of address for the mobile node changes. At the address (tunneled gateway address) when the care-of address
home agent, this modification takes place when a the care-of for the mobile node changes. At the home agent, this
address in a binding changes. At the mobile node, this modi- modification takes place when a the care-of address in a
fication takes place immediately after movement. binding changes. At the mobile node, this modification takes
place immediately after movement.
- When IPsec is used to protect return routability signaling - When IPsec is used to protect return routability signaling
or payload packets, the security policy database entries or payload packets, the security policy database entries
MUST be defined specifically for the tunnel interface SHOULD be defined specifically for the tunnel interface
between the mobile node and the home agent. That is, the between the mobile node and the home agent. That is, the
policy entries are not generally applied on all traffic on policy entries are not generally applied on all traffic on
the physical interface(s) of the nodes, but rather only on the physical interface(s) of the nodes, but rather only on
traffic that enters this tunnel. traffic that enters this tunnel.
The following rules apply to mobile nodes: The following rules apply to mobile nodes:
- The mobile node MUST use the Home Address destination - The mobile node MUST use the Home Address destination
option in Binding Updates and Mobile Prefix Solicitations, option in Binding Updates and Mobile Prefix Solicitations,
sent to the home agent from a care-of address. sent to the home agent from a care-of address.
- If the mobile node tunnels Home Test Init messages or pay- - If IPsec is used to protect return routability signaling
load packets via the home agent with IPsec protection, the or payload packets tunneled via the home agent, IPsec tunnel
mobile node MUST use the Home Address destination and IPsec mode encapsulation MUST be used.
tunnel mode encapsulation.
Depending on whether IPsec AH or ESP is used the protection - Depending on whether IPsec AH or ESP is used the protec-
offered for the Binding Updates is slightly different. AH tion offered for the Binding Updates is slightly different.
protects also the IPv6 header and any extension headers. It AH protects also the IPv6 header and any extension headers.
is important for the home agent to verify that the care-of It is important for the home agent to verify that the care-
address has not been tampered. If ESP is used, the IPv6 of address has not been tampered. If ESP is used, the IPv6
header where this information resides could potentially have header where this information resides could potentially have
been modified by attackers on the path. As a result, the been modified by attackers on the path. As a result, the
attacker would have redirected the mobile node's traffic to attacker would have redirected the mobile node's traffic to
another address. In order to prevent this, Mobile IPv6 another address. In order to prevent this, Mobile IPv6
implementations MUST use the Alternate Care-of Address implementations MUST use the Alternate Care-of Address
mobility option when ESP is used, or when the implementation mobility option when ESP is used, or when the implementation
does not know whether AH or ESP is used. does not know whether AH or ESP is used.
- Where dynamic keying is used, the key management protocol - Where dynamic keying is used, the key management protocol
MUST use the care-of address as the source address in the MUST use the care-of address as the source address in the
protocol exchanges. protocol exchanges.
- Conversely, the IPsec SAs MUST be requested from the key - Conversely, the IPsec SAs MUST be requested from the key
management protocol with the home address as the mobile management protocol with the home address as the mobile
node's address. node's 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 Bind- - The home agent MUST use the Type 2 Routing header in
ing Acknowledgements and Mobile Prefix Advertisements sent Binding Acknowledgements and Mobile Prefix Advertisements
to the mobile node, again due to the need to have the home sent to the mobile node, again due to the need to have the
address visible when the policy checks are made. home address visible when the policy checks are made.
- If the home agent tunnels Home Test messages or payload - If IPsec is used to protect return routability signaling
packets to the mobile node with IPsec protection, the home or payload packets tunneled to and from the mobile node,
agent MUST use the Type 2 Routing header and IPsec tunnel IPsec tunnel mode encapsulation MUST be used.
mode encapsulation.
- We need to avoid the possibility that a mobile node could - We need to avoid the possibility that a mobile node could
use its security association to send a Binding Update on use its security association to send a Binding Update on
behalf of another mobile node using the same home agent. In behalf of another mobile node using the same home agent. In
order to do this, the security policy database entries MUST order to do this, the security policy database entries MUST
unequivocally identify a single SA for any given home unequivocally identify a single SA for any given home
address and home agent when manual keying is used. When address and home agent when manual keying is used. When
dynamic keying is used, the security policy database entries dynamic keying is used, the security policy database entries
MUST unequivocally identify the IKE phase 1 credentials MUST unequivocally identify the IKE phase 1 credentials
which can be used to create security associations for a par- which can be used to create security associations for a
ticular home address. particular home address.
7. Example Configurations 7. Example Configurations
In the following we describe the Security Policy Database (SPD) In the following we describe the Security Policy Database (SPD)
and Security Association Database (SAD) entries necessary to pro- and Security Association Database (SAD) entries necessary to
tect Binding Updates and Binding Acknowledgements exchanged protect Binding Updates and Binding Acknowledgements exchanged
between the mobile node and the home agent. Our examples assume between the mobile node and the home agent. Our examples assume
the use of ESP, but a similar configuration could also be used to the use of ESP, but a similar configuration could also be used to
protect the messages with AH. protect the messages with AH.
Section 7.1 introduces the format we use in the description of 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- the SPD and the SAD. Section 7.2 describes how to configure
ually keyed security associations, and Section 7.3 describes how manually keyed security associations, and Section 7.3 describes
to use dynamic keying. how to use dynamic keying.
7.1. Format 7.1. Format
The format used in the examples is as follows. The SPD descrip- The format used in the examples is as follows. The SPD
tion has the format 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>
skipping to change at page 11, line 9 skipping to change at page 11, line 9
Where <node> represents the name of the node, and <sadentry> has Where <node> represents the name of the node, and <sadentry> has
the following format: the following format:
<sa> "(" <dir> "," <spi> "," <destination> "," <ahesp> "," <mode> ")" ":" <sa> "(" <dir> "," <spi> "," <destination> "," <ahesp> "," <mode> ")" ":"
<selectors> <selectors>
Where <dir> is "IN" or "OUT", <spi> is the SPI of the SA, <desti- 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 nation> is the destination of the SA, <ahesp> is either "AH" or
"ESP", <mode> is either "TUNNEL" or "TRANSPORT", and <selectors> "ESP", <mode> is either "TUNNEL" or "TRANSPORT", and <selectors>
is a boolean expression about the fields of the IPv6 packet. is a boolean expression about the fields of the IPv6 packet.
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. Manual Configuration 7.2. Manual Configuration
7.2.1. Binding Updates and Acknowledgements 7.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 agent home agent: home agent home agent:
mobile node SPD OUT: mobile node SPD OUT:
- IF source = home address & destination = home agent & proto = MH - IF source = home_address_1 & destination = home_agent_1 &
proto = MH
THEN USE SA1 THEN USE SA1
mobile node SPD IN: mobile node SPD IN:
- IF source = home agent & destination = home address & proto = MH - IF source = home_agent_1 & destination = home_address_1 &
proto = MH
THEN USE SA2 THEN USE SA2
mobile node SAD: mobile node SAD:
- SA1(OUT, 5001, home agent, ESP, TRANSPORT): - SA1(OUT, spi_a, home_agent_1, ESP, TRANSPORT):
source = home address & destination = home agent & proto = MH source = home_address_1 & destination = home_agent_1 &
- SA2(IN, 5002, home address, ESP, TRANSPORT): proto = MH
source = home agent & destination = home address & proto = MH - SA2(IN, spi_b, home_address_1, ESP, TRANSPORT):
source = home_agent_1 & destination = home_address_1 &
proto = MH
home agent SPD OUT: home agent SPD OUT:
- IF source = home agent & destination = home address & proto = MH - IF source = home_agent_1 & destination = home_address_1 &
proto = MH
THEN USE SA2 THEN USE SA2
home agent SPD IN: home agent SPD IN:
- IF source = home address & destination = home agent & proto = MH - IF source = home_address_1 & destination = home_agent_1 &
proto = MH
THEN USE SA1 THEN USE SA1
home agent SAD: home agent SAD:
- SA2(OUT, 5002, home address, ESP, TRANSPORT): - SA2(OUT, spi_b, home_address_1, ESP, TRANSPORT):
source = home agent & destination = home address & proto = MH source = home_agent_1 & destination = home_address_1 &
- SA1(IN, 5001, home agent, ESP, TRANSPORT): proto = MH
source = home address & destination = home agent & proto = MH - SA1(IN, spi_a, home_agent_1, ESP, TRANSPORT):
source = home_address_1 & destination = home_agent_1 &
proto = MH
7.2.2. Return Routability Signaling 7.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 home agent. Note that the rules in the SPD are ordered, 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 the ones 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 & source = home address & - IF interface = tunnel to home_agent_1 & source = home_address_1 &
destination = any & proto = MH destination = any & proto = MH
THEN USE SA3 THEN USE SA3
mobile node SPD IN: mobile node SPD IN:
- IF interface = tunnel from home agent & source = any & - IF interface = tunnel from home_agent_1 & source = any &
destination = home address & proto = MH destination = home_address_1 & proto = MH
THEN USE SA4 THEN USE SA4
mobile node SAD: mobile node SAD:
- SA3(OUT, 5003, home agent, ESP, TUNNEL): - SA3(OUT, spi_c, home_agent_1, ESP, TUNNEL):
source = home address & destination = any & proto = MH source = home_address_1 & destination = any & proto = MH
- SA4(IN, 5004, home address, ESP, TUNNEL): - SA4(IN, spi_d, home_address_1, ESP, TUNNEL):
source = any & destination = home address & proto = MH source = any & destination = home_address_1 & proto = MH
home agent SPD OUT: home agent SPD OUT:
- IF interface = tunnel to mobile node & source = any & - IF interface = tunnel to home_address_1 & source = any &
destination = home address & proto = MH destination = home_address_1 & proto = MH
THEN USE SA4 THEN USE SA4
home agent SPD IN: home agent SPD IN:
- IF interface = tunnel from mobile node & source = home address & - IF interface = tunnel from home_address_1 & source = home_address_1 &
destination = any & proto = MH destination = any & proto = MH
THEN USE SA3 THEN USE SA3
home agent SAD: home agent SAD:
- SA4(OUT, 5004, home address, ESP, TUNNEL): - SA4(OUT, spi_d, home_address_1, ESP, TUNNEL):
source = any & destination = home address & proto = MH source = any & destination = home_address_1 & proto = MH
- SA3(IN, 5003, home agent, ESP, TUNNEL): - SA3(IN, spi_c, home_agent_1, ESP, TUNNEL):
source = home address & destination = any & proto = MH source = home_address_1 & destination = any & proto = MH
7.2.3. Prefix Discovery 7.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 protect prefix discovery. (Note that when actual new prefixes to protect prefix discovery.
are discovered, there may be a need to enter new manually config-
ured SAs to protect Binding Updates.)
mobile node SPD OUT: mobile node SPD OUT:
- IF source = home address & destination = home agent & proto = ICMPv6 - IF source = home_address_1 & destination = home_agent_1 &
THEN USE SA5 proto = ICMPv6
THEN USE SA5.
mobile node SPD IN: mobile node SPD IN:
- IF source = home agent & destination = home address & proto = ICMPv6 - IF source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6
THEN USE SA6 THEN USE SA6
mobile node SAD: mobile node SAD:
- SA5(OUT, 5005, home agent, ESP, TRANSPORT): - SA5(OUT, spi_e, home_agent_1, ESP, TRANSPORT):
source = home address & destination = home agent & proto = ICMPv6 source = home_address_1 & destination = home_agent_1 &
- SA6(IN, 5006, home address, ESP, TRANSPORT): proto = ICMPv6
source = home agent & destination = home address & proto = ICMPv6 - SA6(IN, spi_f, home_address_1, ESP, TRANSPORT):
source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6
home agent SPD OUT: home agent SPD OUT:
- IF source = home agent & destination = home address & proto = ICMPv6 - IF source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6
THEN USE SA6 THEN USE SA6
home agent SPD IN: home agent SPD IN:
- IF source = home address & destination = home agent & proto = ICMPv6 - IF source = home_address_1 & destination = home_agent_1 &
proto = ICMPv6
THEN USE SA5 THEN USE SA5
home agent SAD: home agent SAD:
- SA6(OUT, 5006, home address, ESP, TRANSPORT): - SA6(OUT, spi_f, home_address_1, ESP, TRANSPORT):
source = home agent & destination = home address & proto = ICMPv6 source = home_agent_1 & destination = home_address_1 &
- SA5(IN, 5005, home agent, ESP, TRANSPORT): proto = ICMPv6
source = home address & destination = home agent & proto = ICMPv6 - SA5(IN, spi_e, home_agent_1, ESP, TRANSPORT):
source = home_address_1 & destination = home_agent_1 &
proto = ICMPv6
Note that the SPDs described above protect all ICMPv6 traffic
between 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 7.2.4. Payload Packets
It is also possible to perform some additional, optional, protec- It is also possible to perform some additional, optional,
tion of tunneled payload packets. This protection takes place in protection of tunneled payload packets. This protection takes
a similar manner to the return routability protection above, but place in a similar manner to the return routability protection
requires a different value for the protocol field. The necessary above, but requires a different value for the protocol field. The
SPD and SAD entries are shown below. It is assumed that the necessary SPD and SAD entries are shown below. It is assumed that
entries for protecting Binding Updates and Acknowledgements, and the entries for protecting Binding Updates and Acknowledgements,
the entries to protect Home Test Init and Home Test messages take and the entries to protect Home Test Init and Home Test messages
precedence over these entries. take precedence over these entries.
mobile node SPD OUT: mobile node SPD OUT:
- IF interface = tunnel to home agent & source = home address - IF interface = tunnel to home_agent_1 & source =
& home_address_1 &
destination = any & proto = any destination = any & proto = X
THEN USE SA7 THEN USE SA7
mobile node SPD IN: mobile node SPD IN:
- IF interface = tunnel from home agent & source = any & - IF interface = tunnel from home_agent_1 & source = any &
destination = home address & proto = any destination = home_address_1 & proto = X
THEN USE SA8 THEN USE SA8
mobile node SAD: mobile node SAD:
- SA7(OUT, 5007, home agent, ESP, TUNNEL): - SA7(OUT, spi_g, home_agent_1, ESP, TUNNEL):
source = home address & destination = any & proto = any source = home_address_1 & destination = any & proto = X
- SA8(IN, 5008, home address, ESP, TUNNEL): - SA8(IN, spi_h, home_address_1, ESP, TUNNEL):
source = any & destination = home address & proto = any source = any & destination = home_address_1 & proto = X
home agent SPD OUT: home agent SPD OUT:
- IF interface = tunnel to mobile node & source = any & - IF interface = tunnel to home_address_1 & source = any &
destination = home address & proto = 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 mobile node & source = home - IF interface = tunnel from home_address_1 & source =
address & home_address_1 &
destination = any & proto = any destination = any & proto = X
THEN USE SA7 THEN USE SA7
home agent SAD: home agent SAD:
- SA8(OUT, 5008, home address, ESP, TUNNEL): - SA8(OUT, spi_h, home_address_1, ESP, TUNNEL):
source = any & destination = home address & proto = any source = any & destination = home_address_1 & proto = X
- SA7(IN, 5007, home agent, ESP, TUNNEL): - SA7(IN, spi_g, home_agent_1, ESP, TUNNEL):
source = home address & destination = any & proto = any source = home_address_1 & destination = any & proto = X
7.3. Dynamic Keying 7.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 7.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 Acknowledgements: and Acknowledgements:
mobile node SPD OUT: mobile node SPD OUT:
- IF source = home address & destination = home agent & proto = MH - IF source = home_address_1 & destination = home_agent_1 & proto = MH
THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user1 THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user_1
mobile node SPD IN: mobile node SPD IN:
- IF source = home agent & destination = home address & proto = MH - IF source = home_agent_1 & destination = home_address_1 & proto = MH
THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user1 THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user_1
home agent SPD OUT: home agent SPD OUT:
- IF source = home agent & destination = home address & proto = MH - IF source = home_agent_1 & destination = home_address_1 & proto = MH
THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user1 THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user_1
home agent SPD IN: home agent SPD IN:
- IF source = home address & destination = home agent & proto = MH - IF source = home_address_1 & destination = home_agent_1 & proto = MH
THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user1 THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user_1
(We have omitted details of the proposed transforms in the We have omitted details of the proposed transforms in the above,
above.) and all details related to the particular authentication method
such as certificates beyond listing a specific identity that must
be used.
We require IKE to be run using the care-of addresses but still We require IKE to be run using the care-of addresses but still
negotiate IPsec SAs that use home addresses. Note the extra con- negotiate IPsec SAs that use home addresses. The extra conditions
ditions set by the home agent SPD for the peer phase 1 identity. set by the home agent SPD for the peer phase 1 identity to be
These are needed, and must be verified by the home agent. The "user_1" must be verified by the home agent. The purpose of the
purpose of the condition is to ensure that the IKE phase 2 nego- condition is to ensure that the IKE phase 2 negotiation for a
tiation for a given user's home address can't be requested by given user's home address can't be requested by another user. In
another user. the 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 user-specific: every user or home address requires a specific is user-specific: every user or home address requires a specific
configuration entry. It would be possible to alleviate the con- configuration entry. It would be possible to alleviate the
figuration tasks by using certificates that have home addresses configuration tasks by using certificates that have home addresses
in the Subject AltName field. However, it isn't clear if all IKE in 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 cer-
tificates. In any case, even this approach would have required tificates. 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 7.3.2. Return Routability Signaling
Protection for the return routability signaling can be configured Protection for the return routability signaling can be configured
in a similar manner as above. in a similar manner as above.
mobile node SPD OUT: mobile node SPD OUT:
- IF interface = tunnel to home agent & - IF interface = tunnel to home_agent_1 &
source = home address & destination = any & proto = MH source = home_address_1 & destination = any & proto = MH
THEN CREATE ESP TUNNEL SA: gateway = home agent & THEN CREATE ESP TUNNEL SA: gateway = home_agent_1 &
local phase 1 identity = user1 local phase 1 identity = user_1
mobile node SPD IN: mobile node SPD IN:
- IF interface = tunnel from home agent & - IF interface = tunnel from home_agent_1 &
source = any & destination = home address & proto = MH source = any & destination = home_address_1 & proto = MH
THEN CREATE ESP TUNNEL SA: gateway = home agent & THEN CREATE ESP TUNNEL SA: gateway = home_agent_1 &
local phase 1 identity = user1 local phase 1 identity = user_1
home agent SPD OUT: home agent SPD OUT:
- IF interface = tunnel to mobile node & - IF interface = tunnel to home_address_1 &
source = any & destination = home address & proto = MH source = any & destination = home_address_1 & proto = MH
THEN CREATE ESP TUNNEL SA: gateway = home address & THEN CREATE ESP TUNNEL SA: gateway = home_address_1 &
peer phase 1 identity = user1 peer phase 1 identity = user_1
home agent SPD IN: home agent SPD IN:
- IF interface = tunnel from mobile node & - IF interface = tunnel from home_address_1 &
source = home address & destination = any & proto = MH source = home_address_1 & destination = any & proto = MH
THEN CREATE ESP TUNNEL SA: gateway = home address & THEN CREATE ESP TUNNEL SA: gateway = home_address_1 &
peer phase 1 identity = user1 peer phase 1 identity = user_1
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 One difference to the above is that we specified the tunnel
manual protection for return routability signaling had. gateway address, as we need to use a different address for that
than those appearing in the packets.
7.3.3. Prefix Discovery 7.3.3. Prefix Discovery
In the following we describe some additional SPD entries to pro- In the following we describe some additional SPD entries to
tect prefix discovery with IKE. (Note that when actual new pre- protect prefix discovery with IKE. (Note that when actual new
fixes are discovered, there may be a need to enter new manually prefixes are discovered, there may be a need to enter new
configured SPD entries to specify the authorization policy for manually configured SPD entries to specify the authorization
the resulting new home addresses.) policy for the resulting new home addresses.)
mobile node SPD OUT: mobile node SPD OUT:
- IF source = home address & destination = home agent & proto = ICMPv6 - IF source = home_address_1 & destination = home_agent_1 & proto = ICMPv6
THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user1 THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user_1
mobile node SPD IN: mobile node SPD IN:
- IF source = home agent & destination = home address & proto = ICMPv6 - IF source = home_agent_1 & destination = home_address_1 & proto = ICMPv6
THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user1 THEN CREATE ESP TRANSPORT SA: local phase 1 identity = user_1
home agent SPD OUT: home agent SPD OUT:
- IF source = home agent & destination = home address & proto = ICMPv6 - IF source = home_agent_1 & destination = home_address_1 & proto = ICMPv6
THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user1 THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user_1
home agent SPD IN: home agent SPD IN:
- IF source = home address & destination = home agent & proto = ICMPv6 - IF source = home_address_1 & destination = home_agent_1 & proto = ICMPv6
THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user1 THEN CREATE ESP TRANSPORT SA: peer phase 1 identity = user_1
7.3.4. Payload Packets 7.3.4. Payload Packets
Protection for the payload packets happens similarly to the pro- Protection for the payload packets happens similarly to the
tection of return routability signaling. As in the manually keyed protection of return routability signaling. As in the manually
case, these SPD entries have lower priority than the above ones. keyed case, these SPD entries have lower priority than the above
ones.
mobile node SPD OUT: mobile node SPD OUT:
- IF interface = tunnel to home agent & - IF interface = tunnel to home_agent_1 &
source = home address & destination = any & proto = any source = home_address_1 & destination = any & proto = X
THEN CREATE ESP TUNNEL SA: gateway = home agent & THEN CREATE ESP TUNNEL SA: gateway = home_agent_1 &
local phase 1 identity = user1 local phase 1 identity = user_1
mobile node SPD IN: mobile node SPD IN:
- IF interface = tunnel from home agent & - IF interface = tunnel from home_agent_1 &
source = any & destination = home address & proto = any source = any & destination = home_address_1 & proto = X
THEN CREATE ESP TUNNEL SA: gateway = home agent & THEN CREATE ESP TUNNEL SA: gateway = home_agent_1 &
local phase 1 identity = user1 local phase 1 identity = user_1
home agent SPD OUT: home agent SPD OUT:
- IF interface = tunnel to mobile node & - IF interface = tunnel to home_address_1 &
source = any & destination = home address & proto = any source = any & destination = home_address_1 & proto = X
THEN CREATE ESP TUNNEL SA: gateway = home address & THEN CREATE ESP TUNNEL SA: gateway = home_address_1 &
peer phase 1 identity = user1 peer phase 1 identity = user_1
home agent SPD IN: home agent SPD IN:
- IF interface = tunnel from mobile node & - IF interface = tunnel from home_address_1 &
source = home address & destination = any & proto = any source = home_address_1 & destination = any & proto = X
THEN CREATE ESP TUNNEL SA: gateway = home address & THEN CREATE ESP TUNNEL SA: gateway = home_address_1 &
peer phase 1 identity = user1 peer phase 1 identity = user_1
7.4. Mobile Node Returning Home
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 8. Processing Steps within a Node
In this section we give examples of what processing steps node In this section we give examples of what processing steps node
can take to achieve the required packet formats and satisfy the can take to achieve the required packet formats and satisfy the
requirements. These example are for illustration purposes only, requirements. These example are for illustration purposes only,
and implementations are free to choose other strategies as long and implementations are free to choose other strategies as long
as the results stay the same on the wire. as the results stay the same on the wire.
8.1. Binding Update to the Home Agent 8.1. Binding Update to the Home Agent
skipping to change at page 17, line 41 skipping to change at page 18, line 41
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 = 5001) ESP header (SPI = spi_a)
Mobility header Mobility header
Binding Update Binding Update
Step 5. Before forwarding the packet, the addresses in the IPv6 Step 5. Before sending the packet, the addresses in the IPv6
header and the Destination Options header are changed: header 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 = 5001) ESP header (SPI = spi_a)
Mobility header Mobility header
Binding Update Binding Update
8.2. Binding Update from the Mobile Node 8.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 = 5001) 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 = 5001) 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
skipping to change at page 19, line 8 skipping to change at page 20, line 8
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 = 5002) 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 = 5002) ESP header (SPI = spi_b)
Mobility header Mobility header
Binding Acknowledgement Binding Acknowledgement
8.4. Binding Acknowledgement from the Home Agent 8.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 = 5002) 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, 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 = 5002) 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
skipping to change at page 20, line 19 skipping to change at page 21, line 19
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 interface, and we find that IPsec needs to be applied. the 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 = 5003) 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 routed 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 8.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 = 5003) 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 towards the correspondent
node. node.
8.7. Home Test to the Mobile Node 8.7. Home Test to the Mobile Node
Step 1. The home agent receives a Home Test packet from the cor- Step 1. The home agent receives a Home Test packet from the
respondent 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 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. 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- Step 3. The packet matches the IPsec policy entries for the
nel interface, and we note that IPsec needs to be applied. tunnel interface, and we note that IPsec needs to be applied.
Step 4. IPsec is applied, resulting in a new packet. Note that Step 4. IPsec is applied, resulting in a new packet. Note that
the home agent must keep track of the location of the mobile the home agent must keep track of the location of the mobile
node, and update the tunnel gateway address in the security asso- node, and update the tunnel gateway address in the security
ciation(s) accordingly. association(s) accordingly.
IPv6 header (source = home agent, destination = care-of address) IPv6 header (source = home agent, destination = care-of address)
ESP header (SPI = 5004) 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 routed directly to the care-of enter the tunnel, and it is sent directly to the care-of address.
address.
8.8. Home Test from the Home Agent 8.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 = 5004) 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
skipping to change at page 23, line 5 skipping to change at page 24, line 5
This procedure is similar to the one presented in Section 8.6. This procedure is similar to the one presented in Section 8.6.
8.15. Payload Packet to the Mobile Node 8.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 8.7.
8.16. Payload Packet from the Home Agent 8.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 8.8.
9. Security Considerations 9. Implementation 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.
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 We have chosen to require an encapsulation format for return
for a so-called Bumb-In-The-Wire (BITS) implementation model routability and payload packet protection which can only be
of IPsec. As Mobile IPv6 specific modifications of the pack- realized if the IPsec implementation can be controlled via an
ets are required after IPsec processing, the BITS implemen- API. One of the main reasons for choosing such a format is that
tation has to perform also some tasks related to mobility. it removes the overhead of twenty four bytes when a home address
This may increase the complexity of the implementation, even option or routing header is added to the tunneled packet. The API
if it already performs some tasks of the IP layer (such as should minimally support changing the gateway address of a
fragmentation). security association towards the mobile node as the mobile node
moves. Implementations are free to choose other methods to update
a security association. This includes deleting the current SA
and adding a new SA.
- We have chosen to require policy entries that are specific We have also chosen to require that a dynamic key management
to a tunnel interface. While this seems to be required in protocol must be able to make an authorization decision for IPsec
the definition of an "interface" in [4], in practise imple- SA creation with different addresses than with what the key
mentations don't often do this. management protocol is run. We expect this to be done typically by
configuring the allowed combinations of phase 1 user identities
and home addresses.
- A further complication of the IPsec processing on a tunnel The base Mobile IPv6 specification sets high requirements for a
interface is that this requires access to the BITS implemen- so-called Bump-In-The-Stack (BITS) implementation model of IPsec.
tation before the packet actually goes out. As Mobile IPv6 specific modifications of the packets are required
after IPsec processing, the BITS implementation has to perform
also some tasks related to mobility. This may increase the
complexity of the implementation, even if it already performs
some tasks of the IP layer (such as fragmentation).
- We have chosen to use the MAY keyword in the requirement We have chosen to require policy entries that are specific to a
for dynamic key management support. tunnel interface. This means that implementations have to regard
the Home Agent - Mobile Node tunnel as a separate interface on
which IPsec SPDs can be based.
- We have chosen to require that a dynamic key management A further complication of the IPsec processing on a tunnel
protocol must be able to make an authorization decision for interface is that this requires access to the BITS implementation
IPsec SA creation with different addresses than where the before the packet actually goes out.
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 10. Security Considerations
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 The Mobile IPv6 base specification [1] requires strong security
discussed. between the mobile node and the home agent. This memo discusses
how that security can be arranged in practise, using IPsec.
11. References 11. References
[1] D. Johnson, C. Perkins, J. Arkko "Mobility Support for IPv6", [1] D. Johnson, C. Perkins, J. Arkko, "Mobility Support for
Internet Draft draft-ietf-mobileip-ipv6-19.txt. (Work In IPv6", Internet Draft draft-ietf-mobileip-ipv6-19.txt. (Work In
Progress.) September 2002. Progress.) September 2002.
[2] S. Kent, R. Atkinson "Security Architecture for the Internet [2] S. Kent, R. Atkinson, "Security Architecture for the
Protocol" RFC 2401, BBN Corp, @Home Network, November 1998. Internet Protocol" RFC 2401, BBN Corp, @Home Network, November 1998.
[3] D. Harkins and D. Carrel "The Internet Key Exchange", RFC [3] D. Harkins and D. Carrel, "The Internet Key Exchange", RFC
2409, Cisco Systems, November 1998. 2409, Cisco Systems, November 1998.
[4] S. Deering and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
12. Acknowledgements 12. Acknowledgements
The authors would like to thank Erik Nordmark, Gabriel Montene- The authors would like to thank Erik Nordmark, Gabriel
gro, Kevin Miles, and Cheryl Madson for interesting discussions Montenegro, Kevin Miles, Cheryl Madson and Jari T. Malinen for
in this problem space. interesting discussions in this problem space.
13. Author's Address 13. Author's Address
Jari Arkko Jari Arkko
Oy LM Ericsson Ab Oy LM Ericsson Ab
02420 Jorvas 02420 Jorvas
Finland Finland
EMail: Jari.Arkko@ericsson.com EMail: Jari.Arkko@ericsson.com
 End of changes. 

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