ICMP Source Quench Dep.: Deprecation of ICMP Source Quench Messages
Why hosts and routers must now ignore the old ICMP message that asked senders to slow down.
Gont, F., "Deprecation of ICMP Source Quench Messages", RFC 6633, DOI 10.17487/RFC6633, May 2012, <https://www.rfc-editor.org/info/rfc6633>.
@misc{rfc6633,
series = {Request for Comments},
number = 6633,
howpublished = {RFC 6633},
publisher = {RFC Editor},
doi = {10.17487/RFC6633},
url = {https://www.rfc-editor.org/info/rfc6633},
author = {F. Gont},
title = {{Deprecation of ICMP Source Quench Messages}},
pagetotal = 8,
year = 2012,
month = may,
} RFC text
Contents
Internet Engineering Task Force (IETF) F. Gont
Request for Comments: 6633 UTN-FRH / SI6 Networks
Updates: 792, 1122, 1812 May 2012
Category: Standards Track
ISSN: 2070-1721
Deprecation of ICMP Source Quench Messages
Abstract
This document formally deprecates the use of ICMP Source Quench
messages by transport protocols, formally updating RFC 792, RFC 1122,
and RFC 1812.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6633.
Copyright Notice
Copyright (c) 2012 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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction ....................................................2
2. ICMP Source Quench Messages .....................................3
3. Updating RFC 1122 ...............................................3
4. Updating RFC 1812 ...............................................4
5. Clarification for UDP, SCTP, and DCCP ...........................4
6. General Advice to Transport Protocols ...........................4
7. Recommendation Regarding RFC 1016 ...............................5
8. Security Considerations .........................................5
9. IANA Considerations .............................................5
10. Acknowledgements ...............................................5
11. References .....................................................6
11.1. Normative References ......................................6
11.2. Informative References ....................................7
Appendix A. Survey of Support of ICMP Source Quench in Some
Popular TCP/IP Implementations ........................8
1. Introduction
The ICMP specification [RFC0792] defined the ICMP Source Quench
message (type 4, code 0), which was meant as a mechanism for
congestion control. ICMP Source Quench has been known to be an
ineffective (and unfair) antidote for congestion, and generation of
ICMP Source Quench messages by routers has been formally deprecated
by [RFC1812] since 1995. However, reaction to ICMP Source Quench
messages in transport protocols has never been formally deprecated.
This document formally deprecates reaction to ICMP Source Quench
messages by transport protocols such as TCP [RFC0793], formally
updating [RFC0792], [RFC1122], and [RFC1812]. Additionally, it
provides a recommendation against the implementation of [RFC1016].
The rationale for these specification updates is as follows:
o Processing of ICMP Source Quench messages by routers has been
deprecated for nearly 17 years [RFC1812].
o Virtually all popular host implementations have removed support
for ICMP Source Quench messages since (at least) 2005 [RFC5927].
o Widespread deployment of ICMP filtering makes it impossible to
rely on ICMP Source Quench messages for congestion control.
o The IETF has moved away from ICMP Source Quench messages for
congestion control (e.g., note the development of Explicit
Congestion Notification (ECN) [RFC3168] and the fact that ICMPv6
[RFC4443] does not even specify a Source 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",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. ICMP Source Quench Messages
The ICMP specification [RFC0792] defined the ICMP Source Quench
message (type 4, code 0), which was meant to provide a mechanism for
congestion control. The Host Requirements RFC [RFC1122] stated in
Section 4.2.3.9 that hosts MUST react to ICMP Source Quench messages
by slowing transmission on the connection, and further added that the
RECOMMENDED procedure was to put the corresponding connection in the
slow-start phase of TCP's congestion control algorithm [RFC5681].
[RFC1812] noted that research suggested that ICMP Source Quench was
an ineffective (and unfair) antidote for congestion, and formally
deprecated the generation of ICMP Source Quench messages by routers,
stating that routers SHOULD NOT send ICMP Source Quench messages in
response to congestion.
[RFC5927] discussed the use of ICMP Source Quench messages for
performing "blind throughput-reduction" attacks, and noted that most
TCP implementations silently ignore ICMP Source Quench messages.
We note that TCP implements its own congestion control mechanisms
[RFC5681] [RFC3168], which do not depend on ICMP Source Quench
messages.
It is interesting to note that ICMPv6 [RFC4443] does not specify a
Source Quench message.
3. Updating RFC 1122
This document hereby updates Section 3.2.2.3 of [RFC1122] as follows:
A host MUST NOT send ICMP Source Quench messages.
If a Source Quench message is received, the IP layer MAY silently
discard it.
Section 4.2.3.9 of [RFC1122] is updated as follows:
TCP MUST silently discard any received ICMP Source Quench
messages.
The consensus of the TSV WG was that there are no valid reasons for a
host to generate or react to an ICMP Source Quench message in the
current Internet. The recommendation that a sender "MUST NOT" send
an ICMP Source Quench message is because there is no known valid
reason for a host to generate this message. The only known impact of
a sender ignoring this requirement is that it may necessarily consume
network and endpoint resources. Discarding ICMP Source Quench
messages at the Internet layer (rather than at the transport layer)
is a performance optimization that is permitted by this update.
4. Updating RFC 1812
This document hereby updates Section 4.3.3.3 of [RFC1812] as follows:
A router MUST ignore any ICMP Source Quench messages it receives.
The consensus of the TSV WG was that there are no valid reasons for a
router to react to ICMP Source Quench messages in the current
Internet.
5. Clarification for UDP, SCTP, and DCCP
UDP [RFC0768] did not explicitly specify support for ICMP Source
Quench messages. Hereby, we clarify that UDP endpoints MUST silently
discard received ICMP Source Quench messages.
It is understood that SCTP [RFC4960] and DCCP [RFC4340] did not
specify support for processing received ICMP Source Quench messages.
Hereby, we clarify that DCCP and SCTP endpoints MUST silently discard
received ICMP Source Quench messages.
6. General Advice to Transport Protocols
If a Source Quench message is received by any other transport-
protocol instance, it MUST be silently ignored.
The TSV WG is not aware of any mechanism that requires processing of
these messages and therefore expects other transports to follow the
recommendations in Section 3. Note that since generation of ICMP
Source Quench messages has been deprecated for many years, and since
this document additionally deprecates reaction to ICMP Source Quench
messages by IETF-specified transports, future applications cannot
expect to receive these messages.
7. Recommendation Regarding RFC 1016
[RFC1016] describes an experimental approach to the handling of ICMP
Source Quench messages in hosts that was considered in 1987. Even
though RFC 1016 has never been on the IETF Standards Track, for
clarity and avoidance of doubt we note that the approach described in
[RFC1016] MUST NOT be implemented.
8. Security Considerations
ICMP Source Quench messages could be leveraged for performing blind
throughput-reduction attacks against TCP and similar protocols. This
attack vector, along with possible countermeasures, has been
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.
For current TCP implementations, receipt of an ICMP Source Quench
message should not result in security issues because, as noted in
[RFC5927] and [CPNI-TCP], virtually all current versions of popular
TCP implementations already silently ignore ICMP Source Quench
messages. This is also the case for SCTP and DCCP implementations.
Hosts, security gateways, and firewalls MUST silently discard
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).
We note that security devices such as the Snort Network Intrusion
Detection System (NIDS) have logged ICMP Source Quench messages as
such for more than ten years [Anderson2002].
9. IANA Considerations
IANA has marked ICMP type 4 (Source Quench) as "Deprecated" in the
ICMP Parameters registry [ICMPPARREG] with a reference to this
document.
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
order) Fred Baker, David Black, Scott Bradner, James Carlson, Antonio
De Simone, Wesley Eddy, Gorry Fairhurst, Alfred Hoenes, Mahesh
Jethanandani, Kathleen Moriarty, Carlos Pignataro, James Polk,
Anantha Ramaiah, Randall Stewart, Dan Wing, and Andrew Yourtchenko,
for providing valuable feedback on earlier versions of this document.
This document has also benefited from discussions within the TCPM
Working Group while working on [RFC5927].
Fernando Gont wishes to thank Jorge Oscar Gont, Nelida Garcia, and
Guillermo Gont for their love and support.
Fernando Gont's attendance to IETF meetings was supported by ISOC's
"Fellowship to the IETF" program.
11. References
11.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC0792] Postel, J., "Internet Control Message Protocol",
STD 5, RFC 792, September 1981.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
RFC 1812, June 1995.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340,
March 2006.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP
Congestion Control", RFC 5681, September 2009.
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, "Security Assessment of the Transmission
Control Protocol (TCP)", 2009,
<http://www.gont.com.ar/papers/
tn-03-09-security-assessment-TCP.pdf>.
[Floyd1994] Floyd, S., "TCP and Explicit Congestion
Notification", ACM CCR New York, NY, Volume 24,
Issue 5, October 1994.
[FreeBSD] The FreeBSD Project, <http://www.freebsd.org>.
[ICMPPARREG] IANA, "Internet Control Message Protocol (ICMP)
Parameters",
<http://www.iana.org/assignments/icmp-parameters>.
[Linux] The Linux Project, <http://www.kernel.org>.
[NetBSD] The NetBSD Project, <http://www.netbsd.org>.
[OpenBSD] The OpenBSD Project, <http://www.openbsd.org>.
[OpenSolaris] OpenSolaris, <http://www.opensolaris.org>.
[RFC1016] Prue, W. and J. Postel, "Something a host could do
with source quench: The Source Quench Introduced
Delay (SQuID)", RFC 1016, July 1987.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The
Addition of Explicit Congestion Notification (ECN) to
IP", RFC 3168, September 2001.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", RFC 4443,
March 2006.
[RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927,
July 2010.
Appendix A. Survey of Support of ICMP Source Quench in Some Popular
TCP/IP Implementations
A large number of implementations completely ignore ICMP Source
Quench messages meant for TCP connections. This behavior has been
implemented in, at least, Linux [Linux] since 2004, and in FreeBSD
[FreeBSD], NetBSD [NetBSD], OpenBSD [OpenBSD], and Solaris 10 since
2005. Additionally, OpenSolaris [OpenSolaris] has always shipped
with support for ICMP Source Quench messages disabled.
Author's Address
Fernando Gont
UTN-FRH / SI6 Networks
Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706
Argentina
Phone: +54 11 4650 8472
EMail: fgont@si6networks.com
URI: http://www.si6networks.com
AI ELI5
On this page
§1Why Source Quench Is Retired
The ICMP specification, RFC 792, defined the ICMP Source Quench message (type 4, code 0) as a congestion control mechanism. It has been known to be an ineffective and unfair antidote for congestion. RFC 1812 already deprecated the generation of these messages by routers in 1995, but reaction to them in transport protocols was never formally deprecated.
This RFC closes that gap. It gives four reasons: routers have not processed them for nearly 17 years, virtually all popular host implementations have removed support since at least 2005, widespread ICMP filtering makes them unreliable, and the IETF has moved to other tools such as Explicit Congestion Notification (RFC 3168). ICMPv6 (RFC 4443) does not even define a Source Quench message.
Imagine a teacher who used to shout slow down at one noisy student, but it never worked and half the time the shout never arrived. So the school stopped using it and found better ways.
§2What the Older RFCs Said
RFC 1122 said in Section 4.2.3.9 that hosts MUST react to Source Quench by slowing transmission on the connection. The recommended procedure was to put the connection into the slow-start phase of TCP congestion control (RFC 5681).
RFC 1812 said routers SHOULD NOT send Source Quench in response to congestion. RFC 5927 described how forged Source Quench messages could be used for blind throughput-reduction attacks, and noted that most TCP implementations silently ignore them. TCP has its own congestion control that does not depend on these messages.
Old rules said to slow down whenever you got the note. Later work showed the note could be faked by a stranger to slow you down on purpose, and most computers already ignored it.
§3The New Rules for Hosts and Routers
For hosts, the RFC updates Section 3.2.2.3 of RFC 1122: a host MUST NOT send ICMP Source Quench messages, and the IP layer MAY silently discard one that arrives. Section 4.2.3.9 is updated so that TCP MUST silently discard any received Source Quench.
The text explains that there is no known valid reason for a host to generate the message. The only known impact of a sender ignoring this is wasted network and endpoint resources. Discarding at the Internet layer rather than the transport layer is allowed as a performance optimization.
For routers, Section 4.3.3.3 of RFC 1812 is updated: a router MUST ignore any Source Quench messages it receives.
The rules now say: never send the slow-down note, and if one shows up, drop it in the bin. Routers do the same.
| Party | Requirement |
|---|---|
| Host (sending) | MUST NOT send |
| Host IP layer | MAY silently discard |
| TCP, UDP, SCTP, DCCP | MUST silently discard |
| Router | MUST ignore |
| Firewalls and security gateways | MUST silently discard; SHOULD log |
§4Other Transports and RFC 1016
UDP never explicitly specified support for Source Quench. The RFC clarifies that UDP endpoints MUST silently discard it. SCTP (RFC 4960) and DCCP (RFC 4340) also did not specify processing, and the RFC clarifies that their endpoints MUST silently discard it too.
Any other transport-protocol instance MUST silently ignore a received Source Quench. Because generation has been deprecated for many years and reaction is now deprecated for IETF-specified transports, future applications cannot expect to receive these messages.
The RFC also addresses RFC 1016, an experimental host approach to Source Quench from 1987 that was never on the Standards Track. For clarity, it says that approach MUST NOT be implemented.
The rule covers every kind of delivery service, not just one. Even an old experiment about what to do with the note is now off the table.
§5Security and Logging
Source Quench messages could be used for blind throughput-reduction attacks against TCP and similar protocols. Silently ignoring them, as this RFC requires, eliminates that attack vector. The RFC notes that virtually all current popular TCP implementations, and SCTP and DCCP implementations, already ignore them.
Hosts, security gateways and firewalls MUST silently discard received Source Quench packets and SHOULD log the drop as a security fault with minimal details: IP source address, IP destination address, ICMP message type, and date and time.
A trickster could send fake slow-down notes to make your connection crawl. If you ignore every such note, the trick stops working.
§6IANA and Implementation Survey
IANA marked ICMP type 4 (Source Quench) as Deprecated in the ICMP Parameters registry, with a reference to this document.
Appendix A surveys existing behavior. Many implementations completely ignore Source Quench for TCP connections: Linux since 2004, and FreeBSD, NetBSD, OpenBSD and Solaris 10 since 2005. OpenSolaris has always shipped with support disabled.
The official list of message types now has a label on this one saying do not use. Most big operating systems had already stopped listening years before.