idnits 2.17.1 draft-briscoe-tcpm-echo-cookie-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 25, 2014) is 3470 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Experimental draft: draft-ietf-tcpm-fastopen (ref. 'I-D.ietf-tcpm-fastopen') ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) == Outdated reference: A later version (-01) exists of draft-briscoe-tcpm-inner-space-00 == Outdated reference: A later version (-12) exists of draft-touch-tcpm-tcp-syn-ext-opt-01 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCP Maintenance and Minor Extensions (tcpm) B. Briscoe 3 Internet-Draft BT 4 Intended status: Standards Track October 25, 2014 5 Expires: April 28, 2015 7 The Echo Cookie TCP Option 8 draft-briscoe-tcpm-echo-cookie-00 10 Abstract 12 This document specifies a TCP Option called EchoCookie. It provides 13 a single field that a TCP server can use to store opaque cookie data 14 'in flight' rather than in memory. As new TCP options are defined, 15 they can require that implementations support the EchoCookie option. 16 Then if a server's SYN queue is under pressure from a SYN flooding 17 attack, it can ask clients to echo its connection state in their 18 acknowledgement. This facility is similar to the classic SYN Cookie, 19 but it provides enough space for connection state associated with TCP 20 options. In contrast, the classic location for a SYN Cookie only 21 provides enough space for a degraded encoding of the Maximum Segment 22 Size (MSS) TCP option and no others. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 28, 2015. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Echo Cookie TCP Option . . . . . . . . . . . . . . . . . . . 3 61 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 63 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 64 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 66 6.2. Informative References . . . . . . . . . . . . . . . . . 6 67 Appendix A. Protocol Design Issues (to be Deleted before 68 Publication) . . . . . . . . . . . . . . . . . . . . 6 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 71 1. Introduction 73 In order to initiate a connection, a TCP client sends a SYN segment 74 to a TCP server. The server normally allocates memory to hold the 75 required connection state then responds with a SYN/ACK segment to the 76 address the client claims to be sending from. If a TCP server is 77 under SYN flood attack, it can resort to including a SYN Cookie in 78 the SYN/ACK [RFC4987] and not holding any connection state until the 79 client follows through with an echo of the SYN Cookie. Therefore, a 80 SYN Cookie effectively allows a TCP server to store its connection 81 state 'in flight' for a round. Then while it is testing which client 82 addresses correctly complete the handshake, it can protect its memory 83 from exhaustion. 85 The limited size of a SYN Cookie is a known limitation. SYN Cookies 86 are not standardised (and don't need to be), but typically the server 87 encodes its SYN Cookie into the 16 bits of the Initial Sequence 88 Number (ISN) [RFC0793] and the 9 least significant bits of the 89 timestamp option [RFC7323] (if supported by the client). These 90 fields are only large enough to hold a few common TCP options, such 91 as a degraded record of the client's maximum segment size (MSS), the 92 window scale option and SACK-ok. Therefore, SYN Cookies only protect 93 a rudimentary TCP connection service--they do not protect all the 94 facilities provided by TCP options during an attack. 96 These 41 bits are the only space available for SYN cookies. A server 97 can only exploit fields that it can set to any value it chooses and 98 that are naturally echoed by all (or at least most) TCP clients. 99 Ideally, the server would be able to place a cookie of any reasonable 100 size in a new generic EchoCookie TCP option on the SYN/ACK and the 101 client would be required to echo it back in the following ACK. 102 However, that would be of little use until most clients supported it. 104 A simple solution to this problem is to require that EchoCookie 105 support must be implemented with any TCP options defined from now on. 106 A new capability to extend the TCP option space on SYN/ACK segments, 107 e.g. [I-D.touch-tcpm-tcp-syn-ext-opt] or 108 [I-D.briscoe-tcpm-inner-space], could also require that the 109 EchoCookie mechanism must be implemented with it. 111 1.1. Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. These 116 words only have such normative significance when in ALL CAPS, not 117 when in lower case. 119 2. Echo Cookie TCP Option 121 If a TCP server's SYN queue is under pressure from a SYN flood 122 attack, it MAY send an EchoCookie TCP option on the SYN/ACK, instead 123 of consuming memory to hold connection state. 125 0 1 2 126 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 /| ... 127 +---------------+---------------+-----------------/ | /---------+ 128 | EchoCookie | Length | OpaqueCookie /||/ ... | 129 +---------------+---------------+----------------/ | /----------+ 130 |/ 132 Figure 1: The EchoCookie TCP Option 134 The general structure of TCP options is defined in [RFC0793]. The 135 EchoCookie TCP option is defined in Figure 1. The Option Kind is 136 EchoCookie with value {ToDo: Value TBA}. The Length in octets can be 137 any value greater than 1. 139 The OpaqueCookie field is available for the sender to fill with any 140 amount of any type of data it wishes to store in the cookie, only 141 constrained in size to an integer number of octets. 143 When a TCP receiver acknowledges a segment carrying an EchoCookie 144 option, it MUST return an EchoCookie TCP option carrying an identical 145 OpaqueCookie. 147 The mechanism a server uses to determine whether the echoed contents 148 of the cookie are the same as the contents it sent are implementation 149 dependent and do not need to be standardised. 151 The EchoCookie option with length greater than 2 is only defined on a 152 SYN/ACK or on the ACK in response. 154 A client MAY send an empty EchoCookie TCP option with Length=2 on the 155 SYN, to indicate that it supports the EchoCookie facility. This will 156 not be necessary if support is implied by some other means (e.g. use 157 of the Inner Space protocol [I-D.briscoe-tcpm-inner-space] implies 158 support for EchoCookie). 160 If there is any TCP Payload in the SYN, it will never be necessary to 161 include this data in a subsequent Echo Cookie. Not acknowledging the 162 data would be sufficient to get the client to retransmit it. 164 If the client sends a valid TCP Fast Open (TFO) cookie 165 [I-D.ietf-tcpm-fastopen] on the SYN of a resumed connection, there 166 will be no need to defer establishing the connection by responding 167 with an EchoCookie, because the client source address is already 168 known to the server. 170 3. IANA Considerations 172 This specification requires IANA to allocate a value from the TCP 173 Option Kind name-space against the name: 175 "EchoCookie" 177 Early implementation before the IANA allocation MUST follow [RFC6994] 178 and use experimental option 254 and respective Experiment ID: 180 0xEEEE (16 bits); 182 {ToDo: Instead it might be prudent/possible for initial experiments 183 to reuse Option Kinds 6 and/or 7 defined by RFC 1072 (Oct 1988) for a 184 4-octet Echo and Echo Reply facility that was superceded by the 185 combined Echo and Reply facility in the Timestamp option of RFC1323 186 (May 1992) and formally obsoleted by RFC6247 (May 2011). Then if the 187 experiments find that no legacy implementations recognise these 188 options it can re-use them to avoid consuming new Option Kind 189 values.} 190 {ToDo: Values TBA and register them with IANA} then migrate to the 191 assigned option after allocation.} 193 4. Security Considerations 195 If the cookie holds state that was negotiated over a secure 196 connection, it MUST be echoed with the same or a stronger level of 197 security. 199 A SYN/ACK carrying an EchoCookie request MUST NOT exceed the size of 200 the TCP SYN that preceded it. This ensures that the EchoCookie 201 defence cannot amplify an attack by reflection. 203 A server may record a random selection of the clients to which it 204 responds with an EchoCookie option. Then it can detect if a spoof 205 client is mounting a reflection attack, by repeatedly asking the 206 server to send a SYN/ACK to the same victim client that rarely or 207 never responds. In such a case the server SHOULD limit the frequency 208 at which it responds to such a client. 210 {ToDo: More?} 212 5. Acknowledgements 214 Bob Briscoe's contribution is part-funded by the European Community 215 under its Seventh Framework Programme through the Trilogy 2 project 216 (ICT-317756). The views expressed here are solely those of the 217 author. 219 6. References 221 6.1. Normative References 223 [I-D.ietf-tcpm-fastopen] 224 Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 225 Fast Open", draft-ietf-tcpm-fastopen-10 (work in 226 progress), September 2014. 228 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 229 793, September 1981. 231 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 232 Requirement Levels", BCP 14, RFC 2119, March 1997. 234 [RFC6994] Touch, J., "Shared Use of Experimental TCP Options", RFC 235 6994, August 2013. 237 6.2. Informative References 239 [I-D.briscoe-tcpm-inner-space] 240 Briscoe, B., "Inner Space for TCP Options", draft-briscoe- 241 tcpm-inner-space-00 (work in progress), October 2014. 243 [I-D.touch-tcpm-tcp-syn-ext-opt] 244 Touch, J. and T. Faber, "TCP SYN Extended Option Space 245 Using an Out-of-Band Segment", draft-touch-tcpm-tcp-syn- 246 ext-opt-01 (work in progress), September 2014. 248 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 249 Mitigations", RFC 4987, August 2007. 251 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. 252 Scheffenegger, "TCP Extensions for High Performance", RFC 253 7323, September 2014. 255 Appendix A. Protocol Design Issues (to be Deleted before Publication) 257 This appendix is informative, not normative. It records outstanding 258 issues with the protocol design that will need to be resolved before 259 publication. 261 Why limit to SYN/ACK? {ToDo: Consider whether it is OK to generalise 262 EchoCookie with Length > 2 to any segment from client or server 263 (except the SYN, which would create a vulnerability to reflection 264 attacks), especially the FIN, FIN/ACK etc.. It may even be 265 possible to generalise this to cover TFO.} 267 Author's Address 269 Bob Briscoe 270 BT 271 B54/77, Adastral Park 272 Martlesham Heath 273 Ipswich IP5 3RE 274 UK 276 Phone: +44 1473 645196 277 Email: bob.briscoe@bt.com 278 URI: http://bobbriscoe.net/