Nico Williams writes: > 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.
After we have received first IKE_AUTH message, we have already done all the expensive calculations already. I.e we have done the other half of Diffie-Hellman, and there is no point of throwing away that context, even if we get some packets which fail to decrypt. Note, that throwing away packets after this is just one MAC and compare, thus it is very fast compared to the Diffie-Hellman setup. > 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!! No it is not. If you are using EAP, it might be that there is some userinteraction during the IKE_AUTH time. There should not be anything for the first packet, but for later ones there might be. I.e. the pre-shared key needed to send the first IKE_AUTH packet should already be asked from user before even sending first IKE_SA_INIT... Also for small devices might take 10 seconds to actually do the other half of the Diffie-Hellman... I would expect that most timeouts during this phase are in order of minutes... Especially as there might be crappy networks between. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
