RFC 8558

Transport Protocol Path Signals

📅 published April 2019, from ietf

RFC 8558: Transport Protocol Path Signals ✨

  • Stream: Internet Architecture Board (IAB) 👑
  • Editor: T. Hardie, Ed. 💅
  • Date: April 2019 🌸
  • Category: Informational 🦋
  • ISSN: 2070-1721 🎀
  • Obsoletes / Updates: this title block doesn't list any 🫶

Abstract

okay bestie, this doc is all about the signals that on-path elements (the network boxes sitting between the two endpoints) pick up from transport protocols 👀. The big contrast is implicit vs explicit signals. TCP's state machine is the main example: it uses a bunch of well-known messages that get sent in the clear, so anyone on the path can see them and treat them as signals 🔍. But when a transport doesn't send those messages in the clear, the on-path elements just... lose those signals 😭. A lot of the time, that's exactly the goal, because the people moving the messages into confidential channels want that info hidden 🙈. So if the endpoints actually want the network along the path to get these signals, this doc recommends using explicit signals instead 💖.

Status of This Memo

This document is not an Internet Standards Track specification; it is published for informational purposes 🧚.

This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not candidates for any level of Internet Standard; see Section 2 of RFC 7841 💜.

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

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) 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 ....................................................3
   2. Signal Types Inferred ...........................................4
      2.1. Session Establishment ......................................4
           2.1.1. Session Identity ....................................4
           2.1.2. Routability and Intent ..............................4
           2.1.3. Flow Stability ......................................5
           2.1.4. Resource Requirements ...............................5
      2.2. Network Measurement ........................................5
           2.2.1. Path Latency ........................................5
           2.2.2. Path Reliability and Consistency ....................5
   3. Options .........................................................5
      3.1. Do Not Restore These Signals ...............................6
      3.2. Replace These with Network-Layer Signals ...................6
      3.3. Replace These with Per-Transport Signals ...................6
      3.4. Create a Set of Signals Common to Multiple Transports ......6
   4. Recommendation ..................................................7
   5. IANA Considerations .............................................8
   6. Security Considerations .........................................8
   7. Informative References ..........................................9
   IAB Members at the Time of Approval ...............................10
   Acknowledgements ..................................................10
   Author's Address ..................................................10

1. Introduction 🌷

Okay so this doc digs into the signals on-path elements see when they peek at transport protocols, and it compares implicit signals with explicit ones 🔎. TCP's state machine is the classic example: it runs on a series of well-known messages that go out in the clear. Since those messages are visible to network elements sitting on the path between the two nodes that set up the connection, those elements end up using them as signals all the time 💅. The whole Internet is ideally built on end-to-end protocols [RFC1958], but there are cases, like Network Address Translators [RFC3234], where some functions are usually handled by on-path network elements anyway 🫶. When a transport doesn't send these messages in the clear, the on-path elements are just missing those signals. Often, removing them is intentional from the folks moving the messages into confidential channels 🙈. And if the endpoints want the network elements along the path to actually get these signals, this document recommends using explicit signals 💖.

The way on-path elements read TCP [RFC0793] is a great example of implicit signal usage 🦋. TCP uses cleartext handshake messages to set up, keep up, and tear down connections. Those handshake messages are mainly there to build state between the two communicating nodes, but they're also visible to network elements along the path, so certain elements treat them as signals about their own jobs 👀.

Picture a firewall. It might add a rule letting traffic from a specific host and port into its network when a host already inside the network started the connection 🧱. Later it removes that rule once the communication is over. With TCP, the firewall sets up that pinhole rule when it sees the initial TCP SYN acknowledgement, and then removes it when it sees a RST or a FIN and ACK exchange 🌈. The fun part: the firewall doesn't rewrite a single thing in the TCP packet. It just opens a return path that would otherwise have been blocked ✨.

When a transport encrypts the fields it uses for state mechanics, those signals stop being accessible to path elements. How the path element behaves then depends on which signal is missing, on the default behaviour the path element's administrator configured, and on the security posture of the network as a whole 🚨.

2. Signal Types Inferred 🧠

The list below covers signals that can be inferred from transport state messages, including ones exchanged during session establishment and ones that come from the ongoing flow 🌊.

Some of these come from directly looking at packet sequences, like using a sequence number gap pattern to infer network reliability 🕵️‍♀️. Others come from association, like inferring network latency by timing the packet inter-arrival times of a flow ⏱️.

This list is not exhaustive, and it isn't the full set of effects caused by encrypting data and metadata in flight 🙃. Also, because these are derived by inference, they don't include any path signals that wouldn't matter to the endpoint state machines. Honestly, an inference-based system can't send those signals anyway 💀.

2.1. Session Establishment 💕

One of the most basic inferences from examining transport state is that a packet is part of an ongoing flow. In other words, an established session keeps going until messages come in that end it. Path elements can then make smaller inferences related to that session 🎀.

2.1.1. Session Identity 🪪

