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 protected]> 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: [email protected] [mailto:[email protected]] > 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) <[email protected] > <mailto:[email protected]>> 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:[email protected] <mailto:[email protected]>] > 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:[email protected] <mailto:[email protected]>] > 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 > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/ipsec > <https://www.ietf.org/mailman/listinfo/ipsec> > > _______________________________________________ > IPsec mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/ipsec > <https://www.ietf.org/mailman/listinfo/ipsec> > > _______________________________________________ > IPsec mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/ipsec > <https://www.ietf.org/mailman/listinfo/ipsec>
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
