RFC 8517

An Inventory of Transport-Centric Functions Provided by Middleboxes: An Operator Perspective

📅 published February 2019, from ietf

An Inventory of Transport-Centric Functions Provided by Middleboxes: An Operator Perspective ✨

Independent Submission 🎀 Informational 💅 ISSN 2070-1721 🌸 February 2019 🦋

The authors are D. Dolson, Ed., J. Snellman, M. Boucadair, Ed., and C. Jacquenet. The Orange affiliation is listed for Boucadair and Jacquenet. This is RFC 8517 💜, and it's Informational, so it's not a standard. It's an independent submission, meaning the RFC Editor published it, not the IETF stream. The header doesn't list anything it obsoletes or updates.

Abstract

okay so this doc is basically an operator's take on all the good stuff that intermediary devices can do beyond normal IP forwarding 🧚. People call these devices "middleboxes" 📦.

RFC 3234 is the taxonomy that defines middleboxes and their issues 📚. Most middleboxes poke at or change application-layer data. This document is lowkey all about the devices that watch and act on transport-layer info, especially TCP packets 👀.

Status of This Memo

This doc is not an Internet Standards Track spec. It's just published for informational purposes 🌈.

It's a contribution to the RFC Series, totally independent of any other RFC stream. The RFC Editor picked to publish it at their discretion and makes no statement about whether it's worth implementing or deploying 🫶. Anything the RFC Editor approves for publication isn't a candidate for any level of Internet Standard. See Section 2 of RFC 7841 for the details 💅.

For the current status, any errata, and how to give feedback, check https://www.rfc-editor.org/info/rfc8517 🔥.

