INTERNET-DRAFT W A Simpson DayDreamer Intended status: Experimental June 2010 TCP Cookie Transactions (TCPCT) draft-simpson-tcpct-03 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. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) 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. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Simpson expires December 25, 2010 [Page i] DRAFT TCP Cookie Transactions June 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . 1 1.1 Terminology . . . . . . . . . . . . . . . . . . . 1 2. Protocol Overview . . . . . . . . . . . . . . . . . . . 2 2.1 Message Summary (simplified) . . . . . . . . . . . 3 2.2 Compatibility and Transparency . . . . . . . . . . 4 2.3 Fully Loaded Cookies . . . . . . . . . . . . . . . 4 2.4 TCP Header Extension . . . . . . . . . . . . . . . 5 2.5 Option Handling . . . . . . . . . . . . . . 6 3. Protocol Details . . . . . . . . . . . . . . . . . . . . 6 3.1 TCP Cookie Option . . . . . . . . . . . . . . . . 7 3.2 TCP Cookie-Pair Standard Option . . . . . . . . . 7 3.3 TCP Cookie-less Option . . . . . . . . . . . . . . 8 3.4 TCP Timestamps Extended Option . . . . . . . . . . 9 3.5 Cookie Generation . . . . . . . . . . . . . . . . 10 3.5.1 Initiator Cookie . . . . . . . . . . . . . . . . . 11 3.5.2 Responder Cookie . . . . . . . . . . . . . . . . . 11 3.5.3 Responder Secret Value . . . . . . . . . . . . . . 13 4. Cookie Exchange . . . . . . . . . . . . . . . . . . . . 14 4.1 Initiator . . . . . . . . . . . . . . . . . 14 4.2 Responder . . . . . . . . . . . . . 14 4.3 Initiator . . . . . . . . . . . . . . . 15 4.4 Responder . . . . . . . . . . . . . . . . . 16 4.5 Simultaneous Open . . . . . . . . . . . . . . . . 16 5. Accelerated Close . . . . . . . . . . . . . . . . . . . 17 5.1 Initiator Close . . . . . . . . . . . . . . . . . 18 5.2 Responder Close . . . . . . . . . . . . . . . . . 18 6. Accelerated Open . . . . . . . . . . . . . . . . . . . . 19 6.1 Initiator Data . . . . . . . . . . . . . . . 19 6.2 Responder Data . . . . . . . . . . 20 6.3 Initiator Data . . . . . . . . . . . . 21 6.4 Responder Data . . . . . . . . . . . . . . . 21 7. Advisory Reset . . . . . . . . . . . . . . . . . . . . . 22 8. Interactions with other options . . . . . . . . . . . . 22 8.1 TCP Selective Acknowledgment . . . . . . . . . . . 22 8.2 TCP Timestamps . . . . . . . . . . . . . . . . . . 23 8.3 TCP Extensions for Transactions . . . . . . . . . 23 8.4 TCP MD5 Signature . . . . . . . . . . . . . . . . 23 8.5 TCP Authentication . . . . . . . . . . . . . . . . 23 HISTORY . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 ACKNOWLEDGMENTS . . . . . . . . . . . . . . . . . . . . . . . . 25 IESG CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . . . 25 OPERATIONAL CONSIDERATIONS . . . . . . . . . . . . . . . . . . 26 SECURITY CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . 26 APPENDICES . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Simpson expires December 25, 2010 [Page ii] DRAFT TCP Cookie Transactions June 2010 A. Example headers . . . . . . . . . . . . . . . . . . . . 28 A.1 Example options . . . . . . . . . . . . . . 28 A.2 Example with Sack . . . . . . . . . . . 29 A.3 Example with 64-bit Timestamps . . . . 30 NORMATIVE REFERENCES . . . . . . . . . . . . . . . . . . . . . 31 INFORMATIVE REFERENCES . . . . . . . . . . . . . . . . . . . . 32 CONTACTS . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Simpson expires December 25, 2010 [Page iii] DRAFT TCP Cookie Transactions June 2010 1. Introduction TCP Cookie Transactions (TCPCT) provide a cryptologically secure mechanism to guard against simple flooding attacks sent with bogus IP [RFC 791] Sources or TCP [RFC 793] Ports. The initial TCP exchange is vulnerable to forged IP Addresses, predictable Ports, and discoverable Sequence Numbers [Morris1985] [Gont2009]. 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 is detailed in [MSV2009]. 1.1. Terminology The key words "MAY", "MUST, "MUST NOT", "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be interpreted as described in [RFC 2119]. byte An 8-bit quantity; also known as "octet" in standardese. Simpson expires December 25, 2010 [Page 1] DRAFT TCP Cookie Transactions June 2010 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. 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 TCB. Note that the Responder returns the Cookie-Pair with its initial data, but subsequent data segments need only the Timestamps. 3. During closing (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 are summarized in the diagram below. Simpson expires December 25, 2010 [Page 2] DRAFT TCP Cookie Transactions June 2010 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 expires December 25, 2010 [Page 3] DRAFT TCP Cookie Transactions June 2010 2.2. Compatibility and Transparency It is usually better that data arrive slowly, than not at all. Many/most unmanaged middleboxes [RFC 3234] (such as stateless firewalls, load balancers, intrusion detection systems, or network address translators [RFC 3022]) cannot carry transport traffic other than TCP and UDP. Every TCP implementation MUST ignore without error any TCP option it does not implement ([RFC 1122] 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 [RFC 793] "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 [rfc1323bis] and its antecedants). 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 in a backward compatible manner. Semantics for the option have been "overloaded" with a baker's dozen 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. Simpson expires December 25, 2010 [Page 4] DRAFT TCP Cookie Transactions June 2010 C. Cookie values allow applications to 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 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 expires December 25, 2010 [Page 5] DRAFT TCP Cookie Transactions June 2010 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 [RFC 793] 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 [RFC 5452] describes use of an unpredictable Source Port. That is RECOMMENDED by this specification. See [LG2010] for further information. An earlier solution [RFC 1948] describes an unpredictable Initial Sequence Number (ISN). That is REQUIRED by this specification. Support for the (32-bit) TCP Timestamps Option [rfc1323bis] is REQUIRED. The TSoffset SHOULD be generated on a per-connection | basis. [GO2010] The Don't Fragment (DF) bit MUST be set in the IP | (v4) header. The TCP User Timeout Option [RFC 5482] 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 expires December 25, 2010 [Page 6] DRAFT TCP Cookie Transactions June 2010 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). | Simpson expires December 25, 2010 [Page 7] DRAFT TCP Cookie Transactions June 2010 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 . 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. 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. Simpson expires December 25, 2010 [Page 8] DRAFT TCP Cookie Transactions June 2010 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. 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 Simpson expires December 25, 2010 [Page 9] DRAFT TCP Cookie Transactions June 2010 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. | 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. Simpson expires December 25, 2010 [Page 10] DRAFT TCP Cookie Transactions June 2010 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 on a per TCB basis. 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. 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 Simpson expires December 25, 2010 [Page 11] DRAFT TCP Cookie Transactions June 2010 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 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. Simpson expires December 25, 2010 [Page 12] DRAFT TCP Cookie Transactions June 2010 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 round trip time (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 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). Simpson expires December 25, 2010 [Page 13] DRAFT TCP Cookie Transactions June 2010 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. 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 round trip time (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 [RFC 1948]. Simpson expires December 25, 2010 [Page 14] DRAFT TCP Cookie Transactions June 2010 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 round trip time (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. 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 round trip time 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. Simpson expires December 25, 2010 [Page 15] DRAFT TCP Cookie Transactions June 2010 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 [RFC 793, section 3.4, and Figure 8]. Each party receives a Cookie for a connection that has also issued a Cookie. This condition will be unusual. The Source Port SHOULD be randomized [RFC 5452], 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 [RFC 3232]. 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. Simpson expires December 25, 2010 [Page 16] DRAFT TCP Cookie Transactions June 2010 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. Rapidly closing the connection expedites removing Responder state. Any bearing segment SHOULD terminate delayed [RFC 5681]. Retransmit at the latest Timestamps estimated smoothed round trip time (SRTT). Backoff SHOULD NOT be used for bearing retransmissions [RFC 2988]. As the Responder retains no TCB state after closing, a successful | option exchange signals the Initiator will be responsible for handling TIME-WAIT state. (See [FTY1999, section 3] for previous proposal and rationale.) A new Cookie exchange MAY be initiated at any time. This facilitates | persistent connections through intervening network equipment. Simpson expires December 25, 2010 [Page 17] DRAFT TCP Cookie Transactions June 2010 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 not send a final , and/or SHOULD NOT wait the remaining TIME-WAIT interval. The 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. 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 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 final (and verification of the Timestamps and Cookie-Pair options), the Initiator enters TIME- WAIT state. Simpson expires December 25, 2010 [Page 18] DRAFT TCP Cookie Transactions June 2010 Upon arrival of more data prompting a new Cookie exchange, the Initiator SHOULD NOT not send a , and/or SHOULD NOT wait the remaining TIME-WAIT interval. The 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 on a per port basis. 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 ([RFC 1122] 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. 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 [RFC 1644], 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, | Simpson expires December 25, 2010 [Page 19] DRAFT TCP Cookie Transactions June 2010 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 [RFC 1644]. 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 [RFC 5358]. 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. 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 [RFC 793, 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. Simpson expires December 25, 2010 [Page 20] DRAFT TCP Cookie Transactions June 2010 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 [RFC 1644], there is no implicit acknowledgment. If the Selective Acknowledgment (Sack) option [RFC 2018] 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 [RFC 5681] 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) . 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 [RFC 2018] has been Simpson expires December 25, 2010 [Page 21] DRAFT TCP Cookie Transactions June 2010 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 [RFC 5681] 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 [rfc1323bis]. 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 [RFC 5482] 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. 8.1. TCP Selective Acknowledgment (Kind 5 [RFC 2018].) 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. Simpson expires December 25, 2010 [Page 22] DRAFT TCP Cookie Transactions June 2010 8.2. TCP Timestamps (Kind 8 [rfc1323bis].) 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 [RFC 1644].) Incompatible with this specification, and MUST be ignored on receipt. 8.4. TCP MD5 Signature (Kind 19 [RFC 2385].) 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 [RFC 5925].) 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 expires December 25, 2010 [Page 23] DRAFT TCP Cookie Transactions June 2010 History + T/TCP [RFC 1379] [RFC 1644] permits lightweight TCP transactions for applications that traditionally have used UDP. However, T/TCP has unacceptable security issues [Hannan1996] [Phrack1998]. The initial specification [KS1995] of Photuris [RFC 2522], 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. 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 [RFC 4987]. 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) [RFC 2960] was published with an inadequate partial cookie mechanism claiming to be based upon Photuris. It featured a deficient checksum (replaced in 2002 by [RFC 3309] without graceful transition), and has undergone subsequent revisions [RFC 4960]. In 2006, the Datagram Congestion Control Protocol (DCCP) [RFC 4340] Simpson expires December 25, 2010 [Page 24] DRAFT TCP Cookie Transactions June 2010 was published with a mechanism analogous to SYN cookies. Acknowledgments Andre Broido informally described utilizing cookies for Transport | Layer Security (TLS) session identifiers, in place of the [RFC 4507] | 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. 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 expires December 25, 2010 [Page 25] DRAFT TCP Cookie Transactions June 2010 Operational Considerations Any implementation of this specification SHOULD be configurable. TCP_COOKIE_DESIRED Values: 0 (disabled), 8, 10, 12, 14, 16 Default: 16 (testing: 0). Send the Cookie option with the on a per port basis. TCP_COOKIE_IN_ALWAYS Default: off. Silently discard any incoming that is missing the Cookie option on a per port basis. TCP_COOKIE_OUT_NEVER Default: off. Refuse to send (override) the Cookie option on a per port basis. TCP_EXTEND_TIMESTAMP Default: off. If defined, may send 64-bit (or future 128-bit) timestamps extension. TCP_SYN_DATA_LIMIT Default: 0. Maximum: 496. The maximum amount of data transmitted with the on a per port basis. Wait for data before sending. TCP_SYN_ACK_DATA_LIMIT Default: 0. Maximum: 1220. The maximum amount of data transmitted with the on a per port basis. Wait for data before sending. 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 Simpson expires December 25, 2010 [Page 26] DRAFT TCP Cookie Transactions June 2010 general purpose computer without hardware assistance is a very tricky problem (see [RFC 4086] 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 [RFC 4732] and [RFC 3552] 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 expires December 25, 2010 [Page 27] DRAFT TCP Cookie Transactions June 2010 A. Example headers | A.1. Example options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 Cookie (112-bits) 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 expires December 25, 2010 [Page 28] DRAFT TCP Cookie Transactions June 2010 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 expires December 25, 2010 [Page 29] DRAFT TCP Cookie Transactions June 2010 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 expires December 25, 2010 [Page 30] DRAFT TCP Cookie Transactions June 2010 Normative References [RFC 791] Postel, J., "Internet Protocol - DARPA Internet Program Protocol Specification", STD 5, September 1981. [RFC 793] Postel, J., "Transmission Control Protocol - DARPA Internet Program Protocol Specification", STD 7, September 1981. [RFC 1122] Braden, R., Ed., "Requirements for Internet Hosts -- Communication Layers", STD 3, October 1989. [RFC 1948] S. Bellovin, "Defending Against Sequence Number Attacks", May 1996. [RFC 2018] Mathis, M., Mahdavi, J., Floyd, S., and Romanow, A., "TCP Selective Acknowledgment Options", October 1996. [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, March 1997. [RFC 2988] Paxson, V., and Allman, M., "Computing TCP's Retransmission Timer", November 2000. [RFC 3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", January 2002. http://www.iana.org/assignments/port-numbers [RFC 5452] A. Hubert, R. van Mook, "Measures for Making DNS More Resilient against Forged Answers", January 2009. [RFC 5482] Eggert, L., and Gont, F., "TCP User Timeout Option", March 2009. [RFC 5681] Allman, M., Paxson, V., and Blanton, E., "TCP Congestion Control", September 2009. [rfc1323bis] Jacobson, V., Braden, R., and Borman D., "TCP Extensions for High Performance", May 1992. Updating: work in progress, March 4, 2009. http://tools.ietf.org/html/draft-ietf-tcpm-1323bis Simpson expires December 25, 2010 [Page 31] DRAFT TCP Cookie Transactions June 2010 Informative References [EL2008] Eddy, W., and Langley, A., "Extending the Space Available for TCP Options", work in progress, July 1, 2008. [FTY1999] Faber, T., Touch, J., and Yue, W., "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 Oppermann, A., "On the generation of TCP + timestamps", work in progress, June 22, 2010. + http://tools.ietf.org/html/draft-gont-timestamps- + generation [Hannan1996] 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 Claffy, K. C., "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 Simpson, W., "The Photuris Session Key Management Protocol", March 1995. draft-karn- photuris-01.txt 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 5, 2008. [LG2010] Larson, M., and Gont, F., "Transport Protocol Port Randomization Recommendations", work in progress, February 15, 2010. http://tools.ietf.org/html/draft- ietf-tsvwg-port-randomization Simpson expires December 25, 2010 [Page 32] DRAFT TCP Cookie Transactions June 2010 [MAF2004] Medina, A., Allman, M., and Floyd, S., "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 Vixie, P., "Improving TCP Security With Robust Cookies", Usenix ;login:, December 2009. http://www.usenix.org/publications/login/ 2009-12/openpdfs/metzger.pdf [Phrack1998] route [at] infonexus [dot] com, "T/TCP vulnerabilities", Phrack Magazine, Volume 8, Issue 53, July 8, 1998. http://www.phrack.org/issues.html?issue=53&id=6 [RFC 1379] R. Braden, "Extending TCP for Transactions -- Concepts", November 1992. [RFC 1644] Braden, R., "T/TCP -- TCP Extensions for Transactions -- Functional Specification", July 1994. [RFC 2385] A. Heffernan, "Protection of BGP Sessions via the TCP MD5 Signature Option", August 1998. [RFC 2522] Karn, P., and Simpson, W., "Photuris: Session-Key Management Protocol", March 1999. [RFC 2827] Ferguson, P., and Senie, D., "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Simpson expires December 25, 2010 [Page 33] DRAFT TCP Cookie Transactions June 2010 Source Address Spoofing", BCP 38, May 2000. [RFC 2960] Stewart, R., et alia, "Stream Control Transmission Protocol", October 2000. [RFC 3022] Srisuresh, P., and Egevang, K., "Traditional IP Network Address Translator (Traditional NAT)", January 2001. [RFC 3234] Carpenter, B., and Brim, S., "Middleboxes: Taxonomy and Issues", February 2002. [RFC 3309] J. Stone, R. Stewart, D. Otis, "Stream Control Transmission Protocol (SCTP) Checksum", September 2002. [RFC 3552] Rescorla, E., and Korver, B., "Guidelines for Writing RFC Text on Security Considerations", BCP 72, July 2003. [RFC 3704] Baker, F., and Savola, P., "Ingress Filtering for Multihomed Networks", BCP 84, March 2004. [RFC 4086] Eastlake, D. (3rd), Schiller, J., and Crocker, S., "Randomness Requirements for Security", BCP 106, June 2005. [RFC 4340] Kohler, E., Handley, M., and Floyd, S., "Datagram Congestion Control Protocol (DCCP)", March 2006. + [RFC 4507] Salowey, J., Zhou, H., Eronen, P., and Tschofenig, H., + "Transport Layer Security (TLS) Session Resumption + without Server-Side State", May 2006. [RFC 4732] Handley, M., and Rescorla, E., Eds., "Internet Denial-of- Service Considerations", November 2006. [RFC 4953] Touch, J., "Defending TCP Against Spoofing Attacks", July 2007. [RFC 4960] R. Stewart, Ed., "Stream Control Transmission Protocol", September 2007. [RFC 4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", August 2007. [RFC 5358] Damas, J., and Neves, F., "Preventing Use of Recursive Nameservers in Reflector Attacks", BCP 140, October 2008. | [RFC 5925] Touch, J., Mankin, A., and Bonica, R., "The TCP Authentication Option", June 2010. | Simpson expires December 25, 2010 [Page 34] DRAFT TCP Cookie Transactions June 2010 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 William.Allen.Simpson@Gmail.com Simpson expires December 25, 2010 [Page 35]