GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6013

Independent Submission W. Simpson Request for Comments: 6013 DayDreamer Category: Experimental January 2011 ISSN: 2070-1721

                  TCP Cookie Transactions (TCPCT)

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.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for examination, experimental implementation, and
 evaluation.
 This document defines an Experimental Protocol for the Internet
 community.  This is a contribution to the RFC Series, independently
 of any other RFC stream.  The RFC Editor has chosen to publish this
 document at its discretion and makes no statement about its value for
 implementation or deployment.  Documents approved for publication by
 the RFC Editor are not a candidate for any level of Internet
 Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc6013.

Simpson Experimental [Page 1] RFC 6013 TCP Cookie Transactions January 2011

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 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 Experimental [Page 2] RFC 6013 TCP Cookie Transactions January 2011

Table of Contents

 1. Introduction ....................................................4
    1.1. Terminology ................................................4
 2. Protocol Overview ...............................................4
    2.1. Message Summary (Simplified) ...............................6
    2.2. Compatibility and Transparency .............................7
    2.3. Fully Loaded Cookies .......................................7
    2.4. TCP Header Extension .......................................8
    2.5. <SYN> Option Handling ......................................9
 3. Protocol Details ................................................9
    3.1. TCP Cookie Option .........................................10
    3.2. TCP Cookie-Pair Standard Option ...........................10
    3.3. TCP Cookie-less Option ....................................11
    3.4. TCP Timestamps Extended Option ............................11
    3.5. Cookie Generation .........................................13
 4. Cookie Exchange ................................................16
    4.1. Initiator <SYN> ...........................................16
    4.2. Responder <SYN,ACK(SYN)> ..................................17
    4.3. Initiator <ACK(SYN)> ......................................17
    4.4. Responder <ACK> ...........................................18
    4.5. Simultaneous Open .........................................18
 5. Accelerated Close ..............................................19
    5.1. Initiator Close ...........................................20
    5.2. Responder Close ...........................................20
 6. Accelerated Open ...............................................21
    6.1. Initiator <SYN> Data ......................................21
    6.2. Responder <SYN,ACK(SYN)> Data .............................22
    6.3. Initiator <ACK(SYN)> Data .................................23
    6.4. Responder <ACK> Data ......................................24
 7. Advisory Reset .................................................24
 8. Interactions with Other Options ................................24
    8.1. TCP Selective Acknowledgment ..............................25
    8.2. TCP Timestamps ............................................25
    8.3. TCP Extensions for Transactions ...........................25
    8.4. TCP MD5 Signature .........................................25
    8.5. TCP Authentication ........................................25
 9. History ........................................................26
 10. Acknowledgments ...............................................27
 11. IESG Considerations ...........................................27
 12. Operational Considerations ....................................28
 13. Security Considerations .......................................28
 Appendix A. Example Headers .......................................30
    A.1. Example <SYN> Options .....................................30
    A.2. Example <ACK(SYN)> with Sack ..............................31
    A.3. Example <ACK(SYN)> with 64-bit Timestamps .................32
 Normative References ..............................................33
 Informative References ............................................34

Simpson Experimental [Page 3] RFC 6013 TCP Cookie Transactions January 2011

1. Introduction

 TCP Cookie Transactions (TCPCT) provide a cryptologically secure
 mechanism to guard against simple flooding attacks sent with bogus IP
 [RFC791] Sources or TCP [RFC793] Ports.  The initial TCP <SYN>
 exchange is vulnerable to forged IP Addresses, predictable Ports, and
 discoverable Sequence Numbers [Morris1985] [Gont2009].  (See also
 [RFC2827], [RFC3704], and [RFC4953].)
 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 were detailed in [MSV2009].

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

 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.

Simpson Experimental [Page 4] RFC 6013 TCP Cookie Transactions January 2011

    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 Transport Control Block (TCB) [RFC793].
    Note that the Responder returns the Cookie-Pair with its initial
    data, but subsequent data segments need only the Timestamps.
 3. During close (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 is summarized in the diagram below.

Simpson Experimental [Page 5] RFC 6013 TCP Cookie Transactions January 2011

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 Experimental [Page 6] RFC 6013 TCP Cookie Transactions January 2011

2.2. Compatibility and Transparency

    It is usually better that data arrive slowly, than not at all.
 Many/most unmanaged middleboxes [RFC3234] (such as stateless
 firewalls, load balancers, intrusion detection systems, or network
 address translators [RFC3022]) cannot carry transport traffic other
 than TCP and UDP.
 Every TCP implementation MUST ignore without error any TCP option it
 does not implement ([RFC1122] section 4.2.2.5).  In a study of the
 effects of middleboxes on transport protocols [MAF2004], the vast
 majority of modern TCP stacks correctly handle unknown TCP options.
 But it is still prudent to follow the [RFC793] "general principle of
 robustness: be conservative in what you do, be liberal in what you
 accept from others."
 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 [RFC1323] [rfc1323bis] and its antecedents).
 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
 with backward compatibility.  Semantics for the option have been
 "overloaded" with a baker's dozen of 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.
 C. Cookie values allow applications to detect replay attacks.

