RFC 9419

Considerations on Application - Network Collaboration Using Path Signals

📅 published July 2023, from ietf

RFC 9419: The Title Block Tea ✨

Bestie, okay so this is RFC 9419, and it's called Considerations on Application - Network Collaboration Using Path Signals 🎀. It's an Informational doc, so it's a category, not a standard 💅. It came from the Internet Architecture Board (IAB) and is dated July 2023 📅. Its ISSN is 2070-1721.

The authors are J. Arkko (Ericsson), T. Hardie (Cisco), T. Pauly (Apple), and M. Kühlewind (Ericsson). Iconic squad 👑. The title block doesn't list anything it obsoletes or updates, so there's nothing to chase there 🙈.

Abstract 🦋

Okay, so this doc talks about the principles for designing mechanisms that use or provide path signals, and it asks for standards action in some specific, super valuable cases 💜. RFC 8558 describes path signals as messages to or from on-path elements, and it points out that visible information gets used whether or not anyone meant it as a signal 👀. Main character energy for that observation 💀.

The principles here are guidance for designing explicit path signals. Those are encouraged to be authenticated and to include a minimal set of parties, so there's less information sharing 🫶. You can get there with things like encrypting information and setting up trust relationships between the entities on a path 🔐. Lowkey the whole vibe is "share less, verify more" ✨.

Status of This Memo 🌸

Quick reality check: this is not an Internet Standards Track specification. It's published for informational purposes only 📚.

It's a product of the Internet Architecture Board (IAB), and the IAB decided it's valuable enough to keep as a permanent record 🗂️. It represents the consensus of the IAB 🤝. Docs the IAB approves for publication are not candidates for any level of Internet Standard, so no, this isn't going to become a standard lol. See Section 2 of RFC 7841 for the details 💅.

For the current status, any errata, and how to send feedback, check https://www.rfc-editor.org/info/rfc9419 🌈.

Copyright (c) 2023 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're in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document 📜. Don't skip the fine print, bestie 🙏.

Table of Contents 💅

   1.  Introduction
   2.  Principles
     2.1.  Intentional Distribution
     2.2.  Control of the Distribution of Information
     2.3.  Protecting Information and Authentication
     2.4.  Minimize Information
     2.5.  Limiting Impact of Information
     2.6.  Minimum Set of Entities
     2.7.  Carrying Information
   3.  Further Work
   4.  IANA Considerations
   5.  Security Considerations
   6.  Informative References
   IAB Members at the Time of Approval
   Acknowledgments
   Authors' Addresses

1. Introduction ✨

okay so [RFC8558] defines "path signals" as signals to or from on-path elements 🧚 Right now, path signals are usually implicit, meaning they get pulled out of cleartext end-to-end info just by peeking at transport protocols. Like, on-path elements read fields of the TCP header [RFC9293] to figure out end-to-end latency and congestion 👀 These techniques took off because the info was already sitting there and grabbing it needed zero coordination with anyone. That made them way easier to deploy than explicit or cooperative options, which is lowkey the whole reason they won 💅

BUT 🙈 applications and networks have been evolving how they talk to each other without a comprehensive design for how that should work, or which (minimal) info is actually needed for a given function. So we ended up using whatever info was easy to grab instead of the info that was actually needed. That info can be incomplete, incorrect, or only indirectly representative of what's really needed. On top of that, depending on info and mechanisms built for a different function limits how evolvable the protocols are. Not it 😭

In summary, these unplanned interactions cause a few negative effects:

  • Ossifying protocols by introducing dependencies on unintended parties that may not be updating, like how middleboxes have limited the use of TCP options
  • Creating systemic incentives against deploying more secure or otherwise updated versions of protocols
  • Basing network behavior on information that may be incomplete or incorrect
  • Creating a model where network entities expect to be able to use rich information about sessions passing through

