Making QUIC Quicker with NIC Offload
dl.acm.org
Making QUIC Quicker with NIC Offload
1–10 of 31 posts
Re: Making QUIC Quicker with NIC Offload
#2Hmm, researchers with the 'National University of Defense Technology' propound on the benefits of offloading encryption/decryption to a separate processor/FPGA on the Network Interface Card. Just for speed, I'm sure!
Re: Making QUIC Quicker with NIC Offload
#3> We find that the kernel to userspace communication, ... often the cause of application performance degradation
Assuming they're talking about Linux here, I wonder if they used io_uring.
Re: Making QUIC Quicker with NIC Offload
#4Hmm, researchers with the 'National University of Defense Technology' propound on the benefits of offloading encryption/decryption to a separate processor/FPGA on the Network Interface Card. Just for speed, I'm sure!
This has been done for years, eg with Chelsio NICs, and indeed it can speed things up quite a bit.
Re: Making QUIC Quicker with NIC Offload
#5Hmm, researchers with the 'National University of Defense Technology' propound on the benefits of offloading encryption/decryption to a separate processor/FPGA on the Network Interface Card. Just for speed, I'm sure!
This has been done for years, eg with Chelsio NICs, and indeed it can speed things up quite a bit.
Wiretapping has been done for years, yes. NOBUS encryption compromise has a long history, and speeds things up a lot. (for the NSA)
Re: Making QUIC Quicker with NIC Offload
#6> We find that the kernel to userspace communication, ... often the cause of application performance degradation Assuming they're talking about Linux here, I wonder if they used io_uring.
>Lesson #1: Data copy between user and kernel space costs around
50% of total CPU usage. This can be avoided by using kernel-bypass
techniques as adopted in Quant.
>Lesson #2: In the presence of a kernel-bypass optimization, crypto operations become the new most expensive operation, requiring up to 40% of CPU resources per connection.
I suppose they did an equivalent optimization ? I have no experience with io_uring, but I assume the gains are similar to kernel bypass optimizations.
Re: Making QUIC Quicker with NIC Offload
#7> We find that the kernel to userspace communication, ... often the cause of application performance degradation Assuming they're talking about Linux here, I wonder if they used io_uring.
I believe they are talking about "user space networking", like Intel's DPDK. Skipping the kernel and context switches, etc.
Re: Making QUIC Quicker with NIC Offload
#8Earlier quoted context omitted.
This has been done for years, eg with Chelsio NICs, and indeed it can speed things up quite a bit.
Wiretapping has been done for years, yes. NOBUS encryption compromise has a long history, and speeds things up a lot. (for the NSA)
How do you imagine this wiretapping works? This NIC is installed in your servers, and is fed AEAD keys that are derived from key exchange with a client by your TLS stack (and so private keys exist on the host, not on the NIC). This allows the NIC to decrypt/encrypt flows that pass through it and free up CPU cycles. QUIC requires forward secrecy for key exchange, so every flow will use a different AEAD key already, meaning any snooped key can only be used to decrypt the current flow, not any others. Every modern offload NIC uses this basic design, more or less. Where's the wiretap? Is the NIC going to somehow store every intermediate AEAD keys and escrow it to the NSA somehow? What does NOBUS have to do with any of this? And why wouldn't they just backdoor the motherboard/OS/CPU itself to acquire private keys directly?
Re: Making QUIC Quicker with NIC Offload
#9Earlier quoted context omitted.
Wiretapping has been done for years, yes. NOBUS encryption compromise has a long history, and speeds things up a lot. (for the NSA)
How do you imagine this wiretapping works? This NIC is installed in your servers, and is fed AEAD keys that are derived from key exchange with a client by your TLS stack (and so private keys exist on the host, not on the NIC). This allows the NIC to decrypt/encrypt flows that pass through it and free up CPU cycles. QUIC requires forward secrecy for key exchange, so every flow will use a different AEAD key already, me…
Since NIC is used to encrypt the traffic, it can purposefully have vulnerability that NSA knows about?
Fixing NIC is not as easy as fixing software.
Re: Making QUIC Quicker with NIC Offload
#10Earlier quoted context omitted.
How do you imagine this wiretapping works? This NIC is installed in your servers, and is fed AEAD keys that are derived from key exchange with a client by your TLS stack (and so private keys exist on the host, not on the NIC). This allows the NIC to decrypt/encrypt flows that pass through it and free up CPU cycles. QUIC requires forward secrecy for key exchange, so every flow will use a different AEAD key already, me…
Since NIC is used to encrypt the traffic, it can purposefully have vulnerability that NSA knows about? Fixing NIC is not as easy as fixing software.
Software - eg the Linux kernel - can also contain vulnerability only NSA knows about.
In any case, security track record of crypto offload NICs is pretty good.