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

[Tommy Pauly]

Hi Jun,

You’re correct that the draft does not specifically call out using multiple TCP 
connections for a single Child SA. It explains that one reason to use multiple 
TCP connections is to handle “connect[ing] to multiple gateways handling 
different ESP SAs”, which is the one-child-SA-per-TCP model. There is nothing 
in the protocol prohibiting using multiple TCP connections for a single child 
SA; what is your main use case here? Is there something that you find useful in 
that that could perhaps help inform this clarifying text?

Tommy

> On Oct 11, 2016, at 8:42 PM, Hu, Jun (Nokia - US) <jun...@nokia.com> wrote:
> 
> 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) <jun...@nokia.com 
> <mailto:jun...@nokia.com>> 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 <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 <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

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) 
<jun...@nokia.com<mailto:jun...@nokia.com>> 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<mailto:IPsec@ietf.org>
https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org<mailto: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) <jun...@nokia.com> 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] New version of TCP Encapsulation draft, request for adoption

[Hu, Jun (Nokia - US)]

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

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

[Hu, Jun (Nokia - US)]

Thanks all for the clarification. 

> -Original Message-
> From: tpa...@apple.com [mailto:tpa...@apple.com]
> Sent: Monday, May 23, 2016 5:28 PM
> To: Hu, Jun (Nokia - US)
> Cc: Paul Wouters; IPsecME WG
> Subject: Re: [IPsec] New version of TCP Encapsulation draft, request for
> adoption
> 
> Hi Jun,
> 
> You are correct—the draft specifically allows for the possibility of doing
> encrypted TLS as a tunnel for the purposes of getting through some
> middleboxes. There are some that will validate that traffic is either HTTP or 
> TLS,
> and since IKE traffic will not look like HTTP, one could use TLS instead.
> 
> Thanks,
> Tommy
> 
> > On May 23, 2016, at 4:42 PM, Hu, Jun (Nokia - US) <jun...@nokia.com> wrote:
> >
> >> From: Paul Wouters [mailto:p...@nohats.ca]
> >> Sent: Monday, May 23, 2016 4:26 PM
> >> To: Hu, Jun (Nokia - US)
> >> Cc: IPsecME WG
> >> Subject: Re: [IPsec] New version of TCP Encapsulation draft, request
> >> for adoption
> >>
> >> On Mon, 23 May 2016, Hu, Jun (Nokia - US) wrote:
> >>
> >>>> To get past middleware boxes that tend to not touch "real" TLS
> >>>> traffic but mangle anything else.
> >>>
> >>> [HJ]  so there is middle box that will only allow TLS traffic (and
> >>> dropping all
> >> plain tcp traffic)? that sounds pretty extreme, but even in such
> >> case, nothing prevent such middle box to have a new rule to drop TLS
> >> encapsulated IPsec traffic if TLS level encryption is not used.
> >>
> >> Correct. There will always be that battle of deep packet inspection
> >> and proxies versus people who want to be protected from them.
> >
> > [HJ] ok, so my takeaway is TLS encapsulation without encryption is useful 
> > for
> HTTP proxy traversal and some middle box only allows TLS traffic; however the
> draft doesn't prevent TLS encapsulation with encryption, which might be useful
> to get around some really strict middle box which inspects TLS payload.
> >
> > ___
> > 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)]

> From: Paul Wouters [mailto:p...@nohats.ca]
> Sent: Monday, May 23, 2016 4:26 PM
> To: Hu, Jun (Nokia - US)
> Cc: IPsecME WG
> Subject: Re: [IPsec] New version of TCP Encapsulation draft, request for
> adoption
> 
> On Mon, 23 May 2016, Hu, Jun (Nokia - US) wrote:
> 
> >> To get past middleware boxes that tend to not touch "real" TLS
> >> traffic but mangle anything else.
> >
> > [HJ]  so there is middle box that will only allow TLS traffic (and dropping 
> > all
> plain tcp traffic)? that sounds pretty extreme, but even in such case, nothing
> prevent such middle box to have a new rule to drop TLS encapsulated IPsec
> traffic if TLS level encryption is not used.
> 
> Correct. There will always be that battle of deep packet inspection and 
> proxies
> versus people who want to be protected from them.

[HJ] ok, so my takeaway is TLS encapsulation without encryption is useful for 
HTTP proxy traversal and some middle box only allows TLS traffic; however the 
draft doesn't prevent TLS encapsulation with encryption, which might be useful 
to get around some really strict middle box which inspects TLS payload. 

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

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

[Paul Wouters]

On Mon, 23 May 2016, Hu, Jun (Nokia - US) wrote:


To get past middleware boxes that tend to not touch "real" TLS traffic but
mangle anything else.


[HJ]  so there is middle box that will only allow TLS traffic (and dropping all 
plain tcp traffic)? that sounds pretty extreme, but even in such case, nothing 
prevent such middle box to have a new rule to drop TLS encapsulated IPsec 
traffic if TLS level encryption is not used.


Correct. There will always be that battle of deep packet inspection and
proxies versus people who want to be protected from them.