Copyright (c) 2019 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 (https://trustee.ietf.org/license-info) as they stood on the publication date. Please read these carefully, because they describe your rights and restrictions for this document 🙈.

Table of Contents 📑

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
  1.1.  Operator Perspective  . . . . . . . . . . . . . . . . . .   3
  1.2.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   4
2.  Measurements  . . . . . . . . . . . . . . . . . . . . . . . .   5
  2.1.  Packet Loss . . . . . . . . . . . . . . . . . . . . . . .   5
  2.2.  Round-Trip Times  . . . . . . . . . . . . . . . . . . . .   6
  2.3.  Measuring Packet Reordering . . . . . . . . . . . . . . .   6
  2.4.  Throughput and Bottleneck Identification  . . . . . . . .   7
  2.5.  Congestion Responsiveness . . . . . . . . . . . . . . . .   7
  2.6.  Attack Detection  . . . . . . . . . . . . . . . . . . . .   8
  2.7.  Packet Corruption . . . . . . . . . . . . . . . . . . . .   8
  2.8.  Application-Layer Measurements  . . . . . . . . . . . . .   9
3.  Functions beyond Measurement: A Few Examples  . . . . . . . .   9
  3.1.  NAT . . . . . . . . . . . . . . . . . . . . . . . . . . .   9
  3.2.  Firewall  . . . . . . . . . . . . . . . . . . . . . . . .  10
  3.3.  DDoS Scrubbing  . . . . . . . . . . . . . . . . . . . . .  10
  3.4.  Implicit Identification . . . . . . . . . . . . . . . . .  11
  3.5.  Performance-Enhancing Proxies . . . . . . . . . . . . . .  11
  3.6.  Network Coding  . . . . . . . . . . . . . . . . . . . . .  12
  3.7.  Network-Assisted Bandwidth Aggregation  . . . . . . . . .  13
  3.8.  Prioritization and Differentiated Services  . . . . . . .  13
  3.9.  Measurement-Based Shaping . . . . . . . . . . . . . . . .  14
  3.10. Fairness to End-User Quota  . . . . . . . . . . . . . . .  14
4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
5.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
  5.1.  Confidentiality and Privacy . . . . . . . . . . . . . . .  14
  5.2.  Active On-Path Attacks  . . . . . . . . . . . . . . . . .  15
  5.3.  Improved Security . . . . . . . . . . . . . . . . . . . .  15
6.  Informative References  . . . . . . . . . . . . . . . . . . .  16
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  21
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  21

1. Introduction ✨

From [RFC3234], "A middlebox is defined as any intermediary device performing functions other than the normal, standard functions of an IP router on the datagram path between a source host and destination host." 🧚

Middleboxes are usually (but not exclusively) deployed where they can observe bidirectional traffic flows 👀. These spots are typically where leaf networks connect to the Internet, for example:

  • Where a residential or business customer connects to its service provider(s), which may include multihoming 🏠.
  • On the Gi interface where a Gateway General Packet Radio Service (GPRS) Support Node (GGSN) connects to a Packet Data Network (PDN) (Section 3.1 of [RFC6459]) 📡.

For the purposes of this document, and to stay consistent with the definition in RFC 3234, middlebox functions may be found in routers and switches as well as in dedicated devices 💜.

This document itemizes a variety of features provided by middleboxes, and by ad hoc analysis that operators do with packet analyzers 🔍.

Many of the techniques here require stateful analysis of transport streams. A generic state machine is described in [PATH-STATE] 🧠.

This doc summarizes an operator's perception of the benefits middleboxes may provide. The main goal is to give the Internet community info to help them understand what might be gained or lost by decisions that affect (or are affected by) middlebox operation, especially when designing new transport protocols 🦋. See Section 1.1 for more details.

1.1. Operator Perspective 🎀

Network operators are often the first ones called when applications break 😭. The reports usually describe application behavior, not packet behavior. So it's not surprising that operators, who want to be helpful, want some visibility into flow information. That way they can see how the problem flows are doing, and how the other flows are doing too 💅.

Advanced service functions, like Network Address Translators (NATs), firewalls, and so on [RFC7498], are widely used for things like IP address sharing, firewalling, avoiding covert channels, and detecting and protecting against the ever-increasing Distributed Denial of Service (DDoS) attacks 🛡️. For example, environment-specific designs may need a number of service functions, like the ones needed at the Gi interface of a mobile infrastructure [USE-CASE] 📱.

These sophisticated service functions live in the network, but also in service platforms or intermediate entities, such as Content Delivery Networks (CDNs) 🌐. Network maintenance and diagnostics get complicated, especially when responsibility is shared among different players 🙃.

Network Providers are under pressure to deliver differentiated services as a competitive business advantage. They also have to master the complexity of applications, keep evaluating the impacts on middleboxes, and improve customers' quality of experience 💖.

Despite all that complexity, removing those service functions isn't an option, because they address constraints that are often typical of the current (and changing) Internet 🌸. Operators have to deal with constraints like global IPv4 address depletion, and they have to support a plethora of services with different requirements for QoS, security, robustness, and more ✨.

1.2. Scope 🦋

Lots of middleboxes observe and manipulate application-layer content (for example, session boarder controllers [RFC5853]). Those are out of scope here, because the aim is to describe middleboxes that use transport-layer features 🚫. [RFC8404] describes how pervasive encryption of application-layer data affects network monitoring, protecting, and troubleshooting 🔐.

This document isn't meant to recommend (or prohibit) middlebox deployment. Many operators have found that the value middleboxes provide outweighs the added cost and complexity. This doc tries to give that perspective as a reference for discussions about protocol design trade-offs ⚖️.

This document isn't meant to discuss issues related to middleboxes either. Those issues are well known and recorded in existing documents such as [RFC3234] and [RFC6269] 📖. What this doc does is explain the motivations that lead operators to enable these functions even with the complications 🧐.

This document takes an operator perspective: measuring and managing transport connections benefits both parties. The end user gets a better quality of experience, and the network operator improves resource usage. The first is a consequence of the second 💜.

This document doesn't discuss whether exposing some data to on-path devices for network-assistance purposes can be done with in-band or out-of-band mechanisms 🙅‍♀️.

2. Measurements 📊

Network devices, whether on-path or off-path, can make a number of measurements 👀. Automated systems or manual network troubleshooting (for example, with packet-analysis tools) can use these measurements 🛠️. The automated systems come in two types: 1) monitoring systems that compute performance indicators for single connections or aggregates of connections, and generate aggregated reports from them; and 2) active systems that also decide how to handle packet flows based on those performance indicators 🤖.

Long-term trends in these measurements can help an operator with capacity planning 📈.

Short-term anomalies revealed by these measurements can identify network breakages, attacks in progress, or misbehaving devices and applications 🚨.

2.1. Packet Loss 💧

