draft-ietf-tcpm-tcp-uto-00.txt		draft-ietf-tcpm-tcp-uto-01.txt
	TCP Maintenance and Minor L. Eggert		TCP Maintenance and Minor L. Eggert
	Extensions (tcpm) NEC		Extensions (tcpm) NEC
	Internet-Draft F. Gont		Internet-Draft F. Gont
	Expires: November 24, 2005 UTN/FRH		Expires: January 16, 2006 UTN/FRH
	May 23, 2005		July 15, 2005
	TCP User Timeout Option		TCP User Timeout Option
	draft-ietf-tcpm-tcp-uto-00		draft-ietf-tcpm-tcp-uto-01
	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 November 24, 2005.		This Internet-Draft will expire on January 16, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2005).
	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 aborted. TCP implementations		unacknowledged before a connection is forcefully closed. It is a
	typically use a single, system-wide user timeout value. The TCP User		local, per-connection parameter. The advisory TCP User Timeout
	Timeout Option allows conforming TCP implementations to exchange		Option allows conforming TCP implementations to exchange their local
	requests for individual, per-connection user timeouts. Lengthening		user timeouts. This exchange provides an in-protocol mechanism to
	the system-wide default user timeout allows established TCP		coordinate raising or lowering the two user timeouts of a connection.
	connections to survive extended periods of disconnection. On the		Increase the user timeouts allows established TCP connections to
	other hand, shortening the default user timeout allows busy servers		survive extended periods of disconnection. Decreasing user timeouts
	to explicitly notify their clients they will maintain the connection		allows busy servers to explicitly notify their clients that they will
	state information only accross short periods of disconnection.		maintain the connection state only across short periods of
			disconnection.
	1. Introduction		1. Introduction
	The Transmission Control Protocol (TCP) specification [1] defines a		The Transmission Control Protocol (TCP) specification [RFC0793]
	"user timeout" parameter that specifies the maximum amount of time		defines a local, per-connection "user timeout" parameter that
	that transmitted data may remain unacknowledged before TCP will abort		specifies the maximum amount of time that transmitted data may remain
	the corresponding connection. If a disconnection lasts longer than		unacknowledged before TCP will forcefully close the corresponding
	the user timeout, no acknowledgments will be received for any		connection. Applications can set and change this parameter with OPEN
	transmission attempt, including keep-alives [5], and the TCP		and SEND calls. If a network disconnection lasts longer than the
	connection will be aborted when the user timeout occurs.		user timeout, no acknowledgments will be received for any
			transmission attempt, including keep-alives [TCP-ILLU], and the TCP
			connection will close when the user timeout occurs. In the absence
			of an application-specified user timeout, the TCP specification
			[RFC0793] defines a default user timeout of 5 minutes.
	The TCP specification [1] does not constrain the permitted values for		The Host Requirements RFC [RFC1122] refines this definition by
	user timeouts. However, the Host Requirements RFC [2] mandates a		introducing two thresholds, R1 and R2 (R2 > R1), on the number of
	timeout of at least three minutes for the SYN-SENT case. Many TCP		retransmissions of a single segment. It suggests that TCP notify
	implementations default to user timeout values of a few minutes [5].		applications when R1 is reached for a segment, and close the
	Instead of a single user timeout, some TCP implementations offer		connection once R2 is reached. [RFC1122] also refines the
	finer-grained policies. For example, Solaris supports different		recommended values for R1 (three retransmissions) and R2 (100
	timeouts depending on whether a TCP connection is in the SYN-SENT,		seconds), noting that R2 for SYN segments should be at least 3
	SYN-RECEIVED, or ESTABLISHED state [6].		minutes. Instead of a single user timeout, some TCP implementations
			offer finer-grained policies. For example, Solaris supports
			different timeouts depending on whether a TCP connection is in the
			SYN-SENT, SYN-RECEIVED, or ESTABLISHED state [SOLARIS-MANUAL].
	System-wide user timeouts are a useful basic policy. However, the		Although applications may set their local user timeout, there is no
	ability to selectively choose individual user timeout values for		in-protocol mechanism to signal changes in the local user timeout to
	different connections can improve TCP operation in scenarios that are		remote peers. This causes local changes to be ineffective, because,
	currently not well supported. One example of such scenarios are		for example, the peer will still close the connection after its user
	mobile hosts that change network attachment points based on current		timeout expires, even when a host has raised its local user timeout.
	location. Such hosts, maybe using MobileIP [7], HIP [8] or		The ability to modify the two user timeouts associated with a
	transport-layer mobility mechanisms [9], are only intermittently		connection in a coordinated manner can improve TCP operation in
	connected to the Internet. In between connected periods, mobile		scenarios that are currently not well supported. One example of such
	hosts may experience periods of disconnection during which no network		scenarios are mobile hosts that change network attachment points
	service is available [10][11][12]. Other factors that can cause		based on current location. Such hosts, maybe using MobileIP
	transient periods of disconnection are high levels of congestion as		[RFC3344], HIP [I-D.ietf-hip-arch] or transport-layer mobility
	well as link or routing failures inside the network.		mechanisms [I-D.eddy-tcp-mobility], are only intermittently connected
			to the Internet. In between connected periods, mobile hosts may
			experience periods of disconnection during which no network service
			is available [SCHUETZ-THESIS][SCHUETZ-CCR][DRIVE-THRU]. Other
			factors that can cause transient periods of disconnection are high
			levels of congestion as well as link or routing failures inside the
			network.
	In scenarios similar to the ones described above, a host may not know		In scenarios similar to the ones described above, a host may not know
	exactly when or for how long it will be disconnected from the		exactly when or for how long it will be disconnected from the
	network, but it might expect such events due to past mobility		network, but it might expect such events due to past mobility
	patterns and thus benefit from using longer user timeouts. In other		patterns and thus benefit from using longer user timeouts. In other
	scenarios, the length and time of a network disconnection may even be		scenarios, the length and time of a network disconnection may even be
	predictable. For example, an orbiting node on a satellite might		predictable. For example, an orbiting node on a satellite might
	experience disconnections due to line-of-sight blocking by other		experience disconnections due to line-of-sight blocking by other
	planetary bodies. The disconnection periods of such a node may be		planetary bodies. The disconnection periods of such a node may be
	easily computable from orbital mechanics.		easily computable from orbital mechanics.
	In the examples above, as well as in other cases, established TCP		This document specifies a new TCP option - the User Timeout Option
	connections between two peers may be aborted if a disconnection		(UTO) - that allows conforming hosts to exchange their local, per-
	exceeds the system-wide default user timeout. This document		connection user timeout information. This allows, for example,
	specifies a new TCP option - the User Timeout Option - that allows		mobile hosts to maintain TCP connections across disconnected periods
	conforming hosts to exchange per-connection user timeout requests.		that are longer than their peer's default user timeout. A second use
	This allows, for example, mobile hosts to maintain TCP connections		of the TCP User Timeout Option is advertisement of shorter-than-
	across disconnected periods that are longer than their system's		default user timeouts. This can allow busy servers to explicitly
	default user timeout. A second use of the TCP User Timeout Option is		notify their clients that they will maintain the state associated
	advertisement of shorter-than-default user timeouts. This can allow		with established connections only across short periods of
	busy servers to explicitly notify their clients that they will		disconnection.
	maintain the state associated with established connections only
	across short periods of disconnection.		The same benefits can be obtained through an application-layer
			mechanism, i.e., coordinating changes to the user timeout values of a
			connection through application messages. This approach does not
			require a new TCP option, but requires application changes.
	A different approach to tolerate longer periods of disconnection is		A different approach to tolerate longer periods of disconnection is
	simply increasing the system-wide user timeout on both peers. This		simply increasing the system-wide user timeout on both peers. This
	approach has the benefit of not requiring a new TCP option. However,		approach has the benefit of not requiring a new TCP option. However,
	it can also significantly increase the amount of connection state		it can also significantly increase the amount of connection state
	information a host must maintain, because a longer global timeout		information a busy server must maintain, because a longer global
	value will apply to all its connections. The proposed User Timeout		timeout value will apply to all its connections. The proposed TCP
	Option, on the other hand, allows hosts to selectively manage the		User Timeout Option, on the other hand, allows hosts to selectively
	user timeouts of individual connections. They must then only		manage the user timeouts of individual connections, reducing the
	maintain the state associated with selected connections across		amount of state they must maintain across disconnected periods.
	disconnected periods.
	A second benefit of the TCP User Timeout Option is that it allows
	hosts to both request specific user timeouts for new connections and
	to request changes to the effective user timeouts of established
	connections. The latter allows connections to start with short
	timeouts and only request longer timeouts when disconnection is
	imminent, and only for connections considered important. The ability
	to request changes to user timeouts of established connections is
	also useful to raise the user timeout after in-band authentication
	has occurred. For example, peers could request longer user timeouts
	for the TCP connections underlying two-way authenticated TLS
	connections [13] after their authentication handshakes have
	succeeded.
	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 RFC 2119 [3].		document are to be interpreted as described in [RFC2119].
	3. Operation		3. Operation
	Sending a TCP User Timeout Option suggests to the remote peer to use		Sending a TCP User Timeout Option suggests that the remote peer
	the indicated user timeout value for the corresponding connection.		SHOULD start using the indicated user timeout value for the
	Section 3.4 discusses the effects of different timeout values.		corresponding connection. The user timeout value included in a TCP
			User Timeout Option specifies the requested user timeout during the
			synchronized states of a connection (ESTABLISHED, FIN-WAIT-1, FIN-
			WAIT-2, CLOSE-WAIT, CLOSING, or LAST-ACK). Connections in other
			states MUST use standard timeout values [RFC0793][RFC1122]. [anchor4]
	The user timeout value included in a TCP User Timeout Option		Note that an exchange of TCP User Timeout Options between peers is
	specifies the requested user timeout during a connection's		not a binding negotiation. Transmission of a TCP User Timeout Option
	synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT,		is an advisory suggestion that the peer consider adapting its local
	CLOSING, or LAST-ACK.) Connections in other states MUST use standard		user timeout. Hosts remain free to forcefully close or abort
	timeout values [1][2]. [Comment.1]		connections at any time for any reason, whether or not they use
			custom user timeouts or have suggested to the peer to use them.
			A host that supports the TCP User Timeout Option SHOULD include it in
			the next possible segment to its peer whenever it starts using a new
			user timeout for the connection. This allows the peer to adapt its
			local user timeout for the connection accordingly.
	When a host that supports the TCP User Timeout Option receives one,		When a host that supports the TCP User Timeout Option receives one,
	it decides whether to change the connection's local user timeout		it decides whether to change its local user timeout of the connection
	based on the received value. Generally, hosts SHOULD honor requests		based on the received value. Generally, hosts should honor requests
	for changes to the user timeout, unless security concerns or external		for changes to the user timeout (see Section 3.3), unless security
	policies indicate otherwise (see Section 5.) If so, hosts MAY ignore		concerns, resource constraints or external policies indicate
	incoming TCP User Timeout Options and MAY use a different user		otherwise (see Section 5). If so, hosts may ignore incoming TCP User
	timeout for the connection.		Timeout Options and use a different user timeout for the connection.
	It is important to note that the TCP User Timeout Option does not		When a host receives a TCP User Timeout Option, it first decides
	change the semantics of the TCP protocol. Hosts remain free to abort		whether to change its local user timeout for the connection (see
	connections at any time for any reason, whether or not they use		Section 3.3) and then decides whether to send a TCP User Timeout
	custom user timeouts or have suggested the peer to use them.		Option to its peer in response. If it has never sent a TCP User
			Timeout Option to its peer during the lifetime of the connection or
			if it has changed its local user timeout, it SHOULD send TCP User
			Timeout Option with its current local user timeout to its peer.
			[anchor5]
			A host that supports the TCP User Timeout Option SHOULD include one
			in each packet that carries a SYN flag, but need not. [MEDINA] has
			shown that unknown options are correctly handled by the vast majority
			of modern TCP stacks. It is thus not necessary to require
			negotiation use of the TCP User Timeout Option for a connection.
			A TCP implementation that does not support the TCP User Timeout
			Option MUST silently ignore it [RFC1122], thus ensuring
			interoperability.
	Hosts SHOULD impose upper and lower limits on the user timeouts they		Hosts SHOULD impose upper and lower limits on the user timeouts they
	use. Section 3.4 discusses user timeout limits. A TCP User Timeout		use. Section 3.3 discusses user timeout limits. A TCP User Timeout
	Option with a value of zero (i.e., "now") is nonsensical and MUST NOT		Option with a value of zero (i.e., "now") is nonsensical and is used
	be sent. If received, it MUST be ignored. Section 3.4 discusses		for a special purpose, see Section 3.4. Section 3.3 discusses
	potentially problematic effects of other user timeout durations.		potentially problematic effects of other user timeout durations.
	A TCP implementation that does not support the TCP User Timeout		3.1 Reliability Considerations
	Option SHOULD silently ignore it [2], thus ensuring interoperability.
	3.1 Option Format		The TCP User Timeout Option is an advisory TCP option that does not
			change processing for subsequent segments. Unlike other TCP options,
			it need not be exchanged reliably. Consequently, the specification
			in this section does not define a reliability handshake for TCP User
			Timeout Option exchanges. When a segment that carries a TCP User
			Timeout Option is lost, the option may never reach the intended peer.
			Implementations MAY implement local mechanisms to improve delivery
			reliability, such as retransmitting the TCP User Timeout Option when
			they retransmit the segment that originally carried it or "attaching"
			the option to a byte in the stream and retransmitting the option
			whenever that byte or its ACK are retransmitted.
			It is important to note that although these mechanisms can improve
			transmission reliability for the TCP User Timeout Option, they do not
			guarantee delivery (a three-way handshake would be required for
			this). Consequently, implementations MUST NOT assume that a TCP User
			Timeout Option is reliably transmitted.
			3.2 Option Format
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Kind = X | Length = 4 |G| User Timeout |		| Kind = X | Length = 4 |G| User Timeout |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	(One tick mark represents one bit.)		(One tick mark represents one bit.)
	Figure 1: Format of the TCP User Timeout Option		Figure 1: Format of the TCP User Timeout Option
	Figure 1 shows the format of the TCP User Timeout Option. It		Figure 1 shows the format of the TCP User Timeout Option. It
	contains these fields:		contains these fields:
	Kind (8 bits)		Kind (8 bits)
	A TCP option number [1] to be assigned by IANA upon publication of		A TCP option number [RFC0793] to be assigned by IANA upon
	this document (see Section 6.)		publication of this document (see Section 6).
	Length (8 bits)		Length (8 bits)
	Length of the TCP option in octets [1]; its value MUST be 4.		Length of the TCP option in octets [RFC0793]; its value MUST be 4.
	Granularity (1 bit)		Granularity (1 bit)
	Granularity bit, indicating the granularity of the "User Timeout"		Granularity bit, indicating the granularity of the "User Timeout"
	field. When set (G = 1), the time interval in the "User Timeout"		field. When set (G = 1), the time interval in the "User Timeout"
	field MUST be interpreted as minutes. Otherwise (G = 0), the time		field MUST be interpreted as minutes. Otherwise (G = 0), the time
	interval in the "User Timeout" field MUST be interpreted as		interval in the "User Timeout" field MUST be interpreted as
	seconds.		seconds.
	User Timeout (15 bits)		User Timeout (15 bits)
	Specifies the user timeout suggestion for this connection. It		Specifies the user timeout suggestion for this connection. It
	MUST be interpreted as a 15-bit unsigned integer. The granularity		MUST be interpreted as a 15-bit unsigned integer. The granularity
	of the timeout (minutes or seconds) depends on the "G" field.		of the timeout (minutes or seconds) depends on the "G" field.
	3.2 Operation During the SYN Handshake		3.3 Duration of the User Timeout
	A host that supports the TCP User Timeout Option MUST include an
	appropriate TCP User Timeout Option in its initial SYN segment to
	indicate that it supports the option and to suggest an initial user
	timeout for the connection. [Comment.2]
	A host that supports the TCP User Timeout Option and receives a SYN
	segment that includes one MUST respond with an appropriate TCP User
	Timeout Option in its SYN-ACK segment. If an incoming SYN segment
	does not include a TCP User Timeout Option, a host MUST NOT include
	one in the SYN-ACK segment nor in any other segment, and it MUST
	ignore the contents of any other received TCP User Timeout Option.
	3.3 Operation During the Synchronized States
	Unless both the SYN and SYN-ACK of a connection contained TCP User
	Timeout Options, both hosts participating in the connection MUST NOT
	send TCP User Timeout Options in any other segment. Additionally,
	they both MUST ignore the contents of any received TCP User Timeout
	Option.
	If, however, both the SYN and SYN-ACK contained TCP User Timeout
	Options, hosts MAY choose to include additional TCP User Timeout
	Options in segments sent during the synchronized states (ESTABLISHED,
	FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, or LAST-ACK).
	Dynamically adapting the user timeout of a connection during its
	lifetime could be useful in a number of scenarios, for example:
	o TCP may adapt the user timeout based on observed network
	characteristics. [Comment.3]
	o TCP may use short timeouts when connections start and only suggest
	longer timeouts when disconnection was imminent.
	o TCP may use short user timeouts when connections start and only
	raise them once in-band authentication has occurred, for example,
	once a TLS handshake across the connection has succeeded [13].
	Generally, whenever a host decides to change the local user timeout
	of a connection, it SHOULD include a TCP User Timeout Option
	indicating the new user timeout in its next segment to the peer.
	This allows the peer to adapt its local user timeout for the
	connection accordingly.
	TCP's SYN handshake has specific retransmission rules to guarantee
	reliability. These mechanisms also guarantee that the exchange of
	TCP User Timeout Options during the SYN handshake is reliable. This
	is not the case for TCP User Timeout Option exchanges during the
	synchronized states. When a segment carrying a TCP User Timeout
	Option is lost, the peer will not update its local user timeout
	accordingly. This draft does not currently describe mechanisms to
	ensure the reliability of the option exchange in the synchronized
	states, other than noting that periodic inclusion of the option may
	be an appropriate interim mechanism for implementations concerned
	with reliability.
	3.4 Duration of the User Timeout
	The TCP User Timeout Option allows hosts to exchange user timeout		The TCP User Timeout Option allows hosts to exchange user timeout
	values from zero seconds to over 9 hours at a granularity of seconds		values from 1 second to over 9 hours at a granularity of seconds and
	and from zero minutes to over 22 days at a granularity of minutes.		from 1 minute to over 22 days at a granularity of minutes. (An
			option value of zero is reserved for a special purpose, see
			Section 3.4.)
	Very short user timeout values can affect TCP transmissions over		Very short user timeout values can affect TCP transmissions over
	high-delay paths. If the user timeout occurs before an		high-delay paths. If the user timeout occurs before an
	acknowledgment for an outstanding segment arrives, possibly due to		acknowledgment for an outstanding segment arrives, possibly due to
	packet loss, the connection aborts. Many TCP implementations default		packet loss, the connection closes. Many TCP implementations default
	to user timeout values of a few minutes [5]. Although the TCP User		to user timeout values of a few minutes [TCP-ILLU]. Although the TCP
	Timeout Option allows suggestion of short timeouts, applications		User Timeout Option allows suggestion of short timeouts, applications
	advertising them should consider these effects.		advertising them SHOULD consider these effects.
	Long user timeout values allow hosts to tolerate extended periods of		Long user timeout values allow hosts to tolerate extended periods of
	disconnection. However, they also require hosts to maintain the TCP		disconnection. However, they also require hosts to maintain the TCP
	state information associated with connections for long periods of		state information associated with connections for long periods of
	time. Section 5 discusses the security implications of long timeout		time. Section 5 discusses the security implications of long timeout
	values.		values.
	To protect against these effects, implementations SHOULD impose		To protect against these effects, implementations SHOULD impose
	limits on the user timeout values they accept and use. The remainder		limits on the user timeout values they accept and use. The remainder
	of this section describes a RECOMMENDED scheme to limit user timeouts		of this section describes a RECOMMENDED scheme to limit user timeouts
	based on upper and lower limits. Under the RECOMMENDED scheme, each		based on upper and lower limits. Under the RECOMMENDED scheme, each
	TCP SHOULD compute the user timeout (USER_TIMEOUT) for a connection		TCP SHOULD compute the user timeout (USER_TIMEOUT) for a connection
	according to this formula:		according to this formula:
	USER_TIMEOUT = min(U_LIMIT, max(LOCAL_UTO, REMOTE_UTO, L_LIMIT))		USER_TIMEOUT = min(U_LIMIT, max(LOCAL_UTO, REMOTE_UTO, L_LIMIT))
	[Comment.4]
	Each field is to be interpreted as follows:		Each field is to be interpreted as follows:
	USER_TIMEOUT		USER_TIMEOUT
	Resulting user timeout value to be adopted by the local TCP for a		Resulting user timeout value to be adopted by the local TCP for a
	connection.		connection.
	U_LIMIT		U_LIMIT
	Current upper limit imposed on the connection's user timeout by		Current upper limit imposed on the user timeout of a connection by
	the local host.		the local host.
	L_LIMIT		L_LIMIT
	Current lower limit imposed on the connection's user timeout by		Current lower limit imposed on the user timeout of a connection by
	the local host.		the local host.
	LOCAL_UTO		LOCAL_UTO
	Current local user timeout of the specific connection.		Current local user timeout of the specific connection.
	REMOTE_UTO		REMOTE_UTO
	Last "user timeout" value suggested by the remote peer by means of		Last "user timeout" value suggested by the remote peer by means of
	the TCP User Timeout Option.		the TCP User Timeout Option.
	This means that the maximum of the two announced values will be		This means that the maximum of the two announced values will be
	adopted for the user timeout of the connection. The rationale is		adopted for the user timeout of the connection. The rationale is
	that choosing the maximum of the two values will let the connection		that choosing the maximum of the two values will let the connection
	survive transient periods of disconnection. If the TCP that		survive longer periods of disconnection. If the TCP that announced
	announced the lower of the two user timeout values did so in order to		the lower of the two user timeout values did so in order to reduce
	reduce the amount of TCP state information that must be kept on the		the amount of TCP state information that must be kept on the host, it
	host, it can, nevertheless, abort the connection whenever it wants.		can, nevertheless, close or abort the connection whenever it wants.
	Enforcing a lower limit (L_LIMIT) protects against connection aborts		Enforcing a lower limit (L_LIMIT) prevents connections from closing
	due to transient network conditions, including temporary congestion,		due to transient network conditions, including temporary congestion,
	mobility hand-offs and routing instabilities.		mobility hand-offs and routing instabilities.
	An upper limit (U_LIMIT) can reduce the effect of resource exhaustion		An upper limit (U_LIMIT) can reduce the effect of resource exhaustion
	attacks. Section 5 discusses the details of these attacks.		attacks. Section 5 discusses the details of these attacks.
	Note that these limits MAY be specified as system-wide constants or		Note that these limits MAY be specified as system-wide constants or
	at other granularities, such as on per-host, per-user or even per-		at other granularities, such as on per-host, per-user or even per-
	connection basis. Furthermore, these limits need not be static. For		connection basis. Furthermore, these limits need not be static. For
	example, they MAY be a function of system resource utilization or		example, they MAY be a function of system resource utilization or
	attack status and could be dynamically adapted.		attack status and could be dynamically adapted.
	The Host Requirements RFC [2] does not impose any limits on the		The Host Requirements RFC [RFC1122] does not impose any limits on the
	length of the user timeout. However, a time interval of at least 100		length of the user timeout. However, a time interval of at least 100
	seconds is RECOMMENDED. Consequently, the lower limit (LLIMIT)		seconds is RECOMMENDED. Consequently, the lower limit (L_LIMIT)
	SHOULD be set to at least 100 seconds when following the RECOMMENDED		SHOULD be set to at least 100 seconds when following the RECOMMENDED
	scheme described in this section.		scheme described in this section.
			3.4 Special Option Values
			Whenever it is legal to do so according to the specification in the
			previous sections, TCP implementations MAY send a zero-second TCP
			User Timeout Option, i.e, with a "User Timeout" field of zero and a
			"Granularity" of zero. This signals their peers that they support
			the option, but do not suggest a specific user timeout value at that
			time. Essentially, a zero-second TCP User Timeout Option acts as a
			"don't care" value.
			The receiver of a zero-second TCP User Timeout Option SHOULD perform
			the RECOMMENDED strategy for calculating a new local USER_TIMEOUT
			described in Section 3.3 with a numeric value of zero seconds for
			REMOTE_UTO. The sender SHOULD perform the calculation as described
			in Section 3.3. Essentially, the sender SHOULD adapt the peer's UTO
			and the receiver SHOULD continue using its local UTO.
			A zero-minute TCP User Timeout Option, i.e., with a "User Timeout"
			field of zero and a "Granularity" bit of one, is reserved for future
			use. TCP implementations MUST NOT sent it and MUST ignore it upon
			reception.
	4. Interoperability Issues		4. Interoperability Issues
	This section discusses interoperability issues related to introducing		This section discusses interoperability issues related to introducing
	the UTO option.		the TCP User Timeout Option.
	One meta-issue of introducing new TCP options is that header space
	available for TCP options is currently limited to 40 bytes. All
	negotiable options are exchanged during the SYN/SYN-ACK handshake,
	where option space is becoming limited. Current proposals to extend
	the available option space may mitigate this issue [14].
	4.1 Middleboxes		4.1 Middleboxes
	The large number of middleboxes (firewalls, proxies, protocol		The large number of middleboxes (firewalls, proxies, protocol
	scrubbers, etc.) currently present in the Internet pose some		scrubbers, etc.) currently present in the Internet pose some
	difficulty for deploying new TCP options. Some firewalls may block		difficulty for deploying new TCP options. Some firewalls may block
	segments that carry unknown options, preventing connection		segments that carry unknown options, preventing connection
	establishment when the SYN or SYN-ACK contains the UTO option. Some		establishment when the SYN or SYN-ACK contains a TCP User Timeout
	recent results, however, indicate that for new TCP options, this may		Option. Some recent results, however, indicate that for new TCP
	not be a significant threat, with only 0.2% of web requests failing		options, this may not be a significant threat, with only 0.2% of web
	when carrying an unknown option [15].		requests failing when carrying an unknown option [MEDINA].
	Stateful firewalls usually reset connections after a period of		Stateful firewalls usually reset connections after a period of
	inactivity. If such a firewall exists along the path between two		inactivity. If such a firewall exists along the path between two
	peers, it may abort connections regardless of the use of the UTO		peers, it may close or abort connections regardless of the use of the
	Option. In the future, such firewalls may learn to parse the UTO		TCP User Timeout Option. In the future, such firewalls may learn to
	option and modify their behavior accordingly.		parse the TCP User Timeout Option and modify their behavior or the
			option accordingly.
	4.2 TCP Keep-Alives		4.2 TCP Keep-Alives
	Some TCP implementations, such as the one in BSD systems, use a		Some TCP implementations, such as the one in BSD systems, use a
	different abort policy for TCP keepalives than for user data. Thus,		different abort policy for TCP keep-alives than for user data. Thus,
	the TCP keep-alive mechanism might abort a connection that would		the TCP keep-alive mechanism might abort a connection that would
	otherwise have survived the transient period of disconnection.		otherwise have survived the transient period of disconnection.
	Therefore, if a TCP peer enables TCP keep-alives for a connection		Therefore, if a TCP peer enables TCP keep-alives for a connection
	that is using the UTO Option, then the keep-alive timer MUST be set		that is using the TCP User Timeout Option, then the keep-alive timer
	to a value larger than that of the adopted USER TIMEOUT (specified by		MUST be set to a value larger than that of the adopted USER TIMEOUT.
	Equation 1).
	5. Security Considerations		5. Security Considerations
	Lengthening user timeouts has obvious security implications.		Lengthening user timeouts has obvious security implications.
	Flooding attacks cause denial of service by forcing servers to commit		Flooding attacks cause denial of service by forcing servers to commit
	resources for maintaining the state of throw-away connections. TCP		resources for maintaining the state of throw-away connections. TCP
	implementations do not become more vulnerable to simple SYN flooding		implementations do not become more vulnerable to simple SYN flooding
	by implementing the TCP User Timeout Option, because user timeouts		by implementing the TCP User Timeout Option, because user timeouts
	negotiated during the handshake only affect the synchronized states		negotiated during the handshake only affect the synchronized states
	(ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK),		(ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK),
	which simple SYN floods never reach.		which simple SYN floods never reach.
	However, when an attacker completes the three-way handshakes of its		However, when an attacker completes the three-way handshakes of its
	throw-away connections it can amplify the effects of resource		throw-away connections it can amplify the effects of resource
	skipping to change at page 9, line 19		skipping to change at page 9, line 28
	negotiated during the handshake only affect the synchronized states		negotiated during the handshake only affect the synchronized states
	(ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK),		(ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK),
	which simple SYN floods never reach.		which simple SYN floods never reach.
	However, when an attacker completes the three-way handshakes of its		However, when an attacker completes the three-way handshakes of its
	throw-away connections it can amplify the effects of resource		throw-away connections it can amplify the effects of resource
	exhaustion attacks, because the attacked server must maintain the		exhaustion attacks, because the attacked server must maintain the
	connection state associated with the throw-away connections for		connection state associated with the throw-away connections for
	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 cause resource exhaustion. [Comment.5]		already cause 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 [16], before accepting long user timeouts for the peer's		IPsec [I-D.ietf-ipsec-rfc2401bis], before accepting long user
	connections. Similarly, a host can only start to accept long user		timeouts for the peer's connections. Similarly, a host can only
	timeouts for an established connection after in-band authentication		start to accept long user timeouts for an established connection
	has occurred, for example, after a TLS handshake across the		after in-band authentication has occurred, for example, after a TLS
	connection has succeeded [13]. Although these are arguably the most		handshake across the connection has succeeded [RFC2246]. Although
	complete solutions, they depend on external mechanisms to establish a		these are arguably the most complete solutions, they depend on
	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.		single peer, it can limit their effects. Reducing the number of
			high-UTO connections a server supports in the face of an attack turns
			that attack into a denial-of-service attack against the service of
			high-UTO connections.
	Per-peer limits cannot protect against distributed denial of service		Per-peer limits cannot protect against distributed denial of service
	attacks, where multiple clients coordinate a resource exhaustion		attacks, where multiple clients coordinate a resource exhaustion
	attack that uses long user timeouts. To protect against such		attack that uses long user timeouts. To protect against such
	attacks, TCP implementations could reduce the duration of accepted		attacks, TCP implementations could reduce the duration of accepted
	user timeouts with increasing resource utilization.		user timeouts with increasing resource utilization.
	TCP implementations under attack may be forced to shed load by		TCP implementations under attack may be forced to shed load by
	resetting established connections. Some load-shedding heuristics,		resetting established connections. Some load-shedding heuristics,
	such as resetting connections with long idle times first, can		such as resetting connections with long idle times first, can
	negatively affect service for intermittently connected, trusted peers		negatively affect service for intermittently connected, trusted peers
	that have suggested long user timeouts. On the other hand, resetting		that have suggested long user timeouts. On the other hand, resetting
	connections to untrusted peers that use long user timeouts may be		connections to untrusted peers that use long user timeouts may be
	effective. In general, using the peers' level of trust as a		effective. In general, using the peers' level of trust as a
	parameter during the load-shedding decision process may be useful.		parameter during the load-shedding decision process may be useful.
			Note that if TCP needs to close or abort connections with a long TCP
			User Timeout Option to shed load, these connections are still no
			worse off than without the option.
	Finally, upper and lower limits on user timeouts, discussed in		Finally, upper and lower limits on user timeouts, discussed in
	Section 3.4, can be an effective tool to limit the impact of these		Section 3.3, can be an effective tool to limit the impact of these
	sorts of attacks.		sorts of attacks.
	6. IANA Considerations		6. IANA Considerations
	This section is to be interpreted according to [4].		This section is to be interpreted according to [RFC2434].
	This document does not define any new namespaces. It uses an 8-bit		This document does not define any new namespaces. It uses an 8-bit
	TCP option number maintained by IANA at		TCP option number maintained by IANA 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 Allmann, David Borman, Marcus Brunner, Wesley Eddy,		suggestions: Mark Allmann, David Borman, Marcus Brunner, Wesley Eddy,
	Ted Faber, Guillermo Gont, Tom Henderson, Joseph Ishac, Phil Karn,		Ted Faber, Guillermo Gont, Tom Henderson, Joseph Ishac, Jeremy
	Michael Kerrisk, Kostas Pentikousis, Juergen Quittek, Joe Touch,		Harris, Phil Karn, Michael Kerrisk, Dan Krejsa, Kostas Pentikousis,
	Stefan Schmid, Simon Schuetz and Martin Stiemerling.		Juergen Quittek, Joe Touch, Stefan Schmid, Simon Schuetz and Martin
			Stiemerling.
	Lars Eggert is partly funded by Ambient Networks, a research project		Lars Eggert is partly funded by Ambient Networks, a research project
	supported by the European Commission under its Sixth Framework		supported by the European Commission under its Sixth Framework
	Program. The views and conclusions contained herein are those of the		Program. The views and conclusions contained herein are those of the
	authors and should not be interpreted as necessarily representing the		authors and should not be interpreted as necessarily representing the
	official policies or endorsements, either expressed or implied, of		official policies or endorsements, either expressed or implied, of
	the Ambient Networks project or the European Commission.		the Ambient Networks project or the European Commission.
	8. References		8. References
	8.1 Normative References		8.1 Normative References
	[1] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,		[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
	September 1981.		RFC 793, September 1981.
	[2] Braden, R., "Requirements for Internet Hosts - Communication		[RFC1122] Braden, R., "Requirements for Internet Hosts -
	Layers", STD 3, RFC 1122, October 1989.		Communication Layers", STD 3, RFC 1122, October 1989.
	[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA		[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.		IANA Considerations Section in RFCs", BCP 26, RFC 2434,
			October 1998.
	8.2 Informative References		8.2 Informative References
	[5] "TCP/IP Illustrated, Volume 1: The Protocols", Addison-Wesley ,		[DRIVE-THRU]
	1994.		Ott, J. and D. Kutscher, "Drive-Thru Internet: IEEE
			802.11b for Automobile Users", Proc. Infocom , March 2004.
	[6] Sun Microsystems, "Solaris Tunable Parameters Reference
	Manual", Part No. 806-7009-10, 2002.
	[7] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
	August 2002.
	[8] Moskowitz, R., "Host Identity Protocol Architecture",
	draft-ietf-hip-arch-02 (work in progress), January 2005.
	[9] Eddy, W., "Mobility Support For TCP",		[I-D.eddy-tcp-mobility]
			Eddy, W., "Mobility Support For TCP",
	draft-eddy-tcp-mobility-00 (work in progress), April 2004.		draft-eddy-tcp-mobility-00 (work in progress), April 2004.
	[10] Schuetz, S., "Network Support for Intermittently Connected		[I-D.ietf-hip-arch]
	Mobile Nodes", M.S. Thesis, University of Mannheim, Germany,		Moskowitz, R., "Host Identity Protocol Architecture",
	June 2004.		draft-ietf-hip-arch-02 (work in progress), January 2005.
	[11] Schuetz, S., Eggert, L., Schmid, S., and M. Brunner, "Protocol		[I-D.ietf-ipsec-rfc2401bis]
	Enhancements for Intermittently Connected Hosts", under		Kent, S. and K. Seo, "Security Architecture for the
	submission (work in progress), November 2004.		Internet Protocol", draft-ietf-ipsec-rfc2401bis-06 (work
			in progress), April 2005.
	[12] Ott, J. and D. Kutscher, "Drive-Thru Internet: IEEE 802.11b for		[MEDINA] Medina, A., Allman, M., and S. Floyd, "Measuring
	Automobile Users", Proc. INFOCOM , March 2004.		Interactions Between Transport Protocols and Middleboxes",
			Proc. 4th ACM SIGCOMM/USENIX Conference on Internet
			Measurement , October 2004.
	[13] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",		[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
	RFC 2246, January 1999.		RFC 2246, January 1999.
	[14] Eddy, W., "Extending the Space Available for TCP Options",		[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
	draft-eddy-tcp-loo-03 (work in progress), May 2005.		August 2002.
	[15] Medina, A., Allman, M., and S. Floyd, "Measuring Interactions
	Between Transport Protocols and Middleboxes", To appear: Proc.
	ACM SIGCOMM/USENIX Internet Measurement Conference ,
	October 2004.
	[16] Kent, S. and K. Seo, "Security Architecture for the Internet		[SCHUETZ-CCR]
	Protocol", draft-ietf-ipsec-rfc2401bis-06 (work in progress),		Schuetz, S., Eggert, L., Schmid, S., and M. Brunner,
	April 2005.		"Protocol Enhancements for Intermittently Connected
			Hosts", To appear: ACM Computer Communication Review, Vol.
			35, No. 3, July 2005.
	Editorial Comments		[SCHUETZ-THESIS]
			Schuetz, S., "Network Support for Intermittently Connected
			Mobile Nodes", Diploma Thesis, University of Mannheim,
			Germany, June 2004.
	[Comment.1] LE: A future version of this document may extend per-		[SOLARIS-MANUAL]
	connection user timeouts to the SYN-SENT and SYN-		Sun Microsystems, "Solaris Tunable Parameters Reference
	RECEIVED states in a way that conforms to the required		Manual", Part No. 806-7009-10, 2002.
	minimum timeouts.
	[Comment.2] LE: My original proposal was to allow hosts to choose		[TCP-ILLU]
	whether or not to include the option. It's open for		Stevens, W., "TCP/IP Illustrated, Volume 1: The
	discussion whether this flexibility is worth the		Protocols", Addison-Wesley , 1994.
	additional complexity. This is the corresponding text:
	"A host that supports the TCP User Timeout Option MAY
	omit the TCP User Timeout Option from the initial SYN if
	it will not permit custom user timeouts for the specific
	connection. It SHOULD omit the TCP User Timeout Option
	from the initial SYN if there is evidence that the peer
	does not support the TCP User Timeout Option, for
	example, if a prior connection attempt including a TCP
	User Timeout Option has failed. If a host does not
	include a TCP User Timeout Option in its initial SYN, it
	MUST NOT include it in any other segment either and MUST
	ignore the contents of any received TCP User Timeout
	Option."
	[Comment.3] FG: My original proposal suggested that TCP might adapt		Editorial Comments
	the user timeout when signalled of congestion by means
	of ECN.
	[Comment.4] LE: This formula takes the maximum of the two announced		[anchor4] LE: A future version of this document may extend per-
	values. I'd use USER_TIMEOUT = max(L_LIMIT,		connection user timeouts to the SYN-SENT and SYN-RECEIVED
	min(LOCAL_UTO, REMOTE_UTO, U_LIMIT)), instead. This		states in a way that conforms to the required minimum
	version takes the minimum. My rationale is that the		timeouts.
	party announcing the lower value probably had a reason
	for it and may hence not be prepared to handle a longer
	value that it originally indicated.
	[Comment.5] FG: IMO, in practice the TCP User Timeout option does		[anchor5] LE: Should it really always send UTO when it changes the
	not make the situation worse: the same type of attack		local timeout? I can imagine some ping-pong effect when
	can be performed even if the default "USER TIMEOUT" is		two hosts user different UTO adoption strategies. But
	used, since TCP requires no message exchange in order to		maybe that's OK?
	keep a connection open.
	Authors' Addresses		Authors' Addresses
	Lars Eggert		Lars Eggert
	NEC Network Laboratories		NEC Network Laboratories
	Kurfuerstenanlage 36		Kurfuerstenanlage 36
	Heidelberg 69115		Heidelberg 69115
	Germany		Germany
	Phone: +49 6221 90511 43		Phone: +49 6221 90511 43
	skipping to change at page 13, line 16		skipping to change at page 13, line 16
	Evaristo Carriego 2644		Evaristo Carriego 2644
	Haedo, Provincia de Buenos Aires 1706		Haedo, Provincia de Buenos Aires 1706
	Argentina		Argentina
	Phone: +54 11 4650 8472		Phone: +54 11 4650 8472
	Email: fernando@gont.com.ar		Email: fernando@gont.com.ar
	URI: http://www.gont.com.ar/		URI: http://www.gont.com.ar/
	Appendix A. Document Revision History		Appendix A. Document Revision History
			To be removed upon publication
	+-----------+-------------------------------------------------------+		+-----------+-------------------------------------------------------+
	| Revision | Comments |		| Revision | Comments |
	+-----------+-------------------------------------------------------+		+-----------+-------------------------------------------------------+
	| 00 | Resubmission of |		| 00 | Resubmission of |
	| | draft-eggert-gont-tcpm-tcp-uto-option-01.txt to the |		| | draft-eggert-gont-tcpm-tcp-uto-option-01.txt to the |
	| | secretariat after WG adoption. Thus, permit |		| | secretariat after WG adoption. Thus, permit |
	| | derivative works. Updated Lars Eggert's funding |		| | derivative works. Updated Lars Eggert's funding |
	| | attribution. Updated several references. No technical |		| | attribution. Updated several references. No technical |
	| | changes. |		| | changes. |
			| 01 | Clarified and corrected the description of the |
			| | existing user timeout in RFC793 and RFC1122. Removed |
			| | distinction between operating during the 3WHS and the |
			| | established states and introduced zero-second "don't |
			| | care" UTOs in response to mailing list feedback. |
			| | Updated references and addressed many other comments |
			| | from the mailing list. |
	+-----------+-------------------------------------------------------+		+-----------+-------------------------------------------------------+
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
End of changes.
This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/