RFC 7837

IPv6 Destination Option for Congestion Exposure (ConEx)

📅 published May 2016, from ietf

RFC 7837: IPv6 Destination Option for Congestion Exposure (ConEx) 🎀

Okay bestie, this one is from the IETF, published in May 2016 🌸. The authors are S. Krishnan (Ericsson), M. Kuehlewind (ETH Zurich), B. Briscoe (Simula Research Laboratory), and C. Ralli (Telefonica). It's an Experimental doc (ISSN 2070-1721) 🧪, and the title block doesn't list anything it obsoletes or updates.

Abstract ✨

Okay so, Congestion Exposure (ConEx) is a mechanism where senders tell the network about the congestion their packets ran into earlier in the same flow 📡. This doc specifies an IPv6 destination option that can carry ConEx markings in IPv6 datagrams 💖.

Status of This Memo 📜

This document is not an Internet Standards Track specification 🙅‍♀️. It's published so people can examine it, implement it experimentally, and evaluate it 🔬.

It defines an Experimental Protocol for the Internet community. It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 🫶. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for the details 🤓.

For info on the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc7837 🔗.

Copyright (c) 2016 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) as in effect on the date of publication. Please actually read these, because they spell out your rights and restrictions for this document 📖. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License ⚖️.

Table of Contents 🗂️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Conventions Used in This Document . . . . . . . . . . . . . .   3
3.  Requirements for the Coding of ConEx in IPv6  . . . . . . . .   4
4.  ConEx Destination Option (CDO)  . . . . . . . . . . . . . . .   5
5.  Implementation in the Fast Path of ConEx-Aware Routers  . . .   8
6.  Tunnel Processing . . . . . . . . . . . . . . . . . . . . . .   8
7.  Compatibility with Use of IPsec . . . . . . . . . . . . . . .   9
8.  Mitigating Flooding Attacks by Using Preferential Drop  . . .   9
9.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
  11.1.  Normative References . . . . . . . . . . . . . . . . . .  11
  11.2.  Informative References . . . . . . . . . . . . . . . . .  12
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  13
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1. Introduction 🦋

So ConEx is defined in [RFC7713]. It's the mechanism where senders tell the network about congestion their packets hit earlier in the same flow 📡. This doc specifies an IPv6 destination option [RFC2460] that can be used to do ConEx markings in IPv6 datagrams 🎀.

This doc is where the ConEx wire protocol in IPv6 gets specified 🔧. The ConEx info can be used by any network element on the path for stuff like traffic management or egress policing 🚦. This info might also get used by an audit function that checks whether the sender's signaling is legit 🕵️‍♀️. And each transport protocol that supports ConEx signaling will need to precisely specify when it sets ConEx markings. For example, the TCP behavior is specified in [RFC7786] 💜.

This doc is ConEx for IPv6 only 🙅‍♀️. IPv4 headers have space limits, and there's a risk that a middlebox strips options in IPv4. So the main goal of the working group was to specify ConEx in IPv6, for experimentation 🧪.

This spec is experimental so the IETF can figure out whether making the ConEx Signal a destination option meets the requirements in this doc. It also lets them evaluate the proposed encoding of the ConEx Signals described in [RFC7713] 🔬.

The experiment is expected to last no less than two years from publication of this doc, because infrastructure has to be set up before anyone can determine the outcome 🗓️. Experimenting with ConEx needs IPv6 traffic. Even though IPv6 traffic is growing, the traffic mix on IPv6 is still very different from IPv4 🌍. So it might take longer to find a good test scenario where only IPv6 traffic is managed with ConEx 🥲.

2. Conventions Used in This Document 📏

Okay the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be read as described in [RFC2119] 🫶.

3. Requirements for the Coding of ConEx in IPv6 💅

