Frederic Detienne writes: > Like I explained earlier, sharing the address-less QCD token is > problematic in multiple practical network designs: > - Stateless failover pairs (e.g. VRRP, HSRP, ..) > - Load Balanced clusters > - Anycast server clusters
I do not think having address inside the QCD calculations help at all, as the attacker can easily fake that address (it is source address of the IKE SA packet triggering QCD). Adding source address to the QCD token hash only helps if you can guarantee that the load balancer forwarding packets to multiple cluster members does it based on the source address and there is no way to get packet past the load balancer without this demuxing. > In general, QCD address-less token generation is dangerous in all > the scenarios where the server owning the state can be bypassed by > the attacker and any other server in the cluster, not owning state, > can be targeted to receive the "invalid" IKE or ESP packet. I would remove the "address-less" there. QCD is dangerous in those situations regardless whether address is there or not. > In the current proposal, I agree that the issues raised by > address-less token should be more explicit and general. This token > method should be explicitly forbidden when either You misunderstood me. I am not proposing forbidding or adding text for the address-less token. It is secure and works fine on those environments where QCD can be used, i.e. where the QCD token generation secret is not shared with other members. I am opposed of including cookies with IP addresses, as I do not think that solves any problem, as it puts way too much implicit assumptions how the load balancer work. I think that section 5.2 is dangeours and should be removed, and we should forbid sharing QCD token generation secret in all cases where the IKE SA databases are not shared too. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
