Independent Submission W. Simpson Request for Comments: 6013 DayDreamer Category: Experimental January 2011 ISSN: 2070-1721 Independent Submission W. Simpson Request for Comments: 6013 DayDreamer Category: Experimental January 2011 ISSN: 2070-1721 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. 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. 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. 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 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 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].) Initiator Responder ========= ========= -> base options Timestamps Cookie [request data] <- base options Timestamps Cookie [response data] (stateless) Initiator Responder ========= ========= -> base options Timestamps Cookie [request data] <- base options Timestamps Cookie [response data] (stateless) 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." 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. 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). +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kind | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Cookie ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kind | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Cookie ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kind | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Initiator-Cookie ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Responder-Cookie ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kind | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Initiator-Cookie ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Responder-Cookie ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kind | Length | Extend | R | S | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | ~ TS Value ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ TS Echo Reply ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kind | Length | Extend | R | S | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | ~ TS Value ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ TS Echo Reply ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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. 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. 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. 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. 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. 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]. 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. 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. 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. 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. 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 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]. 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]. 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. 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. 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. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [Hannum1996] Hannum, C., "Security Problems Associated With T/TCP", unpublished work in progress, September 1996. http://www.mid-way.org/doc/ttcp-sec.txt [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 [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 [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 [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 [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 [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 [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 [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