Yoav, I am ok with your suggested change. Side comment: in my reading of RFC 5996 I think we could still say "as long as the lifetime of a child SA." I read the RFC as requiring liveness checking only in the case where we have sent but not received traffic. (In other words, I think the sentences "If there has only been ..." and "If no cryptographically protected ..." are related, with the second being subordinate to the first.)
Scott Moonen ([email protected]) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Yoav Nir <[email protected]> To: "[email protected]" <[email protected]> Date: 01/03/2011 10:52 AM Subject: Re: [IPsec] Failure Detection - Issue #200 Sent by: [email protected] 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
<<inline: graycol.gif>>
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
