]>

Prahran Australia mnot@mnot.net https://www.mnot.net/

General regulation Despite being designed and operated as a decentralized network-of-networks, the Internet is continuously subjected to forces that encourage centralization. This document offers a definition of centralization, explains why it is undesirable, identifies different types of centralization, catalogues limitations of common approaches to controlling it, and explores what Internet standards efforts can do to address it. About This Document Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction The Internet has succeeded in no small part because of its purposeful avoidance of any single controlling entity. While this approach may reflect a desire to prevent a single technical failure from having wide impact , it has also enabled the Internet's rapid adoption and broad spread. Because internetworking does not require a network to get permission from or cede control to another entity, it accommodates a spectrum of requirements and is positioned as a public good. While avoiding centralization of control over the Internet remains a widely shared goal, achieving it consistently has proven difficult. Many successful protocols and applications on the Internet today work in a centralized fashion -- to the point where some proprietary, centralized services have become so well-known that they are commonly mistaken for the Internet itself. Even when protocols incorporate techniques intended to prevent centralization, economic and social factors can drive users to prefer centralized solutions built with or on top of supposedly decentralized technology. These difficulties call into question what role architectural regulation -- in particular, that in open standards bodies such as the IETF -- should play in preventing, mitigating, and controlling Internet centralization. This document discusses aspects of centralization that relate to Internet standards efforts. provides a definition of centralization. explains when and why centralization of the Internet's core functions is undesirable. surveys the different kinds of centralization that might surface on the Internet. then catalogues high-level approaches to mitigating centralization and discusses their limitations. Finally, considers the role that Internet standards play in avoiding centralization and mitigating its effects. Engineers who design and standardize Internet protocols are the primary audience for this document. However, designers of proprietary protocols can benefit from considering aspects of centralization, especially if they intend their protocol to be considered for eventual standardisation. Likewise, policymakers can use this document to help identify and remedy inappropriately centralized protocols and applications.

What is Centralization? This document defines "centralization" as the ability of a single entity or a small group of them to exclusively observe, capture, control, or extract rent from the operation or use of a Internet function. Here, "entity" could be a single person, a corporation, or a government. It does not include an organisation that operates in a manner that effectively mitigates centralisation (see ). "Internet function" is defined broadly. It might be an enabling protocol already defined by standards, such as IP , BGP , TCP , or HTTP . It might also be a proposal for a new enabling protocol, or an extension to an existing one. However, the Internet's functions are not limited to standards-defined protocols. User-visible applications built on top of standard protocols are also vulnerable to centralization -- for example, social networking, file sharing, financial services, and news dissemination. Likewise, networking equipment, hardware, operating systems, and software act as enabling technologies that can exhibit centralization risk. The supply of Internet connectivity itself can also be subject to the forces of centralization. Centralization risk is strongest when it affects the entire Internet. However, it can also be present when a substantial portion of the Internet's users lack options for a function. For example, if there is only one provider for a function in a region or legal jurisdiction, that function is effectively centralized for those users. Likewise, if there is a single entity providing a function, it is obviously centralized. However, centralization risk can also be present when there is friction against switching to a substitute, because external factors can more easily promote concentration (see ). For example, if switching requires a significant amount of time, resources, expertise, coordination, loss of functionality, or effort, centralization risk is indicated. Note that availability is related to but distinct from centralization. For example, if my e-mail provider uses only one server, that server might go down and thus block my access to that function. However, this alone is not a cause of centralization risk. "Decentralization" is the process of identifying centralization risk related to a function, followed by the application of techniques used to prevent or mitigate that risk. Decentralization does not require that provision of a function need be so widely distributed that other important factors are sacrificed. Because centralization can have beneficial effects (see ), the techniques used to decentralize a given function might vary, with the optimal balance being determined by many factors. Notably, a function that is only available through a relatively small number of providers can still be effectively decentralized (see, for example, the Domain Name System ). Therefore, discussions of centralization and architectural efforts at decentralization need to be made on a case-by-base basis, depending on the function in question, surrounding circumstances, and other regulatory mechanisms. Note that it is important to distinguish centralization from anti-competitive concerns (also known as "anti-trust"). While there are many interactions between these concepts and making provision of the Internet's functions more competitive may be a motivation for avoiding centralization, only courts are authoritative in determining what is and is not anti-competitive in a market, not standards bodies and other technical fora.

When Centralization is Undesirable Centralization is not always problematic, and is sometimes even desirable. If a function is specific to a given entity -- for example, a person's web site, or a government service -- it is expected that it be controlled by them alone. Emerging applications are often significantly less complex and more efficient to deploy as proprietary rather than decentralized functions. Some functions (such as the Internet standards process itself) even require central control to assure interoperability and application of shared goals and architectural principles. However, when any function becomes widespread enough in use and especially when it becomes a platform for other functions to be built upon, it deserves more scrutiny for centralization risk. Centralization of these functions is problematic when there are not effective mitigations in place (see ), for a variety of reasons. First, the Internet's very nature is incompatible with centralization of its functions. As a "large, heterogeneous collection of interconnected systems" the Internet is often characterised as a "network of networks". These networks relate as peers who agree to facilitate communication, rather than having a relationship of subservience to others' requirements or coercion by them. This focus on independence of action carries through the way the network is architected -- for example, in the concept of an "autonomous system". Second, when a third party has unavoidable access to communications, the "informational and positional advantages" gained can be used to observe behavior (the "panopticon effect") and shape or even deny behaviour (the "chokepoint effect") -- which can be used by those parties (or the states that have authority over them) for coercive ends or to disrupt society itself. Just as good governance of states requires separation of powers , so too does good governance of the Internet require that power not be concentrated in one place. Finally, centralization of an important function can have deleterious effects on the Internet itself, including:

• Limiting Innovation: Centralization can preclude the possibility of "permissionless innovation" -- the ability to deploy new, unforeseen applications without requiring coordination with parties other than those you are communicating with.
• Constraining Competition: The Internet and its users benefit from robust competition when applications and services are available from many providers -- especially when those users can build their own applications and services based upon interoperable standards. When functions form dependencies on a centralized service or platform because no substitutes are suitable, it effectively becomes an essential facility, which encourages abuse of power.
• Reducing Availability: The Internet's availability (as well as applications and services built upon it) improves when there are many ways to obtain access. While centralized services typically benefit from the focused attention that their elevated role requires, when they fail, the resulting loss of availability can have a disproportionate impact.
• Creating Monoculture: The scale available to a centralized service or application can magnify minor flaws in features such as recommendation algorithms to a degree that can have broad (even societal) consequences. Diversity in these functions' implementation is significantly more robust when viewed systemically.
• Self-Reinforcement: As widely noted (see, e.g., ), a centralized service's access to data allows it the opportunity to make improvements to its offerings, while denying such access to others.

See also for further exploration of how centralization can affect the Internet. To summarize, centralization of a function allows it to be captured, effectively becoming a "walled garden" that cannot be a full part of the Internet because it does not meet the Internet's architectural design goals or users' expectations.

Kinds of Centralization Centralization on the Internet is not uniform; it presents in a variety of ways, depending on its relationship to the function in question and underlying causes. The subsections below describe different aspects of Internet centralization.

Proprietary Centralization Creating of a protocol or application with a fixed role for a specific party is the most straightforward kind of centralization. Currently, many widely used messaging, videoconferencing, chat, and similar protocols operate in this fashion. While some argue that such protocols are simpler to design, more amenable to evolution, and more likely to meet user needs , proprietary centralization most often reflects commercial goals -- in particular, a strong desire to capture the protocols' financial benefits by "locking in" users to a proprietary service. Proprietary protocols and applications are not considered to be part of the Internet per se; instead, they are more properly characterized as being built on top of the Internet. As such, the Internet architecture and associated standards do not regulate them, beyond the constraints that the underlying protocols (e.g., TCP, IP, HTTP) impose.

Beneficial Centralization Some protocols introduce centralization risk that is unavoidable, because the protocol's goals requires a centralized function. For example, when there is a need for a single, globally coordinated "source of truth", that function is by nature centralized -- such as in the Domain Name System (DNS), which allows human-friendly naming to be converted into network addresses in a globally consistent fashion. IP addresses allocation is another example of a function having this kind of centralization risk. Internet routing requires addresses to be allocated uniquely, but if a single government or company captured the addressing function, the entire Internet would be at risk of abuse by that entity. Similarly, the need for coordination in the Web's trust model brings centralization risk, because of the Certificate Authority's role in communication between clients and servers. Protocols that need to solve the "rendezvous problem" to coordinate communication between two parties who are not in direct contact also suffer from this kind of centralization risk. For example, chat protocols need to coordinate communication between two parties that wish to talk; while the actual communication can be direct between them (so long as the protocol facilitates that), the endpoints' mutual discovery typically requires a third party. By nature, what is or is not "beneficial" is a judgment call. Some protocols cannot function without a centralized function; others might be significantly enhanced for certain use cases if a function is centralized, or might merely be more efficient. Such judgments should be made in light of established architectural principles and how benefits accrue to end users. When beneficial centralization is present, internet protocols often attempt to mitigate the associated risks using measures such as federation (see ) and multi-stakeholder administration (see ). Protocols that successfully mitigate beneficial centralization are often reused, to avoid the considerable cost and risk of re-implementing those mitigations. For example, if a protocol requires a coordinated, global naming function, reusing the Domain Name System is usually preferable to establishing a new system.

Concentrated Centralization Even when a protocol avoids proprietary centralization and does not require any beneficial centralization, it might become centralized in practice when external factors influence its deployment, so that relatively few or even just one entity provides the function. This is often referred to as "concentration." Economic, legal, and social factors that encourage use of a central function despite the absence of such a requirement in the protocol itself can cause concentration. Often, the factors driving concentration are related to the network effects that are so often seen on the Internet. While in theory every node on the Internet is equal, in practice some nodes are much more connected than others: for example, just a few sites drive much of the traffic on the Web. While expected and observed in many kinds of networks, network effects award asymmetric power to nodes that act as intermediaries to communication. Left unchecked, these factors can cause a potentially decentralized application to become effectively controlled by one party, because the central function has leverage to "lock in" users. For example, social networking is an application that is currently supplied by a few proprietary platforms despite standardization efforts (see, e.g., ), because of the powerful network effects associated. By its nature, concentration is difficult to avoid in protocol design, and federated protocols are particularly vulnerable to it (see ).

Inherited Centralization Most Internet protocols and applications depend on other, "lower-layer" protocols and their implementations. The features, deployment, and operation of these dependencies can surface centralization risk into functions and applications build "on top" of them. For example, the network between endpoints can introduce centralization risk to application-layer protocols, because it is necessary for communication and therefore has power over it. A network might block access to, slow down, or change the content of various application protocols or specific services for financial, political, operational, or criminal reasons, thereby creating pressure to use other services, which can result in centralization of them. Likewise, having only a single implementation of a protocol is an inherited centralization risk, because applications that use it are vulnerable to the control it has over their operation. Even if it is Open Source, there might be inherited centralization risk if there are factors that make forking difficult (for example, the cost of maintaining that fork). Inherited centralization risk is often present when users cannot find a substitute because network effects reduce the choices available to them. This kind of centralization can also be created by legal mandates and incentives that restrict the options for Internet access, the provision of a given function, or the range of implementations available. Some kinds of inherited centralization can be prevented by enforcing layer boundaries through use of techniques like encryption. When the number of parties who have access to content of communication are limited, parties at lower layers can be prevented from interfering with and observing it. Although those lower-layer parties might still be able to prevent communication, encryption also makes it more difficult to discriminate a target from other traffic. Note that the prohibitive effect of encryption on inherited centralization is most pronounced when most (if not all) traffic is encrypted. See also .

Platform Centralization The complement to inherited centralization is platform centralization -- where a function does not directly define a central role, but could facilitate centralization in the applications it supports. For example, HTTP is not considered a centralized protocol; interoperable servers are relatively easy to instantiate, and multiple clients are available. It can be used without central coordination beyond that provided by DNS, as discussed above. However, applications built on top of HTTP (as well as the rest of the "Web Platform") often exhibit centralization. As such, HTTP is an example of a platform for centralization -- while the protocol itself is not centralized, it facilitates the creation of centralized services and applications. Like concentration, platform centralization is difficult to prevent with protocol design. Because of the layered nature of the Internet, most protocols allow considerable flexibility in how they are used, often in a way that it becomes attractive to form a dependency on one party's operation.

The Limits of Decentralization Centralization's relationship to Internet standardization is undeniably about power -- a protocol is an agreed-to set of rules and conventions, and those rules can impact how power accrues. Over time, various techniques have been developed that attempt to avoid concentration of power as a result of protocol design, or to bring accountability when it is unavoidable. While use of these techniques can result in a function which is less centralized or less amenable to some kinds of centralization, they are not adequate to avoid centralization completely. They are also not indicators of whether a protocol is centralized without further analysis.

Federation isn't Enough A widely known technique for managing centralization in Internet protocols is federation -- designing them in such a way that new instances of any centralized function are relatively easy to create and can maintain interoperability and connectivity with other instances. For example, SMTP is the basis of the e-mail suite of protocols, which has two functions that have centralization risk:

1. Giving each user a globally unique address, and
2. Routing messages to the user, even when they change network locations or are disconnected for long periods of time.

E-mail reuses DNS to help mitigate the first risk. To mitigate the second, it defines a specific role for routing users' messages, the Message Transfer Agent (MTA). By allowing anyone to deploy an MTA and defining rules for interconnecting them, the protocol's users avoid a requirement for a single central router. Users can (and often do) choose to delegate that role to someone else, or run their own MTA. However, running your own mail server has become difficult, because of the likelihood of a small MTA being classified as a spam source. Because large MTA operators are widely known and have greater impact if their operation is affected, they are less likely to be classified as such, concentrating the protocol's operation (see ). Another example of a federated Internet protocol is XMPP , supporting "instant messaging" and similar functionality. Like e-mail, it reuses DNS for naming and requires federation to facilitate rendezvous of users from different systems. While some deployments of XMPP do support truly federated messaging (i.e., a person using service A can interoperably chat with someone using service B), many of the largest do not. Because federation is voluntary, some operators captured their users into a single service, rather than provide the benefits of global interoperability. The examples above illustrate that federation can be a useful technique to avoid proprietary centralization and manage beneficial centralization, but on its own does not avoid concentration and platform centralization. If a single entity can capture the value provided by a protocol, they may use the protocol as a platform to get a "winner take all" outcome -- a significant risk with many Internet protocols, since network effects often promote such outcomes. Likewise, external factors (such as spam control) might naturally "tilt the table" towards a few operators.

Multi-Stakeholder Administration is Hard The risks associated with a beneficial centralized function (see ) are sometimes mitigated by delegating that function's administration to a multi-stakeholder body -- an institution that includes representatives of the different kinds of parties that are affected by the system's operation ("stakeholders") in an attempt to make well-reasoned, legitimate, and authoritative decisions. The most widely-studied example of this technique is the administration of the DNS, which as a "single source of truth" exhibits beneficial centralization in its naming function, as well as the operation of the system overall. To mitigate operational centralization, multiple root servers that are administered by separate operators (themselves diverse in geography) and a selection of corporate entities, non-profits, and government bodies from many jurisdictions and affiliations carry this task out. Administration of the name space itself is overseen by the Internet Corporation for Assigned Names and Numbers (ICANN), a global multi-stakeholder body with representation from end users, governments, operators, and others. Another example is the administration of the Web's trust model, implemented by Web browsers as relying parties and Certificate Authorities as trust anchors. To assure that all parties meet the operational and security requirements necessary to provide the desired properties, the CA/Browser Forum was established as an oversight body that involves both of those parties as stakeholders. Yet another example of multi-stakeholderism is the standardization of Internet protocols themselves. Because a specification effectively controls implementation behavior, the standardization process can be seen as a single point of control. As a result, Internet standards bodies like the IETF allow open participation and contribution, make decisions in an open and accountable way, have a well-defined process for making (and when necessary, appealing) decisions, considering the views of different stakeholder groups . A major downside of this approach is that setup and ongoing operation of multi-stakeholder bodies is not trivial. Additionally, their legitimacy cannot be assumed, and may be difficult to establish and maintain (see, e.g., ). This concern is especially relevant if the function being coordinated is broad, complex, and/or contentious.

Blockchains Are Not Magical Increasingly, distributed consensus technologies (such as blockchain) are touted as a solution to centralization issues. A complete survey of this rapidly changing area is beyond the scope of this document, but we can generalise about their properties. These techniques attempt to avoid centralization risk by distributing potentially centralized functions to members of a sometimes large pool of protocol participants. Proper performance of a function is typically guaranteed using cryptographic techniques (often, an append-only transaction ledger). A particular task's assignment to a node for handling usually cannot be predicted or controlled. Sybil attacks (where a party or coordinated parties cheaply create enough protocol participants to affect how consensus is judged) are a major concern for these protocols. Diversity in the pool of participants is encouraged using indirect techniques such as proof-of-work (where each participant has to demonstrate significant consumption of resources) or proof-of-stake (where each participant has some other incentive to execute correctly). Use of these techniques can create barriers to proprietary and inherited centralization. However, depending upon the application in question, concentration and platform centralization can still be possible. Furthermore, distributed consensus technologies have several potential shortcomings that may make them inappropriate -- or at least difficult to use -- for many Internet applications, because their use conflicts with other important goals:

1. Distributed consensus has significant implications for privacy. Because activity (such as queries or transactions) are shared with many unknown parties (and often publicly visible due to the nature of the blockchain) they have very different privacy properties than traditional client/server protocols. Potential mitigations (e.g., Private Information Retrieval; see, e.g., ) are still not suitable for broad deployment.
2. Their complexity and "chattiness" typically result in significantly less efficient use of the network (often, to several orders of magnitude). When distributed consensus protocols use proof-of-work, energy consumption can become significant (to the point where some jurisdictions have banned its use).
3. Distributed consensus protocols are still not proven to scale to the degree expected of successful Internet protocols. In particular, relying on unknown third parties to deliver functionality can introduce significant variability in latency, availability, and throughput. This is a marked change for applications with high expectations for these properties (e.g., consumer-oriented Web sites).
4. By design, distributed consensus protocols diffuse responsibility for a function among several difficult-to-identify parties. While this may be an effective way to prevent some kinds of centralization, it also means that making someone accountable for how the function is performed difficult, and often impossible. While the protocol might use cryptographic techniques to assure correct operation, they may not capture all requirements, and may not be correctly used by the protocol designers.
5. Distributed consensus protocols typically rely on cryptography for identity, rather than trusting a third party's assertions about identity. When a participant loses their keys, recovering their identity is not possible -- an unacceptable usability impact for many applications.

It is also important to recognise that a protocol or an application can use distributed consensus for some functions, but still have centralization risk elsewhere -- either because those functions cannot be decentralized (most commonly, rendezvous and global naming; see ) or because the service provider has chosen not to because of the associated costs and lost opportunities. Even when distributed consensus is used exclusively for all technical functions of a service, some coordination is still necessary -- whether that be through governance of the function itself, creation of shared implementations, or documentation of shared wire protocols. That represents centralization risk, just at a different layer (inherited or platform). These potential shortcomings do not rule out the use of distributed consensus technologies in every instance. They do, however, caution against relying upon these technologies to avoid centralization uncritically.

What Should Internet Standards Do? Centralization is driven by powerful forces -- both economic and social -- as well as the network effects that come with Internet scale. Because permissionless innovation is a core value for the Internet, and yet much of the centralization seen on the Internet is performed by proprietary platforms that take advantage of this nature, the controls available to standards efforts are very limited. While standards bodies on their own cannot prevent centralization, there are meaningful steps that can be taken to prevent some functions from exhibiting centralization. There are also valuable contributions that standards efforts can make to other relevant forms of regulation.

Be Realistic Some kinds of centralization risk are relatively easy to manage in standards efforts. For example, if a proprietary protocol were to be proposed to the IETF, it would be rejected out of hand. There is a growing body of knowledge and experience with beneficial centralization, and a strong inclination to reuse existing infrastructure where possible. As discussed above, encryption is often a way to manage inherited centralization, and has become the norm in standard protocols. These responses are appropriate ways for Internet standards to manage centralization risk. However, preventing concentration and platform centralization is much more difficult in standards efforts. Because we have no "protocol police", it's not possible to demand that someone stop building a proprietary service using a purportedly federated protocol. We also cannot stop someone from building centralized services "on top" of standard protocols without abandoning architectural goals like permissionless innovation. Therefore, committing significant resources to scrutinizing protocols for latent centralization risk -- especially for concentration and platform risks -- is unlikely to be effective in preventing Internet centralization. Almost all existing Internet protocols -- including IP, TCP, HTTP, and DNS -- suffer some form of concentration or platform centralization. Refusing to standardize a newer protocol because it faces similar risks would not be equitable, proportionate, or effective. When we do find centralization risk, we should consider its relationship with other architectural goals as we consider how to address it. In particular, attention should be paid to how effective standards (as a form of architectural regulation) is in achieving each goal. For example, privacy is often more effectively ensured by ex ante technical constraints, as compared to ex post legal regulation. Conversely (as discussed) some kinds of centralization are likely better addressed through legal regulation. Thus, as a first order concern, a standards effort balancing these concerns might focus primarily on privacy. However it is often the case that these are not completely separable goals -- concentration can result in one or a few entities having greater volume and variety of data available exclusively to them, raising significant privacy and security concerns.

Decentralize Proprietary Functions It is worthwhile to create specifications for functions that are currently only satisfied by proprietary providers. By building open specifications on top of already established standards, an alternative to a centralized function can be created. A common objection to such efforts is that adoption is voluntary, not mandatory; there are no "standards police" to mandate their use or enforce correct implementation. For example, specifications like ) have been available for some time without broad adoption by social networking providers. However, while standards aren't mandatory, legal regulation is, and regulators around the globe are now focusing their efforts on the Internet. In particular, legal mandates for interoperability are increasingly discussed as a remedy for competition issues (see, e.g., ). As such, emerging regulation presents an opportunity to create new specifications to decentralize these functions, backed by a legal mandate in combination with changing norms and the resulting market forces . Successfully creating standards that work in concert with legal regulation is new ground for the IETF, presents many potential pitfalls, and will require new capabilities (especially liaison, likely originating in the IAB) and considerable effort. If the Internet community does not make that effort, it is likely that regulators' needs will be filled by other means -- most likely, with less transparency, more narrow input, limited experience, and without reference to the Internet's architectural goals.

Build Robust Ecosystems To minimize inherited centralization risk, standards-defined functions should have an explicit goal of broad, diverse implementation and deployment so that users have as many choices as possible. explores some factors in protocol design that encourage this outcome. This goal can also be furthered by ensuring that the cost of switching to a different implementation or deployment is as low as possible to facilitate subsequent substitution. This implies that the standard is functionally complete and specified precisely enough to result in meaningful interoperability. The goals of completeness and diversity are sometimes in tension. If a standard is extremely complex, it may discourage implementation diversity because the cost of a complete implementation is too high (consider: Web browsers). On the other hand, if the specification is too simple, it may not offer enough functionality to be complete, and the resulting proprietary extensions may make switching difficult (see ). Also worthy of attention are the underlying incentives for implementation. While a completely commoditized protocol might not allow implementations to differentiate themselves, they do provide opportunties for specialization and improvement elsewhere in the value chain . Well-timed standards efforts leverage these forces to focus proprietary interests on top of open technology, rather than as a replacement for it. Balancing these factors to build robust ecosystems is difficult, but is often helped by community building and good design -- in particular, appropriate use of layering. It also requires continuing maintenance and evolution of protocols, to assure that they are still relevant and appropriate to their use.

Limit Delegation of Power Some functions might see substantial benefits if they are performed by a third party in communication. When used well, adding a new party to communication can improve:

• Efficiency: Many functions on the Internet are significantly more efficient when performed at a higher scale. For example, a Content Delivery Network can offer services at a fraction of the financial and environmental cost that would otherwise be paid by someone serving content themselves, because of the scale they operate at.
• Simplicity: Completely disintermediating communication can shift the burden of functions onto endpoints. This can cause increased cognitive load for users; for example, compare commercial social networking platforms with self-hosted efforts.
• Specialization: Having a function concentrated into relatively few hands can improve outcomes because of the resulting specialization. For example, services overseen by professional administrators are often seen to have a better security posture and improved availability.
• Privacy: For some functions, user privacy can be improved by concentrating their activity to prevent individual behaviors from being discriminated from each other. Introduction of a third party can also enforce functional boundaries -- for example, to reduce the need for users to trust potentially malicious endpoints, as seen in the so-called "oblivious" protocols (e.g., ) that allow end users to hide their identity from services, while still accessing them.

However, introducing an new party to communication adds concentration and platform centralization risk to Internet protocols, because it brings opportunities for control and observation. While (as discussed above) standards efforts have a very limited capability to prevent or control these types of centralization, designing protocols with constraints on third party functions can prevent at least the most egregious outcomes. Most often, third parties are added to protocols as "intermediaries" or in designated "agent" roles. In general, they should only be interposed as a result of the positive action of at least one endpoint, and should have their ability to observe or control communication limited to what is necessary to perform their intended function. For example, early deployments of HTTP allowed intermediaries to be interposed by the network without knowledge of the endpoints, and those intermediaries could see and change the full content of traffic by default -- even when they are only intended to perform basic functions such as caching. Because of the introduction of HTTPS and the CONNECT method (see ), combined with efforts to encourage its adoption, those intermediaries are now required to be explicitly interposed by one endpoint. See for more guidance on protocol intermediation. The term "intermediary" is also used (often in legal and regulatory contexts) more broadly than it has been in protocol design; for example, an auction Web site intermediates between buyers and sellers is considered an intermediary, even though it is not formally an intermediary in HTTP (see ). Protocol designers can address the centralization risk associated with this kind of intermediation by standardising the function, rather than restricting the capabilities of the underlying protocols; see .

Avoid Over-Extensibility An important feature of Internet protocols is their ability to evolve, so that they can meet new requirements and adapt to new conditions without requiring a "flag day" to upgrade implementations. Typically, protocols accommodate evolution through extension mechanisms, which allow optional features to be added over time in an interoperable fashion. Extensibility can be viewed as a mechanism for decentralization as well -- by allowing uncoordinated evolution, it promotes autonomy and adaption of a function for local needs. However, protocol extensions can also increase the risk of platform centralization if a powerful entity can change the target for meaningful interoperability by adding proprietary extensions to a standard protocol. This is especially true when the core standard does not itself provide sufficient utility on its own. For example, the SOAP protocol's extreme flexibility and failure to provide significant standalone value allowed vendors to require use of their preferred extensions, favouring those who had more market power. Therefore, standards efforts should focus on providing concrete utility to the majority of their users as published, rather than being a "framework" where interoperability is not immediately available. Internet protocols should not make every aspect of their operation extensible; extension points should be reasoned, appropriate boundaries for flexibility and control. When a protocol defines extension points, they should not allow an extension to declare itself to be mandatory-to-interoperate, as that pattern invites abuse. Where extensions are allowed, attention should be paid to those that emerge; where appropriate, widely adopted extensions should be put through a standards process to assure that the result adheres to architectural principles and shared goals (see also ).

Security Considerations This document does not have direct security impact on Internet protocols. However, failure to consider centralization risks might cause a myriad of security issues.

Informative References Adobe Fastly greenbytes GmbH The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFC 2818, RFC 7231, RFC 7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, RFC 7694, and portions of RFC 7230. University of Notre Dame Columbia Law School George Washington University Georgetown University Signal OECD The Federalist Papers, No. 51 Harvard Business Review, "Breakthrough Ideas for 2004" This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths. This document obsoletes RFC 1771. [STANDARDS-TRACK] This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. This memo gives a mission statement for the IETF, tries to define the terms used in the statement sufficiently to make the mission statement understandable and useful, argues why the IETF needs a mission statement, and tries to capture some of the debate that led to this point. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible. This document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" (User Agent) mail reading systems and mobile environments. [STANDARDS-TRACK] The Extensible Messaging and Presence Protocol (XMPP) is an application profile of the Extensible Markup Language (XML) that enables the near-real-time exchange of structured yet extensible data between any two or more network entities. This document defines XMPP's core protocol methods: setup and teardown of XML streams, channel encryption, authentication, error handling, and communication primitives for messaging, network availability ("presence"), and request-response interactions. This document obsoletes RFC 3920. [STANDARDS-TRACK] This document explains why the IAB believes that, when there is a conflict between the interests of end users of the Internet and other parties, IETF decisions should favor end users. It also explores how the IETF can more effectively achieve this. The Internet community has specified a large number of protocols to date, and these protocols have achieved varying degrees of success. Based on case studies, this document attempts to ascertain factors that contribute to or hinder a protocol's success. It is hoped that these observations can serve as guidance for future protocol work. This memo provides information for the Internet community. Apple Inc. Fastly Apple Inc. Cloudflare Cloudflare This document describes a protocol that allows clients to hide their IP addresses from DNS resolvers via proxying encrypted DNS over HTTPS (DoH) messages. This improves privacy of DNS operations by not allowing any one server entity to be aware of both the client IP address and the content of DNS queries and answers. This experimental protocol is developed outside the IETF and is published here to guide implementation, ensure interoperability among implementations, and enable wide-scale experimentation. Mozilla 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.

Acknowledgements This document benefits from discussions with Brian Trammell during our shared time on the Internet Architecture Board. Thanks to Jari Arkko, Christian Huitema, and Eliot Lear for their comments and suggestions.