Simpson Experimental [Page 7] RFC 6013 TCP Cookie Transactions January 2011

 D. Cookie values MAY be used as an index or nonce for application
    security protocols.  This facility is beyond the scope of this
    specification.
 E. The <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 beyond the scope of this
    specification.
 F. The size of the cookies precludes most other options in the
    standard TCP header space.  The cookie exchange negotiates TCP
    header extension.
 G. The cookie exchange and resulting TCP header extension permit
    negotiation of larger 64-bit (or 128-bit) Timestamps for paths
    with large bandwidth-delay products.
 H. TCP header extension frees some space for additional options.
 I. Previously SYN-only options can be updated.
 J. The cookie exchange indicates agreement to use accelerated close.
 K. The cookie exchange indicates agreement that only the Initiator
    (client) handles TIME-WAIT state.
 L. The Timestamps and Cookie-Pair combination inhibits third parties
    from disrupting communications with <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 Timestamps extended option (defined
 below) indicates the presence of the header extension.
 Validation of known timestamp values protects against data corruption
 by misbehaving middleboxes.

Simpson Experimental [Page 8] RFC 6013 TCP Cookie Transactions January 2011

2.5. <SYN> Option Handling

 As the Responder retains no TCB state after the initial TCP <SYN>
 exchange, all options present in the original <SYN> MUST be repeated.
 For example, an option defined in the [RFC793] 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 [RFC5452] describes use of an unpredictable Source
 Port.  That is RECOMMENDED by this specification.  See [RFC6056] for
 further information.
 An earlier solution [RFC1948] describes an unpredictable Initial
 Sequence Number (ISN).  That is REQUIRED by this specification.
 Support for the (32-bit) TCP Timestamps Option [RFC1323] is REQUIRED.
 A TSoffset SHOULD be generated per connection [GO2010].  The Don't
 Fragment (DF) bit MUST be set in the IP (v4) header.
 The TCP User Timeout Option [RFC5482] is RECOMMENDED.
 Only one instance is permitted of any of the Cookie, Cookie-less, or
 Cookie-Pair option(s).  Segments with duplicative or mutually
 exclusive options MUST be silently discarded.
 For examples, see Appendix A.

Simpson Experimental [Page 9] RFC 6013 TCP Cookie Transactions January 2011

3.1. TCP Cookie Option

                                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                 |      Kind     |    Length     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~                            Cookie                             ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Kind             1 byte: constant 253 (experimental).
 Length           1 byte: range 10 to 18 (bytes); limited by remaining
                  space in the options field.  The number MUST be
                  even; the cookie is a multiple of 16 bits.
 Cookie           8 to 16 bytes (Length - 2): an unpredictable value.
 Options with invalid Length values MUST be ignored.  The minimum
 Cookie size is 64 bits.  If there is not sufficient space for a
 64-bit cookie, this option MUST NOT be used.
 The Responder Cookie MUST be the same size as the Initiator Cookie.
 The cookie pair is a multiple of 32 bits.
 Although the diagram shows a cookie aligned on 32-bit boundaries,
 that is not required.

3.2. TCP Cookie-Pair Standard Option

                                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                 |      Kind     |    Length     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~                       Initiator-Cookie                        ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~                       Responder-Cookie                        ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Kind             1 byte: constant 253 (experimental).
 Length           1 byte: range 18 to 34 (bytes).  The number MUST be
                  even; the cookie pair is a multiple of 32 bits.
 Initiator-Cookie 8 to 16 bytes, from the original <SYN>.

Simpson Experimental [Page 10] RFC 6013 TCP Cookie Transactions January 2011

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

3.3. TCP Cookie-less Option

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |      Kind     |    Length     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Kind             1 byte: constant 253 (experimental).
 Length           1 byte: constant 2 (bytes).  This distinguishes the
                  option from other Cookie options.
 Although no cookie is attached, this indicates that other features of
 this specification are available, including TCP header extension,
 Accelerated Close, Accelerated Open, and Advisory Reset.  This is
 intended for use with TCP authentication options, beyond the scope of
 this specification.

