Lines Matching +full:segment +full:- +full:1 +full:a
1 .. SPDX-License-Identifier: GPL-2.0
7 TCP Authentication Option (TCP-AO) provides a TCP extension aimed at verifying
8 segments between trusted peers. It adds a new TCP header option with
9 a Message Authentication Code (MAC). MACs are produced from the content
10 of a TCP segment using a hashing function with a password known to both peers.
11 The intent of TCP-AO is to deprecate TCP-MD5 providing better security,
12 key rotation and support for a variety of hashing algorithms.
14 1. Introduction
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 +----------------------+------------------------+-----------------------+
33 |Number of keys per |1 |Many |
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
66 A: No [3.1]::
73 A: No, unless it's copied to Transport Control Block (TCB) [3.1]::
75 It is presumed that an MKT affecting a particular connection cannot
76 be destroyed during an active connection -- or, equivalently, that
84 A: Not specified by RFC 5925, seems to be a problem for key management
89 A: It can, it's a key management task to decide when to remove an old key [6.1]::
91 Deciding when to start using a key is a performance issue. Deciding
92 when to remove an MKT is a security issue. Invalid MKTs are expected
93 to be removed. TCP-AO provides no mechanism to coordinate their removal,
94 as we consider this a key management operation.
101 Linux TCP-AO will try its best to prevent you from removing a key that's
102 being used, considering it a key management failure. But since keeping
103 an outdated key may become a security issue and as a peer may
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.
112 Q: What happens when a packet is received on a new connection with no known
115 A: RFC 5925 specifies that by default it is accepted with a warning logged, but
116 the behaviour can be configured by the user [7.5.1.a]::
118 If the segment is a SYN, then this is the first segment of a new
119 connection. Find the matching MKT for this segment, using the segment's
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.
124 Proceed with further TCP handling of 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?)
150 A: Not specified. MKTs can be managed in userspace, the only relevant part to
156 Q: What happens when RNextKeyID requested by a peer is unknown? Should
159 A: It should not, no action needs to be performed [7.5.2.e]::
163 1. If the MKT corresponding to the segment’s socket pair and RNextKeyID
164 is not available, no action is required (RNextKeyID of a received
165 segment needs to match the MKT’s SendID).
167 Q: How is current_key set, and when does it change? Is it a user-triggered
168 change, or is it triggered by a request from the remote peer? Is it set by the
169 user explicitly, or by a matching rule?
171 A: current_key is set by RNextKeyID [6.1]::
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
177 the current_key to change to a new MKT, then change back to a previously
179 segments are received out of order, and is considered a feature of TCP-AO,
184 2. If the matching MKT corresponding to the segment’s socket pair and
187 a. Set current_key to the RNextKeyID MKT.
192 A: Some mechanism should pick the "desired" MKT [3.3]::
194 Multiple MKTs may match a single outgoing segment, e.g., when MKTs
197 given outgoing segment.
199 >> An outgoing TCP segment MUST match at most one desired MKT, indicated
200 by the segment’s socket pair. The segment MAY match multiple MKTs, provided
202 the segment MAY be used to determine the desired MKT when multiple MKTs
205 Q: Can TCP-MD5 connection migrate to TCP-AO (and vice-versa):
207 A: No [1]::
209 TCP MD5-protected connections cannot be migrated to TCP-AO because TCP MD5
210 does not support any changes to a connection’s security algorithm
213 Q: If all MKTs are removed on a connection, can it become a non-TCP-AO signed
216 A: [7.5.2] doesn't have the same choice as SYN packet handling in [7.5.1.i]
217 that would allow accepting segments without a sign (which would be insecure).
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
246 should perform ``setsockopt()`` on a TCP socket when it wants to add,
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 +----------------------+------------------------+-----------------------+
293 Linux provides a set of ``setsockopt()s`` and ``getsockopt()s`` that let
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.
302 provides userspace a way to delete a key that's being used and atomically set
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.
315 to list all MKTs on a TCP socket or use a filter to get keys for a specific
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.
352 TCP connection identifier. A TCP socket pair, i.e., a local IP
353 address, a remote IP address, a TCP local port, and a TCP remote port.
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
366 on a listen socket may have any amount of keys as well. As copying all those
367 keys on a first properly signed SYN would make the request socket bigger, that
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
376 The reverse is valid as well: if userspace adds a new key for a peer on
377 a listener socket, the established sockets in the accept queue won't
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
416 verified with SNE before the increment. As a result, there's
417 this [0; 32Kb] window, when packets with (SNE - 1) can be accepted.
419 Linux implementation simplifies this a bit: as the network stack already tracks
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
426 from the segment with snd_una or rcv_nxt and fits the result into a 2GB window around them,
427 detecting SEQ numbers rolling over. That simplifies the code a lot and only
428 requires SNE numbers to be stored on every TCP-AO socket.
432 a rollover. It allows more TCP segment replays, but yet all regular
433 TCP checks in tcp_sequence() are applied on the verified segment.
434 So, it trades a bit more permissive acceptance of replayed/retransmitted
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