idnits 2.17.1 draft-simpson-tcpct-06.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 (6 January 2011) is 4852 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1323 (Obsoleted by RFC 7323) ** Obsolete normative reference: RFC 1948 (Obsoleted by RFC 6528) ** Obsolete normative reference: RFC 2988 (Obsoleted by RFC 6298) ** Obsolete normative reference: RFC 1700 (ref. 'RFC3232') (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) -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 10 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 6 January 2011 6 TCP Cookie Transactions (TCPCT) 7 draft-simpson-tcpct-06 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-less Option . . . . . . . . . . . . . . 8 62 3.4 TCP Timestamps Extended Option . . . . . . . . . . 9 63 3.5 Cookie Generation . . . . . . . . . . . . . . . . 10 64 3.5.1 Initiator Cookie . . . . . . . . . . . . . . . . . 11 65 3.5.2 Responder Cookie . . . . . . . . . . . . . . . . . 11 66 3.5.3 Responder Secret Value . . . . . . . . . . . . . . 13 67 4. Cookie Exchange . . . . . . . . . . . . . . . . . . . . 14 68 4.1 Initiator . . . . . . . . . . . . . . . . . 14 69 4.2 Responder . . . . . . . . . . . . . 14 70 4.3 Initiator . . . . . . . . . . . . . . . 15 71 4.4 Responder . . . . . . . . . . . . . . . . . 16 72 4.5 Simultaneous Open . . . . . . . . . . . . . . . . 16 73 5. Accelerated Close . . . . . . . . . . . . . . . . . . . 17 74 5.1 Initiator Close . . . . . . . . . . . . . . . . . 18 75 5.2 Responder Close . . . . . . . . . . . . . . . . . 18 76 6. Accelerated Open . . . . . . . . . . . . . . . . . . . . 19 77 6.1 Initiator Data . . . . . . . . . . . . . . . 19 78 6.2 Responder Data . . . . . . . . . . 20 79 6.3 Initiator Data . . . . . . . . . . . . 21 80 6.4 Responder Data . . . . . . . . . . . . . . . 21 81 7. Advisory Reset . . . . . . . . . . . . . . . . . . . . . 22 82 8. Interactions with Other Options . . . . . . . . . . . . 22 83 8.1 TCP Selective Acknowledgment . . . . . . . . . . . 22 84 8.2 TCP Timestamps . . . . . . . . . . . . . . . . . . 23 85 8.3 TCP Extensions for Transactions . . . . . . . . . 23 86 8.4 TCP MD5 Signature . . . . . . . . . . . . . . . . 23 87 8.5 TCP Authentication . . . . . . . . . . . . . . . . 23 88 HISTORY . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 89 ACKNOWLEDGMENTS . . . . . . . . . . . . . . . . . . . . . . . . 25 90 IESG CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . . . 25 91 OPERATIONAL CONSIDERATIONS . . . . . . . . . . . . . . . . . . 26 92 SECURITY CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . 26 93 APPENDICES . . . . . . . . . . . . . . . . . . . . . . . . . . 27 94 A. Example Headers . . . . . . . . . . . . . . . . . . . . 27 95 A.1 Example . . . . . . . . . . . . . . . . . . 27 96 A.2 Example with Sack . . . . . . . . . . . 28 97 A.3 Example with 64-bit Timestamps . . . . 29 98 NORMATIVE REFERENCES . . . . . . . . . . . . . . . . . . . . . 30 99 INFORMATIVE REFERENCES . . . . . . . . . . . . . . . . . . . . 31 100 CONTACTS . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 102 1. Introduction 104 TCP Cookie Transactions (TCPCT) provide a cryptologically secure 105 mechanism to guard against simple flooding attacks sent with bogus IP 106 [RFC791] Sources or TCP [RFC793] Ports. The initial TCP 107 exchange is vulnerable to forged IP Addresses, predictable Ports, and 108 discoverable Sequence Numbers [Morris1985] [Gont2009]. (See also 109 [RFC2827], [RFC3704], and [RFC4953].) 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 were detailed in [MSV2009]. 135 1.1. Terminology 137 The key words "MAY", "MUST, "MUST NOT", "OPTIONAL", "RECOMMENDED", 138 "REQUIRED", "SHOULD", and "SHOULD NOT" in this document are to be 139 interpreted as described in [RFC2119]. 141 byte An 8-bit quantity; also known as "octet" in 142 standardese. 144 2. Protocol Overview 146 The TCPCT extensions consist of several simple phases: 148 1. Each party passes a "cookie" to the other. Due to limited space, 149 only the most basic options are included. 151 The Cookie option also indicates that optional data is 152 acceptable. This data MAY be ignored by either party. 154 A Responder that understands the Cookie option remains stateless. 156 2. During the remainder of the standard TCP three-way handshake, the 157 Timestamps and Cookie-Pair options guard the exchange. 159 Other options present in the original that were successfully 160 returned in the MUST be included with the 161 . Additional options MAY also be included as desired. 163 As there is no Responder state, it has no record of acknowledging 164 previous data. Any optional data MUST be retransmitted. 166 Upon verification of the Timestamps and Cookie-Pair, the Responder 167 creates its Transport Control Block (TCB) [RFC793]. 169 Note that the Responder returns the Cookie-Pair with its initial 170 data, but subsequent data segments need only the Timestamps. 172 3. During close (or reset) of the TCP connection, the Timestamps and 173 Cookie-Pair options guard the exchange. 175 Upon verification of the Timestamps and Cookie-Pair, the Responder 176 removes its TCB. 178 The sequence of messages is summarized in the diagram below. 180 2.1. Message Summary (Simplified) 182 Initiator Responder 183 ========= ========= 184 -> 185 base options 186 Timestamps 187 Cookie 188 [request data] 189 <- 190 base options 191 Timestamps 192 Cookie 193 [response data] 194 (stateless) 196 -> 197 full options 198 Timestamps 199 Cookie-Pair 200 [Sack(response)] 201 data 202 <- 203 full options 204 Timestamps 205 Cookie-Pair 206 data 207 (TCB state created) 208 <- 209 Timestamps 210 data 212 <- 213 Timestamps 214 Cookie-Pair 215 -> 216 Timestamps 217 Cookie-Pair 218 <- 219 Timestamps 220 Cookie-Pair 221 (TCB state removed) 222 TIME-WAIT 224 2.2. Compatibility and Transparency 226 It is usually better that data arrive slowly, than not at all. 228 Many/most unmanaged middleboxes [RFC3234] (such as stateless 229 firewalls, load balancers, intrusion detection systems, or network 230 address translators [RFC3022]) cannot carry transport traffic other 231 than TCP and UDP. 233 Every TCP implementation MUST ignore without error any TCP option it 234 does not implement ([RFC1122] section 4.2.2.5). In a study of the 235 effects of middleboxes on transport protocols [MAF2004], the vast 236 majority of modern TCP stacks correctly handle unknown TCP options. 237 But it is still prudent to follow the [RFC793] "general principle of 238 robustness: be conservative in what you do, be liberal in what you 239 accept from others." 241 Therefore, for each of the extensions defined here, an extension 242 option will be sent in a segment only after the 243 corresponding option was received in the original segment. 245 Furthermore, TCP options will be sent on later segments only after an 246 exchange of options has indicated that both parties understand the 247 extension (see [RFC1323] and its antecedents). 249 Unfortunately, not all middleware adheres to these long-standing 250 requirements. Instead, unknown options are copied to the 251 . This is indistinguishable from a Monkey in the 252 Middle (MITM) reflection attack. 254 2.3. Fully Loaded Cookies 256 One Kind to aid them all, One Kind to find them, 257 One Kind to hold them all and in the header bind them. 259 The cookie exchange provides a singular opportunity to extend TCP 260 with backward compatibility. Semantics for the option have been 261 "overloaded" with a baker's dozen capabilities and facilities. 263 A. First and foremost, the cookie exchange improves operational 264 security for vulnerable servers against flooding attacks. The 265 cookie exchange indicates that the Responder (server) will discard 266 its initial state. All other semantics are subordinate. 268 B. Together with Sequence and Timestamp values, Cookie values protect 269 against insertion and reflection attacks. 271 C. Cookie values allow applications to detect replay attacks. 273 D. Cookie values MAY be used as an index or nonce for application 274 security protocols. This facility is beyond the scope of this 275 specification. 277 E. The and MAY carry application data. This 278 feature is entirely optional, and data is not guaranteed to pass 279 successfully through middleware. Nor are the parties guaranteed 280 to process this data without changes to the Application Program 281 Interface (API). Such changes are beyond the scope of this 282 specification. 284 F. The size of the cookies precludes most other options in the 285 standard TCP header space. The cookie exchange negotiates TCP 286 header extension. 288 G. The cookie exchange and resulting TCP header extension permit 289 negotiation of larger 64-bit (or 128-bit) Timestamps for paths 290 with large bandwidth-delay products. 292 H. TCP header extension frees some space for additional options. 294 I. Previously SYN-only options can be updated. 296 J. The cookie exchange indicates agreement to use accelerated close. 298 K. The cookie exchange indicates agreement that only the Initiator 299 (client) handles TIME-WAIT state. 301 L. The Timestamps and Cookie-Pair combination inhibits third parties 302 from disrupting communications with and . 304 M. The Timestamps and Cookie-Pair combination facilitates rapid reuse 305 of the TCP Source Port with a common destination. 307 2.4. TCP Header Extension 309 Once the Cookie option has been successfully exchanged, TCP header 310 extension is permitted. The Timestamps extended option (defined 311 below) indicates the presence of the header extension. 313 Validation of known timestamp values protects against data corruption 314 by misbehaving middleboxes. 316 2.5. Option Handling 318 As the Responder retains no TCB state after the initial TCP 319 exchange, all options present in the original MUST be repeated. 321 For example, an option defined in the [RFC793] original specification 322 -- Maximum Segment Size (MSS) -- previously appeared only in a 323 bearing segment (including ). If present, MSS will be 324 repeated in the Initiator , together with any additional 325 options. 327 Generally, the Initiator MAY propose SYN-only options -- such as MSS 328 -- anytime both Timestamps and Cookie-Pair options are present. 329 These options are treated the same as with an original . The 330 Responder acknowledges using a subsequent segment containing 331 both Timestamps and Cookie-Pair options (similar to 332 processing). 334 This facility allows previously SYN-only options to be updated from 335 time to time. They take effect upon receipt. 337 However, segments without data will not be delivered reliably. 338 Any otherwise SYN-only options sent without data MUST be 339 retransmitted with successive segments until sent with data (or 340 ), and an is received. 342 3. Protocol Details 344 Another solution [RFC5452] describes use of an unpredictable Source 345 Port. That is RECOMMENDED by this specification. See [LG2010] for 346 further information. 348 An earlier solution [RFC1948] describes an unpredictable Initial 349 Sequence Number (ISN). That is REQUIRED by this specification. 351 Support for the (32-bit) TCP Timestamps Option [RFC1323] is REQUIRED. 352 A TSoffset SHOULD be generated per connection [GO2010]. The Don't 353 Fragment (DF) bit MUST be set in the IP (v4) header. 355 The TCP User Timeout Option [RFC5482] is RECOMMENDED. 357 Only one instance is permitted of any of the Cookie, Cookie-less, or 358 Cookie-Pair option(s). Segments with duplicative or mutually 359 exclusive options MUST be silently discarded. 361 For examples, see Appendix A. 363 3.1. TCP Cookie Option 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Kind | Length | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | | 369 ~ Cookie ~ 370 | | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 Kind 1 byte: constant 253 (experimental). 375 Length 1 byte: range 10 to 18 (bytes); limited by remaining 376 space in the options field. The number MUST be 377 even; the cookie is a multiple of 16 bits. 379 Cookie 8 to 16 bytes (Length - 2): an unpredictable value. 381 Options with invalid Length values MUST be ignored. The minimum 382 Cookie size is 64 bits. If there is not sufficient space for a 383 64-bit cookie, this option MUST NOT be used. 385 The Responder Cookie MUST be the same size as the Initiator Cookie. 386 The cookie pair is a multiple of 32 bits. 388 Although the diagram shows a cookie aligned on 32-bit boundaries, 389 that is not required. 391 3.2. TCP Cookie-Pair Standard Option 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Kind | Length | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | | 397 ~ Initiator-Cookie ~ 398 | | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | | 401 ~ Responder-Cookie ~ 402 | | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 Kind 1 byte: constant 253 (experimental). 407 Length 1 byte: range 18 to 34 (bytes). The number MUST be 408 even; the cookie pair is a multiple of 32 bits. 410 Initiator-Cookie 8 to 16 bytes, from the original . 412 Responder-Cookie 8 to 16 bytes, from the . 414 The Cookie-Pair standard option only appears after the Timestamps 415 extended option (below). 417 Options with invalid Length values MUST be ignored. As the minimum 418 Initiator-Cookie size is 64 bits, the minimum cookie pair is 128 bits 419 (64 bits followed by 64 bits), while the maximum is 256 bits (128 420 bits followed by 128 bits). 422 3.3. TCP Cookie-less Option 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Kind | Length | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 Kind 1 byte: constant 253 (experimental). 430 Length 1 byte: constant 2 (bytes). This distinguishes the 431 option from other Cookie options. 433 Although no cookie is attached, this indicates that other features of 434 this specification are available, including TCP header extension, 435 Accelerated Close, Accelerated Open, and Advisory Reset. This is 436 intended for use with TCP authentication options, beyond the scope of 437 this specification. 439 3.4. TCP Timestamps Extended Option 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Kind | Length | Extend | R | S | 443 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 444 | | 445 ~ TS Value ~ 446 | | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | | 449 ~ TS Echo Reply ~ 450 | | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 Kind 1 byte: constant 254 (experimental). 455 Length 1 byte: constant 4 (bytes). 457 Extend 1 byte: range 9 to 255; the data offset (in 32-bit 458 words) following the standard TCP header. Note this 459 value MUST include the timestamp pair indicated by 460 (S)ize. 462 (R)eserved 5 bits: default zero. Reserved for future use. 464 (S)ize 3 bits: 466 1. 32-bit timestamps. 468 2. 64-bit timestamps. 470 4. 128-bit timestamps. 472 Other values are beyond the scope of this 473 specification. 475 TS Value 4, 8, or 16 bytes. The current value of the 476 timestamp for the sender. 478 TS Echo Reply 4, 8, or 16 bytes. A copy of the most recently 479 received TS Value. 481 The full timestamp pair follows the TCP header (indicated by +=+ 482 delimiters) and maintains 32-bit alignment. 484 This TCP header extension is ignored for sequence number 485 computations. The Sequence Number of the first byte of segment data 486 will be the Initial Sequence Number (ISN) plus one (1) for the . 488 Every TCPCT implementation MUST recognize a Timestamps extended 489 option. The larger 64-bit (or 128-bit) timestamps only appear in an 490 extended option. 492 Segments with invalid Extend values MUST be silently discarded. 494 Only one instance is permitted of either the (32-bit) Timestamps 495 standard option or this Timestamps extended option. Segments with 496 duplicative or mutually exclusive options MUST be silently discarded. 498 Implementation Notes: 500 Serendipitous alignment allows simple loads and stores, instead of 501 slower byte by byte iterations. 503 When the TCP header is aligned on a 32-bit boundary and this is 504 the only option, the timestamps in the extended header SHOULD be 505 aligned on a 64-bit boundary. For both 32-bit and 64-bit 506 timestamps, any data following the extended header will be aligned 507 on a 64-bit boundary. 509 However, the 128-bit timestamps are not 128-bit aligned. 511 3.5. Cookie Generation 513 The technique by which a party generates a cookie is implementation 514 dependent. The method chosen must satisfy some basic requirements: 516 1. The cookie MUST depend on the specific parties. This prevents an 517 attacker from obtaining a cookie using a real IP address and TCP 518 port, and then using it to swamp the victim with requests from 519 randomly chosen IP addresses or ports. 521 2. It MUST NOT be possible for anyone other than the issuing entity 522 to generate cookies that will be accepted by that entity. This 523 implies that the issuing entity will use local secret information 524 in the generation and subsequent verification of a cookie. It 525 must not be possible to deduce this secret information from any 526 particular cookie. 528 3. The cookie generation and verification methods MUST be fast to 529 thwart attacks intended to sabotage CPU resources. 531 A recommended technique is to use a cryptographic hashing function. 533 An incoming cookie can be verified at any time by regenerating it 534 locally from values contained in the incoming datagram and the local 535 secret random value. 537 3.5.1. Initiator Cookie 539 The Initiator secret value that affects its cookie SHOULD change for 540 each new exchange, and is thereafter internally cached per TCB. This 541 provides improved synchronization and protection against replay 542 attacks. 544 An alternative is to cache the cookie instead of the secret value. 545 Incoming cookies can be compared directly without the computational 546 cost of regeneration. 548 It is RECOMMENDED that the cookie be calculated over the secret 549 value, the IP Source and Destination addresses, the TCP Source and 550 Destination ports, and any (optional) Initiator segment data. 552 Implementation Notes: 554 Although the recommendation includes the TCP Source Port, this is 555 very implementation specific. For example, it might not be 556 included when the value is constant or unknown. 558 Likewise, segment data might not be included directly. For 559 example, a pointer to the data could be included instead, with 560 care taken to ensure the pointer changes anytime the data changes. 562 However, it is important that the implementation protect mutually 563 suspicious users of the same system from generating the same 564 cookie. 566 3.5.2. Responder Cookie 568 The Responder secret value that affects its cookies remains the same 569 for many different Initiators. However, this secret SHOULD be 570 changed periodically to limit the time for use of its cookies 571 (typically each 600 seconds). 573 The Responder-Cookie calculation MUST include its own TCP Sequence 574 and Acknowledgment Numbers (after updating values), its own TCP 575 Timestamps value, and the Initiator-Cookie value. This provides 576 improved synchronization and protection against replay attacks. 578 It is RECOMMENDED that the cookie be calculated over the secret 579 value, the IP Source and Destination addresses, its own TCP 580 Destination Port (that is, the incoming Source Port), and the 581 required values (above), followed by the secret value again. 583 The cookie is not cached per Initiator to avoid saving state during 584 the initial TCP exchange. On receipt of a TCP , the 585 Responder regenerates its cookie for validation. 587 Implementation Notes: 589 Although the recommendation does not include the TCP Source Port, 590 this is very implementation specific. It might be successfully 591 included in some variants. 593 The Responder Cookie depends on the TCP Sequence and 594 Acknowledgment Numbers as they will appear for future 595 verification. The Sequence Number will be the Initial Sequence 596 Number (ISN) plus one (1) for its that will be acknowledged. 597 The Acknowledgment Number will be the Initial Sequence Number 598 (ISN) plus one (1) for the that it is now acknowledging. 600 The (32-bit) TCP Timestamps standard option MAY change to the 601 larger 64-bit (or 128-bit) extended form; only the least 602 significant 32 bits are included. The Initiator Timestamp field 603 value MAY increment during the exchange; it MUST NOT be included. 605 The secret value is included twice to better protect against pre- 606 calculated attacks using substitutions for variable length data. 607 Some examples using this technique are IP-MAC and H-MAC, and it is 608 likely that existing code could be shared. 610 The Responder SHOULD designate a (fixed or randomly selected) bit 611 of its cookie to distinguish each changed secret value. The bit 612 is set to a (fixed or randomly selected) constant 0 or 1, and 613 checked upon receipt before further verification. This ensures 614 that only one verification calculation is necessary (on average) 615 during Denial of Service (DoS) attacks. 617 If a Responder Cookie is identical to the Initiator Cookie, the 618 Responder SHOULD change one or more bits of its cookie to prevent 619 its accidental appearance as a reflection attack. 621 3.5.3. Responder Secret Value 623 Each Responder maintains up to two secret values concurrently for 624 efficient secret rollover. Each secret value has 4 states: 626 Generating 627 Generates new Responder-Cookies, but not yet used for primary 628 verification. This is a short-term state, typically lasting only 629 one Round Trip Time (RTT). 631 Primary 632 Used both for generation and primary verification. 634 Retiring 635 Used for verification, until the first failure that can be 636 verified by the newer Generating secret. At that time, this 637 cookie's state is changed to Secondary, and the Generating 638 cookie's state is changed to Primary. This is a short-term state, 639 typically lasting only one RTT. 641 Secondary 642 Used for secondary verification, after primary verification 643 failures. This state lasts no more than twice the Maximum Segment 644 Lifetime (2MSL). Then, the secret is discarded. 646 Implementation Notes: 648 Care MUST be taken to ensure that any expired secrets are promptly 649 wiped from memory, and secrets are never saved to external 650 storage. 652 The first secret after initialization begins in Primary state. 653 The system might have shutdown and restarted rapidly during the 654 previous first secret. Thus, the first secret MUST be partially 655 time dependent, to ensure that it differs from previous first 656 secrets, usually by appending a time to lengthen the first secret. 657 Those that are not the first secret SHOULD NOT include the time. 659 At the same time, there is no TCP TIME-WAIT requirement before 660 accepting connections, and there may be pent up demand for a busy 661 service. Also, there may be outstanding datagrams attempting to 662 complete an earlier cookie exchange. The first secret is likely 663 to be the weakest, as no recent entropy has been included. 665 Therefore, while terminating outstanding exchanges with the first 666 secret, a new Generating secret SHOULD be created after no more 667 than one Maximum Segment Lifetime (1MSL). Subsequent secrets 668 SHOULD be generated at the usual rate (typically 600 seconds). 670 The implementation SHOULD continually gather additional entropy 671 from checksums, cookies, timestamps, and packet arrival timing. 673 4. Cookie Exchange 675 A successful option exchange signals availability of additional 676 features. 678 4.1. Initiator 680 The Cookie exchange MAY be initiated at any time, limited only by the 681 frequency of the timestamp clock. 683 If the TCB exists from a prior (or ongoing) connection, the timestamp 684 MUST be incremented in the option. 686 The Initiator generates its unpredictable cookie value, and includes 687 the Cookie option. 689 During the initial exchange, the Initiator is solely responsible for 690 retransmission. Although the cookie and sequence have not changed, 691 each retransmission appears to the Responder as another original 692 . 694 Implementation Notes: 696 Sending the SHOULD NOT affect any existing TCB. This allows 697 an additional RTT for duplicate or out-of-sequence segments to 698 drain. 700 The new TCB information SHOULD be temporarily cached until a valid 701 matching arrives. Then, any old TCB values are 702 replaced. 704 4.2. Responder 706 Upon receipt of the with a Cookie option, the Responder 707 determines whether there are sufficient resources to begin another 708 connection. 710 If the TCB exists from a prior (or ongoing) connection, the timestamp 711 MUST be incremented in the option. 713 Each Sequence Number MUST be randomized [RFC1948]. 715 The Responder generates its unpredictable cookie value, and includes 716 the Cookie option. 718 As the Responder retains no TCB state, retransmission timers are not 719 available. Arrival of an Initiator's retransmission appears to be an 720 original transmission. There are no differences in processing. 722 Implementation Notes: 724 Sending the MUST NOT affect any existing TCB. This 725 allows an additional RTT for duplicate or out-of-sequence segments 726 to drain. 728 This also inhibits third parties from disrupting communications. 730 4.3. Initiator 732 Upon receipt of the with a Cookie option, the 733 Initiator validates its cookie, timestamp, and corresponding 734 Acknowledgment Number. The existing TCB is updated as necessary. 736 All Initiator options are always retransmitted on this first 737 , allowing the Responder to validate its cookie and 738 establish its state. 740 This segment contains both Timestamps and Cookie-Pair options. 742 The Initiator sends the Timestamps extended option with an 743 appropriate Size -- chosen by a configurable parameter, or 744 automatically based on its analysis of the bandwidth-delay product 745 discovered through the RTT of its timestamp. When the chosen 746 Size is greater than 32 bits, the Initiator adds a random prefix to 747 its own timestamp, and a random prefix to the Responder timestamp 748 echo reply. 750 Implementation Notes: 752 A Responder Cookie identical to the Initiator Cookie MUST be 753 discarded. This is usually an indication of a Monkey in the 754 Middle (MITM) reflection attack or a seriously misconfigured 755 network, and SHOULD be logged. 757 4.4. Responder 759 Upon receipt of the with a Cookie-Pair option, the 760 Responder validates its cookie, timestamp, and corresponding 761 Acknowledgment Number, and establishes state for the connection. Any 762 existing TCB is updated as necessary. 764 This segment contains both Timestamps and Cookie-Pair options. 766 However, the Responder MAY refuse to negotiate the larger 64-bit (or 767 128-bit) Timestamps extended option by returning the least 768 significant bits in a smaller Timestamps extended option. 770 Implementation Notes: 772 An that fails to validate MUST be discarded, and SHOULD 773 be logged. 775 4.5. Simultaneous Open 777 TCP allows two parties to simultaneously initiate the connection. 778 Both parties send and receive an original without an 779 intervening (see [RFC793] section 3.4 and Figure 8). 780 Each party receives a Cookie for a connection that has also 782 issued a Cookie. 784 This condition will be unusual. The Source Port SHOULD be randomized 785 [RFC5452], and SHOULD be chosen to differ from the Destination Port. 786 In particular, the Source Port SHOULD be greater than 1024, 787 preventing intervening network equipment from incorrectly classifying 788 the return traffic. The Destination Port is most likely to be a 789 well-known port less than 1024 [RFC3232]. 791 In the event that these protections are insufficient, the conflict is 792 resolved in an orderly fashion: 794 a. The lesser TCP Port number becomes the Responder; 796 b. The lesser IP Address becomes the Responder; 798 c. The lesser Cookie becomes the Responder; 800 d. All of the above being equal, there is an egregiously insufficient 801 source of randomness, but both Initiators are probably present on 802 the same host: the lesser TCB memory address becomes the 803 Responder. 805 The Initiator silently discards the simultaneous . The 806 Responder revises its Cookie option, and sends the as 807 usual, but without removing its existing TCB. 809 Implementation Notes: 811 This is usually an indication of a Monkey in the Middle (MITM) 812 reflection attack or a seriously misconfigured network, and SHOULD 813 be logged. 815 5. Accelerated Close 817 Support for accelerated close is REQUIRED. Accelerated close relies 818 on the presence of cookies and timestamps. This provides improved 819 synchronization and protection against replay attacks. 821 Either party MAY close with at any time. This SHOULD be 822 sent with the final data segment. 824 This segment contains both Timestamps and Cookie-Pair options. 826 When all segments preceding the have been processed and 827 acknowledged, each party SHOULD acknowledge the . 829 In general, is treated as advisory. A persistent connection 830 can be rapidly re-established. This also inhibits third parties from 831 disrupting communications. 833 Rapidly closing the connection expedites removing Responder state. 834 Any bearing segment SHOULD terminate delayed [RFC5681]. 835 Retransmit at the latest Timestamps estimated Smoothed Round Trip 836 Time (SRTT). Backoff SHOULD NOT be used for bearing 837 retransmissions [RFC2988]. 839 As the Responder retains no TCB state after closing, a successful 840 option exchange signals the Initiator will be responsible for 841 handling TIME-WAIT state. (For previous proposal and rationale, see 842 [FTY1999] section 3.) 844 A new Cookie exchange MAY be initiated at any time. This facilitates 845 persistent connections through intervening network equipment. 847 5.1. Initiator Close 849 Upon receipt of the Initiator (and verification of the 850 Timestamps and Cookie-Pair options), the Responder sends its 851 unless there is additional data pending. In the 852 latter case, the is ignored until the data has been processed 853 and acknowledged. 855 Upon receipt of the Responder (and verification of the 856 Timestamps and Cookie-Pair options), the Initiator sends its final 857 unless there is additional data pending. The Initiator 858 enters TIME-WAIT state. 860 This segment contains both Timestamps and Cookie-Pair options. 862 Upon receipt of the Initiator (and verification of the 863 Timestamps and Cookie-Pair options), the Responder removes its TCB. 865 Upon arrival of more data prompting a new Cookie exchange, the 866 Initiator SHOULD NOT not send a final and/or SHOULD NOT 867 wait the remaining TIME-WAIT interval. Any existing TSoffset SHOULD 868 be incremented. TSoffset will be removed (with the TCB itself) at 869 the conclusion of a future TIME-WAIT state. 871 5.2. Responder Close 873 Upon receipt of the Responder (and verification of the 874 Timestamps and Cookie-Pair options), the Initiator sends its 875 unless there is additional data pending. In the 876 latter case, the is ignored until the data has been processed 877 and acknowledged. 879 Upon receipt of the Initiator (and verification of the 880 Timestamps and Cookie-Pair options), the Responder sends its final 881 and removes its TCB. 883 This segment contains both Timestamps and Cookie-Pair options. 885 If the Responder's final is lost, the Responder is likely 886 to send a (as the Responder retains no TCB state). This 887 distinguished SHOULD copy both Timestamps and Cookie-Pair 888 options. 890 Upon receipt of the Responder's final (and verification of 891 the Timestamps and Cookie-Pair options), the Initiator enters TIME- 892 WAIT state. 894 Upon arrival of more data prompting a new Cookie exchange, the 895 Initiator SHOULD NOT not send a and/or SHOULD NOT wait 896 the remaining TIME-WAIT interval. Any existing TSoffset SHOULD be 897 incremented. TSoffset will be removed (with the TCB itself) at the 898 conclusion of a future TIME-WAIT state. 900 6. Accelerated Open 902 Support for accelerated open is OPTIONAL. 904 When an application is capable of idempotent transactions (such as a 905 query that returns a consistent result or service response heading), 906 the application sets the appropriate limit separately for each port 907 or connection. Applications are responsible for ensuring that 908 retransmissions do not cause duplication of data. 910 This facility allows single data segment transactions without 911 establishing TCB state at the Responder (server). For longer 912 transactions, a short look-ahead of upcoming data allows the 913 Initiator (client) to select alternatives for further processing. 915 6.1. Initiator Data 917 By default, the Initiator does not contain data. The 918 application sets the TCP_SYN_DATA_LIMIT to indicate that the 919 MAY be sent with data. 921 The Responder Maximum Segment Size (MSS) is unknown, and the default 922 MSS (536 bytes) MUST be used instead ([RFC1122] section 4.2.2.6). 923 This is further reduced by the total length of the TCP options (in 924 this case, commonly 496 bytes). Applications MAY specify a shorter 925 limit. 927 If the data will not entirely fit within the initial segment, data 928 MUST NOT be sent until after the Responder's is 929 received. 931 Unlike T/TCP [RFC1644], SHOULD NOT be sent with data. 932 This facilitates persistent connections. 934 Likewise, SHOULD NOT be set. Although the application might 935 use push to indicate that its data is ready to send, the push is 936 implied for data segments. 938 During the initial exchange, the Initiator is solely responsible for 939 retransmission. Although the cookie and sequence have not changed, 940 each retransmission appears to the Responder as another original 941 . 943 Implementation Notes: 945 Initiator with the Cookie option and no segment data is 946 permitted in a test environment. This combination SHOULD be 947 silently discarded. 949 Initiator with both the Cookie option and segment data 950 is similar to T/TCP [RFC1644]. However, whenever the Responder 951 has been sent with data (there is no further 952 data expected), TCB state has not been saved at the Responder. 953 There is no need to send to close the connection. 955 6.2. Responder Data 957 By default, the Responder does not contain data. The 958 application sets the TCP_SYN_ACK_DATA_LIMIT to indicate that the 959 MAY be sent with data. 961 Segment data is limited to the Maximum Transmission Unit (MTU). 962 Applications MAY specify a shorter limit to prevent spoofed 963 amplification and reflection attacks [RFC5358]. 965 Upon receipt of the with a Cookie option, the Responder MAY 966 process any data present. If the initial data is not accepted, the 967 Acknowledgment Number will be the received Sequence Number plus one 968 (1) for the . 970 If the segment data is the entire response (there is no further data 971 expected), MAY be set. 973 However, SHOULD NOT be set. Although the application might use 974 push to indicate that its data is ready to send, the push is implied 975 for data segments (see [RFC793] section 3.7, page 41). 977 As the Responder retains no TCB state, retransmission timers are not 978 available. Arrival of an Initiator's retransmission appears to be an 979 original transmission. There are no differences in processing. 981 Implementation Notes: 983 The Responder Cookie depends on the TCP Sequence and 984 Acknowledgment Numbers after processing . Therefore, neither 985 will include data. 987 6.3. Initiator Data 989 Upon receipt of the with a Cookie option, the 990 Initiator MAY process any data present. In this case, the internal 991 RCV.NXT is advanced to provide at-most-once semantics. 993 If the segment data is the entire response (there is no further data 994 expected), the Initiator enters TIME-WAIT state. 996 Otherwise, original data is retransmitted in , as its 997 processing is optional. The Acknowledgment Number will be the 998 received Sequence Number plus one (1) for the . The Sequence 999 Number will be the Initial Sequence Number (ISN) plus one (1) for the 1000 . 1002 Unlike T/TCP [RFC1644], there is no implicit acknowledgment. 1004 If the Selective Acknowledgment (Sack) option [RFC2018] has been 1005 successfully negotiated, a short Sack acknowledging the response data 1006 MAY be sent following the Cookie-Pair in the extended header. 1008 At this time, any second segment may be sent without awaiting an 1009 , according to the usual [RFC5681] TCP congestion control 1010 process. 1012 Implementation Notes: 1014 Upon arrival of more data prompting a new Cookie exchange, there 1015 is no need to increment the previous timestamp; TCB state has not 1016 been saved at the Responder. Instead, use the saved RCV.NXT, plus 1017 one (1) for the (actual or implied) . 1019 Initiator with the Cookie-Pair option and no 1020 segment data is never required; TCB state has not been saved at 1021 the Responder. This combination MUST be silently discarded. 1023 6.4. Responder Data 1025 Upon receipt of the with a Cookie-Pair option (and 1026 verification of the Timestamps and Cookie-Pair options), the 1027 Responder SHOULD process any data present. 1029 Since the TCP Sequence and Acknowledgment Numbers have not advanced, 1030 the Responder will process the same incoming data, and transmit the 1031 same response. 1033 If the Selective Acknowledgment (Sack) option [RFC2018] has been 1034 successfully negotiated, with a short Sack covering earlier response 1035 data, only additional unacknowledged response data is sent. 1037 At this time, any second segment may be sent without awaiting an 1038 , according to the usual [RFC5681] TCP congestion control 1039 process. 1041 7. Advisory Reset 1043 When a TCB with matching Addresses and Ports is found, but the 1044 Cookie-Pair fails to verify, the datagram MUST be silently discarded. 1046 When no TCB with matching Addresses and Ports is found, a is 1047 sent as usual. The Timestamps option SHOULD be copied [RFC1323]. A 1048 Cookie-Pair option MUST also be copied. The Cookie option (or 1049 Cookie-less option) MUST NOT be copied. 1051 Any is always treated as advisory. A without a matching 1052 Cookie-Pair option could be caused by antique duplicates. Receipt 1053 has no effect on the operation of the protocol. The implementation 1054 SHOULD continue until a USER TIMEOUT expires. (See [RFC5482] for 1055 additional information.) 1057 This also inhibits third parties from disrupting communications. 1059 8. Interactions with Other Options 1061 A successful Cookie (or Cookie-less) option exchange signals 1062 availability of the TCP header extension. Other options with large 1063 data portions MAY also use this feature. The extended option data is 1064 processed in the order that the options appear. 1066 8.1. TCP Selective Acknowledgment 1068 (Kind 5 [RFC2018].) The pairs of 32-bit fields are well suited to 1069 the header extension. Because of its variable size, this is 1070 RECOMMENDED as the final extended option. 1072 During the cookie exchange, the MAY include this option to 1073 acknowledge any optional transaction response data. 1075 8.2. TCP Timestamps 1077 (Kind 8 [RFC1323].) Support is REQUIRED. See also section 3. 1079 When a segment needs no header extension, and 32-bit timestamps have 1080 been negotiated, this option MUST be sent. 1082 8.3. TCP Extensions for Transactions 1084 (Kinds 11-13 [RFC1644].) Incompatible with this specification, and 1085 MUST be ignored on receipt. 1087 8.4. TCP MD5 Signature 1089 (Kind 19 [RFC2385].) This option is beyond the scope of this 1090 specification. Because specific configuration is required, sending 1091 is under the complete control of the operator. Segments lacking this 1092 option will be silently discarded. 1094 The size of the option itself precludes use with the Cookie option in 1095 the . Regardless of the system default, the Cookie option MUST 1096 NOT be sent, and MUST be ignored on receipt. Instead, the Cookie- 1097 less extension option indicates that other features of this 1098 specification are available. 1100 8.5. TCP Authentication 1102 (Kind 29 [RFC5925].) This option is beyond the scope of this 1103 specification. Because specific configuration is required, sending 1104 is under the complete control of the operator. Segments lacking this 1105 option will be silently discarded. 1107 The size of the option itself precludes use with the Cookie option in 1108 the . Regardless of the system default, the Cookie option MUST 1109 NOT be sent, and MUST be ignored on receipt. Instead, the Cookie- 1110 less extension option indicates that other features of this 1111 specification are available. 1113 History 1115 T/TCP [RFC1379] [RFC1644] permits lightweight TCP transactions for 1116 applications that traditionally have used UDP. However, T/TCP has 1117 unacceptable security issues [Hannum1996] [Phrack1998]. 1119 The initial specification [KS1995] of Photuris [RFC2522], now called 1120 version 1 (December 1994 to March 1995), was based on a short list of 1121 design requirements, and simple experimental code by Phil Karn. A 1122 "Cookie" Exchange guards against simple flooding attacks sent with 1123 bogus IP Sources or UDP Ports. 1125 During 1995, the Photuris efficient secret rollover and many other 1126 extensions were specified. Multiple interoperable implementations 1127 were produced. 1129 By September 1996, the long anticipated Denial of Service (DoS) 1130 attacks in the form of TCP SYN floods were devastating popular (and 1131 unpopular) servers and sites. Phil Karn informally mentioned 1132 adapting anti-clogging cookies to TCP. Perry Metzger proposed adding 1133 Karn's cookies as part of a "TCP++" effort [Metzger1996]. 1135 Later in 1996, Daniel J. Bernstein implemented "SYN cookies", small 1136 cookies embedded in the TCP SYN Initial Sequence Number (ISN). This 1137 technique was exceptionally clever, because it did not require 1138 cooperation of the remote party and could be deployed unilaterally. 1139 However, SYN cookies can only be used in emergencies; they are 1140 incompatible with most TCP options. As there is insufficient space 1141 in the Sequence Number, the cookie is not considered cryptologically 1142 secure. Therefore, the mechanism remains inactive until the system 1143 is under attack, and thus is not well tested in operation. SYN 1144 cookies were not accepted for publication until recently [RFC4987]. 1146 In 1998, Perry Metzger proposed adding Karn's cookies as part of a 1147 "TCPng" discussion [Metzger1998]. 1149 In 1999, Faber, Touch, and Yue [FTY1999] proposed using an option to 1150 negotiate the party that would maintain TIME-WAIT state. This 1151 permits a server to entirely eliminate state after closing a 1152 connection. 1154 In 2000, the Stream Control Transmission Protocol (SCTP) [RFC2960] 1155 was published with an inadequate partial cookie mechanism claiming to 1156 be based upon Photuris. It featured a deficient checksum (replaced 1157 in 2002 by [RFC3309] without graceful transition), and has undergone 1158 subsequent revisions [RFC4960]. 1160 In 2006, the Datagram Congestion Control Protocol (DCCP) [RFC4340] 1161 was published with a mechanism analogous to SYN cookies. 1163 Acknowledgments 1165 Andre Broido informally described utilizing cookies for Transport 1166 Layer Security (TLS) session identifiers, in place of the [RFC5077] 1167 ticket. Rapid TLS session resumption would improve both latency and 1168 privacy, but is beyond the scope of this specification. Also, he 1169 provided numerous helpful comments and additional references, such as 1170 [KBC2005]. 1172 H. K. Jerry Chu and Arvind Jain informally described retaining 1173 existing cookies for accelerated open on subsequent connections. 1174 That feature was subsumed by this specification. 1176 Wesley M. Eddy and Adam Langley previously proposed another pair of 1177 options [EL2008] extending the TCP header option space. 1179 Adam Langley previously proposed another option [Langley2008] 1180 permitting constant payload data. His (August 2008) 1181 code was a base for the initial TCPCT implementation. 1183 Joe Touch postulated a (hopefully hypothetical) failure mode: options 1184 re-ordered by middleware. This caused a change in specifications, 1185 and has considerably complicated option interactions and processing. 1186 His helpful comments were appreciated. 1188 Many thanks to Fernando Gont for suggestions, and Rick Jones for 1189 performance testing. 1191 IESG Considerations 1193 Two TCP Option numbers are reserved for general experimental use 1194 under the rules laid out in [RFC4727] and [RFC3692] section 1. Such 1195 values reserved for experimental use are never to be made permanent; 1196 permanent assignments should be obtained through standard processes. 1197 Experimental numbers are intended for experimentation and testing and 1198 are not intended for wide or general deployments. 1200 For further information, contact the author. 1202 Operational Considerations 1204 Any implementation of this specification SHOULD be configurable, 1205 separately for each port or connection. 1207 TCPCT_COOKIE_DESIRED 1208 Values: 0 (disabled), 8, 10, 12, 14, 16. Default: 16. Send the 1209 Cookie option with the . 1211 TCPCT_EXTEND_TS[32|64|128] 1212 Default: off. If defined, may designate 32-bit, 64-bit, or 1213 128-bit timestamps extension. 1215 TCPCT_IN_ALWAYS 1216 Default: off. Silently discard any incoming that is missing 1217 the Cookie option. 1219 TCPCT_OUT_NEVER 1220 Default: off. Refuse to send (override) the Cookie option. 1222 TCP_SYN_DATA_LIMIT 1223 Default: 0. Maximum: 496. The maximum amount of data transmitted 1224 with the . Wait for data before sending. 1226 TCP_SYN_ACK_DATA_LIMIT 1227 Default: 0. Maximum: 1220. The maximum amount of data 1228 transmitted with the . Wait for data before 1229 sending. 1231 Security Considerations 1233 TCPCT was based on currently available tools, by experienced network 1234 protocol designers with an interest in cryptography, rather than by 1235 cryptographers with an interest in network protocols. This 1236 specification is intended to be readily implementable without 1237 requiring an extensive background in cryptology. 1239 Therefore, only minimal background cryptologic discussion and 1240 rationale is included in this document. Although some review has 1241 been provided by the general cryptologic community, it is anticipated 1242 that design decisions and tradeoffs will be thoroughly analysed in 1243 subsequent dissertations and debated for many years to come. 1244 Cryptologic details are reserved for separate documents that may be 1245 more readily and timely updated with new analysis. 1247 The security depends on the quality of the random numbers generated 1248 by each party. Generating cryptographic quality random numbers on a 1249 general purpose computer without hardware assistance is a very tricky 1250 problem (see [RFC4086] for discussion). 1252 TCPCT is not intended to prevent or recover from all possible 1253 security threats. Rather, it is designed to inhibit inadvertent 1254 middlebox interference, while protecting against Denial of Service 1255 (DoS) attacks. (See [RFC4732], and [RFC3552] section 4.6.3 et seq.) 1257 The cookie exchange does not protect against an interloper that can 1258 race to substitute another value, nor an interceptor that can modify 1259 and/or replace a value. These attacks are considerably more 1260 difficult than passive vacuum-cleaner monitoring. 1262 Note that each incoming replaces the Responder cookie. 1263 The initial exchange is most fragile, as protection against spoofing 1264 relies entirely upon the sequence and timestamp. This replacement 1265 strategy allows the correct pair to pass through, while any others 1266 will be filtered via Responder verification later. 1268 A. Example Headers 1269 A.1. Example 1271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1272 | Kind=MSS | Length=4 | (value) | 1273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1274 | Kind=UTO | Length=4 | (timeout) | 1275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1276 | Kind=SackOK | Length=2 | Kind=TS | Length=10 | 1277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1278 | TS Value | 1279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1280 | TS Echo Reply | 1281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1282 | Kind=Cookie | Length=16 | | 1283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1284 | | 1285 + Cookie + 1286 | | 1287 + + 1288 | | 1289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1290 | Kind=wscale | Length=3 | (value) | Kind=EOL | 1291 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1293 A 14 byte (112-bit) Cookie barely fits with the other recommended 1294 options in the maximal 60 byte TCP header (40 bytes of option space). 1296 Since the cookies are required to be the same size and meet a 32-bit 1297 alignment requirement, the implementor recognizes that this order 1298 provides optimal packing. 1300 The UserTimeOut (UTO) option can appear in other locations instead, 1301 such as following the Cookie option. Because some middleboxes are 1302 sensitive to the order of options, UTO should not appear before MSS 1303 nor between the TS and Cookie. 1305 A.2. Example with Sack 1307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1308 | Kind=TSX | Length=4 | Extend=16 | 0 | S=1 | 1309 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1310 | TS Value | 1311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1312 | TS Echo Reply | 1313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1314 | Kind=nop | Kind=nop | Kind=Cookie | Length=30 | 1315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1316 | | 1317 + + 1318 | | 1319 + Initiator-Cookie + 1320 | | 1321 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1322 | | | 1323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1324 | | 1325 + Responder-Cookie + 1326 | | 1327 + + 1328 | | 1329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1330 | Kind=MSS | Length=4 | (value) | 1331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1332 | Kind=UTO | Length=4 | (timeout) | 1333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1334 | Kind=nop | Kind=nop | Kind=Sack | Length=10 | 1335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1336 | Starting Value | 1337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1338 | Ending Value | 1339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1340 | Kind=wscale | Length=3 | (value) | Kind=EOL | 1341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1342 Sack implies SackOK. 1344 A.3. Example with 64-bit Timestamps 1346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1347 | Kind=TSX | Length=4 | Extend=15 | 0 | S=2 | 1348 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1349 | | 1350 + TS Value + 1351 | | 1352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1353 | | 1354 + TS Echo Reply + 1355 | | 1356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1357 | Kind=SackOK | Length=2 | Kind=Cookie | Length=30 | 1358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1359 | | 1360 + + 1361 | | 1362 + Initiator-Cookie + 1363 | | 1364 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1365 | | | 1366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1367 | | 1368 + Responder-Cookie + 1369 | | 1370 + + 1371 | | 1372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1373 | Kind=MSS | Length=4 | (value) | 1374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1375 | Kind=UTO | Length=4 | (timeout) | 1376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1377 | Kind=wscale | Length=3 | (value) | Kind=EOL | 1378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1380 The larger 64-bit (or 128-bit) Timestamps extended option MUST be 1381 recognized, although the Responder MAY return a smaller Timestamps 1382 extended option. 1384 Normative References 1386 [RFC791] Postel, J., "Internet Protocol", STD 5, September 1981. 1388 [RFC793] Postel, J., "Transmission Control Protocol", STD 7, 1389 September 1981. 1391 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -- 1392 Communication Layers", STD 3, October 1989. 1394 [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions 1395 for High Performance", May 1992. 1397 [RFC1948] Bellovin, S., "Defending Against Sequence Number 1398 Attacks", May 1996. 1400 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 1401 Selective Acknowledgment Options", October 1996. 1403 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1404 Requirement Levels", BCP 14, March 1997. 1406 [RFC2988] Paxson, V., and M. Allman, "Computing TCP's 1407 Retransmission Timer", November 2000. 1409 [RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is 1410 Replaced by an On-line Database", January 2002. 1412 http://www.iana.org/assignments/port-numbers 1414 [RFC5452] Hubert, A., and R. van Mook, "Measures for Making DNS 1415 More Resilient against Forged Answers", January 2009. 1417 [RFC5482] Eggert, L., and F. Gont, "TCP User Timeout Option", March 1418 2009. 1420 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 1421 Control", September 2009. 1423 Informative References 1425 [EL2008] Eddy, W., and A. Langley, "Extending the Space Available 1426 for TCP Options", work in progress, July 1, 2008. 1428 [FTY1999] Faber, T., Touch, J., and W. Yue, "The TIME-WAIT state in 1429 TCP and Its Effect on Busy Servers", IEEE INFOCOM 99, pp. 1430 1573-1584. 1432 [Gont2009] Gont, F., "Security assessment of the Transmission 1433 Control Protocol (TCP)", February 2009. 1434 https://www.cpni.gov.uk/Docs/tn-03-09-security- 1435 assessment-TCP.pdf 1437 [GO2010] Gont, F., and A. Oppermann, "On the generation of TCP 1438 timestamps", work in progress, June 2010. 1440 [Hannum1996] 1441 Hannum, C., "Security Problems Associated With T/TCP", 1442 unpublished work in progress, September 1996. 1443 http://www.mid-way.org/doc/ttcp-sec.txt 1445 [KBC2005] Kohno, T., Broido, A., and K. C. Claffy, "Remote physical 1446 device fingerprinting", IEEE Symposium on Security and 1447 Privacy, May 2005. http://www.caida.org/ 1448 outreach/papers/2005/fingerprinting/ 1449 KohnoBroidoClaffy05-devicefingerprinting.pdf 1451 [KS1995] Karn, P., and W. Simpson, "The Photuris Session Key 1452 Management Protocol", March 1995. draft-karn- 1453 photuris-01.txt 1455 Published as: "Photuris: Design Criteria", Proceedings of 1456 Sixth Annual Workshop on Selected Areas in Cryptography, 1457 LNCS 1758, Springer-Verlag. August 1999. 1459 [Langley2008] 1460 Langley, A., "Faster application handshakes with SYN/ACK 1461 payloads", work in progress, August 5, 2008. 1463 [LG2010] Larson, M., and F. Gont, "Transport Protocol Port 1464 Randomization Recommendations", work in progress, August 1465 2010. 1467 [MAF2004] Medina, A., Allman, M., and S. Floyd, "Measuring 1468 Interactions Between Transport Protocols and 1469 Middleboxes", Proceedings 4th ACM SIGCOMM/USENIX 1470 Conference on Internet Measurement, October 2004. 1472 http://www.icsi.berkeley.edu/pubs/networking/tbit- 1473 Aug2004.pdf 1475 [Metzger1996] 1476 Metzger, P., "Re: SYN floods (was: does history repeat 1477 itself?)", September 9, 1996. 1478 http://www.merit.net/mail.archives/nanog/ 1479 1996-09/msg00235.html 1481 [Metzger1998] 1482 Metzger, P., "Re: what a new TCP header might look like", 1483 May 12, 1998. ftp://ftp.isi.edu/end2end/end2end- 1484 interest-1998.mail 1486 [Morris1985] 1487 Morris, R., "A Weakness in the 4.2BSD Unix TCP/IP 1488 Software", Technical Report CSTR-117, AT&T Bell 1489 Laboratories, February 1985. 1490 http://pdos.csail.mit.edu/~rtm/papers/117.pdf 1492 [MSV2009] Metzger, P., Simpson, W., and P. Vixie, "Improving TCP 1493 Security With Robust Cookies", Usenix ;login:, December 1494 2009. http://www.usenix.org/publications/login/ 1495 2009-12/openpdfs/metzger.pdf 1497 [Phrack1998] 1498 route|daemon9, "T/TCP vulnerabilities", Phrack Magazine, 1499 Volume 8, Issue 53, July 8, 1998. 1500 http://www.phrack.org/issues.html?issue=53&id=6 1502 [rfc1323bis] 1503 Borman, D., Braden, R., and V. Jacobson, "TCP Extensions 1504 for High Performance", work in progress, March 2009. 1506 [RFC1379] Braden, R., "Extending TCP for Transactions -- Concepts", 1507 November 1992. 1509 [RFC1644] Braden, R., "T/TCP -- TCP Extensions for Transactions -- 1510 Functional Specification", July 1994. 1512 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP 1513 MD5 Signature Option", August 1998. 1515 [RFC2522] Karn, P., and W. Simpson, "Photuris: Session-Key 1516 Management Protocol", March 1999. 1518 [RFC2827] Ferguson, P., and D. Senie, "Network Ingress Filtering: 1519 Defeating Denial of Service Attacks which employ IP 1520 Source Address Spoofing", BCP 38, May 2000. 1522 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 1523 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 1524 Zhang, L., and V. Paxson, "Stream Control Transmission 1525 Protocol", October 2000. 1527 [RFC3022] Srisuresh, P., and K. Egevang, "Traditional IP Network 1528 Address Translator (Traditional NAT)", January 2001. 1530 [RFC3234] Carpenter, B., and S. Brim, "Middleboxes: Taxonomy and 1531 Issues", February 2002. 1533 [RFC3309] Stone, J., Stewart, R., and D. Otis, "Stream Control 1534 Transmission Protocol (SCTP) Checksum Change", September 1535 2002. 1537 [RFC3552] Rescorla, E., and B. Korver, "Guidelines for Writing RFC 1538 Text on Security Considerations", BCP 72, July 2003. 1540 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 1541 Considered Useful", BCP 82, January 2004. 1543 [RFC3704] Baker, F., and P. Savola, "Ingress Filtering for 1544 Multihomed Networks", BCP 84, March 2004. 1546 [RFC4086] Eastlake, D. (3rd), Schiller, J., and S. Crocker, 1547 "Randomness Requirements for Security", BCP 106, June 1548 2005. 1550 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1551 Congestion Control Protocol (DCCP)", March 2006. 1553 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 1554 ICMPv6, UDP, and TCP Headers", November 2006. 1556 [RFC4732] Handley, M., Rescorla, E., Eds., and Internet 1557 Architecture Board, "Internet Denial-of-Service 1558 Considerations", November 2006. 1560 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", July 1561 2007. 1563 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1564 September 2007. 1566 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 1567 Mitigations", August 2007. 1569 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1570 "Transport Layer Security (TLS) Session Resumption 1571 without Server-Side State", January 2008. 1573 [RFC5358] Damas, J., and F. Neves, "Preventing Use of Recursive 1574 Nameservers in Reflector Attacks", BCP 140, October 2008. 1576 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1577 Authentication Option", June 2010. 1579 Author's Address 1581 Questions about this document can be directed to: 1583 William Allen Simpson 1584 DayDreamer 1585 Computer Systems Consulting Services 1586 1384 Fontaine 1587 Madison Heights, Michigan 48071 1589 William.Allen.Simpson@Gmail.com