Paul

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

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

[Samy Touati]

Hi 

We use TLS to facilitate traversal of IPSEC traffic through http proxies.
The client would use the HTTP Connect command to connect to the proxy.
TLS is only used for this purpose and not for securing the IPSec link.

Thanks.
Samy.


On 5/23/16, 3:55 PM, "IPsec on behalf of Hu, Jun (Nokia - US)" 
<ipsec-boun...@ietf.org on behalf of jun...@nokia.com> wrote:

>> -Original Message-
>> From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Yoav Nir
>> Sent: Monday, May 23, 2016 2:13 PM
>> To: Valery Smyslov
>> Cc: IPsecME WG; Daniel Migault; Paul Wouters; Tommy Pauly
>> Subject: Re: [IPsec] New version of TCP Encapsulation draft, request for
>> adoption
>> 
>> 
>> > On 23 May 2016, at 9:39 AM, Valery Smyslov <sva...@gmail.com> wrote:
>> >
>> > Hi Tommy,
>> >
>> > thank you for clarifications. One more point. The draft is silent
>> > about what the responder is supposed to do with the stream prefix.
>> > Should it check it? In this case what should it do if the prefix is
>> > different from "IKEv2"? Discard the TCP session? Or should it ignore
>> > the prefix completely? In this case how many bytes should it skip from
>> > the beginning of the stream - exactly 5?
>> 
>> This prefix is used for de-multiplexing. For example, if we listen for IKE 
>> on TCP
>> port 443 and also have an HTTPS server there (perhaps as an administrative
>> interface).
>> 
>> Assuming we don’t encrypt IKE in TLS, 
>
>[HJ] this part is a bit confusing for me, if we don't use TLS level 
>encryption, then what's the benefit of using TLS over plain TCP encapsulation? 
> In fact, I don't know why TLS encapsulation is needed at all, it is said in 
>the draft that " The security of the IKEv2 session is entirely derived from 
>the IKVEv2 negotiation and key establishment", so encryption/authentication of 
>TLS level are not needed at all. 
>
>> then we need the prefix to differentiate
>> between IKE and TLS. Currently, there’s no way a valid ClientHello begins 
>> with
>> “IKEv2”, and hopefully that will not change with TLS 1.3 or any future 
>> version. If
>> we do encapsulate IKEv2 in TLS, we still need to differentiate IKEv2 from 
>> HTTP.
>> And again, there is no HTTP method called “IKEv2”.
>
>> 
>> So I think the parsing and consuming of this prefix is not part of the IKE, 
>> but
>> part of the de-multiplexer. If the port has several services, then not 
>> having the
>> “IKEv2” prefix means that the stream should be processed by some other
>> processor. If IKEv2 is the only service on that particular port, then we 
>> need a
>> very simple de-multiplexer: if the first 5 bytes are “IKEv2” then consume 
>> them
>> and forward the rest to the IKEv2 service. If it’s anything else, close the
>> connection.
>> 
>
>___
>IPsec mailing list
>IPsec@ietf.org
>https://www.ietf.org/mailman/listinfo/ipsec


smime.p7s
Description: S/MIME cryptographic signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

> On 23 May 2016, at 9:39 AM, Valery Smyslov  wrote:
> 
> Hi Tommy,
> 
> thank you for clarifications. One more point. The draft is silent about
> what the responder is supposed to do with the stream prefix.
> Should it check it? In this case what should it do if the prefix is
> different from "IKEv2"? Discard the TCP session? Or should
> it ignore the prefix completely? In this case how many bytes
> should it skip from the beginning of the stream - exactly 5?

This prefix is used for de-multiplexing. For example, if we listen for IKE on 
TCP port 443 and also have an HTTPS server there (perhaps as an administrative 
interface).

Assuming we don’t encrypt IKE in TLS, then we need the prefix to differentiate 
between IKE and TLS. Currently, there’s no way a valid ClientHello begins with 
“IKEv2”, and hopefully that will not change with TLS 1.3 or any future version. 
If we do encapsulate IKEv2 in TLS, we still need to differentiate IKEv2 from 
HTTP. And again, there is no HTTP method called “IKEv2”.

So I think the parsing and consuming of this prefix is not part of the IKE, but 
part of the de-multiplexer. If the port has several services, then not having 
the “IKEv2” prefix means that the stream should be processed by some other 
processor. If IKEv2 is the only service on that particular port, then we need a 
very simple de-multiplexer: if the first 5 bytes are “IKEv2” then consume them 
and forward the rest to the IKEv2 service. If it’s anything else, close the 
connection.

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

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

[Valery Smyslov]

Hi Paul,


thank you for clarifications. One more point. The draft is silent about
what the responder is supposed to do with the stream prefix.
Should it check it? In this case what should it do if the prefix is
different from "IKEv2"? Discard the TCP session? Or should
it ignore the prefix completely? In this case how many bytes
should it skip from the beginning of the stream - exactly 5?


That might not work well if we get IKEv2.1


That was the point. But please see below.


Actually, I'd argue it should be a unique identifier but not contain a
verion number of the IKE protocol at all.


Not sure. Actually, this prefix is meaningful only for middleboxes,
so it is not linked with any particular IKE version and can be an arbitrary 
string,
that is different from TLS ClienHello and other existing prefixes Yoav 
mentioned.

On the other hand the prefix can be used as an indication of teh encapsulation
format. For example, in the unlikely event we later want to change length field size 
to 4 bytes, we can change the prefix to distinguish between old and new formats. 
In this case the responder should discard the TCP session if 
the prefix doesn't match an expected value, since it means

that the encapsulation format is different from what it understands.

But my point was that in any case - whether the prefix should be checked or 
ignored
by responder, - the behaviour must be clearly described in the draft.


Paul


Regards,
Valery.

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

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

[Paul Wouters]

On Mon, 23 May 2016, Valery Smyslov wrote:


thank you for clarifications. One more point. The draft is silent about
what the responder is supposed to do with the stream prefix.
Should it check it? In this case what should it do if the prefix is
different from "IKEv2"? Discard the TCP session? Or should
it ignore the prefix completely? In this case how many bytes
should it skip from the beginning of the stream - exactly 5?


That might not work well if we get IKEv2.1

Actually, I'd argue it should be a unique identifier but not contain a
verion number of the IKE protocol at all.

Paul

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

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

[Valery Smyslov]

Hi Tommy,

thank you for clarifications. One more point. The draft is silent about
what the responder is supposed to do with the stream prefix.
Should it check it? In this case what should it do if the prefix is
different from "IKEv2"? Discard the TCP session? Or should
it ignore the prefix completely? In this case how many bytes
should it skip from the beginning of the stream - exactly 5?

Regards,
Valery.

- Original Message - 
From: "Tommy Pauly" <tpa...@apple.com>

To: "Valery Smyslov" <sva...@gmail.com>; "Yoav Nir" <ynir.i...@gmail.com>
Cc: "Paul Wouters" <p...@nohats.ca>; "Daniel Migault" <daniel.miga...@ericsson.com>; 
"IPsecME WG" <ipsec@ietf.org>
Sent: Friday, May 20, 2016 9:11 PM
Subject: Re: [IPsec] New version of TCP Encapsulation draft, request for 
adoption


Hi Valery,

Thanks for your reply! I think these are good points that we can clarify in future versions, although we can address 
these once it is a working group document. Responses inline.


Best,
Tommy


On May 16, 2016, at 11:53 PM, Valery Smyslov <sva...@gmail.com> wrote:

Hi Tommy,

sorry for late reply. I'm mostly OK with the last version of the draft.

Few comments. It is a bit unclear how Stream Prefix is intended
to be used with TLS. Is it insterted at the beginning of the TLS data stream?


The intention is that the prefix is used at the beginning of the stream even when TLS is being used (specifically, 
inside the encrypted TLS stream). Since the point of the prefix is to identify which specific protocol is being used, to 
differentiate from other TLS or VPN traffic, it is relevant to use it even when going over TLS port 443 in case the 
server being used also supports other VPN protocols over the same port using TLS. This is one of the points Yoav brought 
up.




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.



Regards,
Valery.


Hi Paul, Daniel,

Thanks for the comments! Responses inline.

I'd like to also hear feedback from people who brought up issues last time if possible (Valery regarding inclusion of 
TLS, Tero regarding the 3GPP spec conformity, and Yoav regarding the magic value) to validate that this draft is 
satisfactory to resolve those issues.


Thanks,
Tommy



On May 6, 2016, at 4:48 PM, Paul Wouters <p...@nohats.ca> wrote:

On Fri, 6 May 2016, Daniel Migault wrote:


s/IPSec/IPsec


If Tommy could also fix that auto-correct for my iphone, that would be
great too :)


"This method is intended to be used as a fallback option when IKE
cannot be negotiated over UDP."
This seems to indicates that the method should only be used with IKEv2
which contradicts the title. Thus I would mention. When used with IKE,
this method...


This has happened in this group a few times now in different documents.
People want to say IKEv2 to exclude IKE, but we should really say IKE
so these documents don't look weird when/if we get IKEv3.


Sure, this can be changed to IKE rather than IKEv2. Whichever the group thinks 
makes most sense is fine with me.




I think that for interoperability, we should define a port at the
IANA. If that port is 4500 we should detail why an how the two
encapsulation method works. Are there any disadvantages of using an
allocated port? One reason reason I suspect port agility may be needed
is NAT. If so that should be clearly documented.


We should not define a port unless it is 443, which we kind of cannot.


Agreed. The most common port in practice will end up being 443; we do have 4500 allocated if people want to do 
generic TCP testing, but to get through NATs and firewalls, we need to often use 443 today. This may change in the 
future, so we specifically leave this port option as a configuratio

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

[Tommy Pauly]

Hi Valery,

Thanks for your reply! I think these are good points that we can clarify in 
future versions, although we can address these once it is a working group 
document. Responses inline.

Best,
Tommy

> On May 16, 2016, at 11:53 PM, Valery Smyslov  wrote:
> 
> Hi Tommy,
> 
> sorry for late reply. I'm mostly OK with the last version of the draft.
> 
> Few comments. It is a bit unclear how Stream Prefix is intended
> to be used with TLS. Is it insterted at the beginning of the TLS data stream?

The intention is that the prefix is used at the beginning of the stream even 
when TLS is being used (specifically, inside the encrypted TLS stream). Since 
the point of the prefix is to identify which specific protocol is being used, 
to differentiate from other TLS or VPN traffic, it is relevant to use it even 
when going over TLS port 443 in case the server being used also supports other 
VPN protocols over the same port using TLS. This is one of the points Yoav 
brought up.

> 
> 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.

> Regards,
> Valery.
> 
>> Hi Paul, Daniel,
>> 
>> Thanks for the comments! Responses inline.
>> 
>> I'd like to also hear feedback from people who brought up issues last time 
>> if possible (Valery regarding inclusion of TLS, Tero regarding the 3GPP spec 
>> conformity, and Yoav regarding the magic value) to validate that this draft 
>> is satisfactory to resolve those issues.
>> 
>> Thanks,
>> Tommy
>> 
>> 
>>> On May 6, 2016, at 4:48 PM, Paul Wouters  wrote:
>>> 
>>> On Fri, 6 May 2016, Daniel Migault wrote:
>>> 
 s/IPSec/IPsec
>>> 
>>> If Tommy could also fix that auto-correct for my iphone, that would be
>>> great too :)
>>> 
 "This method is intended to be used as a fallback option when IKE
 cannot be negotiated over UDP."
 This seems to indicates that the method should only be used with IKEv2
 which contradicts the title. Thus I would mention. When used with IKE,
 this method...
>>> 
>>> This has happened in this group a few times now in different documents.
>>> People want to say IKEv2 to exclude IKE, but we should really say IKE
>>> so these documents don't look weird when/if we get IKEv3.
>> 
>> Sure, this can be changed to IKE rather than IKEv2. Whichever the group 
>> thinks makes most sense is fine with me.
>> 
>>> 
 I think that for interoperability, we should define a port at the
 IANA. If that port is 4500 we should detail why an how the two
 encapsulation method works. Are there any disadvantages of using an
 allocated port? One reason reason I suspect port agility may be needed
 is NAT. If so that should be clearly documented.
>>> 
>>> We should not define a port unless it is 443, which we kind of cannot.
>> 
>> Agreed. The most common port in practice will end up being 443; we do have 
>> 4500 allocated if people want to do generic TCP testing, but to get through 
>> NATs and firewalls, we need to often use 443 today. This may change in the 
>> future, so we specifically leave this port option as a configuration 
>> property.
>> 
>> We also specifically don't mention that the extra framing protocol will 
>> likely be TLS until we are in the appendix, due to comments from the group 
>> on inclusion of direct references to TLS in the standard.
>> 
>>> 
 I think that we shoudl specify that ESP SPI MUST be non zero to avoid
 the confusion between ESP SPI and Non-ESP marker.
>>> 
>>> First I thought this was not needed, because RFC-3948 would define that,
>>> but it does look confusing because it is mentioned in the section titled
>>> "UDP-Encapsulated ESP Header format":
>>> 
>>> https://tools.ietf.org/html/rfc3948#section-2.1
>>> 
>>> So the draft should probably include something simiar to that 

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

[Valery Smyslov]

Hi Tommy,

sorry for late reply. I'm mostly OK with the last version of the draft.

Few comments. It is a bit unclear how Stream Prefix is intended
to be used with TLS. Is it insterted at the beginning of the TLS data stream?

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?

Regards,
Valery.


Hi Paul, Daniel,

Thanks for the comments! Responses inline.

I'd like to also hear feedback from people who brought up issues last time if possible (Valery regarding inclusion of 
TLS, Tero regarding the 3GPP spec conformity, and Yoav regarding the magic value) to validate that this draft is 
satisfactory to resolve those issues.


Thanks,
Tommy



On May 6, 2016, at 4:48 PM, Paul Wouters  wrote:

On Fri, 6 May 2016, Daniel Migault wrote:


s/IPSec/IPsec


If Tommy could also fix that auto-correct for my iphone, that would be
great too :)


"This method is intended to be used as a fallback option when IKE
cannot be negotiated over UDP."
This seems to indicates that the method should only be used with IKEv2
which contradicts the title. Thus I would mention. When used with IKE,
this method...


This has happened in this group a few times now in different documents.
People want to say IKEv2 to exclude IKE, but we should really say IKE
so these documents don't look weird when/if we get IKEv3.


Sure, this can be changed to IKE rather than IKEv2. Whichever the group thinks 
makes most sense is fine with me.




I think that for interoperability, we should define a port at the
IANA. If that port is 4500 we should detail why an how the two
encapsulation method works. Are there any disadvantages of using an
allocated port? One reason reason I suspect port agility may be needed
is NAT. If so that should be clearly documented.


We should not define a port unless it is 443, which we kind of cannot.


Agreed. The most common port in practice will end up being 443; we do have 4500 allocated if people want to do generic 
TCP testing, but to get through NATs and firewalls, we need to often use 443 today. This may change in the future, so 
we specifically leave this port option as a configuration property.


We also specifically don't mention that the extra framing protocol will likely be TLS until we are in the appendix, 
due to comments from the group on inclusion of direct references to TLS in the standard.





I think that we shoudl specify that ESP SPI MUST be non zero to avoid
the confusion between ESP SPI and Non-ESP marker.


First I thought this was not needed, because RFC-3948 would define that,
but it does look confusing because it is mentioned in the section titled
"UDP-Encapsulated ESP Header format":

https://tools.ietf.org/html/rfc3948#section-2.1

So the draft should probably include something simiar to that section.


We can add a mention that the ESP SPI must be non-zero to match the other RFCs.




An IANA allocated port could could be such indicaton. In that case,
would we need this prefix ?


We all know SSL VPNs exist because some networks block (4)500 on
purpose.


That's correct.




"""
Any specific IKE SA, along with its Child SAs, is either TCP
encapsulated or not.  A mix of TCP and UDP encapsulation for a single
SA is not allowed.
"""


Note: what it you suddenly notice you can go back to UDP. Wouldn't you
have a mix while you migrate all the TCP-ESP to UDP-ESP?


We can make this section more clear. The main point it was trying to avoid was a technique used in previous drafts or 
protocols that used TCP for IKE in which only long packets would use TCP, and other would use UDP. The idea here is 
that all the IKE and ESP packets should share the same stream, and only switch potentially to use UDP if they do a 
MOBIKE switch. In that case, there could be packets on the wire that are mixed, but there would be a discrete break in 
message IDs.





If I understand this correctly it means:
- a) IKEv2 SA using tcp encapsulation requires ESP to use TCP
encapsulation.
- b) an IKEv2 connection OR an ESP session cannot use TCP
encapsulation or UDP or no encapsulation.
I propose to have something similar to this:
When IKEv2 is using TCP encapsulation, the negotiated ESP SA MUST be
encapsulated with TCP.


It might be best to avoid making any statement on this. For example
libreswan introduced a force-encaps= option to work around Amazon not
routing ESP packets. If you 

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

[Daniel Migault]

Hi Tommy,

Thank you very much for the response. They are addressing all my concerns.

BR,
Daniel

On Mon, May 16, 2016 at 4:15 PM, Tommy Pauly  wrote:

> Hi Paul, Daniel,
>
> Thanks for the comments! Responses inline.
>
> I'd like to also hear feedback from people who brought up issues last time
> if possible (Valery regarding inclusion of TLS, Tero regarding the 3GPP
> spec conformity, and Yoav regarding the magic value) to validate that this
> draft is satisfactory to resolve those issues.
>
> Thanks,
> Tommy
>
>
> > On May 6, 2016, at 4:48 PM, Paul Wouters  wrote:
> >
> > On Fri, 6 May 2016, Daniel Migault wrote:
> >
> >> s/IPSec/IPsec
> >
> > If Tommy could also fix that auto-correct for my iphone, that would be
> > great too :)
> >
> >> "This method is intended to be used as a fallback option when IKE
> >> cannot be negotiated over UDP."
> >> This seems to indicates that the method should only be used with IKEv2
> >> which contradicts the title. Thus I would mention. When used with IKE,
> >> this method...
> >
> > This has happened in this group a few times now in different documents.
> > People want to say IKEv2 to exclude IKE, but we should really say IKE
> > so these documents don't look weird when/if we get IKEv3.
>
> Sure, this can be changed to IKE rather than IKEv2. Whichever the group
> thinks makes most sense is fine with me.
>
> >
> >> I think that for interoperability, we should define a port at the
> >> IANA. If that port is 4500 we should detail why an how the two
> >> encapsulation method works. Are there any disadvantages of using an
> >> allocated port? One reason reason I suspect port agility may be needed
> >> is NAT. If so that should be clearly documented.
> >
> > We should not define a port unless it is 443, which we kind of cannot.
>
> Agreed. The most common port in practice will end up being 443; we do have
> 4500 allocated if people want to do generic TCP testing, but to get through
> NATs and firewalls, we need to often use 443 today. This may change in the
> future, so we specifically leave this port option as a configuration
> property.
>
> We also specifically don't mention that the extra framing protocol will
> likely be TLS until we are in the appendix, due to comments from the group
> on inclusion of direct references to TLS in the standard.
>
> >
> >> I think that we shoudl specify that ESP SPI MUST be non zero to avoid
> >> the confusion between ESP SPI and Non-ESP marker.
> >
> > First I thought this was not needed, because RFC-3948 would define that,
> > but it does look confusing because it is mentioned in the section titled
> > "UDP-Encapsulated ESP Header format":
> >
> > https://tools.ietf.org/html/rfc3948#section-2.1
> >
> > So the draft should probably include something simiar to that section.
>
> We can add a mention that the ESP SPI must be non-zero to match the other
> RFCs.
>
> >
> >> An IANA allocated port could could be such indicaton. In that case,
> >> would we need this prefix ?
> >
> > We all know SSL VPNs exist because some networks block (4)500 on
> > purpose.
>
> That's correct.
>
> >
> >> """
> >> Any specific IKE SA, along with its Child SAs, is either TCP
> >> encapsulated or not.  A mix of TCP and UDP encapsulation for a single
> >> SA is not allowed.
> >> """
> >
> > Note: what it you suddenly notice you can go back to UDP. Wouldn't you
> > have a mix while you migrate all the TCP-ESP to UDP-ESP?
>
> We can make this section more clear. The main point it was trying to avoid
> was a technique used in previous drafts or protocols that used TCP for IKE
> in which only long packets would use TCP, and other would use UDP. The idea
> here is that all the IKE and ESP packets should share the same stream, and
> only switch potentially to use UDP if they do a MOBIKE switch. In that
> case, there could be packets on the wire that are mixed, but there would be
> a discrete break in message IDs.
>
> >
> >> If I understand this correctly it means:
> >> - a) IKEv2 SA using tcp encapsulation requires ESP to use TCP
> >> encapsulation.
> >> - b) an IKEv2 connection OR an ESP session cannot use TCP
> >> encapsulation or UDP or no encapsulation.
> >> I propose to have something similar to this:
> >> When IKEv2 is using TCP encapsulation, the negotiated ESP SA MUST be
> >> encapsulated with TCP.
> >
> > It might be best to avoid making any statement on this. For example
> > libreswan introduced a force-encaps= option to work around Amazon not
> > routing ESP packets. If you mention anything for IKE vs ESP you might
> > add limitations that might cause problems later on. While I think we
> > should have SHOULD language on trying to move TCP sessions to UDP, I
> > wouldn't go as far to forbid certain combinations.
> >
> >> In fact a network may have different firewall rules for IKEv2 and ESP
> >> """
> >>  The original initiator (that is, the endpoint that initiated the TCP
> >> connection and sent the first IKE_SA_INIT 

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

[Tommy Pauly]

Hi Paul, Daniel,

Thanks for the comments! Responses inline.

I'd like to also hear feedback from people who brought up issues last time if 
possible (Valery regarding inclusion of TLS, Tero regarding the 3GPP spec 
conformity, and Yoav regarding the magic value) to validate that this draft is 
satisfactory to resolve those issues.

Thanks,
Tommy


> On May 6, 2016, at 4:48 PM, Paul Wouters  wrote:
> 
> On Fri, 6 May 2016, Daniel Migault wrote:
> 
>> s/IPSec/IPsec
> 
> If Tommy could also fix that auto-correct for my iphone, that would be
> great too :)
> 
>> "This method is intended to be used as a fallback option when IKE
>> cannot be negotiated over UDP."
>> This seems to indicates that the method should only be used with IKEv2
>> which contradicts the title. Thus I would mention. When used with IKE,
>> this method...
> 
> This has happened in this group a few times now in different documents.
> People want to say IKEv2 to exclude IKE, but we should really say IKE
> so these documents don't look weird when/if we get IKEv3.

Sure, this can be changed to IKE rather than IKEv2. Whichever the group thinks 
makes most sense is fine with me.

> 
>> I think that for interoperability, we should define a port at the
>> IANA. If that port is 4500 we should detail why an how the two
>> encapsulation method works. Are there any disadvantages of using an
>> allocated port? One reason reason I suspect port agility may be needed
>> is NAT. If so that should be clearly documented.
> 
> We should not define a port unless it is 443, which we kind of cannot.

Agreed. The most common port in practice will end up being 443; we do have 4500 
allocated if people want to do generic TCP testing, but to get through NATs and 
firewalls, we need to often use 443 today. This may change in the future, so we 
specifically leave this port option as a configuration property.

We also specifically don't mention that the extra framing protocol will likely 
be TLS until we are in the appendix, due to comments from the group on 
inclusion of direct references to TLS in the standard.

> 
>> I think that we shoudl specify that ESP SPI MUST be non zero to avoid
>> the confusion between ESP SPI and Non-ESP marker. 
> 
> First I thought this was not needed, because RFC-3948 would define that,
> but it does look confusing because it is mentioned in the section titled
> "UDP-Encapsulated ESP Header format":
> 
> https://tools.ietf.org/html/rfc3948#section-2.1
> 
> So the draft should probably include something simiar to that section.

We can add a mention that the ESP SPI must be non-zero to match the other RFCs.

> 
>> An IANA allocated port could could be such indicaton. In that case,
>> would we need this prefix ?
> 
> We all know SSL VPNs exist because some networks block (4)500 on
> purpose.

That's correct.

> 
>> """
>> Any specific IKE SA, along with its Child SAs, is either TCP
>> encapsulated or not.  A mix of TCP and UDP encapsulation for a single
>> SA is not allowed.
>> """
> 
> Note: what it you suddenly notice you can go back to UDP. Wouldn't you
> have a mix while you migrate all the TCP-ESP to UDP-ESP?

We can make this section more clear. The main point it was trying to avoid was 
a technique used in previous drafts or protocols that used TCP for IKE in which 
only long packets would use TCP, and other would use UDP. The idea here is that 
all the IKE and ESP packets should share the same stream, and only switch 
potentially to use UDP if they do a MOBIKE switch. In that case, there could be 
packets on the wire that are mixed, but there would be a discrete break in 
message IDs.

> 
>> If I understand this correctly it means:
>> - a) IKEv2 SA using tcp encapsulation requires ESP to use TCP
>> encapsulation.
>> - b) an IKEv2 connection OR an ESP session cannot use TCP
>> encapsulation or UDP or no encapsulation.
>> I propose to have something similar to this:
>> When IKEv2 is using TCP encapsulation, the negotiated ESP SA MUST be
>> encapsulated with TCP.
> 
> It might be best to avoid making any statement on this. For example
> libreswan introduced a force-encaps= option to work around Amazon not
> routing ESP packets. If you mention anything for IKE vs ESP you might
> add limitations that might cause problems later on. While I think we
> should have SHOULD language on trying to move TCP sessions to UDP, I
> wouldn't go as far to forbid certain combinations.
> 
>> In fact a network may have different firewall rules for IKEv2 and ESP
>> """
>>  The original initiator (that is, the endpoint that initiated the TCP
>> connection and sent the first IKE_SA_INIT message) is responsible for
>> reestablishing the TCP connection if it is torn down for any
>> unexpected reason.  Since new TCP connections may use different ports
>> due to NAT mappings or local port allocations changing, the responder
>> MUST allow packets for existing SAs to be received from new source
>> ports.
>> """
>> Section 7:
>> This 

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

[Paul Wouters]

On Fri, 6 May 2016, Daniel Migault wrote:


s/IPSec/IPsec


If Tommy could also fix that auto-correct for my iphone, that would be
great too :)


"This method is intended to be used as a fallback option when IKE
cannot be negotiated over UDP."

This seems to indicates that the method should only be used with IKEv2
which contradicts the title. Thus I would mention. When used with IKE,
this method...


This has happened in this group a few times now in different documents.
People want to say IKEv2 to exclude IKE, but we should really say IKE
so these documents don't look weird when/if we get IKEv3.


I think that for interoperability, we should define a port at the
IANA. If that port is 4500 we should detail why an how the two
encapsulation method works. Are there any disadvantages of using an
allocated port? One reason reason I suspect port agility may be needed
is NAT. If so that should be clearly documented.


We should not define a port unless it is 443, which we kind of cannot.


I think that we shoudl specify that ESP SPI MUST be non zero to avoid
the confusion between ESP SPI and Non-ESP marker. 


First I thought this was not needed, because RFC-3948 would define that,
but it does look confusing because it is mentioned in the section titled
"UDP-Encapsulated ESP Header format":

https://tools.ietf.org/html/rfc3948#section-2.1

So the draft should probably include something simiar to that section.


An IANA allocated port could could be such indicaton. In that case,
would we need this prefix ?


We all know SSL VPNs exist because some networks block (4)500 on
purpose.


"""
Any specific IKE SA, along with its Child SAs, is either TCP
encapsulated or not.  A mix of TCP and UDP encapsulation for a single
SA is not allowed.
"""


Note: what it you suddenly notice you can go back to UDP. Wouldn't you
have a mix while you migrate all the TCP-ESP to UDP-ESP?


If I understand this correctly it means:
    - a) IKEv2 SA using tcp encapsulation requires ESP to use TCP
encapsulation.
    - b) an IKEv2 connection OR an ESP session cannot use TCP
encapsulation or UDP or no encapsulation.

I propose to have something similar to this:

When IKEv2 is using TCP encapsulation, the negotiated ESP SA MUST be
encapsulated with TCP.


It might be best to avoid making any statement on this. For example
libreswan introduced a force-encaps= option to work around Amazon not
routing ESP packets. If you mention anything for IKE vs ESP you might
add limitations that might cause problems later on. While I think we
should have SHOULD language on trying to move TCP sessions to UDP, I
wouldn't go as far to forbid certain combinations.


In fact a network may have different firewall rules for IKEv2 and ESP

"""
 The original initiator (that is, the endpoint that initiated the TCP
connection and sent the first IKE_SA_INIT message) is responsible for
reestablishing the TCP connection if it is torn down for any
unexpected reason.  Since new TCP connections may use different ports
due to NAT mappings or local port allocations changing, the responder
MUST allow packets for existing SAs to be received from new source
ports.
"""

Section 7:

This re-define how NAT_DETECTION is performed over TCP. NAT_DETECTION may 
currently seen as a
UDP_ENCAPSULATION_SUPPORTED notify payload to. This won't be the case anymore 
with IKEv2. Maybe we
should provide more text on this.


well, on UDP it is obvious the port can change and you can just update
the port on the receiver based on the last received udp port. with tcp
clearly you know when it is being shut down. I'm not sure if the
receiver should keep such an orphaned IKE SA while waiting for another
TCP session to come in though. It might make sense of there is a DOS
attack using spoofed RST packets, but the attacker can't be stopped
anyway.

Paul

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

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

[Daniel Migault]

Hi,

I have read the draft. TCP encapsulation is a topic that matters, and I
would like different vendors to implement a standard version of this. I
think the draft is in good shape to be adopted and discussed as a WG
document. I am volunteering to continue reviewing the draft and contribute
to the text once adopted.

Please find here my comments. None of them are controversial and they
should not prevent the adoption of the draft.


BR,
Daniel

abstract:

s/IPSec/IPsec


"This method is intended to be used as a fallback option when IKE
cannot be negotiated over UDP."

This seems to indicates that the method should only be used with IKEv2
which contradicts the title. Thus I would mention. When used with IKE,
this method...


We have to chose IKE or IKEv2. If IKE is chosen, then may specify that
IKE means IKEv2. I have seen IKEV@ in appendix A

section 2:
"""
The configuration defined on each peer should include the following
parameters:

   o  One or more TCP ports on which the responder will listen for
  incoming connections.  Note that the initiator may initiate TCP
  connections to the responder from any local port.

