Oh,
And Tom, thanks for the solid review.
Bob
On 11/19/2016 09:32 PM, 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 ..."
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
