On Thu, 18 Jun 2020, Panos Kampanakis (pkampana) wrote:
> I guess the impact is small generally because an IPsec tunnel normally stays up for a long time. Does my guess seem ok here ? > Would there be some noticeable impact on a high-volume connections VPN server ? We tested this in the context of TLS in https://eprint.iacr.org/2020/071. For a tunnel that stays up for a long time (not just a few seconds like HTTPS) and sends Megabytes of data or more, then the larger key+signatures size are amortized over the tunnel data. What becomes more important then is the keygen, encap, decap, sign/verify time. In other words, servers that terminate a lot of connections at the same time will be impacted by slower operations in the handshake (the server throughput drops), but their tunnels that send a few more kilobytes of handshake data and magnitudes more over the tunnel are not significantly affected especially if we are talking about UDP and not TCP (with congestion control slowing down the handshake).
For libreswan, we recently went through performance enhancements, and we found a number of issues in our code that once meassured, were easilly fixed. There are still some linear lookups left in the Linux kernel for policies/states, but we found that with about 1000 users that keep connecting/disconnecting, it wasn't a big problem yet. Hopefully, more clients will use Session Resumption, which would at least cut out the (EC)DiffieHellman part of starting a session again, but on larger servers with that many clients, there tends to not be a guaranteed you can connect to the same server which can resume your session. Also, I'm not sure if we need to further postquantum prood the resumption mechanism (I don't think so, but I'm not a licensed cryptographer) Paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
