draft-ietf-tcpm-tcp-uto-09.txt		draft-ietf-tcpm-tcp-uto-10.txt
	TCP Maintenance and Minor L. Eggert		TCP Maintenance and Minor L. Eggert
	Extensions (tcpm) Nokia		Extensions (tcpm) Nokia
	Internet-Draft F. Gont		Internet-Draft F. Gont
	Intended status: Standards Track UTN/FRH		Intended status: Standards Track UTN/FRH
	Expires: December 15, 2008 June 13, 2008		Expires: June 4, 2009 December 1, 2008
	TCP User Timeout Option		TCP User Timeout Option
	draft-ietf-tcpm-tcp-uto-09		draft-ietf-tcpm-tcp-uto-10
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 35		skipping to change at page 1, line 35
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on December 15, 2008.		This Internet-Draft will expire on June 4, 2009.
	Abstract		Abstract
	The TCP user timeout controls how long transmitted data may remain		The TCP user timeout controls how long transmitted data may remain
	unacknowledged before a connection is forcefully closed. It is a		unacknowledged before a connection is forcefully closed. It is a
	local, per-connection parameter. This document specifies a new TCP		local, per-connection parameter. This document specifies a new TCP
	option - the TCP User Timeout Option - that allows one end of a TCP		option - the TCP User Timeout Option - that allows one end of a TCP
	connection to advertise its current user timeout value. This		connection to advertise its current user timeout value. This
	information provides advice to the other end of the TCP connection to		information provides advice to the other end of the TCP connection to
	adapt its user timeout accordingly. Increasing the user timeouts on		adapt its user timeout accordingly. Increasing the user timeouts on
	skipping to change at page 2, line 24		skipping to change at page 2, line 24
	3.4. Reserved Option Values . . . . . . . . . . . . . . . . . . 10		3.4. Reserved Option Values . . . . . . . . . . . . . . . . . . 10
	4. Interoperability Issues . . . . . . . . . . . . . . . . . . . 10		4. Interoperability Issues . . . . . . . . . . . . . . . . . . . 10
	4.1. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 10		4.1. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 10
	4.2. TCP Keep-Alives . . . . . . . . . . . . . . . . . . . . . 10		4.2. TCP Keep-Alives . . . . . . . . . . . . . . . . . . . . . 10
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 11		5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 12		8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
	8.2. Informative References . . . . . . . . . . . . . . . . . . 13		8.2. Informative References . . . . . . . . . . . . . . . . . . 13
	Appendix A. Document Revision History . . . . . . . . . . . . . . 13		Appendix A. Document Revision History . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
	Intellectual Property and Copyright Statements . . . . . . . . . . 17		Intellectual Property and Copyright Statements . . . . . . . . . . 17
	1. Introduction		1. Introduction
	The Transmission Control Protocol (TCP) specification [RFC0793]		The Transmission Control Protocol (TCP) specification [RFC0793]
	defines a local, per-connection "user timeout" parameter that		defines a local, per-connection "user timeout" parameter that
	specifies the maximum amount of time that transmitted data may remain		specifies the maximum amount of time that transmitted data may remain
	unacknowledged before TCP will forcefully close the corresponding		unacknowledged before TCP will forcefully close the corresponding
	connection. Applications can set and change this parameter with OPEN		connection. Applications can set and change this parameter with OPEN
	and SEND calls. If an end-to-end connectivity disruption lasts		and SEND calls. If an end-to-end connectivity disruption lasts
	longer than the user timeout, no acknowledgments will be received for		longer than the user timeout, a sender will receive no
	any transmission attempt, including keep-alives, and the TCP		acknowledgments for any transmission attempt, including keep-alives,
	connection will close when the user timeout occurs.		and it will close the TCP connection when the user timeout occurs.
	This document specifies a new TCP option - the TCP User Timeout		This document specifies a new TCP option - the TCP User Timeout
	Option - that allows one end of a TCP connection to advertise its		Option - that allows one end of a TCP connection to advertise its
	current user timeout value. This information provides advice to the		current user timeout value. This information provides advice to the
	other end of the connection to adapt its user timeout accordingly.		other end of the connection to adapt its user timeout accordingly.
	That is, TCP remains free to disregard the advice provided by the UTO		That is, TCP remains free to disregard the advice provided by the UTO
	option if local policies suggest it to be appropriate.		option if local policies suggest it to be appropriate.
	Increasing the user timeouts on both ends of a TCP connection allows		Increasing the user timeouts on both ends of a TCP connection allows
	it to survive extended periods without end-to-end connectivity.		it to survive extended periods without end-to-end connectivity.
	skipping to change at page 4, line 5		skipping to change at page 4, line 5
	Although some TCP implementations allow applications to set their		Although some TCP implementations allow applications to set their
	local user timeout, TCP has no in-protocol mechanism to signal		local user timeout, TCP has no in-protocol mechanism to signal
	changes to the local user timeout to the other end of a connection.		changes to the local user timeout to the other end of a connection.
	This causes local changes to be ineffective in allowing a connection		This causes local changes to be ineffective in allowing a connection
	to survive extended periods without connectivity, because the other		to survive extended periods without connectivity, because the other
	end will still close the connection after its user timeout expires.		end will still close the connection after its user timeout expires.
	The ability to inform the other end of a connection about the local		The ability to inform the other end of a connection about the local
	user timeout can improve TCP operation in scenarios that are		user timeout can improve TCP operation in scenarios that are
	currently not well supported. One example of such a scenario is		currently not well supported. One example of such a scenario is
	mobile hosts that change network attachment points based on current		mobile hosts that change network attachment points. Such hosts,
	location. Such hosts, maybe using Mobile IP [RFC3344], HIP [RFC4423]		maybe using Mobile IP [RFC3344], HIP [RFC4423] or transport-layer
	or transport-layer mobility mechanisms [I-D.eddy-tcp-mobility], are		mobility mechanisms [I-D.eddy-tcp-mobility], are only intermittently
	only intermittently connected to the Internet. In between connected		connected to the Internet. In between connected periods, mobile
	periods, mobile hosts may experience periods without end-to-end		hosts may experience periods without end-to-end connectivity. Other
	connectivity. Other factors that can cause transient connectivity		factors that can cause transient connectivity disruptions are high
	disruptions are high levels of congestion or link or routing failures		levels of congestion or link or routing failures inside the network.
	inside the network. In these scenarios, a host may not know exactly		In these scenarios, a host may not know exactly when or for how long
	when or for how long connectivity disruptions will occur, but it		connectivity disruptions will occur, but it might be able to
	might be able to determine an increased likelihood for such events		determine an increased likelihood for such events based on past
	based on past mobility patterns and thus benefit from using longer		mobility patterns and thus benefit from using longer user timeouts.
	user timeouts. In other scenarios, the time and duration of a		In other scenarios, the time and duration of a connectivity
	connectivity disruption may even be predictable. For example, an		disruption may even be predictable. For example, a node in space
	orbiting node on a non-geostationary satellite might experience		might experience connectivity disruptions due to line-of-sight
	connectivity disruptions due to line-of-sight blocking by other		blocking by planetary bodies. The timing of these events may be
	planetary bodies. The timing of these events may be computable from		computable from orbital mechanics.
	orbital mechanics.
	2. Conventions		2. Conventions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	3. Operation		3. Operation
	Use of the TCP User Timeout Option can be enabled either on a per-		Use of the TCP User Timeout Option can be enabled either on a per-
	skipping to change at page 4, line 48		skipping to change at page 4, line 47
	TCP's USER TIMEOUT parameter, as specified in [RFC0793].		TCP's USER TIMEOUT parameter, as specified in [RFC0793].
	ADV_UTO		ADV_UTO
	UTO option advertised to the remote TCP peer. This is an		UTO option advertised to the remote TCP peer. This is an
	application-specified value, and may be specified on a system-wide		application-specified value, and may be specified on a system-wide
	basis. If unspecified, it defaults to the default system-wide		basis. If unspecified, it defaults to the default system-wide
	USER TIMEOUT.		USER TIMEOUT.
	ENABLED (Boolean)		ENABLED (Boolean)
	Flag that controls whether the UTO option is enabled for a		Flag that controls whether the UTO option is enabled for a
	connection. Defaults to false.		connection. This flag applies to both sending and receiving.
			Defaults to false.
	CHANGEABLE (Boolean)		CHANGEABLE (Boolean)
	Flag that controls whether USER_TIMEOUT (TCP's USER TIMEOUT		Flag that controls whether USER_TIMEOUT (TCP's USER TIMEOUT
	parameter) may be changed based on an UTO option received from the		parameter) may be changed based on an UTO option received from the
	other end of the connection. Defaults to true and becomes false		other end of the connection. Defaults to true and becomes false
	when an application explicitly sets USER_TIMEOUT.		when an application explicitly sets USER_TIMEOUT.
	Note that an exchange of UTO options between both ends of a		Note that an exchange of UTO options between both ends of a
	connection is not a binding negotiation. Transmission of a UTO		connection is not a binding negotiation. Transmission of a UTO
	option is a suggestion that the other end consider adapting its user		option is a suggestion that the other end consider adapting its user
	skipping to change at page 11, line 30		skipping to change at page 11, line 30
	longer durations. Because connection state is kept longer, lower-		longer durations. Because connection state is kept longer, lower-
	frequency attack traffic, which may be more difficult to detect, can		frequency attack traffic, which may be more difficult to detect, can
	already exacerbate resource exhaustion.		already exacerbate resource exhaustion.
	Several approaches can help mitigate this issue. First,		Several approaches can help mitigate this issue. First,
	implementations can require prior peer authentication, e.g., using		implementations can require prior peer authentication, e.g., using
	IPsec [RFC4301] or TCP-MD5 [RFC2385], before accepting long user		IPsec [RFC4301] or TCP-MD5 [RFC2385], before accepting long user
	timeouts for the peer's connections. Similarly, a host can start to		timeouts for the peer's connections. Similarly, a host can start to
	accept long user timeouts for an established connection only after		accept long user timeouts for an established connection only after
	in-band authentication has occurred, for example, after a TLS		in-band authentication has occurred, for example, after a TLS
	handshake across the connection has succeeded [RFC4346]. Although		handshake across the connection has succeeded [RFC5246]. Although
	these are arguably the most complete solutions, they depend on		these are arguably the most complete solutions, they depend on
	external mechanisms to establish a trust relationship.		external mechanisms to establish a trust relationship.
	A second alternative that does not depend on external mechanisms		A second alternative that does not depend on external mechanisms
	would introduce a per-peer limit on the number of connections that		would introduce a per-peer limit on the number of connections that
	may use increased user timeouts. Several variants of this approach		may use increased user timeouts. Several variants of this approach
	are possible, such as fixed limits or shortening accepted user		are possible, such as fixed limits or shortening accepted user
	timeouts with a rising number of connections. Although this		timeouts with a rising number of connections. Although this
	alternative does not eliminate resource exhaustion attacks from a		alternative does not eliminate resource exhaustion attacks from a
	single peer, it can limit their effects. Reducing the number of		single peer, it can limit their effects. Reducing the number of
	skipping to change at page 12, line 31		skipping to change at page 12, line 31
	This document does not define any new namespaces. It requests that		This document does not define any new namespaces. It requests that
	IANA allocate a new 8-bit TCP option number for the UTO option from		IANA allocate a new 8-bit TCP option number for the UTO option from
	the registry maintained at		the registry maintained at
	http://www.iana.org/assignments/tcp-parameters.		http://www.iana.org/assignments/tcp-parameters.
	7. Acknowledgments		7. Acknowledgments
	The following people have improved this document through thoughtful		The following people have improved this document through thoughtful
	suggestions: Mark Allman, Caitlin Bestler, David Borman, Bob Braden,		suggestions: Mark Allman, Caitlin Bestler, David Borman, Bob Braden,
	Marcus Brunner, Wesley Eddy, Gorry Fairhurst, Abolade Gbadegesin, Ted		Scott Brim, Marcus Brunner, Wesley Eddy, Gorry Fairhurst, Abolade
	Faber, Guillermo Gont, Tom Henderson, Joseph Ishac, Jeremy Harris,		Gbadegesin, Ted Faber, Guillermo Gont, Tom Henderson, Joseph Ishac,
	Alfred Hoenes, Phil Karn, Michael Kerrisk, Dan Krejsa, Jamshid		Jeremy Harris, Alfred Hoenes, Phil Karn, Michael Kerrisk, Dan Krejsa,
	Mahdavi, Kostas Pentikousis, Juergen Quittek, Anantha Ramaiah, Joe		Jamshid Mahdavi, Kostas Pentikousis, Juergen Quittek, Anantha
	Touch, Stefan Schmid, Simon Schuetz, Tim Shepard and Martin		Ramaiah, Joe Touch, Stefan Schmid, Simon Schuetz, Tim Shepard and
	Stiemerling.		Martin Stiemerling.
			Lars Eggert is partly funded by [TRILOGY], a research project
			supported by the European Commission under its Seventh Framework
			Program.
	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 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.
	skipping to change at page 13, line 33		skipping to change at page 13, line 38
	[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission		[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
	Timer", RFC 2988, November 2000.		Timer", RFC 2988, November 2000.
	[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,		[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
	August 2002.		August 2002.
	[RFC4301] Kent, S. and K. Seo, "Security Architecture for the		[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
	Internet Protocol", RFC 4301, December 2005.		Internet Protocol", RFC 4301, December 2005.
	[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.1", RFC 4346, April 2006.
	[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol		[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
	(HIP) Architecture", RFC 4423, May 2006.		(HIP) Architecture", RFC 4423, May 2006.
	[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.
			[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
			(TLS) Protocol Version 1.2", RFC 5246, August 2008.
	[SOLARIS-MANUAL]		[SOLARIS-MANUAL]
	Sun Microsystems, "Solaris Tunable Parameters Reference		Sun Microsystems, "Solaris Tunable Parameters Reference
	Manual", Part No. 806-7009-10, 2002.		Manual", Part No. 806-7009-10, 2002.
			[TRILOGY] "Trilogy Project", http://www.trilogy-project.org/.
	Appendix A. Document Revision History		Appendix A. Document Revision History
	[[Note to the RFC Editor: Section to be removed upon publication.]]		[[Note to the RFC Editor: Section to be removed upon publication.]]
	+----------+--------------------------------------------------------+		+----------+--------------------------------------------------------+
	| Revision | Comments |		| Revision | Comments |
	+----------+--------------------------------------------------------+		+----------+--------------------------------------------------------+
			| -10 | Addressing the gen-art review comments from Scott |
			| | Brim. Updated reference to [RFC5246]. Added funding |
			| | source acknowledgment. |
			| | |
	| -09 | Resubmission after expiration. Updated reference to |		| -09 | Resubmission after expiration. Updated reference to |
	| | [RFC5226]. |		| | [RFC5226]. |
	| | |		| | |
	| -08 | Addressed additional, minor working group last call |		| -08 | Addressed additional, minor working group last call |
	| | comments. |		| | comments. |
	| | |		| | |
	| -07 | Addressed working group last call comments. |		| -07 | Addressed working group last call comments. |
	| | |		| | |
	| -06 | Includes a note on the limited space for TCP options |		| -06 | Includes a note on the limited space for TCP options |
	| | and miscellaneous editorial changes (suggested by |		| | and miscellaneous editorial changes (suggested by |
End of changes. 14 change blocks.
	35 lines changed or deleted		46 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/