3.4. TCP Timestamps Extended Option

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |      Kind     |    Length     |    Extend     |    R    |  S  |
 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
 |                                                               |
 ~                           TS Value                            ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 ~                         TS Echo Reply                         ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Kind             1 byte: constant 254 (experimental).
 Length           1 byte: constant 4 (bytes).

Simpson Experimental [Page 11] RFC 6013 TCP Cookie Transactions January 2011

 Extend           1 byte: range 9 to 255; the data offset (in 32-bit
                  words) following the standard TCP header.  Note this
                  value MUST include the timestamp pair indicated by
                  (S)ize.
 (R)eserved       5 bits: default zero.  Reserved for future use.
 (S)ize           3 bits:
                  1. 32-bit timestamps.
                  2. 64-bit timestamps.
                  4. 128-bit timestamps.
                  Other values are beyond the scope of this
                  specification.
 TS Value         4, 8, or 16 bytes.  The current value of the
                  timestamp for the sender.
 TS Echo Reply    4, 8, or 16 bytes.  A copy of the most recently
                  received TS Value.
 The full timestamp pair follows the TCP header (indicated by +=+
 delimiters) and maintains 32-bit alignment.
 This TCP header extension is ignored for sequence number
 computations.  The Sequence Number of the first byte of segment data
 will be the Initial Sequence Number (ISN) plus one (1) for the <SYN>.
 Every TCPCT implementation MUST recognize a Timestamps extended
 option.  The larger 64-bit (or 128-bit) timestamps only appear in an
 extended option.
 Segments with invalid Extend values MUST be silently discarded.
 Only one instance is permitted of either the (32-bit) Timestamps
 standard option or this Timestamps extended option.  Segments with
 duplicative or mutually exclusive options MUST be silently discarded.
 Implementation Notes:
    Serendipitous alignment allows simple loads and stores, instead of
    slower byte by byte iterations.

Simpson Experimental [Page 12] RFC 6013 TCP Cookie Transactions January 2011

    When the TCP header is aligned on a 32-bit boundary and this is
    the only option, the timestamps in the extended header SHOULD be
    aligned on a 64-bit boundary.  For both 32-bit and 64-bit
    timestamps, any data following the extended header will be aligned
    on a 64-bit boundary.
    However, the 128-bit timestamps are not 128-bit aligned.

3.5. Cookie Generation

 The technique by which a party generates a cookie is implementation
 dependent.  The method chosen must satisfy some basic requirements:
 1. The cookie MUST depend on the specific parties.  This prevents an
    attacker from obtaining a cookie using a real IP address and TCP
    port, and then using it to swamp the victim with requests from
    randomly chosen IP addresses or ports.
 2. It MUST NOT be possible for anyone other than the issuing entity
    to generate cookies that will be accepted by that entity.  This
    implies that the issuing entity will use local secret information
    in the generation and subsequent verification of a cookie.  It
    must not be possible to deduce this secret information from any
    particular cookie.
 3. The cookie generation and verification methods MUST be fast to
    thwart attacks intended to sabotage CPU resources.
 A recommended technique is to use a cryptographic hashing function.
 An incoming cookie can be verified at any time by regenerating it
 locally from values contained in the incoming datagram and the local
 secret random value.

3.5.1. Initiator Cookie

 The Initiator secret value that affects its cookie SHOULD change for
 each new exchange, and is thereafter internally cached per TCB.  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.

Simpson Experimental [Page 13] RFC 6013 TCP Cookie Transactions January 2011

 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.
    Likewise, segment data might not be included directly.  For
    example, a pointer to the data could be included instead, with
    care taken to ensure the pointer changes anytime the data changes.
    However, it is important that the implementation protect mutually
    suspicious users of the same system from generating the same
    cookie.

