idnits 2.17.1 draft-ietf-tsvwg-source-quench-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC1812, but the abstract doesn't seem to directly say this. It does mention RFC1812 though, so this could be OK. -- The draft header indicates that this document updates RFC1122, but the abstract doesn't seem to directly say this. It does mention RFC1122 though, so this could be OK. -- The draft header indicates that this document updates RFC792, but the abstract doesn't seem to directly say this. It does mention RFC792 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC792, updated by this document, for RFC5378 checks: 1981-09-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 10, 2011) is 4701 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC0793' is defined on line 207, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Downref: Normative reference to an Unknown state RFC: RFC 1016 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Area Working Group (tsvwg) F. Gont 3 Internet-Draft UTN/FRH 4 Updates: 792, 1122, 1812 June 10, 2011 5 (if approved) 6 Intended status: Standards Track 7 Expires: December 12, 2011 9 Deprecation of ICMP Source Quench messages 10 draft-ietf-tsvwg-source-quench-01.txt 12 Abstract 14 This document formally deprecates the use of ICMP Source Quench 15 messages by transport protocols, formally updating RFC 792, RFC 1122, 16 and RFC 1812. Additionally, it requests that the status of RFC 1016 17 be changed to "Historic". 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on December 12, 2011. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. ICMP Source Quench messages . . . . . . . . . . . . . . . . . . 3 55 3. Updating RFC 1122 . . . . . . . . . . . . . . . . . . . . . . . 4 56 4. Updating RFC 1812 . . . . . . . . . . . . . . . . . . . . . . . 4 57 5. General Advice to Transport Protocols . . . . . . . . . . . . . 4 58 6. Changing the status of RFC 1016 to Historic . . . . . . . . . . 4 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 60 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 61 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 62 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 10.1. Normative References . . . . . . . . . . . . . . . . . . . 5 64 10.2. Informative References . . . . . . . . . . . . . . . . . . 6 65 Appendix A. Survey of support of ICMP Source Quench in some 66 popular TCP/IP implementations . . . . . . . . . . . . 7 67 Appendix B. Changes from previous versions of the draft (to 68 be removed by the RFC Editor before publishing 69 this document as an RFC) . . . . . . . . . . . . . . . 7 70 B.1. Changes from draft-ietf-tsvwg-source-quench-00 . . . . . . 7 71 B.2. Changes from draft-gont-tsvwg-source-quench-01 . . . . . . 7 72 B.3. Changes from draft-gont-tsvwg-source-quench-00 . . . . . . 7 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 1. Introduction 77 The ICMP specification [RFC0792] defined the ICMP Source Quench 78 message (type 4, code 0), which was meant as a mechanism for 79 congestion control. ICMP Source Quench has been known to be an 80 ineffective (and unfair) antidote for congestion, and generation of 81 ICMP Source Quench messages by routers has been formally deprecated 82 by [RFC1812] since 1995. However, reaction to ICMP Source Quench 83 messages in transport protocols has never been formally deprecated. 85 This document formally deprecates reaction to ICMP Source Quench 86 messages by transport protocols such as TCP, formally updating 87 [RFC0792], [RFC1122], and [RFC1812]. Additionally, it requests that 88 the status of [RFC1016] be changed to "Historic". The rationale for 89 these specification updates is: 91 o Processing of ICMP Source Quench messages by routers has been 92 deprecated for more than 20 years [RFC1812]. 94 o Virtually all popular host implementations have removed support 95 for ICMP Source Quench messages since (at least) 2005 [RFC5927]. 97 o Widespread deployment of ICMP filtering makes it impossible to 98 rely on ICMP Source Quench messages for congestion control. 100 o The IETF has moved away from ICMP Source Quench messages for 101 congestion control (note e.g. the development of ECN [RFC3168], 102 and the fact that ICMPv6 [RFC4443] does not even specify a Source 103 Quench message). 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [RFC2119]. 109 2. ICMP Source Quench messages 111 The ICMP specification [RFC0792] defined the ICMP Source Quench 112 message (type 4, code 0), which was meant to provide a mechanism for 113 congestion control. The Host Requirements RFC [RFC1122] stated in 114 Section 4.2.3.9 that hosts MUST react to ICMP Source Quench messages 115 by slowing transmission on the connection, and further added that the 116 RECOMMENDED procedure was to put the corresponding connection in the 117 slow-start phase of TCP's congestion control algorithm [RFC5681]. 119 [RFC1812] noted that research suggested that ICMP Source Quench was 120 an ineffective (and unfair) antidote for congestion, and formally 121 deprecated the generation of ICMP Source Quench messages by routers, 122 stating that routers SHOULD NOT send ICMP Source Quench messages in 123 response to congestion. 125 [RFC5927] discussed the use of ICMP Source Quench messages for 126 performing "blind throughput-reduction" attacks, and noted that most 127 TCP implementations silently ignore ICMP Source Quench messages. 129 We note that TCP implements its own congestion control mechanisms 130 [RFC5681] [RFC3168], that do not depend on ICMP Source Quench 131 messages. 133 It is interesting to note that ICMPv6 [RFC4443] does not specify a 134 "Source Quench" message. 136 3. Updating RFC 1122 138 This document hereby updates Section 3.2.2.3 of [RFC1122] as follows: 140 A host SHOULD NOT send ICMP Source Quench messages. 142 If a Source Quench message is received, the IP layer MAY silently 143 discard it. 145 Section 4.2.3.9 of [RFC1122] is updated as follows: 147 TCP SHOULD silently discard any received ICMP Source Quench 148 messages. 150 4. Updating RFC 1812 152 This document hereby updates Section 4.3.3.3 of [RFC1812] as follows: 154 A router SHOULD ignore any ICMP Source Quench messages it 155 receives. 157 5. General Advice to Transport Protocols 159 If a Source Quench message is received by a transport-protocol 160 instance (e.g., a TCP connection), it SHOULD be silently ignored. 162 6. Changing the status of RFC 1016 to Historic 164 This document requests the RFC Editor to change the status of 165 [RFC1016] to "Historic". 167 7. Security Considerations 169 ICMP Source Quench messages could be leveraged for performing blind 170 throughput-reduction attacks against TCP and similar protocols. This 171 attack vector, along with possible countermeasures, have been 172 discussed in great detail in [RFC5927] and [CPNI-TCP]. However, as 173 noted in [RFC5927] and [CPNI-TCP], virtually all current versions of 174 popular TCP implementations already silently ignore ICMP Source 175 Quench messages. 177 Silently ignoring ICMP Source Quench messages, as specified in this 178 document, eliminates the aforementioned attack vector. 180 If deemed necessary, ICMP Source Quench messages could be filtered at 181 firewalls. 183 8. IANA Considerations 185 IANA is requested to mark ICMP type 4 (Source Quench) as "Deprecated" 186 in de ICMP Parameters registry [ICMPPARREG] with a reference to this 187 document. 189 9. Acknowledgements 191 The author of this document would like to thank (in alphabetical 192 order) Fred Baker, David Black, Scott Bradner, James Carlson, Antonio 193 De Simone, Gorry Fairhurst, Alfred Hoenes, Mahesh Jethanandani, 194 Carlos Pignataro, Anantha Ramaiah, Dan Wing, and Andrew Yourtchenko, 195 for providing valuable feedback on earlier versions of this document. 197 This document has benefited from discussions within the TCPM Working 198 Group while working on [RFC5927]. 200 10. References 202 10.1. Normative References 204 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 205 RFC 792, September 1981. 207 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 208 RFC 793, September 1981. 210 [RFC1016] Prue, W. and J. Postel, "Something a host could do with 211 source quench: The Source Quench Introduced Delay 212 (SQuID)", RFC 1016, July 1987. 214 [RFC1122] Braden, R., "Requirements for Internet Hosts - 215 Communication Layers", STD 3, RFC 1122, October 1989. 217 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 218 RFC 1812, June 1995. 220 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 221 Requirement Levels", BCP 14, RFC 2119, March 1997. 223 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 224 Control", RFC 5681, September 2009. 226 10.2. Informative References 228 [CPNI-TCP] 229 CPNI, "Security Assessment of the Transmission Control 230 Protocol (TCP)", 2009, . 233 [FreeBSD] The FreeBSD Project, "http://www.freebsd.org". 235 [ICMPPARREG] 236 Internet Control Message Protocol (ICMP) Parameters, 237 "http://www.iana.org/assignments/icmp-parameters". 239 [Linux] The Linux Project, "http://www.kernel.org". 241 [NetBSD] The NetBSD Project, "http://www.netbsd.org". 243 [OpenBSD] The OpenBSD Project, "http://www.openbsd.org". 245 [OpenSolaris] 246 OpenSolaris, "http://www.opensolaris.org". 248 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 249 of Explicit Congestion Notification (ECN) to IP", 250 RFC 3168, September 2001. 252 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 253 Message Protocol (ICMPv6) for the Internet Protocol 254 Version 6 (IPv6) Specification", RFC 4443, March 2006. 256 [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010. 258 Appendix A. Survey of support of ICMP Source Quench in some popular 259 TCP/IP implementations 261 A large number of implementations completely ignore ICMP Source 262 Quench messages meant for TCP connections. This behavior has been 263 implemented in, at least, Linux [Linux] since 2004, and in FreeBSD 264 [FreeBSD], NetBSD [NetBSD], OpenBSD [OpenBSD], and Solaris 10 since 265 2005. Additionally, OpenSolaris [OpenSolaris] has always shipped 266 with support for ICMP Source Quench messages disabled. 268 Appendix B. Changes from previous versions of the draft (to be removed 269 by the RFC Editor before publishing this document as an 270 RFC) 272 B.1. Changes from draft-ietf-tsvwg-source-quench-00 274 o Discusses the motivation for deprecating ICMP Source Quench 275 messages (as suggested by Anantha Ramaiah). 277 o Incorporates IANA considerations such that ICMP Source Quench 278 messages are deprecated in the corresponding registry. 280 B.2. Changes from draft-gont-tsvwg-source-quench-01 282 o Addresses nits and editorial chagnes suggested by Gorry Fairhurst. 284 o Added the status of Solaris and OpenSolaris to Appendix A. 286 o Document resubmitted as draft-ietf. 288 B.3. Changes from draft-gont-tsvwg-source-quench-00 290 o This revision reflects the recent discussion about ICMP Source 291 Quench messages on the tsvwg mailing-list. A detailed list of the 292 changes is available at: 293 http://www.ietf.org/mail-archive/web/tsvwg/current/msg10407.html 295 Author's Address 297 Fernando Gont 298 Universidad Tecnologica Nacional / Facultad Regional Haedo 299 Evaristo Carriego 2644 300 Haedo, Provincia de Buenos Aires 1706 301 Argentina 303 Phone: +54 11 4650 8472 304 Email: fernando@gont.com.ar 305 URI: http://www.gont.com.ar