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 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 
> <https://www.ietf.org/mailman/listinfo/ipsec>
> 
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org <mailto:IPsec@ietf.org>
> https://www.ietf.org/mailman/listinfo/ipsec 
> <https://www.ietf.org/mailman/listinfo/ipsec>
>  
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org <mailto:IPsec@ietf.org>
> https://www.ietf.org/mailman/listinfo/ipsec 
> <https://www.ietf.org/mailman/listinfo/ipsec>
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to