Subject: [Hipsec] RFC5206-bis and next steps

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 6 Jan 2010 07:11:51 -0800

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.

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.

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?

- Tom

---

From: Christian Vogt <[email-masked]>
Date: Wed, 6 Jan 2010 12:51:37 -0500

Tom -

I agree that NAT traversal support as well as support for handovers  
across address families would be useful to add to the document.  I  
don't see either of this as new functionality, but rather as a  
robustness improvement.

In regards of your suggestion to move use cases into a separate  
document:  Why not?  It makes sense in particular because the use case  
description is quite comprehensive.

- Christian

On Jan 6, 2010, at 7:11, Henderson, Thomas R wrote:

> 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.
> 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
> 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.
>
> 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.
>
> 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.
>

---

From: Miika Komu <[email-masked]>
Date: Thu, 07 Jan 2010 08:22:49 +0200

Henderson, Thomas R wrote:

Hi,

> 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. 
> 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

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.

> 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
> 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.
> 

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.