Valery Smyslov writes: > I don't care about applications, I care about IPsec implementations :-) > Currently an IPsec implementation can always send out a ESP packet > if ESP SA is up. With TCP encapsulation there may be situations > when ESP SA is up, however the encrypted packet cannot be > send out because there is no TCP session associated with this > ESP SA. What IPsec implementation is supposed to do with the data > that TCP/IP stack is trying to send out? Discard? Collect in a hope > that TCP is restored quickly?
Most likely the smart thing is to drop it immediately. It is exactly same thing than when your ESP packets do not go through as network is broken somewhere in the middle. There is no point of queuing them up, as upper layer protocols will retransmit those packets and then the queue will fill up with retransmissions etc, and the upper layer protocols are expecting more about dropped packets, than packets delayed by tens of seconds. > > However, NAT gateways do time out TCP connections, so if the IPsec SA is > > genuinely idle, we might need to send something to keep it alive. But > > then sending a liveness probe is fine for that. > > Are you saying that if I open telnet session via NAT and then > go for dinner, that the session will be broken when I return? Yes. Just last week I was in some meeting room network, which teared down my ssh connections every few minutes. I kept hitting enter on my shell windows every now and then, and usually some of them got disconnected. The stupid NAT box didn't even send RST, thus my connections just hang for several minutes waiting for the TCP timeouts. As this didn't seem to be consistent with activity, i.e it could happen even when I was using the connection, we assumed the NAT box was running out of memory or something and cleaning up TCP connections at random... > Well, I agree that NAT and firewalls can drop any TCP session > at their will, but do they do it regularly in case of timeout? > And what is the typical timeout timeout for TCP? If the NAT boxes have timeout for TCP sessions it is quite long (minutes, tens of minutes, or hours), but if they run out of memory they can clear state quite quickly. > >> Note, that it is a bit different from how liveness check messages are > >> supposed > >> to be used in IKEv2, where liveness check should be done if there is no > >> incoming > >> traffic for some period of time AND if the endpoint is about to send new > >> data > >> to the peer. > > > > That's not my understanding of livenss. What we do is time based > > liveness probes that are skipped when we detected there was recent > > traffic on the IPsec SA. There is no point of sending periodic liveness checks ever. Liveness checks are supposed to be used when you suspect that other end is no longer alive, and if you get reply back you do know it is alive. > RFC7296 is not very explicit about that. Please see RFC3706 (DPD) > Section 5.5, that contains more speculations on this: > > Since the liveliness of a peer is only questionable when no traffic > is exchanged, a viable implementation might begin by monitoring > idleness. Along these lines, a peer's liveliness is only important > when there is outbound traffic to be sent. To this end, an > implementation can initiate a DPD exchange (i.e., send an R-U-THERE > message) when there has been some period of idleness, followed by the > desire to send outbound traffic. > > Compare with RFC7296, Section 2.4: > > 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. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
