RFC 7514

Really Explicit Congestion Notification (RECN)

📅 published April 2015, from ietf

Really Explicit Congestion Notification (RECN) 💖

Title block tea ☕

  • Stream: Independent Submission
  • RFC number: 7514
  • Author: Matthew Luckie (M. Luckie), CAIDA
  • Category: Experimental 🧪
  • Date: 1 April 2015 📅
  • ISSN: 2070-1721
  • Obsoletes / Updates: the header doesn't list either, so this one doesn't obsolete or update anything 🤷‍♀️

Abstract ✨

okay so this doc proposes a brand new ICMP message 🦋 that a router or host can use to tell a host to slow down how fast it's sending 🐢. This is for when the host is ignoring the other hints it gets from packet loss and Explicit Congestion Notification (ECN). main character energy, honestly 👑.

Status of This Memo 📜

This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.

This document defines an Experimental Protocol for the Internet community. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7514.

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Table of Contents 🗂️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
  1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   2
2.  RECN Message Format . . . . . . . . . . . . . . . . . . . . .   2
  2.1.  Advice to Implementers  . . . . . . . . . . . . . . . . .   3
  2.2.  Relationship to ICMP Source Quench  . . . . . . . . . . .   4
3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
4.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
5.  Normative References  . . . . . . . . . . . . . . . . . . . .   4
Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5

1. Introduction 🎀

okay so the deployment of Explicit Congestion Notification (ECN) [RFC3168] is literally stalled 😭. Most operating systems support ECN, but it's turned off by default because people are scared that enabling it will break transport protocols 💀. This doc proposes a new ICMP message that a router or host may use to advise a host to reduce the rate at which it sends, in cases where the host ignores other signals such as packet loss and ECN. We call it the "Really Explicit Congestion Notification" (RECN) message because it delivers a less subtle indication of congestion than packet loss and ECN 🫶.

1.1. Requirements Language 🔤

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Those capital-letter words are the ones with real force, so read them carefully 🧐.

2. RECN Message Format 🧾

Here's the layout, bestie 🍓:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Explicit Notification                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           As much of the invoking packet as possible          |
   +           without the ICMP packet exceeding 576 bytes         |
   |               in IPv4 or the minimum MTU in IPv6              |

Type 🔢

  • IPv4: 4
  • IPv6: 201

Code 🙈

  • 0

Checksum ✨

The checksum is the 16-bit ones's complement of the one's complement sum of the ICMP message starting with the ICMP type field. When an RECN message is encapsulated in an IPv6 packet, the computation includes a "pseudo-header" of IPv6 header fields as specified in Section 8.1 of [RFC2460]. For computing the checksum, the checksum field is first set to zero.

Explicit Notification 💬

This is a 4-byte value that conveys an explicit notification in the ASCII format defined in [RFC20]. This field MUST NOT be set to zero.

Description 📣

An RECN message SHOULD be sent by a router in response to a host that is generating traffic at a rate persistently unfair to other competing flows and that has not reacted to previous packet losses or ECN marks.

The contents of an RECN message MUST be conveyed to the user responsible for the traffic. Precisely how this is accomplished will depend on the capabilities of the host. If text-to-speech capabilities are available, the contents should be converted to sound form and audibly rendered. If the system is currently muted, a pop-up message will suffice. 📱🔊

2.1. Advice to Implementers 💡

As the Explicit Notification field is only 4 bytes, it is not required that the word be null terminated. A client implementation should be careful not to use more than those 4 bytes. If a router chooses a word less than 4 bytes in size, it should null-terminate that word.

A router should not necessarily send an RECN message every time it discards a packet due to congestion. Rather, a router should send these messages whenever it discards a burst of packets from a single sender. For every packet a router discards in a single burst, it should send an RECN message. A router may form short sentences composed of different 4-byte words, and a host should play these sentences back to the user. A router may escalate the content in the Explicit Notification field if it determines that a sender has not adjusted its transmission rate in response to previous RECN messages. There is no upper bound on the intensity of the escalation, either in content or sentence length. 📢💅

2.2. Relationship to ICMP Source Quench 🤝

The RECN message was inspired by the ICMP Source Quench message, which is now deprecated [RFC6633]. Because the RECN message uses a similar approach, an RECN message uses the same ICMP type when encapsulated in IPv4 as was used by the ICMP Source Quench message. It's giving family tree 🌳.

3. IANA Considerations 📋

This is an Experimental RFC; the experiment will conclude two years after the publication of this RFC. During the experiment, implementers are free to use words of their own choosing (up to four letters) in RECN messages. If RECN becomes a Standard of any kind, a list of allowed words will be maintained in an IANA registry. There are no IANA actions required at this time. 🦋

4. Security Considerations 🔐

ICMP messages may be used in various attacks [RFC5927]. An attacker may use the RECN message to cause a host to reduce their transmission rate for no reason. To prevent such an attack, a host must ensure the quoted message corresponds to an active flow on the system, and an attacker MUST set the security flag defined in [RFC3514] to 1 when the RECN message is carried in an IPv4 packet.

🚨 Serious bestie alert: the spoofed-slowdown attack is real, so the flow check and the security flag are not optional vibes. Treat them seriously 💀.

5. Normative References 📚

[RFC20]    Cerf, V., "ASCII format for network interchange", STD 80,
           RFC 20, October 1969,
           <http://www.rfc-editor.org/info/rfc20>.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997,
           <http://www.rfc-editor.org/info/rfc2119>.

[RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
           (IPv6) Specification", RFC 2460, December 1998,
           <http://www.rfc-editor.org/info/rfc2460>.

[RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
           of Explicit Congestion Notification (ECN) to IP", RFC
           3168, September 2001,
           <http://www.rfc-editor.org/info/rfc3168>.

[RFC3514]  Bellovin, S., "The Security Flag in the IPv4 Header", RFC
           3514, April 2003,
           <http://www.rfc-editor.org/info/rfc3514>.

[RFC5927]  Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010,
           <http://www.rfc-editor.org/info/rfc5927>.

[RFC6633]  Gont, F., "Deprecation of ICMP Source Quench Messages",
           RFC 6633, May 2012,
           <http://www.rfc-editor.org/info/rfc6633>.

Author's Address 📮

Matthew Luckie
CAIDA
University of California, San Diego
9500 Gilman Drive
La Jolla, CA  92093-0505
United States

EMail: mjl@caida.org

That's the whole RFC, bestie 🌈💖✨

📦 where this page comes from