Subject: [Hipsec] HIP host multihoming questions

From: TAO YUAN <[email-masked]>
Date: Tue, 4 May 2010 16:06:10 +0800

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.

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. Does anyone know if there are solutions related to HIP
multihomed host’s interface/address switching except rfc5206?

Thanks~

Albert

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 4 May 2010 20:08:04 -0700

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of TAO YUAN
> Sent: Tuesday, May 04, 2010 1:06 AM
> To: [email-masked]
> Subject: [Hipsec] HIP host multihoming questions
>
> Hi, all
>

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.

> 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

---

From: TAO YUAN <[email-masked]>
Date: Thu, 6 May 2010 15:55:14 +0800

> 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-pr…

A host can send multiple ESP_INFO and multiple LOCATOR parameters
during the base exchange to advertise its non-preferred addresses. But
this would not reduce the numbers of messages largely, since address
verification still needs to take place for each address separately.It
only changes the timing of sending.
I think the primary problem here is not how A tell B about its
available addresses, but how can A and B use these address after the
initialization phase.

> http://infrahip.hiit.fi/index.php?index=publications

Yes, it is really wasteful to set up all pairs of SAs proactively if
they can not be used,such as in interface switching scenario. Add some
features of RFC 5534 in is a good idea~

Thank you for your reply