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 IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
