diff options
Diffstat (limited to 'doc/rfc/rfc9518.txt')
| -rw-r--r-- | doc/rfc/rfc9518.txt | 1276 |
1 files changed, 1276 insertions, 0 deletions
diff --git a/doc/rfc/rfc9518.txt b/doc/rfc/rfc9518.txt new file mode 100644 index 0000000..660b45a --- /dev/null +++ b/doc/rfc/rfc9518.txt @@ -0,0 +1,1276 @@ + + + + +Independent Submission M. Nottingham +Request for Comments: 9518 December 2023 +Category: Informational +ISSN: 2070-1721 + + + Centralization, Decentralization, and Internet Standards + +Abstract + + This document discusses aspects of centralization that relate to + Internet standards efforts. It argues that, while standards bodies + have a limited ability to prevent many forms of centralization, they + can still make contributions that assist in the decentralization of + the Internet. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This is a contribution to the RFC Series, independently of any other + RFC stream. The RFC Editor has chosen to publish this document at + its discretion and makes no statement about its value for + implementation or deployment. Documents approved for publication by + the RFC Editor are not candidates for any level of Internet Standard; + see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9518. + +Copyright Notice + + Copyright (c) 2023 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) 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. Centralization + 2.1. Centralization Can Be Harmful + 2.2. Centralization Can Be Helpful + 3. Decentralization + 3.1. Decentralization Strategies + 3.1.1. Federation + 3.1.2. Distributed Consensus + 3.1.3. Operational Governance + 4. What Can Internet Standards Do? + 4.1. Bolster Legitimacy + 4.2. Focus Discussion of Centralization + 4.3. Target Proprietary Functions + 4.4. Enable Switching + 4.5. Control Delegation of Power + 4.6. Enforce Boundaries + 4.7. Consider Extensibility Carefully + 4.8. Reuse What Works + 5. Future Work + 6. Security Considerations + 7. IANA Considerations + 8. Informative References + Acknowledgements + Author's Address + +1. Introduction + + One of the Internet's defining features is its lack of any single + point of technical, political, or economic control. Arguably, that + characteristic assisted the Internet's early adoption and broad + reach: permission is not required to connect to, deploy an + application on, or use the Internet for a particular purpose, so it + can meet diverse needs and be deployed in many different + environments. + + Although maintaining that state of affairs remains a widely espoused + goal, consistently preserving it across the range of services and + applications that people see as "the Internet" has proven elusive. + Whereas early services like the Network News Transfer Protocol (NNTP) + and email had multiple interoperable providers, many contemporary + platforms for content and services are operated by single commercial + entities without any interoperable alternative -- to the point where + some have become so well-known and important to people's experiences + that they are commonly mistaken for the Internet itself [Komaitis]. + + These difficulties call into question what role architectural design + -- in particular, that overseen by open standards bodies such as the + IETF -- can and should play in controlling centralization of the + Internet. + + This document argues that, while decentralized technical standards + may be necessary to avoid centralization of Internet functions, they + are not sufficient to achieve that goal because centralization is + often caused by non-technical factors outside the control of + standards bodies. As a result, standards bodies should not fixate on + preventing all forms of centralization; instead, they should take + steps to ensure that the specifications they produce enable + decentralized operation. + + Although this document has been discussed widely in the IETF + community (see the Acknowledgements section), it represents the views + of the author, not community consensus. Its primary audience is the + engineers who design and standardize Internet protocols. Designers + of proprietary protocols and applications can benefit from + considering these issues, especially if they intend their work to be + considered for eventual standardization. Policymakers can use this + document to help characterize abuses that involve centralized + protocols and applications and evaluate proposed remedies for them. + + Section 2 defines centralization, explains why it is often + undesirable but sometimes beneficial, and surveys how it occurs on + the Internet. Section 3 explores decentralization and highlights + some relevant strategies, along with their limitations. Section 4 + makes recommendations about the role that Internet standards can play + in controlling centralization. Section 5 concludes by identifying + areas for future work. + +2. Centralization + + In this document, "centralization" is the state of affairs where a + single entity or a small group of them can observe, capture, control, + or extract rent from the operation or use of an Internet function + exclusively. + + Here, "entity" could be a person, group, or corporation. An + organization might be subject to governance that mitigates + centralization risk (see Section 3.1.3), but that organization is + still a centralizing entity. + + "Internet function" is used broadly in this document. Most directly, + it might be an enabling protocol already defined by standards, such + as IP [RFC791], BGP [RFC4271], TCP [RFC9293], or HTTP [HTTP]. It + might also be a proposal for a new enabling protocol or an extension + to an existing one. + + Because people's experience of the Internet are not limited to + standards-defined protocols and applications, this document also + considers centralization in functions built on top of standards -- + for example, social networking, file sharing, financial services, and + news dissemination. Likewise, the networking equipment, hardware, + operating systems, and software that act as enabling technologies for + the Internet can also impact centralization. The supply of Internet + connectivity to end users in a particular area or situation can + exhibit centralization, as can the supply of transit between networks + (so called "Tier 1" networks). + + This definition of centralization does not capture all types of + centralization. Notably, technical centralization (for example, + where a machine or network link is a single point of failure) is + relatively well understood by engineers; it can be mitigated, + typically by distributing a function across multiple components. As + we will see, such techniques might address that type of + centralization while failing to prevent control of the function + falling into few hands. A failure because of a cut cable, power + outage, or failed server is well understood by the technical + community but is qualitatively different from the issues encountered + when a core Internet function has a gatekeeper. + + Likewise, political centralization (for example, where a country is + able to control how a function is supplied across the whole Internet) + is equally concerning but is not considered in depth here. + + Even when centralization is not currently present in a function, some + conditions make it more likely that centralization will emerge in the + future. This document uses "centralization risk" to characterize + that possibility. + +2.1. Centralization Can Be Harmful + + Many engineers who participate in Internet standards efforts have an + inclination to prevent and counteract centralization because they see + the Internet's history and architecture as incompatible with it. As + a "large, heterogeneous collection of interconnected systems" [BCP95] + the Internet is often characterized as a "network of networks" whose + operators relate as peers that agree to facilitate communication + rather than experiencing coercion or requiring subservience to + others' requirements. This focus on independence of action is + prevalent in the Internet's design -- for example, in the concept of + an "autonomous system". + + Reluctance to countenance centralization is also rooted in the many + potentially damaging effects that have been associated with it, + including: + + * _Power Imbalance_: When a third party has unavoidable access to + communications, they gain informational and positional advantages + that allow observation of behavior (the "panopticon effect") and + shaping or even denial of behavior (the "chokepoint effect"): + capabilities that those parties (or the states that have authority + over them) can use for coercive ends [FarrellH] or even to disrupt + society itself. Just as [Madison] describes good governance of + the US states, good governance of the Internet requires that power + over any function not be consolidated in one place without + appropriate checks and balances. + + * _Limits on Innovation_: A party with the ability to control + communication can preclude the possibility of "permissionless + innovation", i.e., the ability to deploy new, unforeseen + applications without requiring coordination with parties other + than those you are communicating with. + + * _Constraints on 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 a centralized service or platform must be used + because no substitutes are suitable, it effectively becomes an + essential facility, which opens the door to abuse of power. + + * _Reduced Availability_: Availability of the Internet (and + applications and services built upon it) improves when there are + many ways to obtain access. While service availability can + benefit from the focused attention of a large centralized + provider, that provider's failure can have a disproportionate + impact on availability. + + * _Monoculture_: The scale available to a centralized provider can + magnify minor flaws in features to a degree that can have broad + consequences. For example, a single codebase for routers elevates + the impact of a bug or vulnerability; a single recommendation + algorithm for content can have severe social impact. Diversity in + functions' implementations leads to a more robust outcome when + viewed systemically because "progress is the outcome of a trial- + and-error evolutionary process of many agents interacting freely" + [Aligia]. + + * _Self-Reinforcement_: As widely noted (e.g., see [Abrahamson]), a + centralized provider's access to data allows it the opportunity to + make improvements to its offerings while denying such access to + others. + + The relationship between these harms and centralization is often + complex. It is not always the case that centralization will lead to + them; when it does, there is not always a direct and simple trade- + off. + + For example, consider the relationship between centralization and + availability. A centrally operated system might be more available + because of the resources available to a larger operator, but their + size creates greater impact when a fault is encountered. + Decentralized systems can be more resilient in the face of some forms + of failure but less so in other ways; for example, they may be less + able to react to systemic issues and might be exposed to a larger + collection of security vulnerabilities in total. As such, it cannot + be said that centralization reduces availability in all cases: nor + does it improve it in all cases. + + This tension can be seen in areas like the cloud and mobile Internet + access. If a popular cloud-hosting provider were to become + unavailable (whether for technical or other reasons), many Internet + experiences might be disrupted (especially due to the multiple + dependencies that a modern website often has; see [Kashaf]). + Likewise, a large mobile Internet access provider might have an + outage that affects hundreds of thousands of its users or more -- + just as previous issues at large telephone companies precipitated + widespread outages [PHONE]. + + In both cases, the services are not technically centralized; these + operators have strong incentives to have multiple redundancies in + place and use various techniques to mitigate the risk of any one + component failing. However, they generally do rely upon a single + codebase, a limited selection of hardware, a unified control plane, + and a uniform administrative practice: each of which might + precipitate a widespread failure. + + If there were only one provider for these services (like the + telephone networks of old), they would easily be considered to be + centralized in a way that has significant impact upon availability. + However, many cloud providers offer similar services. In most + places, there are multiple mobile operators available. That weakens + the argument that there is a link between centralization and their + availability because the function's users can switch to other + providers or use more than one provider simultaneously; see + Section 4.4. + + These circumstances suggest one area of inquiry when considering the + relationship between centralization and availability of a given + function: what barriers are there to switching to other providers + (thereby making any disruptions temporary and manageable) or to using + multiple providers simultaneously (to mask the failure of a single + operator)? + + Another example of the need for nuance can be seen when evaluating + competitive constraints. While making provision of various Internet + functions more competitive may be a motivation for many engineers, + only courts (and sometimes regulators) have the authority to define a + relevant market and determine that a behavior is anticompetitive. In + particular, market concentration does not always indicate competition + issues; therefore, what might be considered undesirable + centralization by the technical community might not attract + competition regulation. + +2.2. Centralization Can Be Helpful + + The potential damaging effects of centralization listed above are + widely appreciated. Less widely explored is the reliance on + centralization by some protocols and applications to deliver their + functionality. + + Centralization is often present due to technical necessity. For + example, a single globally coordinated "source of truth" is by nature + centralized -- such as in the root zone of the Domain Name System + (DNS), which allows human-friendly naming to be converted into + network addresses in a globally consistent fashion. + + Or, consider IP address allocation. Internet routing requires + addresses to be allocated uniquely, but if a single government or + company were to capture the addressing function, the entire Internet + would be at risk of abuse by that entity. Similarly, the Web's trust + model requires a Certificate Authority (CA) to serve as the root of + trust for communication between browsers and servers, bringing the + centralization risk, which needs to be considered in the design of + that system. + + Protocols that need to solve the "rendezvous problem" to coordinate + communication between two parties who are not in direct contact also + require centralization. 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 at some point. From the perspective of those + two users, the rendezvous function has a centralization risk. + + Even when not strictly necessary, centralization can create benefits + for a function's users and for society. + + For example, it has long been recognized that the efficiencies that + come with economies of scale can lead to concentration [Demsetz]. + Those efficiencies can be passed on to users as higher quality + products and lower costs, and they might even enable provision of a + function that was not viable at smaller scale. + + Complex and risky functions like financial services (e.g., credit + card processing) are often concentrated into a few specialized + organizations where they can receive the focused attention and + expertise that they require. + + Centralization can also provide an opportunity for beneficial + controls to be imposed. [Schneider2] notes that "centralized + structures can have virtues, such as enabling publics to focus their + limited attention for oversight, or forming a power bloc capable of + challenging less-accountable blocs that might emerge. Centralized + structures that have earned widespread respect in recent centuries -- + including governments, corporations, and nonprofit organizations -- + have done so in no small part because of the intentional design that + went into those structures". + + This can be seen when a function requires governance to realize + common goals and protect minority interests. For example, content + moderation functions impose community values that many see as a + benefit. Of course, they can also be viewed as a choke point where + inappropriate controls are able to be imposed if that governance + mechanism has inadequate oversight, transparency, or accountability. + + Ultimately, deciding when centralization is beneficial is a judgment + call. Some protocols cannot operate without a centralized function; + others might be significantly enhanced for certain use cases if a + function is centralized or might merely be more efficient. Although, + in general, centralization is most concerning when it is not broadly + held to be necessary or beneficial; when it has no checks, balances, + or other mechanisms of accountability; when it selects "favorites" + that are difficult (or impossible) to displace; and when it threatens + the architectural features that make the Internet successful. + +3. Decentralization + + While the term "decentralization" has a long history of use in + economics, politics, religion, and international development, [Baran] + gave one of the first definitions relevant to computer networking as + a condition when "complete reliance upon a single point is not always + required". + + Such technical centralization (while not a trivial topic) is + relatively well understood. Avoiding all forms of centralization -- + including non-technical ones -- using only technical tools (like + protocol design) is considerably more difficult. Several issues are + encountered. + + First, and most critically, technical decentralization measures have, + at best, limited effects on non-technical forms of centralization. + Or, per [Schneider1], "decentralized technology alone does not + guarantee decentralized outcomes". As explored below in Section 3.1, + technical measures are better characterized as necessary but + insufficient to achieve full decentralization of a function. + + Second, decentralizing a function requires overcoming challenges that + centralized ones do not face. A decentralized function can be more + difficult to adapt to user needs (for example, introducing new + features or experimenting with user interfaces) because doing so + often requires coordination between many different actors + [Marlinspike]. Economies of scale are more available to centralized + functions, as is data that can be used to refine a function's design. + All of these factors make centralized solutions more attractive to + service providers and, in some cases, can make a decentralized + solution uneconomic. + + Third, identifying which aspects of a function to decentralize can be + difficult, both because there are often many interactions between + different types and sources of centralization and because + centralization sometimes only becomes clear after the function is + deployed at scale. Efforts to decentralize often have the effect of + merely shifting centralization to a different place -- for example, + in its governance, implementation, deployment, or ancillary + functions. + + For example, the Web was envisioned and widely held to be a + decentralizing force in its early life. Its potential as an enabler + of centralization only became apparent when large websites + successfully leveraged network effects (and secured legal + prohibitions against interoperability, thus increasing switching + costs; see [Doctorow]) to achieve dominance of social networking, + marketplaces, and similar functions. + + Fourth, different parties might have good-faith differences on what + "sufficiently decentralized" means based upon their beliefs, + perceptions, and goals. Just as centralization is a continuum, so is + decentralization, and not everyone agrees what the "right" level or + type is, how to weigh different forms of centralization against each + other, or how to weigh potential centralization against other + architectural goals (such as security or privacy). + + These tensions can be seen, for example, in the DNS. While some + aspects of the system are decentralized -- for example, the + distribution of the lookup function to local servers that users have + the option to override -- an essentially centralized aspect of the + DNS is its operation as a name space: a single global "source of + truth" with inherent (if beneficial) centralization in its + management. ICANN mitigates the associated risk through multi- + stakeholder governance (see Section 3.1.3). While many believe that + this arrangement is sufficient and might even have desirable + qualities (such as the ability to impose community standards over the + operation of the name space), others reject ICANN's oversight of the + DNS as illegitimate, favoring decentralization based upon distributed + consensus protocols rather than human governance [Musiani]. + + Fifth, decentralization unavoidably involves adjustments to the power + relationships between protocol participants, especially when it opens + up the possibility of centralization elsewhere. As [Schneider2] + notes, decentralization "appears to operate as a rhetorical strategy + that directs attention toward some aspects of a proposed social order + and away from others", so "we cannot accept technology as a + substitute for taking social, cultural, and political considerations + seriously". Or, more bluntly, "without governance mechanisms in + place, nodes may collude, people may lie to each other, markets can + be rigged, and there can be significant cost to people entering and + exiting markets" [Bodo]. + + For example, while blockchain-based cryptocurrencies purport to + address the centralization inherent in existing currencies through + technical means, many exhibit considerable concentration of power due + to voting/mining power, distribution of funds, and diversity of the + codebase [Makarov]. Overreliance on technical measures also brings + an opportunity for latent, informal power structures that have their + own risks -- including centralization [Freeman]. + + Overall, decentralizing a function requires considerable work, is + inherently political, and involves a large degree of uncertainty + about the outcome. If one considers decentralization as a larger + social goal (in the spirit of how the term is used in other, non- + computing contexts), merely rearranging technical functions may lead + to frustration. "A distributed network does not automatically yield + an egalitarian, equitable or just social, economic, political + landscape" [Bodo]. + +3.1. Decentralization Strategies + + This section examines some common strategies that are employed to + decentralize Internet functions and discusses their limitations. + +3.1.1. Federation + + Protocol designers often attempt to address centralization through + federation, i.e., designing a function in a way that uses independent + instances that maintain connectivity and interoperability to provide + a single cohesive service. Federation promises to allow users to + choose the instance they associate with and accommodates substitution + of one instance for another, lowering switching costs. + + However, federation alone is insufficient to prevent or mitigate + centralization of a function because non-technical factors can create + pressure to use a central solution. + + For example, the email suite of protocols needs to route messages to + a user even when that user changes network locations or becomes + disconnected for a long period. To facilitate this, SMTP [RFC5321] + 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 avoids a + requirement for a single central server in that role; users can (and + often do) choose to delegate it to someone else or they can run their + own MTA. + + Running one's own MTA has become considerably more onerous over the + years due, in part, to the increasingly complex mechanisms introduced + to fight unwanted commercial emails. These costs create an incentive + to delegate one's MTA to a third party who has the appropriate + expertise and resources, contributing to market concentration + [Holzbauer]. + + Additionally, the measures that MTAs use to identify unwanted + commercial emails are often site specific. Because large MTAs handle + so many more addresses, there is a power imbalance with smaller ones; + if a large MTA decides that email from a small one is unwanted, there + is significant impact on its ability to function and little recourse. + + The Extensible Messaging and Presence Protocol (XMPP) [RFC6120] is a + chat protocol that demonstrates another issue with federation: the + voluntary nature of technical standards. + + Like email, XMPP is federated to facilitate the rendezvous of users + from different systems - if they allow it. While some XMPP + deployments 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, deliberately + denying them the benefits of global interoperability. + + The examples above illustrate that, while federation can create the + conditions necessary for a function to be decentralized, it does not + guarantee that outcome. + +3.1.2. Distributed Consensus + + Increasingly, distributed consensus technologies (such as a + blockchain) are touted as a solution to centralization. A complete + survey of this rapidly changing area is beyond the scope of this + document, but we can generalize about its properties. + + These techniques typically guarantee proper performance of a function + using cryptographic techniques (often, an append-only transaction + ledger). They attempt to avoid centralization by distributing the + operation of a function to members of a sometimes large pool of + protocol participants. Usually, the participants are unknown and + untrusted, and a particular task's assignment to a node for handling + 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 because they would have the effect + of concentrating power into the hands of the attacker. Therefore, + they encourage diversity in the pool of participants using indirect + techniques, such as proof-of-work (where each participant has to show + a significant consumption of resources) or proof-of-stake (where each + participant has some other incentive to execute correctly). + + While these measures can be effective in decentralizing a function's + operation, other aspects of its provision can still be centralized: + for example, governance of its design, creation of shared + implementations, and documentation of wire protocols. That need for + coordination is an avenue for centralization even when the function's + operation remains decentralized. For example, the Ethereum "merge" + demonstrated that the blockchain could address environmental concerns + but only through coordinated community effort and governance: + coordination that was benign in most eyes but, nevertheless, + centralized [ETHEREUM]. + + Furthermore, a protocol or an application composed of many functions + can use distributed consensus for some but still be centralized + elsewhere -- either because those other functions cannot be + decentralized (most commonly, rendezvous and global naming; see + Section 2.2) or because the designer has chosen not to because of the + associated costs and lost opportunities. + + These potential shortcomings do not rule out the use of distributed + consensus technologies in every instance, but they do merit caution + against uncritically relying upon these technologies to avoid or + mitigate centralization. Too often, the use of distributed consensus + is perceived as imbuing all parts of a project with + "decentralization". + +3.1.3. Operational Governance + + Federation and distributed consensus can both create the conditions + for the provision of a function by multiple providers, but they + cannot guarantee it. However, when providers require access to a + resource or cooperation of others to provide that service, that choke + point can itself be used to influence provider behavior -- including + in ways that can counteract centralization. + + In these circumstances, some form of governance over that choke point + is necessary to assure the desired outcome. Often, this is through + the establishment of a multi-stakeholder body, which is 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. + + A widely studied example of this technique is the governance of the + DNS name space, which exhibits centralization as a "single source of + truth" [Moura]. That source of truth is overseen by the Internet + Corporation for Assigned Names and Numbers (ICANN) + <https://www.icann.org/resources/pages/governance/governance-en>, a + global multi-stakeholder body with representation from end users, + governments, operators, and others. + + Another example is the governance of the Web's trust model, + implemented by web browsers as relying parties that have strong + incentives to protect user privacy and security and CAs as trust + anchors that have a strong incentive to be included in browser trust + stores. To promote the operational and security requirements + necessary to provide the desired properties, the CA/Browser Forum + <https://cabforum.org> was established as an oversight body that + involves both parties as stakeholders. + + These examples are notable in that the governance mechanism is not + specified in the protocol documents directly; rather, they are + layered on operationally, but in a manner that takes advantage of + protocol features that enable the imposition of governance. + + Governance in this manner is suited to very limited functions like + the examples above. Even then, the setup and ongoing operation of a + governance mechanism is not trivial, and their legitimacy may be + difficult to establish and maintain (e.g., see [Palladino]); by their + nature, they are vulnerable to capture by the interests that are + being governed. + +4. What Can Internet Standards Do? + + Given the limits of decentralization techniques like federation and + distributed consensus, the voluntary nature of standards compliance, + and the powerful forces that can drive centralization, it is + reasonable to ask what standards efforts like those at the IETF can + do to accommodate helpful centralization while avoiding the + associated harms and acknowledging that the distinction itself is a + judgment call and, therefore, inherently political. + + The subsections below suggest a few concrete, meaningful steps that + standards bodies can take. + +4.1. Bolster Legitimacy + + Where technical standards have only limited ability to control + centralization of the Internet, legal standards (whether regulation, + legislation, or case law) show more promise and are actively being + considered and implemented in various jurisdictions. However, + regulating the Internet is risky without a firm grounding in the + effects on the architecture informed by a technical viewpoint. + + That viewpoint can and should be provided by the Internet standards + community. To effectively do so, its institutions must be seen as + legitimate by the relevant parties -- for example, competition + regulators. If the IETF is perceived as representing or being + controlled by "big tech" concerns or only US-based companies, its + ability to guide decisions that affect the Internet will be + diminished considerably. + + The IETF already has features that arguably provide considerable + legitimacy. Examples of these features include open participation + and representation by individuals rather than by companies, both of + which enhance input legitimacy); a well-defined process with multiple + layers of appeals and transparency, which contributes to throughput + legitimacy; and a long history of successful Internet standards, + which provides perhaps the strongest source of legitimacy for the + IETF -- its output. + + However, it is also widely recognized that the considerable costs + (not just financial) involved in successfully participating in the + IETF have a tendency to favor larger companies over smaller concerns. + Additionally, the specialized and highly technical nature of the work + creates barriers to entry for non-technical stakeholders. These + factors have the potential to reduce the legitimacy of the IETF's + decisions, at least in some eyes. + + Efforts to address these shortcomings are ongoing; for example, see + [RFC8890]. Overall, bolstering the legitimacy of the organization + should be seen as a continuous effort. + + When engaging in external efforts, the IETF community (especially its + leadership) should keep firmly in mind that its voice is most + authoritative when focused on technical and architectural impact. + +4.2. Focus Discussion of Centralization + + Centralization and decentralization are increasingly being raised in + technical standards discussions. Any claim needs to be critically + evaluated. As discussed in Section 2, not all centralization is + automatically harmful. Per Section 3, decentralization techniques do + not automatically address all centralization harms and may bring + their own risks. + + However, standards participants rarely have the expertise or + information available to completely evaluate those claims, because + the analysis involves not only technical factors, but also economic, + social, commercial, and legal aspects. For example, economies of + scale can cause concentration due to the associated efficiencies + [Demsetz], and so determining whether that concentration is + appropriate requires a detailed economic analysis that is not in + scope for a technical standards body. Furthermore, claims of + centralization may have other motivations; in particular, they can be + proxies for power struggles between actors with competing interests, + and a claim of centralization might be used to deny market + participants and (perhaps more importantly) users the benefits of + standardization. + + Therefore, approaches like requiring a "Centralization + Considerations" section in documents, gatekeeping publication on a + centralization review, or committing significant resources to + searching for centralization in protocols are unlikely to improve the + Internet. + + Similarly, refusing to standardize a protocol because it does not + actively prevent all forms of centralization ignores the very limited + power that standards efforts have to do so. Almost all existing + Internet protocols -- including IP, TCP, HTTP, and DNS -- fail to + prevent centralized applications from using them. While the + imprimatur of the standards track [RFC2026] is not without value, + merely withholding it cannot prevent centralization. + + Thus, discussions should be very focused and limited, and any + proposals for decentralization should be detailed so their full + effects can be evaluated. [Schneider1] implores those who propose + decentralization to be "really, really clear about what particular + features of a system a given design seeks to decentralize" and + promotes considered use of tools like separation of powers and + accountability from "old, institutional liberal political theory". + + When evaluating claims that a given proposal is centralized, the + context of those statements should be examined for presuppositions, + assumptions, and omissions. [Bacchi] offers one framework for + critical interrogations, which can be adapted for centralization- + related discussions: + + 1. What is the nature of the centralization that is represented as + being problematic? + + 2. What deep-seated presuppositions or assumptions (conceptual + logics) underlie this representation of the "problem"? + + 3. How has this representation of the problem come about? + + 4. What is left unproblematic in this problem representation? Where + are the silences? Can the "problem" be conceptualized + differently? + + 5. What effects are produced by this representation of the + "problem"? + + 6. How and where has this representation of the "problem" been + produced, disseminated, and defended? How has it been and/or how + can it be disrupted and replaced? + +4.3. Target Proprietary Functions + + Functions that are widely used but lacking in interoperability are + ripe for standardization efforts. Targeting prominent and + proprietary functions (e.g., chat) is appropriate, but so are smaller + efforts to improve interoperability and portability of specific + features that are often used to lock users into a platform, for + example, a format for lists of contacts in a social network. + + A common objection to this approach is that adoption is voluntary; + there are no "standards police" to mandate their use or enforce + correct implementation. For example, specifications like + [ACTIVITYSTREAMS] were available for some time without being used in + a federated manner by commercial social-networking providers. + + That objection ignores the fact that while standards aren't + mandatory, legal regulation is. Legal mandates for interoperability + are increasingly proposed by policymakers as a remedy for competition + issues (e.g., see [DMA]). This appetite for regulation presents an + opportunity for new specifications to decentralize these functions, + backed by a legal mandate in combination with changing norms and the + resulting market forces [Lessig]. + + That opportunity also presents a risk, if the resulting legal + regulation is at odds with the Internet architecture. Successfully + creating standards that work in concert with legal regulation + presents many potential pitfalls and will require new and improved + capabilities (especially liaison) and considerable effort. If the + technical community does not make that effort, it is likely that + regulators will turn to other sources for interoperability + specifications. + +4.4. Enable Switching + + The ability to switch between different function providers is a core + mechanism to control centralization. If users are unable to switch, + they cannot exercise choice or fully realize the value of their + efforts because, for example, "learning to use a vendor's product + takes time, and the skill may not be fully transferable to a + competitor's product if there is inadequate standardization" + [FarrellJ]. + + Therefore, standards should have an explicit goal of facilitating + users switching between implementations and deployments of the + functions they define or enable. + + One necessary condition for switching is the availability of + alternatives; breadth and diversity of implementation and deployment + are required. For example, if there is only a single implementation + of a protocol, applications that use it are vulnerable to the control + it has over their operation. Even open source projects can be an + issue in this regard if there are factors that make forking difficult + (for example, the cost of maintaining that fork). Section 2.1 of + [RFC5218] explores some factors in protocol design that encourage + diversity of implementation. + + The cost of substituting an alternative implementation or deployment + by users is another important factor to consider. This includes + minimizing the amount of time, resources, expertise, coordination, + loss of functionality, and effort required to use a different + provider or implementation -- with the implication that the standard + needs to be functionally complete and specified precisely enough to + allow substitution. + + These goals of completeness and diversity are sometimes at odds. If + a standard becomes 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 enable easy + switching, especially if proprietary extensions are necessary to + complete it (see Section 4.7). + + One objection to protocols that enable easy switching is that they + reduce the incentives for implementation by commercial vendors. + While a completely commoditized protocol might not allow + implementations to differentiate themselves, they provide + opportunities for specialization and improvement elsewhere in the + value chain [Christensen]. Well-timed standards efforts leverage + these forces to focus proprietary interests on top of open technology + rather than as a replacement for it. + +4.5. Control Delegation of Power + + The users of some functions might realize substantial benefits if + they are provided by a third party in communication. Adding a new + party to communication can improve the following: + + * _Efficiency_: Many functions on the Internet are 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 someone serving content themselves would + otherwise pay because of the scale they operate at. Likewise, a + two-sided market platform can introduce sizable efficiencies over + pair-wise buyer/seller trading [Spulber]. + + * _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 consolidated into a 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 + consolidating their activity to prevent individual behaviors from + being discriminated from each other [Chaum]. 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., + [RFC9230]) that allow end users to hide their identity from + services while still accessing them. + + However, if that new party is able to make their participation + "sticky" -- for example, by leveraging their position in the network + to require use of an intermediary, by exploiting their access to + data, or because it is difficult to switch to another provider of the + function -- there is a risk of centralization. + + Most often, third parties are added to functions as "intermediaries" + or in designated "agent" roles. Designing such functions with + thoughtful constraints on these roles can prevent at least the most + egregious abuses of such power. + + When adding new parties to a function, two guidelines have proven + useful. First, third parties should only be interposed into + communication when at least one of the primary parties takes a + positive action to do so. Second, third parties 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 were only intended to perform basic + functions such as caching. Because of the introduction of HTTPS and + the CONNECT method (see Section 9.3.6 of [HTTP]), combined with + efforts to encourage its adoption, those intermediaries are now + required to be explicitly interposed by one endpoint, and they only + have access to basic routing information. + + See [THOMSON-TMI] 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 website that intermediates between buyers and + sellers is considered an intermediary, even though it is not formally + an intermediary in HTTP (see Section 3.7 of [HTTP]). Protocol + designers can address the centralization associated with this kind of + intermediation by standardizing the function rather than restricting + the capabilities of the underlying protocols; see Section 4.3. + +4.6. Enforce Boundaries + + Most Internet protocols and applications depend on other, "lower- + layer" functions and their implementations. The features, + deployment, and operation of these dependencies can become + centralization risks for the functions and applications built "on + top" of them. + + For example, application protocols require a network to function; + therefore, a degree of power over communication is available to the + network provider. They might block access to, slow down, or change + the content of a specific service for financial, political, + operational, or criminal reasons, creating a disincentive (or even + removing the ability) to use a specific provider of a function. By + selectively hindering the use of some services but not others, + network interventions can be composed to create pressure to use those + other services -- intentionally or not. + + Techniques like encryption can discourage such centralization by + enforcing such boundaries. When the number of parties who have + access to the content of communication is limited, other parties who + handle it but are not party to it can be prevented from interfering + with and observing it. Although those parties might still prevent + communication, encryption also makes it more difficult to + discriminate a target from other users' traffic. + +4.7. Consider Extensibility Carefully + + The Internet's ability to evolve is critical, allowing it to meet new + requirements and adapt to new conditions without requiring a "flag + day" to upgrade implementations. Typically, functions accommodate + evolution by defining extension interfaces, which allow optional + features to be added or change over time in an interoperable fashion. + + However, these interfaces can also be leveraged by a powerful entity + if they can change the target for meaningful interoperability by + adding proprietary extensions to a standard. This is especially true + when the core standard does not itself provide sufficient utility on + its own. + + For example, the extreme flexibility of SOAP [SOAP] and its failure + to provide significant standalone value allowed vendors to require + use of their preferred extensions, favoring 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 functions should not make every aspect of their + operation extensible; boundaries between modules should be designed + in a way that allows evolution, while still offering meaningful + functionality. + + Beyond allowing evolution, well-considered interfaces can also aid + decentralization efforts. The structural boundaries that emerge + between the sub-modules of the function -- as well as those with + adjacent functions -- provide touchpoints for interoperability and an + opportunity for substitution of providers. + + In particular, if the interfaces of a function are well-defined and + stable, there is an opportunity to use different providers for that + function. When those interfaces are open standards, change control + resides with the technical community instead of remaining in + proprietary hands, further enhancing stability and enabling (but not + ensuring) decentralization. + +4.8. Reuse What Works + + When centralization is purposefully allowed in an Internet function, + protocol designers often attempt to mitigate the associated risks + using technical measures such as federation (see Section 3.1.1) and + operational governance structures (see Section 3.1.3). + + Protocols that successfully do so are often reused to avoid the + considerable cost and risk of reimplementing those mitigations. For + example, if a protocol requires a coordinated global naming function, + incorporating the Domain Name System is usually preferable to + establishing a new system. + +5. Future Work + + This document has argued that, while standards bodies have little + means of effectively controlling or preventing centralization of the + Internet through protocol design, there are still concrete and useful + steps they can take to improve the Internet. + + Those steps might be elaborated upon and extended in future work; + however, it is doubtless there is more that can be done. New + decentralization techniques might be identified and examined; what we + learn from relationships with other, more effective regulators in + this space can be documented. + + Some have suggested creating a how-to guide or checklist for dealing + with centralization. Because centralization is so contextual and so + varied in how it manifests, this might best be attempted within very + limited areas -- for example, for a particular type of function or a + function at a particular layer. + + The nature of centralization also deserves further study; in + particular, its causes. While there is much commentary on factors + like network effects and switching costs, other aspects -- such as + behavioral, cognitive, social, and economic factors have received + comparatively little attention, although that is changing (e.g., + [Fletcher]). + +6. Security Considerations + + This document does not have a direct security impact on Internet + protocols. That said, failure to consider centralization might cause + a myriad of security issues; see Section 2.1 for a preliminary + discussion. + +7. IANA Considerations + + This document has no IANA actions. + +8. Informative References + + [Abrahamson] + Abrahamson, Z., "Essential Data", Yale Law Journal, Vol. + 124, No. 3, December 2014, + <https://www.yalelawjournal.org/comment/essential-data>. + + [ACTIVITYSTREAMS] + Prodromou, E., Ed. and J. Snell, Ed., "Activity Streams + 2.0", W3C Recommendation, 23 May 2017, + <https://www.w3.org/TR/2017/REC-activitystreams-core- + 20170523/>. Latest version available at + <https://www.w3.org/TR/ activitystreams-core/>. + + [Aligia] Aligia, P. and V. Tarko, "Polycentricity: From Polanyi to + Ostrom, and Beyond", Governance: An International Journal + of Policy, Administration, and Institutions, Vol. 25, No. + 2, p. 237, DOI 10.1111/j.1468-0491.2011.01550.x, April + 2012, <https://onlinelibrary.wiley.com/doi/abs/10.1111/ + j.1468-0491.2011.01550.x>. + + [Bacchi] Bacchi, C., "Introducing the 'What's the Problem + Represented to be?' approach", Chapter 2, Engaging with + Carol Bacchi, 2012, <https://library.oapen.org/bitstream/ + handle/20.500.12657/33181/560097.pdf?sequence=1#page=34>. + + [Baran] Baran, P., "On Distributed Communications: Introduction to + Distributed Communications Networks", DOI 10.7249/RM3420, + 1964, <https://www.rand.org/pubs/research_memoranda/ + RM3420.html>. + + [BCP95] Alvestrand, H., "A Mission Statement for the IETF", + BCP 95, RFC 3935, October 2004. + + <https://www.rfc-editor.org/info/bcp95> + + [Bodo] Bodó, B., Brekke, J. K., and J.-H. Hoepman, + "Decentralization: a multidisciplinary perspective", + Internet Policy Review, Vol. 10, No. 2, + DOI 10.14763/2021.2.1563, June 2021, + <https://policyreview.info/concepts/decentralisation>. + + [Chaum] Chaum, D., "Untraceable electronic mail, return addresses, + and digital pseudonyms", Communications of the ACM, Vol. + 24, No. 2, DOI 10.1145/358549.358563, February 1981, + <https://dl.acm.org/doi/10.1145/358549.358563>. + + [Christensen] + Christensen, C., "The Law of Conservation of Attractive + Profits", Harvard Business Review, "Breakthrough Ideas for + 2004", February 2004. + + [Demsetz] Demsetz, H., "Industry Structure, Market Rivalry, and + Public Policy", Journal of Law and Economics, Vol. 16, No. + 1, April 1973, <https://www.jstor.org/stable/724822>. + + [DMA] The European Parliament and the Council of the European + Union, "Regulation (EU) 2022/1925 of the European + Parliament and of the Council of 14 September 2022 on + contestable and fair markets in the digital sector and + amending Directives (EU) 2019/1937 and (EU) 2020/1828 + (Digital Markets Act)", OJ L 265/1, 12.10.2022, September + 2022, <https://eur-lex.europa.eu/legal-content/EN/ + TXT/?uri=CELEX%3A32022R1925>. + + [Doctorow] Doctorow, C., "Adversarial Interoperability", October + 2019, <https://www.eff.org/deeplinks/2019/10/adversarial- + interoperability>. + + [ETHEREUM] Ethereum, "The Merge", February 2023, + <https://ethereum.org/en/roadmap/merge/>. + + [FarrellH] Farrell, H. and A. Newman, "Weaponized Interdependence: + How Global Economic Networks Shape State Coercion", + International Security, Vol. 44, No. 1, p. 42, + DOI 10.1162/ISEC_a_00351, July 2019, + <https://doi.org/10.1162/ISEC_a_00351>. + + [FarrellJ] Farrell, J. and C. Shapiro, "Dynamic Competition with + Switching Costs", UC Berkeley Department of Economics + Working Paper 8865, DOI 10.2307/2555402, January 1988, + <https://doi.org/10.2307/2555402>. + + [Fletcher] Fletcher, A., "The Role of Behavioural Economics in + Competition Policy", DOI 10.2139/ssrn.4389681, March 2023, + <https://doi.org/10.2139/ssrn.4389681>. + + [Freeman] Freeman, J., "The Tyranny of Structurelessness", Berkeley + Journal of Sociology, Vol. 17, 1972, + <https://www.jstor.org/stable/41035187>. + + [Holzbauer] + Holzbauer, F., Ullrich, J., Lindorfer, M., and T. Fiebig, + "Not that Simple: Email Delivery in the 21st Century", + July 2022, + <https://www.usenix.org/system/files/atc22-holzbauer.pdf>. + + [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/info/rfc9110>. + + [Kashaf] Kashaf, A., Sekar, V., and Y. Agarwal, "Analyzing Third + Party Service Dependencies in Modern Web Services: Have We + Learned from the Mirai-Dyn Incident?", + DOI 10.1145/3419394.3423664, October 2020, + <https://dl.acm.org/doi/pdf/10.1145/3419394.3423664>. + + [Komaitis] Komaitis, K., "Regulators Seem to Think That Facebook Is + the Internet", August 2021, + <https://slate.com/technology/2021/08/facebook-internet- + regulation.html>. + + [Lessig] Lessig, L., "The New Chicago School", Journal of Legal + Studies, Vol. 27, DOI 10.1086/468039, June 1998, + <https://www.journals.uchicago.edu/doi/10.1086/468039>. + + [Madison] Madison, J., "The Structure of the Government Must Furnish + the Proper Checks and Balances Between the Different + Departments", The Federalist Papers, No. 51, February + 1788. + + [Makarov] Makarov, I. and A. Schoar, "Blockchain Analysis of the + Bitcoin Market", National Bureau of Economic Research, + Working Paper 29396, DOI 10.3386/w29396, October 2021, + <https://www.nber.org/papers/w29396>. + + [Marlinspike] + Marlinspike, M., "Reflections: The ecosystem is moving", + May 2016, + <https://signal.org/blog/the-ecosystem-is-moving/>. + + [Moura] Moura, G., Castro, S., Hardaker, W., Wullink, M., and C. + Hesselman, "Clouding up the Internet: how centralized is + DNS traffic becoming?", DOI 10.1145/3419394.3423625, + October 2020, + <https://dl.acm.org/doi/abs/10.1145/3419394.3423625>. + + [Musiani] Musiani, F., "Alternative Technologies as Alternative + Institutions: The Case of the Domain Name System", The + Turn to Infrastructure in Internet Governance, + DOI 10.1057/9781137483591_4, 2016, + <https://link.springer.com/ + chapter/10.1057/9781137483591_4>. + + [Palladino] + Palladino, N. and M. Santaniello, "Legitimacy, Power, and + Inequalities in the Multistakeholder Internet Governance", + DOI 10.1007/978-3-030-56131-4, November 2020, + <https://link.springer.com/ + book/10.1007/978-3-030-56131-4>. + + [PHONE] Skrzycki, C. and J. Burgess, "Computer Failure Paralyzes + Region's Phone Service", June 1991, + <https://www.washingtonpost.com/archive/ + politics/1991/06/27/computer-failure-paralyzes-regions- + phone-service/0db94ac7-89f0-446e-ba33-c126c751b251/>. + + [RFC2026] Bradner, S., "The Internet Standards Process -- Revision + 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, + <https://www.rfc-editor.org/info/rfc2026>. + + [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A + Border Gateway Protocol 4 (BGP-4)", RFC 4271, + DOI 10.17487/RFC4271, January 2006, + <https://www.rfc-editor.org/info/rfc4271>. + + [RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful + Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, + <https://www.rfc-editor.org/info/rfc5218>. + + [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, + DOI 10.17487/RFC5321, October 2008, + <https://www.rfc-editor.org/info/rfc5321>. + + [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence + Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, + March 2011, <https://www.rfc-editor.org/info/rfc6120>. + + [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, + DOI 10.17487/RFC0791, September 1981, + <https://www.rfc-editor.org/info/rfc791>. + + [RFC8890] Nottingham, M., "The Internet is for End Users", RFC 8890, + DOI 10.17487/RFC8890, August 2020, + <https://www.rfc-editor.org/info/rfc8890>. + + [RFC9230] Kinnear, E., McManus, P., Pauly, T., Verma, T., and C.A. + Wood, "Oblivious DNS over HTTPS", RFC 9230, + DOI 10.17487/RFC9230, June 2022, + <https://www.rfc-editor.org/info/rfc9230>. + + [RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)", + STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022, + <https://www.rfc-editor.org/info/rfc9293>. + + [Schneider1] + Schneider, N., "What to do once you admit that + decentralizing everything never seems to work", Hacker + Noon, September 2019, <https://hackernoon.com/ + decentralizing-everything-never-seems-to-work- + 2bb0461bd168>. + + [Schneider2] + Schneider, N., "Decentralization: An Incomplete Ambition", + Journal of Cultural Economy, Vol. 12, No. 4, + DOI 10.31219/osf.io/m7wyj, April 2019, + <https://osf.io/m7wyj/>. + + [SOAP] Mitra, N., Ed. and Y. Lafon, Ed., "SOAP Version 1.2 Part + 0: Primer (Second Edition)", W3C Recommendation, 27 April + 2007, + <https://www.w3.org/TR/2007/REC-soap12-part0-20070427/>. + Latest version available at <https://www.w3.org/TR/ + soap12-part0/>. + + [Spulber] Spulber, D., "Solving The Circular Conundrum: + Communication and Coordination in Two-Sided Markets", + Northwestern University Law Review, Vol. 104, No. 2, + October 2009, <https://wwws.law.northwestern.edu/research- + faculty/clbe/workingpapers/documents/ + spulber_circularconundrum.pdf>. + + [THOMSON-TMI] + Thomson, M., "Principles for the Involvement of + Intermediaries in Internet Protocols", Work in Progress, + Internet-Draft, draft-thomson-tmi-04, 8 September 2022, + <https://datatracker.ietf.org/doc/html/draft-thomson-tmi- + 04>. + +Acknowledgements + + This document was born out of early discussions with Brian Trammell + during our shared time on the Internet Architecture Board. + + Special thanks to Geoff Huston and Milton Mueller for their well- + considered, thoughtful, and helpful reviews. + + Thanks to Jari Arkko, Kristin Berdan, Richard Clayton, Cory Doctorow, + Christian Huitema, Eliot Lear, John Levine, Tommy Pauly, and Martin + Thomson for their comments and suggestions. Likewise, the arch- + discuss@ietf.org (mailto:arch-discuss@ietf.org) mailing list and + Decentralized Internet Infrastructure Research Group provided + valuable discussion and feedback. + + No large language models were used in the production of this + document. + +Author's Address + + Mark Nottingham + Prahran + Australia + Email: mnot@mnot.net + URI: https://www.mnot.net/ |