3.5.2. Responder Cookie

 The Responder secret value that affects its cookies remains the same
 for many different Initiators.  However, this secret SHOULD be
 changed periodically to limit the time for use of its cookies
 (typically each 600 seconds).
 The Responder-Cookie calculation MUST include its own TCP Sequence
 and Acknowledgment Numbers (after updating values), its own TCP
 Timestamps value, and the Initiator-Cookie value.  This provides
 improved synchronization and protection against replay attacks.
 It is RECOMMENDED that the cookie be calculated over the secret
 value, the IP Source and Destination addresses, its own TCP
 Destination Port (that is, the incoming Source Port), and the
 required values (above), followed by the secret value again.
 The cookie is not cached per Initiator to avoid saving state during
 the initial TCP <SYN> exchange.  On receipt of a TCP <ACK(SYN)>, the
 Responder regenerates its cookie for validation.
 Implementation Notes:
    Although the recommendation does not include the TCP Source Port,
    this is very implementation specific.  It might be successfully
    included in some variants.
    The Responder Cookie depends on the TCP Sequence and
    Acknowledgment Numbers as they will appear for future
    verification.  The Sequence Number will be the Initial Sequence

Simpson Experimental [Page 14] RFC 6013 TCP Cookie Transactions January 2011

    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) TCP Timestamps standard option MAY change to the
    larger 64-bit (or 128-bit) extended form; only the least
    significant 32 bits are included.  The Initiator Timestamp field
    value MAY increment during the exchange; it MUST NOT be included.
    The secret value is included twice to better protect against pre-
    calculated attacks using substitutions for variable length data.
    Some examples using this technique are IP-MAC and H-MAC, and it is
    likely that existing code could be shared.
    The Responder SHOULD designate a (fixed or randomly selected) bit
    of its cookie to distinguish each changed secret value.  The bit
    is set to a (fixed or randomly selected) constant 0 or 1, and
    checked upon receipt before further verification.  This ensures
    that only one verification calculation is necessary (on average)
    during Denial of Service (DoS) attacks.
    If a Responder Cookie is identical to the Initiator Cookie, the
    Responder SHOULD change one or more bits of its cookie to prevent
    its accidental appearance as a reflection attack.

3.5.3. Responder Secret Value

 Each Responder maintains up to two secret values concurrently for
 efficient secret rollover.  Each secret value has 4 states:
 Generating
    Generates new Responder-Cookies, but not yet used for primary
    verification.  This is a short-term state, typically lasting only
    one Round Trip Time (RTT).
 Primary
    Used both for generation and primary verification.
 Retiring
    Used for verification, until the first failure that can be
    verified by the newer Generating secret.  At that time, this
    cookie's state is changed to Secondary, and the Generating
    cookie's state is changed to Primary.  This is a short-term state,
    typically lasting only one RTT.

Simpson Experimental [Page 15] RFC 6013 TCP Cookie Transactions January 2011

 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
 the Cookie option.

Simpson Experimental [Page 16] RFC 6013 TCP Cookie Transactions January 2011

 During the initial exchange, the Initiator is solely responsible for
 retransmission.  Although the cookie and sequence have not changed,
 each retransmission appears to the Responder as another original
 <SYN>.
 Implementation Notes:
    Sending the <SYN> SHOULD NOT affect any existing TCB.  This allows
    an additional 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 [RFC1948].
 The Responder generates its unpredictable cookie value, and includes
 the Cookie option.
 As the Responder retains no TCB state, retransmission timers are not
 available.  Arrival of an Initiator's retransmission appears to be an
 original <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 RTT for duplicate or out-of-sequence segments
    to drain.
    This also inhibits third parties from disrupting communications.

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.

