idnits 2.17.00 (12 Aug 2021) /tmp/idnits40655/draft-gont-tcpm-tcp-seq-validation-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 10, 2013) is 3174 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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 September 10, 2013 7 Expires: March 14, 2014 9 On the Validation of TCP Sequence Numbers 10 draft-gont-tcpm-tcp-seq-validation-01.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 March 14, 2014. 46 Copyright Notice 48 Copyright (c) 2013 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. 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 . . . . . . . . . . . . . . . . . . . 14 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, 143 FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, or TIME-WAIT 144 states (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 A segment is judged to occupy a portion of valid receive sequence 375 space if 377 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND 379 or 381 RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND 383 The first part of this test checks to see if the beginning of the 384 segment falls in the window, the second part of the test checks to see 385 if the end of the segment falls in the window; if the segment passes 386 either part of the test it contains data in the window. 388 Actually, it is a little more complicated than this. Due to zero 389 windows and zero length segments, we have four cases for the 390 acceptability of an incoming segment: 392 Segment Receive Test 393 Length Window 394 ------- ------- ------------------------------------------- 396 0 0 SEG.SEQ = RCV.NXT 398 0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND 400 >0 0 not acceptable 402 >0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND 403 or RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND 405 is replaced with: 407 A segment is judged to occupy a portion of valid receive sequence 408 space if 410 RCV.NXT-1 =< SEG.SEQ < RCV.NXT+RCV.WND 412 or 414 RCV.NXT-1 =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND 416 The first part of this test checks to see if the beginning of the 417 segment falls in the window (or one byte to the left to the window), 418 the second part of the test checks to see if the end of the segment 419 falls in the window (or one byte to the left of the window); if the 420 segment passes either part of the test it contains data in the 421 window or control information that needs to be processed by TCP. 423 Actually, it is a little more complicated than this. Due to zero 424 windows and zero length segments, we have four cases for the 425 acceptability of an incoming segment: 427 Segment Receive Test 428 Length Window 429 ------- ------- ------------------------------------------- 431 0 0 RCV.NXT-1 =< SEG.SEQ <= RCV.NXT 433 0 >0 RCV.NXT-1 =< SEG.SEQ < RCV.NXT+RCV.WND 435 >0 0 not acceptable 437 >0 >0 RCV.NXT-1 =< SEG.SEQ < RCV.NXT+RCV.WND 438 or RCV.NXT-1 =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND 440 Additionally, the following text from Section 3.9 (pp.69-70) of 441 [RFC0793]: 443 Segments are processed in sequence. Initial tests on arrival 444 are used to discard old duplicates, but further processing is 445 done in SEG.SEQ order. If a segment's contents straddle the 446 boundary between old and new, only the new parts should be 447 processed. 449 There are four cases for the acceptability test for an incoming 450 segment: 452 Segment Receive Test 453 Length Window 454 ------- ------- ------------------------------------------- 456 0 0 SEG.SEQ = RCV.NXT 458 0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND 460 >0 0 not acceptable 462 >0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND 463 or RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND 465 If the RCV.WND is zero, no segments will be acceptable, but 466 special allowance should be made to accept valid ACKs, URGs and 467 RSTs. 469 If an incoming segment is not acceptable, an acknowledgment 470 should be sent in reply (unless the RST bit is set, if so drop 471 the segment and return): 473 475 After sending the acknowledgment, drop the unacceptable segment 476 and return. 478 In the following it is assumed that the segment is the idealized 479 segment that begins at RCV.NXT and does not exceed the window. 480 One could tailor actual segments to fit this assumption by 481 trimming off any portions that lie outside the window (including 482 SYN and FIN), and only processing further if the segment then 483 begins at RCV.NXT. Segments with higher beginning sequence 484 numbers may be held for later processing. 486 is replaced with: 488 Segments are processed in sequence. Initial tests on arrival 489 are used to discard old duplicates, but further processing is 490 done in SEG.SEQ order. If a segment's contents straddle the 491 boundary between old and new, only the new parts should be 492 processed. Acknowledgement information must still be processed 493 when the contents of the incoming segment are one byte to the 494 left of the receive window. 496 This is to handle simultaneous opens, simultaneous closes, 497 and simultaneous window probes. 499 There are four cases for the acceptability test for an incoming 500 segment: 502 Segment Receive Test 503 Length Window 504 ------- ------- ------------------------------------------- 506 0 0 RCV.NXT-1 =< SEG.SEQ <= RCV.NXT 508 0 >0 RCV.NXT-1 =< SEG.SEQ < RCV.NXT+RCV.WND 510 >0 0 not acceptable 512 >0 >0 RCV.NXT-1 =< SEG.SEQ < RCV.NXT+RCV.WND 513 or RCV.NXT-1 =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND 515 If the RCV.WND is zero, no segments will be acceptable, but 516 special allowance should be made to accept valid ACKs, URGs and 517 RSTs. 519 If an incoming segment is not acceptable, an acknowledgment 520 should be sent in reply (unless the RST bit is set, if so drop 521 the segment and return): 523 525 After sending the acknowledgment, drop the unacceptable segment 526 and return. 528 In the following it is assumed that the segment is the idealized 529 segment that begins at RCV.NXT and does not exceed the window. 530 One could tailor actual segments to fit this assumption by 531 trimming off any portions that lie outside the window (including 532 SYN and FIN). Segments with higher beginning sequence numbers may 533 be held for later processing. Acknowledgement information must 534 still be processed when the contents of the incoming segment are 535 one byte to the left of the receive window. 537 4.2. TCP self connects 539 TCP MUST be able to gracefully handle connection requests (i.e., SYN 540 segments) in which the source end-point (IP Source Address, TCP 541 Source Port) is the same as the destination end-point (IP Destination 542 Address, TCP Destination Port). Such segments MUST result in a TCP 543 "simultaneous open", such as the one described in page 32 of RFC 793 544 [RFC0793]. 546 Those TCP implementations that correctly handle simultaneous opens 547 are expected to gracefully handle this scenario. 549 5. IANA Considerations 551 This document has no IANA actions. The RFC Editor is requested to 552 remove this section before publishing this document as an RFC. 554 6. Security Considerations 556 This document describes a problem found in the current validation 557 rules for TCP sequence numbers. The aforementioned problem has 558 affected some popular TCP implementations, typically leads to 559 connection failures, system crashes, or other undesirable behaviors. 560 This document formally updates RFC 793, such that the aforementioned 561 issues are eliminated. 563 7. Acknowledgements 565 This document originated from a discussion about this topic (at IETF 566 73, Minneapolis) between both co-authors of this document. 568 8. References 570 8.1. Normative References 572 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 573 RFC 793, September 1981. 575 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 576 Requirement Levels", BCP 14, RFC 2119, March 1997. 578 8.2. Informative References 580 [CERT1996] 581 CERT, "CERT Advisory CA-1996-21: TCP SYN Flooding and IP 582 Spoofing Attacks", 1996, 583 . 585 [CPNI-TCP] 586 Gont, F., "CPNI Technical Note 3/2009: Security Assessment 587 of the Transmission Control Protocol (TCP)", 2009, . 591 [Meltman1997] 592 Meltman, "new TCP/IP bug in win95. Post to the bugtraq 593 mailing-list", 1996, 594 . 596 [Wright1994] 597 Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2: 598 The Implementation", Addison-Wesley, 1994. 600 Authors' Addresses 602 Fernando Gont 603 UTN-FRH / SI6 Networks 604 Evaristo Carriego 2644 605 Haedo, Provincia de Buenos Aires 1706 606 Argentina 608 Phone: +54 11 4650 8472 609 Email: fgont@si6networks.com 610 URI: http://www.si6networks.com 612 David Borman 613 Quantum Corporation 614 1155 Centre Pointe Drive, Suite 1 615 Mendota Heights, MN 55120 616 U.S.A. 618 Phone: 651-688-4394 619 Email: david.borman@quantum.com