Hi all.
Issue #200 is about some text in section 8 ("Interaction with Session
Resumption"). The text says that a rebooted peer (and thus a defunct SA) may go
undetected for the lifetime of the SA. However, RFC 5996 says that at some
point, a peer that did not receive incoming traffic on a particular IKE SA or
its children, has to initiate a liveness check.
Here's how I propose to resolve this. Seeing as it's the holiday season, I
won't close the issue until January 10th, but please get your comments in by
then.
Existing text:
What Session Resumption does not help is the problem of detecting
that the peer gateway has failed. A failed gateway may go undetected
for as long as the lifetime of a child SA, because IPsec does not
have packet acknowledgement, and applications cannot signal the IPsec
layer that the tunnel "does not work". Before establishing a new IKE
SA using Session Resumption, a client should ascertain that the
gateway has indeed failed. This could be done using either a
liveness check (as in RFC 5996) or using the QCD tokens described in
this document.
My proposed text:
What Session Resumption does not help is the problem of detecting
that the peer gateway has failed. A failed gateway may go undetected
for an arbitrarily long time, because IPsec does not have packet
acknowledgement, and applications cannot signal the IPsec layer that
the tunnel "does not work". Section 2.4 of RFC 5996 does not specify
how long an implementation needs to wait before beginning a liveness
check, and only says "not recently" (see full quote in Section 2).
In practice some mobile devices wait a very long time before
beginning liveness check, in order to extend battery life by allowing
parts of the device to remain in low-power modes.
QCD tokens provide a way to detect the failure of the peer in the
case where liveness check has not yet ended (or begun).
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
