RFC 7754

Technical Considerations for Internet Service Blocking and Filtering

📅 published March 2016, from ietf
Part 1 of 8 🎀 more parts are coming, bestie, so stay tuned!

RFC 7754: Technical Considerations for Internet Service Blocking and Filtering ✨

okay so this one is RFC 7754 💅, and its title is Technical Considerations for Internet Service Blocking and Filtering. It was published in March 2016 by the Internet Architecture Board (IAB), so it's an IAB document 🦋. The authors are R. Barnes, A. Cooper, O. Kolkman, D. Thaler, and E. Nordmark, all iconic 👑. Its category is Informational, and its ISSN is 2070-1721. The title block doesn't list anything this RFC obsoletes or updates, so it's a standalone vibe 🌸.

Abstract

the Internet is built to be an open communications medium 🌈. that openness is literally one of the biggest reasons the Internet keeps innovating, but it also means some communications can be seen as undesirable by certain parties 😬. so as the Internet grew, so did the mechanisms for limiting how far and how hard abusive or objectionable communications can spread 🛡️. lately there's been a big push toward "blocking" and "filtering," which is the active prevention of those communications ✨.

this document looks at several technical approaches to blocking and filtering and checks how well each one lines up with the overall Internet architecture 🔍. when it's possible, the approach that fits the architecture best is to tell endpoints about potentially undesirable services, so the communicants can avoid abusive or objectionable communications on their own 🫶. the doc also points out that some filtering and blocking approaches can cause unintended consequences for third parties 💀, and it talks about the limits of how well the various approaches actually work 🙈.

Status of This Memo

this document is not an Internet Standards Track specification 🙅‍♀️. it's just published for informational purposes 💜.

this document is a product of the Internet Architecture Board (IAB), and it holds information the IAB decided was valuable enough to keep on the permanent record 📜. it represents the consensus of the IAB ✨. documents the IAB approves for publication aren't a candidate for any level of Internet Standard, so no standard-level status for this one, periodt 💅. see Section 2 of RFC 5741 for more on that.

info about this document's current status, any errata, and how to give feedback can be found at http://www.rfc-editor.org/info/rfc7754 🔗.

