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

Versions: 00 01 02 03 04 05 06 RFC 6013

INTERNET-DRAFT                                               W A Simpson
                                                              DayDreamer
Intended status: Experimental                              February 2010


                    TCP Cookie Transactions (TCPCT)
                         draft-simpson-tcpct-00


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 August 31, 2010                [Page i]

DRAFT                    TCP Cookie Transactions           February 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       <SYN> 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-Pair Extended Option  . . . . . . . . .   8
        3.4       TCP Cookie-less Extension Option . . . . . . . . .   9
        3.5       TCP Timestamps Extended Option . . . . . . . . . .  10
        3.6       Cookie Generation  . . . . . . . . . . . . . . . .  11
           3.6.1  Initiator Cookie . . . . . . . . . . . . . . . . .  12
           3.6.2  Responder Cookie . . . . . . . . . . . . . . . . .  12
           3.6.3  Responder Secret Value . . . . . . . . . . . . . .  13
     4.     Cookie Exchange  . . . . . . . . . . . . . . . . . . . .  14
        4.1       Initiator <SYN>  . . . . . . . . . . . . . . . . .  14
        4.2       Responder <SYN,ACK(SYN)> . . . . . . . . . . . . .  15
        4.3       Initiator <ACK(SYN)> . . . . . . . . . . . . . . .  16
        4.4       Responder <ACK>  . . . . . . . . . . . . . . . . .  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 <SYN> Data . . . . . . . . . . . . . . .  19
        6.2       Responder <SYN,ACK(SYN)> Data  . . . . . . . . . .  20
        6.3       Initiator <ACK(SYN)> Data  . . . . . . . . . . . .  21
        6.4       Responder <ACK> Data . . . . . . . . . . . . . . .  22
     7.     Advisory Reset . . . . . . . . . . . . . . . . . . . . .  22
     8.     Interactions with other options  . . . . . . . . . . . .  23
        8.1       TCP Selective Acknowledgment . . . . . . . . . . .  23
        8.2       TCP Timestamps . . . . . . . . . . . . . . . . . .  23
        8.3       TCP Extensions for Transactions  . . . . . . . . .  23
        8.4       TCP MD5 Signature  . . . . . . . . . . . . . . . .  23
        8.5       TCP Authentication . . . . . . . . . . . . . . . .  24
     HISTORY . . . . . . . . . . . . . . . . . . . . . . . . . . . .  24
     ACKNOWLEDGMENTS . . . . . . . . . . . . . . . . . . . . . . . .  25
     IANA CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . . .  26
     OPERATIONAL CONSIDERATIONS  . . . . . . . . . . . . . . . . . .  26
     SECURITY CONSIDERATIONS . . . . . . . . . . . . . . . . . . . .  27



Simpson                  expires August 31, 2010               [Page ii]

DRAFT                    TCP Cookie Transactions           February 2010


     APPENDICES  . . . . . . . . . . . . . . . . . . . . . . . . . .  28
     A.     Example headers  . . . . . . . . . . . . . . . . . . . .  28
        A.1       Example <SYN> header . . . . . . . . . . . . . . .  28
        A.2       Example <ACK(SYN)> with Sack . . . . . . . . . . .  29
        A.3       Example header with 64-bit Timestamps  . . . . . .  30
     NORMATIVE REFERENCES  . . . . . . . . . . . . . . . . . . . . .  31
     INFORMATIVE REFERENCES  . . . . . . . . . . . . . . . . . . . .  32
     CONTACTS  . . . . . . . . . . . . . . . . . . . . . . . . . . .  34











































Simpson                  expires August 31, 2010              [Page iii]

DRAFT                    TCP Cookie Transactions           February 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 <SYN>
   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].













Simpson                  expires August 31, 2010                [Page 1]

DRAFT                    TCP Cookie Transactions           February 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 <SYN> 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 <SYN> that were successfully
      returned in the <SYN,ACK(SYN)> MUST be included with the
      <ACK(SYN)>.  Additional options MAY also be included as desired.

      As there is no Responder state, it has no record of acknowledging
      previous data.  Any optional <SYN> 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 August 31, 2010                [Page 2]

