< draft-ietf-tsvwg-source-quench-01.txt   draft-ietf-tsvwg-source-quench-02.txt >
Transport Area Working Group (tsvwg) F. Gont Transport Area Working Group (tsvwg) F. Gont
Internet-Draft UTN/FRH Internet-Draft UTN/FRH
Updates: 792, 1122, 1812 June 10, 2011 Updates: 792, 1122, 1812 September 8, 2011
(if approved) (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: December 12, 2011 Expires: March 11, 2012
Deprecation of ICMP Source Quench messages Deprecation of ICMP Source Quench messages
draft-ietf-tsvwg-source-quench-01.txt draft-ietf-tsvwg-source-quench-02.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. Additionally, it requests that the status of RFC 1016
be changed to "Historic". be changed to "Historic".
Status of this Memo Status of this Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 December 12, 2011. This Internet-Draft will expire on March 11, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 12 skipping to change at page 2, line 12
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
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. General Advice to Transport Protocols . . . . . . . . . . . . . 4 5. Clarification for SCTP and DCCP . . . . . . . . . . . . . . . . 5
6. Changing the status of RFC 1016 to Historic . . . . . . . . . . 4 6. General Advice to Transport Protocols . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 7. Changing the status of RFC 1016 to Historic . . . . . . . . . . 5
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
10.1. Normative References . . . . . . . . . . . . . . . . . . . 5 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
10.2. Informative References . . . . . . . . . . . . . . . . . . 6 11.1. Normative References . . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . 7
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) . . . . . . . . . . . . . . . 7 this document as an RFC) . . . . . . . . . . . . . . . 7
B.1. Changes from draft-ietf-tsvwg-source-quench-00 . . . . . . 7 B.1. Changes from draft-ietf-tsvwg-source-quench-01 . . . . . . 8
B.2. Changes from draft-gont-tsvwg-source-quench-01 . . . . . . 7 B.2. Changes from draft-ietf-tsvwg-source-quench-00 . . . . . . 8
B.3. Changes from draft-gont-tsvwg-source-quench-00 . . . . . . 7 B.3. Changes from draft-gont-tsvwg-source-quench-01 . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 B.4. Changes from draft-gont-tsvwg-source-quench-00 . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
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.
skipping to change at page 4, line 22 skipping to change at page 4, line 22
[RFC5681] [RFC3168], that do not depend on ICMP Source Quench [RFC5681] [RFC3168], that do not depend on ICMP Source Quench
messages. messages.
It is interesting to note that ICMPv6 [RFC4443] does not specify a It is interesting to note that ICMPv6 [RFC4443] does not specify a
"Source Quench" message. "Source Quench" message.
3. Updating RFC 1122 3. Updating RFC 1122
This document hereby updates Section 3.2.2.3 of [RFC1122] as follows: This document hereby updates Section 3.2.2.3 of [RFC1122] as follows:
A host SHOULD NOT send ICMP Source Quench messages. A host MUST NOT send ICMP Source Quench messages.
If a Source Quench message is received, the IP layer MAY silently If a Source Quench message is received, the IP layer MAY silently
discard it. discard it.
Section 4.2.3.9 of [RFC1122] is updated as follows: Section 4.2.3.9 of [RFC1122] is updated as follows:
TCP SHOULD silently discard any received ICMP Source Quench TCP MUST silently discard any received ICMP Source Quench
messages. messages.
The consenus of the TSV WG was that there are no valid reasons for a
host to generate or react to an ICMP Source Quench message in the
current Internet. Discarding ICMP Source Quench messages at the
internet-layer (rather than at the transport layer) is a performance
optimization that is permitted by this update.
4. Updating RFC 1812 4. Updating RFC 1812
This document hereby updates Section 4.3.3.3 of [RFC1812] as follows: This document hereby updates Section 4.3.3.3 of [RFC1812] as follows:
A router SHOULD ignore any ICMP Source Quench messages it A router MUST ignore any ICMP Source Quench messages it receives.
receives.
5. General Advice to Transport Protocols The consenus of the TSV WG was that there are no valid reasons for a
router to react to ICMP Source Quench messages in the current
Internet.
If a Source Quench message is received by a transport-protocol 5. Clarification for SCTP and DCCP
instance (e.g., a TCP connection), it SHOULD be silently ignored.
6. Changing the status of RFC 1016 to Historic It is understood that SCTP and SCCP did not specify support for
processing received ICMP Source Quench messages. Hereby we clarify
that DCCP and SCTP end-points MUST silently discard received ICMP
Source Quench messages.
6. General Advice to Transport Protocols
If a Source Quench message is received by any other transport-
protocol instance (e.g., a UDP-based protocol), it SHOULD be silently
ignored.
The TSV WG is not aware of any use that requires processing of these
messages, and therefore expects other transports to follow the
recommendations in Section 3. Note that for IETF-specified
transports, this document formally deprecates reaction to ICMP Source
Quench messages, and that generation of ICMP Source Quench messages
has been deprecated for both hosts and routers. Therefore, future
applications can not expect to receive these messages.
7. Changing the status of RFC 1016 to Historic
This document requests the RFC Editor to change the status of This document requests the RFC Editor to change the status of
[RFC1016] to "Historic". [RFC1016] to "Historic".
7. 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, have been attack vector, along with possible countermeasures, has been
discussed in great detail in [RFC5927] and [CPNI-TCP]. However, as discussed in great detail in [RFC5927] and [CPNI-TCP]. However, as
noted in [RFC5927] and [CPNI-TCP], virtually all current versions of noted in [RFC5927] and [CPNI-TCP], virtually all current versions of
popular TCP implementations already silently ignore ICMP Source popular TCP implementations already silently ignore ICMP Source
Quench messages. Quench messages. This is also the case for SCTP and DCCP
implementations.
Silently ignoring ICMP Source Quench messages, as specified in this Silently ignoring ICMP Source Quench messages, as specified in this
document, eliminates the aforementioned attack vector. document, eliminates the aforementioned attack vector.
If deemed necessary, ICMP Source Quench messages could be filtered at If deemed necessary, ICMP Source Quench messages could be filtered at
firewalls. firewalls.
8. 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.
9. Acknowledgements 10. Acknowledgements
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, Gorry Fairhurst, Alfred Hoenes, Mahesh Jethanandani, De Simone, Gorry Fairhurst, Alfred Hoenes, Mahesh Jethanandani,
Carlos Pignataro, Anantha Ramaiah, Dan Wing, and Andrew Yourtchenko, Carlos Pignataro, Anantha Ramaiah, Randall Stewart, Dan Wing, and
for providing valuable feedback on earlier versions of this document. Andrew Yourtchenko, 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].
10. References 11. References
10.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.
[RFC1016] Prue, W. and J. Postel, "Something a host could do with [RFC1016] Prue, W. and J. Postel, "Something a host could do with
source quench: The Source Quench Introduced Delay source quench: The Source Quench Introduced Delay
(SQuID)", RFC 1016, July 1987. (SQuID)", RFC 1016, July 1987.
skipping to change at page 6, line 18 skipping to change at page 7, line 5
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", [RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
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.
10.2. Informative References 11.2. Informative References
[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>.
[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,
skipping to change at page 7, line 19 skipping to change at page 8, line 5
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-00 B.1. Changes from draft-ietf-tsvwg-source-quench-01
o Changes deprecation of ICMP SQ from "SHOULD NOT" to "MUST NOT" in
response of feedback from Scott Bradner and the TSV WG.
B.2. 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.2. Changes from draft-gont-tsvwg-source-quench-01 B.3. Changes from draft-gont-tsvwg-source-quench-01
o Addresses nits and editorial chagnes suggested by Gorry Fairhurst. o Addresses nits and editorial chagnes 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.3. Changes from draft-gont-tsvwg-source-quench-00 B.4. 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 Universidad Tecnologica Nacional / Facultad Regional Haedo
 End of changes. 25 change blocks. 
37 lines changed or deleted 71 lines changed or added

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