It's super useful for an operator to be able to detect and isolate packet loss in a network 🔍.

Network problems and underprovisioning can be detected if packet loss is measurable 💡. TCP packet loss can be detected by observing gaps in sequence numbers, retransmitted sequence numbers, and selective acknowledgement (SACK) options [RFC2018] 🧩. Packet loss can be detected per direction 🧭.

Gaps indicate loss upstream of the traffic observation point, and retransmissions indicate loss downstream of it 🔼🔽. SACKs can be used to detect either upstream or downstream packet loss. Some care is needed, though, so that packet reordering isn't misidentified as packet loss. SACKs can also help tell upstream losses apart from downstream ones 🤔.

Packet-loss measurements on both sides of the measurement point are an important part of precisely diagnosing insufficiently dimensioned devices or links 🔧. Packet losses are also one of the two main ways congestion shows up. The other is queuing delay, or Explicit Congestion Notification (ECN) [RFC3168]. That's why packet loss is an important measurement for any middlebox that needs to make traffic-handling decisions based on observed levels of congestion 🚦💅

Stay tuned, bestie, part 2 is coming with the rest of Section 2 and beyond! 💜

2.2. Round-Trip Times 🦋

Okay bestie, measuring partial-path round-trip times (RTTs) is so important for diagnosing network drama 😭 like abnormal latency and abnormal packet loss. If you can tell whether latency is bad on one side of the observation point or the other, you get more info than either endpoint can see, because endpoints can only observe full RTTs 💅.

For example, a TCP packet stream can measure the RTT on each side of the measurement point ✨. During the connection handshake, the SYN, SYN/ACK, and ACK timings can set a baseline RTT in each direction. Once the connection is up, the RTT between the server and the measurement point can only be reliably determined using TCP timestamps [RFC7323]. On the side between the measurement point and the client, the exact timing of data segments and ACKs can be used instead. For this latter method to be accurate when packet loss is present, the connection must use selective acknowledgements.

In lots of networks, congestion shows up as increasing packet queuing, and congestion-induced packet loss only happens in extreme cases 🌧️. RTTs also show up as a much smoother signal than the discrete packet-loss events, so they're a slay way to spot individual subscribers for whom the network is a bottleneck at a given time 🎀. They also help find geographical sites, like cellular towers, that are experiencing large-scale congestion 📡.

The main limit of RTT measurement as a congestion signal is the difficulty of reliably distinguishing between the data segments being queued versus the ACKs being queued. 🙈

2.3. Measuring Packet Reordering 🌀

If a network is reordering packets of transport connections, maybe because of an Equal-Cost Multipath (ECMP) misconfiguration (described in [RFC2991] and [RFC7690], for example), the endpoints may react as if packet loss is happening. They might retransmit packets or reduce their forwarding rates 😩. So a network operator really wants the ability to diagnose packet reordering 🔍.

For TCP, packet reordering can be detected by observing TCP sequence numbers per direction. See, for example, the standard packet-reordering metrics in [RFC4737] and the informational metrics in [RFC5236] 📚.

2.4. Throughput and Bottleneck Identification 🚦

Throughput to or from an IP address can be measured without transport-layer measurements, but the transport layer gives you clues about what the endpoints were actually trying to do 🕵️‍♀️.

One way to quickly rule out the network as the bottleneck during troubleshooting is to check whether the speed is limited by the endpoints 💖. For example, the connection speed might instead be limited by suboptimal TCP options, the sender's congestion window, the sender temporarily running out of data to send, the sender waiting for the receiver to send another request, or the receiver closing the receive window.

This data is also useful for middleboxes used to measure network quality of service 📊. Connections, or portions of connections, that are limited by the endpoints don't give an accurate measure of the network's speed. They can be discounted or completely excluded in those analyses 🙅‍♀️.

2.5. Congestion Responsiveness 🌊

Congestion control mechanisms keep evolving, and it's giving innovation 🚀. Tools exist that can interpret protocol sequence numbers (for example, from TCP or RTP) to infer the congestion response of a flow. Operators can use these tools to understand the impact of specific transport protocols on other traffic sharing their network 🫶. For example, packet sequence numbers can be analyzed to see whether an application flow backs off its load in the face of persistent congestion (as TCP does). That tells you whether the behavior is appropriate for sharing limited network capacity 🍓.

