] defines the term "path signals" as signals to or from on-path elements. Today, path signals are often implicit; for example, they are derived from cleartext end-to-end information by, e.g., examining transport protocols. For instance, on-path elements use various fields of the TCP header [RFC 9293
] to derive information about end-to-end latency as well as congestion. These techniques have evolved because the information was available and its use required no coordination with anyone. This made such techniques more easily deployable than alternative, potentially more explicit or cooperative, approaches.
However, this also means that applications and networks have often evolved their interaction without comprehensive design for how this interaction should happen or which (minimal) information would be needed for a certain function. This has led to a situation where information that happens to be easily available is used instead of the information that is actually needed. As such, that information may be incomplete, incorrect, or only indirectly representative of the information that is actually needed. In addition, dependencies on information and mechanisms that were designed for a different function limit the evolvability of the protocols in question.
In summary, such unplanned interactions end up having several negative effects:
Ossifying protocols by introducing dependencies to unintended parties that may not be updating, such as 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
For instance, features such as DNS resolution or TLS setup have been used beyond their original intent, such as in name-based filtering. Media Access Control (MAC) addresses have been used for access control, captive portals have been used to take over cleartext HTTP sessions, and so on. (This document is not about whether those practices are good or bad; it is simply stating a fact that the features were used beyond their original intent.)
Many protocol mechanisms throughout the stack fall into one of two categories: authenticated private communication that is only visible to a very limited set of parties, often one on each "end", and unauthenticated public communication that is visible to all network elements on a path.
Exposed information encourages pervasive monitoring, which is described in [RFC 7258
]. It may also be used for commercial purposes or to form a basis for filtering that the applications or users do not desire. However, a lack of all path signaling, on the other hand, may limit network management, debugging, or the ability for networks to optimize their services. There are many cases where elements on the network path can 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 [RFC 9075
As such, this situation is sometimes cast as an adversarial trade-off between privacy and the ability for the network path to provide intended functions. However, this is perhaps an unnecessarily polarized characterization as a zero-sum situation. Not all information passing implies loss of privacy. For instance, performance information or preferences do not require disclosing the content being accessed, the user identity, or the application in use. Similarly, network congestion status information does not have to reveal network topology, the status of other users, and so on.
Increased deployment of encryption is changing this situation. Encryption provides tools for controlling information access and protects against ossification by avoiding unintended dependencies and requiring active maintenance. The increased deployment of encryption provides an opportunity to reconsider parts of Internet architecture that have used implicit derivation of input signals for on-path functions rather than explicit signaling, as recommended by [RFC 8558
For instance, QUIC replaces TCP for various applications and protects end-to-end signals so that they are only accessible by the endpoints, ensuring evolvability [RFC 9000
]. QUIC does expose information dedicated for on-path elements to consume by using explicit signals for specific use cases, such as the Spin Bit for latency measurements or connection ID that can be used by load balancers [RFC 9312
]. This information is accessible by all on-path devices, but information is limited to only those use cases. Each new use case requires additional action. This points to one way to resolve the adversity: the careful design of what information is passed.
Another extreme is to employ explicit trust and coordination between specific entities, endpoints, and network path elements. VPNs are a good example of a case where there is an explicit authentication and negotiation with a network path element that is used to gain access to specific resources. Authentication and trust must 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 does not necessarily need to remove the ability for network elements to perform beneficial functions. We should instead improve the way that these functions are achieved and design new ways to support explicit collaboration where it is seen as beneficial. As such, 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 addressing this gap by providing better alternatives and mechanisms for building functions that require some collaboration between endpoints and path elements.
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 ways network functions are achieved today, we find that many, if not most of them, fall short of the standard set up by the questions above. Too often, they send unnecessary information, fail to limit the scope of distribution, or fail to provide any negotiation or consent.
Designing explicit signals between applications and network elements, and ensuring that all information is appropriately protected, enables information exchange in both directions that is important for improving the quality of experience and network management. The clean separation provided by explicit signals is also more conducive to protocol evolvability.
Beyond the recommendation in [RFC 8558
], the IAB has provided further guidance on protocol design. Among other documents, [RFC 5218
] provides general advice on incremental deployability based on an analysis of successes and failures, and [RFC 6709
] discusses protocol extensibility. The Internet Technology Adoption and Transition (ITAT) workshop report [RFC 7305
] is also a recommended reading on this same general topic. [RFC 9049
], an IRTF document, provides a catalog of past issues to avoid and discusses incentives for adoption of path signals such as the need for outperforming end-to-end mechanisms or considering per-connection state.
This document discusses different approaches for explicit collaboration and provides guidance on architectural principles to design new mechanisms. Section 2
discusses principles that good design can follow. This section also provides examples and explores the consequences of not following these principles in those examples. Section 3
points to topics that need to be looked at more carefully before any guidance can be given.