Re: [IPsec] Working group last call for the draft-nir-ipsecme-eddsa-00

[David Schinazi]

Based on these arguments, I agree that a new value (5) is preferable to 0.

David


> On Feb 9, 2017, at 08:57, Paul Wouters  wrote:
> 
> Yes I forgot to reply. I strongly object to assigning 0 for real values. It 
> should be left for implementations to detect a value has not been set.
> 
> Paul
> 
> Sent from my iPhone
> 
>> On Feb 9, 2017, at 11:12, Tommy Pauly  wrote:
>> 
>> Thanks for sending out the corrected draft name, Tero. I think this draft is 
>> in good shape in general and we should move forward with it.
>> 
>> The only thing that seems to need ironing out is the specific IANA hash 
>> value. I can see the argument either way: as the draft points out, 0 makes 
>> sense for the Identity hash, since it can be viewed as "no hash at all". 
>> However, I agree with your point that 0 may often be used in code to 
>> indicate an uninitialized value. I would be concerned if existing 
>> implementations flagged 0 as an error, here, as well.
>> 
>> I think it would make sense to do a quick poll of the WG to get some 
>> consensus on this. At this point, I'm mildly in favor of a new value (5).
>> 
>> Thanks,
>> Tommy
>> 
>>> On Feb 9, 2017, at 4:40 AM, Tero Kivinen  wrote:
>>> 
>>> Ah I noticed that my last call email had wrong draft name in the
>>> subject line and in the link. The correct draft name is of course
>>> draft-ietf-ipsecme-eddsa-00 not *-nir-* version.
>>> 
>>> David Schinazi writes:
 I've reviewed this draft. I support it and believe it is ready to move 
 forward
 towards becoming a standards-track RFC. Also, would it make sense to ask
 IANA for early assignment of the code point? Using 0 sounds reasonable to 
 me.
>>> 
>>> As this is expert review registry there is no need to ask for early
>>> allocation, the normal process is just to fill in the IANA general
>>> request for assignments, which then goes to the IANA and they will
>>> then send it to the expert (me) for verification.
>>> 
>>> If normal number (other than 0) would be given out, then I would just
>>> say yes, but allocating 0, which in registry is marked as:
>>> 
>>>   0Reserved[RFC7427]
>>> 
>>> and is not part of the :
>>> 
>>>   5-1023Unassigned
>>> 
>>> range, then I would be bit more hesitant to give it out, and would
>>> most likely want to poll the WG and list before making decision.
>>> 
>>> I actually myself think it would be better to just allocate next free
>>> number from the unassigned space, and keep the value 0 as reserved...
>>> 
>>> For example we do not use value 0 of Encryption Algorithms transform
>>> to mean ENCR_NULL, we do have separate number allocated for it. On the
>>> other hand we do have value 0 meaning NONE in the Integrity algorithm
>>> transform ID table and for diffie hellman values, but there the
>>> meaning is bit different, it means there is no value for that id, here
>>> it would be meaning that there is this identity function version of
>>> the hash function. 
>>> 
>>> As an expert and as a implementor I think I would prefer next free
>>> number over 0... Quite commonly in the code we use value 0 as meaning,
>>> we have not yet received anything, or we have not yet initialized this
>>> field, and having separate value for identity function might make
>>> things easier. But if others have good reasons why the value 0 is
>>> better, feel free to tell me...
>>> -- 
>>> kivi...@iki.fi
>>> 
>>> ___
>>> IPsec mailing list
>>> IPsec@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ipsec
>> 
>> ___
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
> 

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Review of draft-ietf-ipsecme-tcp-encaps-05

[Tommy Pauly]

Hello,

I've posted a new draft with a fix for the TCP Originator vs Original Initiator 
explanation, and a couple typos.

https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-07

I believe this addresses all outstanding comments!

Thanks,
Tommy

