< draft-gont-tcpm-tcp-seq-validation-02.txt   draft-gont-tcpm-tcp-seq-validation-03.txt >
TCP Maintenance and Minor Extensions (tcpm) F. Gont TCP Maintenance and Minor Extensions F. Gont
Internet-Draft UTN-FRH / SI6 Networks (tcpm) UTN-FRH / SI6 Networks
Updates: 793 (if approved) D. Borman Internet-Draft D. Borman
Intended status: Standards Track Quantum Corporation Updates: 793 (if approved) Quantum Corporation
Expires: September 27, 2015 March 26, 2015 Intended status: Standards Track March 5, 2018
Expires: September 6, 2018
On the Validation of TCP Sequence Numbers On the Validation of TCP Sequence Numbers
draft-gont-tcpm-tcp-seq-validation-02.txt draft-gont-tcpm-tcp-seq-validation-03.txt
Abstract Abstract
When TCP receives packets that lie outside of the receive window, the When TCP receives packets that lie outside of the receive window, the
corresponding packets are dropped and either an ACK, RST or no corresponding packets are dropped and either an ACK, RST or no
response is generated due to the out-of-window packet, with no response is generated due to the out-of-window packet, with no
further processing of the packet. Most of the time, this works just further processing of the packet. Most of the time, this works just
fine and TCP remains stable, especially when a TCP connection has fine and TCP remains stable, especially when a TCP connection has
unidirectional data flow. However, there are three scenarios in unidirectional data flow. However, there are three scenarios in
which packets that are outside of the receive window should still which packets that are outside of the receive window should still
have their ACK field processed, or else a packet war will take place. have their ACK field processed, or else a packet war will take place.
The aforementioned issues have affected a number of popular TCP The aforementioned issues have affected a number of popular TCP
implementations, typically leading to connection failures, system implementations, typically leading to connection failures, system
crashes, or other undesirable behaviors. This document describes the crashes, or other undesirable behaviors. This document describes the
three scenarios in which the aforementioned issues might arise, and three scenarios in which the aforementioned issues might arise, and
formally updates RFC 793 such that these potential problems are formally updates RFC 793 such that these potential problems are
mitigated. mitigated.
Status of This Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 27, 2015. This Internet-Draft will expire on September 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. TCP Sequence Number Validation . . . . . . . . . . . . . . . 3 2. TCP Sequence Number Validation . . . . . . . . . . . . . . . . 3
3. Scenarios in which Undesirable Behaviors Might Arise . . . . 4 3. Scenarios in which Undesirable Behaviors Might Arise . . . . . 4
3.1. TCP simultaneous open . . . . . . . . . . . . . . . . . . 4 3.1. TCP simultaneous open . . . . . . . . . . . . . . . . . . 4
3.2. TCP self connects . . . . . . . . . . . . . . . . . . . . 6 3.2. TCP self connects . . . . . . . . . . . . . . . . . . . . 5
3.3. TCP simultaneous close . . . . . . . . . . . . . . . . . 6 3.3. TCP simultaneous close . . . . . . . . . . . . . . . . . . 6
3.4. Simultaneous Window Probes . . . . . . . . . . . . . . . 8 3.4. Simultaneous Window Probes . . . . . . . . . . . . . . . . 8
4. Updating RFC 793 . . . . . . . . . . . . . . . . . . . . . . 9 4. Updating RFC 793 . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. TCP sequence number validation . . . . . . . . . . . . . 9 4.1. TCP sequence number validation . . . . . . . . . . . . . . 9
4.2. Alternative fix for TCP sequene number validation . . . . 14 4.2. Alternative fix for TCP sequene number validation . . . . 14
4.3. TCP self connects . . . . . . . . . . . . . . . . . . . . 14 4.3. TCP self connects . . . . . . . . . . . . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
TCP processes incoming packets in in-sequence order. Packets that TCP processes incoming packets in in-sequence order. Packets that
are not in-sequence but have data that lies in the receive window are are not in-sequence but have data that lies in the receive window are
queued for later processing. Packets that lie outside of the receive queued for later processing. Packets that lie outside of the receive
window are dropped and either an ACK, RST or no response is generated window are dropped and either an ACK, RST or no response is generated
due to the out-of-window packet, with no further processing of the due to the out-of-window packet, with no further processing of the
packet. Most of the time, this works just fine and TCP remains packet. Most of the time, this works just fine and TCP remains
stable, especially when a TCP connection has unidirectional data stable, especially when a TCP connection has unidirectional data
skipping to change at page 4, line 7 skipping to change at page 4, line 25
>0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND >0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND
or RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND or RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND
RFC 793 states that if an incoming segment is not acceptable, an RFC 793 states that if an incoming segment is not acceptable, an
acknowledgment should be sent in reply (unless the RST bit is set), acknowledgment should be sent in reply (unless the RST bit is set),
and that after sending the acknowledgment, the unacceptable segment and that after sending the acknowledgment, the unacceptable segment
should be dropped. should be dropped.
Section 3.9 of RFC 793 repeats (in pp. 69-76) the same validation Section 3.9 of RFC 793 repeats (in pp. 69-76) the same validation
checks when describing the processing of incoming TCP segments meant checks when describing the processing of incoming TCP segments meant
for connections that are in the SYN-RECEIVED, ESTABLISHED, FIN-WAIT- for connections that are in the SYN-RECEIVED, ESTABLISHED,
1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, or TIME-WAIT states FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, or TIME-WAIT
(i.e., any state other than CLOSED, LISTEN, or SYN-SENT). states (i.e., any state other than CLOSED, LISTEN, or SYN-SENT).
A key problem with the aforementioned checks is that it assumes that A key problem with the aforementioned checks is that it assumes that
a segment must be processed only if a portion of it overlaps with the a segment must be processed only if a portion of it overlaps with the
receive window. However, there are some cases in which the receive window. However, there are some cases in which the
Acknowledgement information in an incoming segment needs to be Acknowledgement information in an incoming segment needs to be
processed by TCP even if the contents of the segment does not overlap processed by TCP even if the contents of the segment does not overlap
with the receive window. Otherwise, the TCP state machine may become with the receive window. Otherwise, the TCP state machine may become
dead-locked, and this situation may result in undesirable behaviors dead-locked, and this situation may result in undesirable behaviors
such as system crashes. such as system crashes.
skipping to change at page 5, line 45 skipping to change at page 5, line 45
it enters the SYN-RECEIVED STATE and its RCV.NXT becomes 101. In it enters the SYN-RECEIVED STATE and its RCV.NXT becomes 101. In
line 5, TCP A sends a SYN/ACK in response to the received SYN segment line 5, TCP A sends a SYN/ACK in response to the received SYN segment
from line 3. In line 6, TCP B sends a SYN/ACK in response to the from line 3. In line 6, TCP B sends a SYN/ACK in response to the
received SYN segment from line 4. In line 7, TCP B receives the SYN/ received SYN segment from line 4. In line 7, TCP B receives the SYN/
ACK from line 5. In line 8, TCP A receives the SYN/ACK from line 6, ACK from line 5. In line 8, TCP A receives the SYN/ACK from line 6,
which fails the TCP Sequence Number validation check. As a result, which fails the TCP Sequence Number validation check. As a result,
the received packet is dropped, and a SYN/ACK is sent in response. the received packet is dropped, and a SYN/ACK is sent in response.
In line 9, TCP B processes the SYN/ACK from line 7, which fails the In line 9, TCP B processes the SYN/ACK from line 7, which fails the
TCP Sequence Number validation check. As a result, the received TCP Sequence Number validation check. As a result, the received
packet is dropped, and a SYN/ACK is sent in response. In line 10, packet is dropped, and a SYN/ACK is sent in response. In line 10,
the SYN/ACK from line 9 arrives at TCP B. The segment exchange from the SYN/ACK from line 9 arrives at TCP B. The segment exchange from
lines 8-10 will continue forever (with both TCP end-points will be lines 8-10 will continue forever (with both TCP end-points will be
stuck in the SYN-RECEIVED state), thus leading to a SYN/ACK war. stuck in the SYN-RECEIVED state), thus leading to a SYN/ACK war.
3.2. TCP self connects 3.2. TCP self connects
Some systems have been found to be unable to process TCP connection Some systems have been found to be unable to process TCP connection
requests in which the source endpoint {Source Address, Source Port} requests in which the source endpoint {Source Address, Source Port}
is the same as the destination end-point {Destination Address, is the same as the destination end-point {Destination Address,
Destination Port}. Such a scenario might arise e.g. if a process Destination Port}. Such a scenario might arise e.g. if a process
creates a socket, bind()s a local end-point (IP address and TCP creates a socket, bind()s a local end-point (IP address and TCP
port), and then issues a connect() to the same end-point as that port), and then issues a connect() to the same end-point as that
specified to bind(). specified to bind().
While not widely employed in existing applications, such a socket While not widely employed in existing applications, such a socket
could be employed as a "full-duplex pipe" for Inter-Process could be employed as a "full-duplex pipe" for Inter-Process
Communication (IPC). Communication (IPC).
This scenario is described in detail in pp. 960-962 of This scenario is described in detail in pp. 960-962 of
[Wright1994]. [Wright1994].
skipping to change at page 9, line 12 skipping to change at page 9, line 11
end-points is 0. In line 2, both TCP windows open. In line 3, the end-points is 0. In line 2, both TCP windows open. In line 3, the
"persist timer" at TCP A expires, and hence TCP A sends a "Window "persist timer" at TCP A expires, and hence TCP A sends a "Window
Probe". In line 4, the "persist timer" at TCP B expires, and hence Probe". In line 4, the "persist timer" at TCP B expires, and hence
TCP B sends a "Window Probe". TCP B sends a "Window Probe".
Both Window Probes cross each other in the network. Both Window Probes cross each other in the network.
When this probe arrives at TCP A, TCP a's RCV.NXT becomes 301, and an When this probe arrives at TCP A, TCP a's RCV.NXT becomes 301, and an
ACK segment is sent to advertise the new window (this ACK is shown in ACK segment is sent to advertise the new window (this ACK is shown in
line 6). In line 5, TCP A's Window Probe from line 3 arrives at TCP line 6). In line 5, TCP A's Window Probe from line 3 arrives at TCP
B. TCP B's RCV-WND becomes 101. In line 6, TCP A sends the ACK to B. TCP B's RCV-WND becomes 101. In line 6, TCP A sends the ACK to
advertise the new window. In line 7, TCP B sends an ACK to advertise advertise the new window. In line 7, TCP B sends an ACK to advertise
the new Window. When this ACK arrives at TCP A, the TCP Sequence the new Window. When this ACK arrives at TCP A, the TCP Sequence
Number validation fails, since SEG.SEQ=300 and RCV.NXT=301. Number validation fails, since SEG.SEQ=300 and RCV.NXT=301.
Therefore, this segment elicits a new ACK (meant to re-synchronize Therefore, this segment elicits a new ACK (meant to re-synchronize
the sequence numbers). In line 8, the ACK from line 6 arrives at TCP the sequence numbers). In line 8, the ACK from line 6 arrives at TCP
B. The TCP sequence number validation for this segment fails, since B. The TCP sequence number validation for this segment fails, since
SEG.SEQ=100 AND RCV.NXT=101. Therefore, this segment elicits a new SEG.SEQ=100 AND RCV.NXT=101. Therefore, this segment elicits a new
ACK (meant to re-synchronize the sequence numbers). ACK (meant to re-synchronize the sequence numbers).
Line 9 and line 11 shows the ACK elicited by the segment from line 7, Line 9 and line 11 shows the ACK elicited by the segment from line 7,
while line 10 shows the ACK elicited by the segment from line 8. The while line 10 shows the ACK elicited by the segment from line 8. The
sequence numbers of these ACK segments will be considered invalid, sequence numbers of these ACK segments will be considered invalid,
and hence will elicit further ACKs. Therefore, the segment exchange and hence will elicit further ACKs. Therefore, the segment exchange
from lines 9-11 will repeat indefinitely, thus leading to an "ACK from lines 9-11 will repeat indefinitely, thus leading to an "ACK
war". war".
skipping to change at page 15, line 9 skipping to change at page 15, line 9
7. Acknowledgements 7. Acknowledgements
Thhe authors of this document would like to thank Rui Paulo and Thhe authors of this document would like to thank Rui Paulo and
Michael Scharf for providing valuable comments on earlier versions of Michael Scharf for providing valuable comments on earlier versions of
this document. this document.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
793, September 1981. RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
8.2. Informative References 8.2. Informative References
[CERT1996] [CERT1996]
CERT, , "CERT Advisory CA-1996-21: TCP SYN Flooding and IP CERT, "CERT Advisory CA-1996-21: TCP SYN Flooding and IP
Spoofing Attacks", 1996, Spoofing Attacks", 1996,
<http://www.cert.org/advisories/CA-1996-21.html>. <http://www.cert.org/advisories/CA-1996-21.html>.
[CPNI-TCP] [CPNI-TCP]
Gont, F., "CPNI Technical Note 3/2009: Security Assessment Gont, F., "CPNI Technical Note 3/2009: Security Assessment
of the Transmission Control Protocol (TCP)", 2009, of the Transmission Control Protocol (TCP)", 2009, <http:/
<http://www.gont.com.ar/papers/ /www.gont.com.ar/papers/
tn-03-09-security-assessment-TCP.pdf>. tn-03-09-security-assessment-TCP.pdf>.
[Meltman1997] [Meltman1997]
Meltman, , "new TCP/IP bug in win95. Post to the bugtraq Meltman, "new TCP/IP bug in win95. Post to the bugtraq
mailing-list", 1996, mailing-list", 1996,
<http://insecure.org/sploits/land.ip.DOS.html>. <http://insecure.org/sploits/land.ip.DOS.html>.
[Wright1994] [Wright1994]
Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2: Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2:
The Implementation", Addison-Wesley, 1994. The Implementation", Addison-Wesley, 1994.
Authors' Addresses Authors' Addresses
Fernando Gont Fernando Gont
 End of changes. 16 change blocks. 
41 lines changed or deleted 45 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/