Simpson Experimental [Page 17] RFC 6013 TCP Cookie Transactions January 2011

 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.
 The Initiator sends the Timestamps extended option with an
 appropriate Size -- chosen by a configurable parameter, or
 automatically based on its analysis of the bandwidth-delay product
 discovered through the RTT of its <SYN> timestamp.  When the chosen
 Size is greater than 32 bits, the Initiator adds a random prefix to
 its own timestamp, and a random prefix to the Responder timestamp
 echo reply.
 Implementation Notes:
    A Responder Cookie identical to the Initiator Cookie MUST be
    discarded.  This is usually an indication of a Monkey in the
    Middle (MITM) reflection attack or a seriously misconfigured
    network, and SHOULD be logged.

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.
 However, the Responder MAY refuse to negotiate the larger 64-bit (or
 128-bit) Timestamps extended option by returning the least
 significant bits in a smaller Timestamps extended option.
 Implementation Notes:
    An <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)> (see [RFC793] 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.

Simpson Experimental [Page 18] RFC 6013 TCP Cookie Transactions January 2011

 This condition will be unusual.  The Source Port SHOULD be randomized
 [RFC5452], and SHOULD be chosen to differ from the Destination Port.
 In particular, the Source Port SHOULD be greater than 1024,
 preventing intervening network equipment from incorrectly classifying
 the return traffic.  The Destination Port is most likely to be a
 well-known port less than 1024 [RFC3232].
 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.

Simpson Experimental [Page 19] RFC 6013 TCP Cookie Transactions January 2011

 Rapidly closing the connection expedites removing Responder state.
 Any <FIN> bearing segment SHOULD terminate delayed <ACK> [RFC5681].
 Retransmit at the latest Timestamps estimated Smoothed Round Trip
 Time (SRTT).  Backoff SHOULD NOT be used for <FIN> bearing
 retransmissions [RFC2988].
 As the Responder retains no TCB state after closing, a successful
 option exchange signals the Initiator will be responsible for
 handling TIME-WAIT state.  (For previous proposal and rationale, see
 [FTY1999] section 3.)
 A new Cookie exchange MAY be initiated at any time.  This facilitates
 persistent connections through 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 send a final <ACK(FIN)> and/or SHOULD NOT wait
 the remaining TIME-WAIT interval.  Any existing TSoffset SHOULD be
 incremented.  TSoffset will be removed (with the TCB itself) at the
 conclusion of a future TIME-WAIT state.

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.

Simpson Experimental [Page 20] RFC 6013 TCP Cookie Transactions January 2011

 Upon receipt of the Initiator <FIN,ACK(FIN)> (and verification of the
 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's final <ACK(FIN)> is lost, the Responder is likely
 to send a <RST> (as the Responder retains no TCB state).  This
 distinguished <RST> SHOULD copy both Timestamps and Cookie-Pair
 options.
 Upon receipt of the Responder's 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 send a <FIN,ACK(FIN)> and/or SHOULD NOT wait the
 remaining TIME-WAIT interval.  Any existing TSoffset SHOULD be
 incremented.  TSoffset will be removed (with the TCB itself) at the
 conclusion of a future TIME-WAIT state.

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 separately for each port
 or connection.  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 ([RFC1122] 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 Experimental [Page 21] RFC 6013 TCP Cookie Transactions January 2011

 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 [RFC1644], <FIN> SHOULD NOT be sent with <SYN> data.
 This facilitates 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 and sequence 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 [RFC1644].  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 [RFC5358].
 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.

Simpson Experimental [Page 22] RFC 6013 TCP Cookie Transactions January 2011

 However, <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 <FIN> data segments (see [RFC793] section 3.7, page 41).
 As the Responder retains no TCB state, retransmission timers are not
 available.  Arrival of an Initiator's retransmission appears to be an
 original <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 [RFC1644], there is no implicit acknowledgment.
 If the Selective Acknowledgment (Sack) option [RFC2018] 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 [RFC5681] 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>.

Simpson Experimental [Page 23] RFC 6013 TCP Cookie Transactions January 2011

    Initiator <ACK(SYN),FIN> with the Cookie-Pair option and no
    segment data is never required; TCB state has not been saved at
    the Responder.  This combination MUST be silently discarded.

6.4. Responder <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 [RFC2018] 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 [RFC5681] 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 [RFC1323].  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 [RFC5482] for
 additional information.)
 This also inhibits third parties from disrupting communications.

8. Interactions with Other Options

 A successful Cookie (or Cookie-less) option exchange signals
 availability of the TCP header extension.  Other options with large
 data portions MAY also use this feature.  The extended option data is
 processed in the order that the options appear.

Simpson Experimental [Page 24] RFC 6013 TCP Cookie Transactions January 2011

8.1. TCP Selective Acknowledgment

 (Kind 5 [RFC2018].)  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 [RFC1323].)  Support is REQUIRED.  See also section 3.
 When a segment needs no header extension, and 32-bit timestamps have
 been negotiated, this option MUST be sent.

8.3. TCP Extensions for Transactions

 (Kinds 11-13 [RFC1644].)  Incompatible with this specification, and
 MUST be ignored on receipt.

8.4. TCP MD5 Signature

 (Kind 19 [RFC2385].)  This option is beyond the scope of this
 specification.  Because specific configuration is required, sending
 is under the complete control of the operator.  Segments lacking this
 option will be silently discarded.
 The size of the option itself precludes use with the Cookie option in
 the <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.

8.5. TCP Authentication

 (Kind 29 [RFC5925].)  This option is beyond the scope of this
 specification.  Because specific configuration is required, sending
 is under the complete control of the operator.  Segments lacking this
 option will be silently discarded.
 The size of the option itself precludes use with the Cookie option in
 the <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 Experimental [Page 25] RFC 6013 TCP Cookie Transactions January 2011

9. History

 T/TCP [RFC1379] [RFC1644] permits lightweight TCP transactions for
 applications that traditionally have used UDP.  However, T/TCP has
 unacceptable security issues [Hannum1996] [Phrack1998].
 The initial specification [KS1995] of Photuris [RFC2522], now called
 version 1 (December 1994 to March 1995), was based on a short list of
 design requirements, and simple experimental code by Phil Karn.  A
 "Cookie" Exchange guards against simple flooding attacks sent with
 bogus IP Sources or UDP Ports.
 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 (ISN).  This
 technique was exceptionally clever, because it did not require
 cooperation of the remote party and could be deployed unilaterally.
 However, SYN cookies can only be used in emergencies; they are
 incompatible with most TCP options.  As there is insufficient space
 in the Sequence Number, the cookie is not considered cryptologically
 secure.  Therefore, the mechanism remains inactive until the system
 is under attack, and thus is not well tested in operation.  SYN
 cookies were not accepted for publication until recently [RFC4987].
 In 1998, Perry Metzger proposed adding Karn's cookies as part of a
 "TCPng" discussion [Metzger1998].
 In 1999, Faber, Touch, and Yue [FTY1999] proposed using an option to
 negotiate the party that would maintain TIME-WAIT state.  This
 permits a server to entirely eliminate state after closing a
 connection.
 In 2000, the Stream Control Transmission Protocol (SCTP) [RFC2960]
 was published with an inadequate partial cookie mechanism claiming to
 be based upon Photuris.  It featured a deficient checksum (replaced
 in 2002 by [RFC3309] without graceful transition), and has undergone
 subsequent revisions [RFC4960].

Simpson Experimental [Page 26] RFC 6013 TCP Cookie Transactions January 2011

 In 2006, the Datagram Congestion Control Protocol (DCCP) [RFC4340]
 was published with a mechanism analogous to SYN cookies.

10. Acknowledgments

 Andre Broido informally described utilizing cookies for Transport
 Layer Security (TLS) session identifiers, in place of the [RFC5077]
 ticket.  Rapid TLS session resumption would improve both latency and
 privacy, but is beyond the scope of this specification.  Also, he
 provided numerous helpful comments and additional references, such as
 [KBC2005].
 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.

11. IESG Considerations

 Two TCP Option numbers are reserved for general experimental use
 under the rules laid out in [RFC4727] and [RFC3692] section 1.  Such
 values reserved for experimental use are never to be made permanent;
 permanent assignments should be obtained through standard processes.
 Experimental numbers are intended for experimentation and testing and
 are not intended for wide or general deployments.
 For further information, contact the author.

Simpson Experimental [Page 27] RFC 6013 TCP Cookie Transactions January 2011

12. Operational Considerations

 Any implementation of this specification SHOULD be configurable,
 separately for each port or connection.
 TCPCT_COOKIE_DESIRED
    Values: 0 (disabled), 8, 10, 12, 14, 16.  Default: 16.  Send the
    Cookie option with the <SYN>.
 TCPCT_EXTEND_TS[32|64|128]
    Default: off.  If defined, may designate 32-bit, 64-bit, or
    128-bit timestamps extension.
 TCPCT_IN_ALWAYS
    Default: off.  Silently discard any incoming <SYN> that is missing
    the Cookie option.
 TCPCT_OUT_NEVER
    Default: off.  Refuse to send (override) the Cookie option.
 TCP_SYN_DATA_LIMIT
    Default: 0.  Maximum: 496.  The maximum amount of data transmitted
    with the <SYN>.  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)>.  Wait for data before
    sending.

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

