On Sun, Oct 05, 2014 at 11:22:29PM +0300, Yoav Nir wrote: > Now the responder has two options: > (1) delete the entry in the half-open SA database, or > (2) store the derived key, and keep the half-open SA another 9.5 seconds. > > (2) has the disadvantage that the attacker can keep sending more junk packets > and get the responder to attempt to decrypt all of them. > (1) has the disadvantage that an attacker can inject a junk IKE_AUTH request > by just copying the IKE SPIs from the IKE_INIT response, which will prevent > the responder from processing the real initiator’s IKE_AUTH request. > > So I’m not sure which is worse.
Split the difference. Shorten the amount of time you keep the half-open SA around. The amount of time to keep a half-open SA/connection/state around should be dynamic: based on something like N standard deviations from the average time to complete a handshake when not under (D)DoS attack. 10 seconds is a lot!! If you're going to use OTP -any interactive authentication- then that should really be done as one more round-trip. Human interface factors should not be allowed to interfere at this stage. The old internal Sun punchin VPN did user authentication and authorization after setting up SAs; success led to the necessary routing getting setup so the user's bits moved. Nico -- _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
