WGLC: draft-ietf-hip-dex-04

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

WGLC: draft-ietf-hip-dex-04

Gonzalo Camarillo
Folks,

I would like to start a WGLC on the following draft. This WGLC will
end on November 20th:

https://tools.ietf.org/html/draft-ietf-hip-dex-04

Thanks,

Gonzalo

_______________________________________________
Hipsec mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/hipsec
Reply | Threaded
Open this post in threaded view
|

Re: WGLC: draft-ietf-hip-dex-04

Gonzalo Camarillo
All,

please note this WGLC, review the draft, and send your comments to the
list. Thanks!

Cheers,

Gonzalo

On 27/10/2016 9:39 AM, Gonzalo Camarillo wrote:

> Folks,
>
> I would like to start a WGLC on the following draft. This WGLC will
> end on November 20th:
>
> https://tools.ietf.org/html/draft-ietf-hip-dex-04
>
> Thanks,
>
> Gonzalo
>

_______________________________________________
Hipsec mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/hipsec
Reply | Threaded
Open this post in threaded view
|

Re: WGLC: draft-ietf-hip-dex-04

Tom Henderson-2
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
[hidden email]
https://www.ietf.org/mailman/listinfo/hipsec
Reply | Threaded
Open this post in threaded view
|

Re: WGLC: draft-ietf-hip-dex-04

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

_______________________________________________
Hipsec mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/hipsec
Reply | Threaded
Open this post in threaded view
|

Re: WGLC: draft-ietf-hip-dex-04

Robert Moskowitz
I will start on it Tuesday.

Bob

On 11/20/2016 03:26 AM, Gonzalo Camarillo wrote:

> 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 ..."
>>
> _______________________________________________
> Hipsec mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/hipsec
>

_______________________________________________
Hipsec mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/hipsec
Reply | Threaded
Open this post in threaded view
|

Re: WGLC: draft-ietf-hip-dex-04

Robert Moskowitz
In reply to this post by Tom Henderson-2
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
> [hidden email]
> https://www.ietf.org/mailman/listinfo/hipsec
>

_______________________________________________
Hipsec mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/hipsec
Reply | Threaded
Open this post in threaded view
|

Re: WGLC: draft-ietf-hip-dex-04

Gonzalo Camarillo
In reply to this post by Robert Moskowitz
Bob, Rene

when do you think you will get around to revising the draft, per our
emails below? Thanks!

Cheers,

Gonzalo

On 22/11/2016 7:34 AM, Robert Moskowitz wrote:

> I will start on it Tuesday.
>
> Bob
>
> On 11/20/2016 03:26 AM, Gonzalo Camarillo wrote:
>> 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 ..."
>>>
>> _______________________________________________
>> Hipsec mailing list
>> [hidden email]
>> https://www.ietf.org/mailman/listinfo/hipsec
>>
>

_______________________________________________
Hipsec mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/hipsec
Reply | Threaded
Open this post in threaded view
|

Re: WGLC: draft-ietf-hip-dex-04

René Hummen-2
In reply to this post by Tom Henderson-2
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 <[hidden email]>:
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
[hidden email]
https://www.ietf.org/mailman/listinfo/hipsec


_______________________________________________
Hipsec mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/hipsec
Reply | Threaded
Open this post in threaded view
|

Re: WGLC: draft-ietf-hip-dex-04

Gonzalo Camarillo
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 <[hidden email]
> <mailto:[hidden email]>>:
>
>     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
>     [hidden email] <mailto:[hidden email]>
>     https://www.ietf.org/mailman/listinfo/hipsec
>     <https://www.ietf.org/mailman/listinfo/hipsec>
>
>

_______________________________________________
Hipsec mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/hipsec
Reply | Threaded
Open this post in threaded view
|

Re: WGLC: draft-ietf-hip-dex-04

René Hummen-2
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 <[hidden email]>:
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 <[hidden email]
> <mailto:[hidden email]>>:
>
>     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
>     [hidden email] <mailto:[hidden email]>
>     https://www.ietf.org/mailman/listinfo/hipsec
>     <https://www.ietf.org/mailman/listinfo/hipsec>
>
>


_______________________________________________
Hipsec mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/hipsec
Reply | Threaded
Open this post in threaded view
|

Re: WGLC: draft-ietf-hip-dex-04

Gonzalo Camarillo
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
> <[hidden email] <mailto:[hidden email]>>:
>
>     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 <[hidden email]
>     <mailto:[hidden email]>
>     > <mailto:[hidden email] <mailto:[hidden email]>>>:
>     >
>     >     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
>     >     [hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email] <mailto:[hidden email]>>
>     >     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>>
>     >
>     >
>
>

_______________________________________________
Hipsec mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/hipsec
Reply | Threaded
Open this post in threaded view
|

Re: WGLC: draft-ietf-hip-dex-04

Gonzalo Camarillo
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
>> <[hidden email] <mailto:[hidden email]>>:
>>
>>     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 <[hidden email]
>>     <mailto:[hidden email]>
>>     > <mailto:[hidden email] <mailto:[hidden email]>>>:
>>     >
>>     >     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
>>     >     [hidden email] <mailto:[hidden email]>
>>     <mailto:[hidden email] <mailto:[hidden email]>>
>>     >     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>>
>>     >
>>     >
>>
>>
>

_______________________________________________
Hipsec mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/hipsec
Reply | Threaded
Open this post in threaded view
|

Re: WGLC: draft-ietf-hip-dex-04

René Hummen-2
Hi Gonzalo,

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

BR
René

-----Original Message-----
From: Gonzalo Camarillo [mailto:[hidden email]]
Sent: Donnerstag, 4. Mai 2017 14:47
To: René Hummen <[hidden email]>
Cc: Tom Henderson <[hidden email]>; HIP <[hidden email]>
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
>> <[hidden email] <mailto:[hidden email]>>:
>>
>>     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 <[hidden email]
>>     <mailto:[hidden email]>
>>     > <mailto:[hidden email] <mailto:[hidden email]>>>:
>>     >
>>     >     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
>>     >     [hidden email] <mailto:[hidden email]>
>>     <mailto:[hidden email] <mailto:[hidden email]>>
>>     >     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>>
>>     >
>>     >
>>
>>
>

_______________________________________________
Hipsec mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/hipsec