idnits 2.17.1 draft-gont-tcpm-tcp-seq-validation-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC793, updated by this document, for RFC5378 checks: 1981-09-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 5, 2018) is 2237 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCP Maintenance and Minor Extensions F. Gont 3 (tcpm) UTN-FRH / SI6 Networks 4 Internet-Draft D. Borman 5 Updates: 793 (if approved) Quantum Corporation 6 Intended status: Standards Track March 5, 2018 7 Expires: September 6, 2018 9 On the Validation of TCP Sequence Numbers 10 draft-gont-tcpm-tcp-seq-validation-03.txt 12 Abstract 14 When TCP receives packets that lie outside of the receive window, the 15 corresponding packets are dropped and either an ACK, RST or no 16 response is generated due to the out-of-window packet, with no 17 further processing of the packet. Most of the time, this works just 18 fine and TCP remains stable, especially when a TCP connection has 19 unidirectional data flow. However, there are three scenarios in 20 which packets that are outside of the receive window should still 21 have their ACK field processed, or else a packet war will take place. 22 The aforementioned issues have affected a number of popular TCP 23 implementations, typically leading to connection failures, system 24 crashes, or other undesirable behaviors. This document describes the 25 three scenarios in which the aforementioned issues might arise, and 26 formally updates RFC 793 such that these potential problems are 27 mitigated. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 6, 2018. 46 Copyright Notice 48 Copyright (c) 2018 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. TCP Sequence Number Validation . . . . . . . . . . . . . . . . 3 65 3. Scenarios in which Undesirable Behaviors Might Arise . . . . . 4 66 3.1. TCP simultaneous open . . . . . . . . . . . . . . . . . . 4 67 3.2. TCP self connects . . . . . . . . . . . . . . . . . . . . 5 68 3.3. TCP simultaneous close . . . . . . . . . . . . . . . . . . 6 69 3.4. Simultaneous Window Probes . . . . . . . . . . . . . . . . 8 70 4. Updating RFC 793 . . . . . . . . . . . . . . . . . . . . . . . 9 71 4.1. TCP sequence number validation . . . . . . . . . . . . . . 9 72 4.2. Alternative fix for TCP sequene number validation . . . . 14 73 4.3. TCP self connects . . . . . . . . . . . . . . . . . . . . 14 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 79 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 82 1. Introduction 84 TCP processes incoming packets in in-sequence order. Packets that 85 are not in-sequence but have data that lies in the receive window are 86 queued for later processing. Packets that lie outside of the receive 87 window are dropped and either an ACK, RST or no response is generated 88 due to the out-of-window packet, with no further processing of the 89 packet. Most of the time, this works just fine and TCP remains 90 stable, especially when a TCP connection has unidirectional data 91 flow. 93 However, there are three situations in which packets that are outside 94 of the receive window should still have their ACK field processed. 95 These situations arise during a simultaneous open, simultaneous 96 window probes and a simultaneous close. In all three of these cases, 97 a packet will arrive with a sequence number that is one to the left 98 of the window, but the acknowledgement field has updated information 99 that needs to be processed to avoid entering a packet war, in which 100 both sides of the connection generate a response to the received 101 packet, which just causes the other side to do the same thing. This 102 issue has affected a number of popular TCP implementations, typically 103 leading to connection failures, system crashes, or other undesirable 104 behaviors. 106 Section 2 provides an overview of the TCP sequence number validation 107 checks specified in RFC 793. Section 3 describes the three scenarios 108 in which the current TCP sequence number validation checks can lead 109 to undesirable behaviors. Section 4 formally updates RFC 793 such 110 that these issues are mitigated. 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC 2119 [RFC2119]. 116 2. TCP Sequence Number Validation 118 Section 3.3 of RFC 793 [RFC0793] specifies (in pp. 25-26) how the TCP 119 sequence number of incoming segments is to be validated. It 120 summarizes the validation of the TCP sequence number with the 121 following table: 123 Segment Receive Test 124 Length Window 125 ------- ------- ------------------------------------------- 127 0 0 SEG.SEQ = RCV.NXT 129 0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND 131 >0 0 not acceptable 133 >0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND 134 or RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND 136 RFC 793 states that if an incoming segment is not acceptable, an 137 acknowledgment should be sent in reply (unless the RST bit is set), 138 and that after sending the acknowledgment, the unacceptable segment 139 should be dropped. 141 Section 3.9 of RFC 793 repeats (in pp. 69-76) the same validation 142 checks when describing the processing of incoming TCP segments meant 143 for connections that are in the SYN-RECEIVED, ESTABLISHED, 144 FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, or TIME-WAIT 145 states (i.e., any state other than CLOSED, LISTEN, or SYN-SENT). 147 A key problem with the aforementioned checks is that it assumes that 148 a segment must be processed only if a portion of it overlaps with the 149 receive window. However, there are some cases in which the 150 Acknowledgement information in an incoming segment needs to be 151 processed by TCP even if the contents of the segment does not overlap 152 with the receive window. Otherwise, the TCP state machine may become 153 dead-locked, and this situation may result in undesirable behaviors 154 such as system crashes. 156 3. Scenarios in which Undesirable Behaviors Might Arise 158 The following subsections describe the three scenarios in which the 159 TCP Sequence Number validation specified n RFC 793 (and described in 160 Section 2 of this document) could result in undesirable behaviors. 162 3.1. TCP simultaneous open 164 The following figure illustrates a typical "simultaneous open" 165 attempt. 167 TCP A TCP B 169 1. CLOSED CLOSED 171 2. SYN-SENT --> ... 173 3. SYN-RECEIVED <-- <-- SYN-SENT 175 4. ... --> SYN-RECEIVED 177 5. --> ... 179 6. <-- <-- 181 7. ... --> 183 8. --> ... 185 9. <-- <-- 187 10. ... --> 189 (Failed) Simultaneous Connection Synchronization 191 In line 2, TCP A performs an "active open" by sending a SYN segment 192 to TCP B, and enters the SYN-SENT state. In line 3, TCP B performs 193 an "active open" by sending a SYN segment to TCP A, and enters the 194 "SYN-SENT" state; when TCP A receives this SYN segment sent by TCP B, 195 it enters the SYN-RECEIVED state, and its RCV.NXT becomes 301. In 196 line 4, similarly, when TCP B receives the SYN segment sent by TCP A, 197 it enters the SYN-RECEIVED STATE and its RCV.NXT becomes 101. In 198 line 5, TCP A sends a SYN/ACK in response to the received SYN segment 199 from line 3. In line 6, TCP B sends a SYN/ACK in response to the 200 received SYN segment from line 4. In line 7, TCP B receives the SYN/ 201 ACK from line 5. In line 8, TCP A receives the SYN/ACK from line 6, 202 which fails the TCP Sequence Number validation check. As a result, 203 the received packet is dropped, and a SYN/ACK is sent in response. 204 In line 9, TCP B processes the SYN/ACK from line 7, which fails the 205 TCP Sequence Number validation check. As a result, the received 206 packet is dropped, and a SYN/ACK is sent in response. In line 10, 207 the SYN/ACK from line 9 arrives at TCP B. The segment exchange from 208 lines 8-10 will continue forever (with both TCP end-points will be 209 stuck in the SYN-RECEIVED state), thus leading to a SYN/ACK war. 211 3.2. TCP self connects 213 Some systems have been found to be unable to process TCP connection 214 requests in which the source endpoint {Source Address, Source Port} 215 is the same as the destination end-point {Destination Address, 216 Destination Port}. Such a scenario might arise e.g. if a process 217 creates a socket, bind()s a local end-point (IP address and TCP 218 port), and then issues a connect() to the same end-point as that 219 specified to bind(). 221 While not widely employed in existing applications, such a socket 222 could be employed as a "full-duplex pipe" for Inter-Process 223 Communication (IPC). 225 This scenario is described in detail in pp. 960-962 of 226 [Wright1994]. 228 The aforementioned scenario has been reported to cause malfunction of 229 a number of implementations [CERT1996], and has been exploited in the 230 past to perform Denial of Service (DoS) attacks [Meltman1997] 231 [CPNI-TCP]. 233 While this scenario is not common in the real world, TCP should 234 nevertheless be able to process them without the need of any "extra" 235 code: a SYN segment in which the source end-point {Source Address, 236 Source Port} is the same as the destination end-point {Destination 237 Address, Destination Port} should result in a "simultaneous open" 238 scenario, such as the one described in page 32 of RFC 793 [RFC0793]. 239 Therefore, those TCP implementations that correctly handle 240 simultaneous opens should already be prepared to handle these unusual 241 TCP segments. 243 3.3. TCP simultaneous close 245 The following figure illustrates a typical "simultaneous close" 246 attempt, in which the FIN segments sent by each TCP end-point cross 247 each other in the network. 249 TCP A TCP B 251 1. ESTABLISHED ESTABLISHED 253 2. FIN-WAIT-1 --> ... 255 3. CLOSING <-- <-- FIN-WAIT-1 257 4. ... --> CLOSING 259 5. --> ... 261 6. <-- <-- 263 7. ... --> 265 8. --> ... 267 9. <-- <-- 269 10. ... --> 271 (Failed) Simultaneous Connection Termination 273 In line 1, we assume that both end-points of the connection are in 274 the ESTABLISHED state. In line 2, TCP A performs an "active close" 275 by sending a FIN segment to TCP B, thus entering the FIN-WAIT-1 276 state. In line 3, TCP B performs an active close sending a FIN 277 segment to TCP A, thus entering the FIN-WAIT-1 state; when this 278 segment is processed by TCP A, it enters the CLOSING state (and its 279 RCV.NXT becomes 301). 281 Both FIN segments cross each other on the network, thus resulting 282 in a "simultaneous connection termination" (or "simultaneous 283 close") scenario. 285 In line 4, the FIN segment sent by TCP A arrives to TCP B, causing it 286 to transition to the CLOSING state (at this point, TCP B's RCV.NXT 287 becomes 101). In line 5, TCP A acknowledges the receipt of the TCP 288 B's FIN segment, and also sets the FIN bit in the outgoing segment 289 (since it has not yet been acknowledged). In line 6, TCP B 290 acknowledges the receipt of TCP A's FIN segment, and also sets the 291 FIN bit in the outgoing segment (since it has not yet been 292 acknowledged). In line 7, the FIN/ACK from line 5 arrives at TCP B. 293 In line 8, the FIN/ACK from line 6 fails the TCP sequence number 294 validation check, and thus elicits a ACK segment (the segment also 295 contains the FIN bit set, since it had not yet been acknowledged). 296 In line 9, the FIN/ACK from line 7 fails the TCP sequence number 297 validation check, and hence elicits an ACK segment (the segment also 298 contains the FIN bit set, since it had not yet been acknowledged). 299 In line 10, the FIN/ACK from line 8 finally arrives at TCP B. 301 The packet exchange from lines 8-10 will repeat indefinitely, with 302 both TCP end-points stuck in the CLOSING state, thus leading to a 303 "FIN war": each FIN/ACK segment sent by a TCP will elicit a FIN/ACK 304 from the other TCP, and each of these FIN/ACKs will in turn elicit 305 more FIN/ACKs. 307 3.4. Simultaneous Window Probes 309 The following figure illustrates a scenario in which the "persist 310 timer" at both TCP end-points expires, and both TCP end-points send a 311 "window probes" that cross each other in the network. 313 TCP A TCP B 315 1. ESTABLISHED ESTABLISHED 317 2. (both TCP windows open) 319 3. --> ... 321 4. <-- <-- 323 5. ... --> 325 6. --> ... 327 7. <-- <-- 329 8. ... --> 331 9. --> ... 333 10. <-- <-- 335 11. ... --> 337 (Failed) Simultaneous Connection Termination 339 In line 1, we assume that both end-points of the connection are in 340 the ESTABLISHED state; additionally, TCP A's RCV.NXT is 300, while 341 TCP B's RCV.NXT is 100, and the receive window (RCV.WND) at both TCP 342 end-points is 0. In line 2, both TCP windows open. In line 3, the 343 "persist timer" at TCP A expires, and hence TCP A sends a "Window 344 Probe". In line 4, the "persist timer" at TCP B expires, and hence 345 TCP B sends a "Window Probe". 347 Both Window Probes cross each other in the network. 349 When this probe arrives at TCP A, TCP a's RCV.NXT becomes 301, and an 350 ACK segment is sent to advertise the new window (this ACK is shown in 351 line 6). In line 5, TCP A's Window Probe from line 3 arrives at TCP 352 B. TCP B's RCV-WND becomes 101. In line 6, TCP A sends the ACK to 353 advertise the new window. In line 7, TCP B sends an ACK to advertise 354 the new Window. When this ACK arrives at TCP A, the TCP Sequence 355 Number validation fails, since SEG.SEQ=300 and RCV.NXT=301. 356 Therefore, this segment elicits a new ACK (meant to re-synchronize 357 the sequence numbers). In line 8, the ACK from line 6 arrives at TCP 358 B. The TCP sequence number validation for this segment fails, since 359 SEG.SEQ=100 AND RCV.NXT=101. Therefore, this segment elicits a new 360 ACK (meant to re-synchronize the sequence numbers). 362 Line 9 and line 11 shows the ACK elicited by the segment from line 7, 363 while line 10 shows the ACK elicited by the segment from line 8. The 364 sequence numbers of these ACK segments will be considered invalid, 365 and hence will elicit further ACKs. Therefore, the segment exchange 366 from lines 9-11 will repeat indefinitely, thus leading to an "ACK 367 war". 369 4. Updating RFC 793 371 4.1. TCP sequence number validation 373 The following text from Section 3.3 (pp. 25-26) of [RFC0793]: 375 ---------------- cut here -------------- cut here ---------------- 377 A segment is judged to occupy a portion of valid receive sequence 378 space if 380 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND 382 or 384 RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND 386 The first part of this test checks to see if the beginning of the 387 segment falls in the window, the second part of the test checks to see 388 if the end of the segment falls in the window; if the segment passes 389 either part of the test it contains data in the window. 391 Actually, it is a little more complicated than this. Due to zero 392 windows and zero length segments, we have four cases for the 393 acceptability of an incoming segment: 395 Segment Receive Test 396 Length Window 397 ------- ------- ------------------------------------------- 399 0 0 SEG.SEQ = RCV.NXT 401 0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND 403 >0 0 not acceptable 405 >0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND 406 or RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND 408 ---------------- cut here -------------- cut here ---------------- 410 is replaced with: 412 ---------------- cut here -------------- cut here ---------------- 413 A segment is judged to occupy a portion of valid receive sequence 414 space if 416 RCV.NXT-1 =< SEG.SEQ < RCV.NXT+RCV.WND 418 or 420 RCV.NXT-1 =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND 422 The first part of this test checks to see if the beginning of the 423 segment falls in the window (or one byte to the left to the window), 424 the second part of the test checks to see if the end of the segment 425 falls in the window (or one byte to the left of the window); if the 426 segment passes either part of the test it contains data in the 427 window or control information that needs to be processed by TCP. 429 Actually, it is a little more complicated than this. Due to zero 430 windows and zero length segments, we have four cases for the 431 acceptability of an incoming segment: 433 Segment Receive Test 434 Length Window 435 ------- ------- ------------------------------------------- 437 0 0 RCV.NXT-1 =< SEG.SEQ <= RCV.NXT 439 0 >0 RCV.NXT-1 =< SEG.SEQ < RCV.NXT+RCV.WND 441 >0 0 not acceptable 443 >0 >0 RCV.NXT-1 =< SEG.SEQ < RCV.NXT+RCV.WND 444 or RCV.NXT-1 =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND 446 ---------------- cut here -------------- cut here ---------------- 448 Additionally, the following text from Section 3.9 (pp.69-70) of 449 [RFC0793]: 451 ---------------- cut here -------------- cut here ---------------- 453 Segments are processed in sequence. Initial tests on arrival 454 are used to discard old duplicates, but further processing is 455 done in SEG.SEQ order. If a segment's contents straddle the 456 boundary between old and new, only the new parts should be 457 processed. 459 There are four cases for the acceptability test for an incoming 460 segment: 462 Segment Receive Test 463 Length Window 464 ------- ------- ------------------------------------------- 466 0 0 SEG.SEQ = RCV.NXT 468 0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND 470 >0 0 not acceptable 472 >0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND 473 or RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND 475 If the RCV.WND is zero, no segments will be acceptable, but 476 special allowance should be made to accept valid ACKs, URGs and 477 RSTs. 479 If an incoming segment is not acceptable, an acknowledgment 480 should be sent in reply (unless the RST bit is set, if so drop 481 the segment and return): 483 485 After sending the acknowledgment, drop the unacceptable segment 486 and return. 488 In the following it is assumed that the segment is the idealized 489 segment that begins at RCV.NXT and does not exceed the window. 490 One could tailor actual segments to fit this assumption by 491 trimming off any portions that lie outside the window (including 492 SYN and FIN), and only processing further if the segment then 493 begins at RCV.NXT. Segments with higher beginning sequence 494 numbers may be held for later processing. 495 ---------------- cut here -------------- cut here ---------------- 497 is replaced with: 499 ---------------- cut here -------------- cut here ---------------- 500 Segments are processed in sequence. Initial tests on arrival 501 are used to discard old duplicates, but further processing is 502 done in SEG.SEQ order. If a segment's contents straddle the 503 boundary between old and new, only the new parts should be 504 processed. Acknowledgement information must still be processed 505 when the contents of the incoming segment are one byte to the 506 left of the receive window. 508 This is to handle simultaneous opens, simultaneous closes, 509 and simultaneous window probes. 511 There are four cases for the acceptability test for an incoming 512 segment: 514 Segment Receive Test 515 Length Window 516 ------- ------- ------------------------------------------- 518 0 0 RCV.NXT-1 =< SEG.SEQ <= RCV.NXT 520 0 >0 RCV.NXT-1 =< SEG.SEQ < RCV.NXT+RCV.WND 522 >0 0 not acceptable 524 >0 >0 RCV.NXT-1 =< SEG.SEQ < RCV.NXT+RCV.WND 525 or RCV.NXT-1 =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND 527 If the RCV.WND is zero, no segments will be acceptable, but 528 special allowance should be made to accept valid ACKs, URGs and 529 RSTs. 531 If an incoming segment is not acceptable, an acknowledgment 532 should be sent in reply (unless the RST bit is set, if so drop 533 the segment and return): 535 537 After sending the acknowledgment, drop the unacceptable segment 538 and return. 540 In the following it is assumed that the segment is the idealized 541 segment that begins at RCV.NXT and does not exceed the window. 542 One could tailor actual segments to fit this assumption by 543 trimming off any portions that lie outside the window (including 544 SYN and FIN). Segments with higher beginning sequence numbers may 545 be held for later processing. Acknowledgement information must 546 still be processed when the contents of the incoming segment are 547 one byte to the left of the receive window. 548 ---------------- cut here -------------- cut here ---------------- 550 4.2. Alternative fix for TCP sequene number validation 552 The Linux kernel performs a slightly different TCP sequence number 553 validation check, in that, during window probes, can acommodate 554 window probes of any size (as opposed to the defacto standard 1-byte 555 window probes). This makes the code more general, at the expense of 556 additional state in the TCB (e.g., the TCP sequence number employed 557 in the last window probe). 559 4.3. TCP self connects 561 TCP MUST be able to gracefully handle connection requests (i.e., SYN 562 segments) in which the source end-point (IP Source Address, TCP 563 Source Port) is the same as the destination end-point (IP Destination 564 Address, TCP Destination Port). Such segments MUST result in a TCP 565 "simultaneous open", such as the one described in page 32 of RFC 793 566 [RFC0793]. 568 Those TCP implementations that correctly handle simultaneous opens 569 are expected to gracefully handle this scenario. 571 5. IANA Considerations 573 This document has no IANA actions. The RFC Editor is requested to 574 remove this section before publishing this document as an RFC. 576 6. Security Considerations 578 This document describes a problem found in the current validation 579 rules for TCP sequence numbers. The aforementioned problem has 580 affected some popular TCP implementations, typically leads to 581 connection failures, system crashes, or other undesirable behaviors. 582 This document formally updates RFC 793, such that the aforementioned 583 issues are eliminated. 585 7. Acknowledgements 587 Thhe authors of this document would like to thank Rui Paulo and 588 Michael Scharf for providing valuable comments on earlier versions of 589 this document. 591 8. References 593 8.1. Normative References 595 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 596 RFC 793, DOI 10.17487/RFC0793, September 1981, 597 . 599 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 600 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 601 RFC2119, March 1997, 602 . 604 8.2. Informative References 606 [CERT1996] 607 CERT, "CERT Advisory CA-1996-21: TCP SYN Flooding and IP 608 Spoofing Attacks", 1996, 609 . 611 [CPNI-TCP] 612 Gont, F., "CPNI Technical Note 3/2009: Security Assessment 613 of the Transmission Control Protocol (TCP)", 2009, . 617 [Meltman1997] 618 Meltman, "new TCP/IP bug in win95. Post to the bugtraq 619 mailing-list", 1996, 620 . 622 [Wright1994] 623 Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2: 624 The Implementation", Addison-Wesley, 1994. 626 Authors' Addresses 628 Fernando Gont 629 UTN-FRH / SI6 Networks 630 Evaristo Carriego 2644 631 Haedo, Provincia de Buenos Aires 1706 632 Argentina 634 Phone: +54 11 4650 8472 635 Email: fgont@si6networks.com 636 URI: http://www.si6networks.com 637 David Borman 638 Quantum Corporation 639 1155 Centre Pointe Drive, Suite 1 640 Mendota Heights, MN 55120 641 U.S.A. 643 Phone: 651-688-4394 644 Email: david.borman@quantum.com