One document matched: draft-briscoe-tcpm-echo-cookie-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC0793 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0793.xml">
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4987 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4987.xml">
<!ENTITY RFC6994 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6994.xml">
<!ENTITY RFC7323 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7323.xml">
<!ENTITY I-D.ietf-tcpm-fastopen SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tcpm-fastopen.xml">
<!ENTITY I-D.briscoe-tcpm-inner-space SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.briscoe-tcpm-inner-space.xml">
<!ENTITY I-D.touch-tcpm-tcp-syn-ext-opt SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.touch-tcpm-tcp-syn-ext-opt.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-briscoe-tcpm-echo-cookie-00"
ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
or pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="The Echo Cookie TCP Option">The Echo Cookie TCP
Option</title>
<author fullname="Bob Briscoe" initials="B." surname="Briscoe">
<organization>BT</organization>
<address>
<postal>
<street>B54/77, Adastral Park</street>
<street>Martlesham Heath</street>
<city>Ipswich</city>
<code>IP5 3RE</code>
<country>UK</country>
</postal>
<phone>+44 1473 645196</phone>
<email>bob.briscoe@bt.com</email>
<uri>http://bobbriscoe.net/</uri>
</address>
</author>
<date day="25" month="October" year="2014"/>
<area>Transport</area>
<workgroup>TCP Maintenance and Minor Extensions (tcpm)</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>I-D</keyword>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>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
<xref target="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.</t>
<t>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) <xref target="RFC0793"/> and the 9 least significant bits of the
timestamp option <xref target="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.</t>
<t>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.</t>
<t>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.
<xref target="I-D.touch-tcpm-tcp-syn-ext-opt"/> or <xref
target="I-D.briscoe-tcpm-inner-space"/>, could also require that the
EchoCookie mechanism must be implemented with it.</t>
<section anchor="inspace_Terminology" title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"/>. These words only have such normative significance
when in ALL CAPS, not when in lower case.</t>
</section>
</section>
<section anchor="inspace_SYN_Cookie" title="Echo Cookie TCP Option">
<t>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.</t>
<figure align="center" anchor="inspace_Fig_Cookie"
title="The EchoCookie TCP Option">
<artwork><![CDATA[ 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 /||/ ... |
+---------------+---------------+----------------/ | /----------+
|/
]]></artwork>
</figure>
<t>The general structure of TCP options is defined in <xref
target="RFC0793"/>. The EchoCookie TCP option is defined in <xref
target="inspace_Fig_Cookie"/>. The Option Kind is EchoCookie with value
{ToDo: Value TBA}. The Length in octets can be any value greater than
1.</t>
<t>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. </t>
<t>When a TCP receiver acknowledges a segment carrying an EchoCookie
option, it MUST return an EchoCookie TCP option carrying an identical
OpaqueCookie.</t>
<t>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.</t>
<t>The EchoCookie option with length greater than 2 is only defined on a
SYN/ACK or on the ACK in response.</t>
<t>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 <xref target="I-D.briscoe-tcpm-inner-space"/>
implies support for EchoCookie).</t>
<t>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.</t>
<t>If the client sends a valid TCP Fast Open (TFO) cookie <xref
target="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.</t>
</section>
<section anchor="inspace_IANA" title="IANA Considerations">
<t>This specification requires IANA to allocate a value from the TCP
Option Kind name-space against the name:<list style="empty">
<t>"EchoCookie"</t>
</list></t>
<t>Early implementation before the IANA allocation MUST follow <xref
target="RFC6994"/> and use experimental option 254 and respective
Experiment ID:<list style="empty">
<t>0xEEEE (16 bits);</t>
</list>{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 values.}</t>
<t>{ToDo: Values TBA and register them with IANA} then migrate to the
assigned option after allocation.}</t>
</section>
<section anchor="inspace_Security_Considerations"
title="Security Considerations">
<t>If the cookie holds state that was negotiated over a secure
connection, it MUST be echoed with the same or a stronger level of
security.</t>
<t>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.</t>
<t>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.</t>
<t>{ToDo: More?}</t>
<!--Consider whether there are new SYN flood vulnerabilities.-->
</section>
<section title="Acknowledgements">
<t>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
author.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
&RFC0793;
&RFC2119;
&RFC6994;
&I-D.ietf-tcpm-fastopen;
</references>
<references title="Informative References">
&RFC4987;
&RFC7323;
&I-D.touch-tcpm-tcp-syn-ext-opt;
&I-D.briscoe-tcpm-inner-space;
</references>
<section title="Protocol Design Issues (to be Deleted before Publication)">
<t>This appendix is informative, not normative. It records outstanding
issues with the protocol design that will need to be resolved before
publication.<list style="hanging">
<t hangText="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.}</t>
</list></t>
</section>
<!-- <section title="Change Log (to be Deleted before Publication)">
<t>A detailed version history can be accessed at
<http://datatracker.ietf.org/doc/draft-briscoe-tcpm-echo-cookie/history/></t>
<t/>
</section>
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 21:45:40 |