It's giving chaos, honestly 💀 Features like DNS resolution or TLS setup have been used way beyond their original intent, like for name-based filtering. MAC addresses got used for access control, and captive portals ended up taking over cleartext HTTP sessions, and so on 🌸 (This document isn't here to judge whether those practices are good or bad. It's just stating the fact that these features got used beyond their original intent. No drama, just facts 🫶)

Many protocol mechanisms across the stack fall into one of two categories. The first is authenticated private communication that's only visible to a very limited set of parties, often one on each "end". The second is unauthenticated public communication that's visible to every network element on a path 🦋

Exposed info encourages pervasive monitoring, which [RFC7258] describes. It can also be used for commercial purposes, or as a basis for filtering that applications or users don't want 😤 But on the flip side, a total lack of path signaling can limit network management, debugging, or the ability for networks to optimize their services. There are lots of cases where elements on the network path could provide beneficial services, but only if they can coordinate with the endpoints ✨ It also affects the ability of service providers and others to observe why problems occur [RFC9075].

So this situation gets cast as an adversarial trade-off between privacy and the network path's ability to provide intended functions. Honestly though, that's maybe an unnecessarily polarized take, treating it as a zero-sum game 🙄 Not all information passing implies a loss of privacy. For example, performance information or preferences don't require disclosing the content being accessed, the user identity, or the application in use. Similarly, network congestion status info doesn't have to reveal network topology, the status of other users, and so on 🍓

Increased deployment of encryption is changing this whole situation 🔐 Encryption gives us tools for controlling information access, and it protects against ossification by avoiding unintended dependencies and requiring active maintenance. That deployment is also a chance to rethink parts of the Internet architecture that have been implicitly deriving input signals for on-path functions, instead of using explicit signaling, as recommended by [RFC8558] 🎀

For instance, QUIC replaces TCP for various applications and protects end-to-end signals so that only the endpoints can access them, which ensures evolvability [RFC9000] 👑 QUIC does expose some info meant for on-path elements to consume, using explicit signals for specific use cases. Examples are the Spin Bit for latency measurements, or a connection ID that load balancers can use [RFC9312] 🧚 That info is accessible to all on-path devices, but it's limited to those use cases. Every new use case needs additional action. This points to one way to resolve the adversity: being careful about the design of what information gets passed ✨

Another extreme is explicit trust and coordination between specific entities, endpoints, and network path elements. VPNs are a great example, since there's explicit authentication and negotiation with a network path element to gain access to specific resources 🔑 Authentication and trust have to be considered in both directions: how endpoints trust and authenticate signals from network path elements, and how network path elements trust and authenticate signals from endpoints 🫶

The goal of improving privacy and trust on the Internet doesn't necessarily mean removing the ability for network elements to perform beneficial functions. Instead, we should improve the way those functions are achieved, and design new ways to support explicit collaboration where it's seen as beneficial 🌈 So our goals should be to:

  • ensure that information is distributed intentionally, not accidentally;
  • understand the privacy and other implications of any distributed information;
  • ensure that the information distribution is limited to the intended parties; and
  • gate the distribution of information on the participation of the relevant parties.

These goals for exposure and distribution apply equally to senders, receivers, and path elements 💜

Going forward, new standards work in the IETF needs to focus on closing this gap by providing better alternatives and mechanisms for building functions that require some collaboration between endpoints and path elements. Main character energy for future protocol design 👑

We can establish some basic questions that any new network function should consider:

  • Which entities must consent to the information exchange?
  • What is the minimum information each entity in this set needs?
  • What is the effect that new signals should have?
  • What is the minimum set of entities that need to be involved?
  • What are the right mechanism and needed level of trust to convey this kind of information?

If we look at how network functions are achieved today, we find that many, if not most, fall short of the standard set by the questions above 😬 They send unnecessary information, fail to limit the scope of distribution, or fail to provide any negotiation or consent. Iconic behavior it is not 💀

Designing explicit signals between applications and network elements, while making sure all information is appropriately protected, enables information exchange in both directions. That exchange matters for improving quality of experience and network management ✨ The clean separation that explicit signals provide is also more conducive to protocol evolvability 🦋

