RFC 6013
TCP Cookie Transactions (TCPCT)
🎀 TCP Cookie Transactions (TCPCT) 🎀
Bestie, this one is an Independent Submission! It was written by W. Simpson from DayDreamer 💖 It's in the Experimental category, dated January 2011, and its ISSN is 2070-1721 ✨ The header doesn't list anything it obsoletes or updates, so there's nothing to cross-check there 🦋
Abstract
okay so TCP Cookie Transactions (TCPCT) stops spoofed connections and resource exhaustion before they start 🛡️ The big move is that the Responder (server) doesn't have to keep any state during the initial handshake. 👑 The Initiator (client) is the one in charge of making sure the required delays between connections happen. 🕰️ The cookie exchange can carry data too, but it's limited so it can't be used for amplification and reflection denial of service attacks 💀
Status of This Memo
Real talk, this doc is not an Internet Standards Track spec 📚 It's published so people can examine it, try implementing it, and evaluate it 🧪
It defines an Experimental Protocol for the Internet community 🌈 It's a contribution to the RFC Series, and it's independent of any other RFC stream. The RFC Editor picked to publish it at their discretion and makes no statement about whether it's worth implementing or deploying 🤷♀️ Anything the RFC Editor approves isn't a candidate for any level of Internet Standard. Check Section 2 of RFC 5741 if you want the receipts 📖
For the current status, errata, and how to leave feedback, head to http://www.rfc-editor.org/info/rfc6013 🔗
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved 💜
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date. Please actually read these, because they spell out your rights and restrictions 📜
This document may not be modified, and derivative works of it may not be created, except to format it for publication as an RFC or to translate it into languages other than English 🌸
Table of Contents
1. Introduction ....................................................4
1.1. Terminology ................................................4
2. Protocol Overview ...............................................4
2.1. Message Summary (Simplified) ...............................6
2.2. Compatibility and Transparency .............................7
2.3. Fully Loaded Cookies .......................................7
2.4. TCP Header Extension .......................................8
2.5. <SYN> Option Handling ......................................9
3. Protocol Details ................................................9
3.1. TCP Cookie Option .........................................10
3.2. TCP Cookie-Pair Standard Option ...........................10
3.3. TCP Cookie-less Option ....................................11
3.4. TCP Timestamps Extended Option ............................11
3.5. Cookie Generation .........................................13
4. Cookie Exchange ................................................16
4.1. Initiator <SYN> ...........................................16
4.2. Responder <SYN,ACK(SYN)> ..................................17
4.3. Initiator <ACK(SYN)> ......................................17
4.4. Responder <ACK> ...........................................18
4.5. Simultaneous Open .........................................18
5. Accelerated Close ..............................................19
5.1. Initiator Close ...........................................20
5.2. Responder Close ...........................................20
6. Accelerated Open ...............................................21
6.1. Initiator <SYN> Data ......................................21
6.2. Responder <SYN,ACK(SYN)> Data .............................22
6.3. Initiator <ACK(SYN)> Data .................................23
6.4. Responder <ACK> Data ......................................24
7. Advisory Reset .................................................24
8. Interactions with Other Options ................................24
8.1. TCP Selective Acknowledgment ..............................25
8.2. TCP Timestamps ............................................25
8.3. TCP Extensions for Transactions ...........................25
8.4. TCP MD5 Signature .........................................25
8.5. TCP Authentication ........................................25
9. History ........................................................26
10. Acknowledgments ...............................................27
11. IESG Considerations ...........................................27
12. Operational Considerations ....................................28
13. Security Considerations .......................................28
Appendix A. Example Headers .......................................30
A.1. Example <SYN> Options .....................................30
A.2. Example <ACK(SYN)> with Sack ..............................31
A.3. Example <ACK(SYN)> with 64-bit Timestamps .................32
Normative References ..............................................33
Informative References ............................................341. Introduction ✨
TCPCT gives you a cryptologically secure way to stop simple flooding attacks that show up with bogus IP [RFC791] Sources or TCP [RFC793] Ports 🚫 The first TCP <SYN> exchange is wide open to forged IP Addresses, predictable Ports, and discoverable Sequence Numbers [Morris1985] [Gont2009] 😬 (See also [RFC2827], [RFC3704], and [RFC4953] if you want more drama 🎭)
During connection setup, the cookie (nonce) exchange negotiates getting rid of Responder (server) state 🧹 Those cookies are later used to stop connections from closing too early, and to cut down on state kept around after a connection ends 🔐
The cookie pair is way too big to fit alongside the other recommended options in the maximal 60 byte TCP header, which only gives you 40 bytes of option space 📏 Once an option exchange succeeds, that signals the TCP header extension is available, and it adds room for more options 🌟
Implementations may also optionally swap a small amount of transaction data during the initial cookie exchange 🚀 That cuts down on network latency and host task context switching, which is so efficient 💅
Last one: implementations may optionally recycle prior connections really fast 🔁 For stateless applications, this transparently makes persistent connections and pipelining of requests over each connection way easier 🦋
A lot of these ideas were already floating around in one form or another (check the History and Acknowledgments sections 🙈). This spec basically brings them together into one coherent whole 🧩 More motivation and rationale are in [MSV2009] if you're a deep-dive person 🤓
1.1. Terminology
The key words "MAY", "MUST, "MUST NOT", "OPTIONAL", "RECOMMENDED", "REQUIRED", "SHOULD", and "SHOULD NOT" in this document are to be interpreted as described in [RFC2119] 📖
byte: an 8-bit quantity, also known as "octet" in standardese 💜
2. Protocol Overview 🌸
TCPCT extensions are made of several simple phases 🎀
- Each party passes a "cookie" to the other. Space is limited, so only the most basic options get included 🍓
The Cookie option also says that optional <SYN> data is acceptable. This data MAY be ignored by either party 🫶
A Responder that understands the Cookie option stays stateless ✨
- During the rest of the standard TCP three-way handshake, the Timestamps and Cookie-Pair options guard the exchange 🛡️
Other options that were in the original <SYN> and got successfully returned in the <SYN,ACK(SYN)> MUST be included with the <ACK(SYN)>. Additional options MAY also be included if you want them 💅
Since there's no Responder state, the Responder has no record of acknowledging previous data. Any optional <SYN> data MUST be retransmitted 🔁
Once the Timestamps and Cookie-Pair are verified, the Responder creates its Transport Control Block (TCB) [RFC793] 🏗️
Notice that the Responder returns the Cookie-Pair with its initial data, but subsequent data segments only need the Timestamps 👀
- During close (or reset) of the TCP connection, the Timestamps and Cookie-Pair options guard the exchange 🔒
Once the Timestamps and Cookie-Pair are verified, the Responder removes its TCB 🧹
The message flow is summarized in the diagram below 📊
2.1. Message Summary (Simplified)
Initiator Responder
========= =========
<SYN> ->
base options
Timestamps
Cookie
[request data]
<- <SYN,ACK(SYN)>
base options
Timestamps
Cookie
[response data]
(stateless)
<ACK(SYN)> ->
full options
Timestamps
Cookie-Pair
[Sack(response)]
data
<- <ACK>
full options
Timestamps
Cookie-Pair
data
(TCB state created)
<- <ACK>
Timestamps
data
<- <FIN,ACK>
Timestamps
Cookie-Pair
<FIN,ACK(FIN)> ->
Timestamps
Cookie-Pair
<- <ACK(FIN)>
Timestamps
Cookie-Pair
(TCB state removed)
TIME-WAIT2.2. Compatibility and Transparency
It is usually better that data arrive slowly, than not at all. 🐢💕
Many or most unmanaged middleboxes [RFC3234] (like stateless firewalls, load balancers, intrusion detection systems, or network address translators [RFC3022]) can't carry transport traffic other than TCP and UDP 🙃
Every TCP implementation MUST ignore without error any TCP option it does not implement ([RFC1122] section 4.2.2.5) 🙌 A study of how middleboxes affect transport protocols [MAF2004] found that the vast majority of modern TCP stacks handle unknown TCP options correctly 👏 Even so, it's still prudent to follow the [RFC793] "general principle of robustness: be conservative in what you do, be liberal in what you accept from others." 🧘♀️
So for each extension defined here, an extension option will be sent in a <SYN,ACK(SYN)> segment only after the matching option was received in the original <SYN> segment 🎁
Furthermore, TCP options will be sent on later segments only after an exchange of options has shown that both parties understand the extension (see [RFC1323] [rfc1323bis] and its antecedents) 🤝
Unfortunately, not all middleware follows these long-standing requirements 😤 Instead, unknown <SYN> options get copied into the <SYN,ACK(SYN)>. That's literally indistinguishable from a Monkey in the Middle (MITM) reflection attack 🙀💀
2.3. Fully Loaded Cookies
One Kind to aid them all, One Kind to find them,
One Kind to hold them all and in the header bind them.Okay bestie, the cookie exchange is literally the main character of this whole spec 💅 The option has been "overloaded" with a baker's dozen of capabilities and facilities, and it's giving everything all at once 😭✨
- A. Top priority 🔥: the cookie exchange improves operational security for vulnerable servers against flooding attacks. It indicates that the Responder (server) will discard its initial state. Everything else is subordinate to this one.
- B. Together with Sequence and Timestamp values, Cookie values protect against insertion and reflection attacks 🛡️
- C. Cookie values let applications detect replay attacks 👀
- D. Cookie values MAY be used as an index or nonce for application security protocols. This facility is beyond the scope of this specification 🧚
- E. The
<SYN>and<SYN,ACK(SYN)>MAY carry application data. This feature is entirely optional, and data is not guaranteed to pass successfully through middleware. The parties are also not guaranteed to process this data without changes to the Application Program Interface (API). Those changes are beyond the scope of this specification 🙈 - F. The size of the cookies precludes most other options in the standard TCP header space. The cookie exchange negotiates TCP header extension 🎀
- G. The cookie exchange and resulting TCP header extension permit negotiation of larger 64-bit (or 128-bit) Timestamps for paths with large bandwidth-delay products 🚀
- H. TCP header extension frees some space for additional options 🍓
- I. Previously SYN-only options can be updated 🦋
- J. The cookie exchange indicates agreement to use accelerated close 🏃♀️
- K. The cookie exchange indicates agreement that only the Initiator (client) handles TIME-WAIT state 💅
- L. The Timestamps and Cookie-Pair combination inhibits third parties from disrupting communications with
<FIN>and<RST>🫶 - M. The Timestamps and Cookie-Pair combination facilitates rapid reuse of the TCP Source Port with a common destination 🌈
2.4. TCP Header Extension
Once the Cookie option has been successfully exchanged, TCP header extension is permitted ✨ The Timestamps extended option (defined below) is what signals that the header extension is present.
Validation of known timestamp values protects against data corruption by misbehaving middleboxes 🧐
2.5. <SYN> Option Handling
Okay so here's the thing: the Responder keeps no TCB state after the initial TCP <SYN> exchange, so all options present in the original <SYN> MUST be repeated 🔁
For example, an option defined in the [RFC793] original specification -- Maximum Segment Size (MSS) -- previously appeared only in a <SYN>-bearing segment (including <SYN,ACK(SYN)>). If it's present, MSS will be repeated in the Initiator <ACK(SYN)>, together with any additional options 💖
Generally, the Initiator MAY propose SYN-only options -- such as MSS -- anytime both Timestamps and Cookie-Pair options are present. These options are treated the same as with an original <SYN>. The Responder acknowledges using a subsequent <ACK> segment containing both Timestamps and Cookie-Pair options (similar to <SYN,ACK(SYN)> processing) 🤝
This facility allows previously SYN-only options to be updated from time to time. They take effect upon receipt ⭐
However,<ACK>segments without data will not be delivered reliably. Any otherwise SYN-only options sent without data MUST be retransmitted with successive segments until sent with data (or<FIN>), and an<ACK>is received. Don't skip this one, it's important 💀
3. Protocol Details
Another solution, [RFC5452], describes use of an unpredictable Source Port. That is RECOMMENDED by this specification. See [RFC6056] for further information 🌸
An earlier solution, [RFC1948], describes an unpredictable Initial Sequence Number (ISN). That is REQUIRED by this specification 🔐
Support for the (32-bit) TCP Timestamps Option [RFC1323] is REQUIRED. A TSoffset SHOULD be generated per connection [GO2010]. The Don't Fragment (DF) bit MUST be set in the IP (v4) header 🪽
The TCP User Timeout Option [RFC5482] is RECOMMENDED 🎀
Only one instance is permitted of any of the Cookie, Cookie-less, or Cookie-Pair option(s). Segments with duplicative or mutually exclusive options MUST be silently discarded 🙅♀️
For examples, see Appendix A 📖
3.1. TCP Cookie Option
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Kind — 1 byte: constant
253(experimental). - Length — 1 byte: range
10to18(bytes); limited by remaining space in the options field. The number MUST be even; the cookie is a multiple of 16 bits. - Cookie — 8 to 16 bytes (
Length - 2): an unpredictable value.
Options with invalid Length values MUST be ignored. The minimum Cookie size is 64 bits. If there is not sufficient space for a 64-bit cookie, this option MUST NOT be used 🙃
The Responder Cookie MUST be the same size as the Initiator Cookie. The cookie pair is a multiple of 32 bits 💜
Although the diagram shows a cookie aligned on 32-bit boundaries, that is not required ✨
3.2. TCP Cookie-Pair Standard Option
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Initiator-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Responder-Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Kind — 1 byte: constant
253(experimental). - Length — 1 byte: range
18to34(bytes). The number MUST be even; the cookie pair is a multiple of 32 bits. - Initiator-Cookie — 8 to 16 bytes, from the original
<SYN>. - Responder-Cookie — 8 to 16 bytes, from the
<SYN,ACK(SYN)>.
The Cookie-Pair standard option only appears after the Timestamps extended option (below) 🧩
Options with invalid Length values MUST be ignored. As the minimum Initiator-Cookie size is 64 bits, the minimum cookie pair is 128 bits (64 bits followed by 64 bits), while the maximum is 256 bits (128 bits followed by 128 bits) 🌟
3.3. TCP Cookie-less Option
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Kind — 1 byte: constant
253(experimental). - Length — 1 byte: constant
2(bytes). This distinguishes the option from other Cookie options.
Even though no cookie is attached, this signals that other features of this specification are available, including TCP header extension, Accelerated Close, Accelerated Open, and Advisory Reset ✨ It's intended for use with TCP authentication options, which are beyond the scope of this specification 🔑
3.4. TCP Timestamps Extended Option
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind | Length | Extend | R | S |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
~ TS Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TS Echo Reply ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Kind — 1 byte: constant
254(experimental). - Length — 1 byte: constant
4(bytes). - Extend — 1 byte: range
9to255; the data offset (in 32-bit words) following the standard TCP header. Note this value MUST include the timestamp pair indicated by (S)ize. - (R)eserved — 5 bits: default zero. Reserved for future use 🧸
- (S)ize — 3 bits:
1: 32-bit timestamps.2: 64-bit timestamps.4: 128-bit timestamps.
Other values are beyond the scope of this specification.
- TS Value — 4, 8, or 16 bytes. The current value of the timestamp for the sender ⏰
- TS Echo Reply — 4, 8, or 16 bytes. A copy of the most recently received TS Value 🪞
The full timestamp pair follows the TCP header (indicated by +=+ delimiters) and maintains 32-bit alignment 📏
This TCP header extension is ignored for sequence number computations. The Sequence Number of the first byte of segment data will be the Initial Sequence Number (ISN) plus one (1) for the <SYN> 🔢
Every TCPCT implementation MUST recognize a Timestamps extended option. The larger 64-bit (or 128-bit) timestamps only appear in an extended option 🌈
Segments with invalid Extend values MUST be silently discarded.
Only one instance is permitted of either the (32-bit) Timestamps standard option or this Timestamps extended option. Segments with duplicative or mutually exclusive options MUST be silently discarded 🚫
Implementation Notes:
Serendipitous alignment allows simple loads and stores, instead of slower byte by byte iterations 🤩
When the TCP header is aligned on a 32-bit boundary and this is the only option, the timestamps in the extended header SHOULD be aligned on a 64-bit boundary. For both 32-bit and 64-bit timestamps, any data following the extended header will be aligned on a 64-bit boundary.
However, the 128-bit timestamps are not 128-bit aligned 👀
3.5. Cookie Generation 🍪
Okay so, how a party generates its cookie is totally up to the implementation 💅 but the method has to hit some basic requirements:
- The cookie MUST depend on the specific parties. This stops an attacker from grabbing a cookie using a real IP address and TCP port, then using it to flood the victim with requests from randomly chosen IP addresses or ports 🙅♀️
- It MUST NOT be possible for anyone other than the issuing entity to generate cookies that will be accepted by that entity. So the issuer uses local secret info when making and checking cookies, and nobody should be able to figure out that secret from any single cookie 🔐
- The cookie generation and verification methods MUST be fast, to shut down attacks that try to sabotage CPU resources 🏃♀️
A recommended technique is to use a cryptographic hashing function. 🧁
An incoming cookie can be verified at any time by regenerating it locally from values in the incoming datagram plus the local secret random value. ✅
3.5.1. Initiator Cookie
The Initiator secret value that affects its cookie SHOULD change for each new exchange, and then it gets cached per TCB. This gives better synchronization and protection against replay attacks 🔁
An alternative is to cache the cookie instead of the secret value. Then incoming cookies can be compared directly, without the computational cost of regenerating them 🧠
It is RECOMMENDED that the cookie be calculated over the secret value, the IP Source and Destination addresses, the TCP Source and Destination ports, and any (optional) Initiator <SYN> segment data. 💖
Implementation Notes:
- Although the recommendation includes the TCP Source Port, this is very implementation specific. For example, it might not be included when the value is constant or unknown.
- Likewise, segment data might not be included directly. For example, a pointer to the data could be included instead, with care taken to ensure the pointer changes anytime the data changes.
- However, it is important that the implementation protect mutually suspicious users of the same system from generating the same cookie. Super important, no cap 🫶
3.5.2. Responder Cookie
The Responder secret value that affects its cookies stays the same for many different Initiators. However, this secret SHOULD be changed periodically to limit how long its cookies can be used (typically each 600 seconds) ⏰
The Responder-Cookie calculation MUST include its own TCP Sequence and Acknowledgment Numbers (after updating values), its own TCP Timestamps value, and the Initiator-Cookie value. This gives better synchronization and protection against replay attacks ✨
It is RECOMMENDED that the cookie be calculated over the secret value, the IP Source and Destination addresses, its own TCP Destination Port (that is, the incoming Source Port), and the required values (above), followed by the secret value again. 🎀
The cookie is not cached per Initiator, so no state gets saved during the initial TCP <SYN> exchange. When a TCP <ACK(SYN)> arrives, the Responder regenerates its cookie to validate it 🧚
Implementation Notes:
- Although the recommendation does not include the TCP Source Port, this is very implementation specific. It might be successfully included in some variants.
- The Responder Cookie depends on the TCP Sequence and Acknowledgment Numbers as they will appear for future verification. The Sequence Number will be the Initial Sequence Number (ISN) plus one (1) for its <SYN> that will be acknowledged. The Acknowledgment Number will be the Initial Sequence Number (ISN) plus one (1) for the <SYN> that it is now acknowledging.
- The (32-bit) TCP Timestamps standard option MAY change to the larger 64-bit (or 128-bit) extended form; only the least significant 32 bits are included. The Initiator Timestamp field value MAY increment during the exchange; it MUST NOT be included.
- The secret value is included twice to better protect against pre-calculated attacks using substitutions for variable length data. Some examples using this technique are IP-MAC and H-MAC, and it is likely that existing code could be shared. 🧩
- The Responder SHOULD designate a (fixed or randomly selected) bit of its cookie to distinguish each changed secret value. The bit is set to a (fixed or randomly selected) constant 0 or 1, and checked upon receipt before further verification. This ensures that only one verification calculation is necessary (on average) during Denial of Service (DoS) attacks 🛡️
- If a Responder Cookie is identical to the Initiator Cookie, the Responder SHOULD change one or more bits of its cookie to prevent its accidental appearance as a reflection attack. 🙈
3.5.3. Responder Secret Value
Each Responder maintains up to two secret values concurrently for efficient secret rollover. Each secret value has 4 states:
- Generating: Generates new Responder-Cookies, but is not yet used for primary verification. This is a short-term state, typically lasting only one Round Trip Time (RTT).
- Primary: Used both for generation and primary verification.
- Retiring: Used for verification, until the first failure that can be verified by the newer Generating secret. At that time, this cookie's state is changed to Secondary, and the Generating cookie's state is changed to Primary. This is a short-term state, typically lasting only one RTT.
- Secondary: Used for secondary verification, after primary verification failures. This state lasts no more than twice the Maximum Segment Lifetime (2MSL). Then, the secret is discarded.
Implementation Notes:
- Care MUST be taken to ensure that any expired secrets are promptly wiped from memory, and secrets are never saved to external storage. 🧹
- The first secret after initialization begins in Primary state. The system might have shut down and restarted rapidly during the previous first secret. Thus, the first secret MUST be partially time dependent, to ensure that it differs from previous first secrets, usually by appending a time to lengthen the first secret. Those that are not the first secret SHOULD NOT include the time. ⏳
- At the same time, there is no TCP TIME-WAIT requirement before accepting connections, and there may be pent up demand for a busy service. Also, there may be outstanding datagrams attempting to complete an earlier cookie exchange. The first secret is likely to be the weakest, as no recent entropy has been included. 😬
- Therefore, while terminating outstanding exchanges with the first secret, a new Generating secret SHOULD be created after no more than one Maximum Segment Lifetime (1MSL). Subsequent secrets SHOULD be generated at the usual rate (typically 600 seconds). 🔄
- The implementation SHOULD continually gather additional entropy from checksums, cookies, timestamps, and packet arrival timing. 🎲
4. Cookie Exchange 🤝
A successful option exchange signals availability of additional features. 🌸
4.1. Initiator <SYN>
The Cookie exchange MAY be initiated at any time, limited only by the frequency of the timestamp clock. ⏱️
If the TCB exists from a prior (or ongoing) connection, the timestamp MUST be incremented in the option.
The Initiator generates its unpredictable cookie value, and includes the Cookie option. 🍪
During the initial exchange, the Initiator is solely responsible for retransmission. Although the cookie and sequence have not changed, each retransmission appears to the Responder as another original <SYN>. 🔁
Implementation Notes:
- Sending the <SYN> SHOULD NOT affect any existing TCB. This allows an additional RTT for duplicate or out-of-sequence segments to drain.
- The new TCB information SHOULD be temporarily cached until a valid matching <SYN,ACK(SYN)> arrives. Then, any old TCB values are replaced. 🧼
4.2. Responder <SYN,ACK(SYN)>
Upon receipt of the <SYN> with a Cookie option, the Responder determines whether there are sufficient resources to begin another connection. 💪
If the TCB exists from a prior (or ongoing) connection, the timestamp MUST be incremented in the option.
Each Sequence Number MUST be randomized [RFC1948]. 🎲
The Responder generates its unpredictable cookie value, and includes the Cookie option.
As the Responder retains no TCB state, retransmission timers are not available. Arrival of an Initiator's retransmission appears to be an original <SYN> transmission. There are no differences in processing. 👯
Implementation Notes:
- Sending the <SYN,ACK(SYN)> MUST NOT affect any existing TCB. This allows an additional RTT for duplicate or out-of-sequence segments to drain.
- This also inhibits third parties from disrupting communications. 🚫
4.3. Initiator <ACK(SYN)>
Upon receipt of the <SYN,ACK(SYN)> with a Cookie option, the Initiator validates its cookie, timestamp, and corresponding Acknowledgment Number. The existing TCB is updated as necessary. 🔍
All Initiator <SYN> options are always retransmitted on this first <ACK(SYN)>, allowing the Responder to validate its cookie and establish its state. 📦
This segment contains both Timestamps and Cookie-Pair options. 🎀
The Initiator sends the Timestamps extended option with an appropriate Size -- chosen by a configurable parameter, or automatically based on its analysis of the bandwidth-delay product discovered through the RTT of its <SYN> timestamp. When the chosen Size is greater than 32 bits, the Initiator adds a random prefix to its own timestamp, and a random prefix to the Responder timestamp echo reply. 🧮
Implementation Notes:
- A Responder Cookie identical to the Initiator Cookie MUST be discarded. This is usually an indication of a Monkey in the Middle (MITM) reflection attack or a seriously misconfigured network, and SHOULD be logged.
Lowkey alarm bells: a matching cookie pair is a red flag for a MITM reflection attack. Drop it and log it, bestie 🚨
4.4. Responder <ACK>
Upon receipt of the <ACK(SYN)> with a Cookie-Pair option, the Responder validates its cookie, timestamp, and corresponding Acknowledgment Number, and establishes state for the connection. Any existing TCB is updated as necessary. 🦋
This segment contains both Timestamps and Cookie-Pair options. 💜
However, the Responder MAY refuse to negotiate the larger 64-bit (or 128-bit) Timestamps extended option by returning the least significant bits in a smaller Timestamps extended option. 🙏
Implementation Notes:
- An <ACK(SYN)> that fails to validate MUST be discarded, and SHOULD be logged. 📝
4.5. Simultaneous Open 🦋
okay so TCP lets two people hit "connect" at the exact same time 😭 Both sides send an original <SYN> without waiting for a <SYN,ACK(SYN)> first (see [RFC793] section 3.4 and Figure 8). Each side gets a Cookie for a <Source Address, Source Port, Destination Address, Destination Port> connection that has also issued a Cookie. It's giving two people walking through a door at the same time 🚪💀
This is super rare, so it's giving plot twist. The Source Port SHOULD be randomized [RFC5452], and SHOULD be picked to be different from the Destination Port. Specifically, the Source Port SHOULD be greater than 1024, so random network equipment doesn't accidentally misread the return traffic 🙈 The Destination Port is most likely a well-known port under 1024 [RFC3232], so that part is pretty standard. ✨
If those protections somehow aren't enough, the tie gets broken in a very orderly way:
a. The lesser TCP Port number becomes the Responder;
b. The lesser IP Address becomes the Responder;
c. The lesser Cookie becomes the Responder;
d. If all of the above are equal, there is an egregiously insufficient source of randomness, but both Initiators are probably on the same host: the lesser TCB memory address becomes the Responder. 💀
The Initiator silently discards the simultaneous <SYN>. The Responder updates its Cookie option and sends the <SYN,ACK(SYN)> as usual, but it doesn't remove its existing TCB. 🫶
Implementation Notes:
This is usually a sign of a Monkey in the Middle (MITM) reflection attack or a seriously misconfigured network, and it SHOULD be logged. 🚨 Not a vibe, bestie.
5. Accelerated Close 🌸
Support for accelerated close is REQUIRED. 👑 Accelerated close relies on cookies and timestamps, which gives you better synchronization and protection against replay attacks. Iconic. 🔥
Either party MAY close with <FIN> at any time. This <FIN> SHOULD ride along with the final data segment. 🎀
This segment carries both Timestamps and Cookie-Pair options.
Once all segments before the <FIN> have been processed and acknowledged, each party SHOULD acknowledge the <FIN>. ✅
In general, <FIN> is advisory, not a hard rule 💅 A persistent connection can be re-established really fast, and it also makes it harder for third parties to mess with the conversation. Main character energy.
Closing the connection quickly speeds up removing Responder state. Any segment bearing <FIN> SHOULD end a delayed <ACK> [RFC5681]. Retransmit at the latest Timestamps estimated Smoothed Round Trip Time (SRTT). Backoff SHOULD NOT be used for <FIN>-bearing retransmissions [RFC2988]. Don't back off here, periodt 🙅♀️
Since the Responder keeps no TCB state after closing, a successful option exchange tells the Initiator that it will be the one handling TIME-WAIT state. (For the earlier proposal and reasoning, see [FTY1999] section 3. 🧚)
A new Cookie exchange MAY be started at any time. This helps persistent connections survive intervening network equipment ✨
5.1. Initiator Close 🍓
When the Responder gets the Initiator's <FIN> (and the Timestamps and Cookie-Pair options check out), it sends its <FIN,ACK(FIN)>, unless there's more data pending. If there is, the <FIN> gets ignored until that data has been processed and acknowledged.
When the Initiator gets the Responder's <FIN,ACK(FIN)> (and the Timestamps and Cookie-Pair options check out), it sends its final <ACK(FIN)>, unless there's more data pending. Then the Initiator enters TIME-WAIT state. ⏳
This segment carries both Timestamps and Cookie-Pair options.
When the Responder gets the Initiator's <ACK(FIN)> (and the options check out), it removes its TCB. Bye bye TCB 👋
If more data shows up and triggers a new Cookie exchange, the Initiator SHOULD NOT send a final <ACK(FIN)> and/or SHOULD NOT wait out the rest of the TIME-WAIT interval. Any existing TSoffset SHOULD be incremented. TSoffset gets removed (along with the TCB itself) when a future TIME-WAIT state wraps up 🫧
5.2. Responder Close 💜
When the Initiator gets the Responder's <FIN> (and the Timestamps and Cookie-Pair options check out), it sends its <FIN,ACK(FIN)>, unless there's more data pending. If there is, the <FIN> gets ignored until that data has been processed and acknowledged.
When the Responder gets the Initiator's <FIN,ACK(FIN)> (and the options check out), it sends its final <ACK(FIN)> and removes its TCB. 🧹
This segment carries both Timestamps and Cookie-Pair options.
If the Responder's final <ACK(FIN)> gets lost, the Responder will probably send a <RST> instead (since it doesn't keep any TCB state). This distinguished <RST> SHOULD copy both Timestamps and Cookie-Pair options. 🙃
When the Initiator gets the Responder's final <ACK(FIN)> (and the options check out), it enters TIME-WAIT state.
If more data shows up and triggers a new Cookie exchange, the Initiator SHOULD NOT send a <FIN,ACK(FIN)> and/or SHOULD NOT wait out the rest of the TIME-WAIT interval. Any existing TSoffset SHOULD be incremented. TSoffset gets removed (along with the TCB itself) when a future TIME-WAIT state wraps up. Same energy as before, just flipped 🔄
6. Accelerated Open 🧚♀️
Support for accelerated open is OPTIONAL. You can skip it if you don't need it, no pressure 🫶
When an application can do idempotent transactions (like a query that gives back a consistent result or a service response heading), the application sets the right limit separately for each port or connection. The applications are responsible for making sure retransmissions don't duplicate data. Be responsible, bestie 💅
This feature lets single-data-segment transactions happen without setting up TCB state at the Responder (server). For longer transactions, a quick look-ahead at upcoming data lets the Initiator (client) pick alternatives for further processing. Smart, right? 🧠✨
6.1. Initiator <SYN> Data 🎀
By default, the Initiator's <SYN> doesn't carry data. The application sets TCP_SYN_DATA_LIMIT to say that the <SYN> MAY be sent with data.
The Responder Maximum Segment Size (MSS) is unknown, so the default MSS (536 bytes) MUST be used instead ([RFC1122] section 4.2.2.6). This gets reduced further by the total length of the TCP options (in this case, commonly 496 bytes). Applications MAY specify a shorter limit. 📏
If the data won't entirely fit in the initial segment, data MUST NOT be sent until after the Responder's <SYN,ACK(SYN)> is received. No cutting in line 🚫
Unlike T/TCP [RFC1644], <FIN> SHOULD NOT be sent with <SYN> data. This helps persistent connections. 💖
Same deal with <PSH>: it SHOULD NOT be set. Even though the application might use push to say its data is ready to go, push is implied for <SYN> data segments anyway. 🌈
During the initial exchange, the Initiator is solely responsible for retransmission. The cookie and sequence haven't changed, but each retransmission looks to the Responder like another original <SYN> 🔁
Implementation Notes:
An Initiator <SYN,FIN> with the Cookie option and no segment data is permitted in a test environment. This combination SHOULD be silently discarded. 🧪
An Initiator <SYN,FIN> with both the Cookie option and segment data is similar to T/TCP [RFC1644]. However, once the Responder has sent <SYN,ACK(SYN),FIN> with data (no more data is expected), TCB state hasn't been saved at the Responder. There's no need to send <FIN> to close the connection. Neat, right? 😭✨
6.2. Responder <SYN,ACK(SYN)> Data 🦋
By default, the Responder's <SYN,ACK(SYN)> doesn't carry data. The application sets TCP_SYN_ACK_DATA_LIMIT to say that the <SYN,ACK(SYN)> MAY be sent with data.
Segment data is capped at the Maximum Transmission Unit (MTU). Applications MAY specify a shorter limit to prevent spoofed amplification and reflection attacks [RFC5358]. That's a real security thing, so please don't skip it 🚨
When the <SYN> with a Cookie option arrives, the Responder MAY process any data present. If the initial data isn't accepted, the Acknowledgment Number will be the received Sequence Number plus one (1) for the <SYN>. 🔢
If the segment data is the entire response (no more data is expected), <FIN> MAY be set. 🏁
However, <PSH> SHOULD NOT be set. Even though the application might use push to say its data is ready to send, push is implied for <FIN> data segments (see [RFC793] section 3.7, page 41). 🙅♀️
Since the Responder keeps no TCB state, retransmission timers aren't available. When an Initiator's retransmission shows up, it looks like an original <SYN> transmission. There are no differences in processing. Consistent queen behavior 👑
Implementation Notes:
The Responder Cookie depends on the TCP Sequence and Acknowledgment Numbers after <SYN> has been processed. So neither of them will include data. 🧩
6.3. Initiator <ACK(SYN)> Data 💅
When the <SYN,ACK(SYN)> with a Cookie option arrives, the Initiator MAY process any data present. In this case, the internal RCV.NXT is advanced to provide at-most-once semantics. ✨
If the segment data is the entire response (no more data is expected), the Initiator enters TIME-WAIT state. ⏳
Otherwise, the original <SYN> data is retransmitted in <ACK(SYN)>, since processing it is optional. The Acknowledgment Number will be the received Sequence Number plus one (1) for the <SYN>. The Sequence Number will be the Initial Sequence Number (ISN) plus one (1) for the <SYN>. 🔁
Unlike T/TCP [RFC1644], there's no implicit acknowledgment. 🙅♀️
If the Selective Acknowledgment (Sack) option [RFC2018] was successfully negotiated, a short Sack acknowledging the response data MAY be sent right after the Cookie-Pair in the extended header. 🧁
At this point, any second segment may be sent without waiting for an <ACK>, following the usual [RFC5681] TCP congestion control process. 🚀
Implementation Notes:
When more data shows up and triggers a new Cookie exchange, there's no need to increment the previous timestamp, since TCB state hasn't been saved at the Responder. Instead, use the saved RCV.NXT, plus one (1) for the (actual or implied) <FIN>. 🧠
An Initiator <ACK(SYN),FIN> with the Cookie-Pair option and no segment data is never actually required, since TCB state hasn't been saved at the Responder. This combination MUST be silently discarded. 🗑️
6.4. Responder <ACK> Data 🌸
When the <ACK(SYN)> with a Cookie-Pair option arrives (and the Timestamps and Cookie-Pair options check out), the Responder SHOULD process any data present. 🫶
Since the TCP Sequence and Acknowledgment Numbers haven't advanced, the Responder will process the same incoming data and send the same response. Déjà vu, but make it protocol 🔁
If the Selective Acknowledgment (Sack) option [RFC2018] was successfully negotiated, and a short Sack covers earlier response data, only the additional unacknowledged response data gets sent. ✅
At this point, any second segment may be sent without waiting for an <ACK>, following the usual [RFC5681] TCP congestion control process. 🦋
7. Advisory Reset ✨
okay so this section is about what happens when a <RST> shows up and the cookie doesn't check out 👀. If a TCB with matching Addresses and Ports is found, but the Cookie-Pair fails to verify, the datagram MUST be silently discarded. no reply, just ghosted 💀
When no TCB with matching Addresses and Ports is found, a <RST> is sent as usual. The Timestamps option SHOULD be copied [RFC1323]. A Cookie-Pair option MUST also be copied. The Cookie option (or Cookie-less option) MUST NOT be copied 🙈
Any <RST> is always treated as advisory. A <RST> without a matching Cookie-Pair option could be caused by antique duplicates 🏺 Receipt has no effect on the operation of the protocol. The implementation SHOULD continue until a USER TIMEOUT expires. (See [RFC5482] for additional information.)
This also keeps third parties from messing with your communications 🛡️✨
8. Interactions with Other Options 🧚
A successful Cookie (or Cookie-less) option exchange is basically the signal that the TCP header extension is available 📡 Other options with large data portions MAY also use this feature. The extended option data is processed in the order that the options appear, so order matters, bestie 🫶
8.1. TCP Selective Acknowledgment
(Kind 5 [RFC2018].) The pairs of 32-bit fields are a perfect fit for the header extension 🦋 Because of its variable size, this is RECOMMENDED as the final extended option.
During the cookie exchange, the <ACK(SYN)> MAY include this option to acknowledge any optional transaction response data 💜
8.2. TCP Timestamps
(Kind 8 [RFC1323].) Support is REQUIRED. See also section 3. ⏰
When a segment needs no header extension, and 32-bit timestamps have been negotiated, this option MUST be sent.
8.3. TCP Extensions for Transactions
(Kinds 11-13 [RFC1644].) Incompatible with this specification, so it MUST be ignored on receipt. not it 🙅♀️
8.4. TCP MD5 Signature
(Kind 19 [RFC2385].) This option is beyond the scope of this specification. Because specific configuration is required, sending is under the complete control of the operator 🔐 Segments lacking this option will be silently discarded.
The size of the option itself precludes use with the Cookie option in the <SYN>. Regardless of the system default, the Cookie option MUST NOT be sent, and MUST be ignored on receipt. Instead, the Cookie-less extension option indicates that other features of this specification are available ✨
8.5. TCP Authentication
(Kind 29 [RFC5925].) This option is beyond the scope of this specification. Because specific configuration is required, sending is under the complete control of the operator 🔐 Segments lacking this option will be silently discarded.
The size of the option itself precludes use with the Cookie option in the <SYN>. Regardless of the system default, the Cookie option MUST NOT be sent, and MUST be ignored on receipt. Instead, the Cookie-less extension option indicates that other features of this specification are available 🌸
9. History 📜
T/TCP [RFC1379] [RFC1644] permits lightweight TCP transactions for applications that traditionally have used UDP. However, T/TCP has unacceptable security issues [Hannum1996] [Phrack1998] 😬
The initial specification [KS1995] of Photuris [RFC2522], now called version 1 (December 1994 to March 1995), was based on a short list of design requirements, and simple experimental code by Phil Karn. A "Cookie" Exchange guards against simple flooding attacks sent with bogus IP Sources or UDP Ports 🍓
During 1995, the Photuris efficient secret rollover and many other extensions were specified. Multiple interoperable implementations were produced 🎀
By September 1996, the long anticipated Denial of Service (DoS) attacks in the form of TCP SYN floods were devastating popular (and unpopular) servers and sites 😭 Phil Karn informally mentioned adapting anti-clogging cookies to TCP. Perry Metzger proposed adding Karn's cookies as part of a "TCP++" effort [Metzger1996].
Later in 1996, Daniel J. Bernstein implemented "SYN cookies", small cookies embedded in the TCP SYN Initial Sequence Number (ISN). This technique was exceptionally clever, because it did not require cooperation of the remote party and could be deployed unilaterally 🧠 However, SYN cookies can only be used in emergencies; they are incompatible with most TCP options. As there is insufficient space in the Sequence Number, the cookie is not considered cryptologically secure. Therefore, the mechanism remains inactive until the system is under attack, and thus is not well tested in operation. SYN cookies were not accepted for publication until recently [RFC4987] 🥲
In 1998, Perry Metzger proposed adding Karn's cookies as part of a "TCPng" discussion [Metzger1998].
In 1999, Faber, Touch, and Yue [FTY1999] proposed using an option to negotiate the party that would maintain TIME-WAIT state. This permits a server to entirely eliminate state after closing a connection 👑
In 2000, the Stream Control Transmission Protocol (SCTP) [RFC2960] was published with an inadequate partial cookie mechanism claiming to be based upon Photuris. It featured a deficient checksum (replaced in 2002 by [RFC3309] without graceful transition), and has undergone subsequent revisions [RFC4960] 🫠
In 2006, the Datagram Congestion Control Protocol (DCCP) [RFC4340] was published with a mechanism analogous to SYN cookies 🌈
10. Acknowledgments 💖
Andre Broido informally described utilizing cookies for Transport Layer Security (TLS) session identifiers, in place of the [RFC5077] ticket. Rapid TLS session resumption would improve both latency and privacy, but is beyond the scope of this specification. Also, he provided numerous helpful comments and additional references, such as [KBC2005] 🙌
H. K. Jerry Chu and Arvind Jain informally described retaining existing cookies for accelerated open on subsequent connections. That feature was subsumed by this specification ✨
Wesley M. Eddy and Adam Langley previously proposed another pair of options [EL2008] extending the TCP header option space 🧩
Adam Langley previously proposed another option [Langley2008] permitting <SYN,ACK(SYN)> constant payload data. His (August 2008) code was a base for the initial TCPCT implementation 💅
Joe Touch postulated a (hopefully hypothetical) failure mode: options re-ordered by middleware. This caused a change in specifications, and has considerably complicated option interactions and processing. His helpful comments were appreciated 🫣
Many thanks to Fernando Gont for suggestions, and Rick Jones for performance testing 🥰
11. IESG Considerations 🏛️
Two TCP Option numbers are reserved for general experimental use under the rules laid out in [RFC4727] and [RFC3692] section 1. Such values reserved for experimental use are never to be made permanent; permanent assignments should be obtained through standard processes. Experimental numbers are intended for experimentation and testing and are not intended for wide or general deployments 🧪
For further information, contact the author.
12. Operational Considerations ⚙️
Any implementation of this specification SHOULD be configurable, separately for each port or connection. Knobs for days 🎛️ Here's the full list, copied exactly:
TCPCT_COOKIE_DESIRED
Values: 0 (disabled), 8, 10, 12, 14, 16. Default: 16. Send the
Cookie option with the <SYN>.
TCPCT_EXTEND_TS[32|64|128]
Default: off. If defined, may designate 32-bit, 64-bit, or
128-bit timestamps extension.
TCPCT_IN_ALWAYS
Default: off. Silently discard any incoming <SYN> that is missing
the Cookie option.
TCPCT_OUT_NEVER
Default: off. Refuse to send (override) the Cookie option.
TCP_SYN_DATA_LIMIT
Default: 0. Maximum: 496. The maximum amount of data transmitted
with the <SYN>. Wait for data before sending.
TCP_SYN_ACK_DATA_LIMIT
Default: 0. Maximum: 1220. The maximum amount of data
transmitted with the <SYN,ACK(SYN)>. Wait for data before
sending.Quick recap in my own words 💕
TCPCT_COOKIE_DESIRED: 0 (disabled), 8, 10, 12, 14, or 16, default 16. Sends the Cookie option with the <SYN>.TCPCT_EXTEND_TS[32|64|128]: default off. If defined, it may designate the 32-bit, 64-bit, or 128-bit timestamps extension.TCPCT_IN_ALWAYS: default off. Silently discards any incoming <SYN> missing the Cookie option.TCPCT_OUT_NEVER: default off. Refuses to send (overrides) the Cookie option.TCP_SYN_DATA_LIMIT: default 0, maximum 496. The most data sent with the <SYN>. Waits for data before sending.TCP_SYN_ACK_DATA_LIMIT: default 0, maximum 1220. The most data sent with the <SYN,ACK(SYN)>. Waits for data before sending.
13. Security Considerations 🔒
TCPCT was based on currently available tools, by experienced network protocol designers with an interest in cryptography, rather than by cryptographers with an interest in network protocols. This specification is intended to be readily implementable without requiring an extensive background in cryptology 🧑💻
Therefore, only minimal background cryptologic discussion and rationale is included in this document. Although some review has been provided by the general cryptologic community, it is anticipated that design decisions and tradeoffs will be thoroughly analysed in subsequent dissertations and debated for many years to come. Cryptologic details are reserved for separate documents that may be more readily and timely updated with new analysis 📚
The security depends on the quality of the random numbers generated by each party. Generating cryptographic quality random numbers on a general purpose computer without hardware assistance is a very tricky problem (see [RFC4086] for discussion) 🎲⚠️
TCPCT is not intended to prevent or recover from all possible security threats. Rather, it is designed to inhibit inadvertent middlebox interference, while protecting against Denial of Service (DoS) attacks. (See [RFC4732], and [RFC3552] section 4.6.3 et seq.)
The cookie exchange does not protect against an interloper that can race to substitute another value, nor an interceptor that can modify and/or replace a value. These attacks are considerably more difficult than passive vacuum-cleaner monitoring 🧹👀
Note that each incoming <SYN,ACK(SYN)> replaces the Responder cookie. The initial exchange is most fragile, as protection against spoofing relies entirely upon the sequence and timestamp. This replacement strategy allows the correct pair to pass through, while any others will be filtered via Responder verification later 🦋
Appendix A. Example Headers 🎀
A.1. Example <SYN> 💅
okay bestie, this is the SYN packet all dressed up for the party 🎀 Here's the option list in order:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=MSS | Length=4 | (value) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=UTO | Length=4 | (timeout) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=SackOK | Length=2 | Kind=TS | Length=10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS Echo Reply |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=Cookie | Length=16 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ Cookie +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=wscale | Length=3 | (value) | Kind=EOL |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+A 14 byte (112-bit) Cookie barely squeezes in with the other recommended options 🫶 The whole thing has to fit in the maximal 60 byte TCP header, which only leaves 40 bytes of option space. That's a tight outfit, periodt 😭
Since the cookies are required to be the same size and meet a 32-bit alignment requirement, the implementor recognizes that this order provides optimal packing. ✨ Honestly, the packing is immaculate.
The UserTimeOut (UTO) option can show up in other spots instead, like right after the Cookie option. Some middleboxes are picky about option order, though 🙈 so UTO should not appear before MSS nor between the TS and Cookie.
A.2. Example <ACK(SYN)> with Sack 🦋
this is the SYN-ACK reply, and it's giving a whole new look 🌸
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=TSX | Length=4 | Extend=16 | 0 | S=1 |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| TS Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS Echo Reply |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=nop | Kind=nop | Kind=Cookie | Length=30 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Initiator-Cookie +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ Responder-Cookie +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=MSS | Length=4 | (value) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=UTO | Length=4 | (timeout) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=nop | Kind=nop | Kind=Sack | Length=10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Starting Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ending Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=wscale | Length=3 | (value) | Kind=EOL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Sack implies SackOK. 💜 so if you're sending Sack, SackOK comes along for the ride, no cap.
A.3. Example <ACK(SYN)> with 64-bit Timestamps 🧚
this one has the bigger timestamps, so it's giving extra room to breathe 🌈
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=TSX | Length=4 | Extend=15 | 0 | S=2 |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
+ TS Value +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ TS Echo Reply +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=SackOK | Length=2 | Kind=Cookie | Length=30 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Initiator-Cookie +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ Responder-Cookie +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=MSS | Length=4 | (value) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=UTO | Length=4 | (timeout) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind=wscale | Length=3 | (value) | Kind=EOL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The larger 64-bit (or 128-bit) Timestamps extended option MUST be recognized, although the Responder MAY return a smaller Timestamps extended option. 👑 So the receiving side has to understand the big version, but the reply can stay small if it wants.
Normative References 📚
- [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
- [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.
- [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.
- [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.
- [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
- [RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002.
- [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More Resilient against Forged Answers", RFC 5452, January 2009.
- [RFC5482] Eggert, L. and F. Gont, "TCP User Timeout Option", RFC 5482, March 2009.
- [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.
Informative References ✨
okay bestie, this is the reading list 📚🎀 these are the works the authors leaned on for background. none of them are required to implement the spec, they're just the receipts 💅
[EL2008] Eddy, W. and A. Langley, "Extending the Space Available for TCP Options", Work in Progress, July 2008. 🦋
[FTY1999] Faber, T., Touch, J., and W. Yue, "The TIME-WAIT state in TCP and Its Effect on Busy Servers", IEEE INFOCOM 99, pp. 1573-1584. 🌸
[Gont2009] Gont, F., "Security assessment of the Transmission Control Protocol (TCP)", February 2009. https://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf 🔐
[GO2010] Gont, F. and A. Oppermann, "On the generation of TCP timestamps", Work in Progress, June 2010. ⏱️
[Hannum1996] Hannum, C., "Security Problems Associated With T/TCP", unpublished work in progress, September 1996. http://www.mid-way.org/doc/ttcp-sec.txt 💀
[KBC2005] Kohno, T., Broido, A., and K. C. Claffy, "Remote physical device fingerprinting", IEEE Symposium on Security and Privacy, May 2005. http://www.caida.org/outreach/papers/2005/fingerprinting/KohnoBroidoClaffy05-devicefingerprinting.pdf 🕵️♀️
[KS1995] Karn, P. and W. Simpson, "The Photuris Session Key Management Protocol", March 1995.
Published as: "Photuris: Design Criteria", Proceedings of Sixth Annual Workshop on Selected Areas in Cryptography, LNCS 1758, Springer-Verlag. August 1999. 🧚
[Langley2008] Langley, A., "Faster application handshakes with SYN/ACK payloads", Work in Progress, August 2008. 🚀
[MAF2004] Medina, A., Allman, M., and S. Floyd, "Measuring Interactions Between Transport Protocols and Middleboxes", Proceedings 4th ACM SIGCOMM/USENIX Conference on Internet Measurement, October 2004. http://www.icsi.berkeley.edu/pubs/networking/tbit-Aug2004.pdf 📊
[Metzger1996] Metzger, P., "Re: SYN floods (was: does history repeat itself?)", September 9, 1996. http://www.merit.net/mail.archives/nanog/1996-09/msg00235.html 📨
[Metzger1998] Metzger, P., "Re: what a new TCP header might look like", May 12, 1998. ftp://ftp.isi.edu/end2end/end2end-interest-1998.mail 🍓
[Morris1985] Morris, R., "A Weakness in the 4.2BSD Unix TCP/IP Software", Technical Report CSTR-117, AT&T Bell Laboratories, February 1985. http://pdos.csail.mit.edu/~rtm/papers/117.pdf 🏛️
[MSV2009] Metzger, P., Simpson, W., and P. Vixie, "Improving TCP Security With Robust Cookies", Usenix ;login:, December 2009. http://www.usenix.org/publications/login/2009-12/openpdfs/metzger.pdf 🍪
[Phrack1998] route|daemon9, "T/TCP vulnerabilities", Phrack Magazine, Volume 8, Issue 53, July 8, 1998. http://www.phrack.org/issues.html?issue=53&id=6 😭
[RFC1379] Braden, R., "Extending TCP for Transactions -- Concepts", RFC 1379, November 1992. 📘
[RFC1644] Braden, R., "T/TCP -- TCP Extensions for Transactions Functional Specification", RFC 1644, July 1994. 📗
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998. 🛡️
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management Protocol", RFC 2522, March 1999. 🔑
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. 🚧
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000. 🌊
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001. 🏠
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002. 📦
[RFC3309] Stone, J., Stewart, R., and D. Otis, "Stream Control Transmission Protocol (SCTP) Checksum Change", RFC 3309, September 2002. ✅
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. ✍️
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004. 🧪
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. 🌐
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. 🎲
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 📨
[RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. 🧪
[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and Internet Architecture Board, "Internet Denial-of-Service Considerations", RFC 4732, November 2006. 🚨
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC 4953, July 2007. 👑
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007. 🌊
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, August 2007. 🌧️
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, January 2008. 🔁
[RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive Nameservers in Reflector Attacks", BCP 140, RFC 5358, October 2008. 🪞
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010. 🔐
[RFC6056] Larson, M. and F. Gont, "Recommendations for Transport-Protocol Port Randomization", BCP 156, RFC 6056, January 2011. 🎰
[rfc1323bis] Borman, D., Braden, R., and V. Jacobson., "TCP Extensions for High Performance", Work in Progress, March 2009. 🚄
Author's Address 🎀
Questions about this document can be directed to:
William Allen Simpson 💌
DayDreamer 🌈
Computer Systems Consulting Services 💻
1384 Fontaine 🏡
Madison Heights, Michigan 48071 🇺🇸
EMail: William.Allen.Simpson@Gmail.com 🫶
📦 where this page comes from
- ietf: rfc6013 2011-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms