Internet DRAFT - draft-thomson-tmi
draft-thomson-tmi
Network Working Group M. Thomson
Internet-Draft Mozilla
Intended status: Informational 8 September 2022
Expires: 12 March 2023
Principles for the Involvement of Intermediaries in Internet Protocols
draft-thomson-tmi-04
Abstract
This document proposes a set of principles for designing protocols
with rules for intermediaries. The goal of these principles is to
limit the ways in which intermediaries can produce undesirable
effects and to protect the useful functions that intermediaries
legitimately provide.
Discussion Venues
This note is to be removed before publishing as an RFC.
Discussion of this document takes place on the IAB Model-T list
(modelt@iab.org), which is archived at
https://mailarchive.ietf.org/arch/browse/model-t/.
Source for this draft and an issue tracker can be found at
https://github.com/martinthomson/tmi.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 12 March 2023.
Thomson Expires 12 March 2023 [Page 1]
Internet-Draft Too Much Intermediation September 2022
Copyright Notice
Copyright (c) 2022 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. What is Meant by Intermediary . . . . . . . . . . . . . . . . 3
3. Intermediation Is Essential . . . . . . . . . . . . . . . . . 4
4. Intermediation Is Useful . . . . . . . . . . . . . . . . . . 5
5. Intermediation Enables Scaling Of Control . . . . . . . . . . 5
6. Incentive Misalignment at Scale . . . . . . . . . . . . . . . 6
7. Forced and Unwanted Intermediation . . . . . . . . . . . . . 6
8. Contention over Intermediation . . . . . . . . . . . . . . . 7
9. Proposed Principles . . . . . . . . . . . . . . . . . . . . . 8
9.1. Prefer Services to Intermediaries . . . . . . . . . . . . 9
9.2. Deliberately Select Protocol Participants . . . . . . . . 10
9.3. Limit Capabilities of Intermediaries . . . . . . . . . . 10
9.3.1. Limit Information Exposure . . . . . . . . . . . . . 10
9.3.2. Limit Permitted Interactions . . . . . . . . . . . . 11
9.3.3. Costs of Technical Constraints . . . . . . . . . . . 11
10. Applying Non-Technical Constraints . . . . . . . . . . . . . 12
11. The Effect on Existing Practices . . . . . . . . . . . . . . 12
12. Security Considerations . . . . . . . . . . . . . . . . . . . 13
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
14. Informative References . . . . . . . . . . . . . . . . . . . 14
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
The Internet owes much of its success to its application of the end-
to-end principle [E2E]. The realization that efficiency is best
served by moving higher-level functions to endpoints is a key insight
in system design, but also a key element of the success of the
Internet.
This does not mean that the Internet avoids a relying on functions
provided by entities in the network. While the principle establishes
that some functions are best provided by endsystems, this does not
exclude all intermediary functions. Some level of function in the
Thomson Expires 12 March 2023 [Page 2]
Internet-Draft Too Much Intermediation September 2022
network is necessary, or else there would be no network. The ways in
which intermediaries can assist protocol endpoints are numerous and
constantly evolving.
This document explores some of the ways in which intermediaries make
both essential and valuable contributions to the function of the
system. Problems arise when the interests of intermediaries are
poorly aligned with those of endpoints. This can result in systemic
costs and tension. Addressing those issues can be difficult.
This document proposes the following design principles for the
protocols that might involve the participation of intermediaries:
* Avoid intermediation (Section 9.1)
* Limit the entities that can intermediate (Section 9.2)
* Limit what intermediaries can do (Section 9.3)
These principles aim to provide clarity about the roles and
responsibilities of protocol participants. These principles produce
more robust protocols with better privacy and security properties.
These also limit the secondary costs associated with intermediation.
2. What is Meant by Intermediary
An intermediary is an element that participates in a protocol
exchange. An intermediary receives protocol units, such as packets
or messages, and forwards the protocol units to other protocol
participants. An intermediary might make changes to protocol units
or leave the content of the unit unchanged.
An intermediary often does not directly benefit from the protocol
exchange, but instead acts to facilitate the exchange. An
intermediary often participates at the request of another participant
in the protocol, which might be an endpoint or an intermediary.
Intermediaries exist at all layers of the stack. A router is an
intermediary that acts at the network layer to forward packets. A
TURN relay [RFC8155] provides similar forwarding capability for UDP
in the presence of a network address translator (NAT) -- a different
type of intermediary that provides the ability to share a limited
supply of addresses. At higher layers of the stack, group messaging
servers intermediate the exchange of messages within groups of
people; a conference focus aids the sending of media group real-time
communications; and a social network intermediates communication and
information sharing through the exchange of messages and formation of
groups.
Thomson Expires 12 March 2023 [Page 3]
Internet-Draft Too Much Intermediation September 2022
A person uses a networked computer as an intermediary for their
communications with other people and computers. This intermediation
is essential, for users are unable to directly interact with a
network. Much of the guidance in this document does not apply to the
relationship between users and user agents; see [RFC8890],
Section 4.2 in particular, for an examination of this topic.
An intermediary at one layer of the stack is often an endpoint for
communication at a lower layer. A Diameter peer [DIAMETER] acts as
an intermediary when it forwards requests to other peers. However, a
Diameter peer establishes connections to neighboring peers using TLS/
TCP or DTLS/SCTP and acts as a endpoint for all of those protocols.
It is possible to facilitate communication without being an
intermediary. The DNS provides information that is critical to
locating and communicating with other Internet hosts, but it does so
without intermediating those communications. Thus, this definition
of intermediary does not necessarily include a service like the DNS.
Of course, the use of the DNS could involve engaging with
intermediaries such as recursive resolvers.
3. Intermediation Is Essential
Intermediaries are essential to scalable communications. The service
an intermediary provides usually involves access to resources that
would not otherwise be available. For instance, the Internet does
not function without routers that enable packets to reach other
networks.
There is some level of intermediation that is essential for the
proper functioning of the Internet.
Scalable solutions to the introduction problem often depend on
services that provide access to information and capabilities. As it
is with the network layer of the Internet, the use of an intermediary
can be absolutely essential. For example, a social networking
application acts as an intermediary that provides a communications
medium, content discovery and publication, and related services.
Video conferencing applications often depend on an intermediary that
mixes audio and selectively forwards video so that bandwidth
requirements don't increase beyond what is available for participants
as conferences grow in size.
Thomson Expires 12 March 2023 [Page 4]
Internet-Draft Too Much Intermediation September 2022
4. Intermediation Is Useful
Not all intermediaries have exclusive control access to the resources
they provide access to. A router might facilitate access to other
networks, but similar access might be obtained via a different route.
The same web content might be provided by multiple CDNs. Multiple
DNS resolvers can provide answers to the same queries. The ability
to access the same capabilities from multiple entities contributes
greatly to the robustness of a system.
Intermediaries often provide capabilities that benefit from economies
of scale by providing a service that serves multiple individuals.
For instance, individuals are unlikely to be in a position to
negotiate connections to multiple networks, but an ISP can.
Similarly, an individual might find it difficult to acquire the
capacity necessary to withstand a DDoS attack, but the scale at which
a CDN operates means that this capacity is likely available to it.
Or the value of a social network is in part due to the existing
participation of other people.
Aggregation also provides other potential benefits. For instance,
caching of shared information can allow for performance advantages.
From an efficiency perspective, the use of shared resources might
allow load to be more evenly distributed over time. Or, for privacy,
individual activity might be mixed with the activity of many others,
thereby making it difficult to isolate that activity.
The ability of an intermediary to operate at scale can therefore
provide a number of different benefits to performance, scalability,
privacy, and other areas.
5. Intermediation Enables Scaling Of Control
An action by an intermediary can affect all who communicate using
that intermediary. For an intermediary that operates at scale, this
means it can be seen as an effective control point.
In addition to facilitating communications, some intermediary
deployments aim to effect a policy. This relies on the ability of a
well-placed intermediary to affect multiple protocol interactions and
participants.
Thomson Expires 12 March 2023 [Page 5]
Internet-Draft Too Much Intermediation September 2022
The ability of an intermediary to affect a large number of network
users can be an advantage or vulnerability, depending on perspective.
For instance, network intermediaries have been used to distribute
warnings of impending natural disasters like fire, flood, or
earthquake, which save lives and property. In contrast, control over
large-scale communications can enable censorship [RFC7754],
misinformation [PARADOX], or pervasive monitoring [RFC7258].
Intermediaries that can affect many people can therefore be powerful
agents for control. While the morality of actions taken can be
subjective, network users have to consider the potential for the
power they vest in intermediaries to be abused or subverted.
6. Incentive Misalignment at Scale
A dependency on an intermediary represents a risk to those that take
the dependency. The incentives and motives of intermediaries can be
important to consider when choosing to use an intermediary.
For instance, the information an intermediary needs to perform its
function might be used (or abused) for other purposes. Even the
simple function of forwarding necessarily involves information about
who was communicating, when, and the size of messages. This can
reveal more than is trivially apparent [CLINIC].
As uses of networks become more diverse, the extent that incentives
for intermediaries and network users align reduce. In particular,
acceptance of the costs and risks associated with intermediation by a
majority of network users does not mean that all users have the same
expectations and requirements. This can be a significant problem if
it becomes difficult to avoid or refuse participation by a particular
intermediary.
A dependency on an intermediary, particularly a technically or
operationally challenging dependency, can reduce the number of viable
choices of intermediary operators. Reduced choice can lead to
dependence on specific intermediaries, which reduces resilience and
exposes endpoints to greater potential for abuse.
7. Forced and Unwanted Intermediation
The ability to act as intermediary can offer more options than a
service that is called upon to provide information or services as
needed. Sometimes those advantages are enough to justify the use of
intermediation over alternative designs. However, the use of an
intermediary also introduces costs.
Thomson Expires 12 March 2023 [Page 6]
Internet-Draft Too Much Intermediation September 2022
The use of transparent or interception proxies in HTTP [HTTP] is an
example of a practice that has fallen out of common usage due to
increased use of HTTPS. Use of transparent proxies was once
widespread with a wide variety of reasons for their deployment.
However, transparent proxies were involved in many abuses, such as
unwanted transcoding of content and insertion of identifiers to the
detriment of individual privacy [X-UIDH].
Introducing intermediaries is often done with the intent of avoiding
disruption to protocols that operate a higher layer of the stack.
However, network layering abstractions often leak, meaning that the
effects of the intermediation can be observed. Where those effects
cause problems, it can be difficult to detect and fix those problems.
The insertion of an intermediary in a protocol imposes other costs on
other protocol participants; see [EROSION] or [MIDDLEBOX]. In
particular, poor implementations of intermediaries can adversely
affect protocol operation.
As an intermediary is another participant in a protocol, they can
make interactions less robust. Intermediaries can also be
responsible for ossification, or the inability to deploy new protocol
mechanisms; see Section 2.3 of [USE-IT]. For example, measurement of
TCP showed that the protocol has poor prospects for extensibility due
to widespread use -- and poor implementation -- of intermediaries
[TCP-EXTEND].
Some forms of intermediation have been deployed without consulting
the endpoints involved in the protocol. As protocols evolve or a
more diverse set of deployments are encountered, assumptions that
might have been valid at the time the intermediary was deployed might
not hold. For example, some intermediaries identified a very early
version of QUIC [RFC9000] by checking that the first byte of the UDP
payload was to to a value of 0x07. As this version used the
different bits in this byte to signal different protocol options,
when endpoints started to exercise the options represented by other
values the classification failed.
8. Contention over Intermediation
The IETF has a long history of dealing with different forms of
intermediation.
A debate about the intent and purpose of IPv6 extension headers
[IPv6] occurred prior to the publication of RFC 8986 [SRv6], in
particular, it's PSP (Penultimate Segment Pop) mode. Here, the use
of extension headers by entities other than the communication
endpoints -- that is, intermediaries -- was contested. As the
Thomson Expires 12 March 2023 [Page 7]
Internet-Draft Too Much Intermediation September 2022
purpose of this feature is to communicate routing information between
intermediaries, this could be seen as a form of tunneling between the
communicating routers that uses the ability of IPv6 intermediaries
(or routers) to add or remove extension headers.
Like HTTP, SIP [RFC3261] defines a role for a proxy, which is a form
of intermediary with limited ability to interact with the session
that it facilitates. In practice, many deployments instead choose to
deploy some form of Back-to-Back UA (B2BUA; [RFC7092]) for reasons
that effectively reduce to greater ability to implement control
functions.
There are several ongoing debates in the IETF that are rooted in
disagreement about the rule of intermediaries. The interests of
network-based devices -- which sometimes act as TLS intermediaries --
is fiercely debated in the context of TLS 1.3 [TLS], where the design
renders certain practices obsolete.
The functions provided by intermediaries in different protocols can
be dramatically different. Even within the one protocol, the same
protocol might be deployed to address many different needs. For an
existing protocol with wide deployment, there might not be a single,
easy method for managing the integration of the functions that
intermediaries provide.
9. Proposed Principles
Many problems caused by intermediation are the result of
intermediaries that are introduced without the involvement of
protocol endpoints. Limiting the extent to which protocol designs
depend on intermediaries makes the resulting system more robust.
These principles are progressive, with three stages:
1. Prefer designs without intermediaries (Section 9.1);
2. Failing that, control which entities can intermediate the
protocol (Section 9.2); and
3. Limit actions and information that are available to
intermediaries (Section 9.3).
The use of technical mechanisms to ensure that these principles are
enforced is encouraged. It is expected that protocols will need to
use cryptography for this.
Thomson Expires 12 March 2023 [Page 8]
Internet-Draft Too Much Intermediation September 2022
New protocol designs therefore need to identify what intermediation
is possible and what is desired. Technical mechanisms to guarantee
conformance, where possible, are highly recommended.
Modifying existing protocols to follow these principles could be
difficult, but worthwhile.
9.1. Prefer Services to Intermediaries
Where protocol functions can provided by a service or a means other
than intermediation, the design should prefer that alternative.
Designing protocols to use services rather than intermediaries
ensures that responsibilities of protocol participants are clearly
defined.
If there is a need for information, defining a means for querying a
service for that information is preferable to allowing an
intermediary to add information during an exchange. Similarly,
direct invocation of service to perform an action is better than
involving that service as a participant in the protocol.
Involving an intermediary in a protocol means depending on that
intermediary for every aspect of protocol functioning. For example,
it might be necessary to negotiate the use of new capabilities with
all protocol participants, including the intermediary, even when the
functions for which the intermediary was added are not affected. It
is also more difficult to limit the extent to which a protocol
participant can be involved than a service that is invoked for a
specific task.
Using discrete services is not always the most performant
architecture as additional network interactions can add latency or
other overheads. The cost of these overheads need to be weighed
against the recurrent costs from the involvement of intermediaries.
The contribution of an intermediary to performance and efficiency can
involve trade-offs, such as those discussed in Section 2.3 of [E2E].
One consideration is the potential need for critical functions to be
replicated in both intermediaries and endpoints, reducing efficiency.
Another is the possibility that an intermediary optimized for one
application could degrade performance in other applications.
Preferring services is analogous to the software design principle
that recommends a preference for composition over inheritance
[PATTERNS].
Thomson Expires 12 March 2023 [Page 9]
Internet-Draft Too Much Intermediation September 2022
9.2. Deliberately Select Protocol Participants
Protocol participants should know what other participants they might
be interacting with, including intermediaries.
Protocols that permit the involvement of an intermediary need to do
so intentionally and provide measures that prevent the addition of
unwanted intermediaries. Ideally, all protocol participants are
identified and known to other protocol participants.
The addition of an unwanted protocol participant is an attack on the
protocol.
This is an extension of the conclusion of [PATH-SIGNALS], which:
| 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.
Applying this principle likely requires the use of authentication and
encryption.
9.3. Limit Capabilities of Intermediaries
Protocol participants should be able to limit the capabilities
conferred to other protocol participants. Though this applies to all
participants, intermediaries often have narrowly-defined roles.
Where the potential for intermediation already exists, or
intermediaries provide essential functions, protocol designs should
limit the capabilities and information that protocol participants are
required to grant others.
Limiting the information that participants are required to provide to
other participants has benefits for privacy or to limit the potential
for misuse of information; see Section 9.3.1. Where confidentiality
is impossible or impractical, integrity protection can be used to
ensure that data origin authentication is preserved; see
Section 9.3.2.
9.3.1. Limit Information Exposure
Protocol participants should only have access to the information they
need to perform their designated function.
Thomson Expires 12 March 2023 [Page 10]
Internet-Draft Too Much Intermediation September 2022
Protocol designs based on a principle of providing the minimum
information necessary have several benefits. In addition to
simplicity, requiring smaller messages, or fewer exchanges, reducing
information provides greater control over exposure of information.
This has privacy benefits.
Where an intermediary needs to carry information that it has no need
to access, protocols should use encryption to ensure that the
intermediary cannot access that information.
Providing information for intermediaries using signals that are
separate from other protocol signaling is preferable [PATH-SIGNALS].
In addition, integrity protection should be applied to these signals
to prevent modification.
9.3.2. Limit Permitted Interactions
An action should only be taken based on signals from protocol
participants that are authorized to request that action.
Where an intermediary needs to communicate with other protocol
participants, ensure that these signals are attributed to an
intermediary. Authentication is the best means of ensuring signals
generated by protocol participants are correctly attributed.
Authentication informs decisions protocol participants make about
actions they take.
In some cases, particularly protocols that are primarily two-party
protocols, it might be sufficient to allow the signal to be
attributed to any intermediary. This is the case in QUIC [RFC9000]
where ECN [ECN] and ICMP [ICMP] signals are assumed to be provided by
elements on the network path. Limited mechanisms exist to
authenticate these as signals that originate from path elements,
informing actions taken by endpoints. Consequently, the actions that
can be taken in response to these signals is limited.
9.3.3. Costs of Technical Constraints
Moving from a protocol in which there are two participants (such as
[TLS]) to more than two participants can be more complex and
expensive to implement and deploy.
More generally, the application of technical measures to control how
intermediaries participate in a protocol incur costs that manifest in
several ways. Protocols are more difficult to design;
implementations are larger and more complex; and deployments might
suffer from added operational costs, higher computation loads, and
more bandwidth consumption. These costs are reflective of the true
Thomson Expires 12 March 2023 [Page 11]
Internet-Draft Too Much Intermediation September 2022
cost of involving additional entities in protocols. In protocols
without technical measures to limit participation, these costs have
historically been borne by other protocol participants.
In general however, most protocols are able to reuse existing
mechanisms for cryptographic protection, such as TLS [TLS]. Adopting
something like TLS provides security properties that are well
understood and analyzed. Using a standardized solution enables use
of well-tested implementations that include optimizations and other
mitigations for these costs.
10. Applying Non-Technical Constraints
Not all intermediary functions can be tightly constrained. For
instance, as described in Section 6, some functions involve granting
intermediaries access to information that can be used for more than
its intended purpose. Applying strong technical constraints on how
that information is used might be infeasible or impossible.
Systems that audit the involvement in protocols can use
authentication to improve accountability. Authentication can enable
the use of legal, social, or other types of control that might cover
any shortfall in technical measures.
11. The Effect on Existing Practices
The application of these principles can have an effect on existing
operational practices, particularly where they rely on protocols not
limiting intermediary access. Several documents have explored
aspects of this in detail:
* [RFC8404] describes effects of encryption on practices performed
by intermediaries;
* [RFC8517] describes a broader set of practices;
* [RFC9065] explores the effect on transport-layer intermediaries in
more detail; and
* [NS-IMPACT] examines the effect of TLS on operational network
security practices.
Thomson Expires 12 March 2023 [Page 12]
Internet-Draft Too Much Intermediation September 2022
In all these documents, the defining characteristic is the move from
a system that lacked controls on participation to one in which
technical controls are employed. In each case, the protocols in
question provided little or no technical controls that prevented the
addition of intermediaries. This allowed for the insertion of
intermediaries into sessions without permission or knowledge of other
protocol participants. Adding controls like encryption and
authentication disrupts these practices.
Overall, the advantages derived from having greater control over or
knowledge of other protocol participants outweighs these costs.
In these settings, finding ways for intermediaries to contribute is
an ongoing process. When looking at how intermediaries contributed
to protocols operation prior to the introduction of technical
controls there are three potential classes of outcome of these
discussion:
* Practices might be deemed valuable. Facilities might be added to
protocols to allow or encourage those practices.
* The use case supported by the practice might be deemed valuable,
but the existence of a superior alternative approach could make
further effort unnecessary.
* Practices might be deemed harmful, such that no replacement
mechanism is needed.
Many factors could influence the outcome of this analysis. For
instance, deployment of alternative methods or limited roles for
intermediaries could be relatively simple for new protocol
deployments; whereas it might be challenging to retrofit controls on
existing protocol deployments.
12. Security Considerations
Understanding how intermediaries participate is highly relevant to
the security of a protocol. The principles in Section 9 are
fundamentally an application of a security principle: namely the
principle of least privilege [LEAST-PRIVILEGE].
Lack of proper controls on intermediaries in protocols has been the
source of significant security problems. A protocol is not secure if
it fails to prevent an intermediary from consuming, modifying, or
generating protocol units in ways that are contrary to the interests
of other protocol participants.
Thomson Expires 12 March 2023 [Page 13]
Internet-Draft Too Much Intermediation September 2022
13. IANA Considerations
This document has no IANA actions.
14. Informative References
[CLINIC] Miller, B., Huang, L., Joseph, A., and J. Tygar, "I Know
Why You Went to the Clinic: Risks and Realization of HTTPS
Traffic Analysis", Privacy Enhancing Technologies pp.
143-163, DOI 10.1007/978-3-319-08506-7_8, 2014,
<https://doi.org/10.1007/978-3-319-08506-7_8>.
[DIAMETER] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
Ed., "Diameter Base Protocol", RFC 6733,
DOI 10.17487/RFC6733, October 2012,
<https://www.rfc-editor.org/rfc/rfc6733>.
[E2E] Saltzer, J., Reed, D., and D. Clark, "End-to-end arguments
in system design", ACM Transactions on Computer
Systems vol. 2, no. 4, pp. 277-288,
DOI 10.1145/357401.357402, November 1984,
<https://doi.org/10.1145/357401.357402>.
[ECN] 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/rfc/rfc3168>.
[EROSION] Hildebrand, J. and P. McManus, "Erosion of the moral
authority of transparent middleboxes", Work in Progress,
Internet-Draft, draft-hildebrand-middlebox-erosion-01, 10
November 2014, <https://datatracker.ietf.org/doc/html/
draft-hildebrand-middlebox-erosion-01>.
[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/rfc/rfc9110>.
[ICMP] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/rfc/rfc792>.
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/rfc/rfc8200>.
Thomson Expires 12 March 2023 [Page 14]
Internet-Draft Too Much Intermediation September 2022
[LEAST-PRIVILEGE]
Saltzer, J., "Protection and the control of information
sharing in multics", Communications of the ACM vol. 17,
no. 7, pp. 388-402, DOI 10.1145/361011.361067, July 1974,
<https://doi.org/10.1145/361011.361067>.
[MIDDLEBOX]
Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002,
<https://www.rfc-editor.org/rfc/rfc3234>.
[NS-IMPACT]
Cam-Winget, N., Wang, E., Danyliw, R., and R. DuToit,
"Impact of TLS 1.3 to Operational Network Security
Practices", Work in Progress, Internet-Draft, draft-ietf-
opsec-ns-impact-04, 26 January 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-opsec-
ns-impact-04>.
[PARADOX] Valenzuela, S., Halpern, D., Katz, J., and J. Miranda,
"The Paradox of Participation Versus Misinformation:
Social Media, Political Engagement, and the Spread of
Misinformation", Digital Journalism vol. 7, no. 6, pp.
802-823, DOI 10.1080/21670811.2019.1623701, June 2019,
<https://doi.org/10.1080/21670811.2019.1623701>.
[PATH-SIGNALS]
Hardie, T., Ed., "Transport Protocol Path Signals",
RFC 8558, DOI 10.17487/RFC8558, April 2019,
<https://www.rfc-editor.org/rfc/rfc8558>.
[PATTERNS] Gamma, E., Helm, R., Johnson, R., and J. Vlissides,
"Design Patterns: Elements of Reusable Object-Oriented
Software", 1994.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/rfc/rfc3261>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/rfc/rfc3552>.
Thomson Expires 12 March 2023 [Page 15]
Internet-Draft Too Much Intermediation September 2022
[RFC3724] Kempf, J., Ed., Austein, R., Ed., and IAB, "The Rise of
the Middle and the Future of End-to-End: Reflections on
the Evolution of the Internet Architecture", RFC 3724,
DOI 10.17487/RFC3724, March 2004,
<https://www.rfc-editor.org/rfc/rfc3724>.
[RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session
Initiation Protocol (SIP) Back-to-Back User Agents",
RFC 7092, DOI 10.17487/RFC7092, December 2013,
<https://www.rfc-editor.org/rfc/rfc7092>.
[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/rfc/rfc7258>.
[RFC7754] Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E.
Nordmark, "Technical Considerations for Internet Service
Blocking and Filtering", RFC 7754, DOI 10.17487/RFC7754,
March 2016, <https://www.rfc-editor.org/rfc/rfc7754>.
[RFC8155] Patil, P., Reddy, T., and D. Wing, "Traversal Using Relays
around NAT (TURN) Server Auto Discovery", RFC 8155,
DOI 10.17487/RFC8155, April 2017,
<https://www.rfc-editor.org/rfc/rfc8155>.
[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/rfc/rfc8404>.
[RFC8517] Dolson, D., Ed., Snellman, J., Boucadair, M., Ed., and C.
Jacquenet, "An Inventory of Transport-Centric Functions
Provided by Middleboxes: An Operator Perspective",
RFC 8517, DOI 10.17487/RFC8517, February 2019,
<https://www.rfc-editor.org/rfc/rfc8517>.
[RFC8890] Nottingham, M., "The Internet is for End Users", RFC 8890,
DOI 10.17487/RFC8890, August 2020,
<https://www.rfc-editor.org/rfc/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/rfc/rfc9000>.
Thomson Expires 12 March 2023 [Page 16]
Internet-Draft Too Much Intermediation September 2022
[RFC9065] Fairhurst, G. and C. Perkins, "Considerations around
Transport Header Confidentiality, Network Operations, and
the Evolution of Internet Transport Protocols", RFC 9065,
DOI 10.17487/RFC9065, July 2021,
<https://www.rfc-editor.org/rfc/rfc9065>.
[SRv6] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/rfc/rfc8986>.
[TCP-EXTEND]
Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A.,
Handley, M., and H. Tokuda, "Is it still possible to
extend TCP?", Proceedings of the 2011 ACM SIGCOMM
conference on Internet measurement conference - IMC '11,
DOI 10.1145/2068816.2068834, 2011,
<https://doi.org/10.1145/2068816.2068834>.
[TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>.
[USE-IT] Thomson, M. and T. Pauly, "Long-Term Viability of Protocol
Extension Mechanisms", RFC 9170, DOI 10.17487/RFC9170,
December 2021, <https://www.rfc-editor.org/rfc/rfc9170>.
[X-UIDH] "Verizon Wireless’ use of a Unique Identifier Header
(UIDH)", 19 October 2012,
<https://www.verizon.com/about/news/vzw/2012/10/verizon-
wireless-privacy-policy>.
Appendix A. Acknowledgments
This document is merely an attempt to codify existing practice.
Practice that is inspired, at least in part, by prior work, including
[RFC3552] and [RFC3724] which both advocate for clearer articulation
of trust boundaries.
Jari Arkko, Eric Rescorla, and David Schinazi are acknowledged for
their contributions of thought, review, and text.
Author's Address
Martin Thomson
Mozilla
Email: mt@lowentropy.net
Thomson Expires 12 March 2023 [Page 17]
