RFC 5925
The TCP Authentication Option
RFC 5925: The TCP Authentication Option 🎀
okay bestie, let's get into it 💖 this is RFC 5925, titled "The TCP Authentication Option," and it came out in June 2010.
- Authors: J. Touch (USC/ISI), A. Mankin (Johns Hopkins Univ.), and R. Bonica (Juniper Networks)
- Category: Standards Track ✨
- ISSN: 2070-1721
- Obsoletes: RFC 2385 (the old TCP MD5 option) 💅
- Updates: nothing is listed here
Abstract 🦋
okay so this doc specifies the TCP Authentication Option (TCP-AO), and it's basically the glow-up for TCP MD5 from RFC 2385 🔥 TCP-AO brings in stronger Message Authentication Codes (MACs), protects against replays even on long-lived TCP connections, and explains way more about how security gets tied to TCP connections than TCP MD5 ever did 💜
it works with either a static Master Key Tuple (MKT) setup or an external, out-of-band MKT management mechanism 🌸 either way, TCP-AO still protects connections that reuse the same MKT across repeated instances of a connection. it uses traffic keys derived from the MKT and coordinates MKT changes between endpoints 🫶
the goal is to keep current TCP MD5 uses working, like protecting long-lived connections in BGP and LDP 🌈 and to support a bigger set of MACs without a bunch of other system and operational changes ✨ TCP-AO uses a different option identifier than TCP MD5, even though the two are never allowed to be used at the same time 🙈 it supports IPv6 too, and it's fully compatible with the proposed requirements for replacing TCP MD5 👑
Status of This Memo 🌈
this is an Internet Standards Track document 💅
this doc is a product of the Internet Engineering Task Force (IETF). it represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG) 🎀 for more on Internet Standards, check Section 2 of RFC 5741 ✨
for the current status of this doc, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc5925 🔗
Copyright Notice 💜
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. 💖
this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they're in effect on the date of publication. please read these carefully, because they explain your rights and restrictions for this document 🫶 any Code Components pulled out of this document must include the Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License says 🍓
Table of Contents 🧚
1. Introduction ....................................................4
1.1. Conventions Used in This Document ..........................4
1.2. Applicability Statement ....................................5
1.3. Executive Summary ..........................................6
2. The TCP Authentication Option ...................................7
2.1. Review of TCP MD5 Option ...................................7
2.2. The TCP Authentication Option Format .......................8
3. TCP-AO Keys and Their Properties ...............................10
3.1. Master Key Tuple ..........................................10
3.2. Traffic Keys ..............................................12
3.3. MKT Properties ............................................13
4. Per-Connection TCP-AO Parameters ...............................14
5. Cryptographic Algorithms .......................................15
5.1. MAC Algorithms ............................................15
5.2. Traffic Key Derivation Functions ..........................18
5.3. Traffic Key Establishment and Duration Issues .............22
5.3.1. MKT Reuse Across Socket Pairs ......................22
5.3.2. MKTs Use within a Long-Lived Connection ............23
6. Additional Security Mechanisms .................................23
6.1. Coordinating Use of New MKTs ..............................23
6.2. Preventing Replay Attacks within Long-Lived Connections ...24
7. TCP-AO Interaction with TCP ....................................26
7.1. TCP User Interface ........................................27
7.2. TCP States and Transitions ................................28
7.3. TCP Segments ..............................................28
7.4. Sending TCP Segments ......................................29
7.5. Receiving TCP Segments ....................................30
7.6. Impact on TCP Header Size .................................32
7.7. Connectionless Resets .....................................33
7.8. ICMP Handling .............................................34
8. Obsoleting TCP MD5 and Legacy Interactions .....................35
9. Interactions with Middleboxes ..................................35
9.1. Interactions with Non-NAT/NAPT Middleboxes ................36
9.2. Interactions with NAT/NAPT Devices ........................36
10. Evaluation of Requirements Satisfaction .......................36
11. Security Considerations .......................................42
12. IANA Considerations ...........................................43
13. References ....................................................44
13.1. Normative References .....................................44
13.2. Informative References ...................................45
14. Acknowledgments ...............................................471. Introduction 🌸
okay so the TCP MD5 Signature (TCP MD5) is a TCP option that authenticates TCP segments, including the TCP IPv4 pseudoheader, the TCP header, and the TCP data ✨ it was built to protect BGP sessions from spoofed TCP segments, because those could mess with BGP data or with the robustness of the TCP connection itself 🫶 [RFC2385][RFC4953]
ngl there have been a lot of recent concerns about TCP MD5 🙈 its use of a simple keyed hash for authentication is a problem, because there have been escalating attacks on the algorithm itself [Wa05]. TCP MD5 also doesn't have key management or algorithm agility 💀 this doc adds the agility part, and it gives a simple key coordination mechanism so you can move from one key to another within the same connection 🦋
it does not provide complete cryptographic key management in band of TCP, though. that's because TCP SYN segments don't have enough leftover space to handle that kind of negotiation (see Section 7.6) 🥺 this doc obsoletes the TCP MD5 option with a more general TCP Authentication Option (TCP-AO) 👑 the new option supports other, stronger hash functions, gives replay protection for long-lived connections and across repeated instances of a single connection, coordinates key changes between endpoints, and offers a more explicit recommendation for external key management 💅 the result is compatible with IPv6 and fully compatible with the proposed requirements for a replacement for TCP MD5 [Ed07] 🌈
TCP-AO obsoletes TCP MD5, although a particular implementation may support both mechanisms for backward compatibility 🎀 for any given connection, only one can be in use 🙅♀️ TCP MD5-protected connections can't be migrated to TCP-AO, because TCP MD5 doesn't support any changes to a connection's security algorithm once it's been established 💔
1.1. Conventions Used in This Document 🧚
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be interpreted as described in RFC 2119 [RFC2119] 💖
these words only carry that meaning when they're in ALL CAPS 🫶 lowercase uses of these words don't carry RFC 2119 significance 🙈
the characters >> preceding an indented line (or lines) mark a compliance requirement statement using the key words listed above 🍓 this makes it way easier for reviewers to spot the explicit compliance requirements in this RFC ✨
1.2. Applicability Statement 🦋
TCP-AO is meant to support current uses of TCP MD5, like protecting long-lived connections for routing protocols such as BGP and LDP 🌈 it's also meant to give similar protection to any long-lived TCP connection, like the ones used between proxy caches, for example. it's not designed solely or primarily for routing protocol uses 💜
TCP-AO is meant to replace (and therefore obsolete) TCP MD5 ✨ it enhances TCP MD5's capabilities, as summarized in Section 1.3 🎀 overall, this document recommends that:
>> TCP implementations that support TCP MD5 MUST support TCP-AO. 👑
>> TCP-AO SHOULD be implemented where the protection afforded by TCP authentication is needed, because either IPsec is not supported or TCP-AO's particular properties are needed (e.g., per-connection keys). 💅
>> TCP-AO MAY be implemented elsewhere. 🌸
TCP-AO is not meant to replace the IPsec suite (IPsec and the Internet Key Exchange Protocol (IKE)) for protecting TCP connections [RFC4301][RFC4306] 🫶 the specific differences are noted in Section 1.3 🙌 honestly, we recommend using IPsec and IKE, especially where IKE's existing support for parameter negotiation, session key negotiation, or rekeying is wanted 🔥 TCP-AO is intended for use only where the IPsec suite wouldn't be feasible. for example, that's been suggested as the case for supporting some routing protocols [RFC4953], or in cases where keys need to be tightly coordinated with individual transport sessions [Ed07] 🥹
TCP-AO is also not meant to replace Transport Layer Security (TLS) [RFC5246], Secure BGP (sBGP), Secure Origin BGP (soBGP) [Le09], or any other mechanisms that protect only the TCP data stream 🍓 TCP-AO protects the transport layer and stops attacks from disabling the TCP connection itself [RFC4953] 🛡️ data stream mechanisms only protect the contents of the TCP segments, and they can get disrupted when the connection is affected 😭 some of these data protection protocols, notably TLS, offer a richer set of key management and authentication mechanisms than TCP-AO does, so they protect the data stream in a different way ✨ TCP-AO can be used together with these data stream protections so they complement each other's strengths 🧚💜
1.3. Executive Summary 💖
Okay so, TCP-AO is basically the glow-up of TCP MD5 [RFC2385], and here's everything it changes 💅:
- TCP-AO uses a separate option Kind (29). 🎀
- TCP-AO lets TCP MD5 keep running alongside it for legacy connections, so nobody gets left on read. 🦋
- TCP-AO swaps out TCP MD5's single MAC algorithm for MACs defined in a separate document, and it can be extended to include other MACs. 🔥
- TCP-AO allows rekeying during a TCP connection, as long as an out-of-band protocol or a manual mechanism hands over the new keys. 🔑 The option carries a 'key ID' so multiple keys can be used efficiently at the same time. A key coordination mechanism built on a 'receive next key ID' handles the key change within a connection. ngl this is the part I'm obsessed with ✨. Also, TCP MD5 doesn't stop you from rekeying mid-connection, it just doesn't require support for it either. TCP-AO goes further and supports key changes with zero segment loss. TCP MD5 can drop segments in transit during the changeover, or make you try multiple keys on every received segment while the keys overlap, because it has no explicit key ID. TCP does recover lost segments through retransmission, but loss can still hit performance hard 😭.
- TCP-AO provides automatic replay protection for long-lived connections using sequence number extensions. 🛡️
- TCP-AO keeps per-connection traffic keys unique, as unique as the TCP connection itself. It uses TCP's Initial Sequence Numbers (ISNs) to tell them apart, even when the same static master key tuples get reused across repeated instances of connections on a single socket pair. The main character energy is unmatched 👑.
- TCP-AO spells out how the option interacts with TCP's states, event processing, and user interface. 🧚
- TCP-AO is 2 bytes shorter than TCP MD5 (16 bytes overall instead of 18) in the initially specified default case, which uses a 96-bit MAC. Small but mighty 🍓.
TCP-AO is also different from an IPsec/IKE solution [RFC4301][RFC4306], and here's how:
- TCP-AO does not support dynamic parameter negotiation. 🙈
- TCP-AO puts TCP's socket pair (source address, destination address, source port, destination port) into the security parameter index, along with the KeyID. IPsec instead uses a separate field as the index, called the Security Parameter Index (SPI). 🌈
- TCP-AO forces a change of computed MACs whenever a connection restarts, even when the TCP socket pair (IP addresses and port numbers) is reused [Ed07]. Fresh start, fresh vibes ✨.
- TCP-AO does not support encryption. 🔒
- TCP-AO does not authenticate ICMP messages. Some ICMP messages may be authenticated when using IPsec, depending on the configuration 🤷♀️.
2. The TCP Authentication Option 🎀
The TCP Authentication Option (TCP-AO) uses a TCP option Kind value of 29. The next sections describe TCP-AO and include a quick review of TCP MD5 so you can compare the two 🫶.
2.1. Review of TCP MD5 Option 🦋
Let's start with a refresher. The TCP MD5 option is shown in Figure 1:
+---------+---------+-------------------+
| Kind=19 |Length=18| MD5 digest... |
+---------+---------+-------------------+
| ...digest (con't)... |
+---------------------------------------+
| ... |
+---------------------------------------+
| ... |
+-------------------+-------------------+
| ...digest (con't) |
+-------------------+Figure 1: The TCP MD5 Option [RFC2385]
In the TCP MD5 option, the length is fixed. The MD5 digest takes up 16 bytes after the Kind and Length fields (each one byte), using the full MD5 digest of 128 bits [RFC1321]. Simple and iconic 💜.
The TCP MD5 option computes the MD5 digest over the following values, in this order:
- The IP pseudoheader (IP source and destination addresses, protocol number, and segment length).
- The TCP header excluding options and checksum.
- The TCP data payload.
- A key.
2.2. The TCP Authentication Option Format 🌸
TCP-AO is a superset of what TCP MD5 can do, and it's kept minimal in the spirit of SP4 [SDNS88]. It uses a new Kind field, a Length field similar to TCP MD5's, a KeyID field, and an RNextKeyID field, all laid out in Figure 2:
+------------+------------+------------+------------+
| Kind=29 | Length | KeyID | RNextKeyID |
+------------+------------+------------+------------+
| MAC ...
+-----------------------------------...
...-----------------+
... MAC (con't) |
...-----------------+Figure 2: The TCP Authentication Option (TCP-AO)
TCP-AO defines these fields as follows:
- Kind: An unsigned 1-byte field indicating TCP-AO. TCP-AO uses a new Kind value of 29. ✨
- An endpoint MUST NOT use TCP-AO for the same connection in which TCP MD5 is used. When both options appear, TCP MUST silently discard the segment. 🚫
- A single TCP segment MUST NOT have more than one TCP-AO in its options sequence. When multiple TCP-AOs appear, TCP MUST discard the segment. 🙅♀️
- Length: An unsigned 1-byte field indicating the length of the option in bytes, including the Kind, Length, KeyID, RNextKeyID, and MAC fields. 📏
- The Length value MUST be greater than or equal to 4. When the Length value is less than 4, TCP MUST discard the segment. 🙃
- The Length value MUST be consistent with the TCP header length. When the Length value is invalid, TCP MUST discard the segment. 💀
This Length check implies that the sum of the sizes of all options, when added to the size of the base TCP header (5 words), matches the TCP Offset field exactly. The full verification can be computed because RFC 793 specifies the size of the required options, and RFC 1122 requires that all new options follow a common format with a fixed-length field location [RFC793][RFC1122]. If you only want a partial verification, you can check just TCP-AO: the TCP-AO length, added to the TCP-AO offset from the start of the TCP header, must not exceed the TCP header size as indicated in the TCP header Offset field.
Values of 4 and other small values larger than 4 (e.g., indicating MAC fields of very short length) are of dubious utility, but they are not specifically prohibited. Not the vibe, but legal 🤷♀️.
- KeyID: An unsigned 1-byte field indicating the Master Key Tuple (MKT, as defined in Section 3.1) used to generate the traffic keys that were used to generate the MAC that authenticates this segment. 🔑
It supports efficient key changes during a connection and/or helps with key coordination during connection establishment. More on that in Section 6.1. Note that the KeyID has no cryptographic properties -- it need not be random, nor are there any reserved values.
- KeyID values MAY be the same in both directions of a connection, but they do not have to be, and there is no special meaning when they are.
This lets MKTs get installed on a set of devices without coordinating the KeyIDs across that entire set in advance, and it lets new devices join the set using a group of MKTs later without renumbering the KeyIDs. Both of these capabilities matter a lot when you use wildcards in the TCP socket pair of the MKT, i.e., when an MKT is used among a set of devices specified by a pattern (as noted in Section 3.1). 🧩
- RNextKeyID: An unsigned 1-byte field indicating the MKT that is ready at the sender to be used to authenticate received segments, i.e., the desired 'receive next' key ID. 🔁
It supports efficient key change coordination, more on which in Section 6.1. Note that the RNextKeyID has no cryptographic properties -- it need not be random, nor are there any reserved values.
- MAC: Message Authentication Code. Its contents are determined by the particulars of the security association. Typical MACs are 96-128 bits (12-16 bytes), but any length that fits in the header of the segment being authenticated is allowed. The MAC computation is described further in Section 5.1. 🪪
- Required support for TCP-AO MACs is defined in [RFC5926]; other MACs MAY be supported. 🌟
TCP-AO fields do not indicate the MAC algorithm either implicitly (as with TCP MD5) or explicitly. The particular algorithm used is considered part of the configuration state of the connection's security, and it's managed separately (see Section 3). Keeping it separate is very intentional 💅.
Please note that the use of TCP-AO does not affect TCP's advertised Maximum Segment Size (MSS), as is the case for all TCP options [Bo09]. No MSS drama here 🎉.
The rest of this document explains how TCP-AO is handled and how it relates to TCP. Stay tuned 🦋.
3. TCP-AO Keys and Their Properties 🔑
TCP-AO relies on two sets of keys to authenticate incoming and outgoing segments: Master Key Tuples (MKTs) and traffic keys. 🗝️ MKTs are used to derive unique traffic keys. They include the keying material used to generate those traffic keys, and they also indicate the associated parameters under which traffic keys are used. Those parameters include whether TCP options are authenticated, and indicators of the algorithms used for traffic key derivation and MAC calculation. Traffic keys are the keying material used to compute the MAC of individual TCP segments. So the MKT is the parent, and the traffic key is the baby 👶💜.
3.1. Master Key Tuple
okay so the Master Key Tuple (MKT) is basically the recipe card 🍓 that tells TCP-AO which properties to use for one or more connections. It's made up of these bits:
- TCP connection identifier. This is a TCP socket pair: a local IP address, a remote IP address, a TCP local port, and a TCP remote port. Values can be partly specified with ranges (like
2-30), masks (like0xF0), wildcards (like"*"), or any other suitable indication 💅 - TCP option flag. This flag tells you whether TCP options other than TCP-AO get counted in the MAC calculation 👀 When they do, the content of every option gets included in the order it shows up, with TCP-AO's MAC field zeroed out. When they don't, all the other options get skipped completely (not zeroed, just skipped) 🙈 Even with the flag off, TCP-AO itself is always included with its MAC field zeroed out. That protects the MAC length indication and the key ID fields (KeyID and RNextKeyID), so it's lowkey the most important part ✨ The flag applies to TCP options in both directions, incoming and outgoing segments.
- IDs. These are the values used in the KeyID or RNextKeyID of TCP-AO. They tell MKTs apart when several are in use at once (KeyID), and they show when an MKT is ready to use in the other direction (RNextKeyID) 🦋
Each MKT has two IDs - -- a SendID and a RecvID. The SendID gets stuck into the KeyID of the TCP-AO option on outgoing segments, and the RecvID gets matched against the TCP-AO KeyID on incoming segments. You'll see more about how these two get used in Sections 7.4 and 7.5 🫶
MKT IDs MUST support any value, 0-255 inclusive. There are no reserved ID values. 🔥
ID values are assigned arbitrarily. That means they aren't monotonically increasing, nothing is reserved, and the numbers don't mean anything on their own 🌈 They can be handed out in sequence, or based on any method the connection endpoints agree on (for example, using an external MKT management mechanism).
IDs MUST NOT be assumed to be randomly assigned. 🙅♀️
- Master key. This is a byte sequence used for generating traffic keys. It may be derived from a separate shared key by an external protocol running over a separate channel 🔑 This sequence goes into the traffic key generation algorithm described in Section 5.2.
Implementations are advised to keep master key values in a private, protected area of memory or other storage. 🔒
- Key Derivation Function (KDF). This indicates the key derivation function and its parameters, which get used to generate traffic keys from master keys. It's explained further in Section 5.2 of this document and specified in detail in [RFC5926] 🧁
- Message Authentication Code (MAC) algorithm. This indicates the MAC algorithm and its parameters for this connection. It's explained further in Section 5.1 of this document and specified in detail in [RFC5926] 💜
Components of an MKT MUST NOT change during a connection. ✋
MKT component values can't change during a connection because TCP state gets coordinated during connection establishment. TCP doesn't have a handshake for changing that state once a connection is already up, so it's a no-go 🙃
The set of MKTs MAY change during a connection. ✨
Here's the thing: MKT parameters themselves don't change. Instead, new MKTs get installed, and a connection can switch which MKT it's using 💖
The IDs of MKTs MUST NOT overlap where their TCP connection identifiers overlap. 💅
This document doesn't cover how users or processes create MKTs. It's presumed that an MKT affecting a particular connection can't be destroyed while that connection is active. Or, equivalently, its parameters get copied into an area local to the connection (that's called instantiation), so changes would only affect new connections 🌸 MKTs can be managed by a separate application protocol.
3.2. Traffic Keys
A traffic key is a key derived from the MKT, the local and remote IP address pairs, the TCP port numbers, and, for established connections, the TCP Initial Sequence Numbers (ISNs) in each direction 🧚 Segments exchanged before a connection is established use the same information, except that zero stands in for any unknown values (like ISNs that haven't been coordinated yet).
A single MKT can be used to derive any of four different traffic keys:
- Send_SYN_traffic_key
- Receive_SYN_traffic_key
- Send_other_traffic_key
- Receive_other_traffic_key
Keys are unidirectional, so note that 🫶 A given connection typically uses only three of these keys, because only one of the SYN keys is usually needed. All four only come into play when a connection goes through 'simultaneous open' [RFC793] 👑
Figure 3 shows how MKTs and traffic keys relate. Traffic keys are marked with a "*". Every MKT can be used to derive any of the four traffic keys, but only the keys that are actually needed to handle a connection's segments need to be computed 🦋 Section 5.2 has more details on how traffic keys get derived.
MKT-A MKT-B
+---------------------+ +------------------------+
| SendID = 1 | | SendID = 5 |
| RecvID = 2 | | RecvID = 6 |
| MAC = HMAC-SHA1 | | MAC = AES-CMAC |
| KDF = KDF-HMAC-SHA1 | | KDF = KDF-AES-128-CMAC |
+---------------------+ +------------------------+
| |
+----------+----------+ |
| | |
v v v
Connection 1 Connection 2 Connection 3
+------------------+ +------------------+ +------------------+
| * Send_SYN_key | | * Send_SYN_key | | * Send_SYN_key |
| * Recv_SYN_key | | * Recv_SYN_key | | * Recv_SYN_key |
| * Send_Other_key | | * Send_Other_key | | * Send_Other_key |
| * Recv_Other_key | | * Recv_Other_key | | * Recv_Other_key |
+------------------+ +------------------+ +------------------+
Figure 3: Relationship between MKTs and Traffic Keys3.3. MKT Properties
TCP-AO requires that every protected TCP segment match exactly one MKT. When an outgoing segment matches an MKT, TCP-AO gets used. When nothing matches, TCP-AO doesn't get used 🌷 More than one MKT can match a single outgoing segment (for example, when MKTs are being swapped out). Those MKTs can't have conflicting IDs, as noted elsewhere, and some mechanism has to decide which MKT to use for each outgoing segment.
An outgoing TCP segment MUST match at most one desired MKT, indicated by the segment's socket pair. The segment MAY match multiple MKTs, provided that exactly one MKT is indicated as desired. Other information in the segment MAY be used to determine the desired MKT when multiple MKTs match; such information MUST NOT include values in any TCP option fields. 🧐
We recommend that the mechanism used to pick from among multiple MKTs only use information that TCP-AO would authenticate. Because MKTs may indicate that options other than TCP-AO are ignored in the MAC calculation, we recommend that TCP options should not be used to determine MKTs. 🙈
An incoming TCP segment including TCP-AO MUST match exactly one MKT, indicated solely by the segment's socket pair and its TCP-AO KeyID. 🎯
Incoming segments carry an indicator inside TCP-AO to pick from among multiple matching MKTs, and that's the KeyID field. TCP-AO requires that the KeyID alone be used to tell apart multiple matching MKTs, so MKT changes can be coordinated using the TCP-AO key change coordination mechanism 💫
When an outgoing TCP segment matches no MKTs, TCP-AO is not used. 🙅♀️
TCP-AO is always used when outgoing segments match an MKT, and it isn't used otherwise. Simple as that 💖
4. Per-Connection TCP-AO Parameters ✨
TCP-AO uses a small number of parameters for each connection that uses it, once those have been instantiated 🎀 These values can be stored in the Transport Control Block (TCB) [RFC793]. They're explained in later sections of this document as noted, and they include:
- Current_key - the MKT currently used to authenticate outgoing segments. Its SendID gets inserted in outgoing segments as the KeyID (see Section 7.4, step 2.f). Incoming segments are authenticated using the MKT that matches the segment's TCP connection identifier and its TCP-AO KeyID, compared against the MKT TCP connection identifier and the MKT RecvID (see Section 7.5, step 2.c). There is only one current_key at any given time on a particular connection.
Every TCP connection in a non-IDLE state MUST have at most one current_key specified. 👑
- Rnext_key - the MKT currently preferred for incoming (received) segments. Its RecvID gets inserted in outgoing segments as RNextKeyID (see Section 7.4, step 2.d).
Each TCP connection in a non-IDLE state MUST have at most one rnext_key specified. 🌈
- A pair of Sequence Number Extensions (SNEs). SNEs are used to prevent replay attacks, as described in Section 6.2. Each SNE is initialized to zero upon connection establishment. Its use in the MAC calculation is described in Section 5.1. 🛡️
- One or more MKTs. These are the MKTs that match this connection's socket pair. 🧩
MKTs get used, together with the other parameters of a connection, to create traffic keys that are unique to each connection, as described in Section 5.2. Those traffic keys can be cached after they're computed, and they can be stored in the TCB alongside the corresponding MKT information. They can be considered part of the per-connection parameters 🍭
5. Cryptographic Algorithms 🧪
TCP-AO uses cryptographic algorithms to compute the MAC (Message Authentication Code) that authenticates a segment and its headers. These are called MAC algorithms and are specified in a separate document, which makes it easier to update the algorithm requirements independently of the protocol [RFC5926] 💅 TCP-AO also uses cryptographic algorithms to turn MKTs, which can be shared across connections, into unique traffic keys for each connection. These are called Key Derivation Functions (KDFs) and are specified in [RFC5926] ✨ This section describes how TCP-AO uses these algorithms.
5.1. MAC Algorithms ✨
okay so MAC algorithms are basically the bouncers of TCP-AO 💅 They take a variable-length input plus a key and spit out a fixed-length number. That number tells you two things: did this come from someone who has the same key, and did anyone mess with it on the way over? 🔐 The interface looks like this:
MAC = MAC_alg(traffic_key, message)
INPUT: MAC_alg, traffic_key, message
OUTPUT: MACwhere:
MAC_alg- the specific MAC algorithm used for this computation. The algorithm decides the output length, so you don't need a separate output length parameter. This is specified as described in [RFC5926]. 🎀Traffic_key- the traffic key used for this computation. It gets computed from the connection's current MKT as described in Section 5.2. 🗝️Message- the input data the MAC gets computed over. In TCP-AO, that's the TCP segment with the IP pseudoheader and TCP header options stuck on the front, as described in Section 5.1. 💌MAC- the fixed-length output of the MAC algorithm, given the parameters you handed it. ✨
Real talk, the algorithms in [RFC5926] are each truncated to 96 bits for TCP-AO, as of when this was written 🦋 Each one actually outputs a bigger MAC, but 96 bits is a really reasonable balance between security and message size. BUT this could change later, so please don't assume the TCP-AO size is fixed length. 🙈
The MAC algorithm used for a connection's MAC computation is whatever the MKT says it is, per the definition in [RFC5926]. 🧚
The mandatory-to-implement MAC algorithms for TCP-AO live in a separate RFC, [RFC5926] 💜 This is so the TCP-AO spec can keep moving along the IETF Standards Track even when the algorithms (and their labels, like the ones a user interface or automated MKT management protocol might show) need updates. Cryptography is constantly evolving, bestie, and this setup keeps everything from getting stuck 🌈
>> Additional algorithms, beyond those mandated for TCP-AO, MAY be supported. 🌸
The data going into the MAC is made of the following fields, in this exact order, all read in network-standard byte order 🍓
- The Sequence Number Extension (SNE), in network-standard byte order, laid out like this (more on it in Section 6.2) 🔢
+--------+--------+--------+--------+
| SNE |
+--------+--------+--------+--------+
Figure 4: Sequence Number ExtensionThe SNE for transmitted segments is kept locally in the SND.SNE value. For received segments, a local RCV.SNE value gets used instead. The details of how those values get maintained and used are in Sections 6.2, 7.4, and 7.5. 🫶
- The IP pseudoheader: the IP source and destination addresses, the protocol number, and the segment length, all in network byte order, stuck in front of the TCP header below. The pseudoheader is exactly what gets used for the TCP checksum with either IPv4 or IPv6 [RFC793][RFC2460], so no new rules here, just vibes 👑
+--------+--------+--------+--------+
| Source Address |
+--------+--------+--------+--------+
| Destination Address |
+--------+--------+--------+--------+
| Zero | Proto | TCP Length |
+--------+--------+--------+--------+
Figure 5: TCP IPv4 Pseudoheader [RFC793]
+--------+--------+--------+--------+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+ +
+--------+--------+--------+--------+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+--------+--------+--------+--------+
| Upper-Layer Payload Length |
+--------+--------+--------+--------+
| Zero | Next Header |
+--------+--------+--------+--------+
Figure 6: TCP IPv6 Pseudoheader [RFC2460]- The TCP header, options included by default, with the TCP checksum and TCP-AO MAC fields set to zero, all in network-byte order. 🎀
The TCP option flag in the MKT is what tells you whether the TCP options get included in the MAC. When they are included, only the TCP-AO MAC field gets zeroed. 🧁
When TCP options are not included, every TCP option except TCP-AO gets left out of MAC processing. Again, the TCP-AO MAC field is zeroed for the MAC processing. 🙃
- The TCP data, aka the payload of the TCP segment. 📦
Note that the traffic key is NOT part of the data, bestie 🙅♀️ The MAC algorithm is what tells you how to use the traffic key, for example the way HMACs do it [RFC2104][RFC2403]. The traffic key is derived from the current MKT as described in Section 5.2. 🔑
5.2. Traffic Key Derivation Functions 🔑✨
okay so TCP-AO's traffic keys get cooked up from the MKTs using Key Derivation Functions (KDFs) 🍳. The KDFs in TCP-AO have this interface, bestie:
traffic_key = KDF_alg(master_key, context, output_length)
INPUT: KDF_alg, master_key, context, output_length
OUTPUT: traffic_keywhere:
KDF_alg- the specific Key Derivation Function (KDF) that's the basic building block used to make the traffic key, as indicated in the MKT. It's specified as described in [RFC5926].Master_key- the master_key string, as it gets stored into the associated MKT 🗝️Context- the context used as input when building the traffic_key, as specified in [RFC5926]. How this context gets combined with other info to make the raw input to the KDF is also explained further in [RFC5926].Output_length- the desired output length of the KDF, i.e., the length the KDF's output gets truncated to. This is specified as described in [RFC5926].Traffic_key- the desired output of the KDF, of length output_length, which gets fed into the MAC algorithm, as described in Section 5.1. 💖
The context used as input to the KDF combines the TCP socket pair with the endpoint Initial Sequence Numbers (ISNs) of a connection. This data is unique to each TCP connection instance, so TCP-AO can generate unique traffic keys for that connection, even from an MKT used across lots of different connections or across repeated connections that share a socket pair. Unique traffic keys are generated without relying on external key management properties. The KDF context is defined in Figures 7 and 8 🦋
+--------+--------+--------+--------+
| Source Address |
+--------+--------+--------+--------+
| Destination Address |
+--------+--------+--------+--------+
| Source Port | Dest. Port |
+--------+--------+--------+--------+
| Source ISN |
+--------+--------+--------+--------+
| Dest. ISN |
+--------+--------+--------+--------+
Figure 7: KDF Context for an IPv4 Connection
+--------+--------+--------+--------+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+ +
+--------+--------+--------+--------+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+--------+--------+--------+--------+
| Source Port | Dest. Port |
+--------+--------+--------+--------+
| Source ISN |
+--------+--------+--------+--------+
| Dest. ISN |
+--------+--------+--------+--------+
Figure 8: KDF Context for an IPv6 ConnectionTraffic keys are directional, so "source" and "destination" get read differently for incoming and outgoing segments 🔄. For incoming segments, source is the remote side; for outgoing segments, source is the local side. This further ensures that connection keys generated for each direction are unique. ✨
For SYN segments (segments with the SYN set, but the ACK not set), the destination ISN isn't known yet 🙈. For these segments, the connection key is computed using the context shown above, where the destination ISN value is zero. For all other segments, the ISN pair is used when known. If the ISN pair isn't known, e.g., when sending a reset (RST) after a reboot, the segment should be sent without authentication. If authentication was required, the segment couldn't have been MAC'd properly anyway and would've been dropped on receipt 💀
TCP-AO SYN segments (SYN set, no ACK set) MUST use a destination ISN of zero (whether sent or received); all other segments use the known ISN pair.
Overall, this means each connection will use up to four distinct traffic keys for each MKT 🌈:
Send_SYN_traffic_key- the traffic key used to authenticate outgoing SYNs. The source ISN is known (the TCP connection's local ISN), and the destination (remote) ISN is unknown (so the value 0 is used).Receive_SYN_traffic_key- the traffic key used to authenticate incoming SYNs. The source ISN is known (the TCP connection's remote ISN), and the destination (remote) ISN is unknown (so the value 0 is used).Send_other_traffic_key- the traffic key used to authenticate all other outgoing TCP segments.Receive_other_traffic_key- the traffic key used to authenticate all other incoming TCP segments.
The table below shows how each of these traffic keys is computed 📊. The TCP-AO algorithms refer to source (S) and destination (D) values of the IP address, TCP port, and ISN, and each segment (incoming or outgoing) has a value that refers to the local side of the connection (l) and the remote side (r):
S-IP S-port S-ISN D-IP D-port D-ISN
----------------------------------------------------------------
Send_SYN_traffic_key l-IP l-port l-ISN r-IP r-port 0
Receive_SYN_traffic_key r-IP r-port r-ISN l-IP l-port 0
Send_other_traffic_key l-IP l-port l-ISN r-IP r-port r-ISN
Receive_other_traffic_key r-IP r-port r-ISN l-IP l-port l-ISNThe use of both ISNs in the traffic key computations makes sure segments can't be replayed across repeated connections reusing the same socket 🛡️. Their 32-bit space avoids repeated use except under reboot, and reuse assumes both sides repeat their use on the same connection. We do expect that:
Endpoints should select ISNs pseudorandomly, e.g., as in [RFC1948].
A SYN is authenticated using a destination ISN of zero (whether sent or received), and all other segments would be authenticated using the ISN pair for the connection. There are other cases where the destination ISN isn't known but segments still get emitted, like after an endpoint reboots, when the two endpoints might not have enough info to authenticate segments. This is addressed further in Section 7.7 👀
5.3. Traffic Key Establishment and Duration Issues 🗓️💅
TCP-AO doesn't provide a mechanism for traffic key negotiation, parameter negotiation (MAC algorithm, length, or whether TCP-AO gets used on a connection), or for coordinating rekeying during a connection 🙅♀️. We assume out-of-band mechanisms for MKT establishment, parameter negotiation, and rekeying. This separation of MKT use from MKT management is similar to the one in the IPsec suite [RFC4301][RFC4306].
We encourage users of TCP-AO to apply known techniques for generating appropriate MKTs 🧁, including the use of reasonable master key lengths, limited traffic key sharing, and limiting the duration of MKT use [RFC3562]. This also includes the use of per-connection nonces, as suggested in Section 5.2.
TCP-AO supports rekeying, where new MKTs get negotiated and coordinated out of band, either via a protocol or a manual procedure [RFC4808]. New MKT use is coordinated using the out-of-band mechanism to update both TCP endpoints. When only a single MKT is used at a time, the temporary use of invalid MKTs could result in segments being dropped. TCP is already robust to such drops, but TCP-AO uses the KeyID field to avoid them 🙌. A given connection can have multiple matching MKTs, where the KeyID field identifies the MKT that corresponds to the traffic key used for a segment, so there's no need for expensive trial-and-error testing of MKTs in sequence.
TCP-AO provides an explicit MKT coordination mechanism, described in Section 6.1. Such a mechanism is useful when new MKTs are installed or when MKTs are changed, to determine when to start using the installed MKTs ⭐.
Users are advised to manage MKTs following the spirit of the advice for key management when using TCP MD5 [RFC3562], notably to use appropriate key lengths (12-24 bytes) and to avoid sharing MKTs among multiple BGP peering arrangements 🌸.
5.3.1. MKT Reuse Across Socket Pairs 🦋
MKTs can be reused across different socket pairs within a host, or across different instances of a socket pair within a host. In either case, replay protection is maintained 🔒.
MKTs reused across different socket pairs can't enable replay attacks, because the TCP socket pair is included in the MAC as well as in generating the traffic key. MKTs reused across repeated instances of a given socket pair can't enable replay attacks either, because the connection ISNs are included in the traffic key generation algorithm, and ISN pairs are unlikely to repeat over useful periods 🙌.
5.3.2. MKTs Use within a Long-Lived Connection ⏳
TCP-AO uses Sequence Number Extensions (SNEs) to prevent replay attacks within long-lived connections 🛡️. Explicit MKT rollover, accomplished by external means and indexed using the KeyID field, can be used to change keying material for various reasons (e.g., personnel turnover), but it isn't required to support long-lived connections 🍓.
6. Additional Security Mechanisms 🔐👑
TCP-AO adds mechanisms to support efficient use, especially in environments where only manual keying is available 🧚. These include the previously described mechanisms for supporting multiple concurrent MKTs (via the KeyID field) and for generating unique per-connection traffic keys (via the KDF). This section describes additional mechanisms to coordinate MKT changes and to prevent replay attacks when a traffic key isn't changed for long periods of time 💜.
6.1. Coordinating Use of New MKTs 🔑
okay so at any given time, one TCP connection can have multiple MKTs set up for each direction (incoming and outgoing) 👀. TCP-AO has a way to say "hey, this new MKT is ready!" so the sender can start using it. That's how new MKT use gets coordinated, so you don't lose segments just because the sender used an MKT the receiver wasn't ready for yet 🫶
Quick note: this is meant to be an optimization. Deciding when to start using a key is a performance thing. Deciding when to remove an MKT is a security thing. Invalid MKTs are expected to be removed, but TCP-AO doesn't give you a way to coordinate their removal, because that counts as a key management operation 🙈
New MKT use is coordinated through two ID fields in the header:
- KeyID
- RNextKeyID
KeyID is the outgoing MKT info the segment sender uses to create the segment's MAC, and it's also the matching incoming keying info the segment receiver uses to check that MAC. It holds the SendID of the MKT that's actively in use in that direction ✨
RNextKeyID is the preferred MKT info for received segments coming in later ("receive next"). Basically, the sender is saying "hey, for future segments you send me, use this one." That way the receiver knows when to switch MKTs (and their KeyIDs and traffic keys) 💅 It holds the RecvID of the MKT the sender wants for incoming segments.
Each side of a connection keeps two pointers, as noted in the per-connection info (see Section 4) 🧚
- Currently active outgoing MKT (current_key)
- Current preference for incoming MKT (rnext_key)
current_key is the MKT used to authenticate outgoing segments. When the connection is first set up, it points at the first MKT selected for use 🌸
rnext_key points at an incoming MKT that's ready and preferred for use. When the connection is first set up, it points at the currently active incoming MKT. It can change when new MKTs get installed, whether that's by automatic MKT management protocol operation or user manual selection ✨
rnext_key only changes through manual user intervention or MKT management protocol operation. TCP-AO doesn't touch it. current_key, on the other hand, gets updated by TCP-AO when it processes received TCP segments, as covered in the segment processing description in Section 7.5 💖
Here's a fun one: the algorithm lets current_key switch to a new MKT and then switch back to a previously used one. This is called "backing up" 🦋 It can happen during an MKT change when segments show up out of order. It's actually considered a feature of TCP-AO, because reordering doesn't cause drops, and that's iconic. The only way to avoid reusing a previously used MKT is to remove that MKT once it's no longer considered permitted 🙅♀️
6.2. Preventing Replay Attacks within Long-Lived Connections 🛡️
TCP uses a 32-bit sequence number. In long-lived connections, that number can roll over and repeat 😭 That could mean TCP segments get intentionally and legitimately replayed within a connection. TCP-AO prevents replay attacks, so it needs a way to tell those legitimate replays apart. That's why it adds a 32-bit Sequence Number Extension (SNE) for transmitted and received segments 🔥
The SNE extends the TCP sequence number so that segments within a single connection are always unique ✨ When TCP's sequence number rolls over, there's a chance a segment could be repeated in its entirety. Using an SNE tells apart even identical segments that were sent with identical sequence numbers at different times in a connection 🎀 TCP-AO fakes a 64-bit sequence number space by working out when to increment the high-order 32-bit portion (the SNE), based on transitions in the low-order portion (the TCP sequence number) 🧠
So TCP-AO keeps SND.SNE for transmitted segments and RCV.SNE for received segments, and both start at zero when a connection begins 🌈 The goal is that these SNEs, together with TCP's 32-bit sequence numbers, give you a 64-bit overall sequence number space.
For transmitted segments, SND.SNE can be implemented by extending TCP's sequence number to 64 bits, with SND.SNE being the top (high-order) 32 bits of that number. For received segments, TCP-AO has to emulate a 64-bit number space and correctly infer the right high-order 32 bits of that number as RCV.SNE, using the received 32-bit sequence number and the current connection context 🦋
The implementation of SNEs isn't specified in this document, but one possible way is described here, and it can be used for RCV.SNE, SND.SNE, or both 🍓
Imagine an implementation with two SNEs (SND.SNE, RCV.SNE), plus the extra variables below, all initialized to zero, along with a current TCP segment field (SEG.SEQ) 🧚
SND.PREV_SEQ, needed to detect rollover ofSND.SEQRCV.PREV_SEQ, needed to detect rollover ofRCV.SEQSND.SNE_FLAG, which indicates when to increment theSND.SNERCV.SNE_FLAG, which indicates when to increment theRCV.SNE
When a segment comes in, this algorithm (in C-like pseudocode) works out the SNE used in the MAC. This is the "RCV" side, but an equivalent algorithm can be applied to the "SND" side 💜
/* set the flag when the SEG.SEQ first rolls over */
if ((RCV.SNE_FLAG == 0)
&& (RCV.PREV_SEQ > 0x7fff) && (SEG.SEQ < 0x7fff)) {
RCV.SNE = RCV.SNE + 1;
RCV.SNE_FLAG = 1;
}
/* decide which SNE to use after incremented */
if ((RCV.SNE_FLAG == 1) && (SEG.SEQ > 0x7fff)) {
SNE = RCV.SNE - 1; # use the pre-increment value
} else {
SNE = RCV.SNE; # use the current value
}
/* reset the flag in the *middle* of the window */
if ((RCV.PREV_SEQ < 0x7fff) && (SEG.SEQ > 0x7fff)) {
RCV.SNE_FLAG = 0;
}
/* save the current SEQ for the next time through the code */
RCV.PREV_SEQ = SEG.SEQ;So the first time the sequence number rolls over (the new number is low, in the bottom half of the number space, and the old number was high, in the top half), the SNE gets incremented and a flag gets set 🎉
If the flag is set and a high number shows up, it has to be a reordered segment, so use the pre-increment SNE. Otherwise, use the current SNE 👀
The flag gets cleared by the time the number has rolled all the way around 🔄
The flag stops the SNE from being incremented again until the flag is reset. That reset happens in the middle of the window (when the old number is in the bottom half and the new one is in the top half). Because the receive window is never larger than half of the number space, it's impossible to set and reset the flag at the same time -- outstanding segments, reordering or not, can't straddle both regions at once 💅
7. TCP-AO Interaction with TCP 🎀
Here's how TCP-AO affects various TCP states, segments, events, and interfaces. This is meant to build on the TCP description in RFC 793, and its structure mirrors RFC 793 on purpose [RFC793] 💖
7.1. TCP User Interface 💬
The TCP user interface supports active and passive OPEN, SEND, RECEIVE, CLOSE, STATUS, and ABORT commands. TCP-AO doesn't change this interface as it applies to TCP. Some commands or command sequences need to be tweaked to support TCP-AO, though, and TCP-AO doesn't spell out the details of how that gets done ✨
TCP-AO requires the TCP user interface to be extended so MKTs can be configured, and so an ongoing connection can manage which MKTs are active. MKTs need to be configured before the connection is established, and the set of MKTs can change during a connection 🔑
TCP OPEN, or the sequence of commands that configure a connection to be in the active or passive OPEN state, MUST be augmented so that an MKT can be configured.
A TCP-AO implementation MUST allow the set of MKTs for ongoing TCP connections (i.e., not in the CLOSED state) to be modified.
The MKTs tied to a connection need to be available for confirmation, and that includes being able to read them 👀
TCP STATUS SHOULD be augmented to allow the MKTs of a current or pending connection to be read (for confirmation).
Senders may need to figure out when the outgoing MKT changes (KeyID) or when a new preferred MKT (RNextKeyID) is indicated. These changes immediately affect all subsequent outgoing segments 🚨
TCP SEND, or a sequence of commands resulting in a SEND, MUST be augmented so that the preferred outgoing MKT (current_key) and/or the preferred incoming MKT (rnext_key) of a connection can be indicated.
It might be useful to change the outgoing active MKT (current_key) even when no data is being sent. That can be done by sending a zero-length buffer, or by using a non-send interface (e.g., socket options in Unix), depending on the implementation 🧚
It's also useful to indicate recent segment KeyID and RNextKeyID values that were received. There could be a bunch of these, but they're not expected to change quickly, so any recent sample should be sufficient 💅
TCP RECEIVE, or the sequence of commands resulting in a RECEIVE, MUST be augmented so that the KeyID and RNextKeyID of a recently received segment is available to the user out of band (e.g., as an additional parameter to RECEIVE or via a STATUS call).
7.2. TCP States and Transitions 🌸
TCP includes the states LISTEN, SYN-SENT, SYN-RECEIVED, ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT, and CLOSED ✨
An MKT MAY be associated with any TCP state.
7.3. TCP Segments 📦
TCP includes control segments (at least one of SYN, FIN, RST flags set) and data segments (none of SYN, FIN, or RST flags set). Some control segments can include data, like a SYN 🦋
All TCP segments MUST be checked against the set of MKTs for matching TCP connection identifiers.
TCP segments whose TCP-AO does not validate MUST be silently discarded.
A TCP-AO implementation MUST allow for configuration of the behavior of segments that carry TCP-AO but don't match an MKT. The initial default of this configuration SHOULD be to silently accept such connections. If that isn't the desired case, an MKT can be included to match such connections, or the connection can indicate that TCP-AO is required. Alternately, the configuration can be changed to discard segments with the AO option that don't match an MKT 🙈
Silent discard events SHOULD be signaled to the user as a warning, and silent accept events MAY be signaled to the user as a warning. Both warnings, if available, MUST be accessible via the STATUS interface. Either signal MAY be asynchronous, but if so, they MUST be rate-limited. Either signal MAY be logged, and logging SHOULD allow rate-limiting as well 🚨
All TCP-AO processing happens between the interface of TCP and IP. For incoming segments, this happens after the TCP checksum has been validated. For outgoing segments, this happens before the TCP checksum is computed 🧠
Heads up: use of TCP-AO on a connection is not negotiated within TCP. It's the receiver's job to figure out when TCP-AO is required, through other means (e.g., out of band, manually, or with a key management protocol), and to enforce that requirement ✋
7.4. Sending TCP Segments ✨
okay so this section is the step-by-step recipe for how TCP sticks TCP-AO onto a segment when it leaves 💅 it's giving very precise, bestie 🧚
Note that TCP-AO MUST be the last TCP option processed on outgoing segments, because its MAC calculation may include the values of other TCP options. 🔒
- Find the per-connection parameters for the segment: 🔍
- a. If the segment is a SYN, then it's the first segment of a brand new connection 🌱 so find the matching MKT for it based on the segment's socket pair.
- i. If there is no matching MKT, omit TCP-AO and proceed with transmitting the segment 🫶
- ii. If there is a matching MKT, then set the per-connection parameters as needed (see Section 4) and proceed with step 2.
- b. If the segment is not a SYN, then figure out whether TCP-AO is being used for the connection, use the MKT indicated by the
current_keyvalue from the per-connection parameters (see Section 4), and proceed with step 2.
- a. If the segment is a SYN, then it's the first segment of a brand new connection 🌱 so find the matching MKT for it based on the segment's socket pair.
- Using the per-connection parameters: 🧁
- a. Augment the TCP header with TCP-AO, inserting the appropriate
LengthandKeyIDbased on the MKT indicated bycurrent_key(using thecurrent_keyMKT'sSendIDas the TCP-AOKeyID). Then update the TCP header length accordingly. - b. Determine
SND.SNEas described in Section 6.2. - c. Determine the appropriate traffic key, i.e., the one pointed to by
current_key(as noted in Section 6.1, and as probably cached in the TCB). That meanssend_SYN_traffic_keyfor SYN segments andsend_other_traffic_keyfor everything else. - d. Determine the
RNextKeyIDas indicated by thernext_keypointer, and insert it in the TCP-AORNextKeyIDfield (using thernext_keyMKT'sRecvIDas the TCP-AOKeyID) (as noted in Section 6.1). - e. Compute the MAC using the MKT (and cached traffic key) and data from the segment, as specified in Section 5.1. 🧮
- f. Insert the MAC in the TCP-AO
MACfield. - g. Proceed with transmitting the segment 🚀
- a. Augment the TCP header with TCP-AO, inserting the appropriate
7.5. Receiving TCP Segments 📬
okay the receiving side is where the drama is 😭 this section describes the TCP changes that support TCP-AO when a segment arrives, so let's gossip about it.
Note that TCP-AO MUST be the first TCP option processed on incoming segments, because its MAC calculation may include the values of other TCP options that could change during TCP option processing. This also protects the behavior of all other TCP options from the impact of spoofed segments or modified header information. 🛡️
Note that TCP-AO checks MUST be performed for all incoming SYNs to avoid accepting SYNs lacking TCP-AO where required. Other segments can cache whether TCP-AO is needed in the TCB. 👀
- Find the per-connection parameters for the segment: 🔍
- a. If the segment is a SYN, then it's the first segment of a new connection. Find the matching MKT for it, using the segment's socket pair and its TCP-AO
KeyID, matched against the MKT's TCP connection identifier and the MKT'sRecvID.- i. If there is no matching MKT, remove TCP-AO from the segment and proceed with further TCP handling of the segment.
- a. If the segment is a SYN, then it's the first segment of a new connection. Find the matching MKT for it, using the segment's socket pair and its TCP-AO
NOTE: this presumes that connections that do not match any MKT should be silently accepted, as noted in Section 7.3. 🙈
- ii. If there is a matching MKT, then set the per-connection parameters as needed (see Section 4) and proceed with step 2.
- Using the per-connection parameters: 🧁
- a. Check that the segment's TCP-AO
Lengthmatches the length indicated by the MKT.- i. If the lengths differ, silently discard the segment. Log and/or signal the event as indicated in Section 7.3. 🗑️
- b. Determine the segment's
RCV.SNEas described in Section 6.2. - c. Determine the segment's traffic key from the MKT as described in Section 5.1 (and as likely cached in the TCB). That means
receive_SYN_traffic_keyfor SYN segments andreceive_other_traffic_keyfor other segments. - d. Compute the segment's MAC using the MKT (and its derived traffic key) and the portions of the segment indicated in Section 5.1.
- i. If the computed MAC differs from the TCP-AO
MACfield value, silently discard the segment. Log and/or signal the event as indicated in Section 7.3. 🚨
- i. If the computed MAC differs from the TCP-AO
- e. Compare the received
RNextKeyIDvalue to the currently active outgoingKeyIDvalue (thecurrent_keyMKT'sSendID).- i. If they match, no further action is required. ✅
- ii. If they differ, determine whether the
RNextKeyIDMKT is ready.- If the MKT corresponding to the segment's socket pair and
RNextKeyIDis not available, no action is required (theRNextKeyIDof a received segment needs to match the MKT'sSendID). - If the matching MKT corresponding to the segment's socket pair and
RNextKeyIDis available:- a. Set
current_keyto theRNextKeyIDMKT. 🔑
- a. Set
- If the MKT corresponding to the segment's socket pair and
- f. Proceed with TCP processing of the segment.
- a. Check that the segment's TCP-AO
It is suggested that TCP-AO implementations validate a segment's Length field before computing a MAC, to reduce the overhead incurred by spoofed segments with invalid TCP-AO fields. 🧹
Additional reductions in MAC validation overhead can be supported in the MAC algorithms, e.g., by using a computation algorithm that prepends a fixed value to the computed portion, and a corresponding validation algorithm that verifies the fixed value before investing in the computed portion. Such optimizations would be contained in the MAC algorithm specification, and thus are not specified in TCP-AO explicitly. Note that the KeyID cannot be used for connection validation per se, because it is not assumed random. 🎲
7.6. Impact on TCP Header Size 📏
okay so the header space situation is very tight, bestie 😩 TCP-AO, using the initially required 96-bit MACs, uses a total of 16 bytes of TCP header space [RFC5926]. That makes TCP-AO 2 bytes smaller than the TCP MD5 option (18 bytes). Small but mighty 💪
Note that the TCP option space is most critical in SYN segments, because flags in those segments could potentially increase the option space area in other segments. Because TCP ignores unknown segments, however, it is not possible to extend the option space of SYNs without breaking backward compatibility. 🥺
TCP's 4-bit data offset requires that the options end 60 bytes (15 32-bit words) after the header begins, including the 20-byte header. That leaves 40 bytes for options, of which 15 are expected in current implementations (listed below), leaving at most 25 for other uses. TCP-AO consumes 16 bytes, leaving 9 bytes for additional SYN options (depending on implementation dependant alignment padding, which could consume another 2 bytes at most). 🎀
- SACK permitted (2 bytes) [RFC2018][RFC3517]
- Timestamps (10 bytes) [RFC1323]
- Window scale (3 bytes) [RFC1323]
After a SYN, the following options are expected in current implementations of TCP:
TCP-AO continues to consume 16 bytes in non-SYN segments, leaving a total of 24 bytes for other options, of which the timestamp consumes 10. That leaves 14 bytes, of which 10 are used for a single SACK block. When two SACK blocks are used, such as to handle D-SACK, a smaller TCP-AO MAC would be required to make room for the additional SACK block (i.e., to leave 18 bytes for the D-SACK variant of the SACK option) [RFC2883]. Note that D-SACK is not supportable in TCP MD5 in the presence of timestamps, because TCP MD5's MAC length is fixed and too large to leave sufficient option space. 😵💫
Although TCP option space is limited, we believe TCP-AO is consistent with the desire to authenticate TCP at the connection level for similar uses as were intended by TCP MD5. 💜
7.7. Connectionless Resets 💥
okay this one is spicy 🌶️ TCP-AO allows TCP resets (RSTs) to be exchanged provided both sides have established valid connection state. After such state is established, if one side reboots, TCP-AO prevents TCP's RST mechanism from clearing out old state on the side that did not reboot. This happens because the rebooting side has lost its connection state, and thus its traffic keys. 🔐
It is important that implementations are capable of detecting excesses of TCP connections in such a configuration, and can clear them out if needed to protect their memory usage [Ba10]. To protect against such state from accumulating and never getting cleared out, a number of recommendations are made: 🧹
Connections using TCP-AO SHOULD also use TCP keepalives [RFC1122].
The use of TCP keepalives ensures that connections whose keys are lost are terminated after a finite time. A similar effect can be achieved at the application layer, e.g., with BGP keepalives [RFC4271]. Either kind of keepalive helps ensure the TCP state is cleared out in such a case. The alternative, allowing unauthenticated RSTs to be received, would allow one of the primary vulnerabilities that TCP-AO is intended to prevent. 🛑
Keepalives ensure that connections are dropped across reboots, but this can have a detrimental effect on some protocols. Specifically, BGP reacts poorly to such connection drops, even if they're caused by the use of BGP keepalives. "Graceful restart" was introduced to address this effect [RFC4724], and was extended to support BGP with MPLS [RFC4781]. As a result: 🥀
BGP connections SHOULD require support for graceful restart when using TCP-AO.
We recognize that support for graceful restart is not always feasible. As a result: 🫠
When BGP without graceful restart is used with TCP-AO, both sides of the connection SHOULD save traffic keys in storage that persists across reboots and restore them after a reboot, and SHOULD limit any performance impacts that result from this storage/restoration. 💾✨
7.8. ICMP Handling ✨
okay so TCP can get attacked two ways: in band, through regular TCP segments, or out of band, through ICMP 🙈 ICMP packets can't be protected with TCP-AO, so ngl TCP-AO and IPsec don't fully solve the "we need protected ICMP signaling" problem 😭 TCP-AO does add some extra advice for handling certain ICMPs beyond what IPsec asks for, and it can do that because it lives inside a TCP connection 💅
IPsec has its own rules, like dropping ICMPs in some situations and requiring endpoint authentication for them in others [RFC4301]. There are other proposals that try to shrink the damage from ICMP attacks by double-checking ICMP contents and changing what some messages do based on TCP state, but none of them give ICMP the level of authentication that TCP-AO gives TCP [Go10]. So we take a conservative approach to accepting ICMP messages, summarized in [Go10]:
A TCP-AO implementation MUST default to ignore incoming ICMPv4 messages of Type 3 (destination unreachable), Codes 2-4 (protocol unreachable, port unreachable, and fragmentation needed -- 'hard errors'), and ICMPv6 Type 1 (destination unreachable), Code 1 (administratively prohibited) and Code 4 (port unreachable) intended for connections in synchronized states (ESTABLISHED,FIN-WAIT-1,FIN-WAIT-2,CLOSE-WAIT,CLOSING,LAST-ACK,TIME-WAIT) that match MKTs.
A TCP-AO implementation SHOULD allow whether such ICMPs are ignored to be configured on a per-connection basis.
A TCP-AO implementation SHOULD implement measures to protect ICMP "packet too big" messages, some examples of which are discussed in [Go10].
An implementation SHOULD allow ignored ICMPs to be logged.
This control only touches ICMPs that currently require 'hard errors', which would abort the TCP connection [RFC1122]. The idea is to act like IPsec would with those messages, just with an extra default assumed [RFC4301]. Basically, it's careful, not paranoid 🧚
8. Obsoleting TCP MD5 and Legacy Interactions ✨
TCP-AO obsoletes TCP MD5. As we have noted earlier:
TCP implementations that support TCP MD5 MUST support TCP-AO.
Systems that only do TCP MD5 are considered legacy, and they ought to be upgraded when possible 🎀 To keep talking to those legacy systems until upgrades happen:
TCP MD5 SHOULD be supported where interactions with legacy systems are needed.
A system that supports both TCP-AO and TCP MD5 MUST use TCP-AO for connections unless not supported by its peer, at which point it MAY use TCP MD5 instead.
A TCP implementation MUST NOT use both TCP-AO and TCP MD5 for a particular TCP connection, but MAY support TCP-AO and TCP MD5 simultaneously for different connections (notably to support legacy use of TCP MD5).
The Kind value is how you can tell, inside the TCP segments, whether a particular connection is using TCP-AO or TCP MD5 🦋
It's possible that MKTs could be extended to support TCP MD5, although use of MKTs is not described in RFC 2385.
You can require TCP-AO for a connection, or you can require TCP MD5, but you can't require 'either' 🙅♀️ When an endpoint is configured to require TCP MD5 for a connection, the option must be added to all outgoing segments and validated on all incoming segments [RFC2385]. TCP MD5's requirements rule out speculatively using both options for a given connection, e.g., letting the other end of the connection decide 💀
9. Interactions with Middleboxes 🌸
TCP-AO may interact with middleboxes, depending on how they behave [RFC3234]. Some middleboxes either change TCP options (like TCP-AO) directly, or change the information TCP-AO includes in its MAC calculation. TCP-AO may end up interfering with these devices exactly where the device modifies the stuff TCP-AO is designed to protect 😤
9.1. Interactions with Non-NAT/NAPT Middleboxes
TCP-AO works with middleboxes that don't change the IP addresses or ports of segments 🫶 Those middleboxes may modify some TCP options, and in that case TCP-AO would need to be configured to ignore all options in the MAC calculation on connections going through that element.
Ignoring TCP options may give you less protection, though, because TCP options could be modified in transit, and an attacker could use those modifications 👀 Depending on what changed, TCP could lose efficiency (for example, timestamp changes), or it could stop working correctly (for example, window scale changes). These vulnerabilities only affect the TCP connections where TCP-AO is set up to ignore TCP options.
9.2. Interactions with NAT/NAPT Devices
TCP-AO can't interoperate natively across NAT/NAPT (Network Address Port Translation) devices, since those change the IP addresses and/or port numbers 😭 We expect that getting through these devices may need variants of existing NAT/NAPT traversal mechanisms, for example wrapping the TCP-AO-protected segment inside another transport segment (like UDP), the same way IPsec does [RFC2663][RFC3947]. Those variants can be adapted for use with TCP-AO, or IPsec with NAT traversal can be used instead of TCP-AO in those cases [RFC3947].
An alternate proposal for handling NATs extends TCP-AO independently of this specification [To10]. ok that's the tea for this part 🌈✨
10. Evaluation of Requirements Satisfaction ✨
okay bestie, time to check the homework 📝 TCP-AO hits every current requirement for a revision to TCP MD5, and here's the summary, no cap [Ed07] 🎀
- Protected Elements 🛡️
A solution to revising TCP MD5 should protect (authenticate) the following elements. This is supported, see Section 5.1 💅
- a. IP pseudoheader, including IPv4 and IPv6 versions 🌐 Optional coverage is not allowed here, because IP addresses define a connection. If they can be coordinated across a NAT/NAPT, the sender can compute the MAC based on the received values. If not, a tunnel is required, as noted in Section 9.2. It's giving strict 😤
- b. TCP header 📦 Optional port coverage is not allowed either, because ports define a connection. If they can be coordinated across a NAT/NAPT, the sender can compute the MAC based on the received values. If not, a tunnel is required, as noted in Section 9.2. Same energy as before 🫶
- c. TCP options 🧩 TCP-AO lets you exclude TCP options from coverage, so it plays nice with middleboxes that modify options (except when they modify TCP-AO itself). See Section 9 🦋
- d. TCP payload data 💌
- Option Structure Requirements 🎀
A solution to revising TCP MD5 should use an option with the following structural requirements. This is supported, see Section 5.1 ✨
- a. Privacy 🙈 The option should not unnecessarily expose info about the TCP-AO mechanism. Keeping this info private may be of little value, but it also helps keep the option size small 🍓 TCP-AO only exposes the MKT IDs, MAC, and overall option length on the wire. Short MACs could be hidden by using longer option lengths while specifying a short MAC length. That's equivalent to a different MAC algorithm, and it's specified in the MKT. See Section 2.2 🧚
- b. Allow optional per connection 🌸 The option should not be required on every connection. It should be optional on a per-connection basis. This is supported, because the set of MKTs can be installed to match some connections and not others. Connections not matching any MKT do not require TCP-AO. Also, incoming segments with TCP-AO are not discarded solely because they include the option, as long as they don't match any MKT 🥰
- c. Require non-optional 🔒 The option should be able to be specified as required for a given connection. This is supported, because the set of MKTs can be installed to match some connections and not others. Connections matching any MKT require TCP-AO. Strict but make it cute 💜
- d. Standard parsing 📖 The option should be easy to parse, i.e., without conditional parsing, and should follow the standard RFC 793 option format. This is supported, see Section 2.2 ✅
- e. Compatible with Large Windows and SACK 🪟 The option should be compatible with the use of the Large Windows and SACK options. This is supported, see Section 7.6. The size of the option is intended to allow use with Large Windows and SACK. See also Section 1.3, which says TCP-AO is 2 bytes shorter than TCP MD5 in the default case, assuming a 96-bit MAC 📏
- Cryptography requirements 🔐
A solution to revising TCP MD5 should support modern cryptography capabilities. Slay 👑
- a. Baseline defaults 🧱 The option should have a default that is required in all implementations. TCP-AO uses a default required algorithm as specified in [RFC5926] and as noted in Section 5.1 of this document 💖
- b. Good algorithms ✨ The option should use algorithms considered accepted by the security community, which are considered appropriately safe. The use of non-standard or unpublished algorithms should be avoided. TCP-AO uses MACs as indicated in [RFC5926]. The KDF is also specified in [RFC5926]. The KDF input string follows the typical design (see [RFC5926]) 🧪
- c. Algorithm agility 🦋 The option should support algorithms other than the default, to allow agility over time. TCP-AO allows any desired algorithm, subject to TCP option space limitations, as noted in Section 2.2. Using a set of MKTs lets separate connections use different algorithms, for both the MAC and the KDF 🔄
- d. Order-independent processing 🌀 The option should be processed independently of the proper order. In other words, it should allow processing of TCP segments in the order received, without requiring reordering. This avoids the need for reordering prior to processing, and avoids the impact of misordered segments on the option. This is supported, see Sections 7.3, 7.4, and 7.5. Pre-TCP processing is further required, because TCP segments cannot be discarded solely based on a combination of connection state and out-of-window checks. Many such segments, although discarded, cause a host to respond with a replay of the last valid ACK, e.g., [RFC793]. See also the derivation of the SNE, which is reconstituted at the receiver using a demonstration algorithm that avoids the need for reordering (in Section 6.2) 🫠
- e. Security parameter changes require key changes 🗝️ The option should require that the MKT change whenever the security parameters change. This avoids the need for coordinating option state during a connection, which is typical for TCP options. It also helps allow "bump in the stack" implementations that are not integrated with endpoint TCP implementations. Parameters only change when a new MKT is used. See Section 3 🎀
- Keying requirements 🔑
A solution to revising TCP MD5 should support manual keying, and should support the use of an external automated key management system (e.g., a protocol or other mechanism).
Note that TCP-AO does not specify an MKT management system 🙈
- a. Intraconnection rekeying 🔁 The option should support rekeying during a connection, to avoid the impact of long-duration connections. This is supported by the use of IDs and multiple MKTs, see Section 3 🌈
- b. Efficient rekeying ⚡ The option should support rekeying during a connection without the need to expend undue computational resources. In particular, the options should avoid the need to try multiple keys on a given segment. This is supported by the use of the KeyID. See Section 6.1 💜
- c. Automated and manual keying 🤖 The option should support both automated and manual keying. The use of MKTs allows external automated and manual keying, see Section 3. This capability is enhanced by the generation of unique per-connection keys, which enables use of manual MKTs with automatically generated traffic keys, as noted in Section 5.2 🫶
- d. Key management agnostic 🧁 The option should not assume or require a particular key management solution. This is supported by use of a set of MKTs. See Section 3 🍭
- Expected Constraints 🚧
A solution to revising TCP MD5 should also abide by typical safe security practices. Be safe out here, bestie 🫶
- a. Silent failure 🤫 Receipt of segments failing authentication must result in no visible external action and must not modify internal state, and those events should be logged. This is supported, see Sections 7.3, 7.4, and 7.5 🌙
- b. At most one such option per segment 1️⃣ Only one authentication option can be permitted per segment. This is supported by the protocol requirements, see Section 2.2 ✅
- c. Outgoing all or none 🎯 Segments out of a TCP connection are either all authenticated or all not authenticated. This is supported, see Section 7.4 💅
- d. Incoming all checked 🔍 Segments into a TCP connection are always checked to determine whether their authentication should be present and valid. This is supported, see Section 7.5 👀
- e. Non-interaction with TCP MD5 🤝 The use of this option for a given connection should not preclude the use of TCP MD5, e.g., for legacy use, for other connections. This is supported, see Section 8 🕰️
- f. "Hard" ICMP discard 🙅♀️ The option should allow certain ICMPs to be discarded, notably Type 3 (destination unreachable), Codes 2-4 (transport protocol unreachable, port unreachable, or fragmentation needed and IP DF field set), i.e., the ones indicating the failure of the endpoint to communicate. This is supported, see Section 7.8. These are the "we literally can't reach you" messages, so yes, they get discarded 💀
- g. Maintain TCP connection semantics 🧵 The socket pair alone defines a TCP association and all its security parameters. TCP connection semantics stay the same, in which the socket pair alone defines a TCP association and all its security parameters. This is supported, see Sections 3 and 9 👑
11. Security Considerations 🔐
Okay bestie, TCP-AO is a whole vibe, but it does cost your host some performance, same as TCP MD5 or IPsec 💅. Connections that use TCP-AO can get attacked by sending segments with invalid MACs 😭. An attacker only needs the TCP connection ID and the TCP-AO Length value to seriously drain the host's processing power 💀. It's giving the same vulnerability IPsec has to on-path attacks, where the IP addresses and SPI are visible 👀. The thing is, the whole SPI space in IPsec (32 bits) is arbitrary, but for routing protocols usually only the source port (16 bits) is arbitrary, and it typically has less than 16 bits of randomness [La10] 🙈. So an off-path attacker would have an easier time spoofing a TCP-AO segment that makes the receiver do validation work ⚠️. Still, between Internet routers, both ports could be arbitrary (meaning they're decided ahead of time out of band), and that gives roughly the same off-path antispoofing protection as an arbitrary SPI 🦋.
TCP-AO, just like TCP MD5, may block connectionless resets 🚫. These resets usually happen after a peer crashes, either as a reply to new connection attempts or when data gets sent on stale connections 🌸. In either case, the recovering endpoint might not have the connection key it needs (for example, if it got lost during the crash) 😬. The result can be timeouts instead of a snappier recovery after the crash 🥲. Ways to lessen this are covered in Section 7.7 🎀.
TCP-AO doesn't have a fast decline capability 💀. That's the case where a SYN-ACK shows up without a TCP-AO option and the connection gets reset or aborted right away ✋. Normal TCP behavior will just retry and time out, and honestly that's what you should expect when the intended receiver can't speak the TCP variant that's needed anyway 🤷♀️. Backoff isn't optimized, because that would give attackers on the wire a chance to abort authenticated connection attempts by sending spoofed SYN-ACKs without TCP-AO 🚨.
TCP-AO is meant to give similar protections to IPsec, but it is not meant to replace IPsec or IKE, whether you want stronger security or fancier security management 💜. TCP-AO exists to protect the TCP protocol itself from attacks that TLS, sBGP/soBGP, and other data stream protection mechanisms can't stop 🛡️. Like IPsec, TCP-AO doesn't solve the bigger problem of ICMP attacks on TCP 🙃. It does limit how much damage ICMPs can do, as noted in Section 7.8 ✨.
TCP-AO includes the TCP connection ID (the socket pair) in the MAC calculation, and this is so iconic 👑. It stops different concurrent connections that use the same MKT (for whatever reason) from enabling a traffic-crossing attack, where segments meant for one socket pair get diverted to attack a different socket pair 🦹♀️. When multiple connections use the same MKT, it's really useful to know that segments meant for one ID can't be modified in transit (on purpose or by accident) and end up authenticated for the other ID 🧐. Meeting that requirement would put an extra burden of uniqueness on MKTs inside endsystems, and maybe across endsystems too 😩. The resulting attack is low probability, but including the received ID in the protection is worth it, because it doesn't unduly increase the MAC calculation or MKT management 💖.
Any security algorithm can open the door to a CPU Denial-of-Service (DoS) attack 🔥. That's when the attacker sends fake, random segments and the receiver under attack burns a lot of CPU trying to reject them 💀. In IPsec, these attacks are reduced by using a large Security Parameter Index (SPI) and Sequence Number fields to partly validate segments before CPU cycles get spent validating the Integrity Check Value (ICV) 🧠. In TCP-AO, the socket pair does most of the job that IPsec's SPI does ✨. IPsec's Sequence Number, which is used to avoid replay attacks, isn't needed in TCP-AO, because TCP's own Sequence Number already reorders received segments 🔄. That only works as long as the sequence number doesn't wrap around, which is why TCP-AO adds the SNE in Section 6.2 🎀. TCP already protects itself from replays of authentic segment data and authentic explicit TCP control bits (like SYN, FIN, and ACK) 🫶. Even so, authentic replays could still mess with TCP congestion control [Sa99] 😭. TCP-AO doesn't protect TCP congestion control from this last kind of attack, because layering a windowed security sequence number on top of TCP's own sequence number would be super cumbersome 🙄. If you want that protection, users are encouraged to use IPsec instead 🌈.
It's also not useful to validate TCP's Sequence Number before doing the TCP-AO authentication calculation, because out-of-window segments can still cause valid TCP protocol actions (like ACK retransmission) [RFC793] 🦋. It's similarly not useful to add a separate Sequence Number field to TCP-AO, because doing that could change TCP's behavior even when segments are valid 🙅♀️.
12. IANA Considerations 📋
IANA gave the TCP Authentication Option (TCP-AO) TCP option 29 🎀.
This document doesn't define any new namespaces 🌸.
To specify MAC and KDF algorithms, TCP-AO points to a separate document [RFC5926] 🧚.
13. References 📚
13.1. Normative References 💅
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
[RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP
and AH", RFC 2403, November 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An
Extension to the Selective Acknowledgement (SACK) Option
for TCP", RFC 2883, July 2000.
[RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, "A
Conservative Selective Acknowledgment (SACK)-based Loss
Recovery Algorithm for TCP", RFC 3517, April 2003.
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y.
Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724,
January 2007.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border
Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4781] Rekhter, Y. and R. Aggarwal, "Graceful Restart Mechanism
for BGP with MPLS", RFC 4781, January 2007.
[RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms for
the TCP Authentication Option (TCP-AO)", RFC 5926, June
2010.13.2. Informative References 🌈
[Ba10] Bashyam, M., Jethanandani, M., and A. Ramaiah
"Clarification of sender behaviour in persist condition",
Work in Progress, January 2010.
[Bo07] Bonica, R., Weis, B., Viswanathan, S., Lange, A., and O.
Wheeler, "Authentication for TCP-based Routing and
Management Protocols", Work in Progress, February 2007.
[Bo09] Borman, D., "TCP Options and MSS", Work in Progress, July
2009.
[Ed07] Eddy, W., Ed., Bellovin, S., Touch, J., and R. Bonica,
"Problem Statement and Requirements for a TCP
Authentication Option", Work in Progress, July 2007.
[Go10] Gont, F., "ICMP Attacks against TCP", Work in Progress,
March 2010.
[La10] Larsen, M. and F. Gont, "Transport Protocol Port
Randomization Recommendations", Work in Progress, April
2010.
[Le09] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", Work in Progress, October 2009.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992.
[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks",
RFC 1948, May 1996.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
1997.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC 2663,
August 1999.
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
Issues", RFC 3234, February 2002.
[RFC3562] Leech, M., "Key Management Considerations for the TCP MD5
Signature Option", RFC 3562, July 2003.
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe,
"Negotiation of NAT-Traversal in the IKE", RFC 3947,
January 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5", RFC
4808, March 2007.
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC
4953, July 2007.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[Sa99] Savage, S., N. Cardwell, D. Wetherall, T. Anderson, "TCP
Congestion Control with a Misbehaving Receiver", ACM
Computer Communications Review, V29, N5, pp71-78, October
1999.
[SDNS88] Secure Data Network Systems, "Security Protocol 4 (SP4)",
Specification SDN.401, Revision 1.2, July 12, 1988.
[To07] Touch, J. and A. Mankin, "The TCP Simple Authentication
Option", Work in Progress, July 2007.
[To10] Touch, J., "A TCP Authentication Option NAT Extension",
Work in Progress, January 2010.
[Wa05] Wang, X., H. Yu, "How to break MD5 and other hash
functions", Proc. IACR Eurocrypt 2005, Denmark, pp.19-35.
[We05] Weis, B., Appanna, C., McGrew, D., and A. Ramaiah, "TCP
Message Authentication Code Option", Work in Progress,
December 2005.14. Acknowledgments ✨
okay so this doc didn't just appear out of nowhere 🌸 it came from the TCP Authentication Design team (tcp-auth-dt), and the squad was (alphabetically): Mark Allman, Steve Bellovin, Ron Bonica, Wes Eddy, Lars Eggert, Charlie Kaufman, Andrew Lange, Allison Mankin, Sandy Murphy, Joe Touch, Sriram Viswanathan, Brian Weis, and Magnus Westerlund 🫶 the text is actually derived from a proposal by Joe Touch and Allison Mankin [To07] (originally from June 2006), which was both inspired by and meant as a counterproposal to the TCP MD5 revisions in a doc by Ron Bonica, Brian Weis, Sriran Viswanathan, Andrew Lange, and Owen Wheeler [Bo07] (originally from September 2005) and in a doc by Brian Weis [We05] 💜
Russ Housley suggested L4/application layer management of the master key tuples 🔥 Steve Bellovin motivated the KeyID field 👑 Eric Rescorla suggested using TCP's Initial Sequence Numbers (ISNs) in the traffic key computation, plus SNEs, to avoid replay attacks 🙈 and Brian Weis extended the computation to include the entire connection ID and gave us the details of the traffic key computation 💅 then Mark Allman, Wes Eddy, Lars Eggert, Ted Faber, Russ Housley, Gregory Lebovitz, Tim Polk, Eric Rescorla, Joe Touch, and Brian Weis built the master key coordination mechanism, and honestly that's giving teamwork 🧚
Alfred Hoenes, Charlie Kaufman, Adam Langley, and a bunch of other TCPM WG folks also gave substantial feedback on this doc ✨ literally so many brains 🌈
This document was originally prepared using 2-Word-v2.0.template.dot 🎀
Authors' Addresses 🦋
Here are the authors' details, copied exactly so you can reach them:
Joe Touch
USC/ISI
4676 Admiralty Way
Marina del Rey, CA 90292-6695
U.S.A.
Phone: +1 (310) 448-9151
EMail: touch@isi.edu
URL: http://www.isi.edu/touch
Allison Mankin
Johns Hopkins Univ.
Baltimore, MD
U.S.A.
Phone: 1 301 728 7199
EMail: mankin@psg.com
URL: http://www.psg.com/~mankin/
Ronald P. Bonica
Juniper Networks
2251 Corporate Park Drive
Herndon, VA 20171
U.S.A.
EMail: rbonica@juniper.net📦 where this page comes from
- ietf: rfc5925 2010-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms