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

From: "Hu, Jun (Nokia - US)" <[email-masked]>
Date: Fri, 7 Oct 2016 21:09:06 +0000

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:[email-masked]] 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.
>

---

From: "Hu, Jun (Nokia - US)" <[email-masked]>
Date: Tue, 11 Oct 2016 22:00:06 +0000

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?

> From: IPsec [mailto:[email-masked]] 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
> 
> > > In this case the responder will have two TCP sessions associated
> > > with the IKE SA. Clearly, the new one should be used for further
> > 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tommy Pauly <[email-masked]>
Date: Tue, 11 Oct 2016 17:34:39 -0700

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) <[email-masked]> wrote:
>

---

From: "Hu, Jun (Nokia - US)" <[email-masked]>
Date: Wed, 12 Oct 2016 03:42:55 +0000

>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: [email-masked] [mailto:[email-masked]]
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:

Thanks,

Tommy

On Oct 11, 2016, at 3:00 PM, Hu, Jun (Nokia - US) <[email-masked]<mailto:[email-masked]>> wrote:

-----Original Message-----
From: IPsec [mailto:[email-masked]] 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

-----Original Message-----

protected message is received over it). But what the responder
should do

_______________________________________________
IPsec mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ipsec

_______________________________________________
IPsec mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tommy Pauly <[email-masked]>
Date: Mon, 17 Oct 2016 09:29:54 -0700

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) <[email-masked]> wrote:
> 
> On Oct 11, 2016, at 3:00 PM, Hu, Jun (Nokia - US) <[email-masked] <mailto:[email-masked]>> wrote:
>  
> From: IPsec [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Hu, Jun (Nokia - US)
> From: IPsec [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Tommy Pauly
> ...
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ipsec <https://www.ietf.org/mailman/listinfo/ipsec>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ipsec <https://www.ietf.org/mailman/listinfo/ipsec>
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ipsec <https://www.ietf.org/mailman/listinfo/ipsec>