tjh.dev
+15
-14
Documentation/networking/tls-offload.rst
+15
-14
Documentation/networking/tls-offload.rst
···
51
51
RX
52
52
--
53
53
54
-
On the receive side if the device handled decryption and authentication
54
+
On the receive side, if the device handled decryption and authentication
55
55
successfully, the driver will set the decrypted bit in the associated
56
56
:c:type:`struct sk_buff <sk_buff>`. The packets reach the TCP stack and
57
57
are handled normally. ``ktls`` is informed when data is queued to the socket
···
120
120
RX
121
121
--
122
122
123
-
In RX direction local networking stack has little control over the segmentation,
124
-
so the initial records' TCP sequence number may be anywhere inside the segment.
123
+
In the RX direction, the local networking stack has little control over
124
+
segmentation, so the initial records' TCP sequence number may be anywhere
125
+
inside the segment.
125
126
126
127
Normal operation
127
128
================
···
139
138
segments may start at any point of a record and contain any number of records.
140
139
Assuming segments are received in order, the device should be able to perform
141
140
crypto operations and authentication regardless of segmentation. For this
142
-
to be possible device has to keep small amount of segment-to-segment state.
143
-
This includes at least:
141
+
to be possible, the device has to keep a small amount of segment-to-segment
142
+
state. This includes at least:
144
143
145
144
* partial headers (if a segment carried only a part of the TLS header)
146
145
* partial data block
···
176
175
checksum and performs a 5-tuple lookup to find any TLS connection the packet
177
176
may belong to (technically a 4-tuple
178
177
lookup is sufficient - IP addresses and TCP port numbers, as the protocol
179
-
is always TCP). If connection is matched device confirms if the TCP sequence
180
-
number is the expected one and proceeds to TLS handling (record delineation,
181
-
decryption, authentication for each record in the packet). The device leaves
182
-
the record framing unmodified, the stack takes care of record decapsulation.
183
-
Device indicates successful handling of TLS offload in the per-packet context
184
-
(descriptor) passed to the host.
178
+
is always TCP). If the packet is matched to a connection, the device confirms
179
+
if the TCP sequence number is the expected one and proceeds to TLS handling
180
+
(record delineation, decryption, authentication for each record in the packet).
181
+
The device leaves the record framing unmodified, the stack takes care of record
182
+
decapsulation. Device indicates successful handling of TLS offload in the
183
+
per-packet context (descriptor) passed to the host.
185
184
186
185
Upon reception of a TLS offloaded packet, the driver sets
187
186
the :c:member:`decrypted` mark in :c:type:`struct sk_buff <sk_buff>`
···
440
439
* ``rx_tls_resync_req_end`` - number of times the TLS async resync request
441
440
properly ended with providing the HW tracked tcp-seq.
442
441
* ``rx_tls_resync_req_skip`` - number of times the TLS async resync request
443
-
procedure was started by not properly ended.
442
+
procedure was started but not properly ended.
444
443
* ``rx_tls_resync_res_ok`` - number of times the TLS resync response call to
445
444
the driver was successfully handled.
446
445
* ``rx_tls_resync_res_skip`` - number of times the TLS resync response call to
···
508
507
Transport layer transparency
509
508
----------------------------
510
509
511
-
The device should not modify any packet headers for the purpose
512
-
of the simplifying TLS offload.
510
+
For the purpose of simplifying TLS offload, the device should not modify any
511
+
packet headers.
513
512
514
513
The device should not depend on any packet headers beyond what is strictly
515
514
necessary for TLS offload.