Beyond the recommendation in [RFC8558], the IAB has provided further guidance on protocol design. Among other documents, [RFC5218] gives general advice on incremental deployability, based on an analysis of successes and failures, and [RFC6709] discusses protocol extensibility 📚 The Internet Technology Adoption and Transition (ITAT) workshop report [RFC7305] is also recommended reading on this same general topic. And [RFC9049], an IRTF document, catalogs past issues to avoid. It also discusses incentives for adopting path signals, such as the need to outperform end-to-end mechanisms, or considering per-connection state 🧠

This document discusses different approaches for explicit collaboration and gives guidance on architectural principles for designing new mechanisms 🌸 Section 2 covers principles that good design can follow. It also provides examples and explores the consequences of not following those principles in those examples. Section 3 points to topics that need to be looked at more carefully before any guidance can be given 🫶

2. Principles ✨

This section provides architecture-level principles for protocol designers, and recommends models to apply for network collaboration and signaling 💅

While [RFC8558] focuses specifically on communication to "on-path elements", the principles described in this document potentially apply to:

  • on-path signaling (in either direction) and
  • signaling with other elements in the network that are not directly on-path but still influence end-to-end connections.

An example of on-path signaling is communication between an endpoint and a router on a network path 🧚 An example of signaling with another network element is communication between an endpoint and a network-assigned DNS server, firewall controller, or captive portal API server. Note that these communications are conceptually independent of the base flow, even if they share a packet. They're coming from and going to other parties, rather than creating a multiparty communication 🎀

Taken together, these principles focus on the inherent privacy and security concerns of sharing information between endpoints and network elements. They emphasize that careful scrutiny and a high bar of consent and trust need to be applied 🔥 Given the known threat of pervasive monitoring, applying these principles is critical. That way, the use of path signals doesn't create a disproportionate opportunity for observers to extract new data from flows 👑

2.1. Intentional Distribution ✨

okay so the guideline here is best expressed in [RFC8558] 🎀 and it goes like this:

Fundamentally, this document recommends that implicit signals should be avoided and that an implicit signal should be replaced with an explicit signal only when the signal's originator intends that it be used by the network elements on the path. For many flows, this may result in the signal being absent but allows it to be present when needed.

the vibe is: info should be shared on purpose 💖 It should be sent knowingly, for a specific reason, in signals built for that reason, and whoever gets it should only use it for that reason too. 🫶 And before anyone sends anything, somebody has to actually look at the security and privacy implications of that reason and the info attached to it. no skipping that part 😭

this guideline works in the network element to application direction too 🦋 A network element should not unintentionally leak information. this doc gives recommendations that apply to lots of different situations, but the whole "go do careful analysis" thing is the key 🔑 Different kinds of information, different apps, and different directions of communication all change the analysis, and they can lead to really different answers about what can be shared and who it can be shared with. 💅

for example, there are plenty of things apps should NOT share with network elements, like the content of their communications (e.g., content of communications) 🙈 and there are things network elements should not share with apps, like detailed user location in a wireless network (e.g., detailed user location in a wireless network) 📍 But, equally, info about other stuff, like the onset of congestion, should be possible to share, and it can be super beneficial to everyone involved ✨

so yeah, intentional distribution is the precondition for explicit collaboration 👑 It's what lets each entity have the highest possible level of control over what info it shares. iconic, honestly 💜

2.2. Control of the Distribution of Information

explicit signals are not enough, bestie 🙅‍♀️ The entities also need to agree to exchange the information. Trust and mutual agreement between the involved entities have to decide how information gets distributed, so that each entity has proper control over the collaboration or the info sharing 🫶 There are ways to get there, which we'll go through below.

the sender needs to decide it's willing to send info to a specific entity or set of entities 💌 Any passing of info or request for an action has to be explicit and use signaling mechanisms designed for that exact purpose. Merely sending a particular kind of packet to a destination should not be interpreted as an implicit agreement. no vibes-based consent here, it's giving "read the room" but make it a protocol 🙄