A set of requirements for an ideal concrete ConEx wire protocol is in [RFC7713] 📋. The ConEx working group knew it would be hard to find an IPv6 encoding that satisfies all of them 😭. So the choice in this doc to put ConEx info in a destination option aims at the requirements that constrain where ConEx info can go 🎯:

  • R-1: The marking mechanism needs to be visible to all ConEx-capable nodes on the path.
  • R-2: The mechanism needs to be able to traverse nodes that do not understand the markings. This is required to ensure that ConEx can be incrementally deployed over the Internet.
  • R-3: The presence of the marking mechanism should not significantly alter the processing of the packet. This is required to ensure that ConEx-Marked packets do not face any undue delays or drops due to a badly chosen mechanism.
  • R-4: The markings should be immutable once set by the sender. At the very least, any tampering should be detectable.

Based on these requirements, four solutions for putting ConEx info in the IPv6 header were looked at: hop-by-hop options, destination options, using IPv6 header bits (from the flow label), and new extension headers 🤔. After weighing them, the ConEx working group decided a destination option would best address these requirements 🏆.

Hop-by-hop options would have been the best solution for carrying ConEx markings if they had met R-3 ⏳. The 6MAN working group has work ongoing to address exactly this issue [HBH-HEADER] 🛠️. If that new behavior lands, it would address R-3 and make hop-by-hop options the preferred solution for carrying ConEx markings 🌟.

Choosing a destination option doesn't necessarily satisfy the on-path visibility requirement, because it can be encapsulated by additional IP header(s) 🫣. So ConEx-aware network devices, including policy or audit devices, might have to follow the chaining (extension-) headers into the inner IP headers to find the ConEx info 🔍. This choice was a compromise between fast-path performance of ConEx-aware network nodes and visibility, as discussed in Section 5 ⚖️.

Heads up: the IPv6 specification [RFC2460] does not require or expect intermediate nodes to inspect destination options such as the ConEx Destination Option (CDO). So ConEx-aware intermediate nodes following this spec need updated extension header processing code to be able to read the destination options 🚨.

4. ConEx Destination Option (CDO) ✨

okay bestie, the CDO is a destination option that ConEx-aware senders can pop into their IPv6 datagrams 💌 its whole job is to tell ConEx-aware nodes on the path about the congestion that earlier packets in the same flow ran into, or how risky things look for congestion coming up 🔮 and it has no alignment requirements, so it can sit wherever it fits 🦋

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Option Type  | Option Length |X|L|E|C|  res  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 1: ConEx Destination Option Layout

Option Type

8-bit identifier of the type of option 🎀 it's set to 30 (0x1E), which is allocated for experimental work 🧪

Option Length

8-bit unsigned integer 🔢 it's the length of the option in octets, not counting the Option Type and Option Length fields. It's set to 1 💅

X Bit

okay so when this bit is set, the transport sender is using ConEx with this packet ✨ if it isn't set, the sender is not using ConEx with this packet 🙈

L Bit

when this bit is set, the transport sender has experienced a loss 💀

E Bit

when this bit is set, the transport sender has experienced congestion signaled using Explicit Congestion Notification (ECN) [RFC3168] 🌸

C Bit

when this bit is set, the transport sender is building up congestion credit in the audit function 💰

Reserved (res)

these four bits aren't used in the current specification 🫶 the sender sets them to zero, and the receiver just ignores them 🧚

All packets sent over a ConEx-capable TCP connection, or belonging to the same ConEx-capable flow, MUST carry the CDO 🔥 the chg bit (the third-highest-order bit) in the CDO Option Type field is set to zero, which means the CDO option is immutable 🔒 ConEx-aware network devices read the flags, but ALL network devices MUST forward the CDO unaltered 💖

The CDO SHOULD be placed as the first option in the Destination Option header, before the AH [RFC4302] and/or Encapsulating Security Payload (ESP) [RFC4303] (if present) ✨ the IPsec Authentication Header (AH) MAY be used to verify that the CDO has not been modified 🛡️

If the X bit is zero, the other three bits are undefined, so they MUST be ignored and forwarded unchanged by network nodes 🫠 an X bit of zero means the connection is ConEx-capable but this packet MUST NOT be counted when working out ConEx information in an audit function 🙅‍♀️ this can happen when no congestion feedback is (currently) available, e.g., in TCP when one endpoint has been receiving data but has only been sending pure ACKs (no user data) for a while 🍓 pure ACKs don't advance the sequence number, so the TCP endpoint receiving them can't reliably tell whether any were lost due to congestion 😭 and pure TCP ACKs can't be ECN-marked either [RFC3168] 🚫

