Adding the IPsec list. Begin forwarded message:
From: Frederic Detienne <[email protected]<mailto:[email protected]>> Date: February 1, 2011 9:37:33 PM GMT+02:00 To: Paul Hoffman <[email protected]<mailto:[email protected]>> Cc: Yoav Nir <[email protected]<mailto:[email protected]>>, Pratima Sethi <[email protected]<mailto:[email protected]>>, Yaron Sheffer <[email protected]<mailto:[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]<mailto:[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
