doc: Add RFC documents

1 files changed, 2075 insertions, 0 deletions

diff --git a/doc/rfc/rfc6013.txt b/doc/rfc/rfc6013.txt
new file mode 100644
index 0000000..5da6bbd
--- /dev/null
+++ b/doc/rfc/rfc6013.txt
@@ -0,0 +1,2075 @@
+
+
+
+
+
+
+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]
+