RFC 8546

The Wire Image of a Network Protocol 🎀

Bestie, here's the deets on this one 💖

• RFC number: RFC 8546
• Stream: Internet Architecture Board (IAB)
• Authors: B. Trammell and M. Kuehlewind
• Category: Informational
• Date: April 2019
• ISSN: 2070-1721
• Obsoletes / Updates: nothing listed in the title block

---

Abstract ✨

okay so this doc defines the wire image 👀 which is basically everything a random observer sitting on the network path can see about a protocol, even when they aren't part of the conversation. the whole point is to show how much more encryption changes what those on-path observers can actually do with that info 🔐💅

Status of This Memo 🌸

this one is not an Internet Standards Track spec, it's just published for info purposes 📚

it's a product of the Internet Architecture Board (IAB) and it's basically the IAB's consensus on something they think is worth keeping on the permanent record 🗂️ and documents the IAB approves aren't candidates for any level of Internet Standard, see Section 2 of RFC 7841 🙈

for the current status, errata, and how to send feedback, check https://www.rfc-editor.org/info/rfc8546 🦋

Copyright Notice 💜

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

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they were on the publication date. read those carefully, they spell out your rights and restrictions 📜✨

Table of Contents 🧚

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
2.  Definition  . . . . . . . . . . . . . . . . . . . . . . . . .   3
3.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . .   3
  3.1.  The Extent of the Wire Image  . . . . . . . . . . . . . .   4
  3.2.  Obscuring Timing and Sizing Information . . . . . . . . .   5
  3.3.  Integrity Protection of the Wire Image  . . . . . . . . .   5
4.  Engineering the Wire Image  . . . . . . . . . . . . . . . . .   6
  4.1.  Declaring Protocol Invariants . . . . . . . . . . . . . .   7
  4.2.  Trustworthiness of Engineered Signals . . . . . . . . . .   7
5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
7.  Informative References  . . . . . . . . . . . . . . . . . . .   8
IAB Members at the Time of Approval . . . . . . . . . . . . . . .   9
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   9
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1. Introduction 💖

okay so a protocol spec basically lays out how each participant has to behave: which lower-layer protocols handle which services, how messages get formatted and protected, who sends what and when, and how each side should respond to each message, etc. 📋

but here's the tea ☕ a protocol also leaks info to nonparticipant observers watching the messages go by, and that includes folks in lower-layer protocols too. any info that's clearly defined in the message format (or implied by that definition) and isn't cryptographically protected for confidentiality can be read unambiguously by those observers. that leaked info is the wire image, and that's what this doc is about 🦋✨

the wire image, not the spec, is what decides how third parties on the network paths between participants actually interact with the protocol. main character energy for the packets fr 💅

the rise of transport-layer security [RFC8446], which protects app-layer headers and payloads, plus transport protocols with encrypted control info like QUIC [QUIC], makes this question way more relevant 🔐 QUIC is kind of the first IETF transport protocol to minimize its own wire image on purpose, to prevent ossification and improve end-to-end privacy by cutting down on info radiation 🌈

the flip side is that a less visible wire image messes with a bunch of functions that depend on third parties watching it. this doc treats the wire image as a pure abstraction, not as a side in the ongoing tussle, in the hope it sheds some light on those discussions 🫶

2. Definition 🎀

the wire image of a set of protocols used for a given communication is how that set looks to an entity that isn't taking part in the communication 👀 it's the sequence of packets each participant sends, including the contents of those packets, plus metadata about the observation itself: when each packet was observed and the vantage point of the observer 🔭

3. Discussion 🧚

a few important properties of the wire image pop out of that definition 💜

it's key that the wire image is not just "the unencrypted bits in the header" 🙈 metadata like interpacket timing and packet sizes can be used to infer other parameters about how the protocols behave, or to fingerprint the protocols and/or specific implementations, see Section 3.2 🕵️

this is where it gets spicy: a protocol that encrypts the headers it needs to operate can be deliberately designed to have a specified wire image that's separate from that machinery, see Section 4. this is a capability unique to encrypted protocols, bestie 🔐✨ also, parts of a wire image can be visible to devices on path but still immutable thanks to end-to-end integrity protection, see Section 3.3 🛡️

parts of a protocol stack's wire image that are neither confidentiality protected nor integrity protected are writable by devices on the path between the endpoints 🙃 a protocol with a mostly writable wire image, running over a path with devices that understand its semantics, can be modified to induce behaviors at the participants. TCP is one such protocol on today's Internet 🌐

the term "wire image" works at different scopes 🔍 the wire image of a single packet is the info you can get by observing that one packet alone, while the wire image of a single protocol is the info you get from only that protocol's headers across a sequence of packets, separate from the other protocols in use for the communication. see Section 3.1 for more 📖

