Re: [Hipsec] RFC5206-bis (mobility) status

[Miika Komu <[e-mail]>]

Hi,

Gonzalo asked to bring remaining issues to the list, so let's revive the 
discussion around the mobility extensions.

On 01/12/2015 08:33 PM, Tom Henderson wrote:
> I just published version 8 of RFC5206-bis (mobility), and version 5 of
> the multihoming draft.  These updates make the changes that were
> discussed on the list in December; in summary, the updates were mainly
> about moving additional material related to multihoming from the
> RFC5206-bis draft to the multihoming draft.
>
> The next update I plan to make is to add a description of how UPDATEs
> may be forwarded through rendezvous servers, to handle the double jump
> mobility scenario.  There isn't any discussion about what to do when
> UPDATEs are not acknowledged, so I propose to suggest that, upon failure
> of obtaining an ACK to an UPDATE from a peer, the host should try any
> other addresses that it knows about, and if those also fail, try to send
> the UPDATE to the peer's rendezvous server (if known).
>
> There were 13 open issues in the tracker against RFC5206-bis, but upon
> review, many of them are multihoming questions, so I reassigned several
> of them to the multihoming draft.  Here are the issues against
> RFC5206-bis that I see remaining.
>
> Issue 8:  decouple locator announcement from SA creation
> http://trac.tools.ietf.org/wg/hip/trac/ticket/8

"Need to make sure that revised specifications handle the use case of 
decoupling locator announcements from SA creation (as well as the case 
of integrating them)"

how?

> Issue 9:  some implementations lack some of the compulsory UPDATE
> features, so maybe they should not be mandatory
> http://trac.tools.ietf.org/wg/hip/trac/ticket/9

"Note from Baris Boyvat that some mandatory UPDATE features in RFC5206 
are not supported by implementations, so perhaps they should not be 
mandatory."

hmm, what was this about?

> Issue 12:  sending UPDATE via rendezvous server (discussed above)
> http://trac.tools.ietf.org/wg/hip/trac/ticket/12

"Note: This tracker issue depends on Issue 1 that Julien filed for RFC 
5204. At least one implementation supports this feature."

this should fixed for double jump. And we should decide which document 
(mobility vs. rendezvous) to use describing mobility extensions.

> Issue 15:  suggestion for naming UPDATE packets
> http://trac.tools.ietf.org/wg/hip/trac/ticket/15

"From Baris Boyvat: "There is always three UPDATE packet sent for a 
mobility event. In HIPL this fact was not explicitly used in the 
implementation before, which made the implementation quite complex. I 
would suggest to explicitly quality the UPDATE packets numbers, etc. 
UPDATE1, UPDATE2, UPDATE3 which would in a way force people to think in 
that terms.
Otherwise, when dealing with different UPDATE scenarios, SEQ, ACK 
handling, retransmissions,etc conceptualization become very difficult. 
Actually if possible, I would suggest to nicely separate these concepts 
so that they can be easily modularized in an implementation. I'm not 
sure, it's common for RFCs but this can be done in a "implementation 
recommendation" form."

At least the packet renaming could be done easily.

Related to this, I have also privately suggested Thomas to describe a 
simple state machine for mobility management. I have described the state 
machine a long time ago:

http://www.ietf.org/mail-archive/web/hipsec/current/msg01745.html

This could be also omitted if the authors do not have enough time, or 
included as an implementation note in the appendix.

My biggest concern is that how can we make further UPDATE extensions 
possible (i.e. how to signal that that a host does not support a  new 
extension X), while making the UPDATE procedure a bit more specific?

> Issue 21:  UPDATE signature and HI inclusion
> http://trac.tools.ietf.org/wg/hip/trac/ticket/21

I think we should definitely fix this issue. This is important 
especially with HIP-based firewalls and mobile hosts. And it is rather 
easy to fix.

> Issue 23: Allow Locator fields to have flow bindings
> http://trac.tools.ietf.org/wg/hip/trac/ticket/23

"draft-cao-hiprg-flow-mobility-00 proposes to use RFC6089 flow bindings 
fields with HIP. Although the draft proposes a new locator type, we 
should consider to just extend the base LOCATOR to allow this."

This should affect mainly the multihoming specification, right?