DRAFT                    TCP Cookie Transactions           February 2010


2.1.  Message Summary (simplified)


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


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


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





Simpson                  expires August 31, 2010                [Page 3]

DRAFT                    TCP Cookie Transactions           February 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 <SYN,ACK(SYN)> segment only after the
   corresponding option was received in the original <SYN> 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 <SYN> options are copied to the
   <SYN,ACK(SYN)>.  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 August 31, 2010                [Page 4]

DRAFT                    TCP Cookie Transactions           February 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 outside the scope of this
      specification.

   E. The <SYN> and <SYN,ACK(SYN)> 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 outside 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 the 64-bit Timestamps extended option 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 <FIN> and <RST>.

   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 64-bit Timestamps extended option or the
   Cookie-Pair extended option MUST be used to indicate the presence of
   the header extension.

   Validation of these known values protects against data corruption by
   misbehaving middleboxes.





Simpson                  expires August 31, 2010                [Page 5]

DRAFT                    TCP Cookie Transactions           February 2010


2.5.  <SYN> Option Handling

   As the Responder retains no state after the initial TCP <SYN>
   exchange, all options present in the original <SYN> MUST be repeated.

   For example, an option defined in the [RFC 793] original
   specification -- Maximum Segment Size (MSS) -- previously appeared
   only in a <SYN> bearing segment (including <SYN,ACK(SYN)>).  If
   present, MSS will be repeated in the Initiator <ACK(SYN)>, 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 <SYN>.  The
   Responder acknowledges using a subsequent <ACK> segment containing
   both Timestamps and Cookie-Pair options (similar to <SYN,ACK(SYN)>
   processing).

   This facility allows previously SYN-only options to be updated from
   time to time.  They take effect upon receipt.

   However, <ACK> 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
   <FIN>), and an <ACK> 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 MUST be randomized on a per-connection basis.
   The Don't Fragment (DF) bit MUST be set in the IP header.

   The TCP User Timeout Option [RFC 5482] is RECOMMENDED.

   For examples, see Appendix A.








Simpson                  expires August 31, 2010                [Page 6]

DRAFT                    TCP Cookie Transactions           February 2010


3.1.  TCP Cookie Option

                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |      Kind     |    Length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                            Cookie                             ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Kind             1 byte.  31 (testing 253).

   Length           1 byte.  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.  31 (testing 253).





Simpson                  expires August 31, 2010                [Page 7]

DRAFT                    TCP Cookie Transactions           February 2010


   Length           1 byte.  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 <SYN>.

   Responder-Cookie 8 to 16 bytes, from the <SYN,ACK(SYN)>.

   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).

   Only one instance is permitted of either the Cookie or Cookie-Pair
   option(s).  Segments with duplicative or mutually exclusive options
   MUST be silently discarded.


3.3.  TCP Cookie-Pair Extended Option

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Kind     |    Length     |    Extend     | Zero  | Size  |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                                                               |
   ~                       Initiator-Cookie                        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                       Responder-Cookie                        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Kind             1 byte.  31 (testing 253).

   Length           1 byte.  4 (constant).  This distinguishes the
                    option from other Cookie options.

   Extend           1 byte.  4 to 255, the data offset (in 32-bit words)
                    following the standard TCP header.  Note the value
                    MUST be greater than or equal to Size.

   Zero             4 bits.  Reserved.  Must be zero.

   Size             4 bits.  4 to 8, the number of 32-bit words in the
                    cookie pair.



Simpson                  expires August 31, 2010                [Page 8]

DRAFT                    TCP Cookie Transactions           February 2010


   Initiator-Cookie 8 to 16 bytes, from the original <SYN>.

   Responder-Cookie 8 to 16 bytes, from the <SYN,ACK(SYN)>.

   The full cookie pair follows the TCP header (indicated by +=+
   delimiters) and maintains 32-bit alignment.

   This TCP header extension is ignored for sequence number
   computations.  The Sequence Number of the first byte of segment data
   will be the Initial Sequence Number (ISN) plus one (1) for the <SYN>.

   Segments with invalid Extend or Size values MUST be silently
   discarded.  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).

   Only one instance is permitted of either the Cookie or Cookie-Pair
   option(s).  Segments with duplicative or mutually exclusive options
   MUST be silently discarded.

   Implementation Notes:

      When the Timestamps extended option (below) is present, the
      Cookie-Pair standard option (above) is used instead.


