I agree with Tero that the section is confusing and very difficult to
follow. I have taken a stab at rewording it. I think this still
incorporates the blending of the two approaches that Paul attempted, but
flows better and makes it easier to understand. I'm not sure it addresses
all of Tero's concerns, but I hope it gets us closer.
A token maker MUST NOT send a 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. In such configuration it MUST NOT
be possible to trick one gateway into sending a QCD token for an
IKE SA which exists on another gateway. This is true whether the
an attacker uses the token taker's IP address or a different IP
address.
Because it includes the token taker's IP address in the token
generation, the method in Section 5.2 prevents revealing the QCD
token for an existing pair of IKE SPIs to an attacker who is using a
different IP address. Note that the use of this method causes the
tokens to be invalidated whenever the token taker's address changes.
It is also important to note that this method does not prevent
revealing the QCD token to a man-in-the-middle 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 an existing IKE SA.
IPsec Failure Detection is not applicable to deployments where the QCD
token 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.
Dave Wierbowski
z/OS Comm Server Developer
Phone:
Tie line: 620-4055
External: 607-429-4055
From: Tero Kivinen <kivi...@iki.fi>
To: Paul Hoffman <paul.hoff...@vpnc.org>
Cc: ipsec@ietf.org
Date: 02/11/2011 06:38 AM
Subject: Re: [IPsec] Failure Detection - issue #202
Sent by: ipsec-boun...@ietf.org
Paul Hoffman writes:
> 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.
>
> Because it includes the token taker's IP address in the token
> generation, the method in Section 5.2 prevents revealing the QCD
> token for an existing pair of IKE SPIs to an attacker who is using a
> different IP address. Note that the use of this method causes the
> tokens to be invalidated whenever the token taker's address changes.
> It is important to note that this method does not prevent revealing
> the QCD token to a man-in-the-middle attacker who is spoofing the
> token taker's IP address, if that attacker is able to direct messages
> to a cluster member other than the member responsible for the IKE SA.
>
> This document does not specify how a load-sharing configuration of
> IPsec gateways would work, but in order 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.
>
> If an attacker can somehow access a QCD token while the SA's are
> still active, this attacker will be able to tear down the sessions at
> will. In particular, avoiding false positives is critical to the
> security of the proposal and a token maker MUST NOT send a QCD token
> in an unprotected message for an existing IKE SA. IPsec Failure
> Detection is thus not applicable to deployments where the QCD token
> is shared by multiple gateways and the gateways can not assess
> whether the token can be legitimately sent in the clear while another
> gateway may actually still own the SA's. Load balancer designs
> typically fall in this category.
I think the section is bit confusing. It says similar (or perhaps
same, I am not sure) things in different places using different words,
so it is not really clear what it is saying.
In general I think that section needs rewrite, and the problem is that
nobody really has real overall picture what should be in it, so it
is just cut & paste text from different authors with no overall
structure.
For example it says twice that "token maker MUST NOT send a (valid)
QCD token in an unprotected message for an existing IKE SA." The first
uses "valid QCD token", another says "a QCD token", not sure if there
are supposed to be any difference there.
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
