draft-ietf-tsvwg-source-quench-04.txt   draft-ietf-tsvwg-source-quench-05.txt 
Transport Area Working Group (tsvwg) F. Gont Transport Area Working Group (tsvwg) F. Gont
Internet-Draft UTN/FRH Internet-Draft UTN-FRH / SI6 Networks
Obsoletes: 1016 (if approved) January 19, 2012 Updates: 792, 1122, 1812 February 22, 2012
Updates: 792, 1122, 1812
(if approved) (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: July 22, 2012 Expires: August 25, 2012
Deprecation of ICMP Source Quench messages Deprecation of ICMP Source Quench messages
draft-ietf-tsvwg-source-quench-04.txt draft-ietf-tsvwg-source-quench-05.txt
Abstract Abstract
This document formally deprecates the use of ICMP Source Quench This document formally deprecates the use of ICMP Source Quench
messages by transport protocols, formally updating RFC 792, RFC 1122, messages by transport protocols, formally updating RFC 792, RFC 1122,
and RFC 1812. Additionally, it requests that the status of RFC 1016 and RFC 1812.
be changed to "Historic".
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 22, 2012. This Internet-Draft will expire on August 25, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 15 skipping to change at page 2, line 13
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. ICMP Source Quench messages . . . . . . . . . . . . . . . . . . 3 2. ICMP Source Quench messages . . . . . . . . . . . . . . . . . . 3
3. Updating RFC 1122 . . . . . . . . . . . . . . . . . . . . . . . 4 3. Updating RFC 1122 . . . . . . . . . . . . . . . . . . . . . . . 4
4. Updating RFC 1812 . . . . . . . . . . . . . . . . . . . . . . . 4 4. Updating RFC 1812 . . . . . . . . . . . . . . . . . . . . . . . 4
5. Clarification for UDP, SCTP, and DCCP . . . . . . . . . . . . . 5 5. Clarification for UDP, SCTP, and DCCP . . . . . . . . . . . . . 5
6. General Advice to Transport Protocols . . . . . . . . . . . . . 5 6. General Advice to Transport Protocols . . . . . . . . . . . . . 5
7. Changing the status of RFC 1016 to Historic . . . . . . . . . . 5 7. Recommendation Regarding RFC 1016 . . . . . . . . . . . . . . . 5
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
11.1. Normative References . . . . . . . . . . . . . . . . . . . 6 11.1. Normative References . . . . . . . . . . . . . . . . . . . 7
11.2. Informative References . . . . . . . . . . . . . . . . . . 7 11.2. Informative References . . . . . . . . . . . . . . . . . . 7
Appendix A. Survey of support of ICMP Source Quench in some Appendix A. Survey of support of ICMP Source Quench in some
popular TCP/IP implementations . . . . . . . . . . . . 7 popular TCP/IP implementations . . . . . . . . . . . . 8
Appendix B. Changes from previous versions of the draft (to Appendix B. Changes from previous versions of the draft (to
be removed by the RFC Editor before publishing be removed by the RFC Editor before publishing
this document as an RFC) . . . . . . . . . . . . . . . 8 this document as an RFC) . . . . . . . . . . . . . . . 8
B.1. Changes from draft-ietf-tsvwg-source-quench-03 . . . . . . 8 B.1. Changes from draft-ietf-tsvwg-source-quench-04 . . . . . . 8
B.2. Changes from draft-ietf-tsvwg-source-quench-02 . . . . . . 8 B.2. Changes from draft-ietf-tsvwg-source-quench-03 . . . . . . 8
B.3. Changes from draft-ietf-tsvwg-source-quench-01 . . . . . . 8 B.3. Changes from draft-ietf-tsvwg-source-quench-02 . . . . . . 9
B.4. Changes from draft-ietf-tsvwg-source-quench-00 . . . . . . 8 B.4. Changes from draft-ietf-tsvwg-source-quench-01 . . . . . . 9
B.5. Changes from draft-gont-tsvwg-source-quench-01 . . . . . . 8 B.5. Changes from draft-ietf-tsvwg-source-quench-00 . . . . . . 9
B.6. Changes from draft-gont-tsvwg-source-quench-00 . . . . . . 8 B.6. Changes from draft-gont-tsvwg-source-quench-01 . . . . . . 9
B.7. Changes from draft-gont-tsvwg-source-quench-00 . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
The ICMP specification [RFC0792] defined the ICMP Source Quench The ICMP specification [RFC0792] defined the ICMP Source Quench
message (type 4, code 0), which was meant as a mechanism for message (type 4, code 0), which was meant as a mechanism for
congestion control. ICMP Source Quench has been known to be an congestion control. ICMP Source Quench has been known to be an
ineffective (and unfair) antidote for congestion, and generation of ineffective (and unfair) antidote for congestion, and generation of
ICMP Source Quench messages by routers has been formally deprecated ICMP Source Quench messages by routers has been formally deprecated
by [RFC1812] since 1995. However, reaction to ICMP Source Quench by [RFC1812] since 1995. However, reaction to ICMP Source Quench
messages in transport protocols has never been formally deprecated. messages in transport protocols has never been formally deprecated.
This document formally deprecates reaction to ICMP Source Quench This document formally deprecates reaction to ICMP Source Quench
messages by transport protocols such as TCP, formally updating messages by transport protocols such as TCP, formally updating
[RFC0792], [RFC1122], and [RFC1812]. Additionally, it requests that [RFC0792], [RFC1122], and [RFC1812]. Additionally, it provides
the status of [RFC1016] be changed to "Historic". The rationale for recommendation against the implementation of [RFC1016]. The
these specification updates is: rationale for these specification updates is:
o Processing of ICMP Source Quench messages by routers has been o Processing of ICMP Source Quench messages by routers has been
deprecated for more than 20 years [RFC1812]. deprecated for more than 20 years [RFC1812].
o Virtually all popular host implementations have removed support o Virtually all popular host implementations have removed support
for ICMP Source Quench messages since (at least) 2005 [RFC5927]. for ICMP Source Quench messages since (at least) 2005 [RFC5927].
o Widespread deployment of ICMP filtering makes it impossible to o Widespread deployment of ICMP filtering makes it impossible to
rely on ICMP Source Quench messages for congestion control. rely on ICMP Source Quench messages for congestion control.
o The IETF has moved away from ICMP Source Quench messages for o The IETF has moved away from ICMP Source Quench messages for
congestion control (note e.g. the development of ECN [RFC3168], congestion control (note e.g. the development of ECN [RFC3168],
and the fact that ICMPv6 [RFC4443] does not even specify a Source and the fact that ICMPv6 [RFC4443] does not even specify a Source
Quench message). Quench message).
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", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. ICMP Source Quench messages 2. ICMP Source Quench messages
The ICMP specification [RFC0792] defined the ICMP Source Quench The ICMP specification [RFC0792] defined the ICMP Source Quench
message (type 4, code 0), which was meant to provide a mechanism for message (type 4, code 0), which was meant to provide a mechanism for
congestion control. The Host Requirements RFC [RFC1122] stated in congestion control. The Host Requirements RFC [RFC1122] stated in
Section 4.2.3.9 that hosts MUST react to ICMP Source Quench messages Section 4.2.3.9 that hosts MUST react to ICMP Source Quench messages
skipping to change at page 5, line 35 skipping to change at page 5, line 35
protocol instance, it MUST be silently ignored. protocol instance, it MUST be silently ignored.
The TSV WG is not aware of any use that requires processing of these The TSV WG is not aware of any use that requires processing of these
messages, and therefore expects other transports to follow the messages, and therefore expects other transports to follow the
recommendations in Section 3. Note that for IETF-specified recommendations in Section 3. Note that for IETF-specified
transports, this document formally deprecates reaction to ICMP Source transports, this document formally deprecates reaction to ICMP Source
Quench messages, and that generation of ICMP Source Quench messages Quench messages, and that generation of ICMP Source Quench messages
has been deprecated for both hosts and routers. Therefore, future has been deprecated for both hosts and routers. Therefore, future
applications can not expect to receive these messages. applications can not expect to receive these messages.
7. Changing the status of RFC 1016 to Historic 7. Recommendation Regarding RFC 1016
This document requests the RFC Editor to change the status of RFC 1016 [RFC1016] described an experimental approach to ICMP Source
[RFC1016] to "Historic". Quench message handling in hosts that was being thought about in
1987. The IETF notes that RFC 1016 has never been on the IETF
standards-track, but for clarity and avoidance of doubt, the note
that the approach described in RFC 1016 [RFC1016] MUST NOT be
implemented.
8. Security Considerations 8. Security Considerations
ICMP Source Quench messages could be leveraged for performing blind ICMP Source Quench messages could be leveraged for performing blind
throughput-reduction attacks against TCP and similar protocols. This throughput-reduction attacks against TCP and similar protocols. This
attack vector, along with possible countermeasures, has been attack vector, along with possible countermeasures, has been
discussed in great detail in [RFC5927] and [CPNI-TCP]. 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.
Even though sources "MUST NOT" send ICMP Source Quench Message, there For current TCP implementations, receipt of an ICMP Source Quench
are no known security issues that result from receipt of this message message should not result in security issues because, as noted in
because, as noted in [RFC5927] and [CPNI-TCP], virtually all current [RFC5927] and [CPNI-TCP], virtually all current versions of popular
versions of popular TCP implementations already silently ignore ICMP TCP implementations already silently ignore ICMP Source Quench
Source Quench messages. This is also the case for SCTP and DCCP messages. This is also the case for SCTP and DCCP implementations.
implementations. Receivers should not treat reception as an
exception, error or logged event. Receipt of an ICMP Source Quench
message must not be interpreted as an attempt to attack the receiver.
Silently ignoring ICMP Source Quench messages, as specified in this Hosts, security gateways, and firewalls MUST silently discard
document, eliminates the aforementioned attack vector. 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).
If deemed necessary, ICMP Source Quench messages could be filtered at We note that security devices such as the Snort Network Intrusion
firewalls. Detection System (NIDS) has logged ICMP Source Quench messages as
such for more than ten years. [Anderson2002].
9. IANA Considerations 9. IANA Considerations
IANA is requested to mark ICMP type 4 (Source Quench) as "Deprecated" IANA is requested to mark ICMP type 4 (Source Quench) as "Deprecated"
in de ICMP Parameters registry [ICMPPARREG] with a reference to this in de ICMP Parameters registry [ICMPPARREG] with a reference to this
document. document.
10. Acknowledgements 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 The author of this document would like to thank (in alphabetical
order) Fred Baker, David Black, Scott Bradner, James Carlson, Antonio order) Fred Baker, David Black, Scott Bradner, James Carlson, Antonio
De Simone, Wesley Eddy, Gorry Fairhurst, Alfred Hoenes, Mahesh De Simone, Wesley Eddy, Gorry Fairhurst, Alfred Hoenes, Mahesh
Jethanandani, Carlos Pignataro, Anantha Ramaiah, Randall Stewart, Dan Jethanandani, Kathleen Moriarty, Carlos Pignataro, James Polk,
Wing, and Andrew Yourtchenko, for providing valuable feedback on Anantha Ramaiah, Randall Stewart, Dan Wing, and Andrew Yourtchenko,
earlier versions of this document. for providing valuable feedback on earlier versions of this document.
This document has benefited from discussions within the TCPM Working This document has benefited from discussions within the TCPM Working
Group while working on [RFC5927]. Group while working on [RFC5927].
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981. RFC 792, September 1981.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989.
skipping to change at page 7, line 14 skipping to change at page 7, line 26
RFC 1812, June 1995. RFC 1812, June 1995.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, September 2009. Control", RFC 5681, September 2009.
11.2. Informative References 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-TCP]
CPNI, "Security Assessment of the Transmission Control CPNI, "Security Assessment of the Transmission Control
Protocol (TCP)", 2009, <http://www.cpni.gov.uk/Docs/ Protocol (TCP)", 2009, <http://www.cpni.gov.uk/Docs/
tn-03-09-security-assessment-TCP.pdf>. tn-03-09-security-assessment-TCP.pdf>.
[Floyd1994]
Floyd, S., "TCP and Explicit Congestion Notification", ACM
CCR Volume 24, Issue 5, 1994.
[FreeBSD] The FreeBSD Project, "http://www.freebsd.org". [FreeBSD] The FreeBSD Project, "http://www.freebsd.org".
[ICMPPARREG] [ICMPPARREG]
Internet Control Message Protocol (ICMP) Parameters, Internet Control Message Protocol (ICMP) Parameters,
"http://www.iana.org/assignments/icmp-parameters". "http://www.iana.org/assignments/icmp-parameters".
[Linux] The Linux Project, "http://www.kernel.org". [Linux] The Linux Project, "http://www.kernel.org".
[NetBSD] The NetBSD Project, "http://www.netbsd.org". [NetBSD] The NetBSD Project, "http://www.netbsd.org".
skipping to change at page 8, line 16 skipping to change at page 8, line 36
Quench messages meant for TCP connections. This behavior has been Quench messages meant for TCP connections. This behavior has been
implemented in, at least, Linux [Linux] since 2004, and in FreeBSD implemented in, at least, Linux [Linux] since 2004, and in FreeBSD
[FreeBSD], NetBSD [NetBSD], OpenBSD [OpenBSD], and Solaris 10 since [FreeBSD], NetBSD [NetBSD], OpenBSD [OpenBSD], and Solaris 10 since
2005. Additionally, OpenSolaris [OpenSolaris] has always shipped 2005. Additionally, OpenSolaris [OpenSolaris] has always shipped
with support for ICMP Source Quench messages disabled. with support for ICMP Source Quench messages disabled.
Appendix B. Changes from previous versions of the draft (to be removed Appendix B. Changes from previous versions of the draft (to be removed
by the RFC Editor before publishing this document as an by the RFC Editor before publishing this document as an
RFC) RFC)
B.1. Changes from draft-ietf-tsvwg-source-quench-03 B.1. Changes from draft-ietf-tsvwg-source-quench-04
o Removes request to move RFC 1016 to "Historic" status.
o Updates the Security Considerations section.
B.2. Changes from draft-ietf-tsvwg-source-quench-03
o Added 'Obsoletes' metadata, and moved the reference to [RFC1016] o Added 'Obsoletes' metadata, and moved the reference to [RFC1016]
from the 'Normative References' to the 'Informative References'. from the 'Normative References' to the 'Informative References'.
B.2. Changes from draft-ietf-tsvwg-source-quench-02 B.3. Changes from draft-ietf-tsvwg-source-quench-02
o Clarifies the requirements language. o Clarifies the requirements language.
B.3. Changes from draft-ietf-tsvwg-source-quench-01 B.4. Changes from draft-ietf-tsvwg-source-quench-01
o Changes deprecation of ICMP SQ from "SHOULD NOT" to "MUST NOT" in o Changes deprecation of ICMP SQ from "SHOULD NOT" to "MUST NOT" in
response of feedback from Scott Bradner and the TSV WG. response of feedback from Scott Bradner and the TSV WG.
B.4. Changes from draft-ietf-tsvwg-source-quench-00 B.5. Changes from draft-ietf-tsvwg-source-quench-00
o Discusses the motivation for deprecating ICMP Source Quench o Discusses the motivation for deprecating ICMP Source Quench
messages (as suggested by Anantha Ramaiah). messages (as suggested by Anantha Ramaiah).
o Incorporates IANA considerations such that ICMP Source Quench o Incorporates IANA considerations such that ICMP Source Quench
messages are deprecated in the corresponding registry. messages are deprecated in the corresponding registry.
B.5. Changes from draft-gont-tsvwg-source-quench-01 B.6. Changes from draft-gont-tsvwg-source-quench-01
o Addresses nits and editorial changes suggested by Gorry Fairhurst. o Addresses nits and editorial changes suggested by Gorry Fairhurst.
o Added the status of Solaris and OpenSolaris to Appendix A. o Added the status of Solaris and OpenSolaris to Appendix A.
o Document resubmitted as draft-ietf. o Document resubmitted as draft-ietf.
B.6. Changes from draft-gont-tsvwg-source-quench-00 B.7. Changes from draft-gont-tsvwg-source-quench-00
o This revision reflects the recent discussion about ICMP Source o This revision reflects the recent discussion about ICMP Source
Quench messages on the tsvwg mailing-list. A detailed list of the Quench messages on the tsvwg mailing-list. A detailed list of the
changes is available at: changes is available at:
http://www.ietf.org/mail-archive/web/tsvwg/current/msg10407.html http://www.ietf.org/mail-archive/web/tsvwg/current/msg10407.html
Author's Address Author's Address
Fernando Gont Fernando Gont
Universidad Tecnologica Nacional / Facultad Regional Haedo UTN-FRH / SI6 Networks
Evaristo Carriego 2644 Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706 Haedo, Provincia de Buenos Aires 1706
Argentina Argentina
Phone: +54 11 4650 8472 Phone: +54 11 4650 8472
Email: fernando@gont.com.ar Email: fgont@si6networks.com
URI: http://www.gont.com.ar URI: http://www.si6networks.com
 End of changes. 30 change blocks. 
48 lines changed or deleted 77 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/