3.4.  TCP Cookie-less Extension Option

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Kind     |    Length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Kind             1 byte.  31 (testing 253).

   Length           1 byte.  2 (constant).  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.









Simpson                  expires August 31, 2010                [Page 9]

DRAFT                    TCP Cookie Transactions           February 2010


3.5.  TCP Timestamps Extended Option

                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |      Kind     |    Length     |    Extend     |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                                                               |
   +                           TS Value                            +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                         TS Echo Reply                         +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Kind             1 byte.  32 (testing 254).

   Length           1 byte.  3 (constant).

   Extend           1 byte.  9 to 255, the data offset (in 32-bit words)
                    following the standard TCP header.  Note the value
                    MUST include the timestamp values, plus the
                    following Cookie-Pair standard option.

   TS Value         8 bytes.  The current value of the timestamp for the
                    sender.

   TS Echo Reply    8 bytes.  A copy of the most recently received TS
                    Value.

   The full timestamp pair follows the TCP header (indicated by +=+
   delimiters) and maintains 32-bit alignment.

   This TCP header extension is ignored for sequence number
   computations.  The Sequence Number of the first byte of segment data
   will be the Initial Sequence Number (ISN) plus one (1) for the <SYN>.

   Every TCPCT implementation MUST recognize a Timestamps extended
   option.  These 64-bit timestamps only appear in an extended option.

   As the Responder retains no state after the initial TCP <SYN>
   exchange, the Initiator sends either the regular or extended option
   -- chosen by a configurable parameter, or automatically based on its
   analysis of the bandwidth-delay product discovered through the round
   trip time of its <SYN> timestamp.  The Initiator adds a random 32-bit
   prefix to its own timestamp, and a random 32-bit prefix to the
   Responder timestamp echo reply, sending the Timestamps extended
   option followed by the Cookie-Pair standard option.



Simpson                  expires August 31, 2010               [Page 10]

DRAFT                    TCP Cookie Transactions           February 2010


   However, the Responder MAY refuse to negotiate the 64-bit Timestamps
   extended option by returning a regular 32-bit Timestamps option
   followed by the Cookie-Pair extended option.

   Segments with invalid Extend values MUST be silently discarded.

   Only one instance is permitted of either the (32-bit) Timestamps
   regular or (64-bit) Timestamps extended option.  Only one instance is
   permitted of either the Cookie-Pair extended or Timestamps extended
   option.  Segments with duplicative or mutually exclusive options MUST
   be silently discarded.

   Implementation Notes:

      Frequently, the 32-bit variant is aligned on a 32-bit boundary
      immediately following the TCP header.  The following data is
      aligned on a 64-bit boundary.

      When this option is aligned on a 32-bit boundary immediately
      following the TCP header, these fields are also 64-bit aligned.
      The following data is aligned on a 64-bit boundary.


3.6.  Cookie Generation

   The technique by which a party generates a cookie is implementation
   dependent.  The method chosen must satisfy some basic requirements:

   1. The cookie MUST depend on the specific parties.  This prevents an
      attacker from obtaining a cookie using a real IP address and TCP
      port, and then using it to swamp the victim with requests from
      randomly chosen IP addresses or ports.

   2. It MUST NOT be possible for anyone other than the issuing entity
      to generate cookies that will be accepted by that entity.  This
      implies that the issuing entity will use local secret information
      in the generation and subsequent verification of a cookie.  It
      must not be possible to deduce this secret information from any
      particular cookie.

   3. The cookie generation and verification methods MUST be fast to
      thwart attacks intended to sabotage CPU resources.

   A recommended technique is to use a cryptographic hashing function.

   An incoming cookie can be verified at any time by regenerating it
   locally from values contained in the incoming datagram and the local
   secret random value.



Simpson                  expires August 31, 2010               [Page 11]

DRAFT                    TCP Cookie Transactions           February 2010