Path elements that track session establishment will typically create a session identity for the flow, usually from a tuple of the visible information in the packet headers. That identity is then used to attach other information to the flow 📎.

2.1.2. Routability and Intent 🗺️

Another common inference from session establishment is that the two communicating hosts can each reach the other and both want the conversation to keep going 💬. The firewall example above is a consequence of that inference: since the internal host started the connection, it's assumed to want return traffic, and that's what justifies the pinhole 🙌.

Some other on-path elements assume that a host which asked to talk to a remote address has authorised incoming communication from any other host (for example, Endpoint-Independent Mapping or Endpoint-Independent Filtering [RFC7857]). That's the default behaviour in Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64), for instance 🌸.

2.1.3. Flow Stability 🛤️

Some on-path devices that handle load-sharing or load-balancing may be told to keep the same path for a given flow. Otherwise they'd spread the packets of one flow across multiple paths, and that can cause packets in the flow to arrive out of order 🌀.

2.1.4. Resource Requirements 🔋

Another common inference is that the session is going to need network resources. Those might be requirements inside the network element itself, like table entry space for a firewall or NAT. They might also be communicated by the network element to other systems. On networks that use resource reservations, this could mean reserving radio air time, energy, or network capacity ⚡.

2.2. Network Measurement 📊

Some network elements also watch transport messages so they can measure the paths flows use on their network 📡. The measurements listed below are illustrative, not exhaustive 💜.

2.2.1. Path Latency 🐢

There are a few ways a network element can measure path latency from transport messages, but two common ones are looking at exposed timestamps and associating sequence numbers with a local timer ⏳. These measurements can only ever cover the portion of the path between the system that assigned the timestamp or sequence number and the network element 📐.

2.2.2. Path Reliability and Consistency 🧩

A network element can also measure how reliable a particular path is by looking at sessions that expose sequence numbers. Retransmissions and gaps then get tied to the path segments where they might have happened 🔧.

3. Options 🎨

The options below are alternatives that optimise very different things. Even though this doc reaches a preliminary conclusion, it's meant to kick off a discussion of those trade-offs, and any discussion of them must be understood as preliminary 💭.

3.1. Do Not Restore These Signals 🙅‍♀️

Of course it's always possible to do nothing 😌. The transport messages weren't necessarily meant for on-path network elements to consume, and encrypting them so they aren't visible may be seen by some as a benefit 🔐. Each network element then treats packets without those visible elements according to its own defaults. Experience with this isn't extensive yet, but one consequence has been that state tables for these flows are generally not kept as long as those for flows whose sessions can be identified 🫠. So heartbeat traffic has to be maintained to stop any bindings (for example, NAT or firewall ones) from expiring early 💓. When those bindings aren't kept, methods like a QUIC connection-id [QUIC] may be needed so load balancers or other systems can keep a flow's path pointed at the right peer 🎯.

3.2. Replace These with Network-Layer Signals 🛰️

It would be possible to swap these implicit signals for explicit signals at the network layer 🌐. IPv4 has relatively few facilities for this, but IPv6 hop-by-hop headers [RFC7045] might suit the purpose 🎁. Further examination of how deployable these headers are may be required 🔍.

3.3. Replace These with Per-Transport Signals 🦋

okay so it's totally possible to swap these implicit signals out for signals built for specific transports, just like the first batch was mostly derived from TCP 💅. ngl there's a risk here, though: the first transport that builds these might get reused for a bunch of stuff way outside its original purpose, just because it gets through NATs and firewalls better than everything else 💀. if people do it on purpose, planning to reuse the pieces in other transports, the risk of ossification might be a teeny bit lower 🫶.

3.4. Create a Set of Signals Common to Multiple Transports 🧚

several proposals use UDP [RFC0768] as a demux layer, with new transport semantics layered on top of it 🍓. for those transports, it may be possible to build a common signaling mechanism and set of signals, like the one proposed in "Transport-Independent Path Layer State Management" [PLUS] ✨.

this is basically a cousin of the reuse idea from the section above, but it has a better shot at keeping the solution from getting stuck to the first protocol that moves 🦋.

4. Recommendation 👑

the IAB urges protocol designers to design for confidential operation by default 🔐. we're strongly encouraging developers to include encryption in their implementations and to make them encrypted by default 💜. we also encourage network and service operators to deploy encryption wherever it isn't deployed yet, and we urge firewall policy administrators to permit encrypted traffic 🌸. one of the consequences of this change is the loss of implicit signals, so bestie, just know that going in 😭.

fundamentally, this document recommends that implicit signals should be avoided. an implicit signal should only be replaced with an explicit signal when the signal's originator intends for it to be used by the network elements on the path 🎯. for many flows, this means the signal will be absent, but it can still show up when it's actually needed ✨.

