From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6013.txt | 2075 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 2075 insertions(+) create mode 100644 doc/rfc/rfc6013.txt (limited to 'doc/rfc/rfc6013.txt') diff --git a/doc/rfc/rfc6013.txt b/doc/rfc/rfc6013.txt new file mode 100644 index 0000000..5da6bbd --- /dev/null +++ b/doc/rfc/rfc6013.txt @@ -0,0 +1,2075 @@ + + + + + + +Independent Submission W. Simpson +Request for Comments: 6013 DayDreamer +Category: Experimental January 2011 +ISSN: 2070-1721 + + + TCP Cookie Transactions (TCPCT) + +Abstract + + TCP Cookie Transactions (TCPCT) deter spoofing of connections and + prevent resource exhaustion, eliminating Responder (server) state + during the initial handshake. The Initiator (client) has sole + responsibility for ensuring required delays between connections. The + cookie exchange may carry data, limited to inhibit amplification and + reflection denial of service attacks. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for examination, experimental implementation, and + evaluation. + + This document defines an Experimental Protocol for the Internet + community. This is a contribution to the RFC Series, independently + of any other RFC stream. The RFC Editor has chosen to publish this + document at its discretion and makes no statement about its value for + implementation or deployment. Documents approved for publication by + the RFC Editor are not a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6013. + + + + + + + + + + + + + + + + + +Simpson Experimental [Page 1] + +RFC 6013 TCP Cookie Transactions January 2011 + + +Copyright Notice + + Copyright (c) 2011 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) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. + + 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Simpson Experimental [Page 2] + +RFC 6013 TCP Cookie Transactions January 2011 + + +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. 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 ...........................................16 + 4.2. Responder ..................................17 + 4.3. Initiator ......................................17 + 4.4. Responder ...........................................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 Data ......................................21 + 6.2. Responder Data .............................22 + 6.3. Initiator Data .................................23 + 6.4. Responder 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 Options .....................................30 + A.2. Example with Sack ..............................31 + A.3. Example with 64-bit Timestamps .................32 + Normative References ..............................................33 + Informative References ............................................34 + + + +Simpson Experimental [Page 3] + +RFC 6013 TCP Cookie Transactions January 2011 + + +1. Introduction + + TCP Cookie Transactions (TCPCT) provide a cryptologically secure + mechanism to guard against simple flooding attacks sent with bogus IP + [RFC791] Sources or TCP [RFC793] Ports. The initial TCP + exchange is vulnerable to forged IP Addresses, predictable Ports, and + discoverable Sequence Numbers [Morris1985] [Gont2009]. (See also + [RFC2827], [RFC3704], and [RFC4953].) + + During connection establishment, the cookie (nonce) exchange + negotiates elimination of Responder (server) state. These cookies + are later used to inhibit premature closing of connections, and + reduce retention of state after the connection has terminated. + + The cookie pair is much too large to fit with the other recommended + options in the maximal 60 byte TCP header (40 bytes of option space). + A successful option exchange signals availability of the TCP header + extension, adding space for additional options. + + Also, implementations may optionally exchange limited amounts of + transaction data during the initial cookie exchange, reducing network + latency and host task context switching. + + Finally, implementations may optionally rapidly recycle prior + connections. For otherwise stateless applications, this + transparently facilitates persistent connections and pipelining of + requests over each connection. + + Many of these ideas have been previously proposed in one form or + another (see History and Acknowledgments sections). This + specification integrates these improvements into a coherent whole. + Further motivation and rationale were detailed in [MSV2009]. + +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 + + The TCPCT extensions consist of several simple phases: + + 1. Each party passes a "cookie" to the other. Due to limited space, + only the most basic options are included. + + + + +Simpson Experimental [Page 4] + +RFC 6013 TCP Cookie Transactions January 2011 + + + The Cookie option also indicates that optional data is + acceptable. This data MAY be ignored by either party. + + A Responder that understands the Cookie option remains stateless. + + 2. During the remainder of the standard TCP three-way handshake, the + Timestamps and Cookie-Pair options guard the exchange. + + Other options present in the original that were successfully + returned in the MUST be included with the + . Additional options MAY also be included as desired. + + As there is no Responder state, it has no record of acknowledging + previous data. Any optional data MUST be retransmitted. + + Upon verification of the Timestamps and Cookie-Pair, the Responder + creates its Transport Control Block (TCB) [RFC793]. + + Note that the Responder returns the Cookie-Pair with its initial + data, but subsequent data segments need only the Timestamps. + + 3. During close (or reset) of the TCP connection, the Timestamps and + Cookie-Pair options guard the exchange. + + Upon verification of the Timestamps and Cookie-Pair, the Responder + removes its TCB. + + The sequence of messages is summarized in the diagram below. + + + + + + + + + + + + + + + + + + + + + + + +Simpson Experimental [Page 5] + +RFC 6013 TCP Cookie Transactions January 2011 + + +2.1. Message Summary (Simplified) + + Initiator Responder + ========= ========= + -> + base options + Timestamps + Cookie + [request data] + <- + base options + Timestamps + Cookie + [response data] + (stateless) + + -> + full options + Timestamps + Cookie-Pair + [Sack(response)] + data + <- + full options + Timestamps + Cookie-Pair + data + (TCB state created) + <- + Timestamps + data + + <- + Timestamps + Cookie-Pair + -> + Timestamps + Cookie-Pair + <- + Timestamps + Cookie-Pair + (TCB state removed) + TIME-WAIT + + + + + + + + +Simpson Experimental [Page 6] + +RFC 6013 TCP Cookie Transactions January 2011 + + +2.2. Compatibility and Transparency + + It is usually better that data arrive slowly, than not at all. + + Many/most unmanaged middleboxes [RFC3234] (such as stateless + firewalls, load balancers, intrusion detection systems, or network + address translators [RFC3022]) cannot 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). In a study of the + effects of middleboxes on transport protocols [MAF2004], the vast + majority of modern TCP stacks correctly handle unknown TCP options. + But it is still prudent to follow the [RFC793] "general principle of + robustness: be conservative in what you do, be liberal in what you + accept from others." + + Therefore, for each of the extensions defined here, an extension + option will be sent in a segment only after the + corresponding option was received in the original segment. + + Furthermore, TCP options will be sent on later segments only after an + exchange of options has indicated that both parties understand the + extension (see [RFC1323] [rfc1323bis] and its antecedents). + + Unfortunately, not all middleware adheres to these long-standing + requirements. Instead, unknown options are copied to the + . This is 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. + + The cookie exchange provides a singular opportunity to extend TCP + with backward compatibility. Semantics for the option have been + "overloaded" with a baker's dozen of capabilities and facilities. + + A. First and foremost, the cookie exchange improves operational + security for vulnerable servers against flooding attacks. The + cookie exchange indicates that the Responder (server) will discard + its initial state. All other semantics are subordinate. + + B. Together with Sequence and Timestamp values, Cookie values protect + against insertion and reflection attacks. + + C. Cookie values allow applications to detect replay attacks. + + + +Simpson Experimental [Page 7] + +RFC 6013 TCP Cookie Transactions January 2011 + + + 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 and MAY carry application data. This + feature is entirely optional, and data is not guaranteed to pass + successfully through middleware. Nor are the parties guaranteed + to process this data without changes to the Application Program + Interface (API). Such 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 and . + + 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) indicates the presence of the header extension. + + Validation of known timestamp values protects against data corruption + by misbehaving middleboxes. + + + + + + + + + +Simpson Experimental [Page 8] + +RFC 6013 TCP Cookie Transactions January 2011 + + +2.5. Option Handling + + As the Responder retains no TCB state after the initial TCP + exchange, all options present in the original MUST be repeated. + + For example, an option defined in the [RFC793] original specification + -- Maximum Segment Size (MSS) -- previously appeared only in a + bearing segment (including ). If present, MSS will be + repeated in the Initiator , 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 . The + Responder acknowledges using a subsequent segment containing + both Timestamps and Cookie-Pair options (similar to + processing). + + This facility allows previously SYN-only options to be updated from + time to time. They take effect upon receipt. + + However, 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 + ), and an is received. + +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. + + + + + +Simpson Experimental [Page 9] + +RFC 6013 TCP Cookie Transactions January 2011 + + +3.1. TCP Cookie Option + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Kind | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Cookie ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Kind 1 byte: constant 253 (experimental). + + Length 1 byte: range 10 to 18 (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 18 to 34 (bytes). The number MUST be + even; the cookie pair is a multiple of 32 bits. + + Initiator-Cookie 8 to 16 bytes, from the original . + + + +Simpson Experimental [Page 10] + +RFC 6013 TCP Cookie Transactions January 2011 + + + Responder-Cookie 8 to 16 bytes, from the . + + 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. + + Although no cookie is attached, this indicates that other features of + this specification are available, including TCP header extension, + Accelerated Close, Accelerated Open, and Advisory Reset. This is + intended for use with TCP authentication options, 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). + + + + + + + +Simpson Experimental [Page 11] + +RFC 6013 TCP Cookie Transactions January 2011 + + + Extend 1 byte: range 9 to 255; 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 . + + 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. + + + + + + +Simpson Experimental [Page 12] + +RFC 6013 TCP Cookie Transactions January 2011 + + + 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 + + The technique by which a party generates a cookie is implementation + dependent. The method chosen must satisfy some basic requirements: + + 1. The cookie MUST depend on the specific parties. This prevents an + attacker from obtaining a cookie using a real IP address and TCP + port, and then using it to swamp the victim with requests from + randomly chosen IP addresses or ports. + + 2. It MUST NOT be possible for anyone other than the issuing entity + to generate cookies that will be accepted by that entity. This + implies that the issuing entity will use local secret information + in the generation and subsequent verification of a cookie. It + must not be possible to deduce this secret information from any + particular cookie. + + 3. The cookie generation and verification methods MUST be fast to + thwart attacks intended 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 contained in the incoming datagram and 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 is thereafter internally cached per TCB. This + provides improved synchronization and protection against replay + attacks. + + An alternative is to cache the cookie instead of the secret value. + Incoming cookies can be compared directly without the computational + cost of regeneration. + + + + + + + +Simpson Experimental [Page 13] + +RFC 6013 TCP Cookie Transactions January 2011 + + + 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 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. + +3.5.2. Responder Cookie + + The Responder secret value that affects its cookies remains the same + for many different Initiators. However, this secret SHOULD be + changed periodically to limit the time for use of its cookies + (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 provides + improved 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 to avoid saving state during + the initial TCP exchange. On receipt of a TCP , the + Responder regenerates its cookie for validation. + + 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 + + + +Simpson Experimental [Page 14] + +RFC 6013 TCP Cookie Transactions January 2011 + + + Number (ISN) plus one (1) for its that will be acknowledged. + The Acknowledgment Number will be the Initial Sequence Number + (ISN) plus one (1) for the 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 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. + + + + + + + +Simpson Experimental [Page 15] + +RFC 6013 TCP Cookie Transactions January 2011 + + + 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 shutdown 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 + + 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. + + + + +Simpson Experimental [Page 16] + +RFC 6013 TCP Cookie Transactions January 2011 + + + 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 + . + + Implementation Notes: + + Sending the 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 arrives. Then, any old TCB values are + replaced. + +4.2. Responder + + Upon receipt of the 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 transmission. There are no differences in processing. + + Implementation Notes: + + Sending the 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 + + Upon receipt of the with a Cookie option, the + Initiator validates its cookie, timestamp, and corresponding + Acknowledgment Number. The existing TCB is updated as necessary. + + + + + +Simpson Experimental [Page 17] + +RFC 6013 TCP Cookie Transactions January 2011 + + + All Initiator options are always retransmitted on this first + , 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 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. + +4.4. Responder + + Upon receipt of the 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 that fails to validate MUST be discarded, and SHOULD + be logged. + +4.5. Simultaneous Open + + TCP allows two parties to simultaneously initiate the connection. + Both parties send and receive an original without an + intervening (see [RFC793] section 3.4 and Figure 8). + Each party receives a Cookie for a connection that has also + issued a Cookie. + + + + +Simpson Experimental [Page 18] + +RFC 6013 TCP Cookie Transactions January 2011 + + + This condition will be unusual. The Source Port SHOULD be randomized + [RFC5452], and SHOULD be chosen to differ from the Destination Port. + In particular, the Source Port SHOULD be greater than 1024, + preventing intervening network equipment from incorrectly classifying + the return traffic. The Destination Port is most likely to be a + well-known port less than 1024 [RFC3232]. + + In the event that these protections are insufficient, the conflict is + resolved in an orderly fashion: + + 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. All of the above being equal, there is an egregiously insufficient + source of randomness, but both Initiators are probably present on + the same host: the lesser TCB memory address becomes the + Responder. + + The Initiator silently discards the simultaneous . The + Responder revises its Cookie option, and sends the as + usual, but without removing its existing TCB. + + Implementation Notes: + + This is usually an indication of a Monkey in the Middle (MITM) + reflection attack or a seriously misconfigured network, and SHOULD + be logged. + +5. Accelerated Close + + Support for accelerated close is REQUIRED. Accelerated close relies + on the presence of cookies and timestamps. This provides improved + synchronization and protection against replay attacks. + + Either party MAY close with at any time. This SHOULD be + sent with the final data segment. + + This segment contains both Timestamps and Cookie-Pair options. + + When all segments preceding the have been processed and + acknowledged, each party SHOULD acknowledge the . + + In general, is treated as advisory. A persistent connection + can be rapidly re-established. This also inhibits third parties from + disrupting communications. + + + +Simpson Experimental [Page 19] + +RFC 6013 TCP Cookie Transactions January 2011 + + + Rapidly closing the connection expedites removing Responder state. + Any bearing segment SHOULD terminate delayed [RFC5681]. + Retransmit at the latest Timestamps estimated Smoothed Round Trip + Time (SRTT). Backoff SHOULD NOT be used for bearing + retransmissions [RFC2988]. + + As the Responder retains no TCB state after closing, a successful + option exchange signals the Initiator will be responsible for + handling TIME-WAIT state. (For previous proposal and rationale, see + [FTY1999] section 3.) + + A new Cookie exchange MAY be initiated at any time. This facilitates + persistent connections through intervening network equipment. + +5.1. Initiator Close + + Upon receipt of the Initiator (and verification of the + Timestamps and Cookie-Pair options), the Responder sends its + unless there is additional data pending. In the + latter case, the is ignored until the data has been processed + and acknowledged. + + Upon receipt of the Responder (and verification of the + Timestamps and Cookie-Pair options), the Initiator sends its final + unless there is additional data pending. The Initiator + enters TIME-WAIT state. + + This segment contains both Timestamps and Cookie-Pair options. + + Upon receipt of the Initiator (and verification of the + Timestamps and Cookie-Pair options), the Responder removes its TCB. + + Upon arrival of more data prompting a new Cookie exchange, the + Initiator SHOULD NOT send a final and/or SHOULD NOT wait + the remaining TIME-WAIT interval. Any existing TSoffset SHOULD be + incremented. TSoffset will be removed (with the TCB itself) at the + conclusion of a future TIME-WAIT state. + +5.2. Responder Close + + Upon receipt of the Responder (and verification of the + Timestamps and Cookie-Pair options), the Initiator sends its + unless there is additional data pending. In the + latter case, the is ignored until the data has been processed + and acknowledged. + + + + + + +Simpson Experimental [Page 20] + +RFC 6013 TCP Cookie Transactions January 2011 + + + Upon receipt of the Initiator (and verification of the + Timestamps and Cookie-Pair options), the Responder sends its final + and removes its TCB. + + This segment contains both Timestamps and Cookie-Pair options. + + If the Responder's final is lost, the Responder is likely + to send a (as the Responder retains no TCB state). This + distinguished SHOULD copy both Timestamps and Cookie-Pair + options. + + Upon receipt of the Responder's final (and verification of + the Timestamps and Cookie-Pair options), the Initiator enters TIME- + WAIT state. + + Upon arrival of more data prompting a new Cookie exchange, the + Initiator SHOULD NOT send a and/or SHOULD NOT wait the + remaining TIME-WAIT interval. Any existing TSoffset SHOULD be + incremented. TSoffset will be removed (with the TCB itself) at the + conclusion of a future TIME-WAIT state. + +6. Accelerated Open + + Support for accelerated open is OPTIONAL. + + When an application is capable of idempotent transactions (such as a + query that returns a consistent result or service response heading), + the application sets the appropriate limit separately for each port + or connection. Applications are responsible for ensuring that + retransmissions do not cause duplication of data. + + This facility allows single data segment transactions without + establishing TCB state at the Responder (server). For longer + transactions, a short look-ahead of upcoming data allows the + Initiator (client) to select alternatives for further processing. + +6.1. Initiator Data + + By default, the Initiator does not contain data. The + application sets the TCP_SYN_DATA_LIMIT to indicate that the + MAY be sent with data. + + The Responder Maximum Segment Size (MSS) is unknown, and the default + MSS (536 bytes) MUST be used instead ([RFC1122] section 4.2.2.6). + This is further reduced by the total length of the TCP options (in + this case, commonly 496 bytes). Applications MAY specify a shorter + limit. + + + + +Simpson Experimental [Page 21] + +RFC 6013 TCP Cookie Transactions January 2011 + + + If the data will not entirely fit within the initial segment, data + MUST NOT be sent until after the Responder's is + received. + + Unlike T/TCP [RFC1644], SHOULD NOT be sent with data. + This facilitates persistent connections. + + Likewise, SHOULD NOT be set. Although the application might + use push to indicate that its data is ready to send, the push is + implied for data segments. + + 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 + . + + Implementation Notes: + + Initiator with the Cookie option and no segment data is + permitted in a test environment. This combination SHOULD be + silently discarded. + + Initiator with both the Cookie option and segment data + is similar to T/TCP [RFC1644]. However, whenever the Responder + has been sent with data (there is no further + data expected), TCB state has not been saved at the Responder. + There is no need to send to close the connection. + +6.2. Responder Data + + By default, the Responder does not contain data. The + application sets the TCP_SYN_ACK_DATA_LIMIT to indicate that the + MAY be sent with data. + + Segment data is limited to the Maximum Transmission Unit (MTU). + Applications MAY specify a shorter limit to prevent spoofed + amplification and reflection attacks [RFC5358]. + + Upon receipt of the with a Cookie option, the Responder MAY + process any data present. If the initial data is not accepted, the + Acknowledgment Number will be the received Sequence Number plus one + (1) for the . + + If the segment data is the entire response (there is no further data + expected), MAY be set. + + + + + + +Simpson Experimental [Page 22] + +RFC 6013 TCP Cookie Transactions January 2011 + + + However, SHOULD NOT be set. Although the application might use + push to indicate that its data is ready to send, the push is implied + for data segments (see [RFC793] section 3.7, page 41). + + As the Responder retains no TCB state, retransmission timers are not + available. Arrival of an Initiator's retransmission appears to be an + original transmission. There are no differences in processing. + + Implementation Notes: + + The Responder Cookie depends on the TCP Sequence and + Acknowledgment Numbers after processing . Therefore, neither + will include data. + +6.3. Initiator Data + + Upon receipt of the with a Cookie option, 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 (there is no further data + expected), the Initiator enters TIME-WAIT state. + + Otherwise, original data is retransmitted in , as its + processing is optional. The Acknowledgment Number will be the + received Sequence Number plus one (1) for the . The Sequence + Number will be the Initial Sequence Number (ISN) plus one (1) for the + . + + Unlike T/TCP [RFC1644], there is no implicit acknowledgment. + + If the Selective Acknowledgment (Sack) option [RFC2018] has been + successfully negotiated, a short Sack acknowledging the response data + MAY be sent following the Cookie-Pair in the extended header. + + At this time, any second segment may be sent without awaiting an + , according to the usual [RFC5681] TCP congestion control + process. + + Implementation Notes: + + Upon arrival of more data prompting a new Cookie exchange, there + is no need to increment the previous timestamp; TCB state has not + been saved at the Responder. Instead, use the saved RCV.NXT, plus + one (1) for the (actual or implied) . + + + + + + +Simpson Experimental [Page 23] + +RFC 6013 TCP Cookie Transactions January 2011 + + + Initiator with the Cookie-Pair option and no + segment data is never required; TCB state has not been saved at + the Responder. This combination MUST be silently discarded. + +6.4. Responder Data + + Upon receipt of the with a Cookie-Pair option (and + verification of the Timestamps and Cookie-Pair options), the + Responder SHOULD process any data present. + + Since the TCP Sequence and Acknowledgment Numbers have not advanced, + the Responder will process the same incoming data, and transmit the + same response. + + If the Selective Acknowledgment (Sack) option [RFC2018] has been + successfully negotiated, with a short Sack covering earlier response + data, only additional unacknowledged response data is sent. + + At this time, any second segment may be sent without awaiting an + , according to the usual [RFC5681] TCP congestion control + process. + +7. Advisory Reset + + When a TCB with matching Addresses and Ports is found, but the + Cookie-Pair fails to verify, the datagram MUST be silently discarded. + + When no TCB with matching Addresses and Ports is found, a 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 is always treated as advisory. A 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 inhibits third parties from disrupting communications. + +8. Interactions with Other Options + + A successful Cookie (or Cookie-less) option exchange signals + availability of the TCP header extension. Other options with large + data portions MAY also use this feature. The extended option data is + processed in the order that the options appear. + + + + + +Simpson Experimental [Page 24] + +RFC 6013 TCP Cookie Transactions January 2011 + + +8.1. TCP Selective Acknowledgment + + (Kind 5 [RFC2018].) The pairs of 32-bit fields are well suited to + the header extension. Because of its variable size, this is + RECOMMENDED as the final extended option. + + During the cookie exchange, the 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, and + MUST be ignored on receipt. + +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 . 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 . 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. + + + + + +Simpson Experimental [Page 25] + +RFC 6013 TCP Cookie Transactions January 2011 + + +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]. + + + + + +Simpson Experimental [Page 26] + +RFC 6013 TCP Cookie Transactions January 2011 + + + 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 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. + + + + + + + + + + +Simpson Experimental [Page 27] + +RFC 6013 TCP Cookie Transactions January 2011 + + +12. Operational Considerations + + Any implementation of this specification SHOULD be configurable, + separately for each port or connection. + + TCPCT_COOKIE_DESIRED + Values: 0 (disabled), 8, 10, 12, 14, 16. Default: 16. Send the + Cookie option with the . + + 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 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 . Wait for data before sending. + + TCP_SYN_ACK_DATA_LIMIT + Default: 0. Maximum: 1220. The maximum amount of data + transmitted with the . Wait 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. + + + + + + + +Simpson Experimental [Page 28] + +RFC 6013 TCP Cookie Transactions January 2011 + + + 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 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Simpson Experimental [Page 29] + +RFC 6013 TCP Cookie Transactions January 2011 + + +Appendix A. Example Headers + +A.1. Example + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 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 fits with the other recommended + options in the maximal 60 byte TCP header (40 bytes of option space). + + 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. + + The UserTimeOut (UTO) option can appear in other locations instead, + such as following the Cookie option. Because some middleboxes are + sensitive to the order of options, UTO should not appear before MSS + nor between the TS and Cookie. + + + + + + + + + + + + + + +Simpson Experimental [Page 30] + +RFC 6013 TCP Cookie Transactions January 2011 + + +A.2. Example with Sack + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 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. + + + + + + + + + + + + +Simpson Experimental [Page 31] + +RFC 6013 TCP Cookie Transactions January 2011 + + +A.3. Example with 64-bit Timestamps + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 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. + + + + + + + + + + + + +Simpson Experimental [Page 32] + +RFC 6013 TCP Cookie Transactions January 2011 + + +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. + + + + + + + + + + + + + + +Simpson Experimental [Page 33] + +RFC 6013 TCP Cookie Transactions January 2011 + + +Informative References + + [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 + + + + + + +Simpson Experimental [Page 34] + +RFC 6013 TCP Cookie Transactions January 2011 + + + [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. + + + + +Simpson Experimental [Page 35] + +RFC 6013 TCP Cookie Transactions January 2011 + + + [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. + + + + +Simpson Experimental [Page 36] + +RFC 6013 TCP Cookie Transactions January 2011 + + + [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 + + + + + + + + + + + + + + + + + + + + + + + + + +Simpson Experimental [Page 37] + -- cgit v1.2.3