I'm ok with Frederic's first paragraph as an introduction to the issue; I don't have a strong preference for his text there or for mine.
His second paragraph is lacking a warning that the approach of section 5.2 does not solve all problems in all cases (e.g., what I communicate in my sentence "It is important to note ..."). But I'm ok with either (1) using my paragraph as-is, (2) making some change to how my paragraph states "MUST be able to tell ...," (3) or making some change to Frederick's second paragraph to better convey this. Scott Moonen ([email protected]) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: David Wierbowski/Endicott/IBM@IBMUS To: Yoav Nir <[email protected]> Cc: "[email protected]" <[email protected]>, [email protected] Date: 02/02/2011 09:40 AM Subject: Re: [IPsec] Fwd: Failure Detection - issue #202 Sent by: [email protected] 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
<<inline: graycol.gif>>
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