These tools can also help determine whether mechanisms are needed in the network to stop flows from grabbing excessive network capacity under severe congestion. For instance, you could deploy rate limiters or network transport circuit breakers [RFC8084] 🛑.

2.6. Attack Detection 🚨

When an application or network resource is under attack, it's useful to identify that situation from the network perspective, upstream of the attacked resource 👀.

Detection methods tend to be proprietary, but attack detection from within the network may include:

  • Identifying uncharacteristic traffic volumes or sources;
  • Identifying congestion, possibly using techniques in Sections 2.1 and 2.2;
  • Identifying incomplete connections or transactions, from attacks that attempt to exhaust server resources;
  • Fingerprinting based on whatever available fields are determined to be useful in discriminating an attack from desirable traffic.

Two trends in protocol design make attack detection harder 😤:

  • The desire to encrypt transport-layer fields;
  • The desire to avoid statistical fingerprinting by adding entropy in various forms.

Those approaches are great for privacy 🔐, but they may hinder attack detection 💀.

2.7. Packet Corruption 🧩

One notable source of packet loss is packet corruption 😵. This corruption generally isn't detected until the endpoint validates the checksums and drops the packet. So finding the exact location where packets are lost isn't enough when troubleshooting networks 🙃. An operator would like to find out where packets are being corrupted 🎯. IP and TCP checksum verification lets a measurement device correctly tell apart upstream packet corruption from normal downstream packet loss ✨.

Transport protocol designers should consider whether a middlebox will be able to detect corrupted or tampered packets 🧐.

2.8. Application-Layer Measurements 📱

Information about network health can also be gleaned from application-layer diagnosis, such as:

  • DNS response times and retransmissions calculated by correlating answers to queries;
  • Various protocol-aware voice and video quality analyses.

Could this type of information be provided in a transport layer? 🤔

3. Functions beyond Measurement: A Few Examples 🎭

This section is about features provided by on-path devices that go beyond measurement by modifying, discarding, delaying, or prioritizing traffic 🪄.

3.1. NAT 🏠

Network Address Translators (NATs) let multiple devices share a public address by dividing the transport-layer port space among the devices 🧃.

NAT behavior recommendations are found for UDP in BCP 127 [RFC4787] and for TCP in BCP 142 [RFC7857] 📝.

To support NAT, there must be transport-layer port numbers that can be modified by the NAT. Note that required fields (for example, port numbers) are visible in all IETF-defined transport protocols 👁️.

The application layer must not assume the port number was left unchanged (for example, by including it in a checksum or signing it) ⚠️.

Address sharing is also used in the context of IPv6 transition 🌉. For example, DS-Lite Address Family Transition Router (AFTR) [RFC6333], NAT64 [RFC6146], or A+P [RFC7596][RFC7597] are features enabled in the network to allow IPv4 service continuity over an IPv6 network 💫.

Further, because of some multihoming considerations, some enterprises may enable IPv6 prefix translation by means of IPv6-to-IPv6 Network Prefix Translation (NPTv6) [RFC6296] 🌈.

3.2. Firewall 🧱

Firewalls are pervasive and essential components that inspect incoming and outgoing traffic 🛡️. They're usually the cornerstone of a security policy enforced in end-user premises and other locations. They provide strict guarantees about which traffic may enter or leave those premises, and about which networks and portions of the Internet end users with different clearance levels can access 🔒.

An important aspect of a firewall policy is differentiating internally initiated communications from externally initiated ones 🚪.

For TCP, this is easily done by tracking the TCP state machine. Furthermore, the ending of a TCP connection is indicated by RST or FIN flags 🏁.

For UDP, the firewall can be opened if the first packet comes from an internal user. But closing is generally done by an idle timer of arbitrary duration, which might not match the expectations of the application ⏱️.

Simple IPv6 firewall capabilities for customer premises equipment (both stateless and stateful) are described in [RFC6092] 🏡.

A firewall works better when it can observe the protocol state machine, which is described generally by "Transport-Independent Path Layer State Management" [PATH-STATE] 🧠.

3.3. DDoS Scrubbing 🧽

In the context of a DDoS attack, the purpose of a scrubber is to discard attack traffic while permitting useful traffic 🫧. Such a mitigator is described in [DOTS].