Simpson Experimental [Page 28] RFC 6013 TCP Cookie Transactions January 2011

 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.
 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 Experimental [Page 29] RFC 6013 TCP Cookie Transactions January 2011

Appendix A. Example Headers

A.1. Example <SYN>

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | 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 (112-bit) Cookie 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 Experimental [Page 30] RFC 6013 TCP Cookie Transactions January 2011

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

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Kind=TSX      | Length=4      | Extend=16     |    0    | S=1 |
 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
 |                           TS Value                            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         TS Echo Reply                         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Kind=nop      | Kind=nop      | Kind=Cookie   | Length=30     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 +                                                               +
 |                                                               |
 +                       Initiator-Cookie                        +
 |                                                               |
 +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                               |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
 |                                                               |
 +                       Responder-Cookie                        +
 |                                                               |
 +                                                               +
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Kind=MSS      | Length=4      |            (value)            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Kind=UTO      | Length=4      |           (timeout)           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Kind=nop      | Kind=nop      | Kind=Sack     | Length=10     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                        Starting Value                         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         Ending Value                          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Kind=wscale   | Length=3      |    (value)    | Kind=EOL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Sack implies SackOK.

Simpson Experimental [Page 31] RFC 6013 TCP Cookie Transactions January 2011

A.3. Example <ACK(SYN)> with 64-bit Timestamps

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Kind=TSX      | Length=4      | Extend=15     |    0    | S=2 |
 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
 |                                                               |
 +                           TS Value                            +
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 +                         TS Echo Reply                         +
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Kind=SackOK   | Length=2      | Kind=Cookie   | Length=30     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 +                                                               +
 |                                                               |
 +                       Initiator-Cookie                        +
 |                                                               |
 +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                               |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
 |                                                               |
 +                       Responder-Cookie                        +
 |                                                               |
 +                                                               +
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Kind=MSS      | Length=4      |            (value)            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Kind=UTO      | Length=4      |           (timeout)           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Kind=wscale   | Length=3      |    (value)    | Kind=EOL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 The larger 64-bit (or 128-bit) Timestamps extended option MUST be
 recognized, although the Responder MAY return a smaller Timestamps
 extended option.

