Lines Matching +full:non +full:- +full:overlap +full:- +full:time
1 .. SPDX-License-Identifier: GPL-2.0
7 TCP Authentication Option (TCP-AO) provides a TCP extension aimed at verifying
11 The intent of TCP-AO is to deprecate TCP-MD5 providing better security,
17 .. table:: Short and Limited Comparison of TCP-AO and TCP-MD5
19 +----------------------+------------------------+-----------------------+
20 | | TCP-MD5 | TCP-AO |
22 |Supported hashing |MD5 |Must support HMAC-SHA1 |
23 |algorithms |(cryptographically weak)|(chosen-prefix attacks)|
24 | | |and CMAC-AES-128 (only |
25 | | |side-channel attacks). |
28 +----------------------+------------------------+-----------------------+
29 |Length of MACs (bytes)|16 |Typically 12-16. |
32 +----------------------+------------------------+-----------------------+
35 +----------------------+------------------------+-----------------------+
36 |Possibility to change |Non-practical (both |Supported by protocol |
39 +----------------------+------------------------+-----------------------+
43 +----------------------+------------------------+-----------------------+
44 |Protection against |No |Yes: pseudo-header |
45 |traffic-crossing | |includes TCP ports. |
47 +----------------------+------------------------+-----------------------+
52 +----------------------+------------------------+-----------------------+
55 +----------------------+------------------------+-----------------------+
57 +----------------------+------------------------+-----------------------+
61 ----------------------------------------------------------------
63 Q: Can either SendID or RecvID be non-unique for the same 4-tuple
68 >> The IDs of MKTs MUST NOT overlap where their TCP connection
69 identifiers overlap.
76 be destroyed during an active connection -- or, equivalently, that
93 to be removed. TCP-AO provides no mechanism to coordinate their removal,
101 Linux TCP-AO will try its best to prevent you from removing a key that's
105 it as RNextKeyID - a forced key removal mechanism is provided, where
108 still requesting it. There are no guarantees for force-delete as the peer
109 may yet not have the new key - the TCP connection may just break.
120 socket pair and its TCP-AO KeyID, matched against the MKT's TCP connection
123 i. If there is no matching MKT, remove TCP-AO from the segment.
130 >> A TCP-AO implementation MUST allow for configuration of the behavior
131 of segments with TCP-AO but that do not match an MKT. The initial default
134 connections, or the connection can indicate that TCP-AO is required.
140 Connections not matching any MKT do not require TCP-AO. Further, incoming
141 segments with TCP-AO are not discarded solely because they include
144 Note that Linux TCP-AO implementation differs in this aspect. Currently, TCP-AO
148 (i.e. that a key on all connections MUST be rotated at the same time?)
167 Q: How is current_key set, and when does it change? Is it a user-triggered
174 protocol operation. It is not manipulated by TCP-AO. Current_key is updated
175 by TCP-AO when processing received TCP segments as discussed in the segment
179 segments are received out of order, and is considered a feature of TCP-AO,
205 Q: Can TCP-MD5 connection migrate to TCP-AO (and vice-versa):
209 TCP MD5-protected connections cannot be migrated to TCP-AO because TCP MD5
213 Q: If all MKTs are removed on a connection, can it become a non-TCP-AO signed
218 While switching to non-TCP-AO connection is not prohibited directly, it seems
219 what the RFC means. Also, there's a requirement for TCP-AO connections to
222 TCP-AO requires that every protected TCP segment match exactly one MKT.
226 >> An incoming TCP segment including TCP-AO MUST match exactly one MKT,
227 indicated solely by the segment’s socket pair and its TCP-AO KeyID.
234 Q: Can a non-TCP-AO connection become a TCP-AO-enabled one?
236 A: No: for an already established non-TCP-AO connection it would be impossible
237 to switch to using TCP-AO, as the traffic key generation requires the initial
238 sequence numbers. Paraphrasing, starting using TCP-AO would require
239 re-establishing the TCP connection.
241 2. In-kernel MKTs database vs database in userspace
244 Linux TCP-AO support is implemented using ``setsockopt()s``, in a similar way
245 to TCP-MD5. It means that a userspace application that wants to use TCP-AO
251 (with less locking needed than in the case of an in-kernel database). One also
255 ``setsockopt()s`` for TCP-MD5 support.
259 +----------------------+------------------------+-----------------------+
260 | | ``setsockopt()`` | in-kernel DB |
265 +----------------------+------------------------+-----------------------+
267 | changes | that wants TCP-AO needs| as tunnels, providing |
271 +----------------------+------------------------+-----------------------+
273 +----------------------+------------------------+-----------------------+
274 | Dump-ability | ``getsockopt()`` | Netlink .dump() |
276 +----------------------+------------------------+-----------------------+
279 +----------------------+------------------------+-----------------------+
282 +----------------------+------------------------+-----------------------+
284 +----------------------+------------------------+-----------------------+
285 | Matching of MKTs | half-problem: only | hard |
287 +----------------------+------------------------+-----------------------+
294 userspace manage TCP-AO on a per-socket basis. In order to add/delete MKTs
296 It is not allowed to add a key on an established non-TCP-AO connection
297 as well as to remove the last key from TCP-AO connection.
305 It provides a way to force-delete a key that's not trusted but may break
306 the TCP-AO connection.
308 The usual/normal key-rotation can be performed with ``setsockopt(TCP_AO_INFO)``.
309 It also provides a uAPI to change per-socket TCP-AO settings, such as
310 ignoring ICMPs, as well as clear per-socket TCP-AO packet counters.
312 per-socket TCP-AO settings.
318 To repair TCP-AO connections ``setsockopt(TCP_AO_REPAIR)`` is available,
322 A tip here for scaled TCP_LISTEN sockets, that may have some thousands TCP-AO
326 Linux TCP-AO also provides a bunch of segment counters that can be helpful
329 Each TCP-AO socket has the following counters:
330 - for good segments (properly signed)
331 - for bad segments (failed TCP-AO verification)
332 - for segments with unknown keys
333 - for segments where an AO signature was expected, but wasn't found
334 - for the number of ignored ICMPs
336 TCP-AO per-socket counters are also duplicated with per-netns counters,
340 For monitoring purposes, there are following TCP-AO trace events:
345 one can filter them by net-namespace, 4-tuple, family, L3 index, and TCP header
346 flags. If a segment has a TCP-AO header, the filters may also include
347 keyid, rnext, and maclen. SNE updates include the rolled-over numbers.
354 Values can be partially specified using ranges (e.g., 2-30), masks
357 Currently Linux TCP-AO implementation doesn't provide any TCP port matching.
364 In contrast with an established TCP-MD5 connection which has just one key,
365 TCP-AO connections may have many keys, which means that accepted connections
371 The result is that when userspace removes TCP-AO keys, that may break
372 not-yet-established connections on request sockets as well as not removing
387 This is a similar "do-nothing" approach to TCP-MD5 from the kernel side and
391 Note that this race is rare for it needs TCP-AO key rotation to happen
392 during the 3-way handshake for the new TCP connection.
394 5. Interaction with TCP-MD5
397 A TCP connection can not migrate between TCP-AO and TCP-MD5 options. The
402 both TCP-AO and (deprecated) TCP-MD5 clients. As a result, both types of keys
417 this [0; 32Kb] window, when packets with (SNE - 1) can be accepted.
421 is wanted (rcv_nxt) - that's enough information for a rough estimation
425 tcp_ao_compute_sne() is called for each TCP-AO segment. It compares SEQ numbers
428 requires SNE numbers to be stored on every TCP-AO socket.
442 https://www.rfc-editor.org/rfc/pdfrfc/rfc5925.txt.pdf
444 RFC 5926 Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)
445 https://www.rfc-editor.org/rfc/pdfrfc/rfc5926.txt.pdf
447 Draft "SHA-2 Algorithm for the TCP Authentication Option (TCP-AO)"
448 https://datatracker.ietf.org/doc/html/draft-nayak-tcp-sha2-03
451 https://www.rfc-editor.org/rfc/pdfrfc/rfc2385.txt.pdf