When attacks hit constrained resources, some traffic will be discarded before reaching the intended destination 😮‍💨. A user gets a better experience and a server runs more efficiently if a scrubber can discard attack traffic and leave room for legitimate traffic 💪.

Scrubbing must be provided by an on-path network device, because neither endpoint of a legitimate connection has any control over the source of the attack traffic 🙅‍♀️.

Source-spoofed DDoS attacks can be mitigated at the source using BCP 38 [RFC2827], but it's more difficult if source address filtering can't be applied 🫠.

In contrast to devices in the core of the Internet, middleboxes statefully observing bidirectional transport connections can reject source-spoofed TCP traffic. They do this based on the inability to provide sensible acknowledgement numbers to complete the three-way handshake. Obviously, this requires middlebox visibility into a transport-layer state machine 👑.

Middleboxes may also scrub on the basis of statistical classification, testing how likely a given packet is to be legitimate 📊. As protocol designers add more entropy to headers and lengths, this test becomes less useful, and the best scrubbing strategy becomes random drop 🎲.

3.4. Implicit Identification 🪪

To enhance the end user's quality of experience, some operators deploy implicit identification features. These rely on correlating network-related information to access some local services 🌟. For example, service portals run by some operators may be accessed immediately by end users, without any explicit identification, for the sake of improved service availability ⚡. This works thanks to on-path devices that inject appropriate metadata. A remote server can use that metadata to enforce per-subscriber policies 🧚. The information can be injected at the application layer or at the transport layer (when an address-sharing mechanism is in use) 🧩.

An experimental implementation using a TCP option is described in [RFC7974] 🧪.

For the intended use of implicit identification, it is more secure to have a trusted middlebox mark this traffic than to trust end-user devices. 🔐💜

3.5. Performance-Enhancing Proxies

okay so Performance-Enhancing Proxies (PEPs) 💅✨ are basically middleboxes that make things faster in some networks by fiddling with packet spacing or sending local acknowledgements 🚀. You mostly see them in satellite and cellular networks 🛰️. The Transport-Layer PEPs bit is covered in Section 2.1.1 of [RFC3135] 🎀.

PEPs let the congestion control algorithm get deployed centrally, and it's usually one that's more suited to the specific network 🧠. It's most often delay-based congestion control, and that's giving main character energy 👑. Fancier TCP PEPs treat all of a single end user's TCP connections as one unit 🫶, which improves fairness and lets them react faster when network conditions change ⚡. Like, it was reported that splitting the TCP connections in some network accesses can result in a halved page downloading time [ICCRG] 😭🔥.

Local acknowledgements from PEPs speed up TCP slow start by splitting the effective latency 🦋, and they let retransmissions happen at the PEP instead of at the actual sender 🔁. The PEP can also keep a local buffer that matches the actual network conditions 🌈, which is iconic because the real endpoints often send too much or too little 💀.

A PEP function needs transport-layer fields that let chunks of data be identified (e.g., TCP sequence numbers) 🔢, acknowledgements be identified (e.g., TCP ACK numbers) 🧾, and acknowledgements be created from the PEP 🌸.

Okay but PEPs are only useful in some types of networks 🙈. They're really useful when the congestion control strategies of the endpoints are wrong for the network connecting them 🎯. That being said, poor design can make performance worse when PEPs are deployed 😬. Not me saying "design it right" 💖.

3.6. Network Coding

Network Coding is a technique for improving transmission performance over low-bandwidth, long-latency links such as some satellite links 🛰️🌸. Coding can involve lossless compression and/or adding redundancy to headers and payload 🗜️. A Network Coding Taxonomy is provided by [RFC8406] 📚, and an example of end-to-end coding is FECFRAME [RFC6363] 🧚. It's typically deployed with network-coding gateways at each end of those links, with a network-coding tunnel between them via the slow/lossy/long-latency links 🚇✨.

Network-coding implementations may be specific to TCP, taking advantage of known properties of the protocol 🫶.

The network-coding gateways may use some PEP techniques too, like creating acknowledgements of queued data, removing retransmissions, and pacing data rates to reduce queue oscillation 🎀💅.

The interest in more network coding in some specific networks is discussed in [SATELLITES] 🌈.