Simpson Experimental [Page 32] RFC 6013 TCP Cookie Transactions January 2011

Normative References

 [RFC791]   Postel, J., "Internet Protocol", STD 5, RFC 791, September
            1981.
 [RFC793]   Postel, J., "Transmission Control Protocol", STD 7, RFC
            793, September 1981.
 [RFC1122]  Braden, R., Ed., "Requirements for Internet Hosts -
            Communication Layers", STD 3, RFC 1122, October 1989.
 [RFC1323]  Jacobson, V., Braden, R., and D. Borman, "TCP Extensions
            for High Performance", RFC 1323, May 1992.
 [RFC1948]  Bellovin, S., "Defending Against Sequence Number Attacks",
            RFC 1948, May 1996.
 [RFC2018]  Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
            Selective Acknowledgment Options", RFC 2018, October 1996.
 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC2988]  Paxson, V. and M. Allman, "Computing TCP's Retransmission
            Timer", RFC 2988, November 2000.
 [RFC3232]  Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced
            by an On-line Database", RFC 3232, January 2002.
 [RFC5452]  Hubert, A. and R. van Mook, "Measures for Making DNS More
            Resilient against Forged Answers", RFC 5452, January 2009.
 [RFC5482]  Eggert, L. and F. Gont, "TCP User Timeout Option", RFC
            5482, March 2009.
 [RFC5681]  Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
            Control", RFC 5681, September 2009.

Simpson Experimental [Page 33] RFC 6013 TCP Cookie Transactions January 2011

Informative References

 [EL2008]   Eddy, W. and A. Langley, "Extending the Space Available
            for TCP Options", Work in Progress, July 2008.
 [FTY1999]  Faber, T., Touch, J., and W. Yue, "The TIME-WAIT state in
            TCP and Its Effect on Busy Servers", IEEE INFOCOM 99, pp.
            1573-1584.
 [Gont2009] Gont, F., "Security assessment of the Transmission Control
            Protocol (TCP)", February 2009.
            https://www.cpni.gov.uk/Docs/tn-03-09-security-
            assessment-TCP.pdf
 [GO2010]   Gont, F. and A. Oppermann, "On the generation of TCP
            timestamps", Work in Progress, June 2010.
 [Hannum1996]
            Hannum, C., "Security Problems Associated With T/TCP",
            unpublished work in progress, September 1996.
            http://www.mid-way.org/doc/ttcp-sec.txt
 [KBC2005]  Kohno, T., Broido, A., and K. C. Claffy, "Remote physical
            device fingerprinting", IEEE Symposium on Security and
            Privacy, May 2005.  http://www.caida.org/
            outreach/papers/2005/fingerprinting/
            KohnoBroidoClaffy05-devicefingerprinting.pdf
 [KS1995]   Karn, P. and W. Simpson, "The Photuris Session Key
            Management Protocol", March 1995.
            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 2008.
 [MAF2004]  Medina, A., Allman, M., and S. Floyd, "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

