Subject: [Hipsec] questions on hip-mm

From: [email-masked] (Andrei Gurtov)
Date: Mon Aug 9 19:41:53 2004

Hi,

Skimming through the hip-mm-02 draft I was pondering if any mechanism is 
needed to ensure robustness of a reachability check (retransmissions 
with exponential back off as with a TCP keepalive timer?) in case if 
probes get lost due to errors or congestion somewhere. Another question 
is how does HIP select an IP address of a multihomed host to use, is 
there some API that the application can negotiate with HIP on this? And 
in case the transport protocol wants to transmit simultaneously over 
multiple paths, can it be accomplished with the current draft?

Andrei

---

From: [email-masked] (Jari Arkko)
Date: Thu Aug 12 13:43:35 2004

> probes get lost due to errors or congestion somewhere. Another question 

I think this is needed, and seems to be missing from
the draft as it is. I wonder if it also means that the
UNVERIFIED/ACTIVE/DEPRECATED states need to be changed.
But we could also handle the retransmission only in
the text.

> multiple paths, can it be accomplished with the current draft?

I do not think transmission over multiple paths simultaneously
is advisable with current protocols. That would create TCP
effects that we don't know how to deal with yet.

So my belief is that HIP, just like SCTP and MOBIKE, should
at the moment deal with failover rather than load balancing.

This still leaves your original question of how to choose
the address. Here's my take on it:

o The peer can provide some guidance on the address to use.

o There are some local means to figure out if another address
   should be used, a link down notification from one interface,
   for instance. These means should be used where possible.
   There are also non-local means, basically dealing with
   the observation that "it doesn't work". More on this below:

o We actually have a path (address pair) selection problem
   rather than just having to choose the peer's address.

o In the absence of peer's guidance and/or upon a change in
   the situation, the two participants should employ some
   form of path testing or keepalives to figure out if the
   current path or some of its alternatives are actually
   working. Upon finding that the current path does not
   work and that an alternative path does work, the peers
   should switch to the new path.

--Jari

---

From: [email-masked] (Jari Arkko)
Date: Thu Aug 12 13:43:39 2004

--Jari