3.6.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 <SYN> 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.

      However, it is important that the implementation protect mutually
      suspicious users of the same system from generating the same
      cookie.


3.6.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 MUST include its own TCP Sequence and
   Acknowledgment Numbers, its own TCP Timestamps value, and the
   Initiator-Cookie value.  This provides improved synchronization and
   protection against replay attacks.

   It is RECOMMENDED that the cookie be calculated over the secret
   value, the IP Source and Destination addresses, its own TCP
   Destination port (that is, the incoming Source port), its own TCP
   Sequence and Acknowledgment Numbers (after updating values), and the
   Initiator-Cookie value, followed by the secret value again.

   The cookie is not cached per Initiator to avoid saving state during
   the initial TCP <SYN> exchange.  On receipt of a TCP <ACK(SYN)>, the
   Responder regenerates its cookie for validation.




Simpson                  expires August 31, 2010               [Page 12]

DRAFT                    TCP Cookie Transactions           February 2010


   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 <SYN> that will be acknowledged.
      The Acknowledgment Number will be the Initial Sequence Number
      (ISN) plus one (1) for the <SYN> that it is now acknowledging.

      The (32-bit) Timestamps option MUST be present, and the Kind field
      SHOULD be included.  The Initiator Timestamp Length field MAY
      change to the extended header form; it MUST NOT be included.  The
      Initiator Timestamp value field 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.

      If a Responder Cookie is identical to the Initiator Cookie, the
      Responder SHOULD change one or more bits of its cookie to prevent
      its accidental appearance as a reflection attack.


3.6.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).



Simpson                  expires August 31, 2010               [Page 13]

DRAFT                    TCP Cookie Transactions           February 2010


   Secondary.
      Used for secondary verification, after primary verification
      failures.  This state lasts no more than twice the Maximum Segment
      Lifetime (2MSL).  Then, the secret is discarded.

   Implementation Notes:

      Care MUST be taken to ensure that any expired secrets are promptly
      wiped from memory, and secrets are never saved to external
      storage.

      The first secret after initialization begins in Primary state.
      The system might have shutdown and restarted rapidly during the
      previous first secret.  Thus, the first secret MUST be partially
      time dependent, to ensure that it differs from previous first
      secrets, usually by appending a time to lengthen the first secret.
      Those that are not the first secret SHOULD NOT include the time.

      At the same time, there is no TCP TIME-WAIT requirement before
      accepting connections, and there may be pent up demand for a busy
      service.  Also, there may be outstanding datagrams attempting to
      complete an earlier cookie exchange.  The first secret is likely
      to be the weakest, as no recent entropy has been included.

      Therefore, while terminating outstanding exchanges with the first
      secret, a new Generating secret SHOULD be created after no more
      than one Maximum Segment Lifetime (1MSL).  Subsequent secrets
      SHOULD be generated at the usual rate (typically 600 seconds).

      The implementation SHOULD continually gather additional entropy
      from checksums, cookies, timestamps, and packet arrival timing.


4.  Cookie Exchange

   A successful option exchange signals availability of additional
   features.


4.1.  Initiator <SYN>

   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



Simpson                  expires August 31, 2010               [Page 14]

DRAFT                    TCP Cookie Transactions           February 2010


   the Cookie option.

   During the initial exchange, the Initiator is solely responsible for
   retransmission.  Although the cookie, sequence, and timestamp have
   not changed, each retransmission appears to the Responder as another
   original <SYN>.

   Implementation Notes:

      Sending the <SYN> 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 <SYN,ACK(SYN)> arrives.  Then, any old TCB values are
      replaced.


4.2.  Responder <SYN,ACK(SYN)>

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

   The Responder generates its unpredictable cookie value, and includes
   the Cookie option.

   As the Responder is not required to have any TCB state,
   retransmission timers are not available.  Arrival of an Initiator's
   retransmission appears to be an original <SYN> transmission.  There
   are no differences in processing.

   Implementation Notes:

      Sending the <SYN,ACK(SYN)> 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.







Simpson                  expires August 31, 2010               [Page 15]

DRAFT                    TCP Cookie Transactions           February 2010


