Subject: [mobile-ip] Re: Survey on proposed IPv6 multi-homing mechanisms

From: Mattias Pettersson <[email-masked]>
Date: Tue, 26 Jun 2001 15:55:02 +0200

Hi Marcelo,

[cross-posting to mobile-ip list]

marcelo wrote:
> 
> Hi,
> 
> We have been working on a survey of proposals related to IPv6 multi-homing.
> We think that this could be a good input for a discussion about
> which of these ideas can be valuable, and need to be further developed.
> We have included all the mechanisms that we have found. If there are other
> mechanisms, please let us know. We have also includes some advantages and
> concerns about the mechanisms, but we think that discusion will really
> disclose much more points.
[...]
> 5. Mobility mechanisms
> 
> Another proposal presented in [DUPNOT] is based in the use of IP
> mobility mechanisms. The main idea is to use the care-of-address
> assignation mechanism to switch between delegated addresses in case of
> failure. Suppose that there is an established communication between
> 
>                    Survey on multi-homing mecanisms                   7
> 
> hostA belonging to the multi-homed site and hostB, somewhere in the
> Internet, as shown in figure 4.
> 
>   ___________________________________________
>  |                    Internet               |
>  |                 hostB                     |
>  |___________________________________________|
>        |                             |
>        |                             |
>      +----+                        +----+
>      |ISPA|                        |ISPB|
>      |BRA |                        |BRB |
>      +----+                        +----+
>         |                            |
>   link1 |                            | link2
>       __|____________________________|___
>      |   RA                         RB   |
>      |   |                           |   |
>      |  -------------------------------  |
>      |                 |                 |
>      |               hostA               |
>      |        PrefA:Prefsite:hostA       |
>      |        PrefB:Prefsite:hostA       |
>      |                                   |
>      |___________________________________|
> 
>        Figure 4: Mobility mechanisms
> 
> The established connection is being routed through ISPA and
> PrefA:Prefsite:hostA is used. If ISPA fails, the described steps are
> followed in order to preserve communication:
> - HostA packets contain the home address destination option with
>   PrefA:Prefsite:hostA and PrefB:Prefsite:hostA as source address, so
>   that for every device on the path source address is
>   PrefB:Prefsite:hostA and only hostB replaces this source address by
>   PrefA:Prefsite:hostA.
> - HostA sends a binding update containing  PrefB:Prefsite:hostA as a
>   care-of address. Note that that authentication header is needed in
>   this packet.
> - HostB sends a binding  acknowledgement. This packet and all next
>   packets are sent with PrefA:Prefsite:hostA as final destination
>   (included in a routing header) and PrefB:Prefsite:hostA as next
>   destination (included as destination address). Consequently, all
>   packets are sent towards HostA using ISPB, and address "translation"
>   is done when packets reach HostA.
> 
> Mechanism Evaluation:
> 
> Advantages:
> 
> - The mechanism provides complete fault tolerance.
> - It uses existing protocols.
> - It allows ISP selection for load sharing.
> 
>                    Survey on multi-homing mecanisms                   8
> 
> Concerns
> 
> - Needs Mobile IP implementation on destination host. So, modifications
>   in external hosts are needed to achieve internal multi-homing.
> - Mobile IP security mechanisms impose the use of authentication header,
>   raising complexity.
> 
>

Currently, Mobile IP WG has to come up with a solution to establish
security associations between the MN (host A) and the CN (host B). SA
establishment using public key infrastructure is assumed to not be
available everywhere and with all CNs.

The (unofficially?) proposed draft-perkins-bake-00.txt suggests a (weak
but strong enough for the purpose) mechanism that involves a home agent
during the key exchange. The validity of the MN's binding of the home
address is verified by the CN by sending packets via the home network.
The home agent address belongs to the same prefix as the MN's home
address, i.e. PrefA:Prefsite::.

If no SA is set up prior to the failure of ISPA, the key exchange will
fail since the CN can't send packets through the home agent any more.

/Mattias

---

From: Francis Dupont <[email-masked]>
Date: Tue, 26 Jun 2001 17:08:36 +0200

=> please keep further messages in the multi6 list.

   
=> the mobility mechanism for IPv6 multi-homing was proposed before
the security details were specified in the IPv6 mobility drafts...
So don't expect that it works with any suggestion of this year (:-).
More seriously, the idea was that if the mechanism is applied to
critical connections then these connections are already protected
by some mechanisms, i.e. the key material is already available or
very easy to setup.

   
=> a SA set up prior to the failure of ISPA is the very easy case but
can be common. Issues with the lack of home agent are different:
 - the CN should not flush the binding (i.e. a bit/sub-option/...
   is needed, its meaning should be "keep this binding as long as possible")
 - there is no support for mobile to mobile, in the multi-home environment
   this is translated by no support for failure on both the node and
   its CN ISPs or one has to assume that this condition is detectable.
   A common case is the failure of a high level ISP: if both nodes
   are connected to it they will see a failure at the same time,
   to understand this situation is hard but not impossible...
I like this mechanism (of course :-) but we wait for the IPv6 mobility RFC
before work again on it. BTW this is very easy to implement (movement
detection is a dream).

Regards

[email-masked]