draft-ietf-tcpm-tcp-uto-10.txt		draft-ietf-tcpm-tcp-uto-11.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: June 4, 2009 December 1, 2008		Expires: July 26, 2009 January 22, 2009
	TCP User Timeout Option		TCP User Timeout Option
	draft-ietf-tcpm-tcp-uto-10		draft-ietf-tcpm-tcp-uto-11
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		This Internet-Draft is submitted to IETF in full conformance with the
	applicable patent or other IPR claims of which he or she is aware		provisions of BCP 78 and BCP 79.
	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.
	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
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	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."
	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 June 4, 2009.		This Internet-Draft will expire on July 26, 2009.
			Copyright Notice
			Copyright (c) 2009 IETF Trust and the persons identified as the
			document authors. All rights reserved.
			This document is subject to BCP 78 and the IETF Trust's Legal
			Provisions Relating to IETF Documents
			(http://trustee.ietf.org/license-info) in effect on the date of
			publication of this document. Please review these documents
			carefully, as they describe your rights and restrictions with respect
			to this document.
	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 18		skipping to change at page 2, line 28
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Changing the Local User Timeout . . . . . . . . . . . . . 6		3.1. Changing the Local User Timeout . . . . . . . . . . . . . 6
	3.2. UTO Option Reliability . . . . . . . . . . . . . . . . . . 8		3.2. UTO Option Reliability . . . . . . . . . . . . . . . . . . 8
	3.3. Option Format . . . . . . . . . . . . . . . . . . . . . . 9		3.3. Option Format . . . . . . . . . . . . . . . . . . . . . . 9
	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. Programming and Manageability Considerations . . . . . . . . . 11
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 12		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	8.2. Informative References . . . . . . . . . . . . . . . . . . 13		9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
			9.2. Informative References . . . . . . . . . . . . . . . . . . 13
	Appendix A. Document Revision History . . . . . . . . . . . . . . 14		Appendix A. Document Revision History . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
	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, a sender will receive no		longer than the user timeout, a sender will receive no
	skipping to change at page 4, line 31		skipping to change at page 4, line 31
	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-
	connection basis, e.g., through a socket option, or controlled by a		connection basis, e.g., through an API option, or controlled by a
	system-wide setting. TCP maintains four per-connection state		system-wide setting. TCP maintains four per-connection state
	variables to control the operation of the UTO option, three of which		variables to control the operation of the UTO option, three of which
	(ADV_UTO, ENABLED and CHANGEABLE) are new:		(ADV_UTO, ENABLED and CHANGEABLE) are new:
	USER_TIMEOUT		USER_TIMEOUT
	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
	skipping to change at page 5, line 29		skipping to change at page 5, line 29
	UTO option enables its use by setting ENABLED to true. It may choose		UTO option enables its use by setting ENABLED to true. It may choose
	an appropriate local UTO by explicitly setting ADV_UTO; otherwise,		an appropriate local UTO by explicitly setting ADV_UTO; otherwise,
	UTO is set to the default USER TIMEOUT value. Finally, the		UTO is set to the default USER TIMEOUT value. Finally, the
	application should determine whether it will allow the local USER		application should determine whether it will allow the local USER
	TIMEOUT to change based on received UTO options from the other end of		TIMEOUT to change based on received UTO options from the other end of
	a connection. The default is to allow this for connections that do		a connection. The default is to allow this for connections that do
	not have specific user timeout concerns. If an application		not have specific user timeout concerns. If an application
	explicitly sets the USER_TIMEOUT, CHANGEABLE MUST become false, to		explicitly sets the USER_TIMEOUT, CHANGEABLE MUST become false, to
	prevent UTO options from the other end to override local application		prevent UTO options from the other end to override local application
	requests. Alternatively, applications can set or clear CHANGEABLE		requests. Alternatively, applications can set or clear CHANGEABLE
	directly through socket API calls.		directly through API calls.
	Performing these steps before an active or passive open causes UTO		Performing these steps before an active or passive open causes UTO
	options to be exchanged in the SYN and SYN-ACK packets and is a		options to be exchanged in the SYN and SYN-ACK packets and is a
	reliable way to initially exchange, and potentially adapt to, UTO		reliable way to initially exchange, and potentially adapt to, UTO
	values. TCP implementations MAY provide system-wide default settings		values. TCP implementations MAY provide system-wide default settings
	for the ENABLED, ADV_UTO and CHANGEABLE connection parameters.		for the ENABLED, ADV_UTO and CHANGEABLE connection parameters.
	In addition to exchanging UTO options in the SYN segments, a		In addition to exchanging UTO options in the SYN segments, a
	connection that has enabled UTO options SHOULD include a UTO option		connection that has enabled UTO options SHOULD include a UTO option
	in the first packet that does not have the SYN flag set. This helps		in the first packet that does not have the SYN flag set. This helps
	skipping to change at page 6, line 50		skipping to change at page 6, line 50
	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 closes. Many TCP implementations default		packet loss, the connection closes. Many TCP implementations default
	to USER TIMEOUT values of a few minutes. Although the UTO option		to USER TIMEOUT values of a few minutes. Although the UTO option
	allows suggestion of short timeouts, applications advertising them		allows suggestion of short timeouts, applications advertising them
	should consider these effects.		should consider these effects.
	Long USER TIMEOUT values allow hosts to tolerate extended periods		Long USER TIMEOUT values allow hosts to tolerate extended periods
	without end-to-end connectivity. However, they also require hosts to		without end-to-end connectivity. However, they also require hosts to
	maintain the TCP state information associated with connections for		maintain the TCP state information associated with connections for
	long periods of time. Section 5 discusses the security implications		long periods of time. Section 6 discusses the security implications
	of long timeout values.		of long timeout values.
	To protect against these effects, implementations MUST impose limits		To protect against these effects, implementations MUST impose limits
	on the user timeout values they accept and use. The remainder of		on the user timeout values they accept and use. The remainder of
	this section describes a RECOMMENDED scheme to limit TCP's USER		this section describes a RECOMMENDED scheme to limit TCP's USER
	TIMEOUT based on upper and lower limits.		TIMEOUT based on upper and lower limits.
	Under the RECOMMENDED scheme, and when CHANGEABLE is true, each end		Under the RECOMMENDED scheme, and when CHANGEABLE is true, each end
	SHOULD compute the local USER TIMEOUT for a connection according to		SHOULD compute the local USER TIMEOUT for a connection according to
	this formula:		this formula:
	skipping to change at page 8, line 7		skipping to change at page 8, line 7
	whenever it wants.		whenever it wants.
	It must be noted that the two endpoints of the connection will not		It must be noted that the two endpoints of the connection will not
	necessarily adopt the same user timeout.		necessarily adopt the same user timeout.
	Enforcing a lower limit (L_LIMIT) prevents connections from closing		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 6 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, per-outgoing-		at other granularities, such as on per-host, per-user, per-outgoing-
	interface or even per-connection basis. Furthermore, these limits		interface or even per-connection basis. Furthermore, these limits
	need not be static. For example, they MAY be a function of system		need not be static. For example, they MAY be a function of system
	resource utilization or attack status and could be dynamically		resource utilization or attack status and could be dynamically
	adapted.		adapted.
	The Host Requirements RFC [RFC1122] 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, it recommends a time interval		length of the user timeout. However, it recommends a time interval
	skipping to change at page 9, line 32		skipping to change at page 9, line 32
	(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)
	This MUST be TBD, i.e., the TCP option number [RFC0793] assigned		This MUST be TBD, i.e., the TCP option number [RFC0793] assigned
	by IANA upon publication of this document (see Section 6). [[Note		by IANA upon publication of this document (see Section 7). [[Note
	to the RFC Editor: Throughout this document, replace "TBD" with		to the RFC Editor: Throughout this document, replace "TBD" with
	the TCP option number that IANA has allocated and remove this		the TCP option number that IANA has allocated and remove this
	note.]]		note.]]
	Length (8 bits)		Length (8 bits)
	Length of the TCP option in octets [RFC0793]; 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"
	skipping to change at page 11, line 5		skipping to change at page 11, line 5
	4.2. TCP Keep-Alives		4.2. TCP Keep-Alives
	Some TCP implementations, such as those in BSD systems, use a		Some TCP implementations, such as those in BSD systems, use a
	different abort policy for TCP keep-alives 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 without connectivity.		otherwise have survived the transient period without connectivity.
	Therefore, if a connection that enables keep-alives is also using the		Therefore, if a connection that enables keep-alives is also using the
	TCP User Timeout Option, then the keep-alive timer MUST be set to a		TCP User Timeout Option, then the keep-alive timer MUST be set to a
	value larger than that of the adopted USER TIMEOUT.		value larger than that of the adopted USER TIMEOUT.
	5. Security Considerations		5. Programming and Manageability Considerations
			The IETF specification for TCP [RFC0793] includes a simple, abstract
			application programming interface (API). The API for the UTO
			extension in Section 3 is kept similarly abstract. TCP
			implementations, however, usually provide more complex and feature-
			rich APIs. The "socket" API that originated with BSD Unix and is now
			standardized by POSIX is one such example [POSIX]. It is expected
			that TCP implementations that choose to include the UTO extension
			will extend their API to allow applications to use and configure its
			parameters.
			The MIB objects defined in [RFC4022] and [RFC4898] allow management
			of TCP connections. It is expected that revisions to these documents
			will include definitions of objects for managing the UTO extension
			defined in this document.
			6. 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.		resources for maintaining the state of throw-away connections.
	However, TCP implementations do not become more vulnerable to simple		However, TCP implementations do not become more vulnerable to simple
	SYN flooding by implementing the TCP User Timeout Option, because		SYN flooding by implementing the TCP User Timeout Option, because
	user timeouts exchanged during the handshake only affect the		user timeouts exchanged during the handshake only affect the
	synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT,		synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT,
	CLOSING, LAST-ACK), which simple SYN floods never reach.		CLOSING, LAST-ACK), which simple SYN floods never reach.
	skipping to change at page 11, line 27		skipping to change at page 11, line 44
	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 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. (Implementors that decide to
	accept long user timeouts for an established connection only after		use TCP-MD5 for this purpose are encouraged to monitor the
	in-band authentication has occurred, for example, after a TLS		development of TCP-AO [I-D.ietf-tcpm-tcp-auth-opt], its designated
	handshake across the connection has succeeded [RFC5246]. Although		successor, and update their implementation when it is published as an
	these are arguably the most complete solutions, they depend on		RFC.) A similar approach is for a host to start accepting long user
	external mechanisms to establish a trust relationship.		timeouts for an established connection only after in-band
			authentication has occurred, for example, after a TLS handshake
			across the connection has succeeded [RFC5246]. Although these are
			arguably the most complete solutions, they depend on 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
	high-UTO connections a server supports in the face of an attack turns		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		that attack into a denial-of-service attack against the service of
	skipping to change at page 12, line 18		skipping to change at page 12, line 40
	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		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		User Timeout Option to shed load, these connections are still no
	worse off than without the option.		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.1, can be an effective tool to limit the impact of these		Section 3.1, can be an effective tool to limit the impact of these
	sorts of attacks.		sorts of attacks.
	6. IANA Considerations		7. IANA Considerations
	This section is to be interpreted according to [RFC5226].		This section is to be interpreted according to [RFC5226].
	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		8. 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,
	Scott Brim, Marcus Brunner, Wesley Eddy, Gorry Fairhurst, Abolade		Scott Brim, Marcus Brunner, Wesley Eddy, Gorry Fairhurst, Abolade
	Gbadegesin, Ted Faber, Guillermo Gont, Tom Henderson, Joseph Ishac,		Gbadegesin, Ted Faber, Guillermo Gont, Tom Henderson, Joseph Ishac,
	Jeremy Harris, Alfred Hoenes, Phil Karn, Michael Kerrisk, Dan Krejsa,		Jeremy Harris, Alfred Hoenes, Phil Karn, Michael Kerrisk, Dan Krejsa,
	Jamshid Mahdavi, Kostas Pentikousis, Juergen Quittek, Anantha		Jamshid Mahdavi, Kostas Pentikousis, Juergen Quittek, Anantha
	Ramaiah, Joe Touch, Stefan Schmid, Simon Schuetz, Tim Shepard and		Ramaiah, Joe Touch, Stefan Schmid, Simon Schuetz, Tim Shepard and
	Martin Stiemerling.		Martin Stiemerling.
	Lars Eggert is partly funded by [TRILOGY], a research project		Lars Eggert is partly funded by [TRILOGY], a research project
	supported by the European Commission under its Seventh Framework		supported by the European Commission under its Seventh Framework
	Program.		Program.
	8. References		9. References
	8.1. Normative References		9.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.
	[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.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	May 2008.		May 2008.
	8.2. Informative References		9.2. Informative References
	[I-D.eddy-tcp-mobility]		[I-D.eddy-tcp-mobility]
	Eddy, W., "Mobility Support For TCP",		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.
			[I-D.ietf-tcpm-tcp-auth-opt]
			Touch, J., Mankin, A., and R. Bonica, "The TCP
			Authentication Option", draft-ietf-tcpm-tcp-auth-opt-02
			(work in progress), November 2008.
	[MEDINA] Medina, A., Allman, M., and S. Floyd, "Measuring		[MEDINA] Medina, A., Allman, M., and S. Floyd, "Measuring
	Interactions Between Transport Protocols and Middleboxes",		Interactions Between Transport Protocols and Middleboxes",
	Proc. 4th ACM SIGCOMM/USENIX Conference on Internet		Proc. 4th ACM SIGCOMM/USENIX Conference on Internet
	Measurement , October 2004.		Measurement , October 2004.
			[POSIX] IEEE Std. 1003.1-2001, "Standard for Information
			Technology - Portable Operating System Interface (POSIX)",
			Open Group Technical Standard: Base Specifications Issue
			6, ISO/IEC 9945:2002, December 2001.
	[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5		[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
	Signature Option", RFC 2385, August 1998.		Signature Option", RFC 2385, August 1998.
	[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.
			[RFC4022] Raghunarayan, R., "Management Information Base for the
			Transmission Control Protocol (TCP)", RFC 4022,
			March 2005.
	[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.
	[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.
			[RFC4898] Mathis, M., Heffner, J., and R. Raghunarayan, "TCP
			Extended Statistics MIB", RFC 4898, May 2007.
	[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		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246, August 2008.		(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.
	skipping to change at page 14, line 8		skipping to change at page 15, line 4
	[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/.		[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 |
	+----------+--------------------------------------------------------+		+----------+--------------------------------------------------------+
			| -11 | Addressing IESG review comments. |
			| | |
	| -10 | Addressing the gen-art review comments from Scott |		| -10 | Addressing the gen-art review comments from Scott |
	| | Brim. Updated reference to [RFC5246]. Added funding |		| | Brim. Updated reference to [RFC5246]. Added funding |
	| | source acknowledgment. |		| | 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. |
	| | |		| | |
	skipping to change at page 17, line 4		skipping to change at line 733
	URI: http://research.nokia.com/people/lars_eggert/		URI: http://research.nokia.com/people/lars_eggert/
	Fernando Gont		Fernando Gont
	Universidad Tecnologica Nacional / Facultad Regional Haedo		Universidad Tecnologica Nacional / Facultad Regional Haedo
	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/
	Full Copyright Statement
	Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.
	This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Intellectual Property
	The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in
	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
	made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.
	Copies of IPR disclosures made to the IETF Secretariat and any
	assurances of licenses to be made available, or the result of an
	attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.
End of changes. 25 change blocks.
	33 lines changed or deleted		82 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/