Simpson Experimental [Page 34] RFC 6013 TCP Cookie Transactions January 2011

 [Metzger1996]
            Metzger, P., "Re: SYN floods (was: does history repeat
            itself?)", September 9, 1996.
            http://www.merit.net/mail.archives/nanog/
            1996-09/msg00235.html
 [Metzger1998]
            Metzger, P., "Re: what a new TCP header might look like",
            May 12, 1998.  ftp://ftp.isi.edu/end2end/end2end-
            interest-1998.mail
 [Morris1985]
            Morris, R., "A Weakness in the 4.2BSD Unix TCP/IP
            Software", Technical Report CSTR-117, AT&T Bell
            Laboratories, February 1985.
            http://pdos.csail.mit.edu/~rtm/papers/117.pdf
 [MSV2009]  Metzger, P., Simpson, W., and P. Vixie, "Improving TCP
            Security With Robust Cookies", Usenix ;login:, December
            2009.  http://www.usenix.org/publications/login/
            2009-12/openpdfs/metzger.pdf
 [Phrack1998]
            route|daemon9, "T/TCP vulnerabilities", Phrack Magazine,
            Volume 8, Issue 53, July 8, 1998.
            http://www.phrack.org/issues.html?issue=53&id=6
 [RFC1379]  Braden, R., "Extending TCP for Transactions -- Concepts",
            RFC 1379, November 1992.
 [RFC1644]  Braden, R., "T/TCP -- TCP Extensions for Transactions
            Functional Specification", RFC 1644, July 1994.
 [RFC2385]  Heffernan, A., "Protection of BGP Sessions via the TCP MD5
            Signature Option", RFC 2385, August 1998.
 [RFC2522]  Karn, P. and W. Simpson, "Photuris: Session-Key Management
            Protocol", RFC 2522, March 1999.
 [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
            Defeating Denial of Service Attacks which employ IP Source
            Address Spoofing", BCP 38, RFC 2827, May 2000.
 [RFC2960]  Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
            Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
            Zhang, L., and V. Paxson, "Stream Control Transmission
            Protocol", RFC 2960, October 2000.

Simpson Experimental [Page 35] RFC 6013 TCP Cookie Transactions January 2011

 [RFC3022]  Srisuresh, P. and K. Egevang, "Traditional IP Network
            Address Translator (Traditional NAT)", RFC 3022, January
            2001.
 [RFC3234]  Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
            Issues", RFC 3234, February 2002.
 [RFC3309]  Stone, J., Stewart, R., and D. Otis, "Stream Control
            Transmission Protocol (SCTP) Checksum Change", RFC 3309,
            September 2002.
 [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
            Text on Security Considerations", BCP 72, RFC 3552, July
            2003.
 [RFC3692]  Narten, T., "Assigning Experimental and Testing Numbers
            Considered Useful", BCP 82, RFC 3692, January 2004.
 [RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
            Networks", BCP 84, RFC 3704, March 2004.
 [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
            "Randomness Requirements for Security", BCP 106, RFC 4086,
            June 2005.
 [RFC4340]  Kohler, E., Handley, M., and S. Floyd, "Datagram
            Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
 [RFC4727]  Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4,
            ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.
 [RFC4732]  Handley, M., Ed., Rescorla, E., Ed., and Internet
            Architecture Board, "Internet Denial-of-Service
            Considerations", RFC 4732, November 2006.
 [RFC4953]  Touch, J., "Defending TCP Against Spoofing Attacks", RFC
            4953, July 2007.
 [RFC4960]  Stewart, R., Ed., "Stream Control Transmission Protocol",
            RFC 4960, September 2007.
 [RFC4987]  Eddy, W., "TCP SYN Flooding Attacks and Common
            Mitigations", RFC 4987, August 2007.
 [RFC5077]  Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
            "Transport Layer Security (TLS) Session Resumption without
            Server-Side State", RFC 5077, January 2008.

Simpson Experimental [Page 36] RFC 6013 TCP Cookie Transactions January 2011

 [RFC5358]  Damas, J. and F. Neves, "Preventing Use of Recursive
            Nameservers in Reflector Attacks", BCP 140, RFC 5358,
            October 2008.
 [RFC5925]  Touch, J., Mankin, A., and R. Bonica, "The TCP
            Authentication Option", RFC 5925, June 2010.
 [RFC6056]  Larson, M. and F. Gont, "Recommendations for Transport-
            Protocol Port Randomization", BCP 156, RFC 6056, January
            2011.
 [rfc1323bis]
            Borman, D., Braden, R., and V. Jacobson., "TCP Extensions
            for High Performance", Work in Progress, March 2009.

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
 EMail: William.Allen.Simpson@Gmail.com

Simpson Experimental [Page 37]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6013.txt · Last modified: 2011/01/21 18:12 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki