On 21 Oct 2010, at 12:33, 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.
I suppose your statement was for me...
Not only I agree with Tero this can happen but I personally mentioned it a few
times already. :-)
I am also claiming that it happens not just with SLB -- it can happen with HSRP
and various other network designs.
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
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
2- restrict the token generation method to 5.2 and expand 5.2 to using port
and protocol as well (all routable fields) which actually restricts QCD out of
Mobike. Warnings still apply for specific cases.
3- expand QCD to send a liveness check with a short answer delay. In this
scenario, if the server still has the IKE SA, it will respond to the liveness
check -- which will prove that the clear-text INV_SPI should not have been sent
in the first place. This must hint the client to NOT tear down or rekey the
SA's, which protects against the attack.
With point 3, the protocol does not need the token and the persistent key
anymore and the proposal effectively becomes SIR which itself is immune to the
attacks and works with Mobike.
regards,
fred
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
