Subject: [IPsec] Putting issue #202 to rest

From: Yoav Nir <[email-masked]>
Date: Tue, 22 Feb 2011 09:21:21 +0200

Hi all.

Last week, I submitted version -05 of the failure detection draft. The last two versions both revolved around rewriting section 9.2

I hope this version is something all of us can live with. If I don't get any objections by this week-end, I will close issue #202, and ask Paul & Yaron to move the document forward.  For your convenience, here's the section:

9.2.  QCD Token Transmission

   A token maker MUST NOT send a valid QCD token in an unprotected
   message for an existing IKE SA.

   This requirement is obvious and easy in the case of a single gateway.
   However, some implementations use a load balancer to divide the load
   between several physical gateways.  It MUST NOT be possible even in
   such a configuration to trick one gateway into sending a valid QCD
   token for an IKE SA which is valid on another gateway.  This is true
   whether the attempt to trick the gateway uses the token taker's IP
   address or a different IP address.

   IPsec Failure Detection is not applicable to deployments where the
   QCD secret is shared by multiple gateways and the gateways cannot
   assess whether the token can be legitimately sent in the clear while
   another gateway may actually still own the SA's.  Load balancer
   configurations typically fall in this category.  In order for a load
   balancing configuration of IPsec gateways to support this
   specification, all members MUST be able to tell whether a particular
   IKE SA is active anywhere in the cluster.  One way to do it is to
   synchronize a list of active IKE SPIs among all the cluster members.

   Because it includes the token taker's IP address in the token
   generation, the method in Section 5.2 can (under certain conditions)
   prevent revealing the QCD token for an existing pair of IKE SPIs to
   an attacker who is using a different IP address, even in a load-
   sharing cluster without state synchronization.  This method does not
   prevent revealing the QCD token to an active attacker who is spoofing
   the token taker's IP address.  Such an attacker may attempt to direct
   messages to a cluster member other than the member responsible for
   the IKE SA in an attempt to trick that gateway into sending a QCD
   token for a valid IKE SA.  This method should not be used unless the
   load balancer guarantees that IKE packets from the same source IP
   address always go to the same cluster member.

---

From: Scott C Moonen <[email-masked]>
Date: Wed, 23 Feb 2011 11:28:13 -0500

Yoav, thanks. I'm ok with this text. However, because of Tero's
observations about the man-in-the-middle wording, we might want to improve
the phrase "revealing the QCD token to an active attacker who is spoofing"
to read "sending the QCD token due to an active attacker who is spoofing."

Note that there are two sentences with similar phrasing, but we only need
to change the latter.

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:	02/22/2011 02:21 AM
Subject:	[IPsec] Putting issue #202 to rest
Sent by:	[email-masked]

Hi all.

Last week, I submitted version -05 of the failure detection draft. The last
two versions both revolved around rewriting section 9.2

I hope this version is something all of us can live with. If I don't get
any objections by this week-end, I will close issue #202, and ask Paul &
Yaron to move the document forward.  For your convenience, here's the
section:

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

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 23 Feb 2011 09:00:16 -0800

I have already sent the new draft to our AD for consideration to bring 
to IETF Last Call. Changes can certainly be made after IETF Last Call, 
and this discussion seems worthwhile there.

--Paul Hoffman, Director
--VPN Consortium