proto = ICMPv6
THEN USE SA SA6
home agent SPD IN:
- IF source = home_address_1 & destination = home_agent_1 &
proto = ICMPv6
THEN USE SA SA5
home agent SAD:
- SA6(OUT, spi_f, home_address_1, ESP, TRANSPORT):
source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6
- SA5(IN, spi_e, home_agent_1, ESP, TRANSPORT):
source = home_address_1 & destination = home_agent_1 &
proto = ICMPv6
5.2.4. Payload Packets
It is also possible to perform some additional, optional, protection
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 = IPv6 tunnel to home_agent_1 &
source = home_address_1 & destination = any &
proto = X
THEN USE SA SA7
mobile node SPD IN:
- IF interface = IPv6 tunnel from home_agent_1 &
source = any & destination = home_address_1 &
proto = X
THEN USE SA SA8
mobile node SAD:
- SA7(OUT, spi_g, home_agent_1, ESP, TUNNEL):
source = home_address_1 & destination = any & proto = X
- SA8(IN, spi_h, care_of_address_1, ESP, TUNNEL):
source = any & destination = home_address_1 & proto = X
home agent SPD OUT:
- IF interface = IPv6 tunnel to home_address_1 &
source = any & destination = home_address_1 &
proto = X
THEN USE SA SA8
home agent SPD IN:
- IF interface = IPv6 tunnel from home_address_1 &
source = home_address_1 & destination = any &
proto = X
THEN USE SA SA7
home agent SAD:
- SA8(OUT, spi_h, care_of_address_1, ESP, TUNNEL):
source = any & destination = home_address_1 & proto = X
- SA7(IN, spi_g, home_agent_1, ESP, TUNNEL):
source = home_address_1 & destination = any & proto = X
If multicast group membership control protocols such as MLDv1 [9] or
MLDv2 [11] need to be protected, these packets may use a link-local
address rather than the home address of the mobile node. In this
case the source and destination can be left as a wildcard and the SPD
entries will work solely based on the used interface and the
protocol, which is ICMPv6 for both MLDv1 and MLDv2.
Similar problems are encountered when stateful address
autoconfiguration protocols such as DHCPv6 [10] are used. The same
approach is applicable for DHCPv6 as well. DHCPv6 uses the UDP
protocol.
Support for multiple layers of encapsulation (such as ESP
encapsulated in ESP) is not required by RFC 2401 [2] and is also
otherwise often problematic. It is therefore useful to avoid setting
the protocol X in the above entries to either AH or ESP.
5.3. Dynamic Keying
In this section we show an example configuration that uses IKE to
negotiate security associations.
5.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_1 & destination = home_agent_1 &
proto = MH
THEN USE SA ESP TRANSPORT: local phase 1 identity = user_1
mobile node SPD IN:
- IF source = home_agent_1 & destination = home_address_1 &
proto = MH
THEN USE SA ESP TRANSPORT: local phase 1 identity = user_1
home agent SPD OUT:
- IF source = home_agent_1 & destination = home_address_1 &
proto = MH
THEN USE SA ESP TRANSPORT: peer phase 1 identity = user_1
home agent SPD IN:
- IF source = home_address_1 & destination = home_agent_1 &
proto = MH
THEN USE SA ESP TRANSPORT: peer phase 1 identity = user_1
We have omitted details of the proposed transforms in the 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 version 1 to be run using the care-of addresses but
still negotiate IPsec SAs that use home addresses. The extra
conditions set by the home agent SPD for the peer phase 1 identity to
be "user_1" must be verified by the home agent. The purpose of the
condition is to ensure that the IKE phase 2 negotiation for a given
user’s home address can not be requested by another user. In the
mobile node, we simply set our local identity to be "user_1".
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
configuration tasks by using certificates that have home addresses in
the Subject AltName field. However, it is not clear if all IKE
implementations allow one address to be used for carrying the IKE
negotiations when another address is mentioned in the used
certificates. In any case, even this approach would have required
user-specific tasks in the certification authority.
5.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 = IPv6 tunnel to home_agent_1 &
source = home_address_1 & destination = any &
proto = MH
THEN USE SA ESP TUNNEL: outer destination = home_agent_1 &
local phase 1 identity = user_1
mobile node SPD IN:
- IF interface = IPv6 tunnel from home_agent_1 &
source = any & destination = home_address_1 &
proto = MH
THEN USE SA ESP TUNNEL: outer destination = home_agent_1 &
local phase 1 identity = user_1
home agent SPD OUT:
- IF interface = IPv6 tunnel to home_address_1 &
source = any & destination = home_address_1 &
proto = MH
THEN USE SA ESP TUNNEL: outer destination = home_address_1 &
peer phase 1 identity = user_1
home agent SPD IN:
- IF interface = IPv6 tunnel from home_address_1 &
source = home_address_1 & destination = any &
proto = MH
THEN USE SA ESP TUNNEL: outer destination = home_address_1 &
peer phase 1 identity = user_1
The security association from the home agent to the mobile node uses
the current care-of address as the destination. As discussed
earlier, this address is updated in the SAD as the mobile node moves.
The SPD entries can be written using the home address (as above), if
the care-of address update in the SAD is also done upon the creation
of security associations.
5.3.3. Prefix Discovery
In the following we describe some additional SPD entries to protect
prefix discovery with IKE. (Note that when actual new prefixes 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_1 & destination = home_agent_1 &
proto = ICMPv6
THEN USE SA ESP TRANSPORT: local phase 1 identity = user_1
mobile node SPD IN:
- IF source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6
THEN USE SA ESP TRANSPORT: local phase 1 identity = user_1
home agent SPD OUT:
- IF source = home_agent_1 & destination = home_address_1 &
proto = ICMPv6
THEN USE SA ESP TRANSPORT: peer phase 1 identity = user_1
home agent SPD IN:
- IF source = home_address_1 & destination = home_agent_1 &
proto = ICMPv6
THEN USE SA ESP TRANSPORT: peer phase 1 identity = user_1
5.3.4. Payload Packets
Protection for the payload packets happens similarly to the
protection 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 = IPv6 tunnel to home_agent_1 &
source = home_address_1 & destination = any &
proto = X
THEN USE SA ESP TUNNEL: outer destination = home_agent_1 &
local phase 1 identity = user_1
mobile node SPD IN:
- IF interface = IPv6 tunnel from home_agent_1 &
source = any & destination = home_address_1 &
proto = X
THEN USE SA ESP TUNNEL: outer destination = home_agent_1 &
local phase 1 identity = user_1
home agent SPD OUT:
- IF interface = IPv6 tunnel to home_address_1 &
source = any & destination = home_address_1 &
proto = X
THEN USE SA ESP TUNNEL: outer destination = home_address_1 &
peer phase 1 identity = user_1
home agent SPD IN:
- IF interface = IPv6 tunnel from home_address_1 &
source = home_address_1 & destination = any &
proto = X
THEN USE SA ESP TUNNEL: outer destination = home_address_1 &
peer phase 1 identity = user_1
6. Processing Steps within a Node
6.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 SPD 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.3.2 of the base
specification [7]. 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 = spi_a)
Mobility header
Binding Update
Here spi_a is the SPI value that was either configured manually, or
agreed upon in an earlier IKE negotiation.
Step 5. Before sending 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 = spi_a)
Mobility header
Binding Update
6.2. Binding Update from the Mobile Node
Step 1. The following packet is received at the home agent:
IPv6 header (source = care-of address,
destination = home agent)
Destination Options header
Home Address option (home address)
ESP header (SPI = spi_a)
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 = spi_a)
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 policy required for this security
association (source = home address, destination = home agent, proto =
MH).
Step 5. Mobile IPv6 processes the Binding Update. The Binding
Update is delivered to the Mobile IPv6 module.
Step 6. If there are any security associations in the security
association database for the protection of return routability or
payload packets for this mobile node, those security associations are
updated with the new care-of address.
6.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.5.4 of the base
specification [7]. 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:
IPv6 header (source = home agent,
destination = home address)
Routing header (type 2)
care-of address
ESP header (SPI = spi_b)
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 = spi_b)
Mobility header
Binding Acknowledgement
6.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 = spi_b)
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 = spi_b)
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 policy required for this security
association (source = home agent, destination = home address, proto =
MH).
Step 5. The Binding Acknowledgement is delivered to the Mobile IPv6
module.
6.5. Home Test Init to the Home Agent
Step 1. The mobile node constructs a Home Test Init message:
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 = spi_c)
IPv6 header (source = home address,
destination = correspondent node)
Mobility header
Home Test Init
Step 5. The packet is sent directly to the home agent using IPsec
encapsulation.
6.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 = spi_c)
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 policy required for this
security association and the packet can be processed further.
Step 4. The packet is then forwarded to the correspondent node.
6.7. Home Test to the Mobile Node
Step 1. The home agent receives a Home Test packet from the
correspondent node:
IPv6 header (source = correspondent node,
destination = home address)
Mobility Header
Home Test Init
Step 2. The home agent determines that this packet is destined to a
mobile node that is away from home, and decides to tunnel it.
Step 3. The packet matches the IPsec policy entries for the tunnel
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 endpoint address in the security association(s)
accordingly.
IPv6 header (source = home agent,
destination = care-of address)
ESP header (SPI = spi_d)
IPv6 header (source = correspondent node,
destination = home address)
Mobility Header
Home Test Init
Step 5. The packet is sent directly to the care-of address using
IPsec encapsulation.
6.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 = spi_d)
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 policy required for this security
association (source = any, destination = home address).
Step 4. The packet is given to Mobile IPv6 processing.
6.9. Prefix Solicitation Message to the Home Agent
This procedure is similar to the one presented in Section 6.1.
6.10. Prefix Solicitation Message from the Mobile Node
This procedure is similar to the one presented in Section 6.2.
6.11. Prefix Advertisement Message to the Mobile Node
This procedure is similar to the one presented in Section 6.3.
6.12. Prefix Advertisement Message from the Home Agent
This procedure is similar to the one presented in Section 6.4.
6.13. Payload Packet to the Home Agent
This procedure is similar to the one presented in Section 6.5.
6.14. Payload Packet from the Mobile Node
This procedure is similar to the one presented in Section 6.6.
6.15. Payload Packet to the Mobile Node
This procedure is similar to the one presented in Section 6.7.
6.16. Payload Packet from the Home Agent
This procedure is similar to the one presented in Section 6.8.
6.17. Establishing New Security Associations
Step 1. The mobile node wishes to send a Binding Update to the home
agent.
IPv6 header (source = home address,
destination = home agent)
Mobility header
Binding Update
Step 2. There is no existing security association to protect the
Binding Update, so the mobile node initiates IKE. The IKE packets
are sent as shown in the following examples. The first packet is an
example of an IKE packet sent from the mobile node, and the second
one is from the home agent. The examples shows also that the phase 1
identity used for the mobile node is a FQDN.
IPv6 header (source = care-of address,
destination = home agent)
UDP
IKE
... IDii = ID_FQDN mn123.ha.net ...