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
