Frederic Detienne writes: > In order to secure QCD, the token has to include all the fields that > can be used for routing a packet to any given server: > > - source/destinatition IP > - protocol (UDP / ESP) > - source/destination ports if applicable
But the problem is that the IPsec implementation does not have way to know what fields is used. Some future load balancer might use something else in addition to those you listed there and if that happens we immediately open the QCD protocol for attacks. > > This is of course on top of the SPI and the QCD Secret. > > In doing so, we impose additional constraints on QCD's security and > scope but this is necessary to ensure QCD is a secure protocol. > > So we are now facing three main options > 1- keep using 5.1 token generation and mention that it is dangerous > in specific situations 5.1 token generation is not dangerous, unless you share QCD token generation secrets. Both 5.1 and 5.2 token generations are dangerous if you share QCD token generation secrets unless you know exactly how your load balancer demuxes the IKE packets, and include all information used for this demuxing to your QCD token and make sure load balancer cannot pass packets to any members directly (i.e. bypassing the demuxing). -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
