Subject: Re: [Hipsec] WGLC: draft-ietf-hip-dex-04

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 2 Nov 2016 16:07:28 +0200

All,

please note this WGLC, review the draft, and send your comments to the
list. Thanks!

Cheers,

Gonzalo

On 27/10/2016 9:39 AM, Gonzalo Camarillo wrote:
> Folks,
> 
> I would like to start a WGLC on the following draft. This WGLC will
> end on November 20th:
> 
> https://tools.ietf.org/html/draft-ietf-hip-dex-04
> 
> Thanks,
> 
> Gonzalo
>

---

From: Tom Henderson <[email-masked]>
Date: Sat, 19 Nov 2016 18:32:58 -0800 (PST)

Gonzalo, I have reviewed HIP DEX again and believe it is ready to publish, although I spotted a few minor items below that can be handled in the next revision.

- Tom

Editorial/minor:

Section 1:  The numbered list is somewhat tersely written and may be hard to interpret by the newcomer to HIP specifications.  Consider to elaborate more (using fuller sentences and not sentence fragments).  e.g.:

"Forfeit of Perfect Forward Secrecy with the dropping of an ephemeral Diffie-Hellman key agreement." could be
"Forfeit of the HIPv2 Perfect Forward Secrecy property due to the removal of the HIPv2 ephemeral Diffie-Hellman key agreement."

Section 1.1, spell out 'DoS' first time usage

Section 4.1:  "Note that x and y each constitute half the final session key material."  (change to 'half of the')

The figure in 4.1 does not have a caption, and also, why is 'mac' lowercased?

Sec 4.1.3.1:  "Since only little data is protected by this SA" (perhaps s/little/a small amount/)

Sec. 5.2.4:  "The following new HIT Suite IDs are defined..." (s/IDs are/ID is/ because there is only one defined)

Sec. 6.3:  "sort(HIT-I | HIT-R) is defined as the network byte order concatenation of the two HITs... comparison of the two HITs interpreted as positive (unsigned) 128-bit integers in network byte order"  what does it mean to define a sort on a network byte order concatenation?  It seems perhaps clearer to leave endian issues out (they are implicit everywhere in a protocol) and just define it as a comparison on HITs interpreted as unsigned 128-bit integers (and by the way, is the full 128 bits including prefix included or just the 96 bits)?

Sec. 6.5 through 6.8:  Unlike much of this draft, these sections do not just specifically call out the differences from the corresponding RFC 7401 sections, but instead restate the modified processing flow, and it is hard to spot what is different here.  I wonder whether it would be clearer to just refer to those processing steps in RFC 7401 that are changed.

Sec. 8:  Can a MITM reply to I1 with ICMP parameter problem, causing the true response (coming later) to be ignored because the initiator already gave up?  Maybe clarify here or in sec 5.4 to wait a little while before accepting the result of an ICMP.

Sec. 10:  Consider to update the IANA section in the style that RFC 8003 (and others) used, stating the history of the registry and what exactly is requested to be changed.  For example, something like "RFC 5201 and later RFC 7401 established the following registry ....  This document defines the following new codepoints for that registry ..."

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 20 Nov 2016 10:26:36 +0200

Hi Tom,

thanks. Your comments seem to be the only one we got on this draft
during the WGLC. Authors, could you please revise the draft in order to
address these comments?

Thanks,

Gonzalo

On 20/11/2016 4:32 AM, Tom Henderson wrote:
> Gonzalo, I have reviewed HIP DEX again and believe it is ready to
> publish, although I spotted a few minor items below that can be handled
> in the next revision.
> 
> - Tom
> 
> Editorial/minor:
> 
> Section 1:  The numbered list is somewhat tersely written and may be
> hard to interpret by the newcomer to HIP specifications.  Consider to
> elaborate more (using fuller sentences and not sentence fragments).  e.g.:
> 
> "Forfeit of the HIPv2 Perfect Forward Secrecy property due to the
> removal of the HIPv2 ephemeral Diffie-Hellman key agreement."
> 
> Sec. 5.2.4:  "The following new HIT Suite IDs are defined..." (s/IDs
> are/ID is/ because there is only one defined)
> 
> Sec. 6.3:  "sort(HIT-I | HIT-R) is defined as the network byte order
> concatenation of the two HITs... comparison of the two HITs interpreted
> as positive (unsigned) 128-bit integers in network byte order"  what
> does it mean to define a sort on a network byte order concatenation?  It
> seems perhaps clearer to leave endian issues out (they are implicit
> everywhere in a protocol) and just define it as a comparison on HITs
> interpreted as unsigned 128-bit integers (and by the way, is the full
> 128 bits including prefix included or just the 96 bits)?
> 
> Sec. 6.5 through 6.8:  Unlike much of this draft, these sections do not
> just specifically call out the differences from the corresponding RFC
> 7401 sections, but instead restate the modified processing flow, and it
> is hard to spot what is different here.  I wonder whether it would be
> clearer to just refer to those processing steps in RFC 7401 that are
> changed.
> 
> Sec. 8:  Can a MITM reply to I1 with ICMP parameter problem, causing the
> true response (coming later) to be ignored because the initiator already
> gave up?  Maybe clarify here or in sec 5.4 to wait a little while before
> accepting the result of an ICMP.
> 
> Sec. 10:  Consider to update the IANA section in the style that RFC 8003
> (and others) used, stating the history of the registry and what exactly
> is requested to be changed.  For example, something like "RFC 5201 and
> later RFC 7401 established the following registry ....  This document
> defines the following new codepoints for that registry ..."
>

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 22 Nov 2016 00:34:07 -0500

I will start on it Tuesday.

Bob

On 11/20/2016 03:26 AM, Gonzalo Camarillo wrote:
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec
>

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 22 Nov 2016 00:34:41 -0500

Oh,

And Tom, thanks for the solid review.

Bob

On 11/19/2016 09:32 PM, Tom Henderson wrote:
> publish, although I spotted a few minor items below that can be 
> handled in the next revision.
>
> - Tom
>
> Editorial/minor:
>
> Section 4.1:  "Note that x and y each constitute half the final 
> session key material."  (change to 'half of the')
>
> concatenation of the two HITs... comparison of the two HITs 
> interpreted as positive (unsigned) 128-bit integers in network byte 
> order"  what does it mean to define a sort on a network byte order 
> concatenation?  It seems perhaps clearer to leave endian issues out 
> (they are implicit everywhere in a protocol) and just define it as a 
> comparison on HITs interpreted as unsigned 128-bit integers (and by 
> the way, is the full 128 bits including prefix included or just the 96 
> bits)?
>
> Sec. 6.5 through 6.8:  Unlike much of this draft, these sections do 
> not just specifically call out the differences from the corresponding 
> RFC 7401 sections, but instead restate the modified processing flow, 
> and it is hard to spot what is different here.  I wonder whether it 
> would be clearer to just refer to those processing steps in RFC 7401 
> that are changed.
>
> Sec. 8:  Can a MITM reply to I1 with ICMP parameter problem, causing 
> the true response (coming later) to be ignored because the initiator 
> already gave up?  Maybe clarify here or in sec 5.4 to wait a little 
> while before accepting the result of an ICMP.
>
> Sec. 10:  Consider to update the IANA section in the style that RFC 
> 8003 (and others) used, stating the history of the registry and what 
> exactly is requested to be changed.  For example, something like "RFC 
> 5201 and later RFC 7401 established the following registry ....  This 
> document defines the following new codepoints for that registry ..."
>