Yaron Sheffer writes: > I agree with Scott's position. In the case of site-to-site VPN, where > SAs are NOT set up by configuration, but rather triggered by traffic, > you can have a tunnel triggered by traffic from A to B, but later mostly > used in the opposite direction. This would benefit from allowing the > original responder to be a token taker.
As I explained that even in that case the QCD still slows recovery down by half a round trip. I.e. when the traffic is only coming from B to A, and A crashes, then when A gets up and its getting the unknown ESP, and would be sending QCD token, instead of sending QCD token, it can simply start creating the IKE SA again, and save half a round trip in the recovery time. As the peer B is already known by the configuration as host A was able to initiate IKE SA to it originally, there is no real DoS attack option here, as only thing that attacker can do is to force A to create all the preconfigured connections it is normally doing anyways. > And to answer Tero's original concern, if we require the token maker's > SPI to be unpredictable, then we don't need to worry about token > stealing and we can send the token in the first IKE_AUTH message. Which > would make things a little more regular. I would prefer that, and I think we can require token maker's SPI to be unpredictable if it is using this feature. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
