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

[Gonzalo Camarillo <[e-mail]>]

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