Hi Yoav,
as I mentioned in my mail yesterday, #194 is not just about this
particular issue.
Thanks,
Yaron
On 10/21/2010 12:33 PM, Yoav Nir wrote:
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