If the X bit is set, any of the other three bits (L, E, or C) might be set too 👀 whenever one of those bits is set, the number of bytes carried by this IP packet (including the IP header that directly encapsulates the CDO and everything that IP header encapsulates) SHOULD be counted to determine congestion or credit information 📊 in IPv6, it's easy: add the number 40 (the length of the IPv6 header in bytes) to the value in the Payload Length field of the IPv6 header ✨

The credit signal represents the potential for congestion ⚡ if a congestion event happens, a matching amount of credit gets consumed, as outlined in [RFC7713] 💸 so a ConEx-enabled sender SHOULD, therefore, signal enough credit in advance of any congestion event to cover the (estimated maximum) number of lost or CE-marked bytes that could happen in that event 🌈 how big that estimate is depends on the heuristics and the aggressiveness the sender uses when choosing its sending rate (congestion control) 🧠 the absolute worst case is that every packet in flight gets lost or CE-marked, so that's the most conservative estimate of congestion risk 😱 after a congestion event, if the sender wants to take the same risk again, it just needs to replace the consumed credit, because non-consumed credit doesn't expire ⏳ for TCP, this is described in detail in [RFC7786] 🦋

If the L or E bit is set, a congestion signal (a loss or an ECN mark, respectively) was previously experienced by the same connection 🫧

In principle, all three bits (L, E, or C) might be set in the same packet 🤯 in that case, the packet size MUST be counted once for each respective ConEx information counter 🔢

If a network node extracts ConEx information from a connection, it's expected to hold that information in bytes 🫶 for example, it can compare the total number of bytes sent with the number of bytes sent with ConEx congestion marks (L or E) to figure out the current whole-path congestion level 🛣️ so a ConEx-aware node that processes the CDO MUST use the Payload Length field of the preceding IPv6 header for byte-based counting 📏 when a ratio is measured and equally sized packets can be assumed, counting packets (instead of bytes) should give the same result 🤏 but an audit function needs to know this estimate can be quite wrong if, say, differently sized packets are sent, so it isn't reliable 🙃

