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

[Gonzalo Camarillo <[e-mail]>]

Hi Rene,

did you get answers to your questions below and, in general, enough
input to finalize the draft?

Thanks,

Gonzalo

On 05/02/2017 11:59 PM, René Hummen wrote:
> Hi Tom,
> 
> thanks for your review!
> 
> I have addressed most of your comments in the new revision 05 that I
> just uploaded before. For your remaining comments, I need additional
> input from you and the rest of this group:
> 
> 1) The text from Section 6.3 that you refer to is the same as in RFC5201
> (HIPv1). I agree with you on the endianess. However, I assume that there
> was a good reason why the sort() was specified this way in the original
> HIP version. I would therefore prefer to keep the text as is.
> Concerning the 96 vs. 128 bit issue, the draft defines HITs the same way
> as HIPv2, which from my understanding are the full 128bit.
> 
> 2) Concerning Sec. 6.5 through 6.8, I consciously chose to provide the
> full specification here in order to significantly increase the
> readability of these sections. When only stating the differences, I
> found myself constantly changing between two documents (RFC7401 for the
> content and the DEX draft to see if the content was relevant, removed,
> or modified). To support those interested in the changes between RFC7401
> and the DEX draft, I specifically call out the main differences at the
> end of each section. Does this satisfy your comment?
> 
> 3) If your suggestion for Section 10 is purely cosmetic in nature, I
> would prefer to not put additional effort into the IANA section. So, are
> these changes cosmetic or mandatory?
> 
> BR
> René
> 
> 2016-11-20 3:32 GMT+01:00 Tom Henderson <[e-mail]
> <mailto:[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 <http://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
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/hipsec
>     <https://www.ietf.org/mailman/listinfo/hipsec>
> 
>