draft-ietf-tcpm-tcp-timestamps-01.txt		draft-ietf-tcpm-tcp-timestamps-02.txt
	TCP Maintenance and Minor F. Gont		TCP Maintenance and Minor F. Gont
	Extensions (tcpm) UK CPNI		Extensions (tcpm) UK CPNI
	Internet-Draft November 16, 2010		Internet-Draft December 7, 2010
	Intended status: BCP		Intended status: BCP
	Expires: May 20, 2011		Expires: June 10, 2011
	Reducing the TIME-WAIT state using TCP timestamps		Reducing the TIME-WAIT state using TCP timestamps
	draft-ietf-tcpm-tcp-timestamps-01.txt		draft-ietf-tcpm-tcp-timestamps-02.txt
	Abstract		Abstract
	This document describes an algorithm for processing incoming SYN		This document describes an algorithm for processing incoming SYN
	segments that allows higher connection-establishment rates between		segments that allows higher connection-establishment rates between
	any two TCP endpoints when a TCP timestamps option is present in the		any two TCP endpoints when a TCP timestamps option is present in the
	incoming SYN segment. This document only modifies processing of SYN		incoming SYN segment. This document only modifies processing of SYN
	segments received for connections in the TIME-WAIT state; processing		segments received for connections in the TIME-WAIT state; processing
	in all other states is unchanged.		in all other states is unchanged.
	skipping to change at page 1, line 36		skipping to change at page 1, line 36
	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 May 20, 2011.		This Internet-Draft will expire on June 10, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 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
	skipping to change at page 2, line 37		skipping to change at page 2, line 37
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 8		8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
	8.2. Informative References . . . . . . . . . . . . . . . . . . 9		8.2. Informative References . . . . . . . . . . . . . . . . . . 9
	Appendix A. Behavior of the proposed mechanism in specific		Appendix A. Behavior of the proposed mechanism in specific
	scenarios . . . . . . . . . . . . . . . . . . . . . . 10		scenarios . . . . . . . . . . . . . . . . . . . . . . 10
	A.1. Connection request after system reboot . . . . . . . . . . 10		A.1. Connection request after system reboot . . . . . . . . . . 10
	Appendix B. Changes from previous versions of the draft (to		Appendix B. Changes from previous versions of the draft (to
	be removed by the RFC Editor before publishing		be removed by the RFC Editor before publishing
	this document as an RFC) . . . . . . . . . . . . . . 10		this document as an RFC) . . . . . . . . . . . . . . 10
	B.1. Changes from draft-ietf-tcpm-tcp-timestamps-00 . . . . . . 10		B.1. Changes from draft-ietf-tcpm-tcp-timestamps-01 . . . . . . 10
	B.2. Changes from draft-gont-tcpm-tcp-timestamps-04 . . . . . . 10		B.2. Changes from draft-ietf-tcpm-tcp-timestamps-00 . . . . . . 10
	B.3. Changes from draft-gont-tcpm-tcp-timestamps-03 . . . . . . 10		B.3. Changes from draft-gont-tcpm-tcp-timestamps-04 . . . . . . 10
	B.4. Changes from draft-gont-tcpm-tcp-timestamps-02 . . . . . . 11		B.4. Changes from draft-gont-tcpm-tcp-timestamps-03 . . . . . . 11
	B.5. Changes from draft-gont-tcpm-tcp-timestamps-01 . . . . . . 11		B.5. Changes from draft-gont-tcpm-tcp-timestamps-02 . . . . . . 11
	B.6. Changes from draft-gont-tcpm-tcp-timestamps-00 . . . . . . 11		B.6. Changes from draft-gont-tcpm-tcp-timestamps-01 . . . . . . 11
			B.7. Changes from draft-gont-tcpm-tcp-timestamps-00 . . . . . . 11
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	The Timestamps option, specified in RFC 1323 [RFC1323], allows a TCP		The Timestamps option, specified in RFC 1323 [RFC1323], allows a TCP
	to include a timestamp value in its segments, that can be used to		to include a timestamp value in its segments, that can be used to
	perform two functions: Round-Trip Time Measurement (RTTM), and		perform two functions: Round-Trip Time Measurement (RTTM), and
	Protection Against Wrapped Sequences (PAWS).		Protection Against Wrapped Sequences (PAWS).
	For the purpose of PAWS, the timestamps sent on a connection are		For the purpose of PAWS, the timestamps sent on a connection are
	skipping to change at page 4, line 26		skipping to change at page 4, line 26
	The following paragraphs summarize the processing of SYN segments		The following paragraphs summarize the processing of SYN segments
	received for connections in the TIME-WAIT state. The processing of		received for connections in the TIME-WAIT state. The processing of
	SYN segments received for connections in all other states is		SYN segments received for connections in all other states is
	unchanged. Both the ISN (Initial Sequence Number) and the timestamps		unchanged. Both the ISN (Initial Sequence Number) and the timestamps
	option (if present) of the incoming SYN segment are included in the		option (if present) of the incoming SYN segment are included in the
	heuristics performed for allowing a high connection-establishment		heuristics performed for allowing a high connection-establishment
	rate.		rate.
	Processing of SYN segments received for connections in the TIME-WAIT		Processing of SYN segments received for connections in the TIME-WAIT
	state should occur as follows:		state SHOULD occur as follows:
	o If the previous incarnation of the connection used timestamps,		o If the previous incarnation of the connection used timestamps,
	then,		then,
	* If TCP timestamps would be enabled for the new incarnation of		* If TCP timestamps would be enabled for the new incarnation of
	the connection, and the timestamp contained in the incoming SYN		the connection, and the timestamp contained in the incoming SYN
	segment is greater than the last timestamp seen on the previous		segment is greater than the last timestamp seen on the previous
	incarnation of the connection (for that direction of the data		incarnation of the connection (for that direction of the data
	transfer), honour the connection request (creating a connection		transfer), honour the connection request (creating a connection
	in the SYN-RECEIVED state).		in the SYN-RECEIVED state).
	skipping to change at page 6, line 26		skipping to change at page 6, line 26
	heuristics described above, all these constraints are greatly		heuristics described above, all these constraints are greatly
	relaxed.		relaxed.
	It is clear that the use of TCP timestamps for the heuristics		It is clear that the use of TCP timestamps for the heuristics
	described above benefit from timestamps that are monotonically		described above benefit from timestamps that are monotonically
	increasing across connections between the same two TCP endpoints.		increasing across connections between the same two TCP endpoints.
	Note:		Note:
	The upcoming revision of RFC 1323, [I-D.ietf-tcpm-1323bis],		The upcoming revision of RFC 1323, [I-D.ietf-tcpm-1323bis],
	recommends the selection of timestamps such that they are		recommends the selection of timestamps such that they are
	monotonically-increasing across connections. Specific		monotonically-increasing across connections. An example of such a
	implementation details for such a Timestamps generation scheme can		Timestamps generation scheme can be found in
	be found in [I-D.gont-timestamps-generation].		[I-D.gont-timestamps-generation].
	3. Interaction with various timestamps generation algorithms		3. Interaction with various timestamps generation algorithms
	The algorithm proposed in Section 2 clearly benefits of timestamps		The algorithm proposed in Section 2 clearly benefits of timestamps
	that are monotonically-increasing across connections to the same end-		that are monotonically-increasing across connections to the same end-
	point. In particular, generation of timestamps such that they are		point. In particular, generation of timestamps such that they are
	monotonically-increasing timestamps are important for TCPs that		monotonically-increasing timestamps are important for TCPs that
	perform the active open, as those are the timestamps that will be		perform the active open, as those are the timestamps that will be
	used for the proposed algorithm.		used for the proposed algorithm.
	skipping to change at page 7, line 32		skipping to change at page 7, line 32
	algorithms which do not result in monotonically-increasing ISNs		algorithms which do not result in monotonically-increasing ISNs
	across connections. As noted in [Silbersack], such randomization		across connections. As noted in [Silbersack], such randomization
	schemes break prevent the mechanism proposed in this document from		schemes break prevent the mechanism proposed in this document from
	recycling connections that are in the TIME-WAIT state. However, as		recycling connections that are in the TIME-WAIT state. However, as
	noted earlier in this section, in the worst-case scenario the		noted earlier in this section, in the worst-case scenario the
	heuristics fail, and the result is no worse than the current state-		heuristics fail, and the result is no worse than the current state-
	of-affairs.		of-affairs.
	4. Interaction with various ISN generation algorithms		4. Interaction with various ISN generation algorithms
	[RFC0793] suggests that the ISNs of TCP conections be generated from		[RFC0793] suggests that the ISNs of TCP connections be generated from
	a global timer, such that they are monotonically-increasing across		a global timer, such that they are monotonically-increasing across
	connections. However, this ISN-generation scheme leads to		connections. However, this ISN-generation scheme leads to
	predictable ISNs, which have well-known security implications		predictable ISNs, which have well-known security implications
	[CPNI-TCP]. [RFC1948] proposes an alternative ISN-generation scheme		[CPNI-TCP]. [RFC1948] proposes an alternative ISN-generation scheme
	which results in monotonically-increasing timestamps across		which results in monotonically-increasing timestamps across
	connections that are not easily-predictable by an off-path attacker.		connections that are not easily-predictable by an off-path attacker.
	Some stacks (notably OpenBSD) implement ISN randomization algorithms		Some stacks (notably OpenBSD) implement ISN randomization algorithms
	which do not result in monotonically-increasing ISNs across		which do not result in monotonically-increasing ISNs across
	connections. As noted in [Silbersack], such ISN randomization		connections. As noted in [Silbersack], such ISN randomization
	skipping to change at page 8, line 12		skipping to change at page 8, line 12
	the timestamp contained in the incoming SYN is equal to the last		the timestamp contained in the incoming SYN is equal to the last
	timestamp seen on the connection in the TIME-WAIT state (for that		timestamp seen on the connection in the TIME-WAIT state (for that
	direction of the data transfer).		direction of the data transfer).
	5. Security Considerations		5. Security Considerations
	While the algorithm described in this document for processing		While the algorithm described in this document for processing
	incoming SYN segments would benefit from TCP timestamps that are		incoming SYN segments would benefit from TCP timestamps that are
	monotonically-increasing across connections, this document does not		monotonically-increasing across connections, this document does not
	propose any specific algorithm for generating timestamps, nor does it		propose any specific algorithm for generating timestamps, nor does it
	require monotonically-increasing timestamps across conenctions.		require monotonically-increasing timestamps across connections.
	[CPNI-TCP] contains a detailed discussion of the security		[CPNI-TCP] contains a detailed discussion of the security
	implications of TCP timestamps.		implications of TCP timestamps.
	6. IANA Considerations		6. IANA Considerations
	This document has no actions for IANA.		This document has no actions for IANA.
	7. Acknowledgements		7. Acknowledgements
	The author of this document would like to thank (in alphabetical		The author of this document would like to thank (in alphabetical
	order) Mark Allman, Wesley Eddy, Alfred Hoenes, John Heffner,		order) Mark Allman, Wesley Eddy, Lars Eggert, Alfred Hoenes, John
	Christian Huitema, Eric Rescorla, Joe Touch, and Alexander Zimmermann		Heffner, Christian Huitema, Eric Rescorla, Joe Touch, and Alexander
	for providing valuable feedback on an earlier version of this		Zimmermann for providing valuable feedback on an earlier version of
	document.		this document.
	Additionally, the author would like to thank David Borman for a		Additionally, the author would like to thank David Borman for a
	fruitful discussion on TCP timestamps at IETF 73.		fruitful discussion on TCP timestamps at IETF 73.
	Finally, the author would like to thank the United Kingdom's Centre		Finally, the author would like to thank the United Kingdom's Centre
	for the Protection of National Infrastructure (UK CPNI) for their		for the Protection of National Infrastructure (UK CPNI) for their
	continued support.		continued support.
	8. References		8. References
	skipping to change at page 9, line 5		skipping to change at page 9, line 5
	[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,		[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
	RFC 793, September 1981.		RFC 793, September 1981.
	[RFC1122] Braden, R., "Requirements for Internet Hosts -		[RFC1122] Braden, R., "Requirements for Internet Hosts -
	Communication Layers", STD 3, RFC 1122, October 1989.		Communication Layers", STD 3, RFC 1122, October 1989.
	[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions		[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions
	for High Performance", RFC 1323, May 1992.		for High Performance", RFC 1323, May 1992.
	[RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP",
	RFC 1337, May 1992.
	[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
	[CPNI-TCP]		[CPNI-TCP]
	CPNI, "Security Assessment of the Transmission Control		CPNI, "Security Assessment of the Transmission Control
	Protocol (TCP)", http://www.cpni.gov.uk/Docs/		Protocol (TCP)", http://www.cpni.gov.uk/Docs/
	tn-03-09-security-assessment-TCP.pdf, 2009.		tn-03-09-security-assessment-TCP.pdf, 2009.
	skipping to change at page 9, line 41		skipping to change at page 9, line 38
	1999, pp. 1573-1583 .		1999, pp. 1573-1583 .
	[Linux] The Linux Project, "http://www.kernel.org".		[Linux] The Linux Project, "http://www.kernel.org".
	[Opperman]		[Opperman]
	Oppermann, A., "FYI: Extended TCP syncookies in FreeBSD-		Oppermann, A., "FYI: Extended TCP syncookies in FreeBSD-
	current", Post to the tcpm mailing-list. Available at: ht		current", Post to the tcpm mailing-list. Available at: ht
	tp://www.ietf.org/mail-archive/web/tcpm/current/		tp://www.ietf.org/mail-archive/web/tcpm/current/
	msg02251.html, 2006.		msg02251.html, 2006.
			[RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP",
			RFC 1337, May 1992.
	[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks",		[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks",
	RFC 1948, May 1996.		RFC 1948, May 1996.
	[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common		[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common
	Mitigations", RFC 4987, August 2007.		Mitigations", RFC 4987, August 2007.
	[Silbersack]		[Silbersack]
	Silbersack, M., "Improving TCP/IP security through		Silbersack, M., "Improving TCP/IP security through
	randomization without sacrificing interoperability",		randomization without sacrificing interoperability",
	EuroBSDCon 2005 Conference .		EuroBSDCon 2005 Conference .
	Appendix A. Behavior of the proposed mechanism in specific scenarios		Appendix A. Behavior of the proposed mechanism in specific scenarios
	A.1. Connection request after system reboot		A.1. Connection request after system reboot
	The question was raised on the tcpm mailing-list as to how this		This section clarifies how this algorithm would operate in case a
	algorithm would operate in case a computer reboots, keeps the same IP		computer reboots, keeps the same IP address, looses memory of the
	address, looses memory of the previous time stamps, and then tries to		previous time stamps, and then tries to reestablish a previous
	reestablish a previous connection.		connection.
	Firstly, as specified in [RFC0793], hosts must not establish new		Firstly, as specified in [RFC0793], hosts must not establish new
	connections for a period of 2*MSL after they boot (this is the "quiet		connections for a period of 2*MSL after they boot (this is the "quiet
	time" concept). As a result, specs-wise, this scenario should never		time" concept). As a result, specs-wise, this scenario should never
	occur.		occur.
	If a host does not comply with the "quiet time concept", then the		If a host does not comply with the "quiet time concept", then the
	possible scenarios are:		possible scenarios are:
	o If the selected timestamp for the new connection is monotonically-		o If the selected timestamp for the new connection is monotonically-
	skipping to change at page 10, line 36		skipping to change at page 10, line 36
	o Otherwise, the connection request may time out or be rejected		o Otherwise, the connection request may time out or be rejected
	(depending on whether the workaround described in [RFC1337] is		(depending on whether the workaround described in [RFC1337] is
	implemented or not). This case corresponds to the current state-		implemented or not). This case corresponds to the current state-
	of-affairs without the algorithm proposed in this document.		of-affairs without the algorithm proposed in this document.
	Appendix B. Changes from previous versions of the draft (to be removed		Appendix B. Changes from previous versions of the draft (to be removed
	by the RFC Editor before publishing this document as an		by the RFC Editor before publishing this document as an
	RFC)		RFC)
	B.1. Changes from draft-ietf-tcpm-tcp-timestamps-00		B.1. Changes from draft-ietf-tcpm-tcp-timestamps-01
			o Addresses AD-review comments by Lars Eggert.
			B.2. Changes from draft-ietf-tcpm-tcp-timestamps-00
	o Addresses WG Last call comments received from Wesley Eddy, John		o Addresses WG Last call comments received from Wesley Eddy, John
	Heffner and Joe Touch.		Heffner and Joe Touch.
	o Minor editorial fix (reported by Wes Eddy).		o Minor editorial fix (reported by Wes Eddy).
	B.2. Changes from draft-gont-tcpm-tcp-timestamps-04		B.3. Changes from draft-gont-tcpm-tcp-timestamps-04
	o Draft resubmitted as draft-ietf.		o Draft resubmitted as draft-ietf.
	B.3. Changes from draft-gont-tcpm-tcp-timestamps-03		B.4. Changes from draft-gont-tcpm-tcp-timestamps-03
	o Changed the document title		o Changed the document title
	o Removed all the text related to the algorithm earlier proposed for		o Removed all the text related to the algorithm earlier proposed for
	timestamps generation.		timestamps generation.
	o Addresses comments received from Alexander Zimmermann, Christian		o Addresses comments received from Alexander Zimmermann, Christian
	Huitema, Joe Touch, and others.		Huitema, Joe Touch, and others.
	B.4. Changes from draft-gont-tcpm-tcp-timestamps-02		B.5. Changes from draft-gont-tcpm-tcp-timestamps-02
	o Minor edits (the I-D was just about to expire, so it was		o Minor edits (the I-D was just about to expire, so it was
	resubmitted with almost no changes).		resubmitted with almost no changes).
	B.5. Changes from draft-gont-tcpm-tcp-timestamps-01		B.6. Changes from draft-gont-tcpm-tcp-timestamps-01
	o Version -01 of the draft had expired, and hence the I-D is		o Version -01 of the draft had expired, and hence the I-D is
	resubmitted to make it available again (no changes).		resubmitted to make it available again (no changes).
	B.6. Changes from draft-gont-tcpm-tcp-timestamps-00		B.7. Changes from draft-gont-tcpm-tcp-timestamps-00
	o Fixed author's affiliation.		o Fixed author's affiliation.
	o Addressed feedback submitted by Alfred Hoenes (see:		o Addressed feedback submitted by Alfred Hoenes (see:
	http://www.ietf.org/mail-archive/web/tcpm/current/msg04281.html),		http://www.ietf.org/mail-archive/web/tcpm/current/msg04281.html),
	plus nits sent by Alfred off-list.		plus nits sent by Alfred off-list.
	Author's Address		Author's Address
	Fernando Gont		Fernando Gont
End of changes. 20 change blocks.
	33 lines changed or deleted		39 lines changed or added
This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/