All remaining bits in the CDO are reserved for future use (they're currently the last four bits of the eight-bit option space) 🎁 a ConEx sender SHOULD set the reserved bits in the CDO to zero 🧸 other nodes MUST ignore these bits, and ConEx-aware intermediate nodes MUST forward them unchanged, whatever their values are 💜 they MAY log the presence of a non-zero Reserved field 📝

The CDO only applies to unicast or anycast packets (for the reasoning, see the note about item J on multicast at the end of Section 3.3 of [RFC7713]) 📮 a ConEx sender MUST NOT send a packet with the CDO to a multicast address 🚷 ConEx-capable network nodes MUST treat a multicast packet with the X flag set the same as an equivalent packet without the CDO, and they SHOULD forward it unchanged 🌊

As stated in [RFC7713] (see Section 3.3, item N on network-layer requirements), protocol specs should describe any warning or error messages relevant to the encoding 📣 and there are no warning or error messages associated with the CDO 🙌

5. Implementation in the Fast Path of ConEx-Aware Routers 🏎️

the ConEx information is encoded into a destination option so it doesn't hurt forwarding performance on non-ConEx-aware nodes along the path 💨 destination options usually aren't processed by routers, so the CDO doesn't change fast-path processing of the datagram on non-ConEx-aware routers 🙌 they aren't pushed into the slow path toward the control plane for exception processing 🐢❌

ConEx-aware nodes still need to process the CDO without seriously hurting forwarding 💅 to make that possible, ConEx-aware routers need to quickly check whether the CDO is present and process it if so 🔍 that works best when the CDO sits in a pretty predictable spot 📍 so to help forwarding on ConEx-aware routers, ConEx-aware senders that send IPv6 datagrams with the CDO SHOULD place the CDO as the first destination option in the Destination Option header 🥇

6. Tunnel Processing 🚇

as with any destination option, an ingress tunnel endpoint normally won't copy the CDO when it adds an encapsulating outer IP header 🙅‍♀️ in general, an ingress tunnel SHOULD NOT copy the CDO to the outer header, because that would change the number of bytes that get counted 🧮 however, it MAY copy the CDO to the outer header to help subsequent on-path ConEx functions see it, if the tunnel ingress and the ConEx nodes are coordinated 🤝 this trades off ConEx performance against tunnel processing performance ⚖️

an egress tunnel endpoint SHOULD ignore any CDO in the outer header when it decapsulates an outer IP header 🎀 the information in an inner CDO is always considered correct, even if it differs from the outer CDO 👑 so the decapsulator can strip the outer CDO without comparing it to the inner one 🧹 a decapsulator MAY compare the two and MAY log any case where they differ 🔎 but the packet MUST be forwarded no matter what anomaly shows up, since an outer CDO is only a performance optimization 🚀

a network node that assesses ConEx information SHOULD search through encapsulated IP headers until it finds a CDO 🕵️‍♀️ at any specific network location, the maximum search depth needed is likely to be the same for all packets between a given set of tunnel endpoints 📐

7. Compatibility with Use of IPsec 🔐

a network-based attacker could change ConEx information to trick an audit function in a downstream network into discarding packets 😤 if the endpoints use the IPsec Authentication Header (AH) [RFC2460] to detect changes to IP headers along the path, AH will also detect changes to the CDO header 🛡️ still, AH protection will rarely need to be added for ConEx, because attacks by one network on another are rare when they're traceable 🕵️ other known network-on-network attacks, like TTL expiry attacks, are more damaging to the innocent network (because the ConEx audit discards silently) and harder to trace (because TTL is meant to change, whereas the CDO is not) 💀

Section 4 specifies that the CDO is placed in the Destination Option header before the AH and/or ESP headers, so ConEx information stays in the clear if ESP is being used to encrypt other transmitted information in transport mode [RFC4301] 🙈 in general, a Destination Option header inside an IPv6 packet can be placed in one of two positions: either before the Routing header, or after the ESP/AH headers, as described in Section 4.1 of [RFC2460] 🧩 if the CDO were placed in the latter position and an ESP header was used with encryption, ConEx-aware intermediate nodes wouldn't be able to view and interpret the CDO, which would make it useless 😭

the IPv6 protocol architecture currently doesn't provide a way for new headers to be copied to the outer IP header 🙃 so if IPsec encryption is used in tunnel mode, ConEx information can't be accessed across the extent of the ESP tunnel 🚫

the destination IP stack usually won't process the CDO, so the sender can send a CDO without checking whether the receiver will understand it 🫶 the CDO MUST still be forwarded to the destination IP stack, because the destination might check the integrity of the whole packet, whether or not it understands ConEx 🔐💖

8. Mitigating Flooding Attacks by Using Preferential Drop ✨

The ideas in this section are aspirational, not essential to using ConEx for more general traffic management 💅. Still, once CDO information is present, the CDO header could optionally also be used in the data plane of any IP-aware forwarding node to help mitigate flooding attacks 🛡️.

Heads up, bestie: ConEx is an experimental protocol 🧪. Any mechanism that reacts to information from ConEx needs to be tested in experiments too. That's especially true (or extra true 😭) for the preferential drop mechanism below.

Dropping packets preferentially is a good move against flooding attacks, because ConEx-Marked packets can be assumed to already be restricted by a ConEx ingress policer, as described in [RFC7713] 🌸. So the following ConEx-based preferential dropping scheme is proposed 🎀:

If a router queue is under a very high load and has to drop arriving packets, it MAY preferentially drop packets within the same DiffServ Per-Hop Behavior (PHB), using the preference order in Table 1 (1 means drop first) 🍓. If a router does preferential drop based on ConEx, it SHOULD also support ECN marking 🌈. Preferential dropping can be tricky to implement on some hardware, but routers at the egress of a network SHOULD implement preferential drop based on ConEx markings, if nowhere else 👑. That one is stronger than the MAY above, so pay attention 🫶.

                 +----------------------+----------------+
                 |                      |   Preference   |
                 +----------------------+----------------+
                 | Not-ConEx or no CDO  | 1 (drop first) |
                 | X (but not L,E or C) |       2        |
                 | X and L,E or C       |       3        |
                 +----------------------+----------------+

                Table 1: Drop Preference for ConEx Packets

A flooding attack is basically about congestion of a resource 🌊. As load piles up on a victim, upstream queues grow, and honest sources have to pre-load packets with a higher fraction of ConEx marks 💜.

If downstream queues support ECN marking, preferential dropping gives the most benefit 🔥. The reason is that if a queue is so congested that it drops traffic, it will be CE-marking 100% of the traffic it forwards. So honest sources will be sending 100% ConEx E-marked packets, and they'll be subject to rate-limiting at an ingress policer 🎀.

Senders under malicious control have two options 😈. They can do the same as honest sources and get rate-limited at ingress, or they can understate congestion and not set the E bit 🙈.

If the preferential drop ranking is implemented on queues, those queues will hold E/L-marked traffic until last 🧚. So traffic from malicious sources will all be dropped first, automatically ✨. Either way, malicious sources cannot send more than honest sources 💖.

So ConEx-based preferential dropping, as described above, discriminates against attack traffic when it's part of the overall policing framework described in [RFC7713] 🦋.

9. Security Considerations 🔐

[RFC7713] describes the overall audit framework for making sure ConEx markings truly reflect actual path congestion 🕵️‍♀️. [CONEX-AUDIT] gives further details on handling audit signals 📋. This section focuses purely on the security of the encoding chosen for ConEx markings 🧩.

The CDO Option Type is defined with a chg bit set to zero, as described in Section 4 🎀. If IPsec AH is used, a zero chg bit causes AH to cover the CDO option, so its end-to-end integrity can be verified, as explained in Section 4 🔒.

This document specifies that the Reserved field in the CDO MUST be ignored and forwarded unchanged, even if it does not contain all zeroes 😱. The Reserved field also has to sit outside the Encapsulating Security Payload (ESP), at least in transport mode (see Section 7) 💀. That means the sender could use the Reserved field as a 4-bit-per-packet covert channel to send information to an on-path node outside the control of IPsec 👀. But a covert channel is only a concern if it can get around IPsec in tunnel mode. In tunnel mode, ESP closes the covert channel, as outlined in Section 7 🫶✨.

10. IANA Considerations 🌸

The IPv6 ConEx destination option is used for carrying ConEx markings 💖. This document uses the experimental option type 0x1E (as assigned in IANA's "Destination Options and Hop-by-Hop Options" registry), with the act bits set to 00 and the chg bit set to 0, to realize this option 🧚. No further allocation action is required from IANA at this time 🍓.

11. References 📚

11.1. Normative References

11.2. Informative References

  • [CONEX-AUDIT] Wagner, D. and M. Kuehlewind, "Auditing of Congestion Exposure (ConEx) signals", Work in Progress, draft-wagner-conex-audit-02, April 2016.
  • [HBH-HEADER] Baker, F., "IPv6 Hop-by-Hop Options Extension Header", Work in Progress, draft-ietf-6man-hbh-header-handling-03, Marcy 2016.
  • [RFC7786] Kuehlewind, M., Ed. and R. Scheffenegger, "TCP Modifications for Congestion Exposure (ConEx)", RFC 7786, DOI 10.17487/RFC7786, May 2016, <http://www.rfc-editor.org/info/rfc7786>.

Acknowledgements 🙌

The authors would like to thank David Wagner, Marcelo Bagnulo, Ingemar Johansson, Joel Halpern, John Leslie, Martin Stiemerling, Robert Sparks, Ron Bonica, Brian Haberman, Kathleen Moriarty, Bob Hinden, Ole Troan, and Brian Carpenter for the discussions that made this document better 🥰.

Authors' Addresses 💌

Suresh Krishnan Ericsson 8400 Blvd Decarie Town of Mount Royal, Quebec Canada

Email: suresh.krishnan@ericsson.com

Mirja Kuehlewind ETH Zurich

Email: mirja.kuehlewind@tik.ee.ethz.ch

Bob Briscoe Simula Research Laboratory

Email: ietf@bobbriscoe.net URI: http://bobbriscoe.net/

Carlos Ralli Ucendo Telefonica

Email: ralli@tid.es

📦 where this page comes from