Summary

  • RFC 9505 separates censorship into prescription, identification and interference; a blocklist belongs to the first stage, while a dropped packet belongs to the third.
  • Identification and interference can occur at gateways, ISPs, services, certificate authorities, content platforms or personal devices, so control is not confined to one middlebox.
  • Encryption removes some cheap identification signals but can shift pressure to visible metadata, wholesale blocking or institutions that can still act on users and services.

The missing page is only the last frame

An error page, a reset connection and a timeout can look decisive. Each says that a communication did not complete as expected. None, by itself, says who wanted that result, which rule selected the target or which observer recognized the traffic. Congestion, equipment failure and configuration mistakes can produce similar traces. Even deliberate interference may be applied by an actor different from the one that prescribed it.

RFC 9505 supplies a useful discipline for that uncertainty. The 2023 Informational RFC, co-authored by Mallory Knodel and five colleagues, divides censorship into three elements. Prescription decides what should be suppressed. Identification classifies particular traffic or an identifier as matching that decision. Interference blocks access or impairs the connection. The words are plain, but their separation prevents a common evidentiary shortcut: treating the object in a policy database, the match made by a classifier and the effect observed by a user as one fact.

A blocklist is evidence that a prescription exists. It does not prove that the list was loaded into a working system, that a particular request matched it or that the user experienced interference. A packet trace showing repeated resets may support the interference claim. It may not reveal the list, the matching rule or the prescribing authority. The chain becomes a research object precisely because its joins can be missing.

Three questions for one apparent event

The first question is about selection. What is being prescribed: a keyword, domain, protocol, address, image hash, account category or service? Who maintains the rule, under what authority, for which jurisdiction and for how long? RFC 9505 describes blocklists, databases and heuristics as ways of turning a general demand into targets. That stage can change without a packet moving.

The second question is about visibility. What feature lets a system identify the target? At the application layer it may be a host name, URL, header or content pattern. At the transport layer it may be a port, handshake feature or protocol fingerprint. At the network layer it may be an address or route. Reassembled content can support deep inspection; a certificate or a visible server name can expose a destination without revealing the later encrypted exchange.

The third question is about action. DNS answers can be manipulated. Packets can be dropped, slowed or answered with forged resets. Routes can be withdrawn or adversarially announced. A network can be disconnected, a service overwhelmed, a server removed or a platform compelled to take content down. These acts have different scopes, costs and collateral effects even when the user's screen shows the same absence.

This is also why a binary “blocked” label can be operationally useful without being analytically complete. It can record what a test observed at one place and time. It should not silently absorb claims about motive, authority and mechanism. The honest record says which stage is evidenced and which links remain inferred.

Control does not live at one layer

RFC 9505 maps possible points of control across the system: international gateways and backbones, ISPs, institutions, content delivery networks, certificate or registry functions, application services, content sites and personal devices. The same prescription can therefore be implemented at several places, while one place can serve many different prescriptions.

That breadth defeats the comforting picture of censorship as one appliance in the path. A gateway can inspect traffic, but an application provider can remove content without touching the path. A certificate authority or registry can be pressured at a naming or trust dependency. A school or employer can install controls on a local network. Software on a personal device can suppress access before traffic reaches an ISP.

The RFC calls the tandem use of techniques “censorship in depth.” The same resource may be targeted through DNS, addresses and application signals, or several systems may run in parallel. This costs more but makes evasion of one mechanism insufficient. For measurement, the consequence is important: the disappearance of one symptom does not prove access has been restored. It may mean another layer has taken over.

Encryption changes the price, not the objective

Encryption can remove an identification surface. HTTPS hides request paths and response bodies from a passive intermediary. Protecting a handshake field can deny a censor the inexpensive domain signal it previously used. RFC 9505 treats growing use of encryption as an effective countermeasure against some techniques.

“Some” is the essential limit. If a censor cannot distinguish the target cheaply, it can accept broader blocking, target the encrypted protocol itself, rely on addresses and timing, move to a service provider, or require an endpoint to act. These responses are not guaranteed; they are the choices made visible by the RFC's control-point map. The trade-off changes from precise and cheap interference to coarser, costlier or more politically exposed action.

Overblocking is therefore not merely an implementation bug. It can be the price an actor is willing to pay when a fine-grained signal disappears. RFC 7754 adds the architectural side of this problem: blocking systems differ in scope, granularity and collateral damage, and legal or ethical judgments require context outside that technical analysis. A narrow classifier can reduce unrelated harm while increasing complexity; a broad address or protocol block can be easy to apply while denying legitimate traffic.

A survey is not a verdict

RFC 9505 is an IRTF research-group product, not an IETF standard. It is a survey of existing literature and explicitly makes no recommendation for an individual protocol. Its empirical examples document published observations available to the authors; they are not a live country dashboard. The RFC itself calls the survey a point-in-time statement and asks future work to update techniques with a comparable method.

That boundary strengthens rather than weakens the model. A taxonomy need not decide every disputed case to make evidence better. RFC 6973 shows a similar virtue in privacy analysis: identifiers, correlation and system context must be examined separately because protocol properties do not determine every deployment outcome. RFC 8890 supplies a related IAB principle—that standards work should favor end users when interests conflict—but it does not convert a measurement into proof of intent.

Knodel's contribution is best read in that narrow register. The survey gives protocol designers, implementers and investigators a map of questions. It does not authorize censorship, certify a circumvention tool or settle law. Its durable move is to place the policy decision before the classifier and the classifier before the packet effect, so that the last visible frame cannot impersonate the whole story.

Sources