INTERNET-DRAFT W A Simpson DayDreamer Intended status: Experimental 4 July 2011 TCP Cookie Transactions (TCPCT) Rapid Restart draft-simpson-tcpct-rr-02 Abstract TCP Cookie Transactions (TCPCT) [RFC6013] 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 specification provides an optional rapid restart facility for persistent connections. 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 contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. 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 expires January 4, 2012 [Page i] DRAFT TCPCT Rapid Restart 4 July 2011 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." Applicability This specification is intended for network paths under the complete control of an operator, such as secure tunnels or intra-campus private links. Widely deployed security firewalls block the transmission of these additional data segments, and are outside the scope of this specification. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . 1 1.1 Terminology . . . . . . . . . . . . . . . . . . . 1 2. Protocol Overview . . . . . . . . . . . . . . . . . . . 1 2.1 Message Summary (Simplified) . . . . . . . . . . . 2 3. Protocol Details . . . . . . . . . . . . . . . . . . . . 4 3.1 Responder TCB Retention . . . . . . . . . . . . . 4 3.2 Initiator Data . . . . . . . . . . . . . . . 5 3.3 Responder Data . . . . . . . . . . 5 3.4 Initiator Data . . . . . . . . . . . . 6 3.5 Responder Data . . . . . . . . . . . . . . . 6 ACKNOWLEDGMENTS . . . . . . . . . . . . . . . . . . . . . . . . 7 IANA CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . . . 7 OPERATIONAL CONSIDERATIONS . . . . . . . . . . . . . . . . . . 7 SECURITY CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . 8 NORMATIVE REFERENCES . . . . . . . . . . . . . . . . . . . . . 9 INFORMATIVE REFERENCES . . . . . . . . . . . . . . . . . . . . 9 CONTACTS . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Simpson expires January 4, 2012 [Page ii] DRAFT TCPCT Rapid Restart 4 July 2011 1. Introduction TCP Cookie Transactions (TCPCT) [RFC6013] provide a cryptologically secure mechanism to guard against simple flooding attacks sent with bogus IP [RFC791] Sources or TCP [RFC793] Ports. Also, implementations may optionally exchange limited amounts of transaction data during the initial cookie exchange, reducing network latency and host task context switching. This optional facility allows additional data segments for second and subsequent cookie transactions, immediately following the Responder's and prior to receipt of the Initiator's . The amount of data is limited by both the Initiator's advertised window (rwnd), and the Responder's vestigial congestion window (VCW) calculated by timestamps retained from the previous connection. Where repeated transactions are initiated within 1/2 the Round Trip Time (RTT), assuming symmetrical paths, the entire congestion window (cwnd) remains open. Most efficacious for persistent connections over long-delay paths. 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 This optional facility consist of several simple phases following the initial TCPCT connection. (See [RFC6013] Protocol Overview for previous steps.) 3. During close (or reset) of the TCP connection, the Timestamps and Cookie-Pair options guard the exchange. If the Responder (server) application has set the TCPCT_RETAIN flag prior to the close (or reset) of the connection, the Responder retains its Transport Control Block (TCB) [RFC793] for a limited time. Simpson expires January 4, 2012 [Page 1] DRAFT TCPCT Rapid Restart 4 July 2011 4. If the Initiator (client) application has set the TCPCT_RETAIN flag, rather than expunging the TCB after TIME-WAIT, the implementation retains its TCB indefinitely. When a retained TCB exists, the Responder MAY send additional data segments. 5. The Initiator sends its with Timestamps Extended Option and Cookie-Pair, optionally with Selective Acknowledgment (Sack) [RFC2018] to acknowledge any data. However, the Initiator does not acknowledge any additional data segments until receipt of the corresponding Responder (or ) with Timestamps Extended Option and Cookie-Pair. 6. Connection closes as described in 3. Repeat process for each reconnection. The sequence of messages is summarized in the diagram below. 2.1. Message Summary (Simplified) Initiator Responder ========= ========= TIME-WAIT (TCB state retained) -> base options Timestamps Cookie [request data] <- base options Timestamps Cookie [response data] <- Timestamps data Simpson expires January 4, 2012 [Page 2] DRAFT TCPCT Rapid Restart 4 July 2011 -> full options Timestamps Cookie-Pair [Sack(response)] <- full options Timestamps Cookie-Pair data (TCB state retained) -> base options Timestamps Cookie [request data] <- base options Timestamps Cookie [response data] <- Timestamps data -> full options Timestamps Cookie-Pair [Sack(response)] data <- full options Timestamps Cookie-Pair data Simpson expires January 4, 2012 [Page 3] DRAFT TCPCT Rapid Restart 4 July 2011 -> Timestamps Cookie-Pair data <- Timestamps Cookie-Pair (TCB state retained) TIME-WAIT The upper transaction illustrates a single segment accelerated open, rapid restart, accelerated Initiator close, and advisory . The lower transaction illustrates a multiple segment accelerated open, rapid restart, and normal Responder close. 3. Protocol Details Support for rapid restart is OPTIONAL, and depends upon support for [RFC6013] Accelerated Open. If the symbol TCPCT_RETAIN is defined in the system headers provided at the time of compilation, the implementation supports rapid restart. Although the Initiator is expected to reuse the same TCP Source Port, intervening middleboxes [RFC3234] are likely to expire any [RFC3022] port translations during the time between connections. Instead, the IP Source, Initiator Cookie, and Timestamps Echo Reply fields are checked against the retained TCB of prior connections. 3.1. Responder TCB Retention By default, upon receipt of the Initiator (and verification of the Timestamps and Cookie-Pair options), the Responder removes its TCB. If the Responder (server) application has set the TCPCT_RETAIN flag, the Responder calculates the retention time. This time is based on the anticipated reduction of the congestion window during a short idle period. For purposes of these calculations, the implementation SHOULD reduce its congestion window by half for every Round Trip Time (RTT) that the flow has remained idle. [RFC2861] Where repeated transactions are initiated within 1/2 the Round Trip Time (RTT), assuming symmetrical paths, the entire congestion window (cwnd) remains open. Simpson expires January 4, 2012 [Page 4] DRAFT TCPCT Rapid Restart 4 July 2011 This approach yields advantage for even a vestigial congestion window (VCW) less than the [RFC5681] Initial Window (IW). Unlike the [RFC5681] Restart Window (RW), VCW is not subject to the retransmission timeout (RTO). When VCW is less than or equal to TCP_SYN_ACK_DATA_LIMIT (or the local value in TCPCT_S_DATA_DESIRED) plus Maximum Segment Size (MSS), as limited by the retained Path Maximum Transmission Unit (PMTU), rapid restart offers no improvement over accelerated open. At that time, the Responder removes its TCB. 3.2. Initiator Data By default, the Initiator does not contain data. The application sets TCPCT_S_DATA_DESIRED to indicate that the MAY be sent with data. The Initiator uses the existing Initiator Cookie and fills the Timestamps Echo Reply field with the least significant 32 bits of the most recent Responder Timestamps Value. Any existing TSoffset MUST be incremented. During the rapid restart exchange, the Initiator is solely responsible for retransmission. 3.3. Responder Data By default, the Responder does not contain data. The application sets TCPCT_S_DATA_DESIRED to indicate that the MAY be sent with data. 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 . When a retained TCB exists, the Responder compares the IP Source, Initiator Cookie, and Timestamps Echo Reply. If the corresponding fields exactly match the most recent values, the Responder MAY send additional data segments. This segment data is limited to the retained Path Maximum Transmission Unit (PMTU). The Responder updates the TCB Source Port, and recalculates its Timestamps Value. Any existing TSoffset MUST be incremented. The same Timestamps fields are used for all data segments. As the Timestamps Extended Option has not been received, the standard Simpson expires January 4, 2012 [Page 5] DRAFT TCPCT Rapid Restart 4 July 2011 [RFC1323] (32-bit) Timestamps option is sent. If the segment data is the entire response (there is no further data expected), the Responder MUST NOT send the final segment and MUST NOT be set. Although the Responder retains TCB state, retransmission timers are not used. Arrival of an Initiator's retransmission appears to be an original transmission. As the Responder's Timestamps Value has been recalculated, these subsequent connection attempts MUST NOT trigger rapid restart. This will inhibit self-inflicted Denial of Service (DoS), and prevent spoofed amplification and reflection attacks [RFC5358]. 3.4. Initiator Data Upon receipt of the with a Cookie option, the Initiator MUST process any data present. In this case, the internal RCV.NXT is advanced to provide at-most-once semantics. If the Selective Acknowledgment (Sack) option [RFC2018] has been successfully negotiated, a short Sack acknowledging the response data MUST be sent following the Cookie-Pair in the extended header. At this time, additional segments MAY be sent, according to the usual [RFC5681] TCP congestion control process. However, the Initiator MUST NOT acknowledge any additional data segments, until receipt of the corresponding Responder (or ) with Timestamps Extended Option and Cookie-Pair. Upon retransmission of the , any Sack SHOULD include the accumulated unacknowledged bytes. 3.5. 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 generate the same response. If VCW is less than IW, reset cwnd to IW. Then, increase cwnd by the number (L) of previously unacknowledged bytes indicated by any Simpson expires January 4, 2012 [Page 6] DRAFT TCPCT Rapid Restart 4 July 2011 incoming Sack (similar to [RFC3465]). cwnd = max( IW, VCW ) + L At this time, additional segments MAY be sent, according to the usual [RFC5681] TCP congestion control process. Acknowledgments Yuchung Cheng, H. K. Jerry Chu, Sivasankar Radhakrishnan, and Arvind Jain described exchanging a token for "fast open" on subsequent connections. [CCRJ2011] That feature was subsumed by this specification. Many thanks to Mark Allman, Wesley Eddy, Richard Scheffenegger, and Paul Vixie for helpful comments. IANA Considerations This document has no IANA actions. [RFC Editor: please remove this section prior to publication.] Operational Considerations Any implementation of this specification SHOULD be configurable, separately for each port or connection. TCPCT_RETAIN When this symbol is defined in the system headers provided at the time of compilation, the optional TCPCT Rapid Restart feature is available. Default: 0 (off). Indicates TCPCT TCB SHOULD be retained for rapid restart. TCPCT_S_DATA_DESIRED Default: 0. The maximum amount of data transmitted with the (up to TCP_SYN_DATA_LIMIT) or the (up to TCP_SYN_ACK_DATA_LIMIT). Whenever this field is non-zero, wait for data before sending. Unlike TCPCT_COOKIE_DESIRED, this field MUST be set explicitly; there is no system value. Simpson expires January 4, 2012 [Page 7] DRAFT TCPCT Rapid Restart 4 July 2011 Security Considerations TCPCT was based on currently available tools, by experienced network protocol designers with an interest in cryptography, rather than by cryptographers with an interest in network protocols. This specification is intended to be readily implementable without requiring an extensive background in cryptology. Therefore, only minimal background cryptologic discussion and rationale is included in this document. Although some review has been provided by the general cryptologic community, it is anticipated that design decisions and tradeoffs will be thoroughly analysed in subsequent dissertations and debated for many years to come. Cryptologic details are reserved for separate documents that may be more readily and timely updated with new analysis. The security depends on the quality of the random numbers generated by each party. Generating cryptographic quality random numbers on a general purpose computer without hardware assistance is a very tricky problem (see [RFC4086] for discussion). TCPCT is not intended to prevent or recover from all possible security threats. Rather, it is designed to inhibit inadvertent middlebox interference, while protecting against Denial of Service (DoS) attacks. (See [RFC4732], and [RFC3552] section 4.6.3 et seq.) The cookie exchange does not protect against an interloper that can race to substitute another value, nor an interceptor that can modify and/or replace a value. These attacks are considerably more difficult than passive vacuum-cleaner monitoring. The initial exchange is most fragile, as protection against spoofing relies entirely upon the sequence and timestamp. Instead, the IP Source, Initiator Cookie, and Timestamps Echo Reply fields are checked against the retained TCB of prior connections. This is considerably stronger than the initial exchange; in effect, a partial extension of the three-way handshake closing the prior connection. Simpson expires January 4, 2012 [Page 8] DRAFT TCPCT Rapid Restart 4 July 2011 Normative References [RFC791] Postel, J., "Internet Protocol", STD 5, September 1981. [RFC793] Postel, J., "Transmission Control Protocol", STD 7, September 1981. [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", May 1992. [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, March 1997. [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", September 2009. [RFC6013] Simpson, W. A., "TCP Cookie Transactions (TCPCT)", January 2011. Informative References [CCRJ2011] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", work in progress, March 7, 2011. http://tools.ietf.org/html/draft-cheng-tcpm-fastopen [RFC2861] Handley, M., Padhye, J., and S. Floyd, "TCP Congestion Window Validation", June 2000. [RFC3022] Srisuresh, P., and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", January 2001. [RFC3234] Carpenter, B., and S. Brim, "Middleboxes: Taxonomy and Issues", February 2002. [RFC3465] Allman, M., "TCP Congestion Control with Appropriate Byte Counting (ABC)", February 2003. [RFC3552] Rescorla, E., and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, July 2003. [RFC4086] Eastlake, D. (3rd), Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, June 2005. Simpson expires January 4, 2012 [Page 9] DRAFT TCPCT Rapid Restart 4 July 2011 [RFC4732] Handley, M., Ed., and Rescorla, E., Ed., and Internet Architecture Board, "Internet Denial-of-Service Considerations", November 2006. [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", August 2007. [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", January 2008. [RFC5358] Damas, J., and F. Neves, "Preventing Use of Recursive Nameservers in Reflector Attacks", BCP 140, October 2008. 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 January 4, 2012 [Page 10]