Principles for the Involvement of Intermediaries in Internet Protocols
Mozilla
mt@lowentropy.net
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
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.
Introduction
The Internet owes much of its success to its application of the end-to-end
principle . 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 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 ()
- Limit the entities that can intermediate ()
- Limit what intermediaries can do ()
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.
What is Meant by Intermediary
A protocol intermediary is an element that participates in communications. An
intermediary is not the primary initiator or recipient of communications, but
instead acts to facilitate communications.
An intermediary need not be explicitly present at the request of a participant.
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
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.
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 include services
like the DNS. That said, though the DNS as a service does not result in
intermediation of other activities, there are roles for intermediaries within
the DNS that fit this definition, such as recursive resolvers.
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.
Thus, 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.
Intermediation Is Useful
That intermediaries provide access to valuable resources does not imply that
all intermediaries have exclusive control over access to resources. A router
might provide 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 aggregates demand from 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. 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.
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.
The goal of some intermediary deployments is to effect a policy, relying on the
ability of a well-placed intermediary to affect multiple protocol interactions
and participants.
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
, misinformation, or pervasive monitoring .
Intermediaries that can affect many people can therefore be powerful agents for
control. Though it is clear that 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.
Incentive Misalignment at Scale
A dependency on an intermediary can represent a risk to those that take the
dependency. The incentives and motives of intermediaries can be important to
consider.
For instance, the information necessary for an intermediary to performs its
function can often 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
obvious .
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; see (TODO
CHOKEPOINTS=I-D.iab-chokepoints).
Forced and Unwanted Intermediation
The ability to act as intermediary can offer more options than a service that is
called upon to provide information. Sometimes those advantages are enough to
justify the use of intermediation over alternative designs. However, the use of
an intermediary also introduces costs.
The use of transparent or interception proxies in 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.
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 or
. 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 . For example, measurement of TCP
showed that the protocol has poor prospects for extensibility due to widespread
use - and poor implementation - of intermediaries
.
Contention over Intermediation
The IETF has a long history of dealing with different forms of intermediation
poorly.
Early use of NAT was loudly decried by some in the IETF community. Indeed, the
use of NAT was regarded as an unwanted intrusion by intermediaries. The
eventual recognition - not endorsement - of the existence of NAT
(, ) allowed the community to engage
in the design protocols that properly handled NAT devices (,
) and to make recommendations for best practices
.
Like HTTP, SIP 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; ) 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 are sometimes intermediaries - is fiercely debated in the
context of TLS 1.3 , where the design renders certain practices
obsolete. Proposed uses of IPv6 header extensions in
called into question the
extent to which header extensions are the exclusive domain of endpoints as
opposed to being available to intermediaries.
It could be that the circumstances in each of these debates is different enough
that there is no singular outcome. The complications resulting from large-scale
deployments of great diversity might render a single clear outcome impossible
for an established protocol.
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 set out in three stages:
- Prefer designs without intermediaries ();
- Failing that, control which entities can intermediate the protocol
(); and
- Limit actions and information that are available to intermediaries
().
The use of technical mechanisms to ensure that these principles are enforced is
necessary. It is expected that protocols will need to use cryptography for
this.
New protocols should identify what intermediation is anticipated and provide
technical mechanisms to guarantee conformance. Modifying existing protocols to
follow these principles could be difficult, but worthwhile.
Prefer Services to Intermediaries
Protocols should prefer designs that do not involve additional participants,
such as intermediaries.
Designing protocols to use services rather than intermediaries ensures that
responsibilities of protocol participants are clearly defined. Where functions
can provided by means other than intermediation, the design should prefer that
alternative.
If there is a need for information, defining a means for querying a service for
that information is preferable to adding an intermediary. Similarly, direct
invocation of service to perform an action is better than involving that
service as a participant in the protocol.
Involving an entity as an intermediary can greatly increase the degree to which
that entity becomes a dependency. 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 to overheads. The cost of these
overheads need to be weighed against the recurrent costs from involving
intermediaries.
Preferring services is analogous to the software design principle that
recommends a preference for composition over inheritance .
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 , 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 principle likely requires the use of authentication and encryption.
Limit Capabilities of Intermediaries
Protocol participants should be able to limit the capabilities conferred to
other protocol participants.
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 . Where confidentiality is impossible or
impractical, integrity protection can be used to ensure that data origin
authentication is preserved; see .
Limit Information Exposure
Protocol participants should only have access to the information they need to
perform their designated function.
Protocol designs based on a principle of providing the minimum information
necessary have several benefits. In addition to 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 . In addition, integrity
protection should be applied to these signals to prevent modification.
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 for
ECN and ICMP , both of which 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.
Costs of Technical Constraints
Moving from a protocol in which there are two participants (such as
) 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 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.
Applying Non-Technical Constraints
Not all intermediary functions can be tightly constrained. For instance, as
described in , 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.
The use of authentication allows for other forms of control on intermediaries.
Auditing systems or other mechanisms for ensuring accountability can use
authentication information. Authentication can also enable the use of legal,
social, or other types of control that might cover any shortfall in technical
measures.
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:
-
describes effects of encryption on practices performed by
intermediaries;
-
describes a broader set of practices;
-
explores the effect on
transport-layer intermediaries in more detail; and
-
examines the effect of TLS on
operational network security practices.
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
deployed. In each case the protocols in question provided no technical controls
or only limited technical controls that prevent the addition of intermediaries.
This allowed the deployment of techniques that involved the insertion of
intermediaries into sessions without permission or knowledge of other protocol
participants. By adding controls like encryption, these practices are
disrupted. Overall, the advantages derived from having greater control and
knowledge of other protocol participants outweighs these costs.
The process of identifying critical functions for intermediaries is ongoing.
There are three potential classes of outcome of these discussion:
- Practices might be deemed valuable and methods that allow limited
participation by intermediaries will be added to protocols.
- The use case supported by the practice might be deemed valuable, but
alternative methods that address the use case without the use of an
intermediary will be sought.
- Practices might be deemed harmful and no replacement mechanism will be
sought.
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.
Security Considerations
Controlling the level of participation and access intermediaries have is a
security question. The principles in are fundamentally an
application of a security principle: namely the principle of least privilege
.
Lack of proper controls on intermediaries protocols has been the source of
significant security problems.
IANA Considerations
This document has no IANA actions.
Informative References
Design Patterns: Elements of Reusable Object-Oriented Software
End-to-end arguments in system design
Traversal Using Relays around NAT (TURN) Server Auto Discovery
Current Traversal Using Relays around NAT (TURN) server discovery mechanisms are relatively static and limited to explicit configuration. These are usually under the administrative control of the application or TURN service provider, and not the enterprise, ISP, or the network in which the client is located. Enterprises and ISPs wishing to provide their own TURN servers need auto-discovery mechanisms that a TURN client could use with minimal or no configuration. This document describes three such mechanisms for TURN server discovery.
This document updates RFC 5766 to relax the requirement for mutual authentication in certain cases.
Technical Considerations for Internet Service Blocking and Filtering
The Internet is structured to be an open communications medium. This openness is one of the key underpinnings of Internet innovation, but it can also allow communications that may be viewed as undesirable by certain parties. Thus, as the Internet has grown, so have mechanisms to limit the extent and impact of abusive or objectionable communications. Recently, there has been an increasing emphasis on "blocking" and "filtering", the active prevention of such communications. This document examines several technical approaches to Internet blocking and filtering in terms of their alignment with the overall Internet architecture. When it is possible to do so, the approach to blocking and filtering that is most coherent with the Internet architecture is to inform endpoints about potentially undesirable services, so that the communicants can avoid engaging in abusive or objectionable communications. We observe that certain filtering and blocking approaches can cause unintended consequences to third parties, and we discuss the limits of efficacy of various approaches.
Pervasive Monitoring Is an Attack
Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible.
I Know Why You Went to the Clinic: Risks and Realization of HTTPS Traffic Analysis
HTTP Semantics
The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP: its architecture, terminology, the "http" and "https" Uniform Resource Identifier (URI) schemes, core request methods, request header fields, response status codes, response header fields, and content negotiation. This document obsoletes RFC 2818, RFC 7231, RFC 7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, RFC 7694, and portions of RFC 7230.
Erosion of the moral authority of transparent middleboxes
Many middleboxes on the Internet attempt to add value to the connections that traverse that point on the network. Problems in their implementations erode the moral authority that otherwise might accrue to the legitimate value that they add.
Middleboxes: Taxonomy and Issues
This document is intended as part of an IETF discussion about "middleboxes" - defined as any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and destination host. This document establishes a catalogue or taxonomy of middleboxes, cites previous and current IETF work concerning middleboxes, and attempts to identify some preliminary conclusions. It does not, however, claim to be definitive. This memo provides information for the Internet community.
Long-term Viability of Protocol Extension Mechanisms
The ability to change protocols depends on exercising the extension and version negotiation mechanisms that support change. Protocols that don't use these mechanisms can find that deploying changes can be difficult and costly.
Is it still possible to extend TCP?
Architectural Implications of NAT
This document discusses some of the architectural implications and guidelines for implementations of Network Address Translation (NAT). This memo provides information for the Internet community.
IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation
IAB
As a result of the nature of Network Address Translation (NAT) Middleboxes, communicating endpoints that are separated by one or more NATs do not know how to refer to themselves using addresses that are valid in the addressing realms of their (current and future) peers. Various proposals have been made for "UNilateral Self-Address Fixing (UNSAF)" processes. These are processes whereby some originating endpoint attempts to determine or fix the address (and port) by which it is known to another endpoint - e.g., to be able to use address data in the protocol exchange, or to advertise a public address from which it will receive connections. This document outlines the reasons for which these proposals can be considered at best as short term fixes to specific problems and the specific issues to be carefully evaluated before creating an UNSAF proposal. This memo provides information for the Internet community.
Session Traversal Utilities for NAT (STUN)
Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with Network Address Translator (NAT) traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them. STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This document obsoletes RFC 5389.
Network Address Translation (NAT) Behavioral Requirements for Unicast UDP
This document defines basic terminology for describing different types of Network Address Translation (NAT) behavior when handling Unicast UDP and also defines a set of requirements that would allow many applications, such as multimedia communications or online gaming, to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
SIP: Session Initiation Protocol
This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS-TRACK]
A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents
In many SIP deployments, SIP entities exist in the SIP signaling path between the originating and final terminating endpoints, which go beyond the definition of a SIP proxy, performing functions not defined in Standards Track RFCs. The only term for such devices provided in RFC 3261 is for a Back-to-Back User Agent (B2BUA), which is defined as the logical concatenation of a SIP User Agent Server (UAS) and User Agent Client (UAC).
There are numerous types of SIP B2BUAs performing different roles in different ways; for example, IP Private Branch Exchanges (IPBXs), Session Border Controllers (SBCs), and Application Servers (ASs). This document identifies several common B2BUA roles in order to provide taxonomy other documents can use and reference.
The Transport Layer Security (TLS) Protocol Version 1.3
This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.
This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.
SRv6 Network Programming
The SRv6 Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet. This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization (Service Level Agreements).
Transport Protocol Path Signals
This document discusses the nature of signals seen by on-path elements examining transport protocols, contrasting implicit and explicit signals. For example, TCP's state machine uses a series of well-known messages that are exchanged in the clear. Because these are visible to network elements on the path between the two nodes setting up the transport connection, they are often used as signals by those network elements. In transports that do not exchange these messages in the clear, on-path network elements lack those signals. Often, the removal of those signals is intended by those moving the messages to confidential channels. Where the endpoints desire that network elements along the path receive these signals, this document recommends explicit signals be used.
Transport Protocol Path Signals
This document discusses the nature of signals seen by on-path elements examining transport protocols, contrasting implicit and explicit signals. For example, TCP's state machine uses a series of well-known messages that are exchanged in the clear. Because these are visible to network elements on the path between the two nodes setting up the transport connection, they are often used as signals by those network elements. In transports that do not exchange these messages in the clear, on-path network elements lack those signals. Often, the removal of those signals is intended by those moving the messages to confidential channels. Where the endpoints desire that network elements along the path receive these signals, this document recommends explicit signals be used.
QUIC: A UDP-Based Multiplexed and Secure Transport
This document defines the core of the QUIC transport protocol. Accompanying documents describe QUIC's loss detection and congestion control and the use of TLS for key negotiation. Note to Readers Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org (mailto:quic@ietf.org)), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=quic Working Group information can be found at https://github.com/quicwg; source code and issues list for this draft can be found at https://github.com/quicwg/base-drafts/labels/-transport.
The Addition of Explicit Congestion Notification (ECN) to IP
This memo specifies the incorporation of ECN (Explicit Congestion Notification) to TCP and IP, including ECN's use of two bits in the IP header. [STANDARDS-TRACK]
Internet Control Message Protocol
Effects of Pervasive Encryption on Operators
Pervasive monitoring attacks on the privacy of Internet users are of serious concern to both user and operator communities. RFC 7258 discusses the critical need to protect users' privacy when developing IETF specifications and also recognizes that making networks unmanageable to mitigate pervasive monitoring is not an acceptable outcome: an appropriate balance is needed. This document discusses current security and network operations as well as management practices that may be impacted by the shift to increased use of encryption to help guide protocol development in support of manageable and secure networks.
An Inventory of Transport-Centric Functions Provided by Middleboxes: An Operator Perspective
This document summarizes an operator's perception of the benefits that may be provided by intermediary devices that execute functions beyond normal IP forwarding. Such intermediary devices are often called "middleboxes".
RFC 3234 defines a taxonomy of middleboxes and issues in the Internet. Most of those middleboxes utilize or modify application- layer data. This document primarily focuses on devices that observe and act on information carried in the transport layer, and especially information carried in TCP packets.
Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols
To protect user data and privacy, Internet transport protocols have supported payload encryption and authentication for some time. Such encryption and authentication is now also starting to be applied to the transport protocol headers. This helps avoid transport protocol ossification by middleboxes, while also protecting metadata about the communication. Current operational practice in some networks inspect transport header information within the network, but this is no longer possible when those transport headers are encrypted. This document discusses the possible impact when network traffic uses a protocol with an encrypted transport header. It suggests issues to consider when designing new transport protocols or features. These considerations arise from concerns such as network operations, prevention of network ossification, enabling transport protocol evolution and respect for user privacy.
Impact of TLS 1.3 to Operational Network Security Practices
Network-based security solutions are used by enterprises, the public sector, internet-service providers, and cloud-service providers to both complement and enhance host-based security solutions. As TLS is a widely deployed protocol to secure communication, these network- based security solutions must necessarily interact with it. This document describes this interaction for current operational security practices and notes the impact of TLS 1.3 on them.
Protection and the control of information sharing in multics
Guidelines for Writing RFC Text on Security Considerations
All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture
IAB
The end-to-end principle is the core architectural guideline of the Internet. In this document, we briefly examine the development of the end-to-end principle as it has been applied to the Internet architecture over the years. We discuss current trends in the evolution of the Internet architecture in relation to the end-to-end principle, and try to draw some conclusion about the evolution of the end-to-end principle, and thus for the Internet architecture which it supports, in light of these current trends. This memo provides information for the Internet community.
Acknowledgments
This document is merely an attempt to codify existing practice. Practice that
is inspired, at least in part, by prior work, including and
which both advocate for clearer articulation of trust boundaries.
Eric Rescorla and David Schinazi are acknowledged for their contributions of
thought, review, and text.