idnits 2.17.1 draft-gont-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 RFC1122, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC792, but the abstract doesn't seem to mention this, which it should. 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 (December 6, 2010) is 4861 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 185, 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 (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Area Working Group F. Gont 3 (tsvwg) UTN/FRH 4 Internet-Draft December 6, 2010 5 Updates: 792, 1122, 1812 6 (if approved) 7 Intended status: Standards Track 8 Expires: June 9, 2011 10 Deprecation of ICMP Source Quench messages 11 draft-gont-tsvwg-source-quench-01.txt 13 Abstract 15 This document formally deprecates the use of ICMP Source Quench 16 messages by transport protocols. 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 June 9, 2011. 35 Copyright Notice 37 Copyright (c) 2010 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. General Advice to Transport Protocols . . . . . . . . . . . . . 4 57 6. Changing the status of RFC 1016 Historic . . . . . . . . . . . 4 58 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 59 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 60 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 61 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 10.1. Normative References . . . . . . . . . . . . . . . . . . . 5 63 10.2. Informative References . . . . . . . . . . . . . . . . . . 6 64 Appendix A. Survey of support of ICMP Source Quench in some 65 popular TCP/IP implementations . . . . . . . . . . . . 6 66 Appendix B. Changes from previous versions of the draft (to 67 be removed by the RFC Editor before publishing 68 this document as an RFC) . . . . . . . . . . . . . . . 6 69 B.1. Changes from draft-gont-tsvwg-source-quench-00 . . . . . . 6 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 1. Introduction 74 The ICMP specification [RFC0792] defines the ICMPv4 Source Quench 75 message (type 4, code 0), which is meant as a mechanism for 76 congestion control. ICMP Source Quench is known to be an ineffective 77 (and unfair) antidote for congestion, and generation of ICMP Source 78 Quench messages by routers has been deprecated by [RFC1812] for a 79 long time. However, reaction to ICMP Source Quench messages in 80 transport protocols has never been formally deprecated. 82 This document formally deprecates reaction to ICMP Source Quench 83 messages by transport protocols such as TCP. 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in RFC 2119 [RFC2119]. 89 2. ICMP Source Quench messages 91 The ICMP specification [RFC0792] defines the ICMP Source Quench 92 message (type 4, code 0), which is meant to provide a mechanism for 93 congestion control. The Host Requirements RFC [RFC1122] states in 94 Section 4.2.3.9 that hosts MUST react to ICMP Source Quench messages 95 by slowing transmission on the connection, and further adds that the 96 RECOMMENDED procedure is to put the corresponding connection in the 97 slow-start phase of TCP's congestion control algorithm [RFC5681]. 99 [RFC1812] notes that research suggests that ICMP Source Quench is an 100 ineffective (and unfair) antidote for congestion, and formally 101 deprecates the generation of ICMP Source Quench messages by routers, 102 stating that routers SHOULD NOT send ICMP Source Quench messages in 103 response to congestion. 105 [RFC5927] discusses the use of ICMP Source Quench messages for 106 performing "blind throughput-reduction" attacks, and notes that most 107 TCP implementations silently ignore ICMP Source Quench messages. 109 We note that TCP implements its own congestion control mechanisms 110 [RFC5681] [RFC3168], that do not depend on ICMP Source Quench 111 messages. 113 It is interesting to note that ICMPv6 [RFC4443] does not specify a 114 "Source Quench" message. 116 3. Updating RFC 1122 118 We hereby update Section 3.2.2.3 of [RFC1122] as follows: 120 A host SHOULD NOT send ICMP Source Quench messages. 122 If Source Quench message is received, the IP layer MAY silently 123 discard it. 125 Section 4.2.3.9 of [RFC1122] is updated as follows: 127 TCP SHOULD silently discard any received ICMP Source Quench 128 messages. 130 4. Updating RFC 1812 132 We hereby update Section 4.3.3.3 OF [RFC1812] as follows: 134 A router SHOULD ignore any ICMP Source Quench messages it 135 receives. 137 5. General Advice to Transport Protocols 139 If an ICMP Source Quench message is received by a transport-protocol 140 instance (e.g., a TCP connection), it SHOULD be silently ignored. 142 6. Changing the status of RFC 1016 Historic 144 This document requests the RFC Editor to change the status of 145 [RFC1016] to "Historic". 147 7. Security Considerations 149 ICMP Source Quench messages could be leveraged for performing blind 150 throughput-reduction attacks against TCP and similar protocols. This 151 attack vector, along with possible countermeasures, have been 152 discussed in great detail in [RFC5927] and [CPNI-TCP]. However, as 153 noted in [RFC5927] and [CPNI-TCP], virtually all current versions of 154 popular TCP implementations already silently ignore ICMP Source 155 Quench messages. 157 Silently ignoring ICMP Source Quench messages, as specified in this 158 document, eliminates the aforementioned attack vector. 160 If deemed necessary, ICMP Source Quench messages could be filtered at 161 firewalls. 163 8. IANA Considerations 165 This document has no actions for IANA. The RFC-Editor can remove 166 this section before publication of this document as an RFC. 168 9. Acknowledgements 170 The author of this document would like to thank (in alphabetical 171 order) Fred Baker, Scott Bradner, Antonio De Simone, Gorry Fairhurst, 172 Alfred Hoenes, Mahesh Jethanandani, Dan Wing, and Andrew Yourtchenko, 173 for providing valuable feedback on earlier versions of this document. 175 This document has benefited from discussions within the TCPM Working 176 Group while working on [RFC5927]. 178 10. References 180 10.1. Normative References 182 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 183 RFC 792, September 1981. 185 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 186 RFC 793, September 1981. 188 [RFC1016] Prue, W. and J. Postel, "Something a host could do with 189 source quench: The Source Quench Introduced Delay 190 (SQuID)", RFC 1016, July 1987. 192 [RFC1122] Braden, R., "Requirements for Internet Hosts - 193 Communication Layers", STD 3, RFC 1122, October 1989. 195 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 196 RFC 1812, June 1995. 198 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 199 Requirement Levels", BCP 14, RFC 2119, March 1997. 201 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 202 of Explicit Congestion Notification (ECN) to IP", 203 RFC 3168, September 2001. 205 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 206 Message Protocol (ICMPv6) for the Internet Protocol 207 Version 6 (IPv6) Specification", RFC 4443, March 2006. 209 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 210 Control", RFC 5681, September 2009. 212 10.2. Informative References 214 [CPNI-TCP] 215 CPNI, "Security Assessment of the Transmission Control 216 Protocol (TCP)", http://www.cpni.gov.uk/Docs/ 217 tn-03-09-security-assessment-TCP.pdf, 2009. 219 [FreeBSD] The FreeBSD Project, "http://www.freebsd.org". 221 [Linux] The Linux Project, "http://www.kernel.org". 223 [NetBSD] The NetBSD Project, "http://www.netbsd.org". 225 [OpenBSD] The OpenBSD Project, "http://www.openbsd.org". 227 [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010. 229 Appendix A. Survey of support of ICMP Source Quench in some popular 230 TCP/IP implementations 232 A large number of implementations completely ignore ICMP Source 233 Quench messages meant for TCP connections. This behavior has been 234 implemented in, at least, Linux [Linux] since 2004, and in FreeBSD 235 [FreeBSD], NetBSD [NetBSD], and OpenBSD [OpenBSD] since 2005. 237 Appendix B. Changes from previous versions of the draft (to be removed 238 by the RFC Editor before publishing this document as an 239 RFC) 241 B.1. Changes from draft-gont-tsvwg-source-quench-00 243 o This revision reflects the recent discussion about ICMP Source 244 Quench messages on the tsvwg mailing-list. A detailed list of the 245 changes is available at: 246 http://www.ietf.org/mail-archive/web/tsvwg/current/msg10407.html 248 Author's Address 250 Fernando Gont 251 Universidad Tecnologica Nacional / Facultad Regional Haedo 252 Evaristo Carriego 2644 253 Haedo, Provincia de Buenos Aires 1706 254 Argentina 256 Phone: +54 11 4650 8472 257 Email: fernando@gont.com.ar 258 URI: http://www.gont.com.ar