This document leaves the selection of TCP ports up to
   implementations.  It's suggested to use TCP port 4500, which is
   allocated for IPSec NAT Traversal.
"""
I think that for interoperability, we should define a port at the
IANA. If that port is 4500 we should detail why an how the two
encapsulation method works. Are there any disadvantages of using an
allocated port? One reason reason I suspect port agility may be needed
is NAT. If so that should be clearly documented.


"""
Optionally, an extra framing protocol to use on top of TCP to
  further encapsulate the stream of IKEv2 and IPSec packets.  See
  Appendix A for a detailed discussion.
"""

If I am correct the extra framing is TLS. If so I think it woudl be
clearer to mention extra framing such as TLS.


section 3.2
I think that we shoudl specify that ESP SPI MUST be non zero to avoid
the confusion between ESP SPI and Non-ESP marker.

section 4:

My understanding is that the stream prefix is needed if because tcp
does not have a mechanism that indicates the content of the streams.
An IANA allocated port could could be such indicaton. In that case,
would we need this prefix ?



section 5:

"""
Any specific IKE SA, along with its Child SAs, is either TCP
encapsulated or not.  A mix of TCP and UDP encapsulation for a single
SA is not allowed.
"""

If I understand this correctly it means:
- a) IKEv2 SA using tcp encapsulation requires ESP to use TCP
encapsulation.
- b) an IKEv2 connection OR an ESP session cannot use TCP
encapsulation or UDP or no encapsulation.

I propose to have something similar to this:

When IKEv2 is using TCP encapsulation, the negotiated ESP SA MUST be
encapsulated with TCP.
In fact a network may have different firewall rules for IKEv2 and ESP
traffic. IKEv2 is an application identified with specific ports
whereas ESP packets do not have ports.If the IKEv2 traffic and ESP
were not using the same encapsulation method (non encapsulation, UDP
encapsulation or TCP encapsulation), then IKEv2 would not be able to
proceed to reachability tests of the ESP path, as IKEv2 and ESP would
use different paths. In addition, IKEv2 would be expected to negotiate
the ESP encapsulation between the peers.

With UDP and TCP encapsulation, IKEv2 and ESP packet use the same port
and transport protocol, which means that IKEv2 proceeds to the
connectivity tests and set the tunnel. In the case non-encapsulated
IKEv2 are not blocked, but that ESP packets are blocked, it is the
responsibility of the IKEv2 client to DELETE the IKE_SA on both peers
and than renegotiate the IKEv2 exchange using UDP and then TCP
encapsulation.


If IKEv2 peers are using TCP encapsulation, and both peer support UDP
encapsulation as well as MOBIKE, then it can switch from TCP to UDP
encapsulation for both IKEv2 and ESP traffic by using MOBIKE. The peer
can advertise their respective support with MOBIKE_SUPPORTED and
NAT_DETECTION_*_IP Notify Payloads. When one of the IKEv2 peer
decides to switch from TCP to UDP encapsulation, all IKEv2 and ESP
traffic is switched from TCP to UDP. Note that the other way around is
not possible as IKEv2 does not advertise its support for TCP encapsulation.

[note that using NAT_DETECTION_*_IP as an UDP_ENCAPSULATION_SUPPORTED  only
works when not encapsulated with UDP/TCP]


section 6:

Because of this text, I think it would be good to have a TCP
encapsulation and TCP decapsulation sections that describes TCP and

IPsec interactions.


"""
 The original initiator (that is, the endpoint that initiated the TCP
connection and sent the first IKE_SA_INIT message) is responsible for
reestablishing the TCP connection if it is torn down for any
unexpected reason.  Since new TCP connections may use different ports
due to NAT mappings or local port allocations changing, the responder
MUST allow packets for