Re: [Hipsec] HIP host multihoming questions

["Henderson, Thomas R" <[e-mail]>]

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of TAO YUAN
> Sent: Tuesday, May 04, 2010 1:06 AM
> To: [e-mail]
> Subject: [Hipsec] HIP host multihoming questions
>
> Hi, all
>
> I have some questions about HIP host multihoming.
>
> Consider a scenario described below:
>
> Host A is a multihomed HIP host, which using address IP1 on iterface_1
> to communicate with host B. For fault-tolerant or maybe some other
> purposes, A decides to inform B about its another address IP2 on
> interface_2.
> According to rfc5206, it is a 3-way update process. After this, a new
> pair of SA is created between A and B. We assumed A needs to switch
> its communication with B from interface_1 to interface_2.This may
> caused by the breakdown of interface_1's connected link or upper
> applications' requirements for better performance. Host A initiates
> another 3-way update process, which aims at informing B to send
> packets to A's interface_2 instead of interface_1. If not doing this,
> B may still send packet to interface_1, since it always regards IP1 as
> the preferred address until receives A's notification. More
> explicitly, B won't send packet to interface_2 until it is aware of
> the disconnection of current link due to transport layer mechanism.
> The latency could be very large.
>
> Is this means for an interface switching, host A needs to initiate the
> 3-way update process twice? Host A uses the first one to create a new
> SA, and the second one to notify B about interface switching. And if
> so, why can't we let host A initiate only one update process after its
> interface switching to create a new SA and notify the preferred
> address, which just like the normal mobility event? It looks like more
> reasonable, and initiate update process twice is wasteful.

I believe that what you are suggesting would be appropriate in this case.  The current spec is written such that these SAs are made before being put into service, which requires the three-way handshake.  However, I am not sure that the second update (A to tell B to use interface_2's address as a preferred address) would be a three way handshake, since no address verification needs to take place (if there is already an SA set up to that interface).  Instead, it may just be a two-way handshake.

But I agree with you that it may be better in some cases to just have a single three-way handshake when an address needs to be put into service.  It may also be the case that a host's other (non-preferred) addresses can be advertised during the base exchange and not require the separate three-way handshake.

>
> It is no doubt that host B knows several available addresses of host A
> is useful. These addresses can be used for load sharing or
> fault-tolerant. As described above, it seems like current HIP
> multihoming solution fails to handle this flexible. If a
> interface/address switching mechanism is adopted, the switching can be
> more efficient.

We discussed the future of multihoming at the Anaheim meeting.   As you observed, multihoming is somewhat underspecified in RFC 5206.  We agreed to focus the revision of RFC 5206 on mobility, and again leave a more detailed multihoming specification as a second phase work effort.   There was also sentiment expressed that the current suggestion in RFC 5206 to proactively set up all pairs of SAs between all addresses is excessive.

> Does anyone know if there are solutions related to HIP
> multihomed host's interface/address switching except rfc5206?
>
It has been discussed in the past that the shim6 failure detection and locator selection protocol (RFC 5534) could be applied to HIP multihoming use cases.  Also, the shim6 API document relates to HIP multihoming:  http://tools.ietf.org/html/draft-ietf-shim6-multihome-shim-api-13

Also, Mika Kousa and Baris Boyvat's theses discuss multihoming:
http://infrahip.hiit.fi/index.php?index=publications

- Tom