|Main Archive Page > Month Archives > ipsec archives|
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.
-- firstname.lastname@example.org _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec