On Oct 21, 2010, at 11:59 AM, Tero Kivinen wrote: <snip />
> The section 10.4 seems to assume that attacker cannot force the load > balancer to send the faked packet to any other cluster member than the > one mapped by the source IP-address of the packet. As the algorithm > how the load balancer really selects the peer where it sends the > packet is not necessarely known by the IPsec implementations, I do not > think we can trust we can include all same information to the token > generation. I agree, although I suspect some of my co-authors might not. > For example it could use source port numbers, or destination > IP-address, etc so I think it is quite unsafe to assume anything what > the load balancer might do. > > I think it would be safer to forbid situations where the cluster > members share the same QCD token unless they also share the IKE SA > state. I agree that there is a problem that needs solving here, but I also see some great utility in allowing QCD on such configurations. In a hot-standby cluster, you can have QCD instead of synchronizing state. When one gateway fails, the other takes over immediately (or in less than one second). This is like a reboot, but instantaneous, and it's easier and cheaper to implement than a real cluster with state synchronization - you only need to make sure that the QCD token secret is the same. In this configuration you don't have a problem, unless there's a way to get responses out of the standby member before it becomes active. If you also want to achieve scalability with your cluster, you implement load sharing. There is no state synch, but in case one of the gateways fails, we want the other to be able to use QCD to quickly destroy the existing IKE SAs. Again, if I can get one member to generate a token for an IKE SA owned by another gateway, the attacker wins. I'd say that this requires some very big assumptions for the load balancer anyway (for example, that without a failure, all IKE traffic for a particular SA goes to the same gateway, and even after a failure, old IKE SAs owned by other gateways remain with their respective gateways). We might need some interesting text to describe the requirements there. I think I will close #194, and open a new one that makes the contentious point clearer. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
