idnits 2.17.1 draft-ietf-tsvwg-source-quench-05.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 (February 22, 2012) is 4418 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 264, 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 / SI6 Networks 4 Updates: 792, 1122, 1812 February 22, 2012 5 (if approved) 6 Intended status: Standards Track 7 Expires: August 25, 2012 9 Deprecation of ICMP Source Quench messages 10 draft-ietf-tsvwg-source-quench-05.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. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on August 25, 2012. 35 Copyright Notice 37 Copyright (c) 2012 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. ICMP Source Quench messages . . . . . . . . . . . . . . . . . . 3 54 3. Updating RFC 1122 . . . . . . . . . . . . . . . . . . . . . . . 4 55 4. Updating RFC 1812 . . . . . . . . . . . . . . . . . . . . . . . 4 56 5. Clarification for UDP, SCTP, and DCCP . . . . . . . . . . . . . 5 57 6. General Advice to Transport Protocols . . . . . . . . . . . . . 5 58 7. Recommendation Regarding RFC 1016 . . . . . . . . . . . . . . . 5 59 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 60 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 61 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 62 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 11.1. Normative References . . . . . . . . . . . . . . . . . . . 7 64 11.2. Informative References . . . . . . . . . . . . . . . . . . 7 65 Appendix A. Survey of support of ICMP Source Quench in some 66 popular TCP/IP implementations . . . . . . . . . . . . 8 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) . . . . . . . . . . . . . . . 8 70 B.1. Changes from draft-ietf-tsvwg-source-quench-04 . . . . . . 8 71 B.2. Changes from draft-ietf-tsvwg-source-quench-03 . . . . . . 8 72 B.3. Changes from draft-ietf-tsvwg-source-quench-02 . . . . . . 9 73 B.4. Changes from draft-ietf-tsvwg-source-quench-01 . . . . . . 9 74 B.5. Changes from draft-ietf-tsvwg-source-quench-00 . . . . . . 9 75 B.6. Changes from draft-gont-tsvwg-source-quench-01 . . . . . . 9 76 B.7. Changes from draft-gont-tsvwg-source-quench-00 . . . . . . 9 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 1. Introduction 81 The ICMP specification [RFC0792] defined the ICMP Source Quench 82 message (type 4, code 0), which was meant as a mechanism for 83 congestion control. ICMP Source Quench has been known to be an 84 ineffective (and unfair) antidote for congestion, and generation of 85 ICMP Source Quench messages by routers has been formally deprecated 86 by [RFC1812] since 1995. However, reaction to ICMP Source Quench 87 messages in transport protocols has never been formally deprecated. 89 This document formally deprecates reaction to ICMP Source Quench 90 messages by transport protocols such as TCP, formally updating 91 [RFC0792], [RFC1122], and [RFC1812]. Additionally, it provides 92 recommendation against the implementation of [RFC1016]. The 93 rationale for these specification updates is: 95 o Processing of ICMP Source Quench messages by routers has been 96 deprecated for more than 20 years [RFC1812]. 98 o Virtually all popular host implementations have removed support 99 for ICMP Source Quench messages since (at least) 2005 [RFC5927]. 101 o Widespread deployment of ICMP filtering makes it impossible to 102 rely on ICMP Source Quench messages for congestion control. 104 o The IETF has moved away from ICMP Source Quench messages for 105 congestion control (note e.g. the development of ECN [RFC3168], 106 and the fact that ICMPv6 [RFC4443] does not even specify a Source 107 Quench message). 109 ICMP Source Quench messages are not normally seen in the 110 deployed Internet and were considered rare at least as far back 111 as 1994. [Floyd1994] 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in RFC 2119 [RFC2119]. 117 2. ICMP Source Quench messages 119 The ICMP specification [RFC0792] defined the ICMP Source Quench 120 message (type 4, code 0), which was meant to provide a mechanism for 121 congestion control. The Host Requirements RFC [RFC1122] stated in 122 Section 4.2.3.9 that hosts MUST react to ICMP Source Quench messages 123 by slowing transmission on the connection, and further added that the 124 RECOMMENDED procedure was to put the corresponding connection in the 125 slow-start phase of TCP's congestion control algorithm [RFC5681]. 127 [RFC1812] noted that research suggested that ICMP Source Quench was 128 an ineffective (and unfair) antidote for congestion, and formally 129 deprecated the generation of ICMP Source Quench messages by routers, 130 stating that routers SHOULD NOT send ICMP Source Quench messages in 131 response to congestion. 133 [RFC5927] discussed the use of ICMP Source Quench messages for 134 performing "blind throughput-reduction" attacks, and noted that most 135 TCP implementations silently ignore ICMP Source Quench messages. 137 We note that TCP implements its own congestion control mechanisms 138 [RFC5681] [RFC3168], that do not depend on ICMP Source Quench 139 messages. 141 It is interesting to note that ICMPv6 [RFC4443] does not specify a 142 "Source Quench" message. 144 3. Updating RFC 1122 146 This document hereby updates Section 3.2.2.3 of [RFC1122] as follows: 148 A host MUST NOT send ICMP Source Quench messages. 150 If a Source Quench message is received, the IP layer MAY silently 151 discard it. 153 Section 4.2.3.9 of [RFC1122] is updated as follows: 155 TCP MUST silently discard any received ICMP Source Quench 156 messages. 158 The consensus of the TSV WG was that there are no valid reasons for a 159 host to generate or react to an ICMP Source Quench message in the 160 current Internet. The recommendation that a sender "MUST NOT" send 161 an ICMP Source Quench message is because there is no known valid 162 reason for a host to generate this message. The only known impact of 163 a sender ignoring this requirement is that it may necessarily consume 164 network and endpoint resources. Discarding ICMP Source Quench 165 messages at the internet-layer (rather than at the transport layer) 166 is a performance optimization that is permitted by this update. 168 4. Updating RFC 1812 170 This document hereby updates Section 4.3.3.3 of [RFC1812] as follows: 172 A router MUST ignore any ICMP Source Quench messages it receives. 174 The consensus of the TSV WG was that there are no valid reasons for a 175 router to react to ICMP Source Quench messages in the current 176 Internet. 178 5. Clarification for UDP, SCTP, and DCCP 180 UDP did not explicitly specify support for ICMP Source Quench 181 messages. Hereby we clarify that UDP end-points MUST silently 182 discard received ICMP Source Quench messages. 184 It is understood that SCTP and DCCP did not specify support for 185 processing received ICMP Source Quench messages. Hereby we clarify 186 that DCCP and SCTP end-points MUST silently discard received ICMP 187 Source Quench messages. 189 6. General Advice to Transport Protocols 191 If a Source Quench message is received by any other transport- 192 protocol instance, it MUST be silently ignored. 194 The TSV WG is not aware of any use that requires processing of these 195 messages, and therefore expects other transports to follow the 196 recommendations in Section 3. Note that for IETF-specified 197 transports, this document formally deprecates reaction to ICMP Source 198 Quench messages, and that generation of ICMP Source Quench messages 199 has been deprecated for both hosts and routers. Therefore, future 200 applications can not expect to receive these messages. 202 7. Recommendation Regarding RFC 1016 204 RFC 1016 [RFC1016] described an experimental approach to ICMP Source 205 Quench message handling in hosts that was being thought about in 206 1987. The IETF notes that RFC 1016 has never been on the IETF 207 standards-track, but for clarity and avoidance of doubt, the note 208 that the approach described in RFC 1016 [RFC1016] MUST NOT be 209 implemented. 211 8. Security Considerations 213 ICMP Source Quench messages could be leveraged for performing blind 214 throughput-reduction attacks against TCP and similar protocols. This 215 attack vector, along with possible countermeasures, has been 216 discussed in great detail in [RFC5927] and [CPNI-TCP]. Silently 217 ignoring ICMP Source Quench messages, as specified in this document, 218 eliminates the aforementioned attack vector. 220 For current TCP implementations, receipt of an ICMP Source Quench 221 message should not result in security issues because, as noted in 222 [RFC5927] and [CPNI-TCP], virtually all current versions of popular 223 TCP implementations already silently ignore ICMP Source Quench 224 messages. This is also the case for SCTP and DCCP implementations. 226 Hosts, security gateways, and firewalls MUST silently discard 227 received ICMP Source Quench packets and SHOULD log such drops as a 228 security fault with at least minimal details (IP Source Address, IP 229 Destination Address, ICMP message type, and date/time the packet was 230 seen). 232 We note that security devices such as the Snort Network Intrusion 233 Detection System (NIDS) has logged ICMP Source Quench messages as 234 such for more than ten years. [Anderson2002]. 236 9. IANA Considerations 238 IANA is requested to mark ICMP type 4 (Source Quench) as "Deprecated" 239 in de ICMP Parameters registry [ICMPPARREG] with a reference to this 240 document. 242 10. Acknowledgements 244 The author of this document would like to thank Ran Atkinson, who 245 contributed text that was incorporated into this document and also 246 provided valuable feedback on earlier versions of this document. 248 The author of this document would like to thank (in alphabetical 249 order) Fred Baker, David Black, Scott Bradner, James Carlson, Antonio 250 De Simone, Wesley Eddy, Gorry Fairhurst, Alfred Hoenes, Mahesh 251 Jethanandani, Kathleen Moriarty, Carlos Pignataro, James Polk, 252 Anantha Ramaiah, Randall Stewart, Dan Wing, and Andrew Yourtchenko, 253 for providing valuable feedback on earlier versions of this document. 255 This document has benefited from discussions within the TCPM Working 256 Group while working on [RFC5927]. 258 11. References 259 11.1. Normative References 261 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 262 RFC 792, September 1981. 264 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 265 RFC 793, September 1981. 267 [RFC1122] Braden, R., "Requirements for Internet Hosts - 268 Communication Layers", STD 3, RFC 1122, October 1989. 270 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 271 RFC 1812, June 1995. 273 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 274 Requirement Levels", BCP 14, RFC 2119, March 1997. 276 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 277 Control", RFC 5681, September 2009. 279 11.2. Informative References 281 [Anderson2002] 282 Anderson, D., Fong, M., and A. Valdes, "Heterogeneous 283 Sensor Correlation: A Case Study of Live Traffic 284 Analysis", Proceedings of the 3rd Annual IEEE Information 285 Assurance Workshop New York, NY, USA, 2002. 287 [CPNI-TCP] 288 CPNI, "Security Assessment of the Transmission Control 289 Protocol (TCP)", 2009, . 292 [Floyd1994] 293 Floyd, S., "TCP and Explicit Congestion Notification", ACM 294 CCR Volume 24, Issue 5, 1994. 296 [FreeBSD] The FreeBSD Project, "http://www.freebsd.org". 298 [ICMPPARREG] 299 Internet Control Message Protocol (ICMP) Parameters, 300 "http://www.iana.org/assignments/icmp-parameters". 302 [Linux] The Linux Project, "http://www.kernel.org". 304 [NetBSD] The NetBSD Project, "http://www.netbsd.org". 306 [OpenBSD] The OpenBSD Project, "http://www.openbsd.org". 308 [OpenSolaris] 309 OpenSolaris, "http://www.opensolaris.org". 311 [RFC1016] Prue, W. and J. Postel, "Something a host could do with 312 source quench: The Source Quench Introduced Delay 313 (SQuID)", RFC 1016, July 1987. 315 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 316 of Explicit Congestion Notification (ECN) to IP", 317 RFC 3168, September 2001. 319 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 320 Message Protocol (ICMPv6) for the Internet Protocol 321 Version 6 (IPv6) Specification", RFC 4443, March 2006. 323 [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010. 325 Appendix A. Survey of support of ICMP Source Quench in some popular 326 TCP/IP implementations 328 A large number of implementations completely ignore ICMP Source 329 Quench messages meant for TCP connections. This behavior has been 330 implemented in, at least, Linux [Linux] since 2004, and in FreeBSD 331 [FreeBSD], NetBSD [NetBSD], OpenBSD [OpenBSD], and Solaris 10 since 332 2005. Additionally, OpenSolaris [OpenSolaris] has always shipped 333 with support for ICMP Source Quench messages disabled. 335 Appendix B. Changes from previous versions of the draft (to be removed 336 by the RFC Editor before publishing this document as an 337 RFC) 339 B.1. Changes from draft-ietf-tsvwg-source-quench-04 341 o Removes request to move RFC 1016 to "Historic" status. 343 o Updates the Security Considerations section. 345 B.2. Changes from draft-ietf-tsvwg-source-quench-03 347 o Added 'Obsoletes' metadata, and moved the reference to [RFC1016] 348 from the 'Normative References' to the 'Informative References'. 350 B.3. Changes from draft-ietf-tsvwg-source-quench-02 352 o Clarifies the requirements language. 354 B.4. Changes from draft-ietf-tsvwg-source-quench-01 356 o Changes deprecation of ICMP SQ from "SHOULD NOT" to "MUST NOT" in 357 response of feedback from Scott Bradner and the TSV WG. 359 B.5. Changes from draft-ietf-tsvwg-source-quench-00 361 o Discusses the motivation for deprecating ICMP Source Quench 362 messages (as suggested by Anantha Ramaiah). 364 o Incorporates IANA considerations such that ICMP Source Quench 365 messages are deprecated in the corresponding registry. 367 B.6. Changes from draft-gont-tsvwg-source-quench-01 369 o Addresses nits and editorial changes suggested by Gorry Fairhurst. 371 o Added the status of Solaris and OpenSolaris to Appendix A. 373 o Document resubmitted as draft-ietf. 375 B.7. Changes from draft-gont-tsvwg-source-quench-00 377 o This revision reflects the recent discussion about ICMP Source 378 Quench messages on the tsvwg mailing-list. A detailed list of the 379 changes is available at: 380 http://www.ietf.org/mail-archive/web/tsvwg/current/msg10407.html 382 Author's Address 384 Fernando Gont 385 UTN-FRH / SI6 Networks 386 Evaristo Carriego 2644 387 Haedo, Provincia de Buenos Aires 1706 388 Argentina 390 Phone: +54 11 4650 8472 391 Email: fgont@si6networks.com 392 URI: http://www.si6networks.com