discussion of the right mechanism(s) for these signals is still going, but at a minimum, any method should aim to follow these basic principles 📝:

  • the part of protocol signaling that's meant for end-system state machines should be protected by confidentiality and integrity protection, so that only those end systems can access it 🔒.
  • anything exposed to the path should be done with the intent that the network elements on the path actually use it. this information should be integrity protected, so end systems can detect if path elements have changed things in flight 🕵️‍♀️.
  • signals exposed to the path should be decoupled from the signals that drive the protocol state machines in endpoints. this avoids creating chances for extra inference 🙈.
  • intermediate path elements should not add visible signals that identify the user, origin node, or origin network [RFC8164]. note that if integrity protection is provided as suggested above, any signals added by intermediate path elements will be clearly distinguishable from those added by endpoints, since they won't be inside the integrity-protected portion of the packet 💅.

the IAB notes that methods for letting on-path actors verify integrity protection aren't available unless those actors share keys with the end systems or share a common set of trust points 🔑. as a result, integrity protection can generally be reliably applied by, and verified only by, endpoints 🫶.

verifying the authenticity of signals generated by on-path actors is similarly tricky 😩. endpoints that consume signals generated by on-path actors, especially where those signals are unauthenticated, need to fully think through what it means to do so 🧠. managing the authentication of on-path signals is an area of active research, and defining or recommending methods for it is outside the scope of this document 🔬.

5. IANA Considerations 🌈

this document has no IANA actions. nothing for IANA to do here, no registry drama 🙅‍♀️✨.

6. Security Considerations 💀

this part is serious, so let's get into it 🚨. path-visible signals let network elements along the path act based on the information they signal, whether the signal is implicit or explicit. if the network element is controlled by an attacker, those actions can include dropping, delaying, or mangling the packets that make up a flow 😱. an attacker may also characterize the flow or try to fingerprint the communicating nodes based on the pattern of signals 🕵️.

note that actions that don't benefit the flow or the network may be perceived as an attack, even when a responsible network element is the one taking them 🙃. designing a system that minimizes the ability to act on signals at all, by removing as many signals as possible, may reduce this possibility. this approach also comes with risks, mainly that the actions will keep happening on an arbitrary set of flows 😬.

adding visible signals to the path also increases the information available to an observer. when that information can be linked to a node or user, it may reduce the user's privacy 👀🔒.

when signals from endpoints to the path are independent from the signals endpoints use to manage the flow's state mechanics, an endpoint can falsify them without affecting the peer's understanding of the flow's state 🎭. for encrypted flows, on-path devices can't detect this divergence 🫥. the intent of this practice may be to get improved treatment from the network or to avoid restrictions 🙄. protocol designers should be cautious when introducing explicit signals, and should consider how falsified signals would affect protocol operation and deployment ⚠️. similarly, operators should be cautious in deployments, making sure that default operation without these signals doesn't encourage gaming the system by providing false signals 🚩.

7. Informative References 📚

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

[QUIC]     Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
           Multiplexed and Secure Transport", Work in Progress,
           draft-ietf-quic-transport-19, March 2019.

[RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
           DOI 10.17487/RFC0768, August 1980,
           <https://www.rfc-editor.org/info/rfc768>.

[RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
           RFC 793, DOI 10.17487/RFC0793, September 1981,
           <https://www.rfc-editor.org/info/rfc793>.

[RFC1958]  Carpenter, B., Ed., "Architectural Principles of the
           Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996,
           <https://www.rfc-editor.org/info/rfc1958>.

[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>.

[RFC7045]  Carpenter, B. and S. Jiang, "Transmission and Processing
           of IPv6 Extension Headers", RFC 7045,
           DOI 10.17487/RFC7045, December 2013,
           <https://www.rfc-editor.org/info/rfc7045>.

[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>.

[RFC8164]  Nottingham, M. and M. Thomson, "Opportunistic Security for
           HTTP/2", RFC 8164, DOI 10.17487/RFC8164, May 2017,
           <https://www.rfc-editor.org/info/rfc8164>.

IAB Members at the Time of Approval 🎀

  • Jari Arkko
  • Alissa Cooper
  • Ted Hardie
  • Christian Huitema
  • Gabriel Montenegro
  • Erik Nordmark
  • Mark Nottingham
  • Melinda Shore
  • Robert Sparks
  • Jeff Tantsura
  • Martin Thomson
  • Brian Trammell
  • Suzanne Woolf

Acknowledgements 🫶

in addition to the editor listed in the header, this document pulls in contributions from Brian Trammell, Mirja Kuehlewind, Martin Thomson, Aaron Falk, Mohamed Boucadair, and Joe Hildebrand 💖. these ideas were also discussed at the PLUS BoF, sponsored by Spencer Dawkins 🌟. the ideas around using IPv6 hop-by-hop headers as a network-layer signal benefited from discussions with Tom Herbert 🧠. the description of UDP as a demuxing protocol comes from Stuart Cheshire 🙌. Mark Smith, Kazuho Oku, Stephen Farrell, and Eliot Lear gave valuable comments on earlier draft versions of this document, so they get all the flowers too 🌸💐.

all errors are those of the editor 🙈.

Author's Address 💌

  • Ted Hardie (editor)
  • Email: ted.ietf@gmail.com
📦 where this page comes from