at the same time, the recipient of info or the target of a request should get to choose whether it agrees or denies receiving the info 🌸 It should not be burdened with extra processing if it doesn't want or need to do that. In most protocol designs this just happens naturally, but it's been a problem in some cases where "slow path" packet processing is required or implied, and the recipient or router isn't willing to handle it 🐢 Performance impacts like this are best avoided, however.

in any case, all involved entities must be identified and potentially authenticated if trust is required as a prerequisite to share certain information 🔐

a lot of Internet communications aren't made on behalf of the apps themselves. They're ultimately made on behalf of users 🧚 Not all the info that might get shared directly relates to user actions or other sensitive data, though. All shared info must be carefully evaluated to find potential privacy implications for users 👀 Info that directly relates to the user should not be shared without the user's consent. It's worth noting that the interests of the user and other parties, like the application developer, may not always line up 😬 some apps may want to collect more info about the user than the user would like. As discussed in [RFC8890], from an IETF point of view, the interests of the user should be prioritized over those of the application developer. the general issue of how to balance control between the actual user and an application representing the user's interests is out of scope for this document 🙅‍♀️

2.3. Protecting Information and Authentication

some simple forms of info often exist in cleartext, e.g., Explicit Congestion Notification (ECN) bits from routers are generally not authenticated or integrity protected 📦 That's fine when the information exchanges don't carry anything significantly sensitive from the parties. These kinds of interactions are also usually advisory in nature (see Section 2.5) 🫧

in other cases, it may be necessary to set up a secure signaling channel for talking to a specific other party, e.g., between a network element and an application 🔒 This channel may need to be authenticated, integrity protected, and confidential. That's necessary, for instance, if the particular info or request needs to be shared in confidence only with a particular, trusted network element or endpoint, or if there's a danger of an attack where someone else could forge messages that endanger the communication 😱

authenticated integrity protections on signaled data can help make sure that data received in a signal hasn't been modified by other parties 🛡️ Still, both network elements and endpoints need to be careful about processing or responding to any signal. Whether it's through bugs or attacks, the content of path signals can lead to unexpected behaviors or security vulnerabilities if it isn't handled properly 💀 So the advice in Section 2.5 still applies even when there's a secure channel for sending info. no exceptions, periodt ✨

but here's the thing: authentication does not equal trust 🚨 Whether a communication is with an application server or a network element that can be shown to be associated with a particular domain name, it does NOT follow that info about the user can be safely sent to it. Being verified is not the same as being trustworthy, babe 🙃

sometimes, the ability of a party to show that it's on the path can be useful 🛤️ For instance, an ICMP error that refers to a valid flow may be more trustworthy than any ICMP error that claims to come from an address.

other cases may need more serious assurances 💼 For instance, a specific trust arrangement may be set up between a particular network and application. Or technologies like confidential computing can be applied to give assurance that info processed by a party is handled in an appropriate manner 🧠

2.4. Minimize Information

each party should provide only the info that's needed for the other parties to do the task that collaboration is wanted for, and no more 🧺 This applies to info an application sends about itself, info sent about users, or info sent by the network. It also applies to any info related to flow identification 🪪

an architecture can follow the guideline from [RFC8558] and use explicit signals, but still fail to tell apart info that should be kept private from info that should be shared 🙈 [RFC6973] also lays out this principle of data minimization as a mitigation technique for protecting privacy, and it gives further guidance on it 📚

when we're looking at what info can or can't be passed easily, we have to think about both directions: from the network to the application, and from the application to the network 🔁

for the application-to-network direction, user-identifying info can be a problem for privacy and tracking reasons 🕵️‍♀️ Similarly, application identity can be a problem if it could become the basis for prioritization or discrimination that the application provider may not want to happen 🚫

