Subject: [mobile-ip] Mipv6 issue #194: More details on how movements are handling wrt IKE

From: Jari Arkko <[email-masked]>
Date: Tue, 31 Dec 2002 15:06:58 +0200

Cheryl, you asked a long time ago for additional details regarding
changing IKE and IPsec endpoints. Vijay responded back then with
some answers. The purpose of this e-mail is to try to give a more
complete answer with proposed text. Comments appreciated!

There are several related issues, all related to movements:

- When are the IPsec SA gateway/endpoint addresses changed?

- What happens with IKE endpoints?

- What are the expected processing sequences?

I'll try to answer these issues with the following text. The
overview part will go to 5.2, the requirements to 6, and the
processing sequences will get a new subsection 8.17.

OVERVIEW
========

The format used to protect return routability packets relies on the SA
destination address (tunnel gateway address) to change for the mobile
node as it moves. The home agent's address stays the same, but the
mobile node's gateway address changes upon movements. When the mobile
node adopts a new care-of address, its source address selection rules
will automatically adopt a new source address for outgoing tunnel
packets.

The process is more complicated in the home agent side, as the home
agent has stored the previous care-of address in its Security
Association Database as the gateway address. When IKE is being used,
the mobile node runs it on top of its then current care-of address,
and the resulting tunnel-mode security associations will use the same
addresses as IKE was transported on.

In order for the home agent to be able to tunnel a Home Test message
to the mobile node, the security association used to protect this
message must have the current care-of address. This is accomplished by
having the home agent modify the gateway address of the SA used for
this protection upon accepting a Binding Update. This implies that the
same SA can be used in multiple locations, and no new configuration
or IKE rekeying is needed per movement.

Note that IKE protocol is unable to change its endpoints in this
manner [is this really true?]. Given that IKE is run using care-of
addresses, this renders the current IKE security association unusable
upon movements. A new IKE Phase 1 is therefore needed for rekeying, if
movements have occurred.

REQUIREMENTS
============

Mobile nodes:

- When IPsec is used to protect return routability signaling or
   payload packets, the mobile node MUST set the source address it uses
   for the outgoing tunnel packets to the current primary care-of
   address. The mobile node starts to use a new primary care-of address
   immediately after sending a Binding Update to the home agent to
   register this new address.

- If the mobile node has used IKE to establish security associations
   with its home agent, it SHOULD delete all IKE Phase 1 connections
   run on top of the previous care-of address when the previous care-of
   address is no longer usable or is about to become unusable.

- If the mobile node has used IKE to establish security associations
   with its home agent and wishes to receive notifications from the
   home agent, it MUST re-establish IKE Phase 1 connection after
   movements. It SHOULD do this in parallel with other tasks related to
   movements, such as sending Binding Updates, as the use of existing
   IPsec security associations does not require IKE.

Home agents:

- When IPsec is used to protect return routability signaling or
   payload packets, the security association between the home agent and
   the mobile node MUST change its destination address (tunneled
   gateway 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. No changes are performed if a
   Binding Update is rejected.

- If the home agent has used IKE to establish security associations
   with the mobile node, it SHOULD delete all IKE Phase 1 connections
   run on top of the previous care-of address upon making a
   modification to the care-of address in a binding.

PROCESSING SEQUENCES
====================

In this section we describe the sequence of events that relate to
movement with IKE-based security associations. In the initial
state, the mobile node is not registered in any location and
has no security associations with the home agent.

Step 1. Mobile node with the home address A moves to care-of address B.

Step 2. Mobile node runs IKE from care-of address B to the home
agent, establishing a Phase 1.

Step 3. Protected by this Phase 1, mobile node establishes a pair of
security associations for protecting MH traffic to and from the home
address A.

Step 4. Mobile node sends a Binding Update and receives a Binding
Acknowledgement using the security associations created in Step 3.

Step 5. Mobile node establishes a pair of security associations for
protecting return routability packets. These security associations are
in tunnel mode and their endpoint in the mobile node side is care-of
address B.

Step 6. The mobile node uses the security associations created in
Step 5 to run return routability.

Step 7. The mobile node moves to a new location and adopts a
new care-of address C.

Step 8. Mobile node sends a Binding Update and receives a Binding
Acknowledgement using the security associations created in Step 3.
The home agent modifies the endpoint of the security associations
created in Step 5 to the care-of address C. The home agent and the
mobile node will also remove their Phase 1 connection created on
top of the care-of address B.

Step 9. Optionally, the mobile node establishes a new IKE Phase 1
on top of the care-of address C.

Step 10. The mobile node uses the security associations created in
Step 5 to run return routability. The home agent will be able to send
the Home Test messages back to the mobile node, because the gateway
address was changed to C in Step 8.