Valery Smyslov writes: > > There is stupid implementations out there which do send liveness > > checks every n seconds regardless of anything else, but those are just > > bad implementations. > > My point was that with TCP encapsulation this "stupid" behaviour > wil probably become the "standard" one. Otherwise there is > a chance running into the situation when the original responder loses > TCP session (e.g. RST from an attacker), while the original Initiator > thinks the TCP session is still up. In this case if the Initiator > has nothing to send to the responder, it will remain silent, > while the responder will be unable to use the SAs. > The situation will last until the initiator sends something to the responder: > the responder sends back RST (as it doesn't have this TCP session) > and then the initiator creates a new TCP session.
This is exactly what happens when you using NAT-T in normal case too. I.e. if the responder looses state, it cannot do anything until initiator reconnects. Btw, if you have integrated TCP encapsulated IPsec you can also act on the TCP RST by trying to do liveness check inside the TCP. If that fails then you tear down the TCP session, if it works, then you simply ignore the RST, as it was clearly an attack as other end is still has TCP session up and running. This of course requires kernel to know which TCP sessions are used for the IPsec, and instead of tearing the TCP sessions down they need to indicate the RST to the IPsec so IPsec can check things before telling whether the TCP session needs to be taken down. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
