John Mattsson writes: > Tero Kivinen wrote: > > > and doing Diffie-Hellman for each of them would be too costly > > I agree that was true in the past. Do you think that is still the > case for an optimized implementation of modern algorithms running on > new CPUs? As I wrote in draft-mattsson-tls-psk-ke-dont-dont-don’t:
I do not think it was true even in the past, but router and gateway vendors have always claimed so.. On the other hand they do use very slow hardware on some of thier platforms, so it is true on those environments. Anyways as there has been requests for such feature, then IPsec leaves that decision to the policy, i.e., if your policy requires PFS for each IPsec SA, then IKE will do Diffie-Hellman for each IPsec SA creation, rekey etc. If your policy allows creating or rekeying IPsec SAs without Diffie-Hellman that is possible too, and there are use cases for that too. Things start to look different when you have gateways which have thousads of connections and each of them have thousands of IPsec SAs etc. One of the reason implementations create multiple IPsec SAs is to allow high bandwidth operations i.e., having separate IPsec SA for each cpu-core, and for each separate traffic class. The IPsec SAs there are not independent, as traffic is divided over them using selectors that have nothing to do with security policy. Thus each of those IPsec SAs sharing one long term secret to protect them all does not really matter, as they really are one just IPsec SA split to multiple beacuse of technical reasons.. Then when they want to provide security boundary in time, they will rekey the IKE SA and do Diffie-Hellman there, and then rekey all IPsec SAs using that new IKE SA without using Diffie-Hellman. If they do this every hour or so, then breaking that one IKE SA Diffie-Hellman will allow attacker to see traffic transmitted within that hour, exactly like if all the traffic would have been transmitted using single IPsec SA which is rekeyed every hour with Diffie-Hellman. -- kivi...@iki.fi _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
