Reminder...
On Dec 26, 2010, at 11:38 AM, Yoav Nir wrote:
> 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
