Subject: Re: [IPsec] Failure Detection - Issue #200

From: Yoav Nir <[email-masked]>
Date: Mon, 3 Jan 2011 17:51:45 +0200

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).

---

From: Scott C Moonen <[email-masked]>
Date: Tue, 4 Jan 2011 10:43:38 -0500

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-masked])
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen

From:	Yoav Nir <[email-masked]>
To:	"[email-masked]" <[email-masked]>
Date:	01/03/2011 10:52 AM
Subject:	Re: [IPsec] Failure Detection - Issue #200
Sent by:	[email-masked]

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.
>   case where liveness check has not yet ended (or begun).

_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 05 Jan 2011 19:00:05 -0800

I am closing this open issue. Yaron: please use your proposed text.

Failure detection authors: please have a new draft ready by Monday and 
close out all the resolved issues on the issue tracker. I think we are 
getting ready for a WG Last Call.

--Paul Hoffman, Director
--VPN Consortium