Note: This is not to be confused with transcoding, which performs lossy compression on transmitted media streams and is not in scope for this document 🙅‍♀️. Different thing, bestie!

3.7. Network-Assisted Bandwidth Aggregation

The Hybrid Access Aggregation Point is a middlebox that lets customers aggregate the bandwidth of multiple access technologies 💜.

One of the approaches uses Multipath TCP (MPTCP) proxies [TCP-CONVERT] to forward traffic along multiple paths 🛣️. The MPTCP proxy works at the transport layer while sitting in the operator's network 🏢.

Supporting multipath transport on communicating hosts is still a privileged target design 👑, so such hosts can directly use the resources that a variety of access networks provide 🌟. Nevertheless, network operators don't control end hosts 🙃, and MPTCP support by content servers is still marginal 😭.

Network-assisted MPTCP deployment models are designed to make it easier to adopt MPTCP for establishing multipath communications, without making any assumption about whether the communicating peers support MPTCP 🦋. These models rely on MPTCP Conversion Points (MCPs) that act on behalf of hosts, so the hosts can take advantage of establishing communications over multiple paths [TCP-CONVERT] 🧩.

Note there are cases when end-to-end MPTCP cannot be used even though both client and server are MPTCP-compliant 🤯. An MPTCP proxy can provide multipath utilization in these cases 💖. Examples of such cases are listed below:

  1. The use of private IPv4 addresses in some access networks. Typically, additional subflows cannot be added to the MPTCP connection without the help of an MCP 🏠.
  2. The assignment of IPv6 prefixes only by some networks. If the server is IPv4-only, IPv6 subflows cannot be added to an MPTCP connection established with that server, by definition 🙈.
  3. Subscription to some service offerings is subject to volume quota 📉.

3.8. Prioritization and Differentiated Services

Bulk traffic may be served with a higher latency than interactive traffic with no reduction in throughput 🐢. This fact lets a middlebox improve response times in interactive applications by prioritizing, policing, or remarking interactive transport connections differently from bulk-traffic transport connections 🚦✨. For example, gaming traffic may be prioritized over email or software updates 🎮. Configuration guidelines for Diffserv service classes are discussed in [RFC4594] 📋.

Middleboxes may identify different classes of traffic by inspecting multiple layers of header and length of payload 🔍💅.

3.9. Measurement-Based Shaping

Basic traffic shaping doesn't need any transport-layer information 🙌. All it needs is a way of mapping each packet to a traffic shaper quota 🗂️. For example, there may be a rate limit per 5-tuple or per subscriber IP address 🎯. However, fixed traffic shaping rules are wasteful, because they end up rate-limiting traffic even when the network has free resources available 😤.

More advanced traffic-shaping devices use the transport-layer metrics described in Section 2 to detect congestion on either a per-site or a per-user level 📊, and they use different traffic-shaping rules when congestion is detected [RFC3272] 🔥. This type of device can overcome limitations of downstream devices that behave poorly (e.g., by excessive buffering or suboptimally dropping packets) 🛠️. Iconic problem-solving, no cap 🫡.

3.10. Fairness to End-User Quota

Several service offerings rely on a volume-based charging model (e.g., volume-based data plans offered by cellular providers) 📱. Operators may help end users conserve their data quota by deploying on-path functions that shape traffic that would otherwise be aggressively transferred 🌸.

For example, a fast download of a video that won't be viewed completely by the subscriber may quickly exhaust the data quota 🎬. Limiting the video download rate conserves quota for the benefit of the end user 💜. Also, discarding unsolicited incoming traffic prevents the user's quota from being unfairly exhausted 🛡️.

  1. IANA Considerations ✨

This document has no IANA actions 🌷.

  1. Security Considerations 🔐

5.1. Confidentiality and Privacy

This document intentionally excludes middleboxes that observe or manipulate application-layer data 🙅‍♀️. The measurements and functions described in this document can all be implemented without violating confidentiality [RFC6973] 🫶. However, there is always the question of whether the fields and packet properties used to achieve operational benefits may also be used for harm 😳.

In particular, the question is what confidentiality is lost by exposing transport-layer fields beyond what can be learned by observing IP-layer fields 👀:

  • Sequence numbers: an observer can learn how much data is transferred 📦.
  • Start/Stop indicators: an observer can count transactions for some applications 🔢.
  • Device fingerprinting: an observer may be more easily able to identify a device type when different devices use different default field values or options 📱🕵️‍♀️.

