Documentation/networking/tls-offload.rst

10 Linux kernel provides TLS connection offload infrastructure. Once a TCP
29  * Full TCP NIC offload mode (``TLS_HW_RECORD``) - mode of operation where
31    with its own TCP handling, it is not usable in production environments
43 mode) and then hands the modified scatter list to the TCP layer. From this
44 point on the TCP stack proceeds as normal.
56 :c:type:`struct sk_buff <sk_buff>`. The packets reach the TCP stack and
101 which TCP sequence number corresponds to the beginning of the record with
112 number, simplifying TCP sequence number matching.
124 so the initial records' TCP sequence number may be anywhere inside the segment.
135  * expected TCP sequence number
159 Both the device and the driver maintain expected TCP sequence numbers
168 It replaces the authentication tag and TCP checksum with correct values.
177 lookup is sufficient - IP addresses and TCP port numbers, as the protocol
178 is always TCP). If connection is matched device confirms if the TCP sequence
196 TCP stack.
219 together with its TCP sequence number and TLS record number. The device
248 Until resync is complete driver should not access its expected TCP
256 Next time ``ktls`` pushes a record it will first send its TCP sequence number
307 When the device gets out of sync and the stream reaches TCP sequence
308 numbers more than a max size record past the expected TCP sequence number,
347 the next expected record number and its TCP sequence number. If the
404 Note that each TCP connection requires a TLS session in both directions,
497 TCP segments (i.e. placing packets in the correct order) but any form
503 Offloaded ``ktls`` sockets should support standard TCP stack features
522 on TCP retransmissions to handle corner cases is not acceptable.