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

[René Hummen <[e-mail]>]

Hi Gonzalo,

draft-ietf-hip-dex-05 is ready to be sent to the IESG.

BR
René

-----Original Message-----
From: Gonzalo Camarillo [mailto:[e-mail]] 
Sent: Donnerstag, 4. Mai 2017 14:47
To: René Hummen <[e-mail]>
Cc: Tom Henderson <[e-mail]>; HIP <[e-mail]>
Subject: Re: [Hipsec] WGLC: draft-ietf-hip-dex-04

Rene, I am re-sending my email below. Thanks!

Gonzalo

On 27/04/2017 2:14 PM, Gonzalo Camarillo wrote:
> Hi Rene,
> 
> to be clear, you had 3 questions on your email below and you said you 
> needed further input from the group. Do you mean version 05 of the 
> draft is ready to be sent to the IESG (i.e., ready for publication 
> request), or you will revise the draft once more before it is ready?
> 
> Thanks,
> 
> Gonzalo
> 
> 
> On 26/03/2017 7:16 PM, René Hummen wrote:
>> Hi Gonzalo,
>>
>> I did not receive any comments indicating the need to make further 
>> changes. From my side, we are ready to finalize the draft.
>>
>> BR
>> René
>>
>> 2017-03-16 16:25 GMT+01:00 Gonzalo Camarillo 
>> <[e-mail] <mailto:[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]>
>>     > <mailto:[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]>
>>     <mailto:[e-mail] <mailto:[e-mail]>>
>>     >     https://www.ietf.org/mailman/listinfo/hipsec
>>     <https://www.ietf.org/mailman/listinfo/hipsec>
>>     >     <https://www.ietf.org/mailman/listinfo/hipsec
>>     <https://www.ietf.org/mailman/listinfo/hipsec>>
>>     >
>>     >
>>
>>
>