5.2. Active On-Path Attacks

An on-path attacker being able to observe sequence numbers or session identifiers may make it easier to modify or terminate a transport connection 😱. For example, observing TCP sequence numbers allows generation of a RST packet that terminates the connection 💀. However, signing transport fields softens this attack 🛡️. The attack and solution are described for the TCP authentication option [RFC5925] 🔏. Still, an on-path attacker can also drop the traffic flow 🚫.

5.3. Improved Security

Network maintainability and security can be improved by providing firewalls and DDoS mechanisms with some information about transport connections 🏰. In contrast, it would be very difficult to secure a network in which every packet appears unique and filled with random bits (from the perspective of an on-path device) 🌀.

Some features that help mitigate or filter attacks thanks to a network-assisted mechanism will therefore improve security 🔥, e.g., by means of Distributed-Denial-of-Service Open Threat Signaling (DOTS) [DOTS-SIGNAL] 🦸‍♀️.

6. Informative References ✨

okay bestie, here are all the receipts 🧾💅 every single reference, with every detail intact

[DOTS] Mortensen, A., Andreasen, F., Reddy, T., Compton, R., and N. Teague, "Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture", Work in Progress, draft-ietf-dots-architecture-07, September 2018.

[DOTS-SIGNAL] Reddy, T., Boucadair, M., Patil, P., Mortensen, A., and N. Teague, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification", Work in Progress, draft-ietf-dots-signal-channel-25, September 2018.

[ICCRG] Kuhn, N., "MPTCP and BBR performance over Internet satellite paths", IETF 100, 2017, https://datatracker.ietf.org/meeting/100/materials/slides-100-iccrg-mptcp-and-bbr-performance-over-satcom-links-00 🛰️

[PATH-STATE] Kuehlewind, M., Trammell, B., and J. Hildebrand, "Transport-Independent Path Layer State Management", Work in Progress, draft-trammell-plus-statefulness-04, November 2017. 🌸

