MPTCP and KTLS support

[matttbe]

Currently, an MPTCP socket cannot support other TCP ULP extensions. This includes KTLS.

KTLS is supported in GnuTLS and OpenSSL libraries. It is then tempting to use it without too much of an effort, e.g. lighttpd is using KTLS with OpenSSL and GnuTLS if available since January 2023.

It might be good to see if KTLS and MPTCP subflows hooks can be chained somehow.

[gstrauss]

FYI: lighttpd 1.4.68 (released Jan 2023) supports KTLS in lighttpd mod_openssl and lighttpd mod_gnutls

[matttbe]

FYI: lighttpd 1.4.68 (released Jan 2023) supports KTLS in lighttpd mod_openssl and lighttpd mod_gnutls

@gstrauss Thank you, I got the wrong version, I just updated the description to reflect that!

[matttbe]

@gstrauss if you don't mind me asking here, regarding KTLS and lighttpd, what's the main reason to support it? From what I read on your wiki, when the encryption is done by the kernel in software (TLS_SW), it looks like it helps in some specific situations, not all. From my understanding, KTLS is mainly useful when the encryption is done by the NIC (TLS_HW / TLS_HW_RECORD). But is it something common? What's the main reason to have it enabled by default?

This would help us to prioritise this task. The harder bit for us might be to get compatible HW.

[gstrauss]

what's the main reason to support it?

There are numerous reasons to support kTLS, though I won't try to enumerate them all here. As you noted, one is hardware encryption offload with supporting hardware. On the other hand, for simple hardware and embedded systems, being able to SSL_sendfile() efficiently (lower resource usage) sends a file directly from disk to kernel for encryption, rather than reading the file into userspace, encrypting, and transferring the encrypted data to the kernel. You do not need specialized hardware to realize this benefit. (Side note: SSL_sendfile() is more useful with HTTP/1.x requests, and not used with HTTP/2 requests where lighttpd still reads the file into userspace to perform HTTP/2 framing. Please make sure to test with HTTP/1.1.)

[matttbe]

@gstrauss thank you for your reply!

for simple hardware and embedded systems, being able to SSL_sendfile() efficiently (lower resource usage) sends a file directly from disk to kernel for encryption, rather than reading the file into userspace, encrypting, and transferring the encrypted data to the kernel. You do not need specialized hardware to realize this benefit.

I didn't know OpenSSL was using zero-copy + TLS, good to know this is used by well known libs.

[gstrauss]

I didn't know OpenSSL was using zero-copy + TLS, good to know this is used by well known libs.

For more details: See OpenSSL SSL_OP_ENABLE_KTLS_TX_ZEROCOPY_SENDFILE in https://www.openssl.org/docs/man3.3/man3/SSL_set_options.html or GnuTLS https://gnutls.org/reference/gnutls-gnutls.html#gnutls-record-send-file

[matttbe]

Thank you for the refs!

[geliangtang]

@matttbe Hi Matt, does anyone look at this issue? If not, I am willing to take a look. Please assign it to me.

[matttbe]

@geliangtang as far as I know, nobody is looking at this issue. I can assign you.

Please note that with KTLS, the encryption and decryption can be done in software (TLS_SW), or by the NIC (TLS_HW / TLS_HW_RECORD). At some points in the development (before sending any patches to Netdev), it will be needed to validate that with hardware supporting this feature.

I don't know the internals of KTLS, and even when TLS offload is used, but what I know is that KTLS was the first user of TCP ULP, and MPTCP is also using this framework for the subflows. Maybe it is not needed to "chain" ULPs, maybe hooks can be added in MPTCP code (MPTCP socket or subflows), as long as everything is still OK with MPTCP features: DSS, checksum, etc.

If you have issues, as always, don't hesitate to comment here in this ticket.