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 draft-briscoe-tcpm-echo-cookie-00 Abstract 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", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 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 OpaqueCookie. 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: "EchoCookie" 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 values.} 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 security. 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 author. 6. References 6.1. Normative References [I-D.ietf-tcpm-fastopen] 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 [I-D.briscoe-tcpm-inner-space] Briscoe, B., "Inner Space for TCP Options", draft-briscoe- tcpm-inner-space-00 (work in progress), October 2014. [I-D.touch-tcpm-tcp-syn-ext-opt] 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 publication. 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 BT B54/77, Adastral Park Martlesham Heath Ipswich IP5 3RE UK Phone: +44 1473 645196 Email: bob.briscoe@bt.com URI: http://bobbriscoe.net/ Briscoe Expires April 28, 2015 [Page 6]