Subject: [IPsec] I-D Action:draft-ietf-ipsecme-failure-detection-03.txt

From: [email-masked]
Date: Sun, 09 Jan 2011 23:45:02 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF.

	Title           : A Quick Crash Detection Method for IKE
	Author(s)       : Y. Nir, et al.
	Filename        : draft-ietf-ipsecme-failure-detection-03.txt
	Pages           : 23
	Date            : 2011-01-09

This document describes an extension to the IKEv2 protocol that
allows for faster detection of SA desynchronization using a saved
token.

When an IPsec tunnel between two IKEv2 peers is disconnected due to a
restart of one peer, it can take as much as several minutes for the
other peer to discover that the reboot has occurred, thus delaying
recovery.  In this text we propose an extension to the protocol, that
allows for recovery immediately following the restart.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-failure-detection-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Yoav Nir <[email-masked]>
Date: Mon, 10 Jan 2011 10:03:15 +0200

Greetings.

We have just submitted version -03 of the draft.  This closes issues, #198, #199, #200, and #201.

Which leaves us with just one issue: #202

========= Issue #202: Token makers generating the same tokens without synchronized DB
Section 10.4 of the draft has a use-case where a cluster of gateways share the same QCD token secret, because they back each other up.

The twist in this case, is that they don't have synchronized databases, so a fail-over is very much like a reboot - the IKE SA is gone, and QCD is effective in getting the other side to restart IKE quickly.

The problem is, that without a failover, it may be possible to get a member that does not own the IKE SA to send the QCD token to an attacker. The attacker can then use this QCD token to tear down the IKE SA.

The method in section 5.2 tries to address this, by considering the IP address of the token taker in the calculation.

Tero claims that this is a scenario that we should not address, and that predicting or prescribing load balancer behavior in inherently dangerous.
=======================

Please send your opinions to the list. This one actually addresses the scope of the document, so it's strange that this comes up as the last issue, but we still have to decide on this.

Yoav

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 11 Jan 2011 07:33:23 -0800

> Which leaves us with just one issue: #202

So far, there have been no posts on this thread. I encourage the 
document authors to weigh in on the topic soon so that others can see 
whether they want to as well.

---

From: David Wierbowski <[email-masked]>
Date: Tue, 11 Jan 2011 12:38:56 -0500

I agree with Tero that it is unsafe to assume how a load balancer decides
to distribute traffic.  Since section 9.4 (previously 10.4) is in the
Security Considerations section it seems reasonable to me that we'd warn
that the algorithms in 5.1 and 5.2 should not be used in cases where load
balancing cluster members share the same QCD token and do not share IKE SA
state.

I don't think this restriction precludes the use of QCD in the hot-standby
cluster scenario that Yoav mentioned in his previous append.  By definition
in a hot-standby cluster only one of the cluster members is active at any
one time and it is not doing load balancing with its standby members.

In the same append Yoav stated that to achieve scalability with your hot
standby-cluster, you implement load sharing.  If you add load balancing to
your hot standby-cluster then the warning in the previous paragraph
applies.  In otherwords if you want one of your standby members to be a
load balancing target for the active member in the cluster then you need to
share the IKE SA state between the active member and the standby member.

I'd recommend that the following text from 9.4 be changed:

   To thwart this possible attack, such configurations should use a
   method that considers the taker's IP address, such as the method
   described in Section 5.2.

Dave Wierbowski

From:       Yoav Nir <[email-masked]>
To:         "[email-masked]" <[email-masked]>
Date:       01/10/2011 03:04 AM
Subject:    [IPsec] Issue #202: Token makers generating the same tokens
            without synchronized DB
Sent by:    [email-masked]

Greetings.

We have just submitted version -03 of the draft.  This closes issues, #198,
#199, #200, and #201.

========= Issue #202: Token makers generating the same tokens without
synchronized DB
Section 10.4 of the draft has a use-case where a cluster of gateways share
the same QCD token secret, because they back each other up.

The twist in this case, is that they don't have synchronized databases, so
a fail-over is very much like a reboot - the IKE SA is gone, and QCD is
effective in getting the other side to restart IKE quickly.

The problem is, that without a failover, it may be possible to get a member
that does not own the IKE SA to send the QCD token to an attacker. The
attacker can then use this QCD token to tear down the IKE SA.

The method in section 5.2 tries to address this, by considering the IP
address of the token taker in the calculation.

Tero claims that this is a scenario that we should not address, and that
predicting or prescribing load balancer behavior in inherently dangerous.
=======================

Please send your opinions to the list. This one actually addresses the
scope of the document, so it's strange that this comes up as the last
issue, but we still have to decide on this.

Yoav

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

---

From: Scott C Moonen <[email-masked]>
Date: Wed, 12 Jan 2011 15:45:15 -0500

Comments on the draft, mostly editorial in nature:

(1) There are still some blockquotes that start with excessive first-line
indents, eg., the three quotes on page 5.
(2) Page 5, should add comma after "system" in "Reboot, depending on the
system."
(3) Page 5, should pluralize "implementation" in "IKEv2 implementation can
detect."
(4) Page 5, should remove "the" in "rules given in the section."
(5) Page 6, correct "even has change" to "even has a chance."
(6) Page 6, change comma to semicolon in "immediately, in those cases."
(7) Page 6, suggest improving sentence beginning "Note, that" to read "Note
that the IKEv2 specification specifically gives no guidance for the number
of retries or the length of timeouts, as these do not affect
interoperability."
(8) Page 6, suggest changing "messages as hints that will shorten" to read
"messages to shorten."
(9) Global, need commas after "i.e."
(10) Page 6, change "that kind of hints" to either "this kind of hint" or
"these kinds of hints."
(11) Page 7, pluralize first word in "Implementation that are not token
takers."
(12) Section 4.1, should we specify that the critical bit is set to 0?
(13) Page 8, the last line is an orphan.
(14) Section 4.2 says the payload "MUST follow . . . and precede . . ."  In
general I think the IKEv2 specs have tried to say SHOULD for ordering
considerations; should we do so here?
(15) Section 4.3 says "SHOULD send a new ticket."  I think we mean to say
"QCD_TOKEN notification" instead of "ticket."
(16) Section 4.5, is it correct to denote the unprotected message as a
"request" in the flow diagrams?  I think we were careful in RFC 5996 to
denote standalone messages as informational messages rather than
informational requests.
(17) Section 7, change "new IKE SA consume" to "new IKE SA to consume."
(18) Section 7, suggest changing "re-establishment should occur" to either
"would occur" or "will occur."
(19) Section 8.1, suggest changing "inter-domain VPN gateway" to either add
"an" before it or pluralize "gateway."

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

From:	[email-masked]
To:	[email-masked]
Cc:	[email-masked]
Date:	01/10/2011 02:48 AM
Subject:	[IPsec] I-D Action:draft-ietf-ipsecme-failure-detection-03.txt
Sent by:	[email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the IP Security Maintenance and Extensions
Working Group of the IETF.

ftp://[email-masked]/internet-drafts/draft-ietf-ipsecme-failure-detection-03.txt

---

From: Scott C Moonen <[email-masked]>
Date: Wed, 12 Jan 2011 15:54:03 -0500

I wonder if there's a way to merge sections 9.2 and 9.4.  I think that
using the algorithm in 5.2 as specified in 9.4 is really just an extension
of this requirement from section 9.2: "A token maker MUST NOT send a QCD
token in an unprotected message for an existing IKE SA."

It might be possible to remove a lot of the detail in 9.4 and generalize
9.2 to hint at there being several ways of solving this problem -- 9.2's
state synchronization and 5.2/9.4's including the remote IP address.

From:	David Wierbowski/Endicott/IBM@IBMUS
To:	"[email-masked]" <[email-masked]>, [email-masked]
Cc:	Yoav Nir <[email-masked]>
Date:	01/11/2011 12:39 PM
Subject:	Re: [IPsec] Issue #202: Token makers generating the same tokens
            without synchronized DB
Sent by:	[email-masked]

Dave Wierbowski

Greetings.

Yoav

---

From: Scott C Moonen <[email-masked]>
Date: Thu, 13 Jan 2011 09:47:59 -0500

Combining the two sections could also make it clearer that 5.2/9.4 may not
be a "complete" solution for any given environment.  The approach of
5.2/9.4 solves the problem of an independent attacker using a different
source IP address, but not a proximate/MitM attacker as is currently
addressed in 9.2.

From:	Scott C Moonen/Raleigh/IBM
To:	David Wierbowski/Endicott/IBM@IBMUS
Cc:	"[email-masked]" <[email-masked]>, [email-masked], Yoav
            Nir <[email-masked]>
Date:	01/12/2011 03:54 PM
Subject:	Re: [IPsec] Issue #202: Token makers generating the same tokens
            without synchronized DB

Dave Wierbowski

Greetings.

Yoav

---

From: David Wierbowski <[email-masked]>
Date: Thu, 13 Jan 2011 11:11:03 -0500

Scott,

I agree that there is relationship between sections 9.2 and 9.4. The
statement that "all members MUST be able to tell whether a particular IKE
SA is active anywhere in the cluster" which is found in 9.2 is consistent
with my comment that " the algorithms in 5.1 and 5.2 should not be used in
cases where load balancing cluster members share the same QCD token and do
not share IKE SA state."  Although I suppose I should have said same
QCD_SECRET instead of QCD token  to be more accurate.

I could see why you would say that the algorithm in 5.2 as justified in
section 9.4 is being used to meet the requirement that "A token maker MUST
NOT send a QCD token in an unprotected message for an existing IKE SA."
Certainly if we do not include IP address it is possible that a cluster
member could send the QCD token of an existing IKE SA to an attacker using
a different source IP address.  In that case we'd be unknowingly violating
the rule.  By adding the ip address of the taker we prevent this.

I think you are correct that the two sections could be combined, but I'll
defer to Yoav on that.

As an aside I see that I cut and paste the wrong paragraph in my append.  I
had actually intended to cut and paste the last paragraph of 9.4 and I now
see that I cut and paste the next to last paragraph in section 9.4 :>).

Dave Wierbowski

From:       Scott C Moonen/Raleigh/IBM@IBMUS
To:         David Wierbowski/Endicott/IBM@IBMUS
Cc:         "[email-masked]" <[email-masked]>, [email-masked], Yoav
            Nir <[email-masked]>
Date:       01/13/2011 09:50 AM
Subject:    Re: [IPsec] Issue #202: Token makers generating the same tokens
            without synchronized DB
Sent by:    [email-masked]

Combining the two sections could also make it clearer that 5.2/9.4 may not
be a "complete" solution for any given environment. The approach of 5.2/9.4
solves the problem of an independent attacker using a different source IP
address, but not a proximate/MitM attacker as is currently addressed in
9.2.

(Embedded image moved to file: pic34804.gif)Inactive hide details for Scott
C Moonen---01/12/2011 03:54:03 PM---I wonder if there's a way to merge
sections 9.2 and 9.4.  IScott C Moonen---01/12/2011 03:54:03 PM---I wonder
if there's a way to merge sections 9.2 and 9.4. I think that using the
algorithm in 5.2 as

Cc: "[email-masked]" <[email-masked]>, [email-masked], Yoav Nir
<[email-masked]>

I wonder if there's a way to merge sections 9.2 and 9.4. I think that using
the algorithm in 5.2 as specified in 9.4 is really just an extension of
this requirement from section 9.2: "A token maker MUST NOT send a QCD token
in an unprotected message for an existing IKE SA."

(Embedded image moved to file: pic11871.gif)Inactive hide details for David
Wierbowski---01/11/2011 12:39:21 PM---I agree with Tero that it is unsafe
to assume how a load David Wierbowski---01/11/2011 12:39:21 PM---I agree
with Tero that it is unsafe to assume how a load balancer decides to
distribute traffic. Si

Dave Wierbowski

Greetings.

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Sun, 30 Jan 2011 10:00:42 +0200

Hi Scott.

Thanks for your comments. My replies inline.

On Jan 12, 2011, at 10:45 PM, Scott C Moonen wrote:

(1) There are still some blockquotes that start with excessive first-line indents, eg., the three quotes on page 5.

Those are intentional. They quote from the RFC, so I copied them line by line.

(2) Page 5, should add comma after "system" in "Reboot, depending on the system."

Will be fixed in -04.

(3) Page 5, should pluralize "implementation" in "IKEv2 implementation can detect."

Will be fixed in -04.

Will be fixed in -04.

Will be fixed in -04.

Will be fixed in -04.

(7) Page 6, suggest improving sentence beginning "Note, that" to read "Note that the IKEv2 specification specifically gives no guidance for the number of retries or the length of timeouts, as these do not affect interoperability."

Will be fixed in -04.

(8) Page 6, suggest changing "messages as hints that will shorten" to read "messages to shorten."

Will be fixed in -04.

Will be fixed in -04.

(10) Page 6, change "that kind of hints" to either "this kind of hint" or "these kinds of hints."

Will be fixed in -04.

(11) Page 7, pluralize first word in "Implementation that are not token takers."

Will be fixed in -04.

I think not, because that is true of any notify payload

Not sure what you mean. It says "In any case, the lack of a QCD_TOKEN notification MUST NOT be taken" and then continues on the next page.

(14) Section 4.2 says the payload "MUST follow . . . and precede . . ." In general I think the IKEv2 specs have tried to say SHOULD for ordering considerations; should we do so here?

Agree that we shouldn't. RFC5996 specifically says that order doesn't matter. If nobody objects, I'll change it to a lower-case "should".

(15) Section 4.3 says "SHOULD send a new ticket." I think we mean to say "QCD_TOKEN notification" instead of "ticket."

No. That sentence is about session resumption (RFC 5723), where they do use "tickets". The second sentence talks about tokens:

   For session resumption, as specified in [RFC5723], the situation is
   similar.  The responder, which is necessarily the peer that has
   crashed, SHOULD send a new ticket within the protected payload of the
   IKE_SESSION_RESUME exchange.  If the Initiator is also a token maker,
   it needs to send a QCD_TOKEN in a separate INFORMATIONAL exchange.

(16) Section 4.5, is it correct to denote the unprotected message as a "request" in the flow diagrams? I think we were careful in RFC 5996 to denote standalone messages as informational messages rather than informational requests.

OK. I'll change it to "message"

OK.

(18) Section 7, suggest changing "re-establishment should occur" to either "would occur" or "will occur."

Agree, but I will solve it by moving the whole paragraph to the present tense:

   Session resumption, specified in [RFC5723], allows the setting up of
   a new IKE SA to consume less computing resources.  This is
   particularly useful in the case of a remote access gateway that has
   many tunnels.  A failure of such a gateway requires all these many
   remote access clients to establish an IKE SA either with the rebooted
   gateway or with a backup.  This tunnel re-establishment occurs within
   a short period of time, creating a burden on the remote access
   gateway.  Session resumption addresses this problem by having the
   clients store an encrypted derivative of the IKE SA for quick re-
   establishment.

(19) Section 8.1, suggest changing "inter-domain VPN gateway" to either add "an" before it or pluralize "gateway."

Since the other bullet points are pluralized, I'll go with the former.

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

Internet-Drafts---01/10/2011 02:48:33 AM---A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work

From: [email-masked]<mailto:[email-masked]>
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Date: 01/10/2011 02:48 AM
Subject: [IPsec] I-D Action:draft-ietf-ipsecme-failure-detection-03.txt
Sent by: [email-masked]<mailto:[email-masked]>

________________________________

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
ftp://[email-masked]/internet-drafts/draft-ietf-ipsecme-failure-detection-03.txt_______________________________________________
IPsec mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ipsec

<ATT00001..txt>

---

From: Yoav Nir <[email-masked]>
Date: Sun, 30 Jan 2011 10:14:59 +0200

On Jan 30, 2011, at 10:00 AM, Yoav Nir wrote:

OK. Now that Yaron has helped me figure out what an "orphan" is, this is automatic output from the XML2RFC utility. I think the RFC editor takes care of this before publication.

Yoav