on the other hand, like we noted above, info about general classes of applications may be something application providers want to give, if it enables prioritization that improves service 💫 e.g., telling apart interactive and non-interactive services.

for the network-to-application direction, there's similarly sensitive info, like the precise location of the user 📍 On the other hand, various generic network conditions, predictive bandwidth and latency capabilities, and so on might be really attractive info for applications to use. For instance, they could use it to work out the best strategies for changing codecs 🎶 However, info the network gives about load conditions and so on should not form a mechanism that provides a side channel into what other users are doing 👀 that's a hard no from me.

while info needs to be specific and provided on a per-need basis, it's often beneficial to provide declarative info that, for instance, expresses application needs, and then makes specific requests for action 📝 big main character energy for declarative signals 🎬

2.5. Limiting Impact of Information

info shared between a network element and an endpoint of a connection needs to have a limited impact on how both endpoints and network elements behave 🤏 Any action that an endpoint or network element takes based on a path signal needs to be considered appropriately, based on the level of authentication and trust that's been established, and it needs to be scoped to a specific network path 🛣️ no going rogue on a whole connection because of one signal, fr fr.

for example, an ICMP signal from a network element to an endpoint can be used to influence future behavior on that particular network path (like changing the effective packet size or closing a path-specific connection) 📏 But it should not be able to cause a multipath or migration-capable transport connection to close 🙅‍♀️ That connection has too much going for it to get wiped by one signal 💪

in lots of cases, path signals can be treated as advisory info, with the effect of optimizing or adjusting how connections behave on a specific path ✨ Take a firewall blocking connectivity to a given host. Endpoints should only interpret that as the host being unavailable on that particular path 🧱 That's different from an end-to-end authenticated signal, like a DNSSEC-authenticated denial of existence [RFC7129] 🔏

2.6. Minimum Set of Entities

it is recommended that a design identifies the minimum number of entities needed to share a specific signal required for an identified function 🎯 the smallest crew possible, bestie.

often this will be a very limited set, like when an application only needs to give a signal to its peer at the other end of the connection, or when a host needs to contact a specific VPN gateway 🌐 In other cases a broader set is needed, like when explicit or implicit signals from a potentially unknown set of multiple routers along the path tell the endpoints about congestion 🚦

I know it's tempting to drop these limits in closed, private networks 🏰 but each interaction is still best considered separately, rather than just letting all info exchanges happen inside the closed network. Even in a closed network with carefully managed elements, there may be compromised components, and the most extreme example is the Stuxnet worm, which operated in an air-gapped network 🪱 Most "closed" networks have at least some needs and means to access the rest of the Internet, so they shouldn't be modeled as if they had an impenetrable security barrier 🧱💥

2.7. Carrying Information ✨

okay so here's the tea 🫖 there's a difference between what info gets sent and how it gets sent 💅 the actual info can be super limited, but the mechanisms for sending or requesting it? they can be capable of sharing way more 👀

there's a trade-off here between flexibility and keeping the info minimal in the future 🦋 the worry is that a totally generic data-sharing approach between different layers and parties could get misused 😬 like, making it a requirement to reveal some info just to pass through a network, such as making it mandatory to identify specific applications or users. that is NOT it bestie 🙅‍♀️

so this doc recommends that signaling mechanisms which send info get built to specifically support sending the necessary, minimal set of info (check Section 2.4 🎀) and no more 💖 as we said before, flow-identifying info is a path signal in itself 🧚, so provisioning flow identifiers also needs protocol-specific analysis 🔍

and ALSO these mechanisms need the ability to establish an agreement (see Section 2.2 🤝) plus enough trust to pass the info (see Section 2.3 🫶). no cap, it's all connected 💜

3. Further Work 🌈

this is a developing field and our understanding of it is gonna keep growing 🌱 one recent change is WAY higher use of encryption at different protocol layers 🔐 which obviously impacts the field a lot, because it removes the ability to use most implicit signals 💀 but it might also give us new tools for secure collaboration and force a rethink of how collaboration should happen 🤯

