I wonder if there's a way to merge sections 9.2 and 9.4. I think that using the algorithm in 5.2 as specified in 9.4 is really just an extension of this requirement from section 9.2: "A token maker MUST NOT send a QCD token in an unprotected message for an existing IKE SA."
It might be possible to remove a lot of the detail in 9.4 and generalize 9.2 to hint at there being several ways of solving this problem -- 9.2's state synchronization and 5.2/9.4's including the remote IP address. Scott Moonen ([email protected]) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: David Wierbowski/Endicott/i...@ibmus To: "[email protected]" <[email protected]>, [email protected] Cc: Yoav Nir <[email protected]> Date: 01/11/2011 12:39 PM Subject: Re: [IPsec] Issue #202: Token makers generating the same tokens without synchronized DB Sent by: [email protected] I agree with Tero that it is unsafe to assume how a load balancer decides to distribute traffic. Since section 9.4 (previously 10.4) is in the Security Considerations section it seems reasonable to me that we'd warn that the algorithms in 5.1 and 5.2 should not be used in cases where load balancing cluster members share the same QCD token and do not share IKE SA state. I don't think this restriction precludes the use of QCD in the hot-standby cluster scenario that Yoav mentioned in his previous append. By definition in a hot-standby cluster only one of the cluster members is active at any one time and it is not doing load balancing with its standby members. In the same append Yoav stated that to achieve scalability with your hot standby-cluster, you implement load sharing. If you add load balancing to your hot standby-cluster then the warning in the previous paragraph applies. In otherwords if you want one of your standby members to be a load balancing target for the active member in the cluster then you need to share the IKE SA state between the active member and the standby member. I'd recommend that the following text from 9.4 be changed: To thwart this possible attack, such configurations should use a method that considers the taker's IP address, such as the method described in Section 5.2. Dave Wierbowski From: Yoav Nir <[email protected]> To: "[email protected]" <[email protected]> Date: 01/10/2011 03:04 AM Subject: [IPsec] Issue #202: Token makers generating the same tokens without synchronized DB Sent by: [email protected] Greetings. We have just submitted version -03 of the draft. This closes issues, #198, #199, #200, and #201. Which leaves us with just one issue: #202 ========= Issue #202: Token makers generating the same tokens without synchronized DB Section 10.4 of the draft has a use-case where a cluster of gateways share the same QCD token secret, because they back each other up. The twist in this case, is that they don't have synchronized databases, so a fail-over is very much like a reboot - the IKE SA is gone, and QCD is effective in getting the other side to restart IKE quickly. The problem is, that without a failover, it may be possible to get a member that does not own the IKE SA to send the QCD token to an attacker. The attacker can then use this QCD token to tear down the IKE SA. The method in section 5.2 tries to address this, by considering the IP address of the token taker in the calculation. Tero claims that this is a scenario that we should not address, and that predicting or prescribing load balancer behavior in inherently dangerous. ======================= Please send your opinions to the list. This one actually addresses the scope of the document, so it's strange that this comes up as the last issue, but we still have to decide on this. Yoav _______________________________________________ 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
