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