Copyright (c) 2016 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 (http://trustee.ietf.org/license-info), as they were in effect on the publication date ⭐. please read those carefully, because they describe your rights and restrictions for this document 📖.

Table of Contents

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
2.  Filtering Examples  . . . . . . . . . . . . . . . . . . . . .   5
3.  Characteristics of Blocking Systems . . . . . . . . . . . . .   7
  3.1.  The Party Who Sets Blocking Policies  . . . . . . . . . .   8
  3.2.  Purposes of Blocking  . . . . . . . . . . . . . . . . . .   8
    3.2.1.  Blacklist vs. Whitelist Model . . . . . . . . . . . .   9
  3.3.  Intended Targets of Blocking  . . . . . . . . . . . . . .   9
  3.4.  Components Used for Blocking  . . . . . . . . . . . . . .  10
4.  Evaluation of Blocking Design Patterns  . . . . . . . . . . .  11
  4.1.  Criteria for Evaluation . . . . . . . . . . . . . . . . .  11
    4.1.1.  Scope: What set of hosts and users are affected?  . .  12
    4.1.2.  Granularity: How specific is the blocking?  Will
            blocking one service also block others? . . . . . . .  12
    4.1.3.  Efficacy: How easy is it for a resource or service to
            avoid being blocked?  . . . . . . . . . . . . . . . .  13
    4.1.4.  Security: How does the blocking impact existing trust
            infrastructures?  . . . . . . . . . . . . . . . . . .  14
  4.2.  Network-Based Blocking  . . . . . . . . . . . . . . . . .  15
    4.2.1.  Scope . . . . . . . . . . . . . . . . . . . . . . . .  16
    4.2.2.  Granularity . . . . . . . . . . . . . . . . . . . . .  17
    4.2.3.  Efficacy and Security . . . . . . . . . . . . . . . .  17
    4.2.4.  Summary . . . . . . . . . . . . . . . . . . . . . . .  20
  4.3.  Rendezvous-Based Blocking . . . . . . . . . . . . . . . .  20
    4.3.1.  Scope . . . . . . . . . . . . . . . . . . . . . . . .  21
    4.3.2.  Granularity . . . . . . . . . . . . . . . . . . . . .  21
    4.3.3.  Efficacy  . . . . . . . . . . . . . . . . . . . . . .  21
    4.3.4.  Security and Other Implications . . . . . . . . . . .  22
    4.3.5.  Examples  . . . . . . . . . . . . . . . . . . . . . .  22
    4.3.6.  Summary . . . . . . . . . . . . . . . . . . . . . . .  23
  4.4.  Endpoint-Based Blocking . . . . . . . . . . . . . . . . .  24
    4.4.1.  Scope . . . . . . . . . . . . . . . . . . . . . . . .  24
    4.4.2.  Granularity . . . . . . . . . . . . . . . . . . . . .  24
    4.4.3.  Efficacy  . . . . . . . . . . . . . . . . . . . . . .  25
    4.4.4.  Security  . . . . . . . . . . . . . . . . . . . . . .  25
    4.4.5.  Server Endpoints  . . . . . . . . . . . . . . . . . .  25
    4.4.6.  Summary . . . . . . . . . . . . . . . . . . . . . . .  26
5.  Security Considerations . . . . . . . . . . . . . . . . . . .  26
6.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .  27
7.  Informative References  . . . . . . . . . . . . . . . . . . .  28
IAB Members at the Time of Approval . . . . . . . . . . . . . . .  32
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  33
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  33

1. Introduction 🧚

okay so the original design goal of the Internet was to let hosts talk to each other 💖. but once that goal was met and people actually started using it to communicate, it became clear that some hosts were doing communications that certain parties saw as undesirable 😭. the most famous early example is the Morris worm [Morris], which used the Internet to infect many hosts in 1988 💀. as the Internet grew into a rich communications medium, so did the ways of restricting communications seen as undesirable 🌸. those range from acceptable use policies enforced through informal channels all the way to technical blocking mechanisms ⚙️.

the ways people try to restrict or deny access to Internet resources and services have changed a lot over time 🦋. as noted in [RFC4084], some Internet service providers filter traffic to limit which applications their customers can use and which traffic they allow on their networks 📶. those restrictions are often put in place with customer consent, and the customers can be enterprises or individuals 🫶. however, governments, service providers, and enterprises are increasingly trying to block or filter access to certain content, traffic, or services without the knowledge or agreement of the affected users 🙈. when those organizations don't directly control the networks themselves, they commonly try to use intermediary systems to carry out the blocking or filtering 🕵️‍♀️.

blocking and filtering are super contentious in a lot of cases 🔥, but the desire to restrict communications or access to content will likely keep existing 💅.

the difference between "blocking" and "filtering" is really just a matter of scale and perspective ✨. "blocking" often means preventing access to resources in the aggregate, while "filtering" means preventing access to specific resources within an aggregate 🍓. both can happen at the level of "services" (web hosting or video streaming, for example) or at the level of particular "content" 🎀. for the analysis in this document, the distinction between blocking and filtering doesn't create meaningfully different conclusions 🌈. so for the rest of the doc, we treat the terms as generally equivalent and applicable to restrictions on both content and services 🫶.

this document wants to clarify the technical implications and trade-offs of various blocking strategies 🔍, and to identify where different strategies have the potential to cause harmful side effects ("collateral damage") for Internet users and the overall Internet architecture 💔. this analysis is limited to technical blocking mechanisms 🛠️. the scope of the blocking analyzed here is limited to intentional blocking, not accidental blocking caused by misconfiguration or as an unintentional side effect of something else 🙅‍♀️.

filtering can be considered legal, illegal, ethical, or unethical depending on where it happens, when it happens, and who's doing it ⚖️. this document is for people who are filtering, or thinking about filtering, and who want to understand what their decisions mean for the Internet architecture and the trade-offs that come with each type of filtering strategy 📚. it does not give formulas for making those trade-offs, since filtering decisions probably need context-specific details 🧐. whether particular forms of filtering are lawful in particular jurisdictions raises complicated legal questions that are outside the scope of this document ⚖️. for similar reasons, questions about the ethics of particular forms of filtering are also out of scope 🫠.

2. Filtering Examples ✨

okay so blocking systems have been glowing up right alongside the Internet itself 💅 looking back, there have been a bunch of these systems, set up by different people for different reasons 🦋

Firewalls: firewalls are everywhere in today's Internet [RFC2979] 🔥 they can live on end hosts (under user or admin control) or sit in the network, usually at network boundaries 🌸 the Internet Security Glossary [RFC4949] has a fancy extended definition, but honestly most people just think of a firewall as "something that blocks unwanted traffic" 🙈 (see [RFC4948] for a whole discussion on the many types of unwanted traffic). there are lots of firewall flavors, but a few specific types are worth knowing about 🎀

  • Stateless Packet Filtering: stateless packet filters block based on content-neutral rules, like blocking all inbound connections or outbound connections on certain ports, protocols, or network-layer addresses 🧚 for example, blocking outbound connections to port 25.
  • Stateful Packet Filtering: more advanced setups need to keep state so they can enforce flow-based policies, like blocking inbound traffic for flows that haven't been established ✨
  • Deep Packet Inspection: the even fancier setups do deep packet inspection and filter or block based on the content being carried 👑 lots of firewalls also include web filtering capabilities (see below) 💜

Web Filtering: HTTP and HTTPS are super common targets for blocking and filtering, usually aimed at specific URIs 🍓 some enterprises use HTTP blocking to keep out non-work-appropriate websites, and several nations make their ISPs filter HTTP and HTTPS to block content they consider illegal 😭 HTTPS is a real challenge for these systems, because the URI in an HTTPS request rides inside the encrypted channel 🔐 so to block content delivered over HTTPS, filtering systems have to either block based on network- and transport-layer headers (IP address and/or port), or obtain a trust anchor certificate that endpoints trust and basically act as a man in the middle 💀 these filtering systems often show up as "portals" or "enterprise proxies" that present their own dynamically generated HTTPS certificates 🫶 (See further discussion in Section 5.)

Spam Filtering: spam filtering is one of the oldest forms of content filtering, no cap 🌈 spam filters judge messages using a variety of criteria and information sources to decide whether a message is spam ⭐ for example, DNS Blacklists use the reverse DNS to flag whether an IP address is a known spam source [RFC5782] 💅 spam filters can live on user devices (like in a mail client), be run by a mail domain on behalf of its users, or be outsourced to a third party acting as an intermediate MX proxy 🦋

Domain Name Seizure: there are a bunch of ways to block or modify resolution of a domain name 🌸 one approach is using ICANN's Uniform Dispute Resolution Policy (URDP) to deal with fraudulent use of a name ✨ other authorities may require domains to be blocked within their jurisdictions 🙈 there's been a lot of research on the value and efficacy of these seizures [Takedown08] [BlackLists14] 🔥

The exact method of seizing domain names varies from place to place 🧚 one approach in use is having queries redirected so they resolve to IP addresses of the authority that hosts info about the seizure 💜 how well a seizure works also depends on the method. sometimes the person whose name got seized just switches to a new name 😭 other times the block only works within a region, or only when specific name service infrastructure is used 🍓

Seizures can also have overbroad effects 💀 access to content gets blocked not just within the seizing jurisdiction, but globally, even when it's totally legal somewhere else [RojaDirecta]. when domain redirection happens at intermediate resolvers instead of at authoritative servers, it directly contradicts the end-to-end assumptions in the DNS security architecture [RFC4033], and can potentially cause validation failures by validating end-nodes 🫠

Safe Browsing: modern web browsers have some built-in measures to keep users away from malicious websites 🛡️ for instance, before loading a URI, current versions of Google Chrome and Firefox use the Google Safe Browsing service to figure out whether a given URI is safe to load [SafeBrowsing] 🌟 the DNS can also store third party information that marks domains as safe or unsafe [RFC5782] ✨

Manipulation of routing and addressing data: governments have recently gotten involved in managing IP addressing and routing information so they can keep control over a specific set of DNS servers 👀 as part of an internationally coordinated response to the DNSChanger malware, a Dutch court ordered the RIPE NCC to freeze the accounts of several resource holders, which limited those holders' ability to use certain address blocks [GhostClickRIPE] (also see Section 4.3) 😱 this has raised concerns that the number resource certification system and related secure routing technologies developed by the IETF's SIDR working group could be subject to government manipulation too [RFC6480], potentially to deny targeted networks access to the Internet 💔

Ingress filtering: network service providers use ingress filtering [RFC2827] [RFC3704] to prevent source address spoofing, which gets used as part of other attacks 🛡️

Data loss prevention (DLP): enterprises and other networks worry about confidential information leaking, whether by accident or on purpose 🔒 some of the tools for this are similar to the main subject of this document, blocking and filtering 🎀 in particular, enterprise proxies might be part of a DLP solution 💅

3. Characteristics of Blocking Systems ✨

at a generic level, blocking systems can be characterized by four attributes: the party who sets the blocking policy, the purpose of the blocking, the intended target of the blocking, and the Internet component(s) used as the basis of the blocking system 🦋

3.1. The Party Who Sets Blocking Policies

parties that institute blocking policies include governments, courts, enterprises, network operators, reputation trackers, application providers, and individual end users 🌈 a government might make laws based on cultural norms and/or its elected mandate ⭐ enterprises might use cultural, industry, or legal norms to guide their policies 💼

there can be several steps of translation and transformation from the original intended purpose 🌀 first to laws, then to (government) regulation, followed by high-level policies at, e.g., network operators, and from those policies to filtering architecture and implementation 🧚 each of those steps is a potential source of unintended consequences, as discussed in this document 😬

sometimes the entity that sets the policy is the same entity that enforces it 💅 for example, a network operator might install a firewall in its own networking equipment, or a web application provider might block responses between its web server and certain clients 🔥

other times the policy-setting entity is different from the enforcing entity 🫶 the policy might be imposed on the enforcer, like with blocking initiated by governments, or the enforcer might choose to use policy set by others, like a reputation system used by a spam filter or a safe browsing service 👑 because a policy might be enforced by others, it's best if it can be expressed in a form that's independent of the enforcing technology 🎀

3.2. Purposes of Blocking

there are a bunch of motivations to filter 💜

  • Preventing or responding to security threats. network operators, enterprises, application providers, and end users often block communications believed to be tied to security threats or network attacks 🛡️
  • Restricting objectionable content or services. certain communications may be seen as undesirable, harmful, or illegal by particular governments, enterprises, or users 😤 governments may want to block communications deemed defamation, hate speech, obscenity, intellectual property infringement, or otherwise objectionable 🙅 enterprises may want to keep employees from accessing content that isn't deemed work appropriate 💼 parents may restrict their children from accessing content or services aimed at adults 🧸
  • Restricting access based on business arrangements. some networks are designed to only provide access to certain content or services ("walled gardens") 🏰 or to only provide limited access until end users pay for full Internet services (captive portals provided by hotspot operators, for example) 💸

3.2.1. Blacklist vs. Whitelist Model

the purpose of the blocking often dictates whether the system runs on a blacklist model, where communications are allowed by default but a subset gets blocked, or a whitelist model, where communications are blocked by default with only a subset allowed 🦋 captive portals, walled gardens, and sandboxes used for security or network endpoint assessment usually use a whitelist model, since the scope of allowed communications is narrow 🌸 blocking for other purposes often uses a blacklist model, since only individual content or traffic is meant to be blocked ✨

3.3. Intended Targets of Blocking

blocking systems are set up to target particular content, services, endpoints, or some combination of these 🎯 for example, a "content" filtering system used by an enterprise might block access to specific URIs whose content the enterprise deems inappropriate for the workplace 💅 that's different from a "service" filtering system that blocks all web traffic (maybe as part of a parental control system on an end-user device) 🧚 and also different from an "endpoint" filtering system, where a web application blocks traffic from specific endpoints suspected of malicious activity 🔥

as discussed in Section 4, the design of a blocking system may affect content, services, or endpoints other than the intended targets 😱 for example, when the domain name seizures described above are meant to address specific web pages tied to illegal activity, removing the domains from use also affects every service made available by the hosts associated with those names, including mail and web services that may be totally unrelated to the illegal activity 💔 depending on where the block is imposed within the DNS hierarchy, entirely unrelated organizations may be impacted 🌧️

3.4. Components Used for Blocking

okay bestie, let's talk about the three big pieces that make an internet service actually happen 🧚💖

  1. Endpoints: 💅 the actual content of the service is usually an application-layer protocol running between two or more Internet hosts. Lots of protocols have exactly two endpoints, a client and a server.
  2. Network services: 🌸 the endpoints talk to each other through a bunch of IP networks, and those networks use routing protocols to figure out how to get packets from one endpoint to the other.
  3. Rendezvous services: 🦋 service endpoints usually get identified by names that are way more "human-friendly" than IP addresses (nobody wants to type 192.0.2.1 🙈). Rendezvous services let one endpoint figure out how to contact another one based on that identifier. The domain name system is the classic example, and Distributed Hash Tables (DHTs) have also been used as rendezvous services ✨

Let's use an example, okay? 🎀 Say an HTTP transaction is fetching <http://example.com/index.html>. The client endpoint is an end host running a browser. The client uses the DNS as a rendezvous service when it does a AAAA query to get the IP address for the server name "example.com" 🍓 Then the client sets up a connection to the server and sends the actual HTTP request. After that, the server endpoint responds to the request. Slay 💅

Another example: in SIP, the two endpoints talking are IP phones, and the rendezvous service is provided by an application-layer SIP proxy plus the DNS 📞🫶

So, blocking access to Internet content, services, or endpoints is done by controlling one or more of these components that are involved in delivering the communication 🚫 In the HTTP example above, there are a bunch of ways the successful completion of that request could get stopped:

  • [Endpoint] Preventing the client from making the request 🙅‍♀️
  • [Endpoint] Preventing the server from responding to the request 😭
  • [Endpoint] Preventing the client from making the DNS request needed to resolve example.com 💀
  • [Network] Preventing the request from reaching the server
  • [Network] Preventing the response from reaching the client
  • [Network] Preventing the client from reaching the DNS servers
  • [Network] Preventing the DNS responses from reaching the client
  • [Rendezvous] Preventing the DNS servers from giving the client the correct IP address of the server 🧩

Here's the thing though: people who want to block communications usually only have access to one or two of these components, so their options are pretty limited 🥺 End users and application providers can usually only control their own software and hardware, which means they're stuck with endpoint-based filtering. Some network operators offer filtering services that customers can switch on individually, so end users might have network-based filtering available to them too 🌈 Network operators can control their own networks and the rendezvous services they provide infrastructure support for (like DNS resolvers), or ones they might have access to (like SIP proxies), but usually not endpoints 👑 Enterprises usually have access to their own networks and endpoints for filtering, so that's their lane 💼 And governments might make arrangements with the operators or owners of any of the three components that exist within their jurisdictions to do filtering 🏛️

Next up, we look at blocking systems built on each of the three patterns (network services, rendezvous services, and endpoints) and check out their technical and architectural implications 🔍 The analysis tries to stay as agnostic as possible about who sets the blocking policy (government, end user, network operator, application provider, or enterprise). But the way a particular blocking pattern gets used can still differ depending on who wants the block 🤔 For example, a network-based firewall that an ISP offers for parental control, which parents can choose to turn on, will probably work differently from one that every ISP in a jurisdiction is required to run by the local government 🙃 Same component (network) underneath, though, so the basis is the same 🫶

4. Evaluation of Blocking Design Patterns ✨

4.1. Criteria for Evaluation 📋

Okay so to evaluate the technical implications of each blocking design pattern, we compare them on four criteria: scope, granularity, efficacy, and security 🔥

4.1.1. Scope: What set of hosts and users are affected? 🌍

The Internet is made of lots of distinct autonomous networks and applications, which means a blocking system's impact only stays inside a defined topological scope 🕸️ For example, blocking within an access network only affects a well-defined set of users (namely, the people connected to that access network). Blocking done by an application provider, though, can affect users across the entire Internet 🌐

Blocking systems are generally seen as less objectionable when their impact is as narrow as possible while still working, and as long as the impact stays within the administrative realm of whoever set the policy 💅 As mentioned before, enterprise blocking systems are super common and will generally affect enterprise users 🏢 But design flaws can make the effects of blocking overbroad 😬 For example, at least one service provider blocking content because of a regulation ended up blocking content for downstream service providers. It filtered routes to particular systems and didn't pass the original information along to downstream service providers in other jurisdictions [IN-OM-filtering]. Other service providers have accidentally leaked such black hole routes beyond the jurisdiction [NW08]. A lot of work has gone into BGP security to prevent these kinds of attacks, but deployment of those systems is lagging behind 🐢

4.1.2. Granularity: How specific is the blocking? Will blocking one service also block others? 🎯

Okay, Internet applications are built from a bunch of loosely coupled components, aka "layers" 🧁 Different layers serve different purposes and rely on or offer different functions, like routing, transport, and naming (see [RFC1122], especially Section 1.1.3). These functions get developed independently and are almost always operated by different parties 🤝 For example, in lots of networks, physical and link-layer connectivity is provided by an "access provider," IP routing is handled by an "Internet service provider," and application-layer services come from totally separate entities (like web servers) 💖 Upper-layer protocols and applications rely on combinations of lower-layer functions to work. Functionality at higher layers tends to be more specialized, so lots of different specialized applications can use the same generic underlying network functions ✨

Because of this structure, actions taken at one layer can affect functionality or applications at other layers 😵‍💫 For example, manipulating routing or naming functions to restrict access to a narrow set of resources via specific applications will likely affect every application that depends on those functions 💀 Just like with the scope criteria, blocking systems are generally seen as less objectionable when they're highly granular and don't cause collateral damage to content or services unrelated to the target of the blocking [RFC4924] 🙌

Even within the application layer, granularity can vary depending on how targeted the blocking system is designed to be 🏹 Blocking all traffic for a particular application protocol is less granular than blocking only the traffic tied to a subset of application instances that use that protocol 🧠 Sophisticated heuristics that look at application protocol info, lower-layer protocols, payload signatures, source and destination addresses, inter-packet timing, packet sizes, and other characteristics are sometimes used to narrow down the subset of traffic to block 🔬

4.1.3. Efficacy: How easy is it for a resource or service to avoid being blocked? ✨

Okay bestie, efficacy is the big one 💅. Blocking something might work for a hot second, but the real question is whether it's easy to dodge. A one-and-done policy usually doesn't last (see [CleanFeed] and [BlackLists14]) 🙈. Experience shows blacklists need constant babysitting: you keep adding new entries for unwanted traffic and deleting entries once the bad content is gone 🧹. It can also be really hard to tell when it's safe to unblock. If a host got hijacked and used to launch attacks, it's not obvious when that site has actually been fixed 🤔.

Blacklist-style blocking also struggles because Internet resources are so distributed and mobile 🌍. A service blocked in one jurisdiction can get moved or re-instantiated in another (see, for example, [Malicious-Resolution]) 🦋. Services that depend on blocked resources can be reconfigured to use unblocked ones super fast ⚡. If a website can't use a domain name or a set of IP addresses, it can move its content to another domain name or network, or use alternate syntaxes to write the same resource name (see the discussion of false negatives in [RFC6943]) 🎭.

Then there's "snowshoe spamming" ❄️: a spam originator uses addresses across tons of different networks as sources. It's already common for spam to be spread across lots of resources and jurisdictions so spam blocking doesn't work well 📨.

Whether you're dealing with blacklist or whitelist systems, users and apps can still try to dodge the filters 🕵️‍♀️.

Users can switch protocols or change their traffic patterns to get around filters 🌀. Sometimes apps move their traffic to port 80 or 443 when other ports are blocked 🎀. Or services get tunneled inside other services, proxied by a helpful outside host (like an anonymous redirector), or just run on an alternate port (like 8080 instead of 80 for HTTP) 🚪. Another trick is changing how the service behaves so it uses a dynamic port negotiation phase and isn't stuck on one constant port 🔁.

Here's a fun one about HTTP: a big reason people wanted HTTP/2 to be encrypted by default was that unencrypted HTTP 1.1 traffic was sometimes blocked or improperly processed 😤. When users or apps shift to encrypted HTTP, they slip past filters that depend on the HTTP plaintext payload 🔐.

If voice calls based on SIP [RFC3261] get blocked, people will probably switch to apps that use proprietary protocols so they can still talk to each other 📞.

Some filtering systems only recognize IPv4 traffic, so shifting to IPv6 can help users evade them 🧊. Using IPv6 with header options, stacking multiple layers of tunnels, or using encrypted tunnels also makes it harder for blocking systems to find transport ports inside packets, which makes port-based blocking way trickier 🙃. So yeah, distribution and mobility can hamper blocking efforts in a bunch of different ways 💜.

4.1.4. Security: How does the blocking impact existing trust infrastructures? 🔐

Modern security mechanisms rely on trusted hosts talking over a secure channel with no middleman interfering 🛡️. Protocols like Transport Layer Security (TLS) [RFC5246] and IPsec [RFC4301] are built so each endpoint knows who the other endpoint(s) is, and only the endpoints of the communication can access the secured contents 👀. Like, when you connect to your bank's website, TLS makes sure your banking info goes to the bank and nobody else, so it stays confidential in transit 🏦💕.

Some blocking strategies need intermediaries to insert themselves into the end-to-end path, and that can break the security properties of Internet protocols [RFC4924] 😬. When that happens, it can be really hard or impossible for endpoints to tell attackers apart from "authorized" parties doing the blocking 👻. For example, an enterprise firewall administrator could end up accessing users' personal bank accounts when people on the enterprise network connect to bank websites 😱.

Bestie, this one is serious. Breaking the trust between endpoints is a real privacy and security risk, not a small inconvenience 🚨

Finally, you have to evaluate whether a blocking mechanism can be used by an end user to efficiently locate blocked resources, which can then be reached through other mechanisms that get around the block 🔍. For example, Clayton [CleanFeed] showed how special treatment in one blocking system could be detected by end users to efficiently locate illegal websites. That was super counterproductive to the policy goal of the blocking mechanism 🙃.

4.2. Network-Based Blocking 🛰️

Being able to block access to resources without the consent or cooperation of either endpoint is viewed as a desirable feature by some people who deploy blocking systems 👑. Systems with this property are often implemented using intermediary devices in the network, like firewalls or filtering systems 🧱. These systems inspect traffic as it passes through the network, decide based on the characteristics or content of a communication whether it should be blocked, and then block or allow it as desired ⚖️. For example, web filtering devices usually inspect HTTP requests to determine the URI being requested, compare that URI to a list of blacklisted or whitelisted URIs, and allow the request to proceed only if policy permits it 🌐. Firewalls do a similar job for other classes of traffic besides HTTP 🔥. Some blocking systems focus on specific application-layer traffic, while others, like router Access Control Lists (ACLs), filter traffic based on lower-layer criteria (transport protocol and source or destination addresses or ports) 🧩.

Intermediary systems used for blocking are often not far from the edge of the network 📍. Lots of enterprise networks operate firewalls that block certain websites, and so do some residential ISPs 🏠. Sometimes this filtering happens with the consent or cooperation of the affected endpoints. PCs in an enterprise might be configured to trust an enterprise proxy, a residential ISP might offer a "safe browsing" service, or mail clients might authorize mail servers on the local network to filter spam on their behalf 📬. These cases share some properties with the "Endpoint-Based Blocking" scenarios discussed in Section 4.4 below, since the endpoint has made an informed decision to let the intermediary block on its behalf, so it's unlikely to try to circumvent the blocking 🤝. From an architectural perspective, though, they can still create many of the same problems as network-based filtering conducted without consent 🫠.

4.2.1. Scope 🎯

In the case of government-initiated blocking, network operators subject to a specific jurisdiction may be required to block or filter 🏛️. So laws can be structured to result in blocking by putting obligations on network operators in a jurisdiction, either through direct government action or by letting private actors demand blocking (for example, through lawsuits) ⚖️.

Regardless of who owns a blocking policy, enforcement can be done using Stateless Packet Filtering, Stateful Packet Filtering, or Deep Packet Inspection, as defined in Section 2 🔍. Stateless Packet Filtering has granularity issues (discussed in Section 4.2.2), while network-based Stateful Packet Filtering and Deep Packet Inspection approaches often run into technical issues that limit how viable they are in practice 😵‍💫. A lot of these issues come down to the fact that an intermediary needs access to a sufficient amount of traffic to make its blocking calls 📊.

For residential or consumer networks with lots of egress points, the first step is simply getting access to the constituent packets 🚪. The Internet is designed to deliver packets independently from source to destination, not to any particular point along the way 📦. So the sequence of packets from the sender can only be reliably reconstructed at the intended receiver 🧩. On top of that, inter-network routing is often asymmetric, and for sufficiently complex local networks, intra-network traffic flows can be asymmetric as well [asymmetry] 🌀. That means packets in the reverse direction use a different set of paths than the forward direction 🔄.

This asymmetry means an intermediary in a network with many egress points may, depending on topology and configuration, see only one half of a given communication, which can limit the scope of what it can filter 👀. For example, a filter aimed at requests destined for particular URIs can't make accurate blocking decisions based on the URI if it's only in the data path for HTTP responses and not requests, since the URI isn't included in the responses 🙅‍♀️. Asymmetry may be surmountable with a filtering system that has enough distributed, interconnected filtering nodes that can coordinate information about flows belonging to the same communication or transaction. But depending on the size of the network, that can get seriously complex 🧠. Routing can sometimes be forced to be symmetric within a given network using routing configuration, NAT, or Layer 2 mechanisms (for example, MPLS), but these are frequently brittle, complex, and costly, and can sometimes reduce network performance compared to asymmetric routing 🐢. Enterprise networks may be less susceptible to these problems if they route all traffic through a small number of egress points 🏢.

4.2.2. Granularity 🔬

Once an intermediary in a network has access to traffic, it has to identify which packets need filtering 🎯. That decision is usually based on some combination of information at the network layer (for example, IP addresses), transport layer (ports), or application layer (URIs or other content) 🧁. Deep Packet Inspection type blocking based on application-layer attributes can be more granular and less likely to cause collateral damage than blocking all traffic associated with a particular address, which can hit unrelated occupants of the same address 💥. But more narrowly focused targeting may be more complex, less efficient, or easier to circumvent than filtering that sweeps more broadly, so folks who want to block have to balance these attributes against each other when choosing a blocking system ⚖️💖.

4.2.3. Efficacy and Security ✨

Okay so no matter which layer the blocking happens at 🧚, it may be open to circumvention, especially when the endpoints never agreed to the blocking 🙈. The two endpoints can literally hide attributes from the middle person at any layer by encrypting stuff (more on that below 👀). IP addresses must stay visible even when packets are protected with IPsec 🌸, but blocking by IP address can be trivial to dodge 💀. A filtered site can switch to a new IP in a few quick steps: change one DNS record, set up the new address on its server, or move its services to the new address [BT-TPB] 🦋.

Indeed, Poort, et al. [Poort] found that "any behavioural change in response to blocking access to The Pirate Bay has had no lasting net impact on the overall number of downloaders from illegal sources, as new consumers have started downloading from illegal sources and people learn to circumvent the blocking while new illegal sources may be launched, causing file sharing to increase again", and that these results "are in line with a tendency found in the literature that any effects of legal action against file sharing often fade out after a period of typically six months." 📉 The vibes are very "it always comes back" 💅.

If application content is encrypted with a security protocol such as IPsec or TLS, then the intermediary will need to decrypt the packets to examine the content, or resort to statistical methods to guess what the content is 🤔. Security protocols are generally designed to provide end-to-end security (i.e., to prevent intermediaries from examining content), so the intermediary would need to masquerade as one of the endpoints. That means breaking the authentication in the security protocol 😬, reducing the security of the users and services affected, and interfering with legitimate private communication. Besides, various techniques that use public databases with whitelisted keys (e.g., DANE [RFC6698]) let users detect these sort of intermediaries 🕵️‍♀️. Those users are then likely to act as if the service is blocked 🙅‍♀️.

If the intermediary is unable to decrypt the security protocol, then its blocking decisions for secure sessions can only be based on unprotected attributes, such as IP addresses, protocol IDs, port numbers, packet sizes, and packet timing 📦. Some blocking systems today still try to block based on these attributes, for example by blocking TLS traffic to known proxies that could be used to tunnel through the blocking system 🚧.

However, as the Telex project [Telex] recently demonstrated, if an endpoint cooperates with a relay in the network (e.g., a Telex station), it can create a TLS tunnel that is indistinguishable from legitimate traffic 🤯. For example, if an ISP used by a banking web site were to operate a Telex station at one of its routers, then a blocking system would be unable to tell legitimate encrypted banking traffic apart from Telex-tunneled traffic (potentially carrying content that would have been filtered) 🏦.

Thus, in principle in a blacklist system it is impossible to block tunneled traffic through an intermediary device without blocking all secure traffic from that system. (The only limitation in practice is the requirement for special software on the client.) Those who require that secure traffic be blocked from such sites risk blocking content that would be valuable to their users, perhaps impeding substantial economic activity 💸. Conversely, those who are hosting a myriad of content have an incentive to see that law abiding content does not end up being blocked 🫶.

Governments and network operators should, however, take care not to encourage the use of insecure communications in the naming of security, as doing so will invariably expose their users to the various attacks that the security protocols were put in place to prevent 🚨. Like, the whole point of security protocols is to stop exactly that, so please don't 😭.

Some operators may assume that only blocking access to resources available via unsecure channels is sufficient for their purposes. In other words, the size of the user base that is willing to use secure tunnels and/or special software to circumvent the blocking is low enough to make blocking via intermediaries worthwhile 🧐. Under that assumption, one might decide there is no need to control secure traffic, and so network-based blocking looks like an attractive option 🎯.

However, the longer such blocking systems are in place, the more likely it is that efficient and easy-to-use tunneling tools will become available 🚀. The proliferation of the Tor network, for example, and its increasingly sophisticated blocking-avoidance techniques show that there is energy behind this trend [Tor] 🧅. Thus, network-based blocking becomes less effective over time 📉.

Network-based blocking is a key contributor to the arms race that has led to the development of such tools, and the result is unnecessary layers of complexity in the Internet 😵‍💫. Before content-based blocking became common, the next best option for network operators was port blocking. Its widespread use drove more applications and services to use ports (80 and 443 most commonly) that are unlikely to be blocked 🔌. In turn, network operators shifted to finer-grained content blocking over port 80, content providers shifted to encrypted channels, and operators began trying to identify those channels (although doing so can be resource-prohibitive, especially if tunnel endpoints begin to change frequently) 🐭. Because the premise of network-based blocking is that endpoints have incentives to circumvent it, this cat-and-mouse game is an inevitable by-product of this form of blocking 🐱.

One reason above all stands as an enormous challenge to network-based blocking: the Internet was designed on the premise that people will want to connect and communicate 🌍. IP will run on anything up to and including carrier pigeons [RFC1149] 🐦. It often runs atop TLS, and it has been made to run on other protocols that themselves run atop IP 🧁. Because of this fundamental layering approach, nearly any authorized avenue of communication can be used as a transport. This same "problem" lets communications succeed in the most challenging of environments 👑.

4.2.4. Summary 📝

In sum, network-based blocking is only effective in a fairly constrained set of circumstances 🎀. First, the traffic needs to flow through the network in such a way that the intermediary device has access to any communications it intends to block. Second, the blocking system needs an out-of-band mechanism to mitigate the risk of secure protocols being used to avoid blocking (e.g., human analysts identifying IP addresses of tunnel endpoints) 🔍. If the network is sufficiently complex, or the risk of tunneling is too high, then network-based blocking is unlikely to be effective. In any case, this type of blocking drives the development of increasingly complex layers of circumvention 🌀. Network-based blocking can be done without the cooperation of either endpoint to a communication, but it has the serious drawback of breaking end-to-end security assurances in some cases 💔. The fact that network-based blocking is premised on this lack of cooperation results in arms races that increase the complexity of both application design and network design 🥴.

4.3. Rendezvous-Based Blocking 🌐

Internet applications often require or rely on support from common, global rendezvous services, including the DNS, certificate authorities, search engines, WHOIS databases, and Internet Route Registries 🗺️. These services control or register the structure and availability of Internet applications by providing data elements that are used by application code. Some applications also have their own specialized rendezvous services. For example, to establish an end-to-end SIP call, the end-nodes (terminals) rely on presence and session information supplied by SIP servers 📞.

Global rendezvous services are made up of generic technical databases intended to record certain facts about the network 🗃️. The DNS, for example, stores information about which servers provide services for a given name, and the Resource Public Key Infrastructure (RPKI) stores information about which organizations have been allocated IP addresses 🪪. To offer specialized Internet services and applications, different people rely on these generic records in different ways. So the effects of changes to the databases can be much more difficult to predict than, say, the effect of shutting down a web server (which has the specific purpose of serving web content) 🤷‍♀️.

Although rendezvous services are discussed as a single category, the precise characteristics and implications of blocking each kind of rendezvous service are slightly different. This section gives examples to highlight these differences ✨.

4.3.1. Scope 🎯

In the case of government-initiated blocking, the operators of servers used to provide rendezvous service that are subject to a specific jurisdiction may be required to block or filter. So it is possible for laws to be structured to result in blocking, by imposing obligations on the operators of rendezvous services within a jurisdiction, either via direct government action or by allowing private actors to demand blocking (e.g., through lawsuits) ⚖️.

The scope of blocking conducted by others will depend on which servers they can access. For example, network operators and enterprises may be capable of conducting blocking using their own DNS resolvers or application proxies within their networks, but not authoritative servers controlled by others 🏢.

However, if a service is hosted and operated within a jurisdiction where it is considered legitimate, then blocking access at a global rendezvous service (e.g., one within a jurisdiction where it is considered illegitimate) might deny services in jurisdictions where they are considered legitimate 🙃. This type of collateral damage is lessened when blocking is done at a local rendezvous server that only has local impact, rather than at a global rendezvous server with global impact 🌱.

4.3.2. Granularity 🔬

Blocking at a global rendezvous service can be overbroad if the resources blocked support multiple services, since blocking one service can cause collateral damage to legitimate uses of other services 💥. For example, a given address or domain name might host both legitimate services and services that some would desire to block 🧺.

4.3.3. Efficacy 🏃‍♀️

The distributed nature of the Internet limits the efficacy of blocking based on rendezvous services 🌊. If the Internet community realizes that a blocking decision has been made and wishes to counter it, then local networks can "patch" the authoritative data that a global rendezvous service provides to avoid the blocking. (Although the development of DNSSEC and the RPKI is causing this to change by requiring updates to be authorized 🔐.) In the DNS case, registrants whose names get blocked can relocate their resources to different names 🏠.

Endpoints can also choose not to use a particular rendezvous service 🙋‍♀️. They might switch to a competitor or use an alternate mechanism (for example, IP literals in URIs to circumvent DNS filtering) 🦋.

4.3.4. Security and Other Implications ✨

Okay bestie, blocking global rendezvous services comes with a whole pile of side effects 😭 that can make the Internet less stable, less accessible, and less usable. Infrastructure-based blocking can wreck trust in the general Internet and push people toward parallel or "underground" infrastructures, which causes forms of Internet fragmentation, for example 💔. This risk gets even spicier as security stuff like DNSSEC and RPKI "hardens" the authoritative data 🔒 that existing infrastructure services hand out, and that includes blocked names or routes 🙈. People trying to get around the blocks might end up using less-secure but unblocked parallel services 💀. For the DNS side, RFC 2826 [RFC2826] goes deeper, and so does the advisory [SAC-056] from ICANN's Security and Stability Advisory Committee (SSAC), plus the Internet Society's whitepaper on DNS filtering [ISOCFiltering]. But these worries apply to other global Internet resources too 🌍.

4.3.5. Examples 🎀

Here are a few specific examples for routing, DNS, and WHOIS services 🧚. They show that these rendezvous services are often treated as a global commons, and that jurisdiction-specific legal and ethical reasons for blocking can cause collateral effects in other jurisdictions. They can also be circumvented thanks to the distributed nature of the Internet 🦋.

In 2008, Pakistan Telecom tried to block YouTube inside Pakistan by announcing bogus routes for YouTube address space to peers in Pakistan 😬. The route leak escaped the Pakistani ISP's scope, so YouTube was temporarily denied service globally 📉. Things were back up in roughly two hours, though, because network operators around the world reconfigured their routers to ignore the bogus routes [RenesysPK]. In the context of SIDR and secure routing, a similar reconfiguration could theoretically happen if a resource certificate were revoked to block routing to a given network 🔥.

In the DNS realm, one recent case of U.S. law enforcement seizing domain names involved RojaDirecta, a Spanish web site 🤯. Even though several of the affected domain names belonged to Spanish organizations, they were blocked by the U.S. government because certain servers were operated in the United States 🇺🇸.

Government officials required the operators of the parent zones of a target name (e.g., "com" for "example.com") to point queries for that name at a set of U.S.-government-operated name servers 🏛️. Users of other services, like email, under a target name would then be unable to find the servers providing services for that name, so they'd lose access to those services 📭.

Similar workarounds to the ones used in the Pakistan Telecom case are also available in the DNS case 🛠️. If a domain name is blocked by changing authoritative records, network operators can restore service by extending TTLs on cached pre-blocking records in recursive resolvers, or by statically configuring resolvers to return unblocked results for the affected name. However, depending on the availability of valid signature data, these workarounds will not work with DNSSEC-signed data 🔐.

The action of the Dutch authorities against the RIPE NCC, where RIPE was ordered to freeze the accounts of Internet resource holders, is of a similar character 🤔. By controlling the account holders' WHOIS information, this limited the ability of the ISPs in question to manage their Internet resources. This one is a little different, though, because it doesn't immediately hit the ISPs' ability to provide connectivity. ISPs use and trust the WHOIS databases to build route filters or to get troubleshooting info, but using them for those purposes is voluntary 🧐. So seizing things like this may not have any immediate effect on network connectivity, but it can still dent overall trust in the common infrastructure 💔. It's similar to the other examples because action in one jurisdiction can have broader effects, and because the global system may push networks to build their own autonomous solutions 🌱.

4.3.6. Summary 💅

In summary, rendezvous-based blocking can sometimes stop a target service right away by pulling out some of the resources it depends on 🧨. But those actions can cause harmful side effects because Internet resources are global, and lots of application-layer services rely on generic, global databases for rendezvous 😤. Internet resources can quickly shift between network locations, names, and addresses, and networks are autonomous, so the effects of rendezvous-based blocking can be negated on short order in some cases 🏃. For some applications, rendezvous services are optional to use, not mandatory 🫶. Hence, they're only effective when the endpoint or the endpoint's network chooses to use them. They can be routed around by not using the rendezvous service or by migrating to an alternative one 🦋. To adapt a quote by John Gilmore: "The Internet treats blocking as damage and routes around it" 👑.

4.4. Endpoint-Based Blocking 🌸

Internet users and their devices are constantly making decisions about whether to engage in particular Internet communications 🤔. Users decide whether to click links in suspect emails, browsers warn about sites with suspicious traits, and spam filters check whether senders and messages are legit 🕵️. If the hardware and software making these decisions can be told not to engage in certain communications, those communications are effectively blocked, because they never happen 🙅‍♀️.

Several systems today advise user systems about which communications they should engage in 📣. As discussed above, several modern browsers consult "Safe Browsing" services before loading a website to figure out whether it could be harmful 🛡️. Spam filtering is one of the oldest types of filtering on the Internet 📬. Modern filtering systems typically use one or more "reputation" or "blacklist" databases to decide whether a message or sender should be blocked 🚫. These systems typically have a property where many filtering systems (browsers, Mail Transfer Agents (MTAs)) share a single reputation service 🤝. Even the absence of provisioned PTR records for an IP address may result in email messages not being accepted 📭.

4.4.1. Scope 🎯

In an endpoint-based blocking system, blocking actions are performed autonomously, by individual endpoints or their delegates 🧍. The effects of blocking are usually local in scope, which keeps the splash small for other users and other, legitimate services 🫧.

4.4.2. Granularity 🔍

Endpoint-based blocking avoids some of the limitations of rendezvous-based blocking 💪. Rendezvous-based blocking can only see and affect the rendezvous service at hand (like DNS name resolution), but endpoint-based blocking can potentially see into the entire application, across all layers and transactions 👀. That visibility can give endpoint-based systems a much richer set of info for making narrow blocking decisions 🎯. Support for narrow granularity still depends on how the application protocol client and server are designed, though 🧩. A typical endpoint-based firewall application may have less ability to make fine-grained decisions than an application that does its own blocking (see [RFC7288] for further discussion) 📚.

4.4.3. Efficacy 🦋

Endpoint-based blocking deals well with mobile adversaries 🥷. If a blocked service relocates resources or uses different resources, a rendezvous- or network-based approach may not be able to affect the new resources (at least not immediately) 😵. A network-based blocking system may not even be able to tell whether the new resources are being used, if the previously blocked service uses secure protocols 🔒. Endpoint-based systems, by contrast, can detect when a blocked service's resources have changed (thanks to their full visibility into transactions) and adjust blocking as quickly as new blocking data can be sent out through a reputation system ⚡.

The primary challenge for endpoint-based blocking is that it requires the cooperation of endpoints 🤲. Where that cooperation is willing, it's a fairly low barrier, requiring only reconfiguration or a software update ✅. Where cooperation is unwilling, enforcing it across large numbers of endpoints can be challenging 😩. That challenge gets worse when the endpoints are a diverse set of static, mobile, or visiting endpoints 🌀. If cooperation can be achieved, though, endpoint-based blocking can be much more effective than other approaches, because it is so coherent with the Internet's architectural principles 💜.

4.4.4. Security 🔐

Endpoint-based blocking is performed at one end of an Internet communication, so it avoids the problems related to end-to-end security mechanisms that network-based blocking runs into. It also avoids the challenges to global trust infrastructures that rendezvous-based blocking creates 🙌.

4.4.5. Server Endpoints 🖥️

So far the focus has been on the consuming side of the end-to-end communication, mostly the client side of a client-server connection 👩‍💻. But similar considerations apply to the content-producing side too, whether that endpoint is a server in a client-server connection or a peer in a peer-to-peer connection 🤓.

For blocking web content, narrow targeting can be achieved through whitelisting methods like password authentication, where passwords are available only to authorized clients 🗝️. For example, a web site might only make adult content available to users who provide credit card information, which is assumed to be a proxy for age 💳.

The fact that content-producing endpoints often don't take it upon themselves to block particular forms of content in response to requests from governments or other parties can sometimes motivate those parties to block things elsewhere within the Internet 😤.

If a service is to be blocked, the best way of doing that is to disable the service at the server endpoint 🏁.

4.4.6. Summary 📝

Out of the three design patterns, endpoint-based blocking is the least likely to cause collateral damage to Internet services or to the overall Internet architecture 👑. Endpoint-based blocking systems can potentially see into all layers involved in a communication. That allows blocking to be narrowly targeted and can minimize unintended consequences 🎀. Adversary mobility can be accounted for as soon as reputation systems are updated with new adversary information ⚡. One potential drawback is that it requires the endpoint's cooperation. So implementing blocking at an endpoint when it is not in the endpoint's interest is difficult to accomplish, because the endpoint's user can disable the blocking or switch to a different endpoint 🙄💅.

5. Security Considerations 🔐✨

Okay bestie, this is the big scary one 😭. The main security worry with Internet service blocking is what it does to the end-to-end security model that a lot of Internet security protocols rely on. When blocking is enforced by an intermediary for a given communication, the blocking system may need access to confidentiality-protected data so it can make its blocking decisions. Getting that access often means the blocking system has to defeat the authentication mechanisms built into security protocols. Yikes 💀

For example, some enterprise firewalls dynamically create TLS certificates under a trust anchor that the endpoints being blocked already recognize 🙈. Those certificates let the firewall authenticate as any website, so it can act as a man-in-the-middle on TLS connections passing through it. It's giving external attacker using compromised certificates to intercept TLS connections, and that is not the vibe 🚨.

Modifications like these literally make the firewall itself an attack surface. If an attacker gains control of the firewall or compromises the key pair the firewall uses to sign certificates, they get access to the unencrypted data of all current and recorded TLS sessions for all users behind that firewall, and users can't detect it 💀. And it gets worse: if the compromised key pairs can be extracted from the firewall, every user who relies on that public key is vulnerable, not just the people behind the firewall 😩.

We also have to consider that a legitimate administrator of such a firewall could access privacy-sensitive info, like the bank accounts or health records of users who reach secure sites through the firewall 🫣. These privacy considerations are a big reason people legitimately use secure end-to-end protocols, and those protocols often make it difficult to enforce granular blocking policies 🫶.

When blocking systems can't inspect and surgically block secure protocols, it's so tempting to just block the whole protocol 😬. Like, a web blocking system that can't inspect HTTPS connections might simply block any attempted HTTPS connection. But Internet security protocols are commonly used for critical services like online commerce and banking, so blocking them would block access to those services too, or worse, force them to be conducted over insecure communication 💀.

Security protocols can, of course, also be used as mechanisms for blocking services 🧚. For example, if a blocking system can insert invalid credentials for one party in an authentication protocol, the other end will typically terminate the connection because of the authentication failure. Still, it's typically way simpler to just block secure protocols than to exploit them for service blocking 💅.

6. Conclusion 👑

Filtering is going to keep happening on the Internet, periodt 💅. Our conclusion is that, whenever possible, filtering should be done on the endpoint 💖. Cooperative endpoints are the most likely to have enough contextual knowledge to effectively target blocking, so that kind of blocking keeps unintended consequences to a minimum ✨. It's realistic to expect that at times filtering won't be done on the endpoints. In those cases, promptly informing the endpoint that blocking has occurred gives the transparency needed to redress any errors, especially as they relate to collateral damage from errant filters 🦋.

Blacklist approaches are often a total "cat and mouse" game 🐭, where the people with the content keep moving it around to dodge blocking. Or the content may even be naturally mirrored or cached at other legitimate sites, like the Internet Archive Wayback Machine [Wayback]. At the same time, whitelists carry similar risks, because sites that had "acceptable" content can become targets for "unacceptable content," and perfectly inoffensive, maybe useful or productive content gets unnecessarily blocked 🙈.

From a technical perspective, there are no perfect or even good solutions -- there is only least bad 😭. On that front, we posit that a hybrid approach combining endpoint-based filtering with network filtering may prove least damaging 🌈. An endpoint may choose to take part in a filtering regime in exchange for the network providing broader unfiltered access 🎀.

Finally, we note that where filtering is happening to address content that's generally agreed to be inappropriate or illegal, strong cooperation among service providers and governments may provide additional means to identify both the victims and the perpetrators through non-filtering mechanisms 🧐, like partnerships with the finance industry to identify and limit illegal transactions 💜.

7. Informative References 📚

Okay bestie, here's the reading list. It's long, but every single link is a whole vibe 💅

IAB Members at the Time of Approval 🧑‍💻

Here's the squad that signed off on this one, no cap 👑

  • Jari Arkko
  • Mary Barnes
  • Marc Blanchet
  • Ralph Droms
  • Ted Hardie
  • Joe Hildebrand
  • Russ Housley
  • Erik Nordmark
  • Robert Sparks
  • Andrew Sullivan
  • Dave Thaler
  • Brian Trammell
  • Suzanne Woolf

Acknowledgments 🫶

Huge thank-yous to the many reviewers who gave helpful comments, especially Bill Herrin, Eliot Lear, Patrik Faltstrom, Pekka Savola, and Russ White. NLnet Labs also gets a shoutout, since it's where Olaf Kolkman worked during most of this document's development 🌸

Authors' Addresses 💌

Meet the authors, bestie 💖

Richard Barnes

Richard Barnes
Mozilla
Suite 300
650 Castro Street
Mountain View, CA  94041
United States

Email: rlb@ipv.sx

Alissa Cooper

Alissa Cooper
Cisco
707 Tasman Drive
Milpitas, CA  95035
United States

Email: alcoop@cisco.com

Olaf Kolkman

Olaf Kolkman
Internet Society

Email: kolkman@isoc.org

Dave Thaler

Dave Thaler
Microsoft
One Microsoft Way
Redmond, WA  98052
United States

Email: dthaler@microsoft.com

Erik Nordmark

Erik Nordmark
Arista

Email: nordmark@arista.com
📦 where this page comes from