idnits 2.17.1 draft-ietf-tsvwg-source-quench-04.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 obsoletes RFC1016, but the abstract doesn't seem to directly say this. It does mention RFC1016 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 (January 19, 2012) is 4474 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 251, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) Summary: 1 error (**), 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 Obsoletes: 1016 (if approved) January 19, 2012 5 Updates: 792, 1122, 1812 6 (if approved) 7 Intended status: Standards Track 8 Expires: July 22, 2012 10 Deprecation of ICMP Source Quench messages 11 draft-ietf-tsvwg-source-quench-04.txt 13 Abstract 15 This document formally deprecates the use of ICMP Source Quench 16 messages by transport protocols, formally updating RFC 792, RFC 1122, 17 and RFC 1812. Additionally, it requests that the status of RFC 1016 18 be changed to "Historic". 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on July 22, 2012. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. ICMP Source Quench messages . . . . . . . . . . . . . . . . . . 3 56 3. Updating RFC 1122 . . . . . . . . . . . . . . . . . . . . . . . 4 57 4. Updating RFC 1812 . . . . . . . . . . . . . . . . . . . . . . . 4 58 5. Clarification for UDP, SCTP, and DCCP . . . . . . . . . . . . . 5 59 6. General Advice to Transport Protocols . . . . . . . . . . . . . 5 60 7. Changing the status of RFC 1016 to Historic . . . . . . . . . . 5 61 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 62 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 63 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 64 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 11.1. Normative References . . . . . . . . . . . . . . . . . . . 6 66 11.2. Informative References . . . . . . . . . . . . . . . . . . 7 67 Appendix A. Survey of support of ICMP Source Quench in some 68 popular TCP/IP implementations . . . . . . . . . . . . 7 69 Appendix B. Changes from previous versions of the draft (to 70 be removed by the RFC Editor before publishing 71 this document as an RFC) . . . . . . . . . . . . . . . 8 72 B.1. Changes from draft-ietf-tsvwg-source-quench-03 . . . . . . 8 73 B.2. Changes from draft-ietf-tsvwg-source-quench-02 . . . . . . 8 74 B.3. Changes from draft-ietf-tsvwg-source-quench-01 . . . . . . 8 75 B.4. Changes from draft-ietf-tsvwg-source-quench-00 . . . . . . 8 76 B.5. Changes from draft-gont-tsvwg-source-quench-01 . . . . . . 8 77 B.6. Changes from draft-gont-tsvwg-source-quench-00 . . . . . . 8 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 1. Introduction 82 The ICMP specification [RFC0792] defined the ICMP Source Quench 83 message (type 4, code 0), which was meant as a mechanism for 84 congestion control. ICMP Source Quench has been known to be an 85 ineffective (and unfair) antidote for congestion, and generation of 86 ICMP Source Quench messages by routers has been formally deprecated 87 by [RFC1812] since 1995. However, reaction to ICMP Source Quench 88 messages in transport protocols has never been formally deprecated. 90 This document formally deprecates reaction to ICMP Source Quench 91 messages by transport protocols such as TCP, formally updating 92 [RFC0792], [RFC1122], and [RFC1812]. Additionally, it requests that 93 the status of [RFC1016] be changed to "Historic". The rationale for 94 these specification updates is: 96 o Processing of ICMP Source Quench messages by routers has been 97 deprecated for more than 20 years [RFC1812]. 99 o Virtually all popular host implementations have removed support 100 for ICMP Source Quench messages since (at least) 2005 [RFC5927]. 102 o Widespread deployment of ICMP filtering makes it impossible to 103 rely on ICMP Source Quench messages for congestion control. 105 o The IETF has moved away from ICMP Source Quench messages for 106 congestion control (note e.g. the development of ECN [RFC3168], 107 and the fact that ICMPv6 [RFC4443] does not even specify a Source 108 Quench message). 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [RFC2119]. 114 2. ICMP Source Quench messages 116 The ICMP specification [RFC0792] defined the ICMP Source Quench 117 message (type 4, code 0), which was meant to provide a mechanism for 118 congestion control. The Host Requirements RFC [RFC1122] stated in 119 Section 4.2.3.9 that hosts MUST react to ICMP Source Quench messages 120 by slowing transmission on the connection, and further added that the 121 RECOMMENDED procedure was to put the corresponding connection in the 122 slow-start phase of TCP's congestion control algorithm [RFC5681]. 124 [RFC1812] noted that research suggested that ICMP Source Quench was 125 an ineffective (and unfair) antidote for congestion, and formally 126 deprecated the generation of ICMP Source Quench messages by routers, 127 stating that routers SHOULD NOT send ICMP Source Quench messages in 128 response to congestion. 130 [RFC5927] discussed the use of ICMP Source Quench messages for 131 performing "blind throughput-reduction" attacks, and noted that most 132 TCP implementations silently ignore ICMP Source Quench messages. 134 We note that TCP implements its own congestion control mechanisms 135 [RFC5681] [RFC3168], that do not depend on ICMP Source Quench 136 messages. 138 It is interesting to note that ICMPv6 [RFC4443] does not specify a 139 "Source Quench" message. 141 3. Updating RFC 1122 143 This document hereby updates Section 3.2.2.3 of [RFC1122] as follows: 145 A host MUST NOT send ICMP Source Quench messages. 147 If a Source Quench message is received, the IP layer MAY silently 148 discard it. 150 Section 4.2.3.9 of [RFC1122] is updated as follows: 152 TCP MUST silently discard any received ICMP Source Quench 153 messages. 155 The consensus of the TSV WG was that there are no valid reasons for a 156 host to generate or react to an ICMP Source Quench message in the 157 current Internet. The recommendation that a sender "MUST NOT" send 158 an ICMP Source Quench message is because there is no known valid 159 reason for a host to generate this message. The only known impact of 160 a sender ignoring this requirement is that it may necessarily consume 161 network and endpoint resources. Discarding ICMP Source Quench 162 messages at the internet-layer (rather than at the transport layer) 163 is a performance optimization that is permitted by this update. 165 4. Updating RFC 1812 167 This document hereby updates Section 4.3.3.3 of [RFC1812] as follows: 169 A router MUST ignore any ICMP Source Quench messages it receives. 171 The consensus of the TSV WG was that there are no valid reasons for a 172 router to react to ICMP Source Quench messages in the current 173 Internet. 175 5. Clarification for UDP, SCTP, and DCCP 177 UDP did not explicitly specify support for ICMP Source Quench 178 messages. Hereby we clarify that UDP end-points MUST silently 179 discard received ICMP Source Quench messages. 181 It is understood that SCTP and DCCP did not specify support for 182 processing received ICMP Source Quench messages. Hereby we clarify 183 that DCCP and SCTP end-points MUST silently discard received ICMP 184 Source Quench messages. 186 6. General Advice to Transport Protocols 188 If a Source Quench message is received by any other transport- 189 protocol instance, it MUST be silently ignored. 191 The TSV WG is not aware of any use that requires processing of these 192 messages, and therefore expects other transports to follow the 193 recommendations in Section 3. Note that for IETF-specified 194 transports, this document formally deprecates reaction to ICMP Source 195 Quench messages, and that generation of ICMP Source Quench messages 196 has been deprecated for both hosts and routers. Therefore, future 197 applications can not expect to receive these messages. 199 7. Changing the status of RFC 1016 to Historic 201 This document requests the RFC Editor to change the status of 202 [RFC1016] to "Historic". 204 8. Security Considerations 206 ICMP Source Quench messages could be leveraged for performing blind 207 throughput-reduction attacks against TCP and similar protocols. This 208 attack vector, along with possible countermeasures, has been 209 discussed in great detail in [RFC5927] and [CPNI-TCP]. 211 Even though sources "MUST NOT" send ICMP Source Quench Message, there 212 are no known security issues that result from receipt of this message 213 because, as noted in [RFC5927] and [CPNI-TCP], virtually all current 214 versions of popular TCP implementations already silently ignore ICMP 215 Source Quench messages. This is also the case for SCTP and DCCP 216 implementations. Receivers should not treat reception as an 217 exception, error or logged event. Receipt of an ICMP Source Quench 218 message must not be interpreted as an attempt to attack the receiver. 220 Silently ignoring ICMP Source Quench messages, as specified in this 221 document, eliminates the aforementioned attack vector. 223 If deemed necessary, ICMP Source Quench messages could be filtered at 224 firewalls. 226 9. IANA Considerations 228 IANA is requested to mark ICMP type 4 (Source Quench) as "Deprecated" 229 in de ICMP Parameters registry [ICMPPARREG] with a reference to this 230 document. 232 10. Acknowledgements 234 The author of this document would like to thank (in alphabetical 235 order) Fred Baker, David Black, Scott Bradner, James Carlson, Antonio 236 De Simone, Wesley Eddy, Gorry Fairhurst, Alfred Hoenes, Mahesh 237 Jethanandani, Carlos Pignataro, Anantha Ramaiah, Randall Stewart, Dan 238 Wing, and Andrew Yourtchenko, for providing valuable feedback on 239 earlier versions of this document. 241 This document has benefited from discussions within the TCPM Working 242 Group while working on [RFC5927]. 244 11. References 246 11.1. Normative References 248 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 249 RFC 792, September 1981. 251 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 252 RFC 793, September 1981. 254 [RFC1122] Braden, R., "Requirements for Internet Hosts - 255 Communication Layers", STD 3, RFC 1122, October 1989. 257 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 258 RFC 1812, June 1995. 260 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 261 Requirement Levels", BCP 14, RFC 2119, March 1997. 263 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 264 Control", RFC 5681, September 2009. 266 11.2. Informative References 268 [CPNI-TCP] 269 CPNI, "Security Assessment of the Transmission Control 270 Protocol (TCP)", 2009, . 273 [FreeBSD] The FreeBSD Project, "http://www.freebsd.org". 275 [ICMPPARREG] 276 Internet Control Message Protocol (ICMP) Parameters, 277 "http://www.iana.org/assignments/icmp-parameters". 279 [Linux] The Linux Project, "http://www.kernel.org". 281 [NetBSD] The NetBSD Project, "http://www.netbsd.org". 283 [OpenBSD] The OpenBSD Project, "http://www.openbsd.org". 285 [OpenSolaris] 286 OpenSolaris, "http://www.opensolaris.org". 288 [RFC1016] Prue, W. and J. Postel, "Something a host could do with 289 source quench: The Source Quench Introduced Delay 290 (SQuID)", RFC 1016, July 1987. 292 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 293 of Explicit Congestion Notification (ECN) to IP", 294 RFC 3168, September 2001. 296 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 297 Message Protocol (ICMPv6) for the Internet Protocol 298 Version 6 (IPv6) Specification", RFC 4443, March 2006. 300 [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010. 302 Appendix A. Survey of support of ICMP Source Quench in some popular 303 TCP/IP implementations 305 A large number of implementations completely ignore ICMP Source 306 Quench messages meant for TCP connections. This behavior has been 307 implemented in, at least, Linux [Linux] since 2004, and in FreeBSD 308 [FreeBSD], NetBSD [NetBSD], OpenBSD [OpenBSD], and Solaris 10 since 309 2005. Additionally, OpenSolaris [OpenSolaris] has always shipped 310 with support for ICMP Source Quench messages disabled. 312 Appendix B. Changes from previous versions of the draft (to be removed 313 by the RFC Editor before publishing this document as an 314 RFC) 316 B.1. Changes from draft-ietf-tsvwg-source-quench-03 318 o Added 'Obsoletes' metadata, and moved the reference to [RFC1016] 319 from the 'Normative References' to the 'Informative References'. 321 B.2. Changes from draft-ietf-tsvwg-source-quench-02 323 o Clarifies the requirements language. 325 B.3. Changes from draft-ietf-tsvwg-source-quench-01 327 o Changes deprecation of ICMP SQ from "SHOULD NOT" to "MUST NOT" in 328 response of feedback from Scott Bradner and the TSV WG. 330 B.4. Changes from draft-ietf-tsvwg-source-quench-00 332 o Discusses the motivation for deprecating ICMP Source Quench 333 messages (as suggested by Anantha Ramaiah). 335 o Incorporates IANA considerations such that ICMP Source Quench 336 messages are deprecated in the corresponding registry. 338 B.5. Changes from draft-gont-tsvwg-source-quench-01 340 o Addresses nits and editorial changes suggested by Gorry Fairhurst. 342 o Added the status of Solaris and OpenSolaris to Appendix A. 344 o Document resubmitted as draft-ietf. 346 B.6. Changes from draft-gont-tsvwg-source-quench-00 348 o This revision reflects the recent discussion about ICMP Source 349 Quench messages on the tsvwg mailing-list. A detailed list of the 350 changes is available at: 351 http://www.ietf.org/mail-archive/web/tsvwg/current/msg10407.html 353 Author's Address 355 Fernando Gont 356 Universidad Tecnologica Nacional / Facultad Regional Haedo 357 Evaristo Carriego 2644 358 Haedo, Provincia de Buenos Aires 1706 359 Argentina 361 Phone: +54 11 4650 8472 362 Email: fernando@gont.com.ar 363 URI: http://www.gont.com.ar