Re: [Hipsec] RFC5206-bis and next steps

[Miika Komu <[e-mail]>]

Henderson, Thomas R wrote:

Hi,

> Similar to what was started for RFC 4423 and 5201, I posted a new
> version of RFC 5206 as draft-henderson-hip-rfc5206-bis-00.  Presently
> it is the same as RFC 5206.  I intend to use the trac issue tracker
> once I can access it. 
> http://tools.ietf.org/id/draft-henderson-hip-rfc5206-bis-00.txt
> 
> Since RFC5206 was written, we've had a number of developments:
> 
> 1) NAT traversal draft (soon to be RFC): 
> http://tools.ietf.org/html/draft-ietf-hip-nat-traversal-09
> 
> 2) mobility management aspects of NAT traversal: 
> http://tools.ietf.org/html/draft-melen-hip-nat-mm-00
> 
> 3) There has been work from a couple of implementation teams on
> cross-family handovers (which were largely out of scope of RFC 5206;
> briefly mentioned in Section 3.2.7)
> 
> 4) shim6 has published RFC 5334 that does failure detection and
> locator pair exploration for shim6 contexts, but also has
> applicability to HIP.
> 
> 5) Mobile router draft 
> http://tools.ietf.org/html/draft-melen-hip-mr-02
> 
> My first question is how to scope the RFC5206 revision to take into
> account this additional work.  On one hand, Gonzalo has previously
> requested that, while we can rewrite/reorganize the RFC to improve
> clarity, we should avoid adding functionality.  On the other, it
> seems to me to be hard to ignore this additional progress when
> revising RFC5206bis, because I think we would like to avoid asking
> the future implementor to guess how one set of mechanisms (for
> traditional mobility management) interact with another (when NAT
> traversal is in use).
> 
> My recommendation would be to make RFC5206bis be NAT-aware and
> cross-family capable, but leave out the mobile router work (keep the
> scope to be end-to-end mechanisms).  I think we should somehow
> reconcile the similar but slightly different approaches to
> determining working locator pairs that can be found in RFC5206, ICE,
> and RFC5534.

I would suggest including crossfamily work and double jump descriptions,
and perhaps the SHIM6 work because those have been verified by 
implementation work and/or sold specifications.

On the other hand, we don't have stable specs or even implementation 
work on ICE-based mobility. Also, the mobility signaling will be quite 
different because it includes the ICE protocol.

> My second question is about use cases and document organization.  Use
> cases are very important to document so that people understand how
> these mechanisms work, but there are quite a few possibilities
> (permutations) such as whether rekeying is simultaneously occurring
> or not, in what order the events occur, whether NAT traversal occurs
> or not (moving into and from a NATted environment), how mobility
> events are detected or triggered, etc.  If we keep all of the use
> cases together with the normative material in the document, the
> document may get quite large.

This is not a strong opinion, but I would suggest leaving ICE-based NAT 
traversal out and continuing it's parallel development as a separate draft.

On the other hand, this is a rather strong opinion :) If we include 
ICE-based mobility in the RFC5206, we should include it also in the RFC5201.

I have also some other comments on the ICE work that affect this, but 
I'll start a separate thread on this.

> Another option to having a single document is to keep RFC5206bis
> focused on normative material that is necessary to interoperate (e.g.
> messages, required elements of procedure) and keep in parallel a
> second informative "use cases" document that can also discuss how
> platform-specific or implementation-specific policies impact the
> operation of the protocol.  If we went down this path, we could take
> Section 3 from RFC5206 as well as the use cases in
> draft-melen-hip-nat-mm-00 and put them in a new hip-mm-use-cases
> document.  If this approach were to work out, it would mean that the
> WG would prepare two documents to replace RFC5206, one normative and
> one informative.  I would be inclined to at least try this approach.
> 
> Any comments or feedback on these choices?

Seems ok to me but how do you think this split is this going to improve 
the readability of the specification? Currently the learning curve is 
pretty steep.