5 ms·

The performance gap is shown to be due to hardware offloading, not due to congestion control, in the arxiv paper above.

vlovich123 2y ago
And because Quic is encrypted at a fundamental level, offload likely means needing to share keys with the network card which is a trust concern.
- 10000truths 2y ago
  This is already how TLS offload is implemented for NICs that support it. The handshake isn't offloaded, only the data path. So essentially, the application performs the handshake, then it calls setsockopt to convert the TCP socket to a kTLS socket, then it passes the shared key, IV, etc. to the kTLS socket, and the OS's network stack passes those parameters to the NIC. From there, the NIC only handles the bulk encryption/decryption and record encapsulation/decapsulation. This approach keeps the drivers' offload implementations simple, while still allowing the application/OS to manage the session state.
  - vlovich123 2y ago
    Sure, similar mechanisms are available but for TCP ack offloading and TLS encryption/decryption offloading are distinct features. With QUIC there’s no separation which changes the threat model. Of course the root architectural problem is that this kind of stuff is part of the NIC instead of an “encryption accelerator” that can be requested to operate with a key ID on a RAM region and then the kernel only needs to give the keys to the SE (and potentially that’s where they even originate instead of ever living anywhere else)
- jstarks 2y ago
  Your NIC can already access arbitrary RAM via DMA. It can read your keys already.
  - altairprime 2y ago
    That is often incorrect for Apple computers, whether x64+T2 or aarch64: https://support.apple.com/fr-tn/guide/security/seca4960c2b5/web https://support.apple.com/fr-tn/guide/security/seca4960c2b5/... And it’s often incorrect on x64 PCs when IOMMU access is appropriately segmented. See also e.g. Thunderclap: https://www.ndss-symposium.org/wp-content/uploads/ndss2019_05A-1_Markettos_slides.pdf https://www.ndss-symposium.org/wp-content/uploads/ndss2019_0... It may still be true in some cases, but it shouldn’t be taken for granted that it’s always true.
  - yencabulator 2y ago
    Nope. https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_management_unit https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_ma...
  - gmokki 2y ago
    Kernels enable IOMMU of the CPU, which limits the memory areas of the NIC can access to only to the memory it needs to access. This is also why it should be safe to attach pcie over thunderbolt devices. Although I think for Intel CPUs the mmunuded to be disabled for years because their iGPU driver could not work with it. I hope things have improved with the Xe GPUs.

And because Quic is encrypted at a fundamental level, offload likely means needing to share keys with the network card which is a trust concern.

10000truths 2y ago
This is already how TLS offload is implemented for NICs that support it. The handshake isn't offloaded, only the data path. So essentially, the application performs the handshake, then it calls setsockopt to convert the TCP socket to a kTLS socket, then it passes the shared key, IV, etc. to the kTLS socket, and the OS's network stack passes those parameters to the NIC. From there, the NIC only handles the bulk encryption/decryption and record encapsulation/decapsulation. This approach keeps the drivers' offload implementations simple, while still allowing the application/OS to manage the session state.
- vlovich123 2y ago
  Sure, similar mechanisms are available but for TCP ack offloading and TLS encryption/decryption offloading are distinct features. With QUIC there’s no separation which changes the threat model. Of course the root architectural problem is that this kind of stuff is part of the NIC instead of an “encryption accelerator” that can be requested to operate with a key ID on a RAM region and then the kernel only needs to give the keys to the SE (and potentially that’s where they even originate instead of ever living anywhere else)
jstarks 2y ago
Your NIC can already access arbitrary RAM via DMA. It can read your keys already.
- altairprime 2y ago
  That is often incorrect for Apple computers, whether x64+T2 or aarch64: https://support.apple.com/fr-tn/guide/security/seca4960c2b5/web https://support.apple.com/fr-tn/guide/security/seca4960c2b5/... And it’s often incorrect on x64 PCs when IOMMU access is appropriately segmented. See also e.g. Thunderclap: https://www.ndss-symposium.org/wp-content/uploads/ndss2019_05A-1_Markettos_slides.pdf https://www.ndss-symposium.org/wp-content/uploads/ndss2019_0... It may still be true in some cases, but it shouldn’t be taken for granted that it’s always true.
- yencabulator 2y ago
  Nope. https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_management_unit https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_ma...
- gmokki 2y ago
  Kernels enable IOMMU of the CPU, which limits the memory areas of the NIC can access to only to the memory it needs to access. This is also why it should be safe to attach pcie over thunderbolt devices. Although I think for Intel CPUs the mmunuded to be disabled for years because their iGPU driver could not work with it. I hope things have improved with the Xe GPUs.