Subject: [IPsec] Failure detection proposals

From: Yaron Sheffer <[email-masked]>
Date: Wed, 04 Aug 2010 23:40:21 +0300

In the Maastricht meeting there was just a tiny bit of interest in the 
failure detection idea (reminder: the goal is to ensure that one peer 
discovers that the other IKE peer has restarted, within a short time 
duration, milliseconds instead of minutes). But we didn't see enough 
interest to justify having this as a WG item. So, one last time: if you 
think this is a worthwhile idea, regardless of the proposals on the 
table, please say so publicly. If you speak up, we will expect you to 
contribute to the selection of the preferred document.

If this is of no interest, fine. But if it is an important problem to 
solve and we don't take it on, we could end up with competing non-WG 
proposals. Which would be far from ideal.

Thanks,
	Yaron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf 
Of Paul Hoffman
Sent: Wednesday, July 07, 2010 8:03 PM
To: IPsecme WG
Subject: [IPsec] NUDGE: Starting discussion of failure detection proposals

[[ This topic generated a fair amount of discussion in the past; are 
folks still interested? ]]

Greetings again. The WG has one item on our charter that we have barely 
discussed, namely failure detection. The charter item says that the work 
item is:

>- A standards-track IKEv2 extension that allows an IKE peer to quickly and securely detect that its opposite peer, while currently reachable, has lost its IKEv2/IPsec state. Changes to how the peers recover from this situation are beyond the scope of this work item, as is improving the detection of an unreachable or dead peer. Ideas from draft-nir-ike-qcd-05 and draft-detienne-ikev2-recovery-03 can be used as starting points.

I gave a brief presentation on failure detection at the last IETF 
meeting in Anaheim. The slides are at 
<http://www.ietf.org/proceedings/77/slides/ipsecme-4.pdf>, and the 
following is directly derived from them.

The basic problem being covered by the new extension is:
-  Alice and Bob have SAs up and ESP traffic is flowing, but then Bob 
crashes
-  Alice keeps sending ESP to Bob
-  When Bob finally comes back up, he replies to Alice's ESP with 
INVALID_SPI notifications
-  Alice starts sending IKE liveness checks until she is "sure" that the 
INVALID_SPI responses are not a DoS attack; this could be "several minutes"
-  Then Alice rekeys

Some other problem cases include:
-  Bob has two gateways in some failover architecture. One gateway goes 
down, the other gateway detects this and wants to tell Alice to rekey
-  Bob has a bunch of gateways in some load-balancing or cluster 
architecture. One gateway is taken down on purpose, and the system wants 
to tell Alice to rekey
-  Protocol robustness:  Bob's gateway loses the SA without going down

Our primary goal is that, as soon as Bob starts sending INVALID_SPI 
responses to Alice's ESP traffic, Bob and Alice should be able to 
quickly determine that this is not an attack and therefore they probably 
want to rekey right away. Note that if Bob and Alice are also using 
session resumption, they can use that instead of rekeying; however, in 
the discussion here, we always use "rekey" to mean "rekey or, if 
appropriate, resume". The proposed extension does not include the actual 
rekeying, just the context for them to do it now.

The WG has seen two proposed solutions, QCD and SIR. The following are 
brief summaries of the two proposals.

In QCD (<http://tools.ietf.org/html/draft-nir-ike-qcd>), Bob gives Alice 
a secret token in the AUTH exchange, and then puts the token in his 
INVALID_SPI response as a way to say "this SPI is gone". Bob must 
remember his tokens across reboots, or derive tokens from a master token 
that he memorizes across reboots, and Alice must remember the token (or 
a hash of it) for each SA.

In SIR 
(<http://tools.ietf.org/id/draft-detienne-ikev2-recovery-03.txt>), Alice 
sends a new Check_SPI query with a stateless cookie, essentially asking 
"do you really not know about this
SPI?"; Bob responds by saying "I'm sure I don't know that SPI". Nothing 
is stored on either side, so a man-in-the-middle can attack this to 
cause an unnecessary rekey just as they can normal IKE.

The first task for the WG is to decide which of these two quite 
different approaches to take. After we have done that, we can then hone 
the chosen proposal. During earlier discussion of the proposals, the 
following criteria were mentioned as ones that the WG should consider 
when thinking about the approaches:

-  Support for different scenarios (load balancers, active clusters, 
failover)
-  Security from man-in-the-middle DoS attacks
-  Resources used
-  Intellectual property rights

So: please start discussing the two proposals with respect to these 
criteria or other criteria that are important to you. In a few weeks 
(hopefully well before the Maastricht meeting), I make a call for 
consensus and see where it leads us.

--Paul Hoffman, Director
--VPN Consortium

---

From: Scott C Moonen <[email-masked]>
Date: Thu, 5 Aug 2010 09:28:26 -0400

I think this is an important problem to solve and I'm willing to
participate in discussion of the alternatives,

Scott Moonen ([email-masked])
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen

From:	Yaron Sheffer <[email-masked]>
To:	IPsecme WG <[email-masked]>
Date:	08/04/2010 04:48 PM
Subject:	[IPsec] Failure detection proposals
Sent by:	[email-masked]

Thanks,
		 Yaron

-----Original Message-----

item is:

>- A standards-track IKEv2 extension that allows an IKE peer to quickly and
securely detect that its opposite peer, while currently reachable, has lost
its IKEv2/IPsec state. Changes to how the peers recover from this situation
are beyond the scope of this work item, as is improving the detection of an
unreachable or dead peer. Ideas from draft-nir-ike-qcd-05 and
draft-detienne-ikev2-recovery-03 can be used as starting points.

In SIR

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Thu, 5 Aug 2010 23:19:22 +0300

> contribute to the selection of the preferred document.

I think it comes as no surprise that I think it's a worthwhile idea, and that I am willing to contribute to the selection. The idea for this came to me not out of idle analysis of the IKEv2 RFC, but from a bug report from my company's QA department ("it takes 2 minutes for the tunnel to come back up after we clear the SAs")

> proposals. Which would be far from ideal.

We are already there with competing non-WG proposals. I think it is the IPsecME working group that should decide between them. The alternative to the working group deciding this is to dump this in the AD's lap, which IMHO is worse.

---

From: V Jyothi-B22245 <[email-masked]>
Date: Fri, 6 Aug 2010 11:49:21 +0530

Hi,
 
I am interested to work on this issue.
 
thanks
jyothi

________________________________

From: [email-masked] on behalf of Yaron Sheffer
Sent: Thu 8/5/2010 2:10 AM
To: IPsecme WG
Subject: [IPsec] Failure detection proposals

Thanks,
        Yaron

-----Original Message-----

In SIR

--Paul Hoffman, Director
--VPN Consortium

---

From: "Palanivelan A (apvelan)" <[email-masked]>
Date: Fri, 6 Aug 2010 12:16:53 +0530

Hi There,

This looks interesting and I will also be happy to contribute there.

I do have a draft on BFD that is in the final stages of ISR-review. I
currently  work more on the security stuff and I guess, I can contribute
here.

Regards,

A.Palanivelan

From: [email-masked] [mailto:[email-masked]] On Behalf
Of V Jyothi-B22245
Sent: Friday, August 06, 2010 11:49 AM
To: Yaron Sheffer; IPsecme WG
Subject: Re: [IPsec] Failure detection proposals

Hi,

thanks

jyothi

Thanks,
        Yaron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Paul Hoffman
Sent: Wednesday, July 07, 2010 8:03 PM
To: IPsecme WG
Subject: [IPsec] NUDGE: Starting discussion of failure detection
proposals

item is:

>- A standards-track IKEv2 extension that allows an IKE peer to quickly
and securely detect that its opposite peer, while currently reachable,
has lost its IKEv2/IPsec state. Changes to how the peers recover from
this situation are beyond the scope of this work item, as is improving
the detection of an unreachable or dead peer. Ideas from
draft-nir-ike-qcd-05 and draft-detienne-ikev2-recovery-03 can be used as
starting points.

INVALID_SPI responses are not a DoS attack; this could be "several
minutes"
-  Then Alice rekeys

In SIR

--Paul Hoffman, Director
--VPN Consortium

---

From: Dacheng Zhang <[email-masked]>
Date: Mon, 09 Aug 2010 10:16:27 +0800

As other experts said, this is an interesting issue and worth us spending
efforts on it. I would like to join this work.

> 
> In the Maastricht meeting there was just a tiny bit of 
> interest in the failure detection idea (reminder: the goal is 
> to ensure that one peer discovers that the other IKE peer has 
> restarted, within a short time duration, milliseconds instead 
> of minutes). But we didn't see enough interest to justify 
> having this as a WG item. So, one last time: if you think 
> this is a worthwhile idea, regardless of the proposals on the 
> table, please say so publicly. If you speak up, we will 
> expect you to contribute to the selection of the preferred document.
> 
> If this is of no interest, fine. But if it is an important 
> problem to solve and we don't take it on, we could end up 
> with competing non-WG proposals. Which would be far from ideal.
> 
> Thanks,
> 	Yaron
> 
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Paul Hoffman
> [[ This topic generated a fair amount of discussion in the 
> past; are folks still interested? ]]
> 
> Greetings again. The WG has one item on our charter that we 
> have barely discussed, namely failure detection. The charter 
> item says that the work item is:
> 
> >- A standards-track IKEv2 extension that allows an IKE peer 
> to quickly and securely detect that its opposite peer, while 
> currently reachable, has lost its IKEv2/IPsec state. Changes 
> to how the peers recover from this situation are beyond the 
> scope of this work item, as is improving the detection of an 
> I gave a brief presentation on failure detection at the last 
> IETF meeting in Anaheim. The slides are at 
> <http://www.ietf.org/proceedings/77/slides/ipsecme-4.pdf>, 
> and the following is directly derived from them.
> 
> -  Alice and Bob have SAs up and ESP traffic is flowing, but 
> then Bob crashes
> -  When Bob finally comes back up, he replies to Alice's ESP 
> with INVALID_SPI notifications
> -  Alice starts sending IKE liveness checks until she is 
> "sure" that the INVALID_SPI responses are not a DoS attack; 
> this could be "several minutes"
> -  Then Alice rekeys
> 
> -  Bob has two gateways in some failover architecture. One 
> gateway goes down, the other gateway detects this and wants 
> to tell Alice to rekey
> -  Bob has a bunch of gateways in some load-balancing or 
> cluster architecture. One gateway is taken down on purpose, 
> and the system wants to tell Alice to rekey
> Our primary goal is that, as soon as Bob starts sending 
> INVALID_SPI responses to Alice's ESP traffic, Bob and Alice 
> should be able to quickly determine that this is not an 
> attack and therefore they probably want to rekey right away. 
> Note that if Bob and Alice are also using session resumption, 
> they can use that instead of rekeying; however, in the 
> discussion here, we always use "rekey" to mean "rekey or, if 
> appropriate, resume". The proposed extension does not include 
> the actual rekeying, just the context for them to do it now.
> 
> The WG has seen two proposed solutions, QCD and SIR. The 
> following are brief summaries of the two proposals.
> 
> In QCD (<http://tools.ietf.org/html/draft-nir-ike-qcd>), Bob 
> gives Alice a secret token in the AUTH exchange, and then 
> puts the token in his INVALID_SPI response as a way to say 
> "this SPI is gone". Bob must remember his tokens across 
> reboots, or derive tokens from a master token that he 
> memorizes across reboots, and Alice must remember the token 
> (or a hash of it) for each SA.
> 
> In SIR
> (<http://tools.ietf.org/id/draft-detienne-ikev2-recovery-03.tx
> t>), Alice sends a new Check_SPI query with a stateless 
> cookie, essentially asking "do you really not know about this 
> SPI?"; Bob responds by saying "I'm sure I don't know that 
> SPI". Nothing is stored on either side, so a 
> man-in-the-middle can attack this to cause an unnecessary 
> rekey just as they can normal IKE.
> 
> The first task for the WG is to decide which of these two 
> quite different approaches to take. After we have done that, 
> we can then hone the chosen proposal. During earlier 
> discussion of the proposals, the following criteria were 
> mentioned as ones that the WG should consider when thinking 
> about the approaches:
> 
> So: please start discussing the two proposals with respect to 
> these criteria or other criteria that are important to you. 
> In a few weeks (hopefully well before the Maastricht 
> meeting), I make a call for consensus and see where it leads us.
> 
> --Paul Hoffman, Director
> --VPN Consortium

---

From: David Wierbowski <[email-masked]>
Date: Mon, 9 Aug 2010 09:13:45 -0400

I agree with Scott and I am also willing to participate in discussion of
the alternatives.

Dave Wierbowski

From:       Scott C Moonen/Raleigh/IBM@IBMUS
To:         Yaron Sheffer <[email-masked]>
Cc:         IPsecme WG <[email-masked]>, [email-masked]
Date:       08/05/2010 09:33 AM
Subject:    Re: [IPsec] Failure detection proposals
Sent by:    [email-masked]

(Embedded image moved to file: pic03142.gif)Inactive hide details for Yaron
Sheffer ---08/04/2010 04:48:45 PM---In the Maastricht meeting there was
just a tiny bit of inteYaron Sheffer ---08/04/2010 04:48:45 PM---In the
Maastricht meeting there was just a tiny bit of interest in the failure
detection idea (remi

Thanks,
Yaron

-----Original Message-----

In SIR

--Paul Hoffman, Director
--VPN Consortium

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 10 Aug 2010 13:19:51 +0300

OK, Paul and I are finally convinced that we have sufficient WG interest 
in solving this problem. Now, I'd like to ask the people who have 
responded (as well as others) to read the two drafts, and to tell us why 
they prefer the one over the other.

Quoting myself: "If you speak up, we will expect you to contribute to 
the selection of the preferred document".

Please respond with comments to the drafts and/or a comparison within 
the next week, i.e. by August 17.

Thanks,
	Yaron

> From: Yaron Sheffer<[email-masked]>
> To: IPsecme WG<[email-masked]>

---

From: Scott C Moonen <[email-masked]>
Date: Fri, 13 Aug 2010 15:07:03 -0400

I've looked over the two drafts.  My summary impression is that I prefer
QCD, albeit for subjective reasons.  It is less complicated and therefore
simpler to implement and test.  I think I would have a higher degree of
confidence in planning it for our implementation, and I suspect it would
see more quick and widespread use.

Some comments/questions for the individual drafts:

QCD:
(1) Why can't the N(QCD_TOKEN) appear in the CREATE_CHILD_SA request
message for rekeying the IKE SA?
(2) The draft (perhaps in the section 5 intro) should emphasize that the
tokens MUST be produced in such a way that different IKE SPI pairs are
unlikely to share the same token value.

Recovery:
(1) The draft needs to specify how the IKE message header bits are expected
to be set for the various flows.
(2) The draft should explicitly acknowledge cases where it is (with good
reason) breaking specific MUST NOT statements in ikev2bis (e.g., a couple
of cases of "MUST NOT respond").
(3) I dislike the MITM weakness but I understand that this is not the most
attractive fruit for a MITM.
(4) Nit: acronym plurals shouldn't use apostrophes (i.e., "SAs" is
preferred to "SA's").

From:	Yaron Sheffer <[email-masked]>
To:	IPsecme WG <[email-masked]>
Date:	08/10/2010 06:20 AM
Subject:	[IPsec] Failure detection proposals, stage 2
Sent by:	[email-masked]

Thanks,
		 Yaron

proposals
>> - A standards-track IKEv2 extension that allows an IKE peer to quickly
and
minutes"

---

From: Yoav Nir <[email-masked]>
Date: Fri, 13 Aug 2010 22:29:34 +0300

On Aug 13, 2010, at 10:07 PM, Scott C Moonen wrote:

> I've looked over the two drafts. My summary impression is that I prefer QCD, albeit for subjective reasons. It is less complicated and therefore simpler to implement and test. I think I would have a higher degree of confidence in planning it for our implementation, and I suspect it would see more quick and widespread use.
> 
> (1) Why can't the N(QCD_TOKEN) appear in the CREATE_CHILD_SA request message for rekeying the IKE SA?
> 
The QCD token depends on the IKE SPIs. The Initiator SPI is sent in the request, but the Responder SPI is sent in the response. Because of this, the Initiator cannot calculate the QCD token when sending the rekey request. The responder, however, has both IKE SPIs, and is able to send the QCD token in the CREATE_CHILD_SA response.

> (2) The draft (perhaps in the section 5 intro) should emphasize that the tokens MUST be produced in such a way that different IKE SPI pairs are unlikely to share the same token value.
> 

I can add a bullet point there saying something like "The method of token generation MUST be such, that a collision of QCD tokens between different pairs of IKE SPI will be highly unlikely." Is that satisfactory?

I will leave it to others to answer for SIR.

---

From: Scott C Moonen <[email-masked]>
Date: Fri, 13 Aug 2010 15:37:49 -0400

Yoav,

> The QCD token depends on the IKE SPIs. The Initiator SPI is sent in the
> request, but the Responder SPI is sent in the response. Because of this,
> the Initiator cannot calculate the QCD token when sending the rekey
request.
> The responder, however, has both IKE SPIs, and is able to send the QCD
token
> in the CREATE_CHILD_SA response.

Aah, right, that makes sense.

> I can add a bullet point there saying something like "The method of token
> generation MUST be such, that a collision of QCD tokens between different
> pairs of IKE SPI will be highly unlikely." Is that satisfactory?

Yes, thanks!

From:	Yoav Nir <[email-masked]>
To:	Scott C Moonen/Raleigh/IBM@IBMUS
Cc:	Yaron Sheffer <[email-masked]>, IPsecme WG
            <[email-masked]>, "[email-masked]"
            <[email-masked]>
Date:	08/13/2010 03:34 PM
Subject:	Re: [IPsec] Failure detection proposals, stage 2

The QCD token depends on the IKE SPIs. The Initiator SPI is sent in the
request, but the Responder SPI is sent in the response. Because of this,
the Initiator cannot calculate the QCD token when sending the rekey
request. The responder, however, has both IKE SPIs, and is able to send the
QCD token in the CREATE_CHILD_SA response.

I can add a bullet point there saying something like "The method of token
generation MUST be such, that a collision of QCD tokens between different
pairs of IKE SPI will be highly unlikely." Is that satisfactory?

---

From: David Wierbowski <[email-masked]>
Date: Sun, 15 Aug 2010 23:21:07 -0400

I also prefer  the QCD draft over the SIR draft.  My reasons are similar to
Scott's.  I feel the method in QCD is sufficient and the SIR method is
overly complex for the problem at hand.  I think SIR would be bigger to
implement and more error prone than QCD.  In short I think the SIR method
is a much bigger stick than needed.

Dave Wierbowski

z/OS Comm Server Developer

 Phone:
    Tie line:   620-4055
    External:  607-429-4055

Date:       08/13/2010 03:10 PM

QCD:

Recovery:

(Embedded image moved to file: pic56651.gif)Inactive hide details for Yaron
Sheffer ---08/10/2010 06:20:17 AM---OK, Paul and I are finally convinced
that we have sufficienYaron Sheffer ---08/10/2010 06:20:17 AM---OK, Paul
and I are finally convinced that we have sufficient WG interest in solving
this problem. N

Thanks,
Yaron

proposals
and
minutes"

---

From: "Palanivelan A (apvelan)" <[email-masked]>
Date: Mon, 16 Aug 2010 10:37:03 +0530

Hi,

I had a look at both the documents and here are my thoughts.

I support QCD to be taken forward of the two.

Both these documents have good thoughts in addressing the issue, but
also have gaps in terms of security. Both these designs are prone to
security attacks and going by the proposed solutions, the QCD seems the
better of the two.

Some effort into Liveness detection mechanism , the method of generating
secured QCD token and managing the token in an optimized manner are some
of the items that can be worked on from the QCD draft. I think, Fixing
these items would  lead to a more secured and acceptable solution and I
will be more than happy to work with the team on these items.

Thanks and Regards,
A.Palanivelan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Yaron Sheffer
Sent: Tuesday, August 10, 2010 3:50 PM
To: IPsecme WG
Subject: [IPsec] Failure detection proposals, stage 2

Thanks,
	Yaron

proposals
minutes"

---

From: Dacheng Zhang <[email-masked]>
Date: Mon, 16 Aug 2010 18:31:58 +0800

Hi, 

I think both solutions are very interesting. But after carefully
consideration, I prefer to support QCD. 

Firstly, compared to SIR, the QCD solution is simpler. It can use fewer
packets to achieve the objective, because a peer can verify the token
directly after receiving an INVALID_SPI packet.

Secondly, in SIR, a peer has to wait for a certain period to ensure that it
did not get a CHECK_SPI (NACK) packet from an attacker. This solution seems
relatively ineffective and low efficient. (According to the draft, the
period should be a least a few m-seconds. However, I don’t think it is long
enough.

It is just my humble opinion.

--Dacheng

> Both these documents have good thoughts in addressing the 
> issue, but also have gaps in terms of security. Both these 
> designs are prone to security attacks and going by the 
> proposed solutions, the QCD seems the better of the two.
> 
> Some effort into Liveness detection mechanism , the method of 
> generating secured QCD token and managing the token in an 
> optimized manner are some of the items that can be worked on 
> from the QCD draft. I think, Fixing these items would  lead 
> to a more secured and acceptable solution and I will be more 
> than happy to work with the team on these items.
> 
> Thanks and Regards,
> A.Palanivelan
> 
> On Behalf Of Yaron Sheffer
> in solving this problem. Now, I'd like to ask the people who 
> have responded (as well as others) to read the two drafts, 
> and to tell us why
> 
> Quoting myself: "If you speak up, we will expect you to 
> contribute to the selection of the preferred document".
> 
> Please respond with comments to the drafts and/or a 
> comparison within the next week, i.e. by August 17.
> 
> Thanks,
> 	Yaron
> 
> > Subject: [IPsec] Failure detection proposals Sent by: 
> > [email-masked]
> >
> >
> >
> interest in the 
> expect you to 
> problem to 
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> > Of Paul Hoffman
> > securely detect that its opposite peer, while currently 
> reachable, has
> lost
> > are beyond the scope of this work item, as is improving the 
> detection
> of an

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 23 Aug 2010 09:17:41 -0700

>From the responses to Yaron's request, there is a clear consensus in the WG to start with QCD as the WG's work item. We'll talk to the authors of the QCD draft about how they want to proceed with taking this into the WG.

--Paul Hoffman, Director
--VPN Consortium