Re: [IPsec] New version of TCP Encapsulation draft, request for adoption

[Hu, Jun (Nokia - US)]

>From the section 6 text, my understanding is draft allows multiple TCP 
>connections for a given tunnel which includes multiple CHILD_SAs; however it 
>is not clear to me that draft also allows multiple TCP session for a single 
>SA, is there any use case of having multiple TCP sessions for a single 
>CHILD_SA?


From: tpa...@apple.com [mailto:tpa...@apple.com]
Sent: Tuesday, October 11, 2016 5:35 PM
To: Hu, Jun (Nokia - US)
Cc: Valery Smyslov; Yoav Nir; IPsecME WG; Daniel Migault; Paul Wouters
Subject: Re: [IPsec] New version of TCP Encapsulation draft, request for 
adoption

Please see section 6:


 Multiple TCP connections between the initiator and the responder are

   allowed, but their use must take into account the initiator

   capabilities and the deployment model such as to connect to multiple

   gateways handling different ESP SAs when deployed in a high

   availability model.  It is also possible to negotiate multiple IKE

   SAs over the same TCP connection.



   The processing of the TCP packets is the same whether its within a

   single or multiple TCP connections.


We believe this text is fairly direct in specifying that multiple IKE SAs can 
go over a single TCP stream, and that multiple TCP streams are allowed for a 
single IKE SA/Child SA set. There is no dependency between the TCP streams and 
the IKE or Child SAs. We recommend a 1-to-1 correspondence for simplicity, but 
there is no technical limitation. The TCP streams should not necessarily be 
closed or reset if the SA sends data on a different flow.


Thanks,

Tommy


On Oct 11, 2016, at 3:00 PM, Hu, Jun (Nokia - US) 
> wrote:

Any comments to my questions below?
Does draft allows multiple TCP sessions for a given SA? Or it should be only 
one TCP session allowed for a given SA?


-Original Message-
From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Hu, Jun (Nokia - US)
Sent: Friday, October 07, 2016 2:09 PM
To: Tommy Pauly; Valery Smyslov; Yoav Nir
Cc: IPsecME WG; Daniel Migault; Paul Wouters
Subject: Re: [IPsec] New version of TCP Encapsulation draft, request for
adoption

I was reading the draft again, and had similar problem as below; Draft states
that SA state should be independent of TCP state and it allows multiple TCP
sessions between two peers even when there is only one IKE_SA; I assume this
means for a given tunnel, different SA could belong to different TCP session,
e.g. IKE_SA uses TCP session-1, CHILD_SA uses TCP session-2; however does
this mean draft allows multiple TCP sessions for a given SA? I guess not, if
that's the case, then it should be stated clearly in the draft that for a given 
SA,
only one TCP session is allowed; In case of when the original initiator lost TCP
session and create a new one, the responder should update its TCP_session-
to-SA binding after it receives a valid IKE/ESP packet is received on the new
TCP session and close the old one, send TCP RST


-Original Message-
From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Tommy Pauly
...


Then, I think some text should be added describing a situation when
the original responder having a valid (from its point of view) TCP
session receives a request from original initiator for a new TCP
session. This may happen if original initiator looses TCP state for
some reason (RST from an attacker, temporary network failure etc.).
In this case the responder will have two TCP sessions associated
with the IKE SA. Clearly, the new one should be used for further
communications, but only after it is proven to be authentic (some
protected message is received over it). But what the responder
should do
with the old TCP session?

Keep it? Send FIN? Send RST? Just discard?

In general, the approach of the draft is to clearly separate the TCP
state from the IKE session state. If you look at Section 6, it
specifically allows for multiple TCP connections between two peers
even if there is only one IKE SA between them. If one of them becomes
redundant (because the other peer opened up a new TCP flow for some
reason), it would make sense to close the other in a usual way. I
think this can be left to the implementation, but either a FIN or RST would be
appropriate rather than a discard. We can add that to future versions.



___
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] New version of TCP Encapsulation draft, request for adoption

[Tommy Pauly]

Please see section 6:

 Multiple TCP connections between the initiator and the responder are
   allowed, but their use must take into account the initiator
   capabilities and the deployment model such as to connect to multiple
   gateways handling different ESP SAs when deployed in a high
   availability model.  It is also possible to negotiate multiple IKE
   SAs over the same TCP connection.

   The processing of the TCP packets is the same whether its within a
   single or multiple TCP connections.

We believe this text is fairly direct in specifying that multiple IKE SAs can 
go over a single TCP stream, and that multiple TCP streams are allowed for a 
single IKE SA/Child SA set. There is no dependency between the TCP streams and 
the IKE or Child SAs. We recommend a 1-to-1 correspondence for simplicity, but 
there is no technical limitation. The TCP streams should not necessarily be 
closed or reset if the SA sends data on a different flow.

Thanks,
Tommy


> On Oct 11, 2016, at 3:00 PM, Hu, Jun (Nokia - US)  wrote:
> 
> Any comments to my questions below?
> Does draft allows multiple TCP sessions for a given SA? Or it should be only 
> one TCP session allowed for a given SA?
> 
>> -Original Message-
>> From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Hu, Jun (Nokia - US)
>> Sent: Friday, October 07, 2016 2:09 PM
>> To: Tommy Pauly; Valery Smyslov; Yoav Nir
>> Cc: IPsecME WG; Daniel Migault; Paul Wouters
>> Subject: Re: [IPsec] New version of TCP Encapsulation draft, request for
>> adoption
>> 
>> I was reading the draft again, and had similar problem as below; Draft states
>> that SA state should be independent of TCP state and it allows multiple TCP
>> sessions between two peers even when there is only one IKE_SA; I assume this
>> means for a given tunnel, different SA could belong to different TCP session,
>> e.g. IKE_SA uses TCP session-1, CHILD_SA uses TCP session-2; however does
>> this mean draft allows multiple TCP sessions for a given SA? I guess not, if
>> that's the case, then it should be stated clearly in the draft that for a 
>> given SA,
>> only one TCP session is allowed; In case of when the original initiator lost 
>> TCP
>> session and create a new one, the responder should update its TCP_session-
>> to-SA binding after it receives a valid IKE/ESP packet is received on the new
>> TCP session and close the old one, send TCP RST
>> 
>>> -Original Message-
>>> From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Tommy Pauly
>> ...
>> 
 Then, I think some text should be added describing a situation when
 the original responder having a valid (from its point of view) TCP
 session receives a request from original initiator for a new TCP
 session. This may happen if original initiator looses TCP state for
 some reason (RST from an attacker, temporary network failure etc.).
 In this case the responder will have two TCP sessions associated
 with the IKE SA. Clearly, the new one should be used for further
 communications, but only after it is proven to be authentic (some
 protected message is received over it). But what the responder
 should do
>>> with the old TCP session?
 Keep it? Send FIN? Send RST? Just discard?
 
>>> 
>>> In general, the approach of the draft is to clearly separate the TCP
>>> state from the IKE session state. If you look at Section 6, it
>>> specifically allows for multiple TCP connections between two peers
>>> even if there is only one IKE SA between them. If one of them becomes
>>> redundant (because the other peer opened up a new TCP flow for some
>>> reason), it would make sense to close the other in a usual way. I
>>> think this can be left to the implementation, but either a FIN or RST would 
>>> be
>> appropriate rather than a discard. We can add that to future versions.
>>> 
>> 
>> ___
>> 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] New version of TCP Encapsulation draft, request for adoption

[Hu, Jun (Nokia - US)]

Any comments to my questions below?
Does draft allows multiple TCP sessions for a given SA? Or it should be only 
one TCP session allowed for a given SA?

> -Original Message-
> From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Hu, Jun (Nokia - US)
> Sent: Friday, October 07, 2016 2:09 PM
> To: Tommy Pauly; Valery Smyslov; Yoav Nir
> Cc: IPsecME WG; Daniel Migault; Paul Wouters
> Subject: Re: [IPsec] New version of TCP Encapsulation draft, request for
> adoption
> 
> I was reading the draft again, and had similar problem as below; Draft states
> that SA state should be independent of TCP state and it allows multiple TCP
> sessions between two peers even when there is only one IKE_SA; I assume this
> means for a given tunnel, different SA could belong to different TCP session,
> e.g. IKE_SA uses TCP session-1, CHILD_SA uses TCP session-2; however does
> this mean draft allows multiple TCP sessions for a given SA? I guess not, if
> that's the case, then it should be stated clearly in the draft that for a 
> given SA,
> only one TCP session is allowed; In case of when the original initiator lost 
> TCP
> session and create a new one, the responder should update its TCP_session-
> to-SA binding after it receives a valid IKE/ESP packet is received on the new
> TCP session and close the old one, send TCP RST
> 
> > -Original Message-
> > From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Tommy Pauly
> ...
> 
> > > Then, I think some text should be added describing a situation when
> > > the original responder having a valid (from its point of view) TCP
> > > session receives a request from original initiator for a new TCP
> > > session. This may happen if original initiator looses TCP state for
> > > some reason (RST from an attacker, temporary network failure etc.).
> > > In this case the responder will have two TCP sessions associated
> > > with the IKE SA. Clearly, the new one should be used for further
> > > communications, but only after it is proven to be authentic (some
> > > protected message is received over it). But what the responder
> > > should do
> > with the old TCP session?
> > > Keep it? Send FIN? Send RST? Just discard?
> > >
> >
> > In general, the approach of the draft is to clearly separate the TCP
> > state from the IKE session state. If you look at Section 6, it
> > specifically allows for multiple TCP connections between two peers
> > even if there is only one IKE SA between them. If one of them becomes
> > redundant (because the other peer opened up a new TCP flow for some
> > reason), it would make sense to close the other in a usual way. I
> > think this can be left to the implementation, but either a FIN or RST would 
> > be
> appropriate rather than a discard. We can add that to future versions.
> >
> 
> ___
> 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] Gen-ART Last Call review of draft-ietf-ipsecme-safecurves-04

[Orit Levin]

Thanks, Yoav!
This addresses all my comments.
Best,
Orit.

