idnits 2.17.1 draft-simpson-tcpct-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(i) Publication Limitation clause. 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 2010) is 5182 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC 2827' is defined on line 1535, but no explicit reference was found in the text == Unused Reference: 'RFC 3704' is defined on line 1554, but no explicit reference was found in the text == Unused Reference: 'RFC 4953' is defined on line 1560, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1948 (Obsoleted by RFC 6528) ** Obsolete normative reference: RFC 2988 (Obsoleted by RFC 6298) ** Obsolete normative reference: RFC 1700 (ref. 'RFC 3232') (Obsoleted by RFC 3232) -- No information found for draft-karn-photuris - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 1379 (Obsoleted by RFC 6247) -- Obsolete informational reference (is this intentional?): RFC 1644 (Obsoleted by RFC 6247) -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 2960 (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 3309 (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT W A Simpson 3 DayDreamer 4 Intended status: Experimental February 2010 6 TCP Cookie Transactions (TCPCT) 7 draft-simpson-tcpct-00 9 Abstract 11 TCP Cookie Transactions (TCPCT) deter spoofing of connections and 12 prevent resource exhaustion, eliminating Responder (server) state 13 during the initial handshake. The Initiator (client) has sole 14 responsibility for ensuring required delays between connections. The 15 cookie exchange may carry data, limited to inhibit amplification and 16 reflection denial of service attacks. 18 Copyright Notice 20 Copyright (c) 2010 IETF Trust and the persons identified as the 21 document authors. All rights reserved. 23 This document is subject to BCP 78 and the IETF Trust's Legal 24 Provisions Relating to IETF Documents 25 (http://trustee.ietf.org/license-info) in effect on the date of 26 publication of this document. Please review these documents 27 carefully, as they describe your rights and restrictions with respect 28 to this document. 30 This document may not be modified, and derivative works of it may not 31 be created, except to format it for publication as an RFC or to 32 translate it into languages other than English. 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute working 41 documents as Internet-Drafts. The list of current Internet-Drafts is 42 at http://datatracker.ietf.org/drafts/current. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . 1 51 1.1 Terminology . . . . . . . . . . . . . . . . . . . 1 52 2. Protocol Overview . . . . . . . . . . . . . . . . . . . 2 53 2.1 Message Summary (simplified) . . . . . . . . . . . 3 54 2.2 Compatibility and Transparency . . . . . . . . . . 4 55 2.3 Fully Loaded Cookies . . . . . . . . . . . . . . . 4 56 2.4 TCP Header Extension . . . . . . . . . . . . . . . 5 57 2.5 Option Handling . . . . . . . . . . . . . . 6 58 3. Protocol Details . . . . . . . . . . . . . . . . . . . . 6 59 3.1 TCP Cookie Option . . . . . . . . . . . . . . . . 7 60 3.2 TCP Cookie-Pair Standard Option . . . . . . . . . 7 61 3.3 TCP Cookie-Pair Extended Option . . . . . . . . . 8 62 3.4 TCP Cookie-less Extension Option . . . . . . . . . 9 63 3.5 TCP Timestamps Extended Option . . . . . . . . . . 10 64 3.6 Cookie Generation . . . . . . . . . . . . . . . . 11 65 3.6.1 Initiator Cookie . . . . . . . . . . . . . . . . . 12 66 3.6.2 Responder Cookie . . . . . . . . . . . . . . . . . 12 67 3.6.3 Responder Secret Value . . . . . . . . . . . . . . 13 68 4. Cookie Exchange . . . . . . . . . . . . . . . . . . . . 14 69 4.1 Initiator . . . . . . . . . . . . . . . . . 14 70 4.2 Responder . . . . . . . . . . . . . 15 71 4.3 Initiator . . . . . . . . . . . . . . . 16 72 4.4 Responder . . . . . . . . . . . . . . . . . 16 73 4.5 Simultaneous Open . . . . . . . . . . . . . . . . 16 74 5. Accelerated Close . . . . . . . . . . . . . . . . . . . 17 75 5.1 Initiator Close . . . . . . . . . . . . . . . . . 18 76 5.2 Responder Close . . . . . . . . . . . . . . . . . 18 77 6. Accelerated Open . . . . . . . . . . . . . . . . . . . . 19 78 6.1 Initiator Data . . . . . . . . . . . . . . . 19 79 6.2 Responder Data . . . . . . . . . . 20 80 6.3 Initiator Data . . . . . . . . . . . . 21 81 6.4 Responder Data . . . . . . . . . . . . . . . 22 82 7. Advisory Reset . . . . . . . . . . . . . . . . . . . . . 22 83 8. Interactions with other options . . . . . . . . . . . . 23 84 8.1 TCP Selective Acknowledgment . . . . . . . . . . . 23 85 8.2 TCP Timestamps . . . . . . . . . . . . . . . . . . 23 86 8.3 TCP Extensions for Transactions . . . . . . . . . 23 87 8.4 TCP MD5 Signature . . . . . . . . . . . . . . . . 23 88 8.5 TCP Authentication . . . . . . . . . . . . . . . . 24 89 HISTORY . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 90 ACKNOWLEDGMENTS . . . . . . . . . . . . . . . . . . . . . . . . 25 91 IANA CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . . . 26 92 OPERATIONAL CONSIDERATIONS . . . . . . . . . . . . . . . . . . 26 93 SECURITY CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . 27 94 APPENDICES . . . . . . . . . . . . . . . . . . . . . . . . . . 28 95 A. Example headers . . . . . . . . . . . . . . . . . . . . 28 96 A.1 Example header . . . . . . . . . . . . . . . 28 97 A.2 Example with Sack . . . . . . . . . . . 29 98 A.3 Example header with 64-bit Timestamps . . . . . . 30 99 NORMATIVE REFERENCES . . . . . . . . . . . . . . . . . . . . . 31 100 INFORMATIVE REFERENCES . . . . . . . . . . . . . . . . . . . . 32 101 CONTACTS . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 103 1. Introduction 105 TCP Cookie Transactions (TCPCT) provide a cryptologically secure 106 mechanism to guard against simple flooding attacks sent with bogus IP 107 [RFC 791] Sources or TCP [RFC 793] Ports. The initial TCP 108 exchange is vulnerable to forged IP Addresses, predictable Ports, and 109 discoverable Sequence Numbers [Morris1985] [Gont2009]. 111 During connection establishment, the cookie (nonce) exchange 112 negotiates elimination of Responder (server) state. These cookies 113 are later used to inhibit premature closing of connections, and 114 reduce retention of state after the connection has terminated. 116 The cookie pair is much too large to fit with the other recommended 117 options in the maximal 60 byte TCP header (40 bytes of option space). 118 A successful option exchange signals availability of the TCP header 119 extension, adding space for additional options. 121 Also, implementations may optionally exchange limited amounts of 122 transaction data during the initial cookie exchange, reducing network 123 latency and host task context switching. 125 Finally, implementations may optionally rapidly recycle prior 126 connections. For otherwise stateless applications, this 127 transparently facilitates persistent connections and pipelining of 128 requests over each connection. 130 Many of these ideas have been previously proposed in one form or 131 another (see History and Acknowledgments sections). This 132 specification integrates these improvements into a coherent whole. 133 Further motivation and rationale is detailed in [MSV2009]. 135 1.1. Terminology 137 The key words "MAY", "MUST, "MUST NOT", "OPTIONAL", "RECOMMENDED", 138 "SHOULD", and "SHOULD NOT" in this document are to be interpreted as 139 described in [RFC 2119]. 141 2. Protocol Overview 143 The TCPCT extensions consist of several simple phases: 145 1. Each party passes a "cookie" to the other. Due to limited space, 146 only the most basic options are included. 148 The Cookie option also indicates that optional data is 149 acceptable. This data MAY be ignored by either party. 151 A Responder that understands the Cookie option remains stateless. 153 2. During the remainder of the standard TCP three-way handshake, the 154 Timestamps and Cookie-Pair options guard the exchange. 156 Other options present in the original that were successfully 157 returned in the MUST be included with the 158 . Additional options MAY also be included as desired. 160 As there is no Responder state, it has no record of acknowledging 161 previous data. Any optional data MUST be retransmitted. 163 Upon verification of the Timestamps and Cookie-Pair, the Responder 164 creates its TCB. 166 Note that the Responder returns the Cookie-Pair with its initial 167 data, but subsequent data segments need only the Timestamps. 169 3. During closing (or reset of) the TCP connection, the Timestamps 170 and Cookie-Pair options guard the exchange. 172 Upon verification of the Timestamps and Cookie-Pair, the Responder 173 removes its TCB. 175 The sequence of messages are summarized in the diagram below. 177 2.1. Message Summary (simplified) 179 Initiator Responder 180 ========= ========= 181 -> 182 base options 183 Timestamps 184 Cookie 185 [request data] 186 <- 187 base options 188 Timestamps 189 Cookie 190 [response data] 191 (stateless) 193 -> 194 full options 195 Timestamps 196 Cookie-Pair 197 [Sack(response)] 198 data 199 <- 200 full options 201 Timestamps 202 Cookie-Pair 203 data 204 (TCB state created) 205 <- 206 Timestamps 207 data 209 <- 210 Timestamps 211 Cookie-Pair 212 -> 213 Timestamps 214 Cookie-Pair 215 <- 216 Timestamps 217 Cookie-Pair 218 (TCB state removed) 219 TIME WAIT 221 2.2. Compatibility and Transparency 223 It is usually better that data arrive slowly, than not at all. 225 Many/most unmanaged middleboxes [RFC 3234] (such as stateless 226 firewalls, load balancers, intrusion detection systems, or network 227 address translators [RFC 3022]) cannot carry transport traffic other 228 than TCP and UDP. 230 Every TCP implementation MUST ignore without error any TCP option it 231 does not implement ([RFC 1122] section 4.2.2.5). In a study of the 232 effects of middleboxes on transport protocols [MAF2004], the vast 233 majority of modern TCP stacks correctly handle unknown TCP options. 234 But it is still prudent to follow the [RFC 793] "general principle of 235 robustness: be conservative in what you do, be liberal in what you 236 accept from others." 238 Therefore, for each of the extensions defined here, an extension 239 option will be sent in a segment only after the 240 corresponding option was received in the original segment. 242 Furthermore, TCP options will be sent on later segments only after an 243 exchange of options has indicated that both parties understand the 244 extension (see [rfc1323bis] and its antecedants). 246 Unfortunately, not all middleware adheres to these long-standing 247 requirements. Instead, unknown options are copied to the 248 . This is indistinguishable from a Monkey in the 249 Middle (MITM) reflection attack. 251 2.3. Fully Loaded Cookies 253 One Kind to aid them all, One Kind to find them, 254 One Kind to hold them all and in the header bind them. 256 The cookie exchange provides a singular opportunity to extend TCP in 257 a backward compatible manner. Semantics for the option have been 258 "overloaded" with a baker's dozen capabilities and facilities. 260 A. First and foremost, the cookie exchange improves operational 261 security for vulnerable servers against flooding attacks. The 262 cookie exchange indicates that the Responder (server) will discard 263 its initial state. All other semantics are subordinate. 265 B. Together with Sequence and Timestamp values, Cookie values protect 266 against insertion and reflection attacks. 268 C. Cookie values allow applications to detect replay attacks. 270 D. Cookie values MAY be used as an index or nonce for application 271 security protocols. This facility is outside the scope of this 272 specification. 274 E. The and MAY carry application data. This 275 feature is entirely optional, and data is not guaranteed to pass 276 successfully through middleware. Nor are the parties guaranteed 277 to process this data without changes to the Application Program 278 Interface (API). Such changes are outside the scope of this 279 specification. 281 F. The size of the cookies precludes most other options in the 282 standard TCP header space. The cookie exchange negotiates TCP 283 header extension. 285 G. The cookie exchange and resulting TCP header extension permit 286 negotiation of the 64-bit Timestamps extended option for paths 287 with large bandwidth-delay products. 289 H. TCP header extension frees some space for additional options. 291 I. Previously -only options can be updated. 293 J. The cookie exchange indicates agreement to use accelerated close. 295 K. The cookie exchange indicates agreement that only the Initiator 296 (client) handles TIME-WAIT state. 298 L. The Timestamps and Cookie-Pair combination inhibits third parties 299 from disrupting communications with and . 301 M. The Timestamps and Cookie-Pair combination facilitates rapid reuse 302 of the TCP Source Port with a common destination. 304 2.4. TCP Header Extension 306 Once the Cookie option has been successfully exchanged, TCP header 307 extension is permitted. The 64-bit Timestamps extended option or the 308 Cookie-Pair extended option MUST be used to indicate the presence of 309 the header extension. 311 Validation of these known values protects against data corruption by 312 misbehaving middleboxes. 314 2.5. Option Handling 316 As the Responder retains no state after the initial TCP 317 exchange, all options present in the original MUST be repeated. 319 For example, an option defined in the [RFC 793] original 320 specification -- Maximum Segment Size (MSS) -- previously appeared 321 only in a bearing segment (including ). If 322 present, MSS will be repeated in the Initiator , together 323 with any additional options. 325 Generally, the Initiator MAY propose SYN-only options -- such as MSS 326 -- anytime both Timestamps and Cookie-Pair options are present. 327 These options are treated the same as with an original . The 328 Responder acknowledges using a subsequent segment containing 329 both Timestamps and Cookie-Pair options (similar to 330 processing). 332 This facility allows previously SYN-only options to be updated from 333 time to time. They take effect upon receipt. 335 However, segments without data will not be delivered reliably. 336 Any otherwise SYN-only options sent without data MUST be 337 retransmitted with successive segments until sent with data (or 338 ), and an is received. 340 3. Protocol Details 342 Another solution [RFC 5452] describes use of an unpredictable Source 343 Port. That is RECOMMENDED by this specification. See [LG2010] for 344 further information. 346 An earlier solution [RFC 1948] describes an unpredictable Initial 347 Sequence Number (ISN). That is REQUIRED by this specification. 349 Support for the (32-bit) TCP Timestamps Option [rfc1323bis] is 350 REQUIRED. The TSoffset MUST be randomized on a per-connection basis. 351 The Don't Fragment (DF) bit MUST be set in the IP header. 353 The TCP User Timeout Option [RFC 5482] is RECOMMENDED. 355 For examples, see Appendix A. 357 3.1. TCP Cookie Option 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Kind | Length | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | | 363 ~ Cookie ~ 364 | | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 Kind 1 byte. 31 (testing 253). 369 Length 1 byte. 10 to 18 (bytes), limited by remaining 370 space in the options field. The number MUST be 371 even. The cookie is a multiple of 16-bits. 373 Cookie 8 to 16 bytes (Length - 2). An unpredictable value. 375 Options with invalid Length values MUST be ignored. The minimum 376 Cookie size is 64-bits. If there is not sufficient space for a 377 64-bit cookie, this option MUST NOT be used. 379 The Responder Cookie MUST be the same size as the Initiator Cookie. 380 The cookie pair is a multiple of 32-bits. 382 Although the diagram shows a cookie aligned on 32-bit boundaries, 383 that is not required. 385 3.2. TCP Cookie-Pair Standard Option 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Kind | Length | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | | 391 ~ Initiator-Cookie ~ 392 | | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | | 395 ~ Responder-Cookie ~ 396 | | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 Kind 1 byte. 31 (testing 253). 401 Length 1 byte. 18 to 34 (bytes). The number MUST be even. 402 The cookie pair is a multiple of 32-bits. 404 Initiator-Cookie 8 to 16 bytes, from the original . 406 Responder-Cookie 8 to 16 bytes, from the . 408 The Cookie-Pair standard option only appears after the Timestamps 409 extended option (below). 411 Options with invalid Length values MUST be ignored. As the minimum 412 Initiator-Cookie size is 64-bits, the minimum cookie pair is 128-bits 413 (64-bits followed by 64-bits), while the maximum is 256-bits 414 (128-bits followed by 128-bits). 416 Only one instance is permitted of either the Cookie or Cookie-Pair 417 option(s). Segments with duplicative or mutually exclusive options 418 MUST be silently discarded. 420 3.3. TCP Cookie-Pair Extended Option 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Kind | Length | Extend | Zero | Size | 424 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 425 | | 426 ~ Initiator-Cookie ~ 427 | | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | | 430 ~ Responder-Cookie ~ 431 | | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 Kind 1 byte. 31 (testing 253). 436 Length 1 byte. 4 (constant). This distinguishes the 437 option from other Cookie options. 439 Extend 1 byte. 4 to 255, the data offset (in 32-bit words) 440 following the standard TCP header. Note the value 441 MUST be greater than or equal to Size. 443 Zero 4 bits. Reserved. Must be zero. 445 Size 4 bits. 4 to 8, the number of 32-bit words in the 446 cookie pair. 448 Initiator-Cookie 8 to 16 bytes, from the original . 450 Responder-Cookie 8 to 16 bytes, from the . 452 The full cookie pair follows the TCP header (indicated by +=+ 453 delimiters) and maintains 32-bit alignment. 455 This TCP header extension is ignored for sequence number 456 computations. The Sequence Number of the first byte of segment data 457 will be the Initial Sequence Number (ISN) plus one (1) for the . 459 Segments with invalid Extend or Size values MUST be silently 460 discarded. As the minimum Initiator-Cookie size is 64-bits, the 461 minimum cookie pair is 128-bits (64-bits followed by 64-bits), while 462 the maximum is 256-bits (128-bits followed by 128-bits). 464 Only one instance is permitted of either the Cookie or Cookie-Pair 465 option(s). Segments with duplicative or mutually exclusive options 466 MUST be silently discarded. 468 Implementation Notes: 470 When the Timestamps extended option (below) is present, the 471 Cookie-Pair standard option (above) is used instead. 473 3.4. TCP Cookie-less Extension Option 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | Kind | Length | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 Kind 1 byte. 31 (testing 253). 481 Length 1 byte. 2 (constant). This distinguishes the 482 option from other Cookie options. 484 Although no cookie is attached, this indicates that other features of 485 this specification are available, including TCP header extension, 486 Accelerated Close, Accelerated Open, and Advisory Reset. This is 487 intended for use with TCP authentication options. 489 3.5. TCP Timestamps Extended Option 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Kind | Length | Extend | 493 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 494 | | 495 + TS Value + 496 | | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | | 499 + TS Echo Reply + 500 | | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 Kind 1 byte. 32 (testing 254). 505 Length 1 byte. 3 (constant). 507 Extend 1 byte. 9 to 255, the data offset (in 32-bit words) 508 following the standard TCP header. Note the value 509 MUST include the timestamp values, plus the 510 following Cookie-Pair standard option. 512 TS Value 8 bytes. The current value of the timestamp for the 513 sender. 515 TS Echo Reply 8 bytes. A copy of the most recently received TS 516 Value. 518 The full timestamp pair follows the TCP header (indicated by +=+ 519 delimiters) and maintains 32-bit alignment. 521 This TCP header extension is ignored for sequence number 522 computations. The Sequence Number of the first byte of segment data 523 will be the Initial Sequence Number (ISN) plus one (1) for the . 525 Every TCPCT implementation MUST recognize a Timestamps extended 526 option. These 64-bit timestamps only appear in an extended option. 528 As the Responder retains no state after the initial TCP 529 exchange, the Initiator sends either the regular or extended option 530 -- chosen by a configurable parameter, or automatically based on its 531 analysis of the bandwidth-delay product discovered through the round 532 trip time of its timestamp. The Initiator adds a random 32-bit 533 prefix to its own timestamp, and a random 32-bit prefix to the 534 Responder timestamp echo reply, sending the Timestamps extended 535 option followed by the Cookie-Pair standard option. 537 However, the Responder MAY refuse to negotiate the 64-bit Timestamps 538 extended option by returning a regular 32-bit Timestamps option 539 followed by the Cookie-Pair extended option. 541 Segments with invalid Extend values MUST be silently discarded. 543 Only one instance is permitted of either the (32-bit) Timestamps 544 regular or (64-bit) Timestamps extended option. Only one instance is 545 permitted of either the Cookie-Pair extended or Timestamps extended 546 option. Segments with duplicative or mutually exclusive options MUST 547 be silently discarded. 549 Implementation Notes: 551 Frequently, the 32-bit variant is aligned on a 32-bit boundary 552 immediately following the TCP header. The following data is 553 aligned on a 64-bit boundary. 555 When this option is aligned on a 32-bit boundary immediately 556 following the TCP header, these fields are also 64-bit aligned. 557 The following data is aligned on a 64-bit boundary. 559 3.6. Cookie Generation 561 The technique by which a party generates a cookie is implementation 562 dependent. The method chosen must satisfy some basic requirements: 564 1. The cookie MUST depend on the specific parties. This prevents an 565 attacker from obtaining a cookie using a real IP address and TCP 566 port, and then using it to swamp the victim with requests from 567 randomly chosen IP addresses or ports. 569 2. It MUST NOT be possible for anyone other than the issuing entity 570 to generate cookies that will be accepted by that entity. This 571 implies that the issuing entity will use local secret information 572 in the generation and subsequent verification of a cookie. It 573 must not be possible to deduce this secret information from any 574 particular cookie. 576 3. The cookie generation and verification methods MUST be fast to 577 thwart attacks intended to sabotage CPU resources. 579 A recommended technique is to use a cryptographic hashing function. 581 An incoming cookie can be verified at any time by regenerating it 582 locally from values contained in the incoming datagram and the local 583 secret random value. 585 3.6.1. Initiator Cookie 587 The Initiator secret value that affects its cookie SHOULD change for 588 each new exchange, and is thereafter internally cached on a per TCB 589 basis. This provides improved synchronization and protection against 590 replay attacks. 592 An alternative is to cache the cookie instead of the secret value. 593 Incoming cookies can be compared directly without the computational 594 cost of regeneration. 596 It is RECOMMENDED that the cookie be calculated over the secret 597 value, the IP Source and Destination addresses, the TCP Source and 598 Destination ports, and any (optional) Initiator segment data. 600 Implementation Notes: 602 Although the recommendation includes the TCP Source port, this is 603 very implementation specific. For example, it might not be 604 included when the value is constant or unknown. 606 However, it is important that the implementation protect mutually 607 suspicious users of the same system from generating the same 608 cookie. 610 3.6.2. Responder Cookie 612 The Responder secret value that affects its cookies remains the same 613 for many different Initiators. However, this secret SHOULD be 614 changed periodically to limit the time for use of its cookies 615 (typically each 600 seconds). 617 The Responder-Cookie MUST include its own TCP Sequence and 618 Acknowledgment Numbers, its own TCP Timestamps value, and the 619 Initiator-Cookie value. This provides improved synchronization and 620 protection against replay attacks. 622 It is RECOMMENDED that the cookie be calculated over the secret 623 value, the IP Source and Destination addresses, its own TCP 624 Destination port (that is, the incoming Source port), its own TCP 625 Sequence and Acknowledgment Numbers (after updating values), and the 626 Initiator-Cookie value, followed by the secret value again. 628 The cookie is not cached per Initiator to avoid saving state during 629 the initial TCP exchange. On receipt of a TCP , the 630 Responder regenerates its cookie for validation. 632 Implementation Notes: 634 Although the recommendation does not include the TCP Source port, 635 this is very implementation specific. It might be successfully 636 included in some variants. 638 The Responder Cookie depends on the TCP Sequence and 639 Acknowledgment Numbers as they will appear for future 640 verification. The Sequence Number will be the Initial Sequence 641 Number (ISN) plus one (1) for its that will be acknowledged. 642 The Acknowledgment Number will be the Initial Sequence Number 643 (ISN) plus one (1) for the that it is now acknowledging. 645 The (32-bit) Timestamps option MUST be present, and the Kind field 646 SHOULD be included. The Initiator Timestamp Length field MAY 647 change to the extended header form; it MUST NOT be included. The 648 Initiator Timestamp value field MAY increment during the exchange; 649 it MUST NOT be included. 651 The secret value is included twice to better protect against pre- 652 calculated attacks using substitutions for variable length data. 653 Some examples using this technique are IP-MAC and H-MAC, and it is 654 likely that existing code could be shared. 656 If a Responder Cookie is identical to the Initiator Cookie, the 657 Responder SHOULD change one or more bits of its cookie to prevent 658 its accidental appearance as a reflection attack. 660 3.6.3. Responder Secret Value 662 Each Responder maintains up to two secret values concurrently for 663 efficient secret rollover. Each secret value has 4 states: 665 Generating. 666 Generates new Responder-Cookies, but not yet used for primary 667 verification. This is a short-term state, typically lasting only 668 one round trip time (RTT). 670 Primary. 671 Used both for generation and primary verification. 673 Retiring. 674 Used for verification, until the first failure that can be 675 verified by the newer Generating secret. At that time, this 676 cookie's state is changed to Secondary, and the Generating 677 cookie's state is changed to Primary. This is a short-term state, 678 typically lasting only one round trip time (RTT). 680 Secondary. 681 Used for secondary verification, after primary verification 682 failures. This state lasts no more than twice the Maximum Segment 683 Lifetime (2MSL). Then, the secret is discarded. 685 Implementation Notes: 687 Care MUST be taken to ensure that any expired secrets are promptly 688 wiped from memory, and secrets are never saved to external 689 storage. 691 The first secret after initialization begins in Primary state. 692 The system might have shutdown and restarted rapidly during the 693 previous first secret. Thus, the first secret MUST be partially 694 time dependent, to ensure that it differs from previous first 695 secrets, usually by appending a time to lengthen the first secret. 696 Those that are not the first secret SHOULD NOT include the time. 698 At the same time, there is no TCP TIME-WAIT requirement before 699 accepting connections, and there may be pent up demand for a busy 700 service. Also, there may be outstanding datagrams attempting to 701 complete an earlier cookie exchange. The first secret is likely 702 to be the weakest, as no recent entropy has been included. 704 Therefore, while terminating outstanding exchanges with the first 705 secret, a new Generating secret SHOULD be created after no more 706 than one Maximum Segment Lifetime (1MSL). Subsequent secrets 707 SHOULD be generated at the usual rate (typically 600 seconds). 709 The implementation SHOULD continually gather additional entropy 710 from checksums, cookies, timestamps, and packet arrival timing. 712 4. Cookie Exchange 714 A successful option exchange signals availability of additional 715 features. 717 4.1. Initiator 719 The Cookie exchange MAY be initiated at any time, limited only by the 720 frequency of the timestamp clock. 722 If the TCB exists from a prior (or ongoing) connection, the timestamp 723 MUST be incremented in the option. 725 The Initiator generates its unpredictable cookie value, and includes 726 the Cookie option. 728 During the initial exchange, the Initiator is solely responsible for 729 retransmission. Although the cookie, sequence, and timestamp have 730 not changed, each retransmission appears to the Responder as another 731 original . 733 Implementation Notes: 735 Sending the SHOULD NOT affect any existing TCB. This allows 736 an additional round trip time (RTT) for duplicate or out of 737 sequence segments to drain. 739 The new TCB information SHOULD be temporarily cached until a valid 740 matching arrives. Then, any old TCB values are 741 replaced. 743 4.2. Responder 745 Upon receipt of the with a Cookie option, the Responder 746 determines whether there are sufficient resources to begin another 747 connection. 749 If the TCB exists from a prior (or ongoing) connection, the timestamp 750 MUST be incremented in the option. 752 Each Sequence Number MUST be randomized [RFC 1948]. 754 The Responder generates its unpredictable cookie value, and includes 755 the Cookie option. 757 As the Responder is not required to have any TCB state, 758 retransmission timers are not available. Arrival of an Initiator's 759 retransmission appears to be an original transmission. There 760 are no differences in processing. 762 Implementation Notes: 764 Sending the MUST NOT affect any existing TCB. This 765 allows an additional round trip time (RTT) for duplicate or out of 766 sequence segments to drain. 768 This also inhibits third parties from disrupting communications. 770 4.3. Initiator 772 Upon receipt of the with a Cookie option, the 773 Initiator validates its cookie, timestamp, and corresponding 774 Acknowledgment Number. The existing TCB is updated as necessary. 776 All Initiator options are always retransmitted on this first 777 , allowing the Responder to validate its cookie and 778 establish its state. 780 This segment contains both Timestamps and Cookie-Pair options. 782 Implementation Notes: 784 A Responder Cookie identical to the Initiator Cookie MUST be 785 discarded. This is usually an indication of a Monkey in the 786 Middle (MITM) reflection attack or a seriously misconfigured 787 network, and SHOULD be logged. 789 4.4. Responder 791 Upon receipt of the with a Cookie-Pair option, the 792 Responder validates its cookie, timestamp, and corresponding 793 Acknowledgment Number, and establishes state for the connection. Any 794 existing TCB is updated as necessary. 796 This segment contains both Timestamps and Cookie-Pair options. 798 Implementation Notes: 800 An that fails to validate MUST be discarded, and SHOULD 801 be logged. 803 4.5. Simultaneous Open 805 TCP allows two parties to simultaneously initiate the connection. 806 Both parties send and receive an original without an 807 intervening [RFC 793, section 3.4, and Figure 8]. 808 Each party receives a Cookie for a connection that has also 810 issued a Cookie. 812 This condition will be unusual. The Source Port SHOULD be randomized 813 [RFC 5452], and SHOULD be chosen to differ from the Destination Port. 814 In particular, the Source Port SHOULD be greater than 1024, 815 preventing intervening network equipment from incorrectly classifying 816 the return traffic. The Destination Port is most likely to be a 817 well-known port less than 1024 [RFC 3232]. 819 In the event that these protections are insufficient, the conflict is 820 resolved in an orderly fashion: 822 a. The lesser TCP Port number becomes the Responder; 824 b. The lesser IP Address becomes the Responder; 826 c. The lesser Cookie becomes the Responder; 828 d. All of the above being equal, there is an egregiously insufficient 829 source of randomness, but both Initiators are probably present on 830 the same host: the lesser TCB memory address becomes the 831 Responder. 833 The Initiator silently discards the simultaneous . The 834 Responder revises its Cookie option, and sends the as 835 usual, but without removing its existing TCB. 837 Implementation Notes: 839 This is usually an indication of a Monkey in the Middle (MITM) 840 reflection attack or a seriously misconfigured network, and SHOULD 841 be logged. 843 5. Accelerated Close 845 Support for accelerated close is required. Accelerated close relies 846 on the presence of cookies and timestamps. This provides improved 847 synchronization and protection against replay attacks. 849 Either party MAY close with at any time. This SHOULD be 850 sent with the final data segment. 852 This segment contains both Timestamps and Cookie-Pair options. 854 When all segments preceding the have been processed and 855 acknowledged, each party SHOULD acknowledge the . 857 In general, is treated as advisory. A persistent connection 858 can be rapidly re-established. This also inhibits third parties from 859 disrupting communications. 861 Rapidly closing the connection expedites removing Responder state. 862 Any bearing segment SHOULD terminate delayed [RFC 5681]. 864 Backoff SHOULD NOT used for bearing retransmissions [RFC 2988]. 865 Instead, retransmit at the latest Timestamps estimated smoothed round 866 trip time (SRTT). 868 As the Responder retains no state after closing, a successful option 869 exchange signals the Initiator will be responsible for handling TIME- 870 WAIT state. (See [FTY1999, section 3] for previous proposal and 871 rationale.) 873 A new Cookie exchange MAY be initiated at any time. This facilitates 874 the appearance of persistent connections to intervening network 875 equipment. 877 5.1. Initiator Close 879 Upon receipt of the Initiator (and verification of the 880 Timestamps and Cookie-Pair options), the Responder sends its 881 unless there is additional data pending. In the 882 latter case, the is ignored until the data has been processed 883 and acknowledged. 885 Upon receipt of the Responder (and verification of the 886 Timestamps and Cookie-Pair options), the Initiator sends its final 887 unless there is additional data pending. The Initiator 888 enters TIME-WAIT state. 890 This segment contains both Timestamps and Cookie-Pair options. 892 Upon receipt of the Initiator (and verification of the 893 Timestamps and Cookie-Pair options), the Responder removes its TCB. 895 Upon arrival of more data prompting a new Cookie exchange, the 896 Initiator SHOULD NOT not send a final , and/or SHOULD NOT 897 wait the remaining TIME-WAIT interval. A TCB offset to the previous 898 timestamp SHOULD be incremented. The offset will be removed (with 899 the TCB itself) at the conclusion of a future TIME-WAIT state. 901 5.2. Responder Close 903 Upon receipt of the Responder (and verification of the 904 Timestamps and Cookie-Pair options), the Initiator sends its 905 unless there is additional data pending. In the 906 latter case, the is ignored until the data has been processed 907 and acknowledged. 909 Upon receipt of the Initiator (and verification of the 910 Timestamps and Cookie-Pair options), the Responder sends its final 911 and removes its TCB. 913 This segment contains both Timestamps and Cookie-Pair options. 915 If the Responder final is lost, the Responder is likely to 916 send a (as the Responder has no TCB). This distinguished 917 SHOULD copy both Timestamps and Cookie-Pair options. 919 Upon receipt of the Responder final (and verification of 920 the Timestamps and Cookie-Pair options), the Initiator enters TIME- 921 WAIT state. 923 Upon arrival of more data prompting a new Cookie exchange, the 924 Initiator SHOULD NOT not send a , and/or SHOULD NOT 925 wait the remaining TIME-WAIT interval. A TCB offset to the previous 926 timestamp SHOULD be incremented. The offset will be removed (with 927 the TCB itself) at the conclusion of a future TIME-WAIT state. 929 6. Accelerated Open 931 Support for accelerated open is OPTIONAL. 933 When an application is capable of idempotent transactions (such as a 934 query that returns a consistent result or service response heading), 935 the application sets the appropriate limit on a per port basis. 936 Applications are responsible for ensuring that retransmissions do not 937 cause duplication of data. 939 This facility allows single data segment transactions without 940 establishing TCB state at the Responder (server). For longer 941 transactions, a short look-ahead of upcoming data allows the 942 Initiator (client) to select alternatives for further processing. 944 6.1. Initiator Data 946 By default, the Initiator does not contain data. The 947 application sets the TCP_SYN_DATA_LIMIT to indicate that the 948 MAY be sent with data. 950 The Responder Maximum Segment Size (MSS) is unknown, and the default 951 MSS (536 bytes) MUST be used instead ([RFC 1122] section 4.2.2.6). 952 This is further reduced by the total length of the TCP options (in 953 this case, commonly 496 bytes). Applications MAY specify a shorter 954 limit. 956 If the data will not entirely fit within the initial segment, data 957 MUST NOT be sent until after the Responder's is 958 received. 960 Unlike T/TCP [RFC 1644], SHOULD NOT be set. This facilitates 961 the appearance of persistent connections. 963 Likewise, SHOULD NOT be set. Although the application might 964 use push to indicate that its data is ready to send, the push is 965 implied for data segments. 967 During the initial exchange, the Initiator is solely responsible for 968 retransmission. Although the cookie, sequence, and timestamp have 969 not changed, each retransmission appears to the Responder as another 970 original . 972 Implementation Notes: 974 Initiator with the Cookie option and no segment data is 975 permitted in a test environment. This combination SHOULD be 976 silently discarded. 978 Initiator with both the Cookie option and segment data 979 is similar to T/TCP [RFC 1644]. However, whenever the Responder 980 has been sent with data (there is no further 981 data expected), TCB state has not been saved at the Responder. 982 There is no need to send to close the connection. 984 6.2. Responder Data 986 By default, the Responder does not contain data. The 987 application sets the TCP_SYN_ACK_DATA_LIMIT to indicate that the 988 MAY be sent with data. 990 Segment data is limited to the Maximum Transmission Unit (MTU). 991 Applications MAY specify a shorter limit to prevent spoofed 992 amplification and reflection attacks [RFC 5358]. 994 Upon receipt of the with a Cookie option, the Responder MAY 995 process any data present. If the initial data is not accepted, the 996 Acknowledgment Number will be the received Sequence Number plus one 997 (1) for the . 999 If the segment data is the entire response (there is no further data 1000 expected), MAY be set. 1002 However, SHOULD NOT be set. Although the application might use 1003 push to indicate that its data is ready to send, the push is implied 1004 for data segments [RFC 793, section 3.7, page 41]. 1006 As the Responder is not required to have any TCB state, 1007 retransmission timers are not available. Arrival of an Initiator's 1008 retransmission appears to be an original transmission. There 1009 are no differences in processing. 1011 Implementation Notes: 1013 The Responder Cookie depends on the TCP Sequence and 1014 Acknowledgment Numbers after processing . Therefore, neither 1015 will include data. 1017 6.3. Initiator Data 1019 Upon receipt of the with a Cookie option, the 1020 Initiator MAY process any data present. In this case, the internal 1021 RCV.NXT is advanced to provide at-most-once semantics. 1023 If the segment data is the entire response (there is no further data 1024 expected), the Initiator enters TIME-WAIT state. 1026 Otherwise, original data is retransmitted in , as its 1027 processing is optional. The Acknowledgment Number will be the 1028 received Sequence Number plus one (1) for the . The Sequence 1029 Number will be the Initial Sequence Number (ISN) plus one (1) for the 1030 . 1032 Unlike T/TCP [RFC 1644], there is no implicit acknowledgment. 1034 If the Selective Acknowledgment (Sack) option [RFC 2018] has been 1035 successfully negotiated, a short Sack acknowledging the response data 1036 MAY be sent following the Cookie-Pair in the extended header. 1038 At this time, any second segment may be sent without awaiting an 1039 , according to the usual [RFC 5681] TCP congestion control 1040 process. 1042 Implementation Notes: 1044 Upon arrival of more data prompting a new Cookie exchange, there 1045 is no need to increment the previous timestamp; TCB state has not 1046 been saved at the Responder. Instead, use the saved RCV.NXT, plus 1047 one (1) for the (actual or implied) . 1049 Initiator with the Cookie-Pair option and no 1050 segment data is never required; TCB state has not been saved at 1051 the Responder. This combination MUST be silently discarded. 1053 6.4. Responder Data 1055 Upon receipt of the with a Cookie-Pair option (and 1056 verification of the Timestamps and Cookie-Pair options), the 1057 Responder SHOULD process any data present. 1059 Since the TCP Sequence and Acknowledgment Numbers have not advanced, 1060 the Responder will process the same incoming data, and transmit the 1061 same response. 1063 If the Selective Acknowledgment (Sack) option [RFC 2018] has been 1064 successfully negotiated, with a short Sack covering earlier response 1065 data, only additional unacknowledged response data is sent. 1067 At this time, any second segment may be sent without awaiting an 1068 , according to the usual [RFC 5681] TCP congestion control 1069 process. 1071 7. Advisory Reset 1073 When a TCB with matching Addresses and Ports is found, but the 1074 Cookie-Pair fails to verify, the datagram MUST be silently discarded. 1076 When no TCB with matching Addresses and Ports is found, a is 1077 sent as usual. The Timestamps option SHOULD be copied [rfc1323bis]. 1078 A Cookie-Pair option MUST also be copied. The Cookie option (or 1079 Cookie-less option) MUST NOT be copied. 1081 Any is always treated as advisory. A without a matching 1082 Cookie-Pair option could be caused by antique duplicates. Receipt 1083 has no effect on the operation of the protocol. The implementation 1084 SHOULD continue until a USER TIMEOUT expires. (See [RFC 5482] for 1085 additional information.) 1087 This also inhibits third parties from disrupting communications. 1089 8. Interactions with other options 1091 A successful Cookie (or Cookie-less) option exchange signals 1092 availability of the TCP header extension. Other options with large 1093 data portions MAY also use this feature. The extended option data is 1094 processed in the order that the options appear. 1096 8.1. TCP Selective Acknowledgment 1098 (Kind 5 [RFC 2018].) The pairs of 32-bit fields are well suited to 1099 the header extension. Because of its variable size, this is 1100 RECOMMENDED as the final extended option. 1102 During the cookie exchange, the MAY include this option to 1103 acknowledge any optional transaction response data. 1105 8.2. TCP Timestamps 1107 (Kind 8 [rfc1323bis].) Support is required. These 32-bit timestamps 1108 always appear as a regular option. 1110 8.3. TCP Extensions for Transactions 1112 (Kinds 11-13 [RFC 1644].) Incompatible with this specification, and 1113 MUST be ignored on receipt. 1115 8.4. TCP MD5 Signature 1117 (Kind 19 [RFC 2385].) The data field is well suited to header 1118 extension, as 32-bit alignment is required. However, this option is 1119 beyond the scope of this specification. 1121 The size of the option itself precludes use with the Cookie option in 1122 the . Regardless of the system default, the Cookie option MUST 1123 NOT be sent, and MUST be ignored on receipt. Instead, the Cookie- 1124 less extension option indicates that other features of this 1125 specification are available. 1127 8.5. TCP Authentication 1129 (Kind TBD.) The data field is not well suited to header extension, 1130 as there is no 32-bit alignment requirement. 1132 The size of the option itself precludes use with the Cookie option in 1133 the . Regardless of the system default, the Cookie option MUST 1134 NOT be sent, and MUST be ignored on receipt. Instead, the Cookie- 1135 less extension option indicates that other features of this 1136 specification are available. 1138 History 1140 T/TCP [RFC 1379] [RFC 1644] permits lightweight TCP transactions for 1141 applications that traditionally have used UDP. However, T/TCP has 1142 unacceptable security issues [Hannan1996] [Phrack1998]. 1144 The initial specification [KS1995] of Photuris [RFC 2522], now called 1145 version 1 (December 1994 to March 1995), was based on a short list of 1146 design requirements, and simple experimental code by Phil Karn. A 1147 "Cookie" Exchange guards against simple flooding attacks sent with 1148 bogus IP Sources or UDP Ports. 1150 During 1995, the Photuris efficient secret rollover and many other 1151 extensions were specified. Multiple interoperable implementations 1152 were produced. 1154 By September 1996, the long anticipated Denial of Service (DoS) 1155 attacks in the form of TCP SYN floods were devastating popular (and 1156 unpopular) servers and sites. Phil Karn informally mentioned 1157 adapting anti-clogging cookies to TCP. Perry Metzger proposed adding 1158 Karn's cookies as part of a "TCP++" effort [Metzger1996]. 1160 Later in 1996, Daniel J. Bernstein implemented "SYN cookies", small 1161 cookies embedded in the TCP SYN initial sequence number. This 1162 technique was exceptionally clever, because it did not require 1163 cooperation of the remote party and could be deployed unilaterally. 1164 However, SYN cookies can only be used in emergencies; they are 1165 incompatible with most TCP options. As there is insufficient space 1166 in the sequence number, the cookie is not considered cryptologically 1167 secure. Therefore, the mechanism remains inactive until the system 1168 is under attack, and thus is not well tested in operation. SYN 1169 cookies were not accepted for publication until recently [RFC 4987]. 1171 In 1998, Perry Metzger proposed adding Karn's cookies as part of a 1172 "TCPng" discussion [Metzger1998]. 1174 In 1999, Faber, Touch, and Yue [FTY1999] proposed using an option to 1175 negotiate the party that would maintain TIME-WAIT state. This 1176 permits a server to entirely eliminate state after closing a 1177 connection. 1179 In 2000, the Stream Control Transmission Protocol (SCTP) [RFC 2960] 1180 was published with an inadequate partial cookie mechanism claiming to 1181 be based upon Photuris. It featured a deficient checksum (replaced 1182 in 2002 by [RFC 3309] without graceful transition), and has undergone 1183 subsequent revisions [RFC 4960]. 1185 In 2006, the Datagram Congestion Control Protocol (DCCP) [RFC 4340] 1186 was published with a mechanism analogous to SYN cookies. 1188 Acknowledgments 1190 Andre Broido informally described utilizing cookies for Transport 1191 Layer Security (TLS) session identifiers. Rapid TLS session 1192 resumption would improve both latency and privacy. 1194 H. K. Jerry Chu and Arvind Jain informally described retaining 1195 existing cookies for accelerated open on subsequent connections. 1196 That feature was subsumed by this specification. 1198 Wesley M. Eddy and Adam Langley previously proposed another pair of 1199 options [EL2008] extending the TCP header option space. 1201 Adam Langley previously proposed another option [Langley2008] 1202 permitting constant payload data. His (August 2008) 1203 code was a base for the initial TCPCT implementation. 1205 Joe Touch postulated a (hopefully hypothetical) failure mode: options 1206 re-ordered by middleware. This caused a change in specifications, 1207 and has considerably complicated option interactions and processing. 1208 His helpful comments were appreciated. 1210 Many thanks to Fernando Gont for suggestions, and Rick Jones for 1211 performance testing. 1213 IANA Considerations 1215 This specification registers two new TCP options. These (previously 1216 unpublished) options were specifically selected to avoid conflicts, 1217 and IANA was advised in advance. 1219 TCP Cookie Option 1220 Kind: 31 1221 Length: variable. 1223 TCP Timestamps Extended Option 1224 Kind: 32 1225 Length: 3. 1227 Notes: Kind 31 is a prime number, particularly appropriate for a 1228 security enhancement. Kind 32 is a multiple of TCP Timestamps Option 1229 (Kind 8); Kind 16 was already registered. 1231 Operational Considerations 1233 Any implementation of this specification SHOULD be configurable. 1235 TCP_COOKIE_DESIRED 1236 Values: 0 (disabled), 8, 10, 12, 14, 16 Default: 16 (testing: 0). 1237 Send the Cookie option with the on a per port basis. 1239 TCP_COOKIE_IN_ALWAYS 1240 Default: off. Silently discard any incoming that is missing 1241 the Cookie option on a per port basis. 1243 TCP_COOKIE_OUT_NEVER 1244 Default: off. Refuse to send (override) the Cookie option on a 1245 per port basis. 1247 TCP_EXTEND_TIMESTAMP 1248 Default: off. If defined, may send 64-bit timestamps extension. 1250 TCP_SYN_DATA_LIMIT 1251 Default: 0. Maximum: 496. The maximum amount of data transmitted 1252 with the on a per port basis. Wait for data before sending. 1254 TCP_SYN_ACK_DATA_LIMIT 1255 Default: 0. Maximum: 1220. The maximum amount of data 1256 transmitted with the on a per port basis. Wait for 1257 data before sending. 1259 Security Considerations 1261 TCPCT was based on currently available tools, by experienced network 1262 protocol designers with an interest in cryptography, rather than by 1263 cryptographers with an interest in network protocols. This 1264 specification is intended to be readily implementable without 1265 requiring an extensive background in cryptology. 1267 Therefore, only minimal background cryptologic discussion and 1268 rationale is included in this document. Although some review has 1269 been provided by the general cryptologic community, it is anticipated 1270 that design decisions and tradeoffs will be thoroughly analysed in 1271 subsequent dissertations and debated for many years to come. 1272 Cryptologic details are reserved for separate documents that may be 1273 more readily and timely updated with new analysis. 1275 TCPCT is not intended to prevent or recover from all possible 1276 security threats. Rather, it is designed to protect against Denial 1277 of Service (DoS) attacks [RFC 3552], and inhibit inadvertent 1278 middlebox interference. 1280 The Cookie exchange does not protect against an interloper that can 1281 race to substitute another value, nor an interceptor that can modify 1282 and/or replace a value. These attacks are considerably more 1283 difficult than passive vacuum-cleaner monitoring. 1285 Note that each incoming replaces the Responder cookie. 1286 The initial exchange is most fragile, as protection against spoofing 1287 relies entirely upon the sequence and timestamp. This replacement 1288 strategy allows the correct pair to pass through, while any others 1289 will be filtered via Responder verification later. 1291 A. Example headers 1292 A.1. Example header 1294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1295 | Kind=MSS | Length=4 | (value) | 1296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1297 | Kind=UTO | Length=4 | (timeout) | 1298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1299 | Kind=SackOK | Length=2 | Kind=TS | Length=10 | 1300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1301 | TS Value | 1302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1303 | TS Echo Reply | 1304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1305 | Kind=Cookie | Length=16 | | 1306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1307 | | 1308 + Cookie + 1309 | | 1310 + + 1311 | | 1312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1313 | Kind=wscale | Length=3 | (value) | Kind=EOL | 1314 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1316 A 14 byte Cookie (112-bits) barely fits with the other recommended 1317 options in the maximal 60 byte TCP header (40 bytes of option space). 1319 Since the cookies are required to be the same size and meet a 32-bit 1320 alignment requirement, the implementor recognizes that this order 1321 provides optimal packing. 1323 The UserTimeOut (UTO) option can appear in other locations instead, 1324 such as following the Cookie option. Because some middleboxes are 1325 sensitive to the order of options, UTO should not appear before MSS 1326 nor between the TS and Cookie. 1328 A.2. Example with Sack 1330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1331 | Kind=MSS | Length=4 | (value) | 1332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1333 | Kind=UTO | Length=4 | (timeout) | 1334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1335 | Kind=SackOK | Length=2 | Kind=TS | Length=10 | 1336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1337 | TS Value | 1338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1339 | TS Echo Reply | 1340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1341 | Kind=Cookie+ | Length=4 | Extend=10 | 0 | Size=7| 1342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1343 | Kind=wscale | Length=3 | (value) | Kind=EOL | 1344 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1345 | | 1346 + + 1347 | | 1348 + Initiator-Cookie + 1349 | | 1350 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1351 | | | 1352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1353 | | 1354 + Responder-Cookie + 1355 | | 1356 + + 1357 | | 1358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1359 | Kind=nop | Kind=nop | Kind=Sack | Length=10 | 1360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1361 | Starting Value | 1362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1363 | Ending Value | 1364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1366 The 224-bit cookie pair is much too large to fit with the other 1367 recommended options. This illustrates an extension of the TCP 1368 header. 1370 A.3. Example header with 64-bit Timestamps 1372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1373 | Kind=MSS | Length=4 | (value) | 1374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1375 | Kind=UTO | Length=4 | (timeout) | 1376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1377 | Kind=TS64 | Length=3 | Extend=12 | Kind=nop | 1378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1379 | Kind=wscale | Length=3 | (value) | Kind=EOL | 1380 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1381 | | 1382 + TS Value + 1383 | | 1384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1385 | | 1386 + TS Echo Reply + 1387 | | 1388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1389 | Kind=SackOK | Length=2 | Kind=Cookie | Length=30 | 1390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1391 | | 1392 + + 1393 | | 1394 + Initiator-Cookie + 1395 | | 1396 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1397 | | | 1398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1399 | | 1400 + Responder-Cookie + 1401 | | 1402 + + 1403 | | 1404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1406 This example shows the (optional) 64-bit Timestamps extended option. 1408 Normative References 1410 [RFC 791] Postel, J., "Internet Protocol - DARPA Internet Program 1411 Protocol Specification", STD 5, September 1981. 1413 [RFC 793] Postel, J., "Transmission Control Protocol - DARPA 1414 Internet Program Protocol Specification", STD 7, 1415 September 1981. 1417 [RFC 1122] Braden, R., Ed., "Requirements for Internet Hosts -- 1418 Communication Layers", STD 3, October 1989. 1420 [RFC 1948] S. Bellovin, "Defending Against Sequence Number Attacks", 1421 May 1996. 1423 [RFC 2018] Mathis, M., Mahdavi, J., Floyd, S., and Romanow, A., "TCP 1424 Selective Acknowledgment Options", October 1996. 1426 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 1427 Requirement Levels", BCP 14, March 1997. 1429 [RFC 2988] Paxson, V., and Allman, M., "Computing TCP's 1430 Retransmission Timer", November 2000. 1432 [RFC 3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by 1433 an On-line Database", January 2002. 1435 http://www.iana.org/assignments/port-numbers 1437 [RFC 5452] A. Hubert, R. van Mook, "Measures for Making DNS More 1438 Resilient against Forged Answers", January 2009. 1440 [RFC 5482] Eggert, L., and Gont, F., "TCP User Timeout Option", 1441 March 2009. 1443 [RFC 5681] Allman, M., Paxson, V., and Blanton, E., "TCP Congestion 1444 Control", September 2009. 1446 [rfc1323bis] 1447 Jacobson, V., Braden, R., and Borman D., "TCP Extensions 1448 for High Performance", May 1992. 1450 Updating: work in progress, March 4, 2009. 1451 http://tools.ietf.org/html/draft-ietf-tcpm-1323bis 1453 Informative References 1455 [EL2008] Eddy, W., and Langley, A., "Extending the Space Available 1456 for TCP Options", work in progress, July 1, 2008. 1458 [FTY1999] Faber, T., Touch, J., and Yue, W., "The TIME-WAIT state 1459 in TCP and Its Effect on Busy Servers", IEEE INFOCOM 99, 1460 pp. 1573-1584. 1462 [Gont2009] Gont, F., "Security assessment of the Transmission 1463 Control Protocol (TCP)", February 2009. 1464 https://www.cpni.gov.uk/Docs/tn-03-09-security- 1465 assessment-TCP.pdf 1467 [Hannan1996] 1468 Hannum, C., "Security Problems Associated With T/TCP", 1469 unpublished work in progress, September 1996. 1470 http://www.mid-way.org/doc/ttcp-sec.txt 1472 [KS1995] Karn, P., and Simpson, W., "The Photuris Session Key 1473 Management Protocol", March 1995. draft-karn- 1474 photuris-01.txt 1476 Published as: "Photuris: Design Criteria", Proceedings of 1477 Sixth Annual Workshop on Selected Areas in Cryptography, 1478 LNCS 1758, Springer-Verlag. August 1999. 1480 [Langley2008] 1481 Langley, A., "Faster application handshakes with SYN/ACK 1482 payloads", work in progress, August 5, 2008. 1484 [LG2010] Larson, M., and Gont, F., "Transport Protocol Port 1485 Randomization Recommendations", work in progress, 1486 February 15, 2010. http://tools.ietf.org/html/draft- 1487 ietf-tsvwg-port-randomization 1489 [MAF2004] Medina, A., Allman, M., and Floyd, S., "Measuring 1490 Interactions Between Transport Protocols and 1491 Middleboxes", Proceedings 4th ACM SIGCOMM/USENIX 1492 Conference on Internet Measurement, October 2004. 1493 http://www.icsi.berkeley.edu/pubs/networking/tbit- 1494 Aug2004.pdf 1496 [Metzger1996] 1497 Metzger, P., "Re: SYN floods (was: does history repeat 1498 itself?)", September 9, 1996. 1499 http://www.merit.net/mail.archives/nanog/ 1500 1996-09/msg00235.html 1502 [Metzger1998] 1503 Metzger, P., "Re: what a new TCP header might look like", 1504 May 12, 1998. ftp://ftp.isi.edu/end2end/end2end- 1505 interest-1998.mail 1507 [Morris1985] 1508 Morris, R., "A Weakness in the 4.2BSD Unix TCP/IP 1509 Software", Technical Report CSTR-117, AT&T Bell 1510 Laboratories, February 1985. 1511 http://pdos.csail.mit.edu/~rtm/papers/117.pdf 1513 [MSV2009] Metzger, P., Simpson, W., and Vixie, P., "Improving TCP 1514 Security With Robust Cookies", Usenix ;login:, December 1515 2009. http://www.usenix.org/publications/login/ 1516 2009-12/openpdfs/metzger.pdf 1518 [Phrack1998] 1519 route [at] infonexus [dot] com, "T/TCP vulnerabilities", 1520 Phrack Magazine, Volume 8, Issue 53, July 8, 1998. 1521 http://www.phrack.org/issues.html?issue=53&id=6 1523 [RFC 1379] R. Braden, "Extending TCP for Transactions -- Concepts", 1524 November 1992. 1526 [RFC 1644] Braden, R., "T/TCP -- TCP Extensions for Transactions -- 1527 Functional Specification", July 1994. 1529 [RFC 2385] A. Heffernan, "Protection of BGP Sessions via the TCP MD5 1530 Signature Option", August 1998. 1532 [RFC 2522] Karn, P., and Simpson, W., "Photuris: Session-Key 1533 Management Protocol", March 1999. 1535 [RFC 2827] Ferguson, P., and Senie, D., "Network Ingress Filtering: 1536 Defeating Denial of Service Attacks which employ IP 1537 Source Address Spoofing", BCP 38, May 2000. 1539 [RFC 2960] Stewart, R., et alia, "Stream Control Transmission 1540 Protocol", October 2000. 1542 [RFC 3022] Srisuresh, P., and Egevang, K., "Traditional IP Network 1543 Address Translator (Traditional NAT)", January 2001. 1545 [RFC 3234] Carpenter, B., and Brim, S., "Middleboxes: Taxonomy and 1546 Issues", February 2002. 1548 [RFC 3309] J. Stone, R. Stewart, D. Otis, "Stream Control 1549 Transmission Protocol (SCTP) Checksum", September 2002. 1551 [RFC 3552] Rescorla, E., and Korver, B., "Guidelines for Writing RFC 1552 Text on Security Considerations", BCP 72, July 2003. 1554 [RFC 3704] Baker, F., and Savola, P., "Ingress Filtering for 1555 Multihomed Networks", BCP 84, March 2004. 1557 [RFC 4340] Kohler, E., Handley, M., and Floyd, S., "Datagram 1558 Congestion Control Protocol (DCCP)", March 2006. 1560 [RFC 4953] Touch, J., "Defending TCP Against Spoofing Attacks", July 1561 2007. 1563 [RFC 4960] R. Stewart, Ed., "Stream Control Transmission Protocol", 1564 September 2007. 1566 [RFC 4987] Eddy, W., "TCP SYN Flooding Attacks and Common 1567 Mitigations", August 2007. 1569 [RFC 5358] Damas, J., and Neves, F., "Preventing Use of Recursive 1570 Nameservers in Reflector Attacks", BCP 140, October 2008. 1572 Author's Address 1574 Questions about this document can be directed to: 1576 William Allen Simpson 1577 DayDreamer 1578 Computer Systems Consulting Services 1579 1384 Fontaine 1580 Madison Heights, Michigan 48071 1582 William.Allen.Simpson@Gmail.com