there are some examples of modern, well-designed collaboration mechanisms, but the list is not long 😭 we clearly need more work if we want the benefits of collaboration in more cases 🍓 this requires a mindset change, a migration away from relying on implicit signals ✨ and we need to pick cases where collaboration can be done safely, where it's not a privacy concern, and where the incentives of the relevant parties are aligned 🫶 it should also be said that a lot of complex cases would need significant developments before they become feasible 🛠️

here are some of the most difficult areas. research on these topics would be welcome 📚 notice that the topics include both stuff dealing directly with on-path network element collaboration AND some adjacent issues that would influence that collaboration 👑

  • Business arrangements. some forms of collaboration may depend on business arrangements, which may or may not be easy to put in place 💸 for instance, some quality-of-service mechanisms involve an expectation of paying for a service 💰 this is possible and has been successful within individual domains, e.g., users can pay for higher data rates or data caps in their ISP networks 📶 however, it's a business-wise proposition that is much harder for end-to-end connections across multiple administrative domains 😩 [Claffy2015] [RFC9049]
  • Secure communication with path elements. secure communication with path elements is needed, as discussed in Section 2.3 🔒 finding practical ways to do this has been difficult, both mechanically and from a scalability point of view 🥲 partly because there's no easy way to find out which parties to trust or what trust roots would be appropriate 🤷‍♀️ some application-network element interaction designs have focused on info (such as ECN bits) that's distributed openly within a path 🌊 but there are limited examples of designs with secure info exchange with specific network elements or endpoints 🙈
  • Path signals against denial-of-service attacks. the use of path signals to reduce the effects of denial-of-service attacks, e.g., perhaps modern forms of "source quench" designs, could be developed 🦋 the difficulty is finding a solution that is both effective against attacks AND doesn't let third parties slow down or censor someone else's communication 🚫
  • Dissociating info from user location and behavior. work has begun on mechanisms that dissociate the info held by servers from knowledge of the user's network location and behavior 🕵️‍♀️ among the solutions that exist for this but aren't widely deployed yet are [Oblivious] [PDoT] [DNS-CONFIDENTIAL] [HTTP-OBLIVIOUS] 🧩 these solutions each address specific parts of the issue, and more work remains to limit the spread of info about the user's actions 📉 host applications currently share sensitive info about the user's actions with a variety of infrastructure and path elements 😳 starting from basic data, such as domain names, source and destination addresses, and protocol header info 🧾 and it can expand to detailed end-user identity and other info learned by the servers 🫣 protecting all of this info is needed 🛡️
  • Sharing info from networks to applications. work is needed to explore how to increase deployment of mechanisms for sharing info from networks to applications 📡 there are some working examples, e.g., ECN 🌈 a few other proposals have been made (see, e.g., [MOBILE-THROUGHPUT-GUIDANCE]), but very few of those have seen deployment 🥺
  • Sharing info from applications to networks. additional work on sharing info from applications to networks would also be valuable 💜 there are a few working examples of this (see Section 1) 🎀 numerous proposals have been made in this space, but most of them haven't progressed through standards or been deployed, for a variety of reasons [RFC9049] 😮‍💨 however, several current or recent proposals exist, such as [NETWORK-TOKENS] ✨
  • Data privacy regimes. data privacy regimes generally deal with multiple issues, not just whether some info is shared with another party 📜 for instance, there may be rules about how long info can be stored or what purpose it may be used for ⏳ similar issues may also apply to the kind of info sharing discussed in this document 🔁
  • Policy and regulation. the present work has focused on the technical aspects of making collaboration safe and mutually beneficial 🤓 but of course, deployments need to take into account various regulatory and other policy matters 🏛️ these include privacy regulation, competitive issues, network neutrality aspects, and so on 🌸

4. IANA Considerations 🎀

this document has no IANA actions 🙌

5. Security Considerations 🔐

this document has no security considerations 💅

6. Informative References 📚✨

