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

Versions: 00

TCP Maintenance and Minor Extensions (tcpm)                   B. Briscoe
Internet-Draft                                                        BT
Intended status: Standards Track                        October 25, 2014
Expires: April 28, 2015

                       The Echo Cookie TCP Option


   This document specifies a TCP Option called EchoCookie.  It provides
   a single field that a TCP server can use to store opaque cookie data
   'in flight' rather than in memory.  As new TCP options are defined,
   they can require that implementations support the EchoCookie option.
   Then if a server's SYN queue is under pressure from a SYN flooding
   attack, it can ask clients to echo its connection state in their
   acknowledgement.  This facility is similar to the classic SYN Cookie,
   but it provides enough space for connection state associated with TCP
   options.  In contrast, the classic location for a SYN Cookie only
   provides enough space for a degraded encoding of the Maximum Segment
   Size (MSS) TCP option and no others.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 28, 2015.

Copyright Notice

   Copyright (c) 2014 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

Briscoe                  Expires April 28, 2015                 [Page 1]

Internet-Draft         The Echo Cookie TCP Option           October 2014

   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Echo Cookie TCP Option  . . . . . . . . . . . . . . . . . . .   3
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Appendix A.  Protocol Design Issues (to be Deleted before
                Publication) . . . . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   In order to initiate a connection, a TCP client sends a SYN segment
   to a TCP server.  The server normally allocates memory to hold the
   required connection state then responds with a SYN/ACK segment to the
   address the client claims to be sending from.  If a TCP server is
   under SYN flood attack, it can resort to including a SYN Cookie in
   the SYN/ACK [RFC4987] and not holding any connection state until the
   client follows through with an echo of the SYN Cookie.  Therefore, a
   SYN Cookie effectively allows a TCP server to store its connection
   state 'in flight' for a round.  Then while it is testing which client
   addresses correctly complete the handshake, it can protect its memory
   from exhaustion.

   The limited size of a SYN Cookie is a known limitation.  SYN Cookies
   are not standardised (and don't need to be), but typically the server
   encodes its SYN Cookie into the 16 bits of the Initial Sequence
   Number (ISN) [RFC0793] and the 9 least significant bits of the
   timestamp option [RFC7323] (if supported by the client).  These
   fields are only large enough to hold a few common TCP options, such
   as a degraded record of the client's maximum segment size (MSS), the
   window scale option and SACK-ok.  Therefore, SYN Cookies only protect
   a rudimentary TCP connection service--they do not protect all the
   facilities provided by TCP options during an attack.

Briscoe                  Expires April 28, 2015                 [Page 2]

Internet-Draft         The Echo Cookie TCP Option           October 2014

   These 41 bits are the only space available for SYN cookies.  A server
   can only exploit fields that it can set to any value it chooses and
   that are naturally echoed by all (or at least most) TCP clients.
   Ideally, the server would be able to place a cookie of any reasonable
   size in a new generic EchoCookie TCP option on the SYN/ACK and the
   client would be required to echo it back in the following ACK.
   However, that would be of little use until most clients supported it.

   A simple solution to this problem is to require that EchoCookie
   support must be implemented with any TCP options defined from now on.
   A new capability to extend the TCP option space on SYN/ACK segments,
   e.g.  [I-D.touch-tcpm-tcp-syn-ext-opt] or
   [I-D.briscoe-tcpm-inner-space], could also require that the
   EchoCookie mechanism must be implemented with it.

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].  These
   words only have such normative significance when in ALL CAPS, not
   when in lower case.

2.  Echo Cookie TCP Option

   If a TCP server's SYN queue is under pressure from a SYN flood
   attack, it MAY send an EchoCookie TCP option on the SYN/ACK, instead
   of consuming memory to hold connection state.

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3   /|   ...
   +---------------+---------------+-----------------/ | /---------+
   |  EchoCookie   |    Length     |  OpaqueCookie   /||/  ...     |
   +---------------+---------------+----------------/ | /----------+

                    Figure 1: The EchoCookie TCP Option

   The general structure of TCP options is defined in [RFC0793].  The
   EchoCookie TCP option is defined in Figure 1.  The Option Kind is
   EchoCookie with value {ToDo: Value TBA}. The Length in octets can be
   any value greater than 1.

   The OpaqueCookie field is available for the sender to fill with any
   amount of any type of data it wishes to store in the cookie, only
   constrained in size to an integer number of octets.

Briscoe                  Expires April 28, 2015                 [Page 3]

Internet-Draft         The Echo Cookie TCP Option           October 2014

   When a TCP receiver acknowledges a segment carrying an EchoCookie
   option, it MUST return an EchoCookie TCP option carrying an identical

   The mechanism a server uses to determine whether the echoed contents
   of the cookie are the same as the contents it sent are implementation
   dependent and do not need to be standardised.

   The EchoCookie option with length greater than 2 is only defined on a
   SYN/ACK or on the ACK in response.

   A client MAY send an empty EchoCookie TCP option with Length=2 on the
   SYN, to indicate that it supports the EchoCookie facility.  This will
   not be necessary if support is implied by some other means (e.g. use
   of the Inner Space protocol [I-D.briscoe-tcpm-inner-space] implies
   support for EchoCookie).

   If there is any TCP Payload in the SYN, it will never be necessary to
   include this data in a subsequent Echo Cookie.  Not acknowledging the
   data would be sufficient to get the client to retransmit it.

   If the client sends a valid TCP Fast Open (TFO) cookie
   [I-D.ietf-tcpm-fastopen] on the SYN of a resumed connection, there
   will be no need to defer establishing the connection by responding
   with an EchoCookie, because the client source address is already
   known to the server.

3.  IANA Considerations

   This specification requires IANA to allocate a value from the TCP
   Option Kind name-space against the name:


   Early implementation before the IANA allocation MUST follow [RFC6994]
   and use experimental option 254 and respective Experiment ID:

      0xEEEE (16 bits);

   {ToDo: Instead it might be prudent/possible for initial experiments
   to reuse Option Kinds 6 and/or 7 defined by RFC 1072 (Oct 1988) for a
   4-octet Echo and Echo Reply facility that was superceded by the
   combined Echo and Reply facility in the Timestamp option of RFC1323
   (May 1992) and formally obsoleted by RFC6247 (May 2011).  Then if the
   experiments find that no legacy implementations recognise these
   options it can re-use them to avoid consuming new Option Kind

Briscoe                  Expires April 28, 2015                 [Page 4]

Internet-Draft         The Echo Cookie TCP Option           October 2014

   {ToDo: Values TBA and register them with IANA} then migrate to the
   assigned option after allocation.}

4.  Security Considerations

   If the cookie holds state that was negotiated over a secure
   connection, it MUST be echoed with the same or a stronger level of

   A SYN/ACK carrying an EchoCookie request MUST NOT exceed the size of
   the TCP SYN that preceded it.  This ensures that the EchoCookie
   defence cannot amplify an attack by reflection.

   A server may record a random selection of the clients to which it
   responds with an EchoCookie option.  Then it can detect if a spoof
   client is mounting a reflection attack, by repeatedly asking the
   server to send a SYN/ACK to the same victim client that rarely or
   never responds.  In such a case the server SHOULD limit the frequency
   at which it responds to such a client.

   {ToDo: More?}

5.  Acknowledgements

   Bob Briscoe's contribution is part-funded by the European Community
   under its Seventh Framework Programme through the Trilogy 2 project
   (ICT-317756).  The views expressed here are solely those of the

6.  References

6.1.  Normative References

              Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
              Fast Open", draft-ietf-tcpm-fastopen-10 (work in
              progress), September 2014.

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7, RFC
              793, September 1981.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC6994]  Touch, J., "Shared Use of Experimental TCP Options", RFC
              6994, August 2013.

Briscoe                  Expires April 28, 2015                 [Page 5]

Internet-Draft         The Echo Cookie TCP Option           October 2014

6.2.  Informative References

              Briscoe, B., "Inner Space for TCP Options", draft-briscoe-
              tcpm-inner-space-00 (work in progress), October 2014.

              Touch, J. and T. Faber, "TCP SYN Extended Option Space
              Using an Out-of-Band Segment", draft-touch-tcpm-tcp-syn-
              ext-opt-01 (work in progress), September 2014.

   [RFC4987]  Eddy, W., "TCP SYN Flooding Attacks and Common
              Mitigations", RFC 4987, August 2007.

   [RFC7323]  Borman, D., Braden, B., Jacobson, V., and R.
              Scheffenegger, "TCP Extensions for High Performance", RFC
              7323, September 2014.

Appendix A.  Protocol Design Issues (to be Deleted before Publication)

   This appendix is informative, not normative.  It records outstanding
   issues with the protocol design that will need to be resolved before

   Why limit to SYN/ACK?  {ToDo: Consider whether it is OK to generalise
      EchoCookie with Length > 2 to any segment from client or server
      (except the SYN, which would create a vulnerability to reflection
      attacks), especially the FIN, FIN/ACK etc.. It may even be
      possible to generalise this to cover TFO.}

Author's Address

   Bob Briscoe
   B54/77, Adastral Park
   Martlesham Heath
   Ipswich  IP5 3RE

   Phone: +44 1473 645196
   Email: bob.briscoe@bt.com
   URI:   http://bobbriscoe.net/

Briscoe                  Expires April 28, 2015                 [Page 6]

Html markup produced by rfcmarkup 1.121, available from https://tools.ietf.org/tools/rfcmarkup/