Hi Tero,
If no
cryptographically protected messages have been received on an IKE SA
or any of its Child SAs recently, the system needs to perform a
liveness check in order to prevent sending messages to a dead peer.
Here - if you don't want to send message to a peer, you don't care if
it is dead, do you?
Yes.
The idea is that you want to avoid black hole, i.e. you are sending
stuff, and other end is dropping it because state got cleared from the
other end.
I.e. you are supposed to do liveness check when you for example
receive some kind of ICMP which would indicate that other end might be
down (for example port unreachable, host unreachable etc).
Also other end is sending traffic to you and you are sending traffic
to him, but then suddenly the other end stops sending traffic to you,
i.e. the traffic pattern changed to be unidirectional. This could of
course be because traffic changed, but it could indicate there is
problem. So when you detect that (i.e. you are sending traffic, but
other end is not sending any cryptographically protected messages),
you do liveness check. If the other end respondes you know it is
alive, and traffic pattern simply changed. If the traffic pattern
stays one way for longer time, you might repeat the liveness check at
some point, as otherwise you do not detect whether the other end died
or not.
In normal case one way traffic patters are not very common, so you
always have traffic coming back (ACKs etc).
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.
Regards,
Valery.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