> On Feb 7, 2017, at 9:44 AM, Tommy Pauly  wrote:
> 
> Hi Valery,
> 
> Thanks for the feedback! I'll clarify that the TCP Originator is the same as 
> the original initiator of the first IKE SA, as well as fixing the 
> typographical errors.
> 
> If anyone else has more feedback, please chime in! I'll wait a day or so 
> before updating the draft, to batch any other changes that should be made.
> 
> Thanks,
> Tommy
> 
>> On Feb 7, 2017, at 5:54 AM, Valery Smyslov  wrote:
>> 
>> Hi Tommy,
>> 
>> thank you for the quick update. A couple nits:
>> 
>> 1. Section 1.2:
>> s/the the/the
>> 
>> 2. Section 1.2:
>>  The TCP  
>>  Originator MUST be the same as the "Original Initiator", or the  
>>  Initiator of the first IKE SA exchange for a given IKE session.
>> 
>> Again, this is confusing. In RFC7296 the term " Original Initiator" is 
>> defined as:
>>   The "original initiator
>>always refers to the party who initiated the exchange that resulted
>>in the current IKE SA.  In other words, if the "original responder"
>>starts rekeying the IKE SA, that party becomes the "original
>>initiator" of the new IKE SA."
>> 
>> "the Initiator of the first IKE SA exchange for a given IKE session" is also
>> wrong, since IKE session means IKE SA and it can be a rekey of previous
>> IKE SA when entities swap their original roles.
>> 
>> This is now what we want it to mean, so an additional clarification is 
>> needed.
>> Something along the lines:
>> 
>>   The TCP Originator MUST be the same as the entity who originally
>>   initiated the first IKE SA (in a series of possibly several rekeyed
>>   IKE SAs).
>> 
>> Otherwise it looks good.
>> 
>> Regards,
>> Valery.
>> 
>>> Hi Valery,
>>> 
>>> Thanks so much for your comments! I have posted a new version of the draft 
>>> here:
>>> https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-06
>>> 
>>> Responses inline.
>>> 
>>> Best,
>>> Tommy
>>> 
 On Feb 2, 2017, at 4:13 AM, Valery Smyslov  wrote:
 
 Hi,
 
 here is my review of draft-ietf-ipsecme-tcp-encaps-05.
 The draft is in a good shape, but a bit of final polishing is required.
 
 1. The terms "tunnel", "tunneled" are used throughout the document
  when referring to ESP SA. I think it is technically incorrect, since
  ESP supports both tunnel and transport modes, so the document
  should use more appropriate terms like "IPsec SA", "ESP packets" etc.
>>> 
>>> Great point. I have removed the references to tunnel, and replaced with SA, 
>>> generally.
>>> 
 
 2. Section 4.
  This value is
 only sent once, by the Initiator only, at the beginning of any stream
 of IKE and ESP messages.
 
 If other framing protocols are used within TCP to further encapsulate
 or encrypt the stream of IKE and ESP messages, the Stream Prefix must
 be at the start of the Initiator's IKE and ESP message stream within
 the added protocol layer [Appendix A].
 
 Using "Initiator" is wrong here, since the TCP stream may be re-established
 after the peers rekeyed IKE SA and changed their roles (so that original
 Initiator becomes Responder). It either must be "original Initiator"
 (with all explanations who it is, as in Section 6) or, preferably,
 "originator of TCP stream" (or smth like that).
 
 Actually, "Initiator" is used in a lot of places throughout the document
 and in most cases it means "original Initiator of the first IKE SA in a 
 series
 of possible successive rekeys of this SA". It is good to look through
 all these uses and either clarify this term in all places it is used, or 
 add
 some para in the beginning of the draft, e.g. like it is done in RFC4555:
 
 In this document, the term "initiator" means the party who originally
 initiated the first IKE_SA (in a series of possibly several rekeyed
 IKE_SAs); "responder" is the other peer.  During the lifetime of the
 IKE_SA, both parties may initiate INFORMATIONAL or CREATE_CHILD_SA
 exchanges; in this case, the terms "exchange initiator" and "exchange
 responder" are used.  The term "original initiator" (which in [IKEv2]
 refers to the party who started the latest IKE_SA rekeying) is not
 used in this document.
 
 I also noticed that both "Initiator" and "initiator" are used in the 
 document
 (as well as "Responder" and "responder"). It's better to use one form
 (preferably with capital letter, like in RFC7296). RFC Editor will change
 them to one form in any case, so you can ease her work a bit.
>>> 
>>> I've switched to use the capitalized version of Initiator 

[IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-07.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Maintenance and Extensions of the 
IETF.

Title   : TCP Encapsulation of IKE and IPsec Packets
Authors : Tommy Pauly
  Samy Touati
  Ravi Mantha
Filename: draft-ietf-ipsecme-tcp-encaps-07.txt
Pages   : 22
Date: 2017-02-09

Abstract:
   This document describes a method to transport IKE and IPsec packets
   over a TCP connection for traversing network middleboxes that may
   block IKE negotiation over UDP.  This method, referred to as TCP
   encapsulation, involves sending both IKE packets for Security
   Association establishment and ESP packets over a TCP connection.
   This method is intended to be used as a fallback option when IKE
   cannot be negotiated over UDP.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-tcp-encaps-07


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Working group last call for the draft-nir-ipsecme-eddsa-00

[Paul Wouters]

Yes I forgot to reply. I strongly object to assigning 0 for real values. It 
should be left for implementations to detect a value has not been set.

Paul

Sent from my iPhone

> On Feb 9, 2017, at 11:12, Tommy Pauly  wrote:
> 
> Thanks for sending out the corrected draft name, Tero. I think this draft is 
> in good shape in general and we should move forward with it.
> 
> The only thing that seems to need ironing out is the specific IANA hash 
> value. I can see the argument either way: as the draft points out, 0 makes 
> sense for the Identity hash, since it can be viewed as "no hash at all". 
> However, I agree with your point that 0 may often be used in code to indicate 
> an uninitialized value. I would be concerned if existing implementations 
> flagged 0 as an error, here, as well.
> 
> I think it would make sense to do a quick poll of the WG to get some 
> consensus on this. At this point, I'm mildly in favor of a new value (5).
> 
> Thanks,
> Tommy
> 
>> On Feb 9, 2017, at 4:40 AM, Tero Kivinen  wrote:
>> 
>> Ah I noticed that my last call email had wrong draft name in the
>> subject line and in the link. The correct draft name is of course
>> draft-ietf-ipsecme-eddsa-00 not *-nir-* version.
>> 
>> David Schinazi writes:
>>> I've reviewed this draft. I support it and believe it is ready to move 
>>> forward
>>> towards becoming a standards-track RFC. Also, would it make sense to ask
>>> IANA for early assignment of the code point? Using 0 sounds reasonable to 
>>> me.
>> 
>> As this is expert review registry there is no need to ask for early
>> allocation, the normal process is just to fill in the IANA general
>> request for assignments, which then goes to the IANA and they will
>> then send it to the expert (me) for verification.
>> 
>> If normal number (other than 0) would be given out, then I would just
>> say yes, but allocating 0, which in registry is marked as:
>> 
>>0Reserved[RFC7427]
>> 
>> and is not part of the :
>> 
>>5-1023Unassigned
>> 
>> range, then I would be bit more hesitant to give it out, and would
>> most likely want to poll the WG and list before making decision.
>> 
>> I actually myself think it would be better to just allocate next free
>> number from the unassigned space, and keep the value 0 as reserved...
>> 
>> For example we do not use value 0 of Encryption Algorithms transform
>> to mean ENCR_NULL, we do have separate number allocated for it. On the
>> other hand we do have value 0 meaning NONE in the Integrity algorithm
>> transform ID table and for diffie hellman values, but there the
>> meaning is bit different, it means there is no value for that id, here
>> it would be meaning that there is this identity function version of
>> the hash function. 
>> 
>> As an expert and as a implementor I think I would prefer next free
>> number over 0... Quite commonly in the code we use value 0 as meaning,
>> we have not yet received anything, or we have not yet initialized this
>> field, and having separate value for identity function might make
>> things easier. But if others have good reasons why the value 0 is
>> better, feel free to tell me...
>> -- 
>> kivi...@iki.fi
>> 
>> ___
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Working group last call for the draft-nir-ipsecme-eddsa-00

[Tommy Pauly]

Thanks for sending out the corrected draft name, Tero. I think this draft is in 
good shape in general and we should move forward with it.

The only thing that seems to need ironing out is the specific IANA hash value. 
I can see the argument either way: as the draft points out, 0 makes sense for 
the Identity hash, since it can be viewed as "no hash at all". However, I agree 
with your point that 0 may often be used in code to indicate an uninitialized 
value. I would be concerned if existing implementations flagged 0 as an error, 
here, as well.

I think it would make sense to do a quick poll of the WG to get some consensus 
on this. At this point, I'm mildly in favor of a new value (5).

Thanks,
Tommy

> On Feb 9, 2017, at 4:40 AM, Tero Kivinen  wrote:
> 
> Ah I noticed that my last call email had wrong draft name in the
> subject line and in the link. The correct draft name is of course
> draft-ietf-ipsecme-eddsa-00 not *-nir-* version.
> 
> David Schinazi writes:
>> I've reviewed this draft. I support it and believe it is ready to move 
>> forward
>> towards becoming a standards-track RFC. Also, would it make sense to ask
>> IANA for early assignment of the code point? Using 0 sounds reasonable to me.
> 
> As this is expert review registry there is no need to ask for early
> allocation, the normal process is just to fill in the IANA general
> request for assignments, which then goes to the IANA and they will
> then send it to the expert (me) for verification.
> 
> If normal number (other than 0) would be given out, then I would just
> say yes, but allocating 0, which in registry is marked as:
> 
>   0   Reserved[RFC7427]
> 
> and is not part of the :
> 
>   5-1023  Unassigned
> 
> range, then I would be bit more hesitant to give it out, and would
> most likely want to poll the WG and list before making decision.
> 
> I actually myself think it would be better to just allocate next free
> number from the unassigned space, and keep the value 0 as reserved...
> 
> For example we do not use value 0 of Encryption Algorithms transform
> to mean ENCR_NULL, we do have separate number allocated for it. On the
> other hand we do have value 0 meaning NONE in the Integrity algorithm
> transform ID table and for diffie hellman values, but there the
> meaning is bit different, it means there is no value for that id, here
> it would be meaning that there is this identity function version of
> the hash function. 
> 
> As an expert and as a implementor I think I would prefer next free
> number over 0... Quite commonly in the code we use value 0 as meaning,
> we have not yet received anything, or we have not yet initialized this
> field, and having separate value for identity function might make
> things easier. But if others have good reasons why the value 0 is
> better, feel free to tell me...
> -- 
> kivi...@iki.fi
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Working group last call for the draft-nir-ipsecme-eddsa-00

[Tero Kivinen]

Ah I noticed that my last call email had wrong draft name in the
subject line and in the link. The correct draft name is of course
draft-ietf-ipsecme-eddsa-00 not *-nir-* version.

David Schinazi writes:
> I've reviewed this draft. I support it and believe it is ready to move forward
> towards becoming a standards-track RFC. Also, would it make sense to ask
> IANA for early assignment of the code point? Using 0 sounds reasonable to me.

As this is expert review registry there is no need to ask for early
allocation, the normal process is just to fill in the IANA general
request for assignments, which then goes to the IANA and they will
then send it to the expert (me) for verification.

If normal number (other than 0) would be given out, then I would just
say yes, but allocating 0, which in registry is marked as:

0   Reserved[RFC7427]

and is not part of the :

5-1023  Unassigned

range, then I would be bit more hesitant to give it out, and would
most likely want to poll the WG and list before making decision.

I actually myself think it would be better to just allocate next free
number from the unassigned space, and keep the value 0 as reserved...

For example we do not use value 0 of Encryption Algorithms transform
to mean ENCR_NULL, we do have separate number allocated for it. On the
other hand we do have value 0 meaning NONE in the Integrity algorithm
transform ID table and for diffie hellman values, but there the
meaning is bit different, it means there is no value for that id, here
it would be meaning that there is this identity function version of
the hash function. 

As an expert and as a implementor I think I would prefer next free
number over 0... Quite commonly in the code we use value 0 as meaning,
we have not yet received anything, or we have not yet initialized this
field, and having separate value for identity function might make
things easier. But if others have good reasons why the value 0 is
better, feel free to tell me...
-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] [Editorial Errata Reported] RFC7296 (4930)

