In reading this thread, I see Frederic saying that he is replacing text
and getting some pushback, but it feels like that his text is reasonable
as an addition to the security considerations.
To close this issue and allow the document to go to IETF LC, I ask the
authors to replace 9.2 with the following text, which is a mixture of
the two proposals, with an extra paragraph break to show where the new
idea starts. Yaron and I will move this to the Area Director as soon as
we have a new draft. Thanks for all the work done so far!
--Paul Hoffman
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.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