okay so this is the reading list bit, and it's giving research paper energy 🤓 every single one is here exactly as written, so you can go find the real thing 💅

[Claffy2015]
           Claffy, KC. and D. Clark, "Adding Enhanced Services to the
           Internet: Lessons from History", TPRC 43: The 43rd
           Research Conference on Communication, Information and
           Internet Policy Paper, DOI 10.2139/ssrn.2587262, November
           2015, <https://papers.ssrn.com/sol3/
           papers.cfm?abstract_id=2587262>.

[DNS-CONFIDENTIAL]
           Arkko, J. and J. Novotny, "Privacy Improvements for DNS
           Resolution with Confidential Computing", Work in Progress,
           Internet-Draft, draft-arkko-dns-confidential-02, 2 July
           2021, <https://datatracker.ietf.org/doc/html/draft-arkko-
           dns-confidential-02>.

[EXPLICIT-COOP]
           Trammell, B., Ed., "Architectural Considerations for
           Transport Evolution with Explicit Path Cooperation", Work
           in Progress, Internet-Draft, draft-trammell-stackevo-
           explicit-coop-00, 23 September 2015,
           <https://datatracker.ietf.org/doc/html/draft-trammell-
           stackevo-explicit-coop-00>.

[HTTP-OBLIVIOUS]
           Thomson, M. and C. A. Wood, "Oblivious HTTP", Work in
           Progress, Internet-Draft, draft-thomson-http-oblivious-02,
           24 August 2021, <https://datatracker.ietf.org/doc/html/
           draft-thomson-http-oblivious-02>.

[MOBILE-THROUGHPUT-GUIDANCE]
           Jain, A., Terzis, A., Flinck, H., Sprecher, N.,
           Arunachalam, S., Smith, K., Devarapalli, V., and R. Bar
           Yanai, "Mobile Throughput Guidance Inband Signaling
           Protocol", Work in Progress, Internet-Draft, draft-flinck-
           mobile-throughput-guidance-04, 13 March 2017,
           <https://datatracker.ietf.org/doc/html/draft-flinck-
           mobile-throughput-guidance-04>.

[NETWORK-TOKENS]
           Yiakoumis, Y., McKeown, N., and F. Sorensen, "Network
           Tokens", Work in Progress, Internet-Draft, draft-
           yiakoumis-network-tokens-02, 21 December 2020,
           <https://datatracker.ietf.org/doc/html/draft-yiakoumis-
           network-tokens-02>.

[Oblivious]
           Schmitt, P., Edmundson, A., Mankin, A., and N. Feamster,
           "Oblivious DNS: Practical Privacy for DNS Queries",
           Proceedings on Privacy Enhancing Technologies, Volume
           2019, Issue 2, pp. 228-244, DOI 10.2478/popets-2019-0028,
           December 2018, <https://doi.org/10.2478/popets-2019-0028>.

[PATH-SIGNALS-INFO]
           Arkko, J., "Considerations on Information Passed between
           Networks and Applications", Work in Progress, Internet-
           Draft, draft-arkko-path-signals-information-00, 22
           February 2021, <https://datatracker.ietf.org/doc/html/
           draft-arkko-path-signals-information-00>.

[PDoT]     Nakatsuka, Y., Paverd, A., and G. Tsudik, "PDoT: Private
           DNS-over-TLS with TEE Support", Digital Threats: Research
           and Practice, Volume 2, Issue 1, Article No. 3, pp. 1-22,
           DOI 10.1145/3431171, February 2021,
           <https://doi.org/10.1145/3431171>.

[PER-APP-NETWORKING]
           Colitti, L. and T. Pauly, "Per-Application Networking
           Considerations", Work in Progress, Internet-Draft, draft-
           per-app-networking-considerations-00, 15 November 2020,
           <https://datatracker.ietf.org/doc/html/draft-per-app-
           networking-considerations-00>.

[RFC5218]  Thaler, D. and B. Aboba, "What Makes for a Successful
           Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008,
           <https://www.rfc-editor.org/info/rfc5218>.

[RFC6709]  Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design
           Considerations for Protocol Extensions", RFC 6709,
           DOI 10.17487/RFC6709, September 2012,
           <https://www.rfc-editor.org/info/rfc6709>.

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

[RFC7129]  Gieben, R. and W. Mekking, "Authenticated Denial of
           Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129,
           February 2014, <https://www.rfc-editor.org/info/rfc7129>.

[RFC7258]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
           Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
           2014, <https://www.rfc-editor.org/info/rfc7258>.

[RFC7305]  Lear, E., Ed., "Report from the IAB Workshop on Internet
           Technology Adoption and Transition (ITAT)", RFC 7305,
           DOI 10.17487/RFC7305, July 2014,
           <https://www.rfc-editor.org/info/rfc7305>.

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

[RFC8890]  Nottingham, M., "The Internet is for End Users", RFC 8890,
           DOI 10.17487/RFC8890, August 2020,
           <https://www.rfc-editor.org/info/rfc8890>.

[RFC9000]  Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
           Multiplexed and Secure Transport", RFC 9000,
           DOI 10.17487/RFC9000, May 2021,
           <https://www.rfc-editor.org/info/rfc9000>.

[RFC9049]  Dawkins, S., Ed., "Path Aware Networking: Obstacles to
           Deployment (A Bestiary of Roads Not Taken)", RFC 9049,
           DOI 10.17487/RFC9049, June 2021,
           <https://www.rfc-editor.org/info/rfc9049>.

[RFC9075]  Arkko, J., Farrell, S., Kühlewind, M., and C. Perkins,
           "Report from the IAB COVID-19 Network Impacts Workshop
           2020", RFC 9075, DOI 10.17487/RFC9075, July 2021,
           <https://www.rfc-editor.org/info/rfc9075>.

[RFC9293]  Eddy, W., Ed., "Transmission Control Protocol (TCP)",
           STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
           <https://www.rfc-editor.org/info/rfc9293>.

[RFC9312]  Kühlewind, M. and B. Trammell, "Manageability of the QUIC
           Transport Protocol", RFC 9312, DOI 10.17487/RFC9312,
           September 2022, <https://www.rfc-editor.org/info/rfc9312>.

IAB Members at the Time of Approval 🌸

these are the IAB folks who were on the board when this doc got approved for publication 🫶

  • Jari Arkko
  • Deborah Brungard
  • Lars Eggert
  • Wes Hardaker
  • Cullen Jennings
  • Mallory Knodel
  • Mirja Kühlewind
  • Zhenbin Li
  • Tommy Pauly
  • David Schinazi
  • Russ White
  • Qin Wu
  • Jiankang Yao

Acknowledgments 💜

okay bestie, the authors wanna thank everyone at the IETF, the IAB, and their day jobs 💅 for the interesting thoughts and proposals in this space. Bits of this document also showed up in [PER-APP-NETWORKING] and [PATH-SIGNALS-INFO] 🦋 and similar thoughts are presented in [EXPLICIT-COOP], so shoutout to them too ✨

Last but not least, a massive thank you to Adrian Farrell, Toerless Eckert, Martin Thomson, Mark Nottingham, Luis M. Contreras, Watson Ladd, Vittorio Bertola, Andrew Campling, Eliot Lear, Spencer Dawkins, Christian Huitema, David Schinazi, Cullen Jennings, Mallory Knodel, Zhenbin Li, Chris Box, and Jeffrey Haas for giving useful feedback on this topic and document 🥹🎀

Authors' Addresses 🧚

Jari Arkko
Ericsson
Email: jari.arkko@ericsson.com


Ted Hardie
Cisco
Email: ted.ietf@gmail.com


Tommy Pauly
Apple
Email: tpauly@apple.com


Mirja Kühlewind
Ericsson
Email: mirja.kuehlewind@ericsson.com
📦 where this page comes from