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

[Tom Henderson <[e-mail]>]

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