Subject: [Hipsec] issue resolution on RFC5201-bis

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 1 Jan 2013 23:23:50 -0800

I'd like to try to wrap up the open issues on RFC5201-bis.  There are four issues remaining in the tracker:

1) ticket 25:  Orchid Generation Algorithm (http://trac.tools.ietf.org/wg/hip/trac/ticket/25)

This issue was open to flag the need to revise RFC4843-bis.  I believe that this has been done and the documents are now consistent (although the 5201-bis draft should point to the -03 version of the 4843-bis draft).  I propose to close this with no further changes other than a reference refresh, if there are no objections.

2) ticket 39:  Improve text relating to R1 counter rollover  (http://trac.tools.ietf.org/wg/hip/trac/ticket/39)

I'd like to propose the following text change:

OLD TEXT (sec 4.1.4):

The R1 counter SHOULD NOT roll over.

NEW TEXT:

The R1 generation counter may roll over or may become reset.   It is important for an Initiator to be robust to the loss of state about the R1 generation counter of a peer, or to a reset of the peer's counter.  It is recommended that, when choosing between multiple R1s, the Initiatior prefer to use the R1 that is most consistent with the R1 generation counter, but that if it is unable to make progress with that R1, the Initiator may try the other R1s.

3) ticket 40:  decreasing the per-packet overhead (http://trac.tools.ietf.org/wg/hip/trac/ticket/40)

Rene has suggested changes to the PUZZLE, SOLUTION, and R1_COUNTER encoding, to make them more bit-efficient.  The proposals seem reasonable to me but there hasn't been much list discussion.  Should we proceed with these changes?  (suggested in this email:  http://www.ietf.org/mail-archive/web/hipsec/current/msg03608.html)

4) ticket 41:  LSI prefix range (http://trac.tools.ietf.org/wg/hip/trac/ticket/41)

As I mentioned last month, it seems that the use of special IPv4 addresses (loopback prefix or class E prefix) may cause problems on some operating systems.  

However, I just scanned the draft and couldn't find any place where we are mentioning LSIs.  It may be out of scope for 5201-bis.  I propose to close this with no changes, perhaps just updating the tracker issue with the results of the implementation survey.  If there is a future need to specify LSI ranges, it may be that RFC 1918 blocks or other address blocks known to be unused in a HIP environment could be recommended as LSIs.

We also have the open issue of IANA allocation of an Orchid prefix, but that is a 4843-bis issue.

- Tom

---

From: "Dr. Tobias Heer" <[email-masked]>
Date: Tue, 08 Jan 2013 23:11:46 +0100

Hello Tom,

I'm sorry for the late reply. See my comments below.

> This issue was open to flag the need to revise RFC4843-bis.  I believe that this has been done and the documents are now consistent (although the 5201-bis draft should point to the -03 version of t…

I agree.
> The R1 generation counter may roll over or may become reset.   It is important for an Initiator to be robust to the loss of state about the R1 generation counter of a peer, or to a reset of the pee…
I think "most consistent" is ambiguous. I would rather say "with the
least numerical distance" or "closest to" or even "identical to" because
the last sentence already deals with the case that an identical counter
is not available. The last sentence could be extended by: "may try other
R1s with lower R1 counters beginning with the R1 packet with the highest
counter".

> Rene has suggested changes to the PUZZLE, SOLUTION, and R1_COUNTER encoding, to make them more bit-efficient.  The proposals seem reasonable to me but there hasn't been much list discussion.  Shoul…

I think the proposals are valuable but I think the benefit of the
changes would not justify the effort of implemeting these (at this late
state). I would opt for leaving the protocol as it is now.

> However, I just scanned the draft and couldn't find any place where we are mentioning LSIs.  It may be out of scope for 5201-bis.  I propose to close this with no changes, perhaps just updating the…
I agree that this can be handled later if the need arises.

Thanks for your work.

Tobias

> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 16 Jan 2013 10:12:44 -0800

Tobias, inline below...
> > 1) ticket 25:  Orchid Generation Algorithm
> > (http://trac.tools.ietf.org/wg/hip/trac/ticket/25)
> >
> > This issue was open to flag the need to revise RFC4843-bis.  I
> believe that this has been done and the documents are now consistent
> (although the 5201-bis draft should point to the -03 version of the
> 4843-bis draft).  I propose to close this with no further changes other
> than a reference refresh, if there are no objections.
> 
> I agree.

I closed this accordingly, as there were no other comments.

> >
> > 2) ticket 39:  Improve text relating to R1 counter rollover
> > (http://trac.tools.ietf.org/wg/hip/trac/ticket/39)
> >
> > The R1 generation counter may roll over or may become reset.   It is
> important for an Initiator to be robust to the loss of state about the
> R1 generation counter of a peer, or to a reset of the peer's counter.
> It is recommended that, when choosing between multiple R1s, the
> Initiatior prefer to use the R1 that is most consistent with the R1
> generation counter, but that if it is unable to make progress with that
> R1, the Initiator may try the other R1s.

> least numerical distance" or "closest to" or even "identical to"
> because the last sentence already deals with the case that an identical
> counter is not available. The last sentence could be extended by: "may
> try other R1s with lower R1 counters beginning with the R1 packet with
> the highest counter".

New text proposal, based on your input:

The R1 generation counter may roll over or may become reset.   It is
important for an Initiator to be robust to the loss of state about the
R1 generation counter of a peer, or to a reset of the peer's counter.
It is recommended that, when choosing between multiple R1s, the
Initiatior prefer to use the R1 that corresponds to the current R1
generation counter, but that if it is unable to make progress with that
R1, the Initiator may try the other R1s beginning with the R1 packet
with the highest counter.

> 
> >
> > 3) ticket 40:  decreasing the per-packet overhead
> > (http://trac.tools.ietf.org/wg/hip/trac/ticket/40)
> >
> > Rene has suggested changes to the PUZZLE, SOLUTION, and R1_COUNTER
> > encoding, to make them more bit-efficient.  The proposals seem
> > reasonable to me but there hasn't been much list discussion.  Should
> > we proceed with these changes?  (suggested in this email:
> > http://www.ietf.org/mail-archive/web/hipsec/current/msg03608.html)
> 

Since there were no other comments, I believe that we can stay with
the status quo and leave these enhancements for future work.

> 
> >
> > 4) ticket 41:  LSI prefix range
> > (http://trac.tools.ietf.org/wg/hip/trac/ticket/41)
> >
> > As I mentioned last month, it seems that the use of special IPv4
> addresses (loopback prefix or class E prefix) may cause problems on
> some operating systems.
> >
> > However, I just scanned the draft and couldn't find any place where
> we are mentioning LSIs.  It may be out of scope for 5201-bis.  I
> propose to close this with no changes, perhaps just updating the
> tracker issue with the results of the implementation survey.  If there
> is a future need to specify LSI ranges, it may be that RFC 1918 blocks
> or other address blocks known to be unused in a HIP environment could
> be recommended as LSIs.

I just closed this issue and left some documentation in the tracker.

We have two open issues above but I think they can be closed as suggested above; I'll close them on Friday if there are no other comments by then.

- Tom