I'm not sure what Frederic means by this statement should "be moved under
Security Considerations." Section 9.2 is already in the Security
Considerations section.
As far as his proposed text, I feel that Scott's text does a better job
describing the concern. Frederic's own text does not help with his concern
of hiding the complexity in the statement that "all members MUST be able to
tell whether a particular IKE SA is active anywhere in the cluster." He
just reworded the statement to be "Practically, 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." Both statements mean the same thing and impose the same
requirement.
If consensus is that others prefer Frederic's statement over the one that
Scott provided us, then I believe the "Practically" should be deleted from
the sentence that I mentioned above and the last sentence should be changed
to, "Load balancer designs may fall in this category." I don't think we
should presume to know what is typical in load balancers.
Dave Wierbowski
z/OS Comm Server Developer
Phone:
Tie line: 620-4055
External: 607-429-4055
From: Yoav Nir <[email protected]>
To: "[email protected]" <[email protected]>
Date: 02/01/2011 04:30 PM
Subject: [IPsec] Fwd: Failure Detection - issue #202
Sent by: [email protected]
Adding the IPsec list.
Begin forwarded message:
From: Frederic Detienne <[email protected]>
Date: February 1, 2011 9:37:33 PM GMT+02:00
To: Paul Hoffman <[email protected]>
Cc: Yoav Nir <[email protected]>, Pratima Sethi <[email protected]>,
Yaron Sheffer <[email protected]>
Subject: Re: [IPsec] Failure Detection - issue #202
Hi Paul, Yoav,
thanks. We are rather puzzled and have been debating how to address
this.
The proposal should either properly support Load Balancers or should
step down and rule out that use case.
The statement:
-8<---
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
-8<---
Hides a lot of complexity behind a single sentence. This sentence
actually makes Failure Detection impractical. Simplicity of
implementation (as compared to SA state synchronization) were key
drivers for us in this proposal.
The statement should be more precise about the general scenario and
be moved under Security Considerations.
-8<---
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.
Practically, 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.
-8<---
thanks and regards,
Frederic
On 01 Feb 2011, at 17:51, Paul Hoffman wrote:
Pratima and Frederic: Please respond to Yaron and I ASAP,
either way, whether or not you agree with the wording. Given
that this was your issue and you did not comment during WG LC,
we are concerned that we have lost contact with you.
If you do not agree with the wording, you need to say so on the
mailing list before Friday.
--Paul Hoffman
On 2/1/11 7:05 AM, Yoav Nir wrote:
Hi all.
Following last week's conf call, Scott Moonen has
proposed text to resolve issue #202. The idea is to
remove section 9.4 entirely, and change section 9.2 as
follows:
OLD:
9.2. QCD Token Transmission
A token maker MUST NOT send a QCD token in an
unprotected message for
an existing IKE SA. This implies that a conforming QCD
token maker
MUST be able to tell whether a particular pair of IKE
SPIs represent
a valid 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 QCD token
for an IKE SA which is valid on another gateway.
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.
NEW:
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.
Please discuss this issue this week, as I intend to
publish version -04 on Friday if there are no objections
to this change.
Yoav
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
Scanned by Check Point Total Security Gateway.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