for a given packet seen at a given point in the network, the wire image includes info from the entire stack of protocols in use at that observation point 📚 which means the wire image depends on the observer too, so each observer might see a slightly different image of the same communication 👀

in this doc we assume that only info at the transport layer and above is delivered end-to-end, and we focus on the "Internet" wire image, meaning the part at the network layer and above 🌸 confidentiality and integrity protection can be added at multiple layers of the stack, but protection below the network layer doesn't stop modification, either by the devices terminating those security associations or by devices on different segments of the path 🙅‍♀️

3.1. The Extent of the Wire Image 💅

we start by defining the wire image as the properties of a sequence of packets in isolation, but that's not how passive observers actually use wire images 👀 they usually consider the union of all the info in the wire images of all the packets generated by a given conversation 🧩

same goes for a single protocol's wire image, which is rarely seen on its own 🙃 the app and network stacks on each endpoint use multiple protocols for any higher-level task. for example, protocols carrying user content are often seen together with DNS traffic, and the wire image info from each protocol in use for a communication can be correlated to infer stuff about what the overlying app is doing 🔗

wire image info usually isn't used alone either 🫣 it's correlated with other context the observer has, like info about other communications each endpoint is engaged in, info about the implementations of the protocols at each endpoint, info about the network and internetwork topology near those endpoints, and so on. that context plus the wire image can lead to more detailed inferences about endpoint and end-user behavior 🕵️‍♀️✨

also, the wire image is multidimensional 🌈 so the name "image" isn't just a metaphor, and general image recognition techniques may apply to pulling patterns and info out of it 🖼️🤯

3.2. Obscuring Timing and Sizing Information 🦋

encryption can protect a protocol's headers' confidentiality as long as forwarding devices don't need that protected info for basic forwarding 🔐 ciphersuites and other transmission techniques designed to block timing analysis can also be applied at the sender to reduce the info content of the metadata part of the wire image 🫶

but there are limits, bestie 🚧 packets can't be made smaller than their information content, can't be sent faster than the sender's processing time requirements allow, and can't cross the network faster than the speed of light ⚡ and since these techniques cost bandwidth efficiency and latency, they're also capped by how much latency and bandwidth inefficiency the application can tolerate 🐢

3.3. Integrity Protection of the Wire Image 🛡️

adding end-to-end integrity protection to parts of the wire image makes it impossible for on-path devices to change them without the endpoints detecting it 🚫 the endpoints can then respond to those changes, so those parts are effectively immutable 🔒 they can still be seen by devices on path though, which lets endpoints create signals meant solely for those on-path devices to consume 📡✨

integrity protection can practically only be applied to the sequence of bits in each packet, so a protocol's visible wire image can't be made completely immutable in a packet-switched network 🙈 interarrival timings, for instance, can't be easily protected, since the observable delay sequence changes as packets move through the network and hit different delays on different links ⏱️ message sequences aren't practically protectable either, because packets can be dropped or reordered anywhere in the network as part of how it operates 🌀 and intermediate systems that understand the protocol semantics in the readable part of the wire image can purposely delay or drop packets to mess with the protocol's operation 😤

4. Engineering the Wire Image ✨

okay so this is the part where we get to design the wire image on purpose 🎀 Understanding what a protocol's wire image looks like lets us engineer it, and the big lesson from years of watching protocols at the network and transport layers get deployed (or not 💀) is this: every observable part of a protocol's wire image will eventually get used by devices on path. 😭 So if you want to change or extend something that shows up in the observable wire image later, it gets really hard to deploy, or straight up impossible.

A network function that does something useful for whoever deployed it will grab the info it needs from the wire image, and it'll usually go for the easiest route to get it. 🧚

For example, let's talk about the iconic TCP [RFC793] transport protocol 👑 As described in [RFC8558], a bunch of in-network functions have evolved to rely on implicit signals in TCP's wire image. And because TCP provides neither integrity nor confidentiality protection for its headers, those signals are basically inseparable from how TCP actually works internally 🫶 A few of them:

• Determining return routability and consent: TCP's wire image has an implicit hint that the sender of a packet is at least on the path toward its source address (that's in the acknowledgement number during the handshake), and another implicit hint that a receiving device consents to keep the communication going. Stateful network firewalls use these. 🔥
• Measuring loss and latency: Looking at the sequence number and acknowledgement number values, along with the ECN [RFC3168] control bits, lets you infer congestion, loss, and retransmission along the path. The sequence and acknowledgement numbers together with the timestamp option [RFC7323] let you measure application-experienced latency. 📊

When you're designing a protocol, these kinds of features are worth thinking about 💅 The wire image can be designed to explicitly expose information to the network functions the designers consider important. But the wire image should expose as little other information as possible 🌸