4.3.  Initiator <ACK(SYN)>

   Upon receipt of the <SYN,ACK(SYN)> with a Cookie option, the
   Initiator validates its cookie, timestamp, and corresponding
   Acknowledgment Number.  The existing TCB is updated as necessary.

   All Initiator <SYN> options are always retransmitted on this first
   <ACK(SYN)>, allowing the Responder to validate its cookie and
   establish its state.

   This segment contains both Timestamps and Cookie-Pair options.

   Implementation Notes:

      A Responder Cookie identical to the Initiator Cookie MUST be
      discarded.  This is usually an indication of a Monkey in the
      Middle (MITM) reflection attack or a seriously misconfigured
      network, and SHOULD be logged.


4.4.  Responder <ACK>

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

   Implementation Notes:

      An <ACK(SYN)> 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 <SYN> without an
   intervening <SYN,ACK(SYN)> [RFC 793, section 3.4, and Figure 8].
   Each party receives a Cookie for a <Source Address, Source Port,
   Destination Address, Destination Port> 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



Simpson                  expires August 31, 2010               [Page 16]

DRAFT                    TCP Cookie Transactions           February 2010


   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.

   The Initiator silently discards the simultaneous <SYN>.  The
   Responder revises its Cookie option, and sends the <SYN,ACK(SYN)> 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 <FIN> at any time.  This <FIN> SHOULD be
   sent with the final data segment.

   This segment contains both Timestamps and Cookie-Pair options.

   When all segments preceding the <FIN> have been processed and
   acknowledged, each party SHOULD acknowledge the <FIN>.

   In general, <FIN> 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 <FIN> bearing segment SHOULD terminate delayed <ACK> [RFC 5681].



Simpson                  expires August 31, 2010               [Page 17]

DRAFT                    TCP Cookie Transactions           February 2010


   Backoff SHOULD NOT used for <FIN> bearing retransmissions [RFC 2988].
   Instead, retransmit at the latest Timestamps estimated smoothed round
   trip time (SRTT).

   As the Responder retains no 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
   the appearance of persistent connections to intervening network
   equipment.


