[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

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 <SYN> Data . . . . . . . . . . . . . . .   5
        3.3       Responder <SYN,ACK(SYN)> Data  . . . . . . . . . .   5
        3.4       Initiator <ACK(SYN)> Data  . . . . . . . . . . . .   6
        3.5       Responder <ACK> 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
   <SYN,ACK(SYN)> and prior to receipt of the Initiator's <ACK(SYN)>.
   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 <ACK(SYN)> with Timestamps Extended Option
      and Cookie-Pair, optionally with Selective Acknowledgment (Sack)
      [RFC2018] to acknowledge any <SYN,ACK(SYN)> data.

      However, the Initiator does not acknowledge any additional data
      segments until receipt of the corresponding Responder <ACK> (or
      <FIN,ACK>) 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)

   <SYN>                          ->
   base options
   Timestamps
   Cookie
   [request data]
                                   <-   <SYN,ACK(SYN)>
                                        base options
                                        Timestamps
                                        Cookie
                                        [response data]
                                   <-   <ACK>
                                        Timestamps
                                        data










Simpson                  expires January 4, 2012                [Page 2]

DRAFT                      TCPCT Rapid Restart               4 July 2011


   <FIN,ACK(SYN)>                 ->
   full options
   Timestamps
   Cookie-Pair
   [Sack(response)]
                                   <-   <FIN,ACK(FIN)>
                                        full options
                                        Timestamps
                                        Cookie-Pair
                                        data
                                        (TCB state retained)


   <SYN>                          ->
   base options
   Timestamps
   Cookie
   [request data]
                                   <-   <SYN,ACK(SYN)>
                                        base options
                                        Timestamps
                                        Cookie
                                        [response data]
                                   <-   <ACK>
                                        Timestamps
                                        data


   <ACK(SYN)>                     ->
   full options
   Timestamps
   Cookie-Pair
   [Sack(response)]
   data
                                   <-   <FIN,ACK>
                                        full options
                                        Timestamps
                                        Cookie-Pair
                                        data












Simpson                  expires January 4, 2012                [Page 3]

DRAFT                      TCPCT Rapid Restart               4 July 2011


   <FIN,ACK(FIN)>                 ->
   Timestamps
   Cookie-Pair
   data
                                   <-   <ACK(FIN)>
                                        Timestamps
                                        Cookie-Pair
                                        (TCB state retained)
   TIME-WAIT

   The upper transaction illustrates a single segment accelerated open,
   rapid restart, accelerated Initiator close, and advisory <FIN>.

   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 <ACK(FIN)> (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 <SYN> Data

   By default, the Initiator <SYN> does not contain data.  The
   application sets TCPCT_S_DATA_DESIRED to indicate that the <SYN> 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 <SYN,ACK(SYN)> Data

   By default, the Responder <SYN,ACK(SYN)> does not contain data.  The
   application sets TCPCT_S_DATA_DESIRED to indicate that the
   <SYN,ACK(SYN)> MAY be sent with data.

   Upon receipt of the <SYN> 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 <SYN>.

   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 <FIN>
   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 <SYN> 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 <ACK(SYN)> Data

   Upon receipt of the <SYN,ACK(SYN)> 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 <ACK> (or
   <FIN,ACK>) with Timestamps Extended Option and Cookie-Pair.  Upon
   retransmission of the <ACK(SYN)>, any Sack SHOULD include the
   accumulated unacknowledged bytes.


3.5.  Responder <ACK> Data

   Upon receipt of the <ACK(SYN)> 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 <SYN>
      (up to TCP_SYN_DATA_LIMIT) or the <SYN,ACK(SYN)> (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]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/