[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, DOI 10.17487/RFC2018, October 1996, https://www.rfc-editor.org/info/rfc2018.

[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, https://www.rfc-editor.org/info/rfc2827.

[RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and Multicast Next-Hop Selection", RFC 2991, DOI 10.17487/RFC2991, November 2000, https://www.rfc-editor.org/info/rfc2991.

[RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. Shelby, "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations", RFC 3135, DOI 10.17487/RFC3135, June 2001, https://www.rfc-editor.org/info/rfc3135.

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

[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, https://www.rfc-editor.org/info/rfc3234.

[RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. Xiao, "Overview and Principles of Internet Traffic Engineering", RFC 3272, DOI 10.17487/RFC3272, May 2002, https://www.rfc-editor.org/info/rfc3272.

[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, DOI 10.17487/RFC4594, August 2006, https://www.rfc-editor.org/info/rfc4594.

[RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S., and J. Perser, "Packet Reordering Metrics", RFC 4737, DOI 10.17487/RFC4737, November 2006, https://www.rfc-editor.org/info/rfc4737.

[RFC4787] Audet, F., Ed. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 2007, https://www.rfc-editor.org/info/rfc4787.

[RFC5236] Jayasumana, A., Piratla, N., Banka, T., Bare, A., and R. Whitner, "Improved Packet Reordering Metrics", RFC 5236, DOI 10.17487/RFC5236, June 2008, https://www.rfc-editor.org/info/rfc5236.

[RFC5853] Hautakorpi, J., Ed., Camarillo, G., Penfield, R., Hawrylyshen, A., and M. Bhatia, "Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments", RFC 5853, DOI 10.17487/RFC5853, April 2010, https://www.rfc-editor.org/info/rfc5853.

[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, https://www.rfc-editor.org/info/rfc5925.

[RFC6092] Woodyatt, J., Ed., "Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service", RFC 6092, DOI 10.17487/RFC6092, January 2011, https://www.rfc-editor.org/info/rfc6092.

[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, April 2011, https://www.rfc-editor.org/info/rfc6146.

[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, DOI 10.17487/RFC6269, June 2011, https://www.rfc-editor.org/info/rfc6269.

[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, https://www.rfc-editor.org/info/rfc6296.

[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, https://www.rfc-editor.org/info/rfc6333.

[RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error Correction (FEC) Framework", RFC 6363, DOI 10.17487/RFC6363, October 2011, https://www.rfc-editor.org/info/rfc6363.

[RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)", RFC 6459, DOI 10.17487/RFC6459, January 2012, https://www.rfc-editor.org/info/rfc6459.

[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, https://www.rfc-editor.org/info/rfc6973.

[RFC7323] Borman, D., Braden, B., Jacobson, V., and R. Scheffenegger, Ed., "TCP Extensions for High Performance", RFC 7323, DOI 10.17487/RFC7323, September 2014, https://www.rfc-editor.org/info/rfc7323.

[RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for Service Function Chaining", RFC 7498, DOI 10.17487/RFC7498, April 2015, https://www.rfc-editor.org/info/rfc7498.

[RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. Farrer, "Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, July 2015, https://www.rfc-editor.org/info/rfc7596.

[RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., Murakami, T., and T. Taylor, Ed., "Mapping of Address and Port with Encapsulation (MAP-E)", RFC 7597, DOI 10.17487/RFC7597, July 2015, https://www.rfc-editor.org/info/rfc7597.

[RFC7690] Byerly, M., Hite, M., and J. Jaeggli, "Close Encounters of the ICMP Type 2 Kind (Near Misses with ICMPv6 Packet Too Big (PTB))", RFC 7690, DOI 10.17487/RFC7690, January 2016, https://www.rfc-editor.org/info/rfc7690.

[RFC7857] Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar, S., and K. Naito, "Updates to Network Address Translation (NAT) Behavioral Requirements", BCP 127, RFC 7857, DOI 10.17487/RFC7857, April 2016, https://www.rfc-editor.org/info/rfc7857.

[RFC7974] Williams, B., Boucadair, M., and D. Wing, "An Experimental TCP Option for Host Identification", RFC 7974, DOI 10.17487/RFC7974, October 2016, https://www.rfc-editor.org/info/rfc7974.

[RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, https://www.rfc-editor.org/info/rfc8084.

[RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of Pervasive Encryption on Operators", RFC 8404, DOI 10.17487/RFC8404, July 2018, https://www.rfc-editor.org/info/rfc8404.

[RFC8406] Adamson, B., Adjih, C., Bilbao, J., Firoiu, V., Fitzek, F., Ghanem, S., Lochin, E., Masucci, A., Montpetit, M-J., Pedersen, M., Peralta, G., Roca, V., Ed., Saxena, P., and S. Sivakumar, "Taxonomy of Coding Techniques for Efficient Network Communications", RFC 8406, DOI 10.17487/RFC8406, June 2018, https://www.rfc-editor.org/info/rfc8406.

[SATELLITES] Kuhn, N. and E. Lochin, "Network coding and satellites", Work in Progress, draft-irtf-nwcrg-network-coding-satellites-02, November 2018.

[TCP-CONVERT] Bonaventure, O., Boucadair, M., Gundavelli, S., and S. Seo, "0-RTT TCP Convert Protocol", Work in Progress, draft-ietf-tcpm-converters-04, October 2018.

[USE-CASE] Napper, J., Stiemerling, M., Lopez, D., and J. Uttaro, "Service Function Chaining Use Cases in Mobile Networks", Work in Progress, draft-ietf-sfc-use-case-mobility-08, May 2018.

Acknowledgements 🫶

shoutout to the squad who reviewed this and dropped suggestions 💖 the authors are so grateful, no cap: Brian Trammell, Brian Carpenter, Mirja Kuehlewind, Kathleen Moriarty, Gorry Fairhurst, Adrian Farrel, and Nicolas Kuhn 🌈

Authors' Addresses 🎀

the people who wrote it, and how to reach them 💌

David Dolson (editor)

Email: ddolson@acm.org


Juho Snellman

Email: jsnell@iki.fi


Mohamed Boucadair (editor)
Orange
4 rue du Clos Courtel
Rennes  35000
France

Email: mohamed.boucadair@orange.com


Christian Jacquenet
Orange
4 rue du Clos Courtel
Rennes  35000
France

Email: christian.jacquenet@orange.com
📦 where this page comes from