5.1.  Initiator Close

   Upon receipt of the Initiator <FIN> (and verification of the
   Timestamps and Cookie-Pair options), the Responder sends its
   <FIN,ACK(FIN)> unless there is additional data pending.  In the
   latter case, the <FIN> is ignored until the data has been processed
   and acknowledged.

   Upon receipt of the Responder <FIN,ACK(FIN)> (and verification of the
   Timestamps and Cookie-Pair options), the Initiator sends its final
   <ACK(FIN)> 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 <ACK(FIN)> (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 <ACK(FIN)>, and/or SHOULD NOT
   wait the remaining TIME-WAIT interval.  A TCB offset to the previous
   timestamp SHOULD be incremented.  The offset 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 <FIN> (and verification of the
   Timestamps and Cookie-Pair options), the Initiator sends its
   <FIN,ACK(FIN)> unless there is additional data pending.  In the
   latter case, the <FIN> is ignored until the data has been processed
   and acknowledged.

   Upon receipt of the Initiator <FIN,ACK(FIN)> (and verification of the



Simpson                  expires August 31, 2010               [Page 18]

DRAFT                    TCP Cookie Transactions           February 2010


   Timestamps and Cookie-Pair options), the Responder sends its final
   <ACK(FIN)> and removes its TCB.

   This segment contains both Timestamps and Cookie-Pair options.

   If the Responder final <ACK(FIN)> is lost, the Responder is likely to
   send a <RST> (as the Responder has no TCB).  This distinguished <RST>
   SHOULD copy both Timestamps and Cookie-Pair options.

   Upon receipt of the Responder final <ACK(FIN)> (and verification of
   the Timestamps and Cookie-Pair options), the Initiator enters TIME-
   WAIT state.

   Upon arrival of more data prompting a new Cookie exchange, the
   Initiator SHOULD NOT not send a <FIN,ACK(FIN)>, and/or SHOULD NOT
   wait the remaining TIME-WAIT interval.  A TCB offset to the previous
   timestamp SHOULD be incremented.  The offset 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 <SYN> Data

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




Simpson                  expires August 31, 2010               [Page 19]

DRAFT                    TCP Cookie Transactions           February 2010


   If the data will not entirely fit within the initial segment, data
   MUST NOT be sent until after the Responder's <SYN,ACK(SYN)> is
   received.

   Unlike T/TCP [RFC 1644], <FIN> SHOULD NOT be set.  This facilitates
   the appearance of persistent connections.

   Likewise, <PSH> SHOULD NOT be set.  Although the application might
   use push to indicate that its data is ready to send, the push is
   implied for <SYN> data segments.

   During the initial exchange, the Initiator is solely responsible for
   retransmission.  Although the cookie, sequence, and timestamp have
   not changed, each retransmission appears to the Responder as another
   original <SYN>.

   Implementation Notes:

      Initiator <SYN,FIN> with the Cookie option and no segment data is
      permitted in a test environment.  This combination SHOULD be
      silently discarded.

      Initiator <SYN,FIN> with both the Cookie option and segment data
      is similar to T/TCP [RFC 1644].  However, whenever the Responder
      <SYN,ACK(SYN),FIN> 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 <FIN> to close the connection.


6.2.  Responder <SYN,ACK(SYN)> Data

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

   If the segment data is the entire response (there is no further data
   expected), <FIN> MAY be set.

   However, <PSH> SHOULD NOT be set.  Although the application might use



Simpson                  expires August 31, 2010               [Page 20]

DRAFT                    TCP Cookie Transactions           February 2010


   push to indicate that its data is ready to send, the push is implied
   for <FIN> data segments [RFC 793, section 3.7, page 41].

   As the Responder is not required to have any TCB state,
   retransmission timers are not available.  Arrival of an Initiator's
   retransmission appears to be an original <SYN> transmission.  There
   are no differences in processing.

   Implementation Notes:

      The Responder Cookie depends on the TCP Sequence and
      Acknowledgment Numbers after processing <SYN>.  Therefore, neither
      will include data.


6.3.  Initiator <ACK(SYN)> Data

   Upon receipt of the <SYN,ACK(SYN)> 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 <SYN> data is retransmitted in <ACK(SYN)>, as its
   processing is optional.  The Acknowledgment Number will be the
   received Sequence Number plus one (1) for the <SYN>.  The Sequence
   Number will be the Initial Sequence Number (ISN) plus one (1) for the
   <SYN>.

   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
   <ACK>, 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) <FIN>.

      Initiator <ACK(SYN),FIN> with the Cookie-Pair option and no



Simpson                  expires August 31, 2010               [Page 21]

DRAFT                    TCP Cookie Transactions           February 2010


      segment data is never required; TCB state has not been saved at
      the Responder.  This combination MUST be silently discarded.


6.4.  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 transmit the
   same response.

   If the Selective Acknowledgment (Sack) option [RFC 2018] has been
   successfully negotiated, with a short Sack covering earlier response
   data, only additional unacknowledged response data is sent.

   At this time, any second segment may be sent without awaiting an
   <ACK>, 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 <RST> 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 <RST> is always treated as advisory.  A <RST> 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.











Simpson                  expires August 31, 2010               [Page 22]

DRAFT                    TCP Cookie Transactions           February 2010


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 <ACK(SYN)> MAY include this option to
   acknowledge any optional transaction response data.


8.2.  TCP Timestamps

   (Kind 8 [rfc1323bis].)  Support is required.  These 32-bit timestamps
   always appear as a regular option.


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].)  The data field is well suited to header
   extension, as 32-bit alignment is required.  However, this option is
   beyond the scope of this specification.

   The size of the option itself precludes use with the Cookie option in
   the <SYN>.  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 August 31, 2010               [Page 23]

DRAFT                    TCP Cookie Transactions           February 2010


8.5.  TCP Authentication

   (Kind TBD.)  The data field is not well suited to header extension,
   as there is no 32-bit alignment requirement.

   The size of the option itself precludes use with the Cookie option in
   the <SYN>.  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.


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].




Simpson                  expires August 31, 2010               [Page 24]

DRAFT                    TCP Cookie Transactions           February 2010


   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]
   was published with a mechanism analogous to SYN cookies.


Acknowledgments

   Andre Broido informally described utilizing cookies for Transport
   Layer Security (TLS) session identifiers.  Rapid TLS session
   resumption would improve both latency and privacy.

   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 <SYN,ACK(SYN)> 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.












Simpson                  expires August 31, 2010               [Page 25]

DRAFT                    TCP Cookie Transactions           February 2010


IANA Considerations

   This specification registers two new TCP options.  These (previously
   unpublished) options were specifically selected to avoid conflicts,
   and IANA was advised in advance.

   TCP Cookie Option
   Kind: 31
   Length: variable.

   TCP Timestamps Extended Option
   Kind: 32
   Length: 3.

   Notes: Kind 31 is a prime number, particularly appropriate for a
   security enhancement.  Kind 32 is a multiple of TCP Timestamps Option
   (Kind 8); Kind 16 was already registered.


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 <SYN> on a per port basis.

   TCP_COOKIE_IN_ALWAYS
      Default: off.  Silently discard any incoming <SYN> 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 timestamps extension.

   TCP_SYN_DATA_LIMIT
      Default: 0.  Maximum: 496.  The maximum amount of data transmitted
      with the <SYN> 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 <SYN,ACK(SYN)> on a per port basis.  Wait for
      data before sending.





Simpson                  expires August 31, 2010               [Page 26]

DRAFT                    TCP Cookie Transactions           February 2010


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.

   TCPCT is not intended to prevent or recover from all possible
   security threats.  Rather, it is designed to protect against Denial
   of Service (DoS) attacks [RFC 3552], and inhibit inadvertent
   middlebox interference.

   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 <SYN,ACK(SYN)> 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 August 31, 2010               [Page 27]

DRAFT                    TCP Cookie Transactions           February 2010


A.  Example headers
A.1.  Example <SYN> header

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 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 August 31, 2010               [Page 28]

DRAFT                    TCP Cookie Transactions           February 2010


A.2.  Example <ACK(SYN)> with Sack

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 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=4      | Extend=10     |   0   | Size=7|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Kind=wscale   | Length=3      |    (value)    | Kind=EOL      |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                                                               |
   +                                                               +
   |                                                               |
   +                       Initiator-Cookie                        +
   |                                                               |
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                                                               |
   +                       Responder-Cookie                        +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Kind=nop      | Kind=nop      | Kind=Sack     | Length=10     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Starting Value                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Ending Value                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The 224-bit cookie pair is much too large to fit with the other
   recommended options.  This illustrates an extension of the TCP
   header.










Simpson                  expires August 31, 2010               [Page 29]

DRAFT                    TCP Cookie Transactions           February 2010


A.3.  Example header with 64-bit Timestamps

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Kind=MSS      | Length=4      |            (value)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Kind=UTO      | Length=4      |           (timeout)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Kind=TS64     | Length=3      | Extend=12     | Kind=nop      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Kind=wscale   | Length=3      |    (value)    | Kind=EOL      |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                                                               |
   +                           TS Value                            +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                         TS Echo Reply                         +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Kind=SackOK   | Length=2      | Kind=Cookie   | Length=30     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                       Initiator-Cookie                        +
   |                                                               |
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                                                               |
   +                       Responder-Cookie                        +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This example shows the (optional) 64-bit Timestamps extended option.














Simpson                  expires August 31, 2010               [Page 30]

DRAFT                    TCP Cookie Transactions           February 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 August 31, 2010               [Page 31]

DRAFT                    TCP Cookie Transactions           February 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

   [Hannan1996]
               Hannum, C., "Security Problems Associated With T/TCP",
               unpublished work in progress, September 1996.
               http://www.mid-way.org/doc/ttcp-sec.txt

   [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

   [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



Simpson                  expires August 31, 2010               [Page 32]

DRAFT                    TCP Cookie Transactions           February 2010


   [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
               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.



Simpson                  expires August 31, 2010               [Page 33]

DRAFT                    TCP Cookie Transactions           February 2010


   [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 4340]  Kohler, E., Handley, M., and Floyd, S., "Datagram
               Congestion Control Protocol (DCCP)", March 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.




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 August 31, 2010               [Page 34]


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