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] 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 https://www.ietf.org/mailman/listinfo/ipsec