However, even when information is explicitly handed to the network, anything the wire image exposes, even stuff that wasn't meant for an observer to use, has to be designed super carefully 😭 Why? Because deployed network functions that use that information might make it immutable for future versions of the protocol. Like, information needed for the receiving endpoint to decrypt (cryptographic handshakes, sequence numbers, and so on) may be used by devices along the path for their own purposes. Not me being dramatic about it 🙈

4.1. Declaring Protocol Invariants

One potential way to shrink the part of the wire image that devices on the path will use is to define a set of invariants for a protocol during its development 🦋 Declaring invariants is basically a promise from the developers that certain bits in the wire image, and behaviors you can observe in the wire image, will be preserved through the specification of all future versions of the protocol. QUIC's invariants [QUIC-INVARIANTS] are an early attempt to apply this approach to QUIC. ✨

Static parts of the wire image (bits with simple meanings at fixed positions in protocol headers) are easy to make invariant. Other parts are more or less appropriate to define as invariants. For a protocol that has a version and/or extension negotiation mechanism, the bits in the header and the behaviors tied to those bits that implement version negotiation should be made invariant. Fluid parts of the wire image, and behaviors that aren't needed for interoperability, are not appropriate as invariants. 🙅‍♀️

Parts of a protocol's wire image that aren't declared invariant but are meant to be visible to devices on path should be protected against "accidental invariance" 🚨 That's when on-path devices get deployed over time and start making simplifying assumptions about those parts of the wire image, which makes new behaviors that don't fit those assumptions hard to deploy. Integrity protection of the wire image can help protect against accidental invariance itself, because read-only wire images invite less meddling than path-writable ones 🧁 The techniques discussed in [USE-IT] may also help prevent accidental invariance and ossification. 💜

And parts of a protocol's wire image that aren't declared invariant and aren't meant to be visible to the path should be encrypted to protect their confidentiality 🔐 When confidentiality protection isn't possible or practical, then, as above, the approaches discussed in [USE-IT] may be useful for preventing ossification. 🫧

4.2. Trustworthiness of Engineered Signals

Here's the tea ☕ The signals in the wire image that are engineered to be exposed are separate from the signals that drive an encrypted protocol's mechanisms. So the accuracy of those path-facing signals may not be verifiable by on-path devices; see [RFC8558]. 👀

And honestly? Any two endpoints that share a secret channel between them (in this case, the encrypted protocol itself) can collude to change the meaning and information content of these signals. 😳 This is unavoidable. It comes from the separation between the wire image and the protocol's operation that confidentiality protection of the protocol's headers gives you. It's giving trust issues, and that's just physics for protocols 🥲

5. IANA Considerations

This document has no IANA actions. 🌈

6. Security Considerations

This is the serious part, bestie, so pay attention 🚨 This document explores the information the wire image exposes that may be relevant to end-to-end communication privacy and security. When you design the wire image of a network protocol, you must take care to expose only the information the protocol's design says the network needs, and careful design is necessary to reduce the risk that information not explicitly included in the wire image can be worked out from observing it. Privacy leaks are not a vibe 💀

7. Informative References

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

[QUIC-INVARIANTS]
           Thomson, M., "Version-Independent Properties of QUIC",
           Work in Progress, draft-ietf-quic-invariants-04, April
           2019.

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

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

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

[RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
           Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
           <https://www.rfc-editor.org/info/rfc8446>.

[RFC8558]  Hardie, T., Ed., "Transport Protocol Path Signals",
           RFC 8558, DOI 10.17487/RFC8558, April 2019,
           <https://www.rfc-editor.org/info/rfc8558>.

[USE-IT]   Thomson, M., "Long-term Viability of Protocol Extension
           Mechanisms", Work in Progress, draft-thomson-use-it-or-
           lose-it-03, January 2019.

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

Acknowledgments 🫶

Huge thanks to Martin Thomson, Stephen Farrell, Thomas Fossati, Ted Hardie, Mark Nottingham, Tommy Pauly, and the membership of the IAB Stack Evolution Program for the text, feedback, and discussions that made this document better 💖

This work is partially supported by the European Commission under Horizon 2020 grant agreement No. 688421, Measurement and Architecture for a Middleboxed Internet (MAMI), and by the Swiss State Secretariat for Education, Research, and Innovation under contract No. 15.0268. This support does not imply endorsement. 🌸

Authors' Addresses 🦋

Brian Trammell
ETH Zurich
Gloriastrasse 35
8092 Zurich
Switzerland

Email: ietf@trammell.ch


Mirja Kuehlewind
ETH Zurich
Gloriastrasse 35
8092 Zurich
Switzerland

Email: ietf@kuehlewind.net