Paul Wouters writes: > > 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. > > That I disagree with. I want to cleanup roadwarriors who have left at > some point, which means a liveness probe without me having traffic > pending for them.
Why? Doing liveness probe is much more expensive operation than keeping IKE SA and Child SAs in memory. If the connection is silent, there is no traffic thus there is no cost unless you run out of memory. When you are starting to run out of memory you can do liveness checks to clear out dead connections. You can also just set the rekey interval to be 3600 seconds or something, and then that rekey will do "liveness" check for you :-) > > 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? > > I guess it assumes the other end acts the same, so if any endpoint wants > to send, they will do liveness. Of course both ends acts the same. This text is not tied to any one end. > But I agree the RFC text could be better. I think the current text is fine. It could also say that "you MUST NOT do periodic liveness checks", but I assume some people would have objected to that, just because that would made their implementations non-conforming... -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
