idnits 2.17.1 draft-gont-tcpm-tcp-seq-validation-04.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 11, 2019) is 1866 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 (tcpm) F. Gont 3 Internet-Draft UTN-FRH / SI6 Networks 4 Updates: 793 (if approved) D. Borman 5 Intended status: Standards Track Quantum Corporation 6 Expires: September 12, 2019 March 11, 2019 8 On the Validation of TCP Sequence Numbers 9 draft-gont-tcpm-tcp-seq-validation-04.txt 11 Abstract 13 When TCP receives packets that lie outside of the receive window, the 14 corresponding packets are dropped and either an ACK, RST or no 15 response is generated due to the out-of-window packet, with no 16 further processing of the packet. Most of the time, this works just 17 fine and TCP remains stable, especially when a TCP connection has 18 unidirectional data flow. However, there are three scenarios in 19 which packets that are outside of the receive window should still 20 have their ACK field processed, or else a packet war will take place. 21 The aforementioned issues have affected a number of popular TCP 22 implementations, typically leading to connection failures, system 23 crashes, or other undesirable behaviors. This document describes the 24 three scenarios in which the aforementioned issues might arise, and 25 formally updates RFC 793 such that these potential problems are 26 mitigated. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 12, 2019. 45 Copyright Notice 47 Copyright (c) 2019 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. TCP Sequence Number Validation . . . . . . . . . . . . . . . 3 64 3. Scenarios in which Undesirable Behaviors Might Arise . . . . 4 65 3.1. TCP simultaneous open . . . . . . . . . . . . . . . . . . 4 66 3.2. TCP self connects . . . . . . . . . . . . . . . . . . . . 6 67 3.3. TCP simultaneous close . . . . . . . . . . . . . . . . . 6 68 3.4. Simultaneous Window Probes . . . . . . . . . . . . . . . 8 69 4. Updating RFC 793 . . . . . . . . . . . . . . . . . . . . . . 9 70 4.1. TCP sequence number validation . . . . . . . . . . . . . 9 71 4.2. Alternative fix for TCP sequence number validation . . . 14 72 4.3. TCP self connects . . . . . . . . . . . . . . . . . . . . 14 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 75 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 78 8.2. Informative References . . . . . . . . . . . . . . . . . 15 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 81 1. Introduction 83 TCP processes incoming packets in in-sequence order. Packets that 84 are not in-sequence but have data that lies in the receive window are 85 queued for later processing. Packets that lie outside of the receive 86 window are dropped and either an ACK, RST or no response is generated 87 due to the out-of-window packet, with no further processing of the 88 packet. Most of the time, this works just fine and TCP remains 89 stable, especially when a TCP connection has unidirectional data 90 flow. 92 However, there are three situations in which packets that are outside 93 of the receive window should still have their ACK field processed. 94 These situations arise during a simultaneous open, simultaneous 95 window probes and a simultaneous close. In all three of these cases, 96 a packet will arrive with a sequence number that is one to the left 97 of the window, but the acknowledgement field has updated information 98 that needs to be processed to avoid entering a packet war, in which 99 both sides of the connection generate a response to the received 100 packet, which just causes the other side to do the same thing. This 101 issue has affected a number of popular TCP implementations, typically 102 leading to connection failures, system crashes, or other undesirable 103 behaviors. 105 Section 2 provides an overview of the TCP sequence number validation 106 checks specified in RFC 793. Section 3 describes the three scenarios 107 in which the current TCP sequence number validation checks can lead 108 to undesirable behaviors. Section 4 formally updates RFC 793 such 109 that these issues are mitigated. 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC 2119 [RFC2119]. 115 2. TCP Sequence Number Validation 117 Section 3.3 of RFC 793 [RFC0793] specifies (in pp. 25-26) how the TCP 118 sequence number of incoming segments is to be validated. It 119 summarizes the validation of the TCP sequence number with the 120 following table: 122 Segment Receive Test 123 Length Window 124 ------- ------- ------------------------------------------- 126 0 0 SEG.SEQ = RCV.NXT 128 0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND 130 >0 0 not acceptable 132 >0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND 133 or RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND 135 RFC 793 states that if an incoming segment is not acceptable, an 136 acknowledgment should be sent in reply (unless the RST bit is set), 137 and that after sending the acknowledgment, the unacceptable segment 138 should be dropped. 140 Section 3.9 of RFC 793 repeats (in pp. 69-76) the same validation 141 checks when describing the processing of incoming TCP segments meant 142 for connections that are in the SYN-RECEIVED, ESTABLISHED, FIN-WAIT- 143 1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, or TIME-WAIT states 144 (i.e., any state other than CLOSED, LISTEN, or SYN-SENT). 146 A key problem with the aforementioned checks is that it assumes that 147 a segment must be processed only if a portion of it overlaps with the 148 receive window. However, there are some cases in which the 149 Acknowledgement information in an incoming segment needs to be 150 processed by TCP even if the contents of the segment does not overlap 151 with the receive window. Otherwise, the TCP state machine may become 152 dead-locked, and this situation may result in undesirable behaviors 153 such as system crashes. 155 3. Scenarios in which Undesirable Behaviors Might Arise 157 The following subsections describe the three scenarios in which the 158 TCP Sequence Number validation specified n RFC 793 (and described in 159 Section 2 of this document) could result in undesirable behaviors. 161 3.1. TCP simultaneous open 163 The following figure illustrates a typical "simultaneous open" 164 attempt. 166 TCP A TCP B 168 1. CLOSED CLOSED 170 2. SYN-SENT --> ... 172 3. SYN-RECEIVED <-- <-- SYN-SENT 174 4. ... --> SYN-RECEIVED 176 5. --> ... 178 6. <-- <-- 180 7. ... --> 182 8. --> ... 184 9. <-- <-- 186 10. ... --> 188 (Failed) Simultaneous Connection Synchronization 190 In line 2, TCP A performs an "active open" by sending a SYN segment 191 to TCP B, and enters the SYN-SENT state. In line 3, TCP B performs 192 an "active open" by sending a SYN segment to TCP A, and enters the 193 "SYN-SENT" state; when TCP A receives this SYN segment sent by TCP B, 194 it enters the SYN-RECEIVED state, and its RCV.NXT becomes 301. In 195 line 4, similarly, when TCP B receives the SYN segment sent by TCP A, 196 it enters the SYN-RECEIVED STATE and its RCV.NXT becomes 101. In 197 line 5, TCP A sends a SYN/ACK in response to the received SYN segment 198 from line 3. In line 6, TCP B sends a SYN/ACK in response to the 199 received SYN segment from line 4. In line 7, TCP B receives the SYN/ 200 ACK from line 5. In line 8, TCP A receives the SYN/ACK from line 6, 201 which fails the TCP Sequence Number validation check. As a result, 202 the received packet is dropped, and a SYN/ACK is sent in response. 203 In line 9, TCP B processes the SYN/ACK from line 7, which fails the 204 TCP Sequence Number validation check. As a result, the received 205 packet is dropped, and a SYN/ACK is sent in response. In line 10, 206 the SYN/ACK from line 9 arrives at TCP B. The segment exchange from 207 lines 8-10 will continue forever (with both TCP end-points will be 208 stuck in the SYN-RECEIVED state), thus leading to a SYN/ACK war. 210 3.2. TCP self connects 212 Some systems have been found to be unable to process TCP connection 213 requests in which the source endpoint {Source Address, Source Port} 214 is the same as the destination end-point {Destination Address, 215 Destination Port}. Such a scenario might arise e.g. if a process 216 creates a socket, bind()s a local end-point (IP address and TCP 217 port), and then issues a connect() to the same end-point as that 218 specified to bind(). 220 While not widely employed in existing applications, such a socket 221 could be employed as a "full-duplex pipe" for Inter-Process 222 Communication (IPC). 224 This scenario is described in detail in pp. 960-962 of 225 [Wright1994]. 227 The aforementioned scenario has been reported to cause malfunction of 228 a number of implementations [CERT1996], and has been exploited in the 229 past to perform Denial of Service (DoS) attacks [Meltman1997] 230 [CPNI-TCP]. 232 While this scenario is not common in the real world, TCP should 233 nevertheless be able to process them without the need of any "extra" 234 code: a SYN segment in which the source end-point {Source Address, 235 Source Port} is the same as the destination end-point {Destination 236 Address, Destination Port} should result in a "simultaneous open" 237 scenario, such as the one described in page 32 of RFC 793 [RFC0793]. 238 Therefore, those TCP implementations that correctly handle 239 simultaneous opens should already be prepared to handle these unusual 240 TCP segments. 242 3.3. TCP simultaneous close 244 The following figure illustrates a typical "simultaneous close" 245 attempt, in which the FIN segments sent by each TCP end-point cross 246 each other in the network. 248 TCP A TCP B 250 1. ESTABLISHED ESTABLISHED 252 2. FIN-WAIT-1 --> ... 254 3. CLOSING <-- <-- FIN-WAIT-1 256 4. ... --> CLOSING 258 5. --> ... 260 6. <-- <-- 262 7. ... --> 264 8. --> ... 266 9. <-- <-- 268 10. ... --> 270 (Failed) Simultaneous Connection Termination 272 In line 1, we assume that both end-points of the connection are in 273 the ESTABLISHED state. In line 2, TCP A performs an "active close" 274 by sending a FIN segment to TCP B, thus entering the FIN-WAIT-1 275 state. In line 3, TCP B performs an active close sending a FIN 276 segment to TCP A, thus entering the FIN-WAIT-1 state; when this 277 segment is processed by TCP A, it enters the CLOSING state (and its 278 RCV.NXT becomes 301). 280 Both FIN segments cross each other on the network, thus resulting 281 in a "simultaneous connection termination" (or "simultaneous 282 close") scenario. 284 In line 4, the FIN segment sent by TCP A arrives to TCP B, causing it 285 to transition to the CLOSING state (at this point, TCP B's RCV.NXT 286 becomes 101). In line 5, TCP A acknowledges the receipt of the TCP 287 B's FIN segment, and also sets the FIN bit in the outgoing segment 288 (since it has not yet been acknowledged). In line 6, TCP B 289 acknowledges the receipt of TCP A's FIN segment, and also sets the 290 FIN bit in the outgoing segment (since it has not yet been 291 acknowledged). In line 7, the FIN/ACK from line 5 arrives at TCP B. 292 In line 8, the FIN/ACK from line 6 fails the TCP sequence number 293 validation check, and thus elicits a ACK segment (the segment also 294 contains the FIN bit set, since it had not yet been acknowledged). 295 In line 9, the FIN/ACK from line 7 fails the TCP sequence number 296 validation check, and hence elicits an ACK segment (the segment also 297 contains the FIN bit set, since it had not yet been acknowledged). 298 In line 10, the FIN/ACK from line 8 finally arrives at TCP B. 300 The packet exchange from lines 8-10 will repeat indefinitely, with 301 both TCP end-points stuck in the CLOSING state, thus leading to a 302 "FIN war": each FIN/ACK segment sent by a TCP will elicit a FIN/ACK 303 from the other TCP, and each of these FIN/ACKs will in turn elicit 304 more FIN/ACKs. 306 3.4. Simultaneous Window Probes 308 The following figure illustrates a scenario in which the "persist 309 timer" at both TCP end-points expires, and both TCP end-points send a 310 "window probes" that cross each other in the network. 312 TCP A TCP B 314 1. ESTABLISHED ESTABLISHED 316 2. (both TCP windows open) 318 3. --> ... 320 4. <-- <-- 322 5. ... --> 324 6. --> ... 326 7. <-- <-- 328 8. ... --> 330 9. --> ... 332 10. <-- <-- 334 11. ... --> 336 (Failed) Simultaneous Connection Termination 338 In line 1, we assume that both end-points of the connection are in 339 the ESTABLISHED state; additionally, TCP A's RCV.NXT is 300, while 340 TCP B's RCV.NXT is 100, and the receive window (RCV.WND) at both TCP 341 end-points is 0. In line 2, both TCP windows open. In line 3, the 342 "persist timer" at TCP A expires, and hence TCP A sends a "Window 343 Probe". In line 4, the "persist timer" at TCP B expires, and hence 344 TCP B sends a "Window Probe". 346 Both Window Probes cross each other in the network. 348 When this probe arrives at TCP A, TCP a's RCV.NXT becomes 301, and an 349 ACK segment is sent to advertise the new window (this ACK is shown in 350 line 6). In line 5, TCP A's Window Probe from line 3 arrives at TCP 351 B. TCP B's RCV-WND becomes 101. In line 6, TCP A sends the ACK to 352 advertise the new window. In line 7, TCP B sends an ACK to advertise 353 the new Window. When this ACK arrives at TCP A, the TCP Sequence 354 Number validation fails, since SEG.SEQ=300 and RCV.NXT=301. 355 Therefore, this segment elicits a new ACK (meant to re-synchronize 356 the sequence numbers). In line 8, the ACK from line 6 arrives at TCP 357 B. The TCP sequence number validation for this segment fails, since 358 SEG.SEQ=100 AND RCV.NXT=101. Therefore, this segment elicits a new 359 ACK (meant to re-synchronize the sequence numbers). 361 Line 9 and line 11 shows the ACK elicited by the segment from line 7, 362 while line 10 shows the ACK elicited by the segment from line 8. The 363 sequence numbers of these ACK segments will be considered invalid, 364 and hence will elicit further ACKs. Therefore, the segment exchange 365 from lines 9-11 will repeat indefinitely, thus leading to an "ACK 366 war". 368 4. Updating RFC 793 370 4.1. TCP sequence number validation 372 The following text from Section 3.3 (pp. 25-26) of [RFC0793]: 374 ---------------- cut here -------------- cut here ---------------- 376 A segment is judged to occupy a portion of valid receive sequence 377 space if 379 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND 381 or 383 RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND 385 The first part of this test checks to see if the beginning of the 386 segment falls in the window, the second part of the test checks to see 387 if the end of the segment falls in the window; if the segment passes 388 either part of the test it contains data in the window. 390 Actually, it is a little more complicated than this. Due to zero 391 windows and zero length segments, we have four cases for the 392 acceptability of an incoming segment: 394 Segment Receive Test 395 Length Window 396 ------- ------- ------------------------------------------- 398 0 0 SEG.SEQ = RCV.NXT 400 0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND 402 >0 0 not acceptable 404 >0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND 405 or RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND 407 ---------------- cut here -------------- cut here ---------------- 409 is replaced with: 411 ---------------- cut here -------------- cut here ---------------- 412 A segment is judged to occupy a portion of valid receive sequence 413 space if 415 RCV.NXT-1 =< SEG.SEQ < RCV.NXT+RCV.WND 417 or 419 RCV.NXT-1 =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND 421 The first part of this test checks to see if the beginning of the 422 segment falls in the window (or one byte to the left to the window), 423 the second part of the test checks to see if the end of the segment 424 falls in the window (or one byte to the left of the window); if the 425 segment passes either part of the test it contains data in the 426 window or control information that needs to be processed by TCP. 428 Actually, it is a little more complicated than this. Due to zero 429 windows and zero length segments, we have four cases for the 430 acceptability of an incoming segment: 432 Segment Receive Test 433 Length Window 434 ------- ------- ------------------------------------------- 436 0 0 RCV.NXT-1 =< SEG.SEQ <= RCV.NXT 438 0 >0 RCV.NXT-1 =< SEG.SEQ < RCV.NXT+RCV.WND 440 >0 0 not acceptable 442 >0 >0 RCV.NXT-1 =< SEG.SEQ < RCV.NXT+RCV.WND 443 or RCV.NXT-1 =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND 445 ---------------- cut here -------------- cut here ---------------- 447 Additionally, the following text from Section 3.9 (pp.69-70) of 448 [RFC0793]: 450 ---------------- cut here -------------- cut here ---------------- 452 Segments are processed in sequence. Initial tests on arrival 453 are used to discard old duplicates, but further processing is 454 done in SEG.SEQ order. If a segment's contents straddle the 455 boundary between old and new, only the new parts should be 456 processed. 458 There are four cases for the acceptability test for an incoming 459 segment: 461 Segment Receive Test 462 Length Window 463 ------- ------- ------------------------------------------- 465 0 0 SEG.SEQ = RCV.NXT 467 0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND 469 >0 0 not acceptable 471 >0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND 472 or RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND 474 If the RCV.WND is zero, no segments will be acceptable, but 475 special allowance should be made to accept valid ACKs, URGs and 476 RSTs. 478 If an incoming segment is not acceptable, an acknowledgment 479 should be sent in reply (unless the RST bit is set, if so drop 480 the segment and return): 482 484 After sending the acknowledgment, drop the unacceptable segment 485 and return. 487 In the following it is assumed that the segment is the idealized 488 segment that begins at RCV.NXT and does not exceed the window. 489 One could tailor actual segments to fit this assumption by 490 trimming off any portions that lie outside the window (including 491 SYN and FIN), and only processing further if the segment then 492 begins at RCV.NXT. Segments with higher beginning sequence 493 numbers may be held for later processing. 494 ---------------- cut here -------------- cut here ---------------- 496 is replaced with: 498 ---------------- cut here -------------- cut here ---------------- 499 Segments are processed in sequence. Initial tests on arrival 500 are used to discard old duplicates, but further processing is 501 done in SEG.SEQ order. If a segment's contents straddle the 502 boundary between old and new, only the new parts should be 503 processed. Acknowledgement information must still be processed 504 when the contents of the incoming segment are one byte to the 505 left of the receive window. 507 This is to handle simultaneous opens, simultaneous closes, 508 and simultaneous window probes. 510 There are four cases for the acceptability test for an incoming 511 segment: 513 Segment Receive Test 514 Length Window 515 ------- ------- ------------------------------------------- 517 0 0 RCV.NXT-1 =< SEG.SEQ <= RCV.NXT 519 0 >0 RCV.NXT-1 =< SEG.SEQ < RCV.NXT+RCV.WND 521 >0 0 not acceptable 523 >0 >0 RCV.NXT-1 =< SEG.SEQ < RCV.NXT+RCV.WND 524 or RCV.NXT-1 =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND 526 If the RCV.WND is zero, no segments will be acceptable, but 527 special allowance should be made to accept valid ACKs, URGs and 528 RSTs. 530 If an incoming segment is not acceptable, an acknowledgment 531 should be sent in reply (unless the RST bit is set, if so drop 532 the segment and return): 534 536 After sending the acknowledgment, drop the unacceptable segment 537 and return. 539 In the following it is assumed that the segment is the idealized 540 segment that begins at RCV.NXT and does not exceed the window. 541 One could tailor actual segments to fit this assumption by 542 trimming off any portions that lie outside the window (including 543 SYN and FIN). Segments with higher beginning sequence numbers may 544 be held for later processing. Acknowledgement information must 545 still be processed when the contents of the incoming segment are 546 one byte to the left of the receive window. 547 ---------------- cut here -------------- cut here ---------------- 549 4.2. Alternative fix for TCP sequence number validation 551 The Linux kernel performs a slightly different TCP sequence number 552 validation check, that can accommodate window probes of any size (as 553 opposed to the de facto standard 1-byte window probes). This makes 554 the code more general, at the expense of additional state in the TCB 555 (e.g., the TCP sequence number employed in the last window probe). 557 4.3. TCP self connects 559 TCP MUST be able to gracefully handle connection requests (i.e., SYN 560 segments) in which the source end-point (IP Source Address, TCP 561 Source Port) is the same as the destination end-point (IP Destination 562 Address, TCP Destination Port). Such segments MUST result in a TCP 563 "simultaneous open", such as the one described in page 32 of RFC 793 564 [RFC0793]. 566 Those TCP implementations that correctly handle simultaneous opens 567 are expected to gracefully handle this scenario. 569 5. IANA Considerations 571 This document has no IANA actions. The RFC Editor is requested to 572 remove this section before publishing this document as an RFC. 574 6. Security Considerations 576 This document describes a problem found in the current validation 577 rules for TCP sequence numbers. The aforementioned problem has 578 affected some popular TCP implementations, typically leading to 579 connection failures, system crashes, or other undesirable behaviors. 580 This document formally updates RFC 793, such that the aforementioned 581 issues are eliminated. 583 7. Acknowledgements 585 Thhe authors of this document would like to thank Theo de Raadt, Rui 586 Paulo and Michael Scharf for providing valuable comments on earlier 587 versions of this document. 589 8. References 590 8.1. Normative References 592 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 593 RFC 793, DOI 10.17487/RFC0793, September 1981, 594 . 596 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 597 Requirement Levels", BCP 14, RFC 2119, 598 DOI 10.17487/RFC2119, March 1997, 599 . 601 8.2. Informative References 603 [CERT1996] 604 CERT, "CERT Advisory CA-1996-21: TCP SYN Flooding and IP 605 Spoofing Attacks", 1996, 606 . 608 [CPNI-TCP] 609 Gont, F., "CPNI Technical Note 3/2009: Security Assessment 610 of the Transmission Control Protocol (TCP)", 2009, 611 . 614 [Meltman1997] 615 Meltman, "new TCP/IP bug in win95. Post to the bugtraq 616 mailing-list", 1996, 617 . 619 [Wright1994] 620 Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2: 621 The Implementation", Addison-Wesley, 1994. 623 Authors' Addresses 625 Fernando Gont 626 UTN-FRH / SI6 Networks 627 Evaristo Carriego 2644 628 Haedo, Provincia de Buenos Aires 1706 629 Argentina 631 Phone: +54 11 4650 8472 632 Email: fgont@si6networks.com 633 URI: http://www.si6networks.com 634 David Borman 635 Quantum Corporation 636 1155 Centre Pointe Drive, Suite 1 637 Mendota Heights, MN 55120 638 U.S.A. 640 Phone: 651-688-4394 641 Email: david.borman@quantum.com