From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6633.txt | 451 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 451 insertions(+) create mode 100644 doc/rfc/rfc6633.txt (limited to 'doc/rfc/rfc6633.txt') diff --git a/doc/rfc/rfc6633.txt b/doc/rfc/rfc6633.txt new file mode 100644 index 0000000..80951fc --- /dev/null +++ b/doc/rfc/rfc6633.txt @@ -0,0 +1,451 @@ + + + + + + +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. + + + + + + + + +Gont Standards Track [Page 1] + +RFC 6633 Deprecation of ICMP Source Quench May 2012 + + +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). + + + + +Gont Standards Track [Page 2] + +RFC 6633 Deprecation of ICMP Source Quench May 2012 + + + 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. + + + +Gont Standards Track [Page 3] + +RFC 6633 Deprecation of ICMP Source Quench May 2012 + + + 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. + + + + + + + + +Gont Standards Track [Page 4] + +RFC 6633 Deprecation of ICMP Source Quench May 2012 + + +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 + + + +Gont Standards Track [Page 5] + +RFC 6633 Deprecation of ICMP Source Quench May 2012 + + + 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. + + + + + + + + +Gont Standards Track [Page 6] + +RFC 6633 Deprecation of ICMP Source Quench May 2012 + + +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, + . + + [Floyd1994] Floyd, S., "TCP and Explicit Congestion + Notification", ACM CCR New York, NY, Volume 24, + Issue 5, October 1994. + + [FreeBSD] The FreeBSD Project, . + + [ICMPPARREG] IANA, "Internet Control Message Protocol (ICMP) + Parameters", + . + + [Linux] The Linux Project, . + + [NetBSD] The NetBSD Project, . + + [OpenBSD] The OpenBSD Project, . + + [OpenSolaris] OpenSolaris, . + + [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. + + + + + +Gont Standards Track [Page 7] + +RFC 6633 Deprecation of ICMP Source Quench May 2012 + + +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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gont Standards Track [Page 8] + -- cgit v1.2.3