[Tero Kivinen]

RFC Errata System writes:
> The following errata report has been submitted for RFC7296,
> "Internet Key Exchange Protocol Version 2 (IKEv2)".
> 
> --
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=7296=4930
> 
> --
> Type: Editorial
> Reported by: Nikolai Malykh 
> 
> Section: 3.16
> 
> Original Text
> -
>Note that since IKE passes an indication of initiator identity in the
>first message in the IKE_AUTH exchange, the responder SHOULD NOT send
>EAP Identity requests.  The initiator MAY, however, respond to such
>requests if it receives them.
> 
> Corrected Text
> --
> 
> 
> Notes
> -
> The last sentence of this section contains unnecessary repetition
> written above (the last sentence in description of Type field).

This is true, but when we discussed it last time while in RFC editor
phase of the rfc5996bis (which came out to be RFC7296) we decided that
this emphasis is useful, and decided to keep it.

https://www.ietf.org/mail-archive/web/ipsec/current/msg09362.html
https://www.ietf.org/mail-archive/web/ipsec/current/msg09365.html

At that point we fixed the text to use same RFC2119 wording in both
places. 

I do not think there has been anything that really changed the reasons
why we decided to kept it twice in the document since that, so I think
the text should stay at it is now.

> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --
> RFC7296 (draft-kivinen-ipsecme-ikev2-rfc5996bis-04)
> --
> Title   : Internet Key Exchange Protocol Version 2 (IKEv2)
> Publication Date: October 2014
> Author(s)   : C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, T. Kivinen
> Category: INTERNET STANDARD
> Source  : IP Security Maintenance and Extensions
> Area: Security
> Stream  : IETF
> Verifying Party : IESG
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec