On 2/11/11 7:08 AM, David Wierbowski wrote:
I agree with Tero that the section is confusing and very difficult to follow.
FWIW, I thought the wording I presented was repetitive but not confusing. "Repetitive" is not necessarily a bad thing for security considerations, but confusing is.
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.
OK, let's have an extra round before we go to IETF Last Call. If no one disagrees with Dave's new wording before Tuesday, Feb 15, I will ask the authors to put it in a new draft.
--Paul Hoffman _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
