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.
Definitely you can do it. It's a usual tradeoff between wasting
resources doing frequent liveness checks and wasting memory
for the dead connection. Choose right balance.
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.
Sure. The problem is that with TCP encapsulation the other end may have
no TCP session and would have been unable to send any traffic (including
liveness checks) until this end (the original initiator) restores TCP seesion.
Valery.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