-Original Message-
From: Yoav Nir [mailto:ynir.i...@gmail.com] 
Sent: Tuesday, October 11, 2016 12:46 PM
To: Orit Levin 
Cc: draft-ietf-ipsecme-safecurves@ietf.org; General Area Review Team 

Subject: Re: Gen-ART Last Call review of draft-ietf-ipsecme-safecurves-04

Hi, Orit.

I accepted most of your suggestions with a few exceptions below:

> On 28 Sep 2016, at 0:30, Orit Levin  wrote:
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area Review 
> Team (Gen-ART) reviews all IETF documents being processed by the IESG for the 
> IETF Chair.  Please treat these comments just like any other last call 
> comments.
> 
> For more information, please see the FAQ at 
> .
> 
> Document: review of draft-ietf-ipsecme-safecurves-04
> Reviewer: Orit Levin (mailto:or...@microsoft.com) Review Date: 
> 2016-09-27 IETF LC End Date: 2016-09-29 IESG Telechat date: unknown
> 
> Summary:
> This draft is basically ready for publication, but has nits that should be 
> fixed before publication. The nits are purely editorial, but fixing them will 
> improve the document's readability.
> 
> 1. Introduction
> Par.1 "key agreement (Diffie-Hellman)" : Replace with "key agreement using 
> Diffie-Hellman".
> Par.2 "That document": Replace with the name of the document to make clear 
> which one is "that" document.
> Par.2 "free from": Replace with "resilient to".
> 
> 2. Curve25519 and Curve448
> Add at the start "Implementations of Curve25519 and Curve448 MUST/SHALL 
> follow the steps described in this section."
> Par.1 Replace "are inherited from" with "are compliant with".
> Par.2 Replace "goes as" with "is performed as"
> 
> 3. Use and Negotiation in IKEv2
> Consider replacing TBA1/TBA2 throughout the section with [to be replaced with 
> TBA1/TBA2 according to the IANA assignment].

I have left this as is. This worked for me in the past. I will make sure these 
were replaced during AUTH48.

> 3.2 Consider replace the first sentence with "Receiving and handling 
> of incompatible point formats MUST comply with [or MUST follow] 
> considerations/procedures described in section 5 of [RFC7748].”

I ended up with this:
3.2.  Recipient Tests

   Receiving and handling of incompatible point formats MUST follow the
   considerations described in section 5 of [RFC7748].  In particular,
   receiving entities MUST mask the most-significant bit in the final
   byte for X25519 (but not X448), and implementations MUST accept non-
   canonical values.

> 
> 4. Security Considerations
> Par.1 Replace the paragraph text to
> "For high-performance constant-time implementations, it is RECOMMENDED to use 
> Curve25519 and Curve448 which were designed for this purpose. Implementers 
> MUST/SHOULD NOT attempt to improve performance by reusing supposedly 
> ephemeral key pair across multiple key exchanges [because ...].”

Your suggested text says that reusing ephemeral keys is a bad thing. Reading 
over the original text I can see that it could be interpreted like that. This 
was not our intention. Reusing ephemeral keys is OK. You MUST use a 
constant-time implementation because otherwise each use of the same ephemeral 
key may leak a few bits. So if you are reusing the keys, it is especially 
important to use constant-time implementations, whereas if you only used each 
key once, it would be kind-of OK to use any implementation.  I’ve reworded the 
paragraph as follows:

   Curve25519 and Curve448 are designed to facilitate the production of
   high-performance constant-time implementations.  Implementors are
   encouraged to use a constant-time implementation of the functions.
   This point is of crucial importance especially if the implementation
   chooses to reuse its ephemeral key pair in many key exchanges for
   performance reasons.


> Par.3 In " ... the process used to pick these curves..." replace "these" with 
> the names to avoid confusion.
> Par.3 Replace " ...verification has been done..." with "verification can be 
> done".
> Par.4 Replace ",generated in a fully verifiable way," with "that are 
> generated in a fully verifiable way".
> 
> 6. Acknowledgements
> Par1. Replace "is by Mike" with "were defined/specified/etc. by Mike".
> Par1. Replace "are in RFC 7748" with " are documented/specified/etc. in RFC 
> 7748".
> 
> Thank you,
> Orit.
> 
> 
> 

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

[IPsec] New Version Notification - draft-ietf-ipsecme-safecurves-05.txt

[internet-drafts]

A new version (-05) has been submitted for draft-ietf-ipsecme-safecurves:
https://www.ietf.org/internet-drafts/draft-ietf-ipsecme-safecurves-05.txt


The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-safecurves/

Diff from previous version:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-safecurves-05

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.

IETF Secretariat.

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

[IPsec] I-D Action: draft-ietf-ipsecme-safecurves-05.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   : Curve25519 and Curve448 for IKEv2 Key Agreement
Authors : Yoav Nir
  Simon Josefsson
Filename: draft-ietf-ipsecme-safecurves-05.txt
Pages   : 7
Date: 2016-10-11

Abstract:
   This document describes the use of Curve25519 and Curve448 for
   ephemeral key exchange in the Internet Key Exchange (IKEv2) protocol.


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

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

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


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