< draft-gont-tcpm-tcp-seq-validation-01.txt		draft-gont-tcpm-tcp-seq-validation-02.txt >
	TCP Maintenance and Minor Extensions F. Gont		TCP Maintenance and Minor Extensions (tcpm) F. Gont
	(tcpm) UTN-FRH / SI6 Networks		Internet-Draft UTN-FRH / SI6 Networks
	Internet-Draft D. Borman		Updates: 793 (if approved) D. Borman
	Updates: 793 (if approved) Quantum Corporation		Intended status: Standards Track Quantum Corporation
	Intended status: Standards Track September 10, 2013		Expires: September 27, 2015 March 26, 2015
	Expires: March 14, 2014
	On the Validation of TCP Sequence Numbers		On the Validation of TCP Sequence Numbers
	draft-gont-tcpm-tcp-seq-validation-01.txt		draft-gont-tcpm-tcp-seq-validation-02.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 March 14, 2014.		This Internet-Draft will expire on September 27, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	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 . . . . . . . . . . . . . . . . . . . . 5		3.2. TCP self connects . . . . . . . . . . . . . . . . . . . . 6
	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. TCP self connects . . . . . . . . . . . . . . . . . . . . 14		4.2. Alternative fix for TCP sequene number validation . . . . 14
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		4.3. TCP self connects . . . . . . . . . . . . . . . . . . . . 14
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 14		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14		6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 14		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
	8.2. Informative References . . . . . . . . . . . . . . . . . . 15		8.1. Normative References . . . . . . . . . . . . . . . . . . 15
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15		8.2. Informative References . . . . . . . . . . . . . . . . . 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 25 ¶		skipping to change at page 4, line 7 ¶
	>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,		for connections that are in the SYN-RECEIVED, ESTABLISHED, FIN-WAIT-
	FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, or TIME-WAIT		1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, or TIME-WAIT states
	states (i.e., any state other than CLOSED, LISTEN, or SYN-SENT).		(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 11 ¶		skipping to change at page 9, line 12 ¶
	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".
	4. Updating RFC 793		4. Updating RFC 793
	4.1. TCP sequence number validation		4.1. TCP sequence number validation
	The following text from Section 3.3 (pp. 25-26) of [RFC0793]:		The following text from Section 3.3 (pp. 25-26) of [RFC0793]:
			---------------- cut here -------------- cut here ----------------
	A segment is judged to occupy a portion of valid receive sequence		A segment is judged to occupy a portion of valid receive sequence
	space if		space if
	RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND		RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND
	or		or
	RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND		RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND
	The first part of this test checks to see if the beginning of the		The first part of this test checks to see if the beginning of the
	skipping to change at page 10, line 36 ¶		skipping to change at page 10, line 38 ¶
	0 0 SEG.SEQ = RCV.NXT		0 0 SEG.SEQ = RCV.NXT
	0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND		0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND
	>0 0 not acceptable		>0 0 not acceptable
	>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
			---------------- cut here -------------- cut here ----------------
	is replaced with:		is replaced with:
			---------------- cut here -------------- cut here ----------------
	A segment is judged to occupy a portion of valid receive sequence		A segment is judged to occupy a portion of valid receive sequence
	space if		space if
	RCV.NXT-1 =< SEG.SEQ < RCV.NXT+RCV.WND		RCV.NXT-1 =< SEG.SEQ < RCV.NXT+RCV.WND
	or		or
	RCV.NXT-1 =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND		RCV.NXT-1 =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND
	The first part of this test checks to see if the beginning of the		The first part of this test checks to see if the beginning of the
	skipping to change at page 11, line 38 ¶		skipping to change at page 11, line 39 ¶
	0 0 RCV.NXT-1 =< SEG.SEQ <= RCV.NXT		0 0 RCV.NXT-1 =< SEG.SEQ <= RCV.NXT
	0 >0 RCV.NXT-1 =< SEG.SEQ < RCV.NXT+RCV.WND		0 >0 RCV.NXT-1 =< SEG.SEQ < RCV.NXT+RCV.WND
	>0 0 not acceptable		>0 0 not acceptable
	>0 >0 RCV.NXT-1 =< SEG.SEQ < RCV.NXT+RCV.WND		>0 >0 RCV.NXT-1 =< SEG.SEQ < RCV.NXT+RCV.WND
	or RCV.NXT-1 =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND		or RCV.NXT-1 =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND
			---------------- cut here -------------- cut here ----------------
	Additionally, the following text from Section 3.9 (pp.69-70) of		Additionally, the following text from Section 3.9 (pp.69-70) of
	[RFC0793]:		[RFC0793]:
			---------------- cut here -------------- cut here ----------------
	Segments are processed in sequence. Initial tests on arrival		Segments are processed in sequence. Initial tests on arrival
	are used to discard old duplicates, but further processing is		are used to discard old duplicates, but further processing is
	done in SEG.SEQ order. If a segment's contents straddle the		done in SEG.SEQ order. If a segment's contents straddle the
	boundary between old and new, only the new parts should be		boundary between old and new, only the new parts should be
	processed.		processed.
	There are four cases for the acceptability test for an incoming		There are four cases for the acceptability test for an incoming
	segment:		segment:
	Segment Receive Test		Segment Receive Test
	skipping to change at page 12, line 47 ¶		skipping to change at page 12, line 49 ¶
	After sending the acknowledgment, drop the unacceptable segment		After sending the acknowledgment, drop the unacceptable segment
	and return.		and return.
	In the following it is assumed that the segment is the idealized		In the following it is assumed that the segment is the idealized
	segment that begins at RCV.NXT and does not exceed the window.		segment that begins at RCV.NXT and does not exceed the window.
	One could tailor actual segments to fit this assumption by		One could tailor actual segments to fit this assumption by
	trimming off any portions that lie outside the window (including		trimming off any portions that lie outside the window (including
	SYN and FIN), and only processing further if the segment then		SYN and FIN), and only processing further if the segment then
	begins at RCV.NXT. Segments with higher beginning sequence		begins at RCV.NXT. Segments with higher beginning sequence
	numbers may be held for later processing.		numbers may be held for later processing.
			---------------- cut here -------------- cut here ----------------
	is replaced with:		is replaced with:
			---------------- cut here -------------- cut here ----------------
	Segments are processed in sequence. Initial tests on arrival		Segments are processed in sequence. Initial tests on arrival
	are used to discard old duplicates, but further processing is		are used to discard old duplicates, but further processing is
	done in SEG.SEQ order. If a segment's contents straddle the		done in SEG.SEQ order. If a segment's contents straddle the
	boundary between old and new, only the new parts should be		boundary between old and new, only the new parts should be
	processed. Acknowledgement information must still be processed		processed. Acknowledgement information must still be processed
	when the contents of the incoming segment are one byte to the		when the contents of the incoming segment are one byte to the
	left of the receive window.		left of the receive window.
	This is to handle simultaneous opens, simultaneous closes,		This is to handle simultaneous opens, simultaneous closes,
	and simultaneous window probes.		and simultaneous window probes.
	skipping to change at page 14, line 4 ¶		skipping to change at page 14, line 5 ¶
	and return.		and return.
	In the following it is assumed that the segment is the idealized		In the following it is assumed that the segment is the idealized
	segment that begins at RCV.NXT and does not exceed the window.		segment that begins at RCV.NXT and does not exceed the window.
	One could tailor actual segments to fit this assumption by		One could tailor actual segments to fit this assumption by
	trimming off any portions that lie outside the window (including		trimming off any portions that lie outside the window (including
	SYN and FIN). Segments with higher beginning sequence numbers may		SYN and FIN). Segments with higher beginning sequence numbers may
	be held for later processing. Acknowledgement information must		be held for later processing. Acknowledgement information must
	still be processed when the contents of the incoming segment are		still be processed when the contents of the incoming segment are
	one byte to the left of the receive window.		one byte to the left of the receive window.
			---------------- cut here -------------- cut here ----------------
	4.2. TCP self connects		4.2. Alternative fix for TCP sequene number validation
			The Linux kernel performs a slightly different TCP sequence number
			validation check, in that, during window probes, can acommodate
			window probes of any size (as opposed to the defacto standard 1-byte
			window probes). This makes the code more general, at the expense of
			additional state in the TCB (e.g., the TCP sequence number employed
			in the last window probe).
			4.3. TCP self connects
	TCP MUST be able to gracefully handle connection requests (i.e., SYN		TCP MUST be able to gracefully handle connection requests (i.e., SYN
	segments) in which the source end-point (IP Source Address, TCP		segments) in which the source end-point (IP Source Address, TCP
	Source Port) is the same as the destination end-point (IP Destination		Source Port) is the same as the destination end-point (IP Destination
	Address, TCP Destination Port). Such segments MUST result in a TCP		Address, TCP Destination Port). Such segments MUST result in a TCP
	"simultaneous open", such as the one described in page 32 of RFC 793		"simultaneous open", such as the one described in page 32 of RFC 793
	[RFC0793].		[RFC0793].
	Those TCP implementations that correctly handle simultaneous opens		Those TCP implementations that correctly handle simultaneous opens
	are expected to gracefully handle this scenario.		are expected to gracefully handle this scenario.
	skipping to change at page 14, line 33 ¶		skipping to change at page 14, line 44 ¶
	This document describes a problem found in the current validation		This document describes a problem found in the current validation
	rules for TCP sequence numbers. The aforementioned problem has		rules for TCP sequence numbers. The aforementioned problem has
	affected some popular TCP implementations, typically leads to		affected some popular TCP implementations, typically leads to
	connection failures, system crashes, or other undesirable behaviors.		connection failures, system crashes, or other undesirable behaviors.
	This document formally updates RFC 793, such that the aforementioned		This document formally updates RFC 793, such that the aforementioned
	issues are eliminated.		issues are eliminated.
	7. Acknowledgements		7. Acknowledgements
	This document originated from a discussion about this topic (at IETF		Thhe authors of this document would like to thank Rui Paulo and
	73, Minneapolis) between both co-authors of this document.		Michael Scharf for providing valuable comments on earlier versions of
			this document.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,		[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
	RFC 793, September 1981.		793, September 1981.
	[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, March 1997.
	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, <http:/		of the Transmission Control Protocol (TCP)", 2009,
	/www.gont.com.ar/papers/		<http://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. 25 change blocks.
	43 lines changed or deleted		65 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/