draft-ietf-tsvwg-source-quench-04.txt		draft-ietf-tsvwg-source-quench-05.txt
	Transport Area Working Group (tsvwg) F. Gont		Transport Area Working Group (tsvwg) F. Gont
	Internet-Draft UTN/FRH		Internet-Draft UTN-FRH / SI6 Networks
	Obsoletes: 1016 (if approved) January 19, 2012		Updates: 792, 1122, 1812 February 22, 2012
	Updates: 792, 1122, 1812
	(if approved)		(if approved)
	Intended status: Standards Track		Intended status: Standards Track
	Expires: July 22, 2012		Expires: August 25, 2012
	Deprecation of ICMP Source Quench messages		Deprecation of ICMP Source Quench messages
	draft-ietf-tsvwg-source-quench-04.txt		draft-ietf-tsvwg-source-quench-05.txt
	Abstract		Abstract
	This document formally deprecates the use of ICMP Source Quench		This document formally deprecates the use of ICMP Source Quench
	messages by transport protocols, formally updating RFC 792, RFC 1122,		messages by transport protocols, formally updating RFC 792, RFC 1122,
	and RFC 1812. Additionally, it requests that the status of RFC 1016		and RFC 1812.
	be changed to "Historic".
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on July 22, 2012.		This Internet-Draft will expire on August 25, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 15		skipping to change at page 2, line 13
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. ICMP Source Quench messages . . . . . . . . . . . . . . . . . . 3		2. ICMP Source Quench messages . . . . . . . . . . . . . . . . . . 3
	3. Updating RFC 1122 . . . . . . . . . . . . . . . . . . . . . . . 4		3. Updating RFC 1122 . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Updating RFC 1812 . . . . . . . . . . . . . . . . . . . . . . . 4		4. Updating RFC 1812 . . . . . . . . . . . . . . . . . . . . . . . 4
	5. Clarification for UDP, SCTP, and DCCP . . . . . . . . . . . . . 5		5. Clarification for UDP, SCTP, and DCCP . . . . . . . . . . . . . 5
	6. General Advice to Transport Protocols . . . . . . . . . . . . . 5		6. General Advice to Transport Protocols . . . . . . . . . . . . . 5
	7. Changing the status of RFC 1016 to Historic . . . . . . . . . . 5		7. Recommendation Regarding RFC 1016 . . . . . . . . . . . . . . . 5
	8. Security Considerations . . . . . . . . . . . . . . . . . . . . 5		8. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 6		11.1. Normative References . . . . . . . . . . . . . . . . . . . 7
	11.2. Informative References . . . . . . . . . . . . . . . . . . 7		11.2. Informative References . . . . . . . . . . . . . . . . . . 7
	Appendix A. Survey of support of ICMP Source Quench in some		Appendix A. Survey of support of ICMP Source Quench in some
	popular TCP/IP implementations . . . . . . . . . . . . 7		popular TCP/IP implementations . . . . . . . . . . . . 8
	Appendix B. Changes from previous versions of the draft (to		Appendix B. Changes from previous versions of the draft (to
	be removed by the RFC Editor before publishing		be removed by the RFC Editor before publishing
	this document as an RFC) . . . . . . . . . . . . . . . 8		this document as an RFC) . . . . . . . . . . . . . . . 8
	B.1. Changes from draft-ietf-tsvwg-source-quench-03 . . . . . . 8		B.1. Changes from draft-ietf-tsvwg-source-quench-04 . . . . . . 8
	B.2. Changes from draft-ietf-tsvwg-source-quench-02 . . . . . . 8		B.2. Changes from draft-ietf-tsvwg-source-quench-03 . . . . . . 8
	B.3. Changes from draft-ietf-tsvwg-source-quench-01 . . . . . . 8		B.3. Changes from draft-ietf-tsvwg-source-quench-02 . . . . . . 9
	B.4. Changes from draft-ietf-tsvwg-source-quench-00 . . . . . . 8		B.4. Changes from draft-ietf-tsvwg-source-quench-01 . . . . . . 9
	B.5. Changes from draft-gont-tsvwg-source-quench-01 . . . . . . 8		B.5. Changes from draft-ietf-tsvwg-source-quench-00 . . . . . . 9
	B.6. Changes from draft-gont-tsvwg-source-quench-00 . . . . . . 8		B.6. Changes from draft-gont-tsvwg-source-quench-01 . . . . . . 9
			B.7. Changes from draft-gont-tsvwg-source-quench-00 . . . . . . 9
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	The ICMP specification [RFC0792] defined the ICMP Source Quench		The ICMP specification [RFC0792] defined the ICMP Source Quench
	message (type 4, code 0), which was meant as a mechanism for		message (type 4, code 0), which was meant as a mechanism for
	congestion control. ICMP Source Quench has been known to be an		congestion control. ICMP Source Quench has been known to be an
	ineffective (and unfair) antidote for congestion, and generation of		ineffective (and unfair) antidote for congestion, and generation of
	ICMP Source Quench messages by routers has been formally deprecated		ICMP Source Quench messages by routers has been formally deprecated
	by [RFC1812] since 1995. However, reaction to ICMP Source Quench		by [RFC1812] since 1995. However, reaction to ICMP Source Quench
	messages in transport protocols has never been formally deprecated.		messages in transport protocols has never been formally deprecated.
	This document formally deprecates reaction to ICMP Source Quench		This document formally deprecates reaction to ICMP Source Quench
	messages by transport protocols such as TCP, formally updating		messages by transport protocols such as TCP, formally updating
	[RFC0792], [RFC1122], and [RFC1812]. Additionally, it requests that		[RFC0792], [RFC1122], and [RFC1812]. Additionally, it provides
	the status of [RFC1016] be changed to "Historic". The rationale for		recommendation against the implementation of [RFC1016]. The
	these specification updates is:		rationale for these specification updates is:
	o Processing of ICMP Source Quench messages by routers has been		o Processing of ICMP Source Quench messages by routers has been
	deprecated for more than 20 years [RFC1812].		deprecated for more than 20 years [RFC1812].
	o Virtually all popular host implementations have removed support		o Virtually all popular host implementations have removed support
	for ICMP Source Quench messages since (at least) 2005 [RFC5927].		for ICMP Source Quench messages since (at least) 2005 [RFC5927].
	o Widespread deployment of ICMP filtering makes it impossible to		o Widespread deployment of ICMP filtering makes it impossible to
	rely on ICMP Source Quench messages for congestion control.		rely on ICMP Source Quench messages for congestion control.
	o The IETF has moved away from ICMP Source Quench messages for		o The IETF has moved away from ICMP Source Quench messages for
	congestion control (note e.g. the development of ECN [RFC3168],		congestion control (note e.g. the development of ECN [RFC3168],
	and the fact that ICMPv6 [RFC4443] does not even specify a Source		and the fact that ICMPv6 [RFC4443] does not even specify a Source
	Quench message).		Quench message).
			ICMP Source Quench messages are not normally seen in the
			deployed Internet and were considered rare at least as far back
			as 1994. [Floyd1994]
	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 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	2. ICMP Source Quench messages		2. ICMP Source Quench messages
	The ICMP specification [RFC0792] defined the ICMP Source Quench		The ICMP specification [RFC0792] defined the ICMP Source Quench
	message (type 4, code 0), which was meant to provide a mechanism for		message (type 4, code 0), which was meant to provide a mechanism for
	congestion control. The Host Requirements RFC [RFC1122] stated in		congestion control. The Host Requirements RFC [RFC1122] stated in
	Section 4.2.3.9 that hosts MUST react to ICMP Source Quench messages		Section 4.2.3.9 that hosts MUST react to ICMP Source Quench messages
	skipping to change at page 5, line 35		skipping to change at page 5, line 35
	protocol instance, it MUST be silently ignored.		protocol instance, it MUST be silently ignored.
	The TSV WG is not aware of any use that requires processing of these		The TSV WG is not aware of any use that requires processing of these
	messages, and therefore expects other transports to follow the		messages, and therefore expects other transports to follow the
	recommendations in Section 3. Note that for IETF-specified		recommendations in Section 3. Note that for IETF-specified
	transports, this document formally deprecates reaction to ICMP Source		transports, this document formally deprecates reaction to ICMP Source
	Quench messages, and that generation of ICMP Source Quench messages		Quench messages, and that generation of ICMP Source Quench messages
	has been deprecated for both hosts and routers. Therefore, future		has been deprecated for both hosts and routers. Therefore, future
	applications can not expect to receive these messages.		applications can not expect to receive these messages.
	7. Changing the status of RFC 1016 to Historic		7. Recommendation Regarding RFC 1016
	This document requests the RFC Editor to change the status of		RFC 1016 [RFC1016] described an experimental approach to ICMP Source
	[RFC1016] to "Historic".		Quench message handling in hosts that was being thought about in
			1987. The IETF notes that RFC 1016 has never been on the IETF
			standards-track, but for clarity and avoidance of doubt, the note
			that the approach described in RFC 1016 [RFC1016] MUST NOT be
			implemented.
	8. Security Considerations		8. Security Considerations
	ICMP Source Quench messages could be leveraged for performing blind		ICMP Source Quench messages could be leveraged for performing blind
	throughput-reduction attacks against TCP and similar protocols. This		throughput-reduction attacks against TCP and similar protocols. This
	attack vector, along with possible countermeasures, has been		attack vector, along with possible countermeasures, has been
	discussed in great detail in [RFC5927] and [CPNI-TCP].		discussed in great detail in [RFC5927] and [CPNI-TCP]. Silently
			ignoring ICMP Source Quench messages, as specified in this document,
			eliminates the aforementioned attack vector.
	Even though sources "MUST NOT" send ICMP Source Quench Message, there		For current TCP implementations, receipt of an ICMP Source Quench
	are no known security issues that result from receipt of this message		message should not result in security issues because, as noted in
	because, as noted in [RFC5927] and [CPNI-TCP], virtually all current		[RFC5927] and [CPNI-TCP], virtually all current versions of popular
	versions of popular TCP implementations already silently ignore ICMP		TCP implementations already silently ignore ICMP Source Quench
	Source Quench messages. This is also the case for SCTP and DCCP		messages. This is also the case for SCTP and DCCP implementations.
	implementations. Receivers should not treat reception as an
	exception, error or logged event. Receipt of an ICMP Source Quench
	message must not be interpreted as an attempt to attack the receiver.
	Silently ignoring ICMP Source Quench messages, as specified in this		Hosts, security gateways, and firewalls MUST silently discard
	document, eliminates the aforementioned attack vector.		received ICMP Source Quench packets and SHOULD log such drops as a
			security fault with at least minimal details (IP Source Address, IP
			Destination Address, ICMP message type, and date/time the packet was
			seen).
	If deemed necessary, ICMP Source Quench messages could be filtered at		We note that security devices such as the Snort Network Intrusion
	firewalls.		Detection System (NIDS) has logged ICMP Source Quench messages as
			such for more than ten years. [Anderson2002].
	9. IANA Considerations		9. IANA Considerations
	IANA is requested to mark ICMP type 4 (Source Quench) as "Deprecated"		IANA is requested to mark ICMP type 4 (Source Quench) as "Deprecated"
	in de ICMP Parameters registry [ICMPPARREG] with a reference to this		in de ICMP Parameters registry [ICMPPARREG] with a reference to this
	document.		document.
	10. Acknowledgements		10. Acknowledgements
			The author of this document would like to thank Ran Atkinson, who
			contributed text that was incorporated into this document and also
			provided valuable feedback on earlier versions of this document.
	The author of this document would like to thank (in alphabetical		The author of this document would like to thank (in alphabetical
	order) Fred Baker, David Black, Scott Bradner, James Carlson, Antonio		order) Fred Baker, David Black, Scott Bradner, James Carlson, Antonio
	De Simone, Wesley Eddy, Gorry Fairhurst, Alfred Hoenes, Mahesh		De Simone, Wesley Eddy, Gorry Fairhurst, Alfred Hoenes, Mahesh
	Jethanandani, Carlos Pignataro, Anantha Ramaiah, Randall Stewart, Dan		Jethanandani, Kathleen Moriarty, Carlos Pignataro, James Polk,
	Wing, and Andrew Yourtchenko, for providing valuable feedback on		Anantha Ramaiah, Randall Stewart, Dan Wing, and Andrew Yourtchenko,
	earlier versions of this document.		for providing valuable feedback on earlier versions of this document.
	This document has benefited from discussions within the TCPM Working		This document has benefited from discussions within the TCPM Working
	Group while working on [RFC5927].		Group while working on [RFC5927].
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,		[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
	RFC 792, September 1981.		RFC 792, September 1981.
	[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 7, line 14		skipping to change at page 7, line 26
	RFC 1812, June 1995.		RFC 1812, June 1995.
	[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.
	[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion		[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
	Control", RFC 5681, September 2009.		Control", RFC 5681, September 2009.
	11.2. Informative References		11.2. Informative References
			[Anderson2002]
			Anderson, D., Fong, M., and A. Valdes, "Heterogeneous
			Sensor Correlation: A Case Study of Live Traffic
			Analysis", Proceedings of the 3rd Annual IEEE Information
			Assurance Workshop New York, NY, USA, 2002.
	[CPNI-TCP]		[CPNI-TCP]
	CPNI, "Security Assessment of the Transmission Control		CPNI, "Security Assessment of the Transmission Control
	Protocol (TCP)", 2009, <http://www.cpni.gov.uk/Docs/		Protocol (TCP)", 2009, <http://www.cpni.gov.uk/Docs/
	tn-03-09-security-assessment-TCP.pdf>.		tn-03-09-security-assessment-TCP.pdf>.
			[Floyd1994]
			Floyd, S., "TCP and Explicit Congestion Notification", ACM
			CCR Volume 24, Issue 5, 1994.
	[FreeBSD] The FreeBSD Project, "http://www.freebsd.org".		[FreeBSD] The FreeBSD Project, "http://www.freebsd.org".
	[ICMPPARREG]		[ICMPPARREG]
	Internet Control Message Protocol (ICMP) Parameters,		Internet Control Message Protocol (ICMP) Parameters,
	"http://www.iana.org/assignments/icmp-parameters".		"http://www.iana.org/assignments/icmp-parameters".
	[Linux] The Linux Project, "http://www.kernel.org".		[Linux] The Linux Project, "http://www.kernel.org".
	[NetBSD] The NetBSD Project, "http://www.netbsd.org".		[NetBSD] The NetBSD Project, "http://www.netbsd.org".
	skipping to change at page 8, line 16		skipping to change at page 8, line 36
	Quench messages meant for TCP connections. This behavior has been		Quench messages meant for TCP connections. This behavior has been
	implemented in, at least, Linux [Linux] since 2004, and in FreeBSD		implemented in, at least, Linux [Linux] since 2004, and in FreeBSD
	[FreeBSD], NetBSD [NetBSD], OpenBSD [OpenBSD], and Solaris 10 since		[FreeBSD], NetBSD [NetBSD], OpenBSD [OpenBSD], and Solaris 10 since
	2005. Additionally, OpenSolaris [OpenSolaris] has always shipped		2005. Additionally, OpenSolaris [OpenSolaris] has always shipped
	with support for ICMP Source Quench messages disabled.		with support for ICMP Source Quench messages disabled.
	Appendix B. Changes from previous versions of the draft (to be removed		Appendix B. Changes from previous versions of the draft (to be removed
	by the RFC Editor before publishing this document as an		by the RFC Editor before publishing this document as an
	RFC)		RFC)
	B.1. Changes from draft-ietf-tsvwg-source-quench-03		B.1. Changes from draft-ietf-tsvwg-source-quench-04
			o Removes request to move RFC 1016 to "Historic" status.
			o Updates the Security Considerations section.
			B.2. Changes from draft-ietf-tsvwg-source-quench-03
	o Added 'Obsoletes' metadata, and moved the reference to [RFC1016]		o Added 'Obsoletes' metadata, and moved the reference to [RFC1016]
	from the 'Normative References' to the 'Informative References'.		from the 'Normative References' to the 'Informative References'.
	B.2. Changes from draft-ietf-tsvwg-source-quench-02		B.3. Changes from draft-ietf-tsvwg-source-quench-02
	o Clarifies the requirements language.		o Clarifies the requirements language.
	B.3. Changes from draft-ietf-tsvwg-source-quench-01		B.4. Changes from draft-ietf-tsvwg-source-quench-01
	o Changes deprecation of ICMP SQ from "SHOULD NOT" to "MUST NOT" in		o Changes deprecation of ICMP SQ from "SHOULD NOT" to "MUST NOT" in
	response of feedback from Scott Bradner and the TSV WG.		response of feedback from Scott Bradner and the TSV WG.
	B.4. Changes from draft-ietf-tsvwg-source-quench-00		B.5. Changes from draft-ietf-tsvwg-source-quench-00
	o Discusses the motivation for deprecating ICMP Source Quench		o Discusses the motivation for deprecating ICMP Source Quench
	messages (as suggested by Anantha Ramaiah).		messages (as suggested by Anantha Ramaiah).
	o Incorporates IANA considerations such that ICMP Source Quench		o Incorporates IANA considerations such that ICMP Source Quench
	messages are deprecated in the corresponding registry.		messages are deprecated in the corresponding registry.
	B.5. Changes from draft-gont-tsvwg-source-quench-01		B.6. Changes from draft-gont-tsvwg-source-quench-01
	o Addresses nits and editorial changes suggested by Gorry Fairhurst.		o Addresses nits and editorial changes suggested by Gorry Fairhurst.
	o Added the status of Solaris and OpenSolaris to Appendix A.		o Added the status of Solaris and OpenSolaris to Appendix A.
	o Document resubmitted as draft-ietf.		o Document resubmitted as draft-ietf.
	B.6. Changes from draft-gont-tsvwg-source-quench-00		B.7. Changes from draft-gont-tsvwg-source-quench-00
	o This revision reflects the recent discussion about ICMP Source		o This revision reflects the recent discussion about ICMP Source
	Quench messages on the tsvwg mailing-list. A detailed list of the		Quench messages on the tsvwg mailing-list. A detailed list of the
	changes is available at:		changes is available at:
	http://www.ietf.org/mail-archive/web/tsvwg/current/msg10407.html		http://www.ietf.org/mail-archive/web/tsvwg/current/msg10407.html
	Author's Address		Author's Address
	Fernando Gont		Fernando Gont
	Universidad Tecnologica Nacional / Facultad Regional Haedo		UTN-FRH / SI6 Networks
	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: fgont@si6networks.com
	URI: http://www.gont.com.ar		URI: http://www.si6networks.com
End of changes. 30 change blocks.
	48 lines changed or deleted		77 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/