<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version  -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

<rfc ipr="trust200902" docName="draft-irtf-pearg-censorship-06" category="info">

  <front>
    <title abbrev="draft-irtf-pearg-censorship">A Survey of Worldwide Censorship Techniques</title>

    <author initials="J.L." surname="Hall" fullname="Joseph Lorenzo Hall">
      <organization>Internet Society</organization>
      <address>
        <email>hall@isoc.org</email>
      </address>
    </author>
    <author initials="M.D." surname="Aaron" fullname="Michael D. Aaron">
      <organization>CU Boulder</organization>
      <address>
        <email>michael.drew.aaron@gmail.com</email>
      </address>
    </author>
    <author initials="A." surname="Andersdotter" fullname="Amelia Andersdotter">
      <organization></organization>
      <address>
        <email>amelia.ietf@andersdotter.cc</email>
      </address>
    </author>
    <author initials="B." surname="Jones" fullname="Ben Jones">
      <organization>Princeton</organization>
      <address>
        <email>bj6@cs.princeton.edu</email>
      </address>
    </author>
    <author initials="N." surname="Feamster" fullname="Nick Feamster">
      <organization>U Chicago</organization>
      <address>
        <email>feamster@uchicago.edu</email>
      </address>
    </author>
    <author initials="M." surname="Knodel" fullname="Mallory Knodel">
      <organization>Center for Democracy &amp; Technology</organization>
      <address>
        <email>mknodel@cdt.org</email>
      </address>
    </author>

    <date year="2022" month="May" day="25"/>

    <area>General</area>
    <workgroup>pearg</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>This document describes technical mechanisms employed in network censorship that regimes around
the world use for blocking or impairing Internet traffic. It aims
to make designers, implementers, and users of Internet protocols aware
of the properties exploited and mechanisms used for censoring
end-user access to information.  This document makes no suggestions on
individual protocol considerations, and is purely informational,
intended as a reference.</t>



    </abstract>


  </front>

  <middle>


<section anchor="intro" title="Introduction">

<t>Censorship is where an entity in a position of power – such as a
government, organization, or individual – suppresses communication
that it considers objectionable, harmful, sensitive, politically
incorrect or inconvenient <xref target="WP-Def-2020"/>. Although censors that engage in censorship
must do so through legal, military, or
other means, this document focuses largely on technical
mechanisms used to achieve network censorship.</t>

<t>This document describes technical mechanisms that censorship regimes
around the world use for blocking or impairing Internet traffic.  See
<xref target="RFC7754"/> for a discussion of Internet blocking and filtering in
terms of implications for Internet architecture, rather than end-user
access to content and services. There is also a growing field of
academic study of censorship circumvention (see the review article of
<xref target="Tschantz-2016"/>), results from which we seek to make relevant here
for protocol designers and implementers.</t>

<t>Censorship circumvention also impacts the cost of implementation of a censorship measure and we include mentions of tradeoffs in relation to such costs in conjunction with each technical method identified below.</t>

</section>
<section anchor="terms" title="Terminology">

<t>We describe three elements of Internet censorship: prescription,
identification, and interference. The document contains three major
sections, each corresponding to one of these elements. Prescription is
the process by which censors determine what types of material they
should censor, e.g., classifying pornographic websites as undesirable.
Identification is the process by which censors classify specific
traffic or traffic identifiers to be blocked or impaired, e.g.,
deciding that webpages containing “sex” in an HTTP Header or that
accept traffic through the URL wwww.sex.example are likely to be
undesirable.  Interference is the process by which censors intercede
in communication and prevents access to censored materials by blocking
access or impairing the connection, e.g., implementing a technical
solution capable of identifying HTTP headers or URLs and ensuring they
are rendered wholly or partially inaccessible.</t>

</section>
<section anchor="tech-prescrip" title="Technical Prescription">

<t>Prescription is the process of figuring out what censors would like to
block <xref target="Glanville-2008"/>. Generally, censors aggregate information “to
block” in blocklists or use real-time heuristic assessment of content
<xref target="Ding-1999"/>. Some national networks are designed to more naturally
serve as points of control <xref target="Leyba-2019"/>. There are also indications
that online censors use probabilistic machine learning techniques
<xref target="Tang-2016"/>. Indeed, web crawling and machine learning techniques
are an active research idea in the effort to identify content deemed
as morally or commercially harmful to companies or consumers in some
jurisdictions <xref target="SIDN2020"/>.</t>

<t>There are typically a few types of blocklist elements: Keyword, domain
name, protocol, or Internet Protocol (IP) address. Keyword and domain name
blocking take place at the application level, e.g., HTTP; protocol blocking
often occurs using Deep Packet Inspection to identify a forbidden protocol;
IP blocking tends to take place using IP addresses in IPv4/IPv6 headers.
Some censors also use the presence of certain keywords to enable more
aggressive blocklists <xref target="Rambert-2021"/> or to be more permissive with
content <xref target="Knockel-2021"/>.</t>

<t>The mechanisms for building up these blocklists vary. Censors can purchase
from private industry “content control” software, such as SmartFilter,
which lets censors filter traffic from broad categories they would like to
block, such as gambling or pornography <xref target="Knight-2005"/>. In these cases,
these private services attempt to categorize every semi-questionable
website as to allow for meta-tag blocking. Similarly, they tune real-time
content heuristic systems to map their assessments onto categories of
objectionable content.</t>

<t>Countries that are more interested in retaining specific political control
typically have ministries or organizations that maintain blocklists. Examples
include the Ministry of Industry and Information Technology in China, Ministry of
Culture and Islamic Guidance in Iran, and specific to copyright in France <xref target="HADOPI-2020"/>
and across the EU for consumer protection law <xref target="Reda-2017"/>.</t>

</section>
<section anchor="tech-id" title="Technical Identification">

<section anchor="poc" title="Points of Control">

<t>Internet censorship takes place in all parts of the network
topology. It may be implemented in the network itself (e.g. local loop
or backhaul), on the services side of communication (e.g. web hosts,
cloud providers or content delivery networks), in the ancillary
services eco-system (e.g. domain name system or certificate
authorities) or on the end-client side (e.g. in an end-user device
such as a smartphone, laptop or desktop or software executed on such
devices).  An important aspect of pervasive technical interception is
the necessity to rely on software or hardware to intercept the content
the censor is interested in. There are various logical and physical
points-of-control censors may use for interception mechanisms,
including, though not limited to, the following.</t>

<t><list style="symbols">
  <t>Internet Backbone: If a censor controls the gateways into a region,
they can filter undesirable traffic that is traveling into and out
of the region by packet sniffing and port mirroring at the relevant
exchange points. Censorship at this point of control is most
effective at controlling the flow of information between a region
and the rest of the Internet, but is ineffective at identifying
content traveling between the users within a region. Some national
network designs naturally serve as more effective chokepoints and
points of control <xref target="Leyba-2019"/>.</t>
  <t>Internet Service Providers: Internet Service Providers are
frequently exploited points of control. They
have the benefit of being easily enumerable by a censor – often
falling under the jurisdictional or operational control of a censor
in an indisputable way – with the additional feature that an ISP
can identify the regional and international traffic
of all their users. The censor’s filtration mechanisms can be placed
on an ISP via governmental mandates, ownership, or voluntary/coercive influence.</t>
  <t>Institutions: Private institutions such as corporations,
schools, and Internet cafes can use filtration mechanisms.
These mechanisms are occasionally at the request of a
government censor, but can also be implemented to help achieve
institutional goals, such as fostering a particular moral outlook on
life by school-children, independent of broader society or
government goals.</t>
  <t>Content Distribution Networks (CDNs): CDNs seek to collapse network
topology in order to better locate content closer to the service’s
users. This reduces content transmission latency and improves quality
of service. The CDN service’s content
servers, located “close” to the user in a network-sense, can be
powerful points of control for censors, especially if the location
of CDN content repositories allow for easier interference.</t>
  <t>Certificate Authorities (CAs) for Public-Key Infrastructures (PKIs):
Authorities that issue cryptographically secured resources can be a
significant point of control. CAs that issue certificates to domain
holders for TLS/HTTPS (the Web PKI) or Regional/Local Internet
Registries (RIRs) that issue Route Origination Authorizations (ROAs)
to BGP operators can be forced to issue rogue certificates that may
allow compromise, i.e., by allowing censorship software to engage in
identification and interference where not possible before. CAs may
also be forced to revoke certificates. This may lead to adversarial
traffic routing or TLS interception being allowed, or an otherwise
rightful origin or destination point of traffic flows being unable
to communicate in a secure way.</t>
  <t>Services: Application service providers can be pressured,
coerced, or legally required to censor specific content or data flows.
Service providers naturally face incentives to maximize their
potential customer base and potential service shutdowns or legal
liability due to censorship efforts may seem much less attractive
than potentially excluding content, users, or uses of their
service. Services have increasingly become focal points of
censorship discussions, as well as the focus of discussions of moral
imperatives to use censorship tools.</t>
  <t>Content sites: On the service side of communications lie many platforms that
publish user-generated content require terms of service compliance with all content
and user accounts in order to avoid intermediary liability for the web hosts.
In aggregate these policies, actions and remedies are known as content moderation.
Content moderation happens above the services or application layer, but
these mechanisms are built to filter, sort and block content and users
thus making them available to censors through direct pressure on the private entity.</t>
  <t>Personal Devices: Censors can mandate censorship software be
installed on the device level. This has many disadvantages in terms
of scalability, ease-of-circumvention, and operating system
requirements. (Of course, if a personal device is treated with
censorship software before sale and this software is difficult to
reconfigure, this may work in favor of those seeking to control
information, say for children, students, customers, or employees.)
The emergence of mobile devices exacerbate these feasibility
problems. This software can also be mandated by institutional actors
acting on non-governmentally mandated moral imperatives.</t>
</list></t>

<t>At all levels of the network hierarchy, the filtration mechanisms used
to censor undesirable traffic are essentially the same: a censor
either directly identifies undesirable content using the identifiers
described below and then uses a blocking or shaping mechanism such as
the ones exemplified below to prevent or impair access, or requests
that an actor ancillary to the censor, such as a private entity,
perform these functions.  Identification of undesirable traffic can
occur at the application, transport, or network layer of the IP
stack. Censors often focus on web traffic, so the relevant protocols
tend to be filtered in predictable ways (see <xref target="http-req"/> and
<xref target="http-resp"/>). For example, a subversive image might make it past a
keyword filter. However, if later the image is deemed undesirable, a
censor may then blacklist the provider site’s IP address.</t>

</section>
<section anchor="app-layer" title="Application Layer">

<t>The following subsections describe properties and tradeoffs of common
ways in which censors filter using application-layer information. Each
subsection includes empirical examples describing these common
behaviors for further reference.</t>

<section anchor="http-req" title="HTTP Request Header Identification">

<t>An HTTP header contains a lot of useful information for traffic
identification. Although “host” is the only required field in an HTTP
request header (for HTTP/1.1 and later), an HTTP method field is necessary
to do anything
useful. As such, “method” and “host” are the two fields used
most often for ubiquitous censorship. A censor can sniff traffic and
identify a specific domain name (host) and usually a page name (GET
/page) as well. This identification technique is usually paired with
transport header identification (see <xref target="sec_thid"/>) for a more robust
method.</t>

<t>Tradeoffs: Request Identification is a technically straight-forward
identification method that can be easily implemented at the Backbone
or ISP level. The hardware needed for this sort of identification is
cheap and easy-to-acquire, making it desirable when budget and scope
are a concern. HTTPS will encrypt the relevant request and response
fields, so pairing with transport identification (see <xref target="sec_thid"/>) is
necessary for HTTPS filtering. However, some countermeasures can
trivially defeat simple forms of HTTP Request Header Identification.
For example, two cooperating endpoints – an instrumented web server
and client – could encrypt or otherwise obfuscate the “host” header in
a request, potentially thwarting techniques that match against “host” header values.</t>

<t>Empirical Examples: Studies exploring censorship mechanisms have found
evidence of HTTP header/ URL filtering in many countries, including
Bangladesh, Bahrain, China, India, Iran, Malaysia, Pakistan, Russia,
Saudi Arabia, South Korea, Thailand, and Turkey
<xref target="Verkamp-2012"/> <xref target="Nabi-2013"/> <xref target="Aryan-2012"/>. Commercial technologies
such as the McAfee SmartFilter and NetSweeper are often purchased by
censors <xref target="Dalek-2013"/>.  These commercial technologies use a
combination of HTTP Request Identification and Transport Header
Identification to filter specific URLs. Dalek et al. and Jones et
al. identified the use of these products in the wild
<xref target="Dalek-2013"/> <xref target="Jones-2014"/>.</t>

</section>
<section anchor="http-resp" title="HTTP Response Header Identification">

<t>While HTTP Request Header Identification relies on the information
contained in the HTTP request from client to server, response
identification uses information sent in response by the server to
client to identify undesirable content.</t>

<t>Tradeoffs: As with HTTP Request Header Identification, the techniques
used to identify HTTP traffic are well-known, cheap, and relatively
easy to implement. However, they are made useless by HTTPS because
HTTPS encrypts the response and its headers.</t>

<t>The response fields are also less helpful for identifying content than
request fields, as “Server” could easily be identified using HTTP
Request Header identification, and “Via” is rarely relevant.  HTTP
Response censorship mechanisms normally let the first n packets
through while the mirrored traffic is being processed; this may allow
some content through and the user may be able to detect that the
censor is actively interfering with undesirable content.</t>

<t>Empirical Examples: In 2009, Jong Park et al. at the University of New
Mexico demonstrated that the Great Firewall of China (GFW) has used this
technique <xref target="Crandall-2010"/>. However, Jong Park et al. found that the
GFW discontinued this practice during the course of the study. Due to
the overlap in HTTP response filtering and keyword filtering (see
<xref target="kw-filt"></xref>), it is likely that most censors rely on keyword
filtering over TCP streams instead of HTTP response filtering.</t>

</section>
<section anchor="tls" title="Transport Layer Security (TLS)">

<t>Similar to HTTP, censors have deployed a variety of techniques towards
censoring Transport Layer Security (TLS) (and by extension HTTPS). Most of
these techniques relate to the Server Name Indication (SNI) field,
including censoring SNI, Encrypted SNI, or omitted SNI. Censors can also
censor HTTPS content via server certificates. 
Note that TLS 1.3 acts as a security component of QUIC.</t>

<section anchor="sni" title="Server Name Indication (SNI)">

<t>In encrypted connections using TLS, there
may be servers that host multiple “virtual servers” at a given network
address, and the client will need to specify in the
Client Hello message which domain name it seeks to connect to (so that
the server can respond with the appropriate TLS certificate) using the
Server Name Indication (SNI) TLS extension <xref target="RFC6066"/>. 
The Client Hello message is unencrypted for TCP-based TLS. 
When using QUIC, the Client Hello message is encrypted but its 
confidentiality is not effectively protected because the initial encryption 
keys are derived using a value that is visible on the wire. Since SNI is
often sent in the clear (as are the cert fields sent in response),
censors and filtering software can use it (and response cert fields)
as a basis for blocking, filtering, or impairment by dropping
connections to domains that match prohibited content (e.g.,
bad.foo.example may be censored while good.foo.example is not)
<xref target="Shbair-2015"/>. There are undergoing standardization efforts in the
TLS Working Group to encrypt SNI <xref target="I-D.ietf-tls-sni-encryption"/>
<xref target="I-D.ietf-tls-esni"/> and recent research shows promising results in
the use of encrypted SNI in the face of SNI-based filtering
<xref target="Chai-2019"/> in some countries.</t>

<t>Domain fronting has been one popular way to avoid identification by
censors <xref target="Fifield-2015"/>. To avoid identification by censors,
applications using domain fronting put a different domain name in the
SNI extension than in the Host: header, which is protected by
HTTPS. The visible SNI would indicate an unblocked domain, while the
blocked domain remains hidden in the encrypted application header.
Some encrypted messaging services relied on domain fronting to enable
their provision in countries employing SNI-based filtering. These
services used the cover provided by domains for which blocking at the
domain level would be undesirable to hide their true domain
names. However, the companies holding the most popular domains have
since reconfigured their software to prevent this practice.  It may be
possible to achieve similar results using potential future options to
encrypt SNI.</t>

<t>Tradeoffs: Some clients do not send the SNI extension (e.g., clients
that only support versions of SSL and not TLS), rendering this method
ineffective (see <xref target="omitsni"/>). In addition, this technique requires deep packet
inspection techniques that can be computationally and
infrastructurally expensive, especially when applied to QUIC where deep packet inspection requires key extraction and decryption of the Client Hello in order to read the SNI. Improper configuration of an SNI-based
block can result in significant overblocking, e.g., when a
second-level domain like populardomain.example is inadvertently
blocked. In the case of encrypted SNI, pressure to censor may
transfer to other points of intervention, such as content and application providers.</t>

<t>Empirical Examples: There are many examples of security firms that
offer SNI-based filtering products <xref target="Trustwave-2015"/> <xref target="Sophos-2015"/>
<xref target="Shbair-2015"/>, and the governments of China, Egypt, Iran, Qatar,
South Korea, Turkey, Turkmenistan, and the UAE all do widespread SNI
filtering or blocking <xref target="OONI-2018"/> <xref target="OONI-2019"/> <xref target="NA-SK-2019"/>
<xref target="CitizenLab-2018"/> <xref target="Gatlan-2019"/> <xref target="Chai-2019"/> <xref target="Grover-2019"/>
<xref target="Singh-2019"/>. SNI blocking against QUIC traffic has been first observed in Russia in March 2022 <xref target="Elmenhorst-2022"/>.</t>

</section>
<section anchor="esni" title="Encrypted SNI (ESNI)">

<t>With the data leakage present with the SNI field, a natural response is to 
encrypt it, which is forthcoming in TLS 1.3 with Encrypted Client Hello
(ECH).  Prior to ECH, the Encrypted SNI (ESNI) extension is available to
prevent the data leakage caused by SNI, which encrypts only the SNI field.
Unfortunately, censors can target connections that use the ESNI extension
specifically for censorship. This guarantees overblocking for the censor,
but can be worth the cost if ESNI is not yet widely deployed within the
country.  Encrypted Client Hello (ECH) is the emerging standard for protecting
the entire TLS Client Hello, but it is not yet widely deployed.</t>

<t>Tradeoffs: The cost to censoring Encrypted SNI (ESNI) is significantly
higher than SNI to a censor, as the censor can no longer target
censorship to specific domains and guarantees over-blocking. In these
cases, the censor uses the over-blocking to discourage the use of
ESNI entirely.</t>

<t>Empirical Examples: In 2020, China began censoring all uses of Encrypted
ESNI (ESNI) <xref target="Bock-2020b"/>, even for innocuous connections. The
censorship mechanism for China’s ESNI censorship differs from how
China censors SNI-based connections, suggesting that new middleboxes
were deployed specifically to target ESNI connections.</t>

</section>
<section anchor="omitsni" title="Omitted-SNI">

<t>Researchers have observed that some clients omit the SNI extension
entirely. This omitted-SNI approach limits the information available
to a censor. Like with ESNI, censors can choose to block connections that
omit the SNI, though this too risks over-blocking.</t>

<t>Tradeoffs: The approach of censoring all connections that omit the SNI field
is guaranteed to over-block, though connections that omit the SNI field
should be relatively rare in the wild.</t>

<t>Empirical Examples: In the past, researchers have observed censors in Russia
blocking connections that omit the SNI field <xref target="Bock-2020b"/>.</t>

</section>
<section anchor="server-response-certificate" title="Server Response Certificate">

<t>During the TLS handshake after the TLS Client Hello, the server will respond
with the TLS certificate. This certificate also contains the domain
the client is trying to access, creating another avenue that censors
can use to perform censorship. This technique will not work in TLS 1.3, as the 
certificate will be encrypted.</t>

<t>Tradeoffs: Censoring based on the server certificate requires deep
packet inspection techniques that can be more computationally
expensive compared to other methods. Additionally, the certificate is
sent later in the TLS Handshake compared to the SNI field, forcing
the censor to track the connection for longer.</t>

<t>Empirical Examples: Researchers have observed the Reliance Jio
ISP in India using certificate response fields to censor connections
<xref target="Satija-2021"/>.</t>

</section>
</section>
<section anchor="kw-filt" title="Instrumenting Content Distributors">

<t>Many governments pressure content providers to censor themselves, or
provide the legal framework within which content distributors are
incentivized to follow the content restriction preferences of agents
external to the content distributor <xref target="Boyle-1997"/>. Due to the
extensive reach of such censorship, we define content
distributor as any service that provides utility to users, including
everything from web sites to locally installed programs. A commonly
used method of instrumenting content distributors consists of keyword
identification to detect restricted terms on their platform. Governments
may provide the terms on such keyword lists. Alternatively, the content
provider may be expected to come up with their own list. A different
method of instrumenting content distributors consists of requiring a
distributor to disassociate with some categories of users. See also
<xref target="notice"/>.</t>

<t>Tradeoffs: By instrumenting content distributors to identify
restricted content or content providers, the censor can gain new
information at the cost of political capital with the companies it
forces or encourages to participate in censorship. For example, the
censor can gain insight about the content of encrypted traffic by
coercing web sites to identify restricted content. Coercing content
distributors to regulate users, categories of users, content and
content providers may encourage users and content providers to exhibit
self-censorship, an additional advantage for censors (see <xref target="selfcensor"/>). The tradeoffs
for instrumenting content distributors are highly dependent on the
content provider and the requested assistance. A typical concern is
that the targeted keywords or categories of users are too broad, risk
being too broadly applied, or are not subjected to a sufficiently
robust legal process prior to their mandatory application (see p. 8 of
<xref target="EC-2012"/>).</t>

<t>Empirical Examples: Researchers discovered keyword identification
by content providers on platforms ranging from instant messaging
applications <xref target="Senft-2013"/> to search engines <xref target="Rushe-2015"/>
<xref target="Cheng-2010"/> <xref target="Whittaker-2013"/> <xref target="BBC-2013"/> <xref target="Condliffe-2013"/>. To
demonstrate the prevalence of this type of keyword identification, we
look to search engine censorship.</t>

<t>Search engine censorship demonstrates keyword identification by
content providers and can be regional or worldwide.  Implementation is
occasionally voluntary, but normally it is based on laws and regulations
of the country a search engine is operating in. The keyword blocklists
are most likely maintained by the search engine provider. China is
known to require search engine providers to “voluntarily” maintain
search term blocklists to acquire and keep an Internet content provider
(ICP) license <xref target="Cheng-2010"/>.  It is clear these blocklists are
maintained by each search engine provider based on the slight
variations in the intercepted searches <xref target="Zhu-2011"/>
<xref target="Whittaker-2013"/>. The United Kingdom has been pushing search engines
to self-censor with the threat of litigation if they do not do it
themselves: Google and Microsoft have agreed to block more than
100,000 queries in U.K. to help combat abuse <xref target="BBC-2013"/>
<xref target="Condliffe-2013"/>.  European Union law, as well as US law, requires
modification of search engine results in response to either copyright,
trademark, data protection or defamation concerns <xref target="EC-2012"/>.</t>

<t>Depending on the output, search engine keyword identification may be
difficult or easy to detect. In some cases specialized or blank
results provide a trivial enumeration mechanism, but more subtle
censorship can be difficult to detect. In February 2015, Microsoft’s search
engine, Bing, was accused of censoring Chinese content outside of
China <xref target="Rushe-2015"/> because Bing returned different results for
censored terms in Chinese and English. However, it is possible that
censorship of the largest base of Chinese search users, China, biased
Bing’s results so that the more popular results in China (the
uncensored results) were also more popular for Chinese speakers
outside of China.</t>

<t>Disassociation by content distributors from certain categories of
users has happened for instance in Spain, as a result of the conflict
between the Catalunyan independence movement and the Spanish legal
presumption of a unitary state <xref target="Lomas-2019"/>. E-sport event
organizers have also disassociated themselves from top players who
expressed political opinions in relation to the 2019 Hong Kong
protests <xref target="Victor-2019"/>. See also <xref target="discon"/>.</t>

</section>
<section anchor="dpi" title="Deep Packet Inspection (DPI) Identification">

<t>DPI (deep packet inspection) technically is any kind of packet
analysis beyond IP address and port number and has become
computationally feasible as a component of censorship mechanisms
in recent years <xref target="Wagner-2009"/>. Unlike other
techniques, DPI reassembles network flows to examine the application
“data” section, as opposed to only headers, and is therefore often
used for keyword identification. DPI also differs from other
identification technologies because it can leverage additional packet
and flow characteristics, e.g., packet sizes and timings, when identifying
content. To prevent substantial quality of service (QoS) impacts, DPI
normally analyzes a copy of data while the original packets continue
to be routed. Typically, the traffic is split using either a mirror
switch or fiber splitter, and analyzed on a cluster of machines
running Intrusion Detection Systems (IDS) configured for censorship.</t>

<t>Tradeoffs: DPI is one of the most expensive identification mechanisms
and can have a large QoS impact <xref target="Porter-2010"/>.  When used as a
keyword filter for TCP flows, DPI systems can cause also major
overblocking problems. Like other techniques, DPI is less useful
against encrypted data, though DPI can leverage unencrypted elements
of an encrypted data flow, e.g., the Server Name Indication (SNI) sent
in the clear for TLS, or metadata about an encrypted flow, e.g., packet
sizes, which differ across video and textual flows, to identify traffic.
See <xref target="sni"/> for more information about SNI-based filtration mechanisms.</t>

<t>Other kinds of information can be inferred by comparing certain unencrypted elements
exchanged during TLS handshakes to similar data points from known sources.
This practice, called TLS fingerprinting, allows a probabilistic identification of
a party’s operating system, browser, or application based on a comparison of the
specific combinations of TLS version, ciphersuites, compression options, etc.
sent in the ClientHello message to similar signatures found in unencrypted traffic <xref target="Husak-2016"/>.</t>

<t>Despite these problems, DPI is the most powerful identification method
and is widely used in practice. The Great Firewall of China (GFW), the
largest censorship system in the world, uses DPI to identify
restricted content over HTTP and DNS and inject TCP RSTs and bad DNS
responses, respectively, into connections <xref target="Crandall-2010"/> <xref target="Clayton-2006"/> <xref target="Anonymous-2014"/>.</t>

<t>Empirical Examples: Several studies have found evidence of censors
using DPI for censoring content and tools. Clayton et al., Crandal et al.,
Anonymous, and Khattak et al., all explored the GFW <xref target="Crandall-2010"/>
<xref target="Clayton-2006"/> <xref target="Anonymous-2014"/>. Khattak et al. even probed the
firewall to discover implementation details like how much state it stores <xref target="Khattak-2013"/>.
The Tor project claims that China, Iran, Ethiopia, and others must have used
DPI to block the obfs2 protocol <xref target="Wilde-2012"/>.  Malaysia has
been accused of using targeted DPI, paired with DDoS, to identify and
subsequently attack pro-opposition material <xref target="Wagstaff-2013"/>.  It
also seems likely that organizations not so worried about blocking
content in real-time could use DPI to sort and categorically search
gathered traffic using technologies such as NarusInsight
<xref target="Hepting-2011"/>.</t>

</section>
</section>
<section anchor="transport" title="Transport Layer">

<section anchor="sec_thid" title="Shallow Packet Inspection and Transport Header Identification">

<t>Of the various shallow packet inspection methods, Transport Header
Identification is the most pervasive, reliable, and predictable type
of identification.  Transport headers contain a few invaluable pieces
of information that must be transparent for traffic to be successfully
routed: destination and source IP address and port.  Destination and
Source IP are doubly useful, as not only does it allow a censor to
block undesirable content via IP blocklisting, but also allows a
censor to identify the IP of the user making the request and the IP
address of the destination being visited, which in most cases can be
used to infer the domain being visited <xref target="Patil-2019"/>. Port is useful
for allowlisting certain applications.</t>

<t>Combining IP address, port and protocol information found in the transport header, shallow packet inspection can be used by a censor to identify specific TCP or UDP endpoints. UDP endpoint blocking has been observed in the context of QUIC blocking <xref target="Elmenhorst-2021"/>.</t>

<t>Trade-offs: header identification is popular due to its simplicity,
availability, and robustness.</t>

<t>Header identification is trivial to implement, but is difficult to
implement in backbone or ISP routers at scale, and is therefore
typically implemented with DPI. Blocklisting an IP is equivalent to
installing a specific route on a router (such as a /32 route for IPv4
addresses and a /128 route for IPv6 addresses). However, due to
limited flow table space, this cannot scale beyond a few thousand IPs
at most. IP blocking is also relatively crude. It often leads to
overblocking and cannot deal with some services like Content
Distribution Networks (CDN) that host content at hundreds or thousands
of IP addresses. Despite these limitations, IP blocking is extremely
effective because the user needs to proxy their traffic through
another destination to circumvent this type of identification. 
In addition, IP blocking is effective against all protocols above IP, e.g. 
TCP and QUIC.</t>

<t>Port-blocking is generally not useful because many types of content
share the same port and it is possible for censored applications to
change their port. For example, most HTTP traffic goes over port 80,
so the censor cannot differentiate between restricted and allowed web
content solely on the basis of port. HTTPS goes over port 443, with
similar consequences for the censor except only partial metadata may
now be available to the censor. Port allowlisting is occasionally
used, where a censor limits communication to approved ports, such as
80 for HTTP traffic and is most effective when used in conjunction
with other identification mechanisms. For example, a censor could
block the default HTTPS port, port 443, thereby forcing most users to
fall back to HTTP. A counter-example is that port 25 (SMTP) has long
been blocked on residential ISPs’ networks to reduce the risk for
email spam, but in doing so also prohibits residential ISP customers
from running their own email servers.</t>

</section>
<section anchor="prot-id" title="Protocol Identification">

<t>Censors sometimes identify entire protocols to be blocked using a
variety of traffic characteristics.  For example, Iran impairs the
performance of HTTPS traffic, a protocol that prevents further
analysis, to encourage users to switch to HTTP, a protocol that they
can analyze <xref target="Aryan-2012"/>. A simple protocol identification
would be to recognize all TCP traffic over port 443 as HTTPS, but more
sophisticated analysis of the statistical properties of payload data
and flow behavior, would be more effective, even when port 443 is not
used <xref target="Hjelmvik-2010"/> <xref target="Sandvine-2014"/>.</t>

<t>If censors can detect circumvention tools, they can block them, so
censors like China are extremely interested in identifying the
protocols for censorship circumvention tools. In recent years, this
has devolved into an arms race between censors and circumvention tool
developers. As part of this arms race, China developed an extremely
effective protocol identification technique that researchers call
active probing or active scanning.</t>

<t>In active probing, the censor determines whether hosts are running a
circumvention protocol by trying to initiate communication using the
circumvention protocol. If the host and the censor successfully
negotiate a connection, then the censor conclusively knows that host
is running a circumvention tool. China has used active scanning to
great effect to block Tor <xref target="Winter-2012"/>.</t>

<t>Trade-offs: Protocol identification necessarily only provides insight
into the way information is traveling, and not the information itself.</t>

<t>Protocol identification is useful for detecting and blocking
circumvention tools, like Tor, or traffic that is difficult to
analyze, like VoIP or SSL, because the censor can assume that this
traffic should be blocked. However, this can lead to over-blocking
problems when used with popular protocols.  These methods are
expensive, both computationally and financially, due to the use of
statistical analysis, and can be ineffective due to their imprecise
nature.</t>

<t>Censors have also used protocol identification in the past in an
‘allowlist’ filtering capacity, such as by only allowing specific,
pre-vetted protocols to be used and blocking any unrecognized
protocols <xref target="Bock-2020"/>. These protocol filtering approaches can also lead to
over-blocking if the allowed lists of protocols is too small or
incomplete, but can be cheap to implement, as many standard ‘allowed’ 
protocols are simple to identify (such as HTTP).</t>

<t>Empirical Examples: Protocol identification can be easy to detect if
it is conducted in real time and only a particular protocol is
blocked, but some types of protocol identification, like active
scanning, are much more difficult to detect. Protocol identification
has been used by Iran to identify and throttle SSH traffic to make it
unusable <xref target="Anonymous-2007"/> and by China to identify and block Tor
relays <xref target="Winter-2012"/>. Protocol identification has also been used for
traffic management, such as the 2007 case where Comcast in the United
States used RST injection to interrupt BitTorrent Traffic
<xref target="Winter-2012"/>. In 2020, Iran deployed an allowlist protocol filter,
which only allowed three protocols to be used (DNS, TLS, and HTTP) on
specific ports and censored any connection it could not identify <xref target="Bock-2020"/>. 
In 2022, Russia seemed to have used protocol identification to block most
HTTP/3 connections <xref target="Elmenhorst-2022"/>.</t>

</section>
</section>
<section anchor="residualcensorship" title="Residual Censorship">

<t>Another feature of some modern censorship systems is residual censorship, a
punitive form of censorship whereby after a censor disrupts a forbidden
connection, the censor continues to target subsequent connections, even if they
are innocuous <xref target="Bock-2021"/>. Residual censorship can take many forms
and often relies on the methods of technical interference described in the next
section.</t>

<t>An important facet of residual censorship is precisely what the censor
continues to block after censorship is initially triggered. There are three
common options available to an adversary: 2-tuple (client IP, server IP),
3-tuple (client IP, server IP+port), or 4-tuple (client IP+port, server
IP+port). Future connections that match the tuple of information the censor
records will be disrupted <xref target="Bock-2021"/>.</t>

<t>Residual censorship can sometimes be difficult to identify and can often complicate
censorship measurement.</t>

<t>Trade-offs: The impact of residual censorship is to provide users with further
discouragement from trying to access forbidden content, though it is not
clear how successful it is at accomplishing this.</t>

<t>Empirical Examples: China has used 3-tuple residual censorship in conjunction
with their HTTP censorship for years and researchers have reported seeing similar
residual censorship for HTTPS. China seems to use a mix of 3-tuple and 4-tuple
residual censorship for their censorship of HTTPS with ESNI. Some censors that
perform censorship via packet dropping often accidentally implement 4-tuple
residual censorship, including Iran and Kazakhstan <xref target="Bock-2021"/>.</t>

</section>
</section>
<section anchor="tech-interference" title="Technical Interference">

<section anchor="application-layer" title="Application Layer">

<section anchor="dns-mangling" title="DNS Interference">

<t>There are a variety of mechanisms that censors can use to block or
filter access to content by altering responses from the DNS
<xref target="AFNIC-2013"/> <xref target="ICANN-SSAC-2012"/>, including blocking the response,
replying with an error message, or responding with an incorrect
address. Note that there are now encrypted transports for DNS queries
in DNS-over-HTTPS <xref target="RFC8484"/> and DNS-over-TLS <xref target="RFC7858"/> that can
mitigate interference with DNS queries between the stub and the
resolver.</t>

<t>Responding to a DNS query with an incorrect address can be achieved
with on-path interception, off-path cache poisoning, and lying by
the nameserver.</t>

<t>“DNS mangling” is a network-level technique of on-path interception where an incorrect IP
address is returned in response to a DNS query to a censored
destination. An example of this is what some Chinese networks do (we
are not aware of any other wide-scale uses of mangling). On those
Chinese networks, every DNS request in transit is examined (presumably
by network inspection technologies such as DPI) and, if it matches a
censored domain, a false response is injected. End users can see this
technique in action by simply sending DNS requests to any unused IP
address in China (see example below). If it is not a censored name,
there will be no response. If it is censored, a forged response
will be returned. For example, using the command-line dig utility to
query an unused IP address in China of 192.0.2.2 for the name
“www.uncensored.example”  compared with
“www.censored.example” (censored at the time of writing), we get a
forged IP address “198.51.100.0” as a response:</t>

<figure><artwork><![CDATA[
% dig +short +nodnssec @192.0.2.2 A www.uncensored.example
;; connection timed out; no servers could be reached

% dig +short +nodnssec @192.0.2.2 A www.censored.example
198.51.100.0
]]></artwork></figure>

<t>DNS cache poisoning happens off-path and refers to a mechanism where a censor interferes
with the response sent by an authoritative DNS name server to a recursive
resolver by responding more quickly than the authoritative name server
can respond with an alternative IP address <xref target="Halley-2008"/>.
Cache poisoning occurs
after the requested site’s name servers resolve the request and
attempt to forward the true IP back to the requesting device; on the
return route the resolved IP is recursively cached by each DNS server
that initially forwarded the request. During this caching process if
an undesirable keyword is recognized, the resolved IP is “poisoned”
and an alternative IP (or NXDOMAIN error) is returned more quickly
than the upstream resolver can respond, causing a forged IP
address to be cached (and potentially recursively so). The alternative
IPs usually direct to a nonsense domain or a warning page.
Alternatively, Iranian censorship appears to prevent the communication
en-route, preventing a response from ever being sent <xref target="Aryan-2012"/>.</t>

<t>There are also cases of what is colloquially called “DNS lying”, where
a censor mandates that the DNS responses provided – by an operator of
a recursive resolver such as an Internet access provider – be
different than what authoritative name server would provide
<xref target="Bortzmeyer-2015"/>.</t>

<t>Trade-offs: These forms of DNS interference require the censor to
force a user to traverse a controlled DNS hierarchy (or intervening
network on which the censor serves as a Active Pervasive Attacker
<xref target="RFC7624"/> to rewrite DNS responses) for the mechanism to be
effective. It can be circumvented by using alternative DNS resolvers
(such as any of the public DNS resolvers) that may fall outside of the
jurisdictional control of the censor, or Virtual Private Network (VPN)
technology. DNS mangling and cache poisoning also imply returning an
incorrect IP to those attempting to resolve a domain name, but in some
cases the destination may be technically accessible; over HTTP, for
example, the user may have another method of obtaining the IP address
of the desired site and may be able to access it if the site is
configured to be the default server listening at this IP address.
Target blocking has also been a problem, as occasionally users outside
of the censors region will be directed through DNS servers or
DNS-rewriting network equipment controlled by a censor, causing the
request to fail. The ease of circumvention paired with the large risk
of content blocking and target blocking make DNS interference a
partial, difficult, and less than ideal censorship
mechanism.</t>

<t>Additionally, the above mechanisms rely on DNSSEC not being deployed
or DNSSEC validation not being active on the client or recursive
resolver (neither of which are hard to imagine given limited
deployment of DNSSEC and limited client support for DNSSEC
validation). Note that an adversary seeking to merely block resolution
can serve a DNSSEC record that doesn’t validate correctly, assuming of
course that the client/recursive resolver validates.</t>

<t>Previously, techniques were used for e.g. censorship that relied on
DNS requests being passed in cleartext over port 53
<xref target="SSAC-109-2020"/>. With the deployment of encrypted DNS (e.g.,
DNS-over-HTTPS <xref target="RFC8484"/>) these requests are now increasingly passed
on port 443 with other HTTPS traffic, or in the case of DNS-over-TLS
<xref target="RFC7858"/> no longer passed in the clear (see also <xref target="sec_thid"/>).</t>

<t>Empirical Examples: DNS interference, when properly implemented, is
easy to identify based on the shortcomings identified above. Turkey
relied on DNS interference for its country-wide block of websites such
Twitter and YouTube for almost week in March of 2014 but the ease of
circumvention resulted in an increase in the popularity of Twitter
until Turkish ISPs implementing an IP blocklist to achieve the
governmental mandate <xref target="Zmijewski-2014"/>.  Ultimately, Turkish ISPs
started hijacking all requests to Google and Level 3’s international
DNS resolvers <xref target="Zmijewski-2014"/>. DNS interference, when incorrectly
implemented, has resulted in some of the largest “censorship
disasters”.  In January 2014, China started directing all requests
passing through the Great Fire Wall to a single domain,
dongtaiwang.com, due to an improperly configured DNS poisoning
attempt; this incident is thought to be the largest Internet-service
outage in history <xref target="AFP-2014"/> <xref target="Anon-SIGCOMM12"/>. Countries such as
China, Iran, Turkey, and the United States have discussed blocking
entire TLDs as well, but only Iran has acted by blocking all Israeli
(.il) domains <xref target="Albert-2011"/>. DNS-blocking is commonly deployed in
European countries to deal with undesirable content, such as child
abuse content (Norway, United Kingdom, Belgium, Denmark, Finland,
France, Germany, Ireland, Italy, Malta, the Netherlands, Poland, Spain
and Sweden <xref target="Wright-2013"/> <xref target="Eneman-2010"/>), online gambling (Belgium,
Bulgaria, Czech Republic, Cyprus, Denmark, Estonia, France, Greece,
Hungary, Italy, Latvia, Lithuania, Poland, Portugal, Romania,
Slovakia, Slovenia, Spain (see Section 6.3.2 of: <xref target="EC-gambling-2012"/>,
<xref target="EC-gambling-2019"/>)), copyright infringement (all European Economic Area countries),
hate-speech and extremism (France <xref target="Hertel-2015"/>) and terrorism
content (France <xref target="Hertel-2015"/>).</t>

</section>
</section>
<section anchor="transport-layer" title="Transport Layer">

<section anchor="performance-degradation" title="Performance Degradation">

<t>While other interference techniques outlined in this section mostly
focus on blocking or preventing access to content, it can be an
effective censorship strategy in some cases to not entirely block
access to a given destination, or service but instead degrade the
performance of the relevant network connection.  The resulting user
experience for a site or service under performance degradation can be
so bad that users opt to use a different site, service, or method of
communication, or may not engage in communication at all if there are
no alternatives.  Traffic shaping techniques that rate-limit the
bandwidth available to certain types of traffic is one example of a
performance degradation.</t>

<t>Trade offs: While implementing a performance degradation will not
always eliminate the ability of people to access a desire resource, it
may force them to use other means of communication where censorship
(or surveillance) is more easily accomplished.</t>

<t>Empirical Examples: Iran has been known to shape the bandwidth available to
HTTPS traffic to encourage unencrypted HTTP traffic <xref target="Aryan-2012"/>.</t>

</section>
<section anchor="packet-dropping" title="Packet Dropping">

<t>Packet dropping is a simple mechanism to prevent undesirable
traffic. The censor identifies undesirable traffic and chooses to not
properly forward any packets it sees associated with the traversing
undesirable traffic instead of following a normal routing
protocol. This can be paired with any of the previously described
mechanisms so long as the censor knows the user must route traffic
through a controlled router.</t>

<t>Trade offs: Packet Dropping is most successful when every traversing
packet has transparent information linked to undesirable content, such
as a Destination IP. One downside Packet Dropping suffers from is the
necessity of blocking all content from otherwise allowable IPs
based on a single subversive sub-domain; blogging services and github
repositories are good examples. China famously dropped all github
packets for three days based on a single repository hosting
undesirable content <xref target="Anonymous-2013"/>.  The need to inspect every
traversing packet in close to real time also makes Packet Dropping
somewhat challenging from a QoS perspective.</t>

<t>Empirical Examples: Packet Dropping is a very common form of technical
interference and lends itself to accurate detection given the unique
nature of the time-out requests it leaves in its wake. The Great
Firewall of China has been observed using packet dropping as one of its primary
mechanisms of technical censorship <xref target="Ensafi-2013"/>. Iran has also used
Packet Dropping as the mechanisms for throttling SSH
<xref target="Aryan-2012"/>. These are but two examples of a ubiquitous censorship
practice. Notably, packet dropping during the handshake or working connection is the only interference technique observed for QUIC traffic so far, e.g. in India, Iran, Russia and Uganda <xref target="Elmenhorst-2021"/><xref target="Elmenhorst-2022"/>.</t>

</section>
<section anchor="rst-inject" title="RST Packet Injection">

<t>Packet injection, generally, refers to a man-in-the-middle (MITM)
network interference technique that spoofs packets in an established
traffic stream. RST packets are normally used to let one side of TCP
connection know the other side has stopped sending information, and
thus the receiver should close the connection. RST Packet Injection is
a specific type of packet injection attack that is used to interrupt
an established stream by sending RST packets to both sides of a TCP
connection; as each receiver thinks the other has dropped the
connection, the session is terminated.</t>

<t>QUIC is not vulnerable to these types of injection attacks once the
connection has been setup. While QUIC implements a stateless reset mechanism, 
such a reset is only accepted by a peer if the packet ends in a previously 
issued stateless reset token which is hard to guess. 
During the handshake, QUIC only provides effective protection
against off-path attackers but is vulnerable to injection attacks by
attackers that have parsed prior packets.
(See <xref target="I-D.ietf-quic-transport"/> for more details.)</t>

<t>Trade-offs: Although ineffective against non-TCP protocols (QUIC, IPSec), RST Packet Injection has a few advantages that make it
extremely popular as a technique employed for censorship. RST Packet Injection is
an out-of-band interference mechanism, allowing the avoidance of the the
QoS bottleneck one can encounter with inline techniques such as Packet
Dropping. This out-of-band property allows a censor to inspect a copy
of the information, usually mirrored by an optical splitter, making it
an ideal pairing for DPI and protocol identification
<xref target="Weaver-2009"/> (this asynchronous version of a MITM is often called a
Man-on-the-Side (MOTS)).
RST Packet Injection also has the advantage of only
requiring one of the two endpoints to accept the spoofed packet for
the connection to be interrupted.</t>

<t>The difficult part of RST Packet Injection is spoofing “enough”
correct information to ensure one end-point accepts a RST packet as
legitimate; this generally implies a correct IP, port, and TCP
sequence number. Sequence number is the hardest to get correct, as
<xref target="RFC0793"/> specifies an RST Packet should be in-sequence to be
accepted, although the RFC also recommends allowing in-window packets
as “good enough”. This in-window recommendation is important, as if it
is implemented it allows for successful Blind RST Injection attacks
<xref target="Netsec-2011"/>.  When in-window sequencing is allowed, it is trivial
to conduct a Blind RST Injection: while the term “blind” injection
implies the censor
doesn’t know any sensitive sequencing information about
the TCP stream they are injecting into, they can simply enumerate all
~70000 possible windows; this is particularly useful for interrupting
encrypted/obfuscated protocols such as SSH or Tor <xref target="Gilad"/>.
Some censorship evasion systems work by trying to confuse the censor
into tracking incorrect information, rendering their RST Packet Injection
useless <xref target="Khattak-2013"/>, <xref target="Wang-2017"/>, <xref target="Li-2017"/>, <xref target="Bock-2019"/>,
<xref target="Wang-2020"/>.</t>

<t>RST Packet Injection relies on a stateful network, making it useless against UDP
connections. RST Packet Injection is among the most popular censorship
techniques used today given its versatile nature and effectiveness
against all types of TCP traffic. Recent research shows that a TCP RST
packet injection attack can even work in the case of an off-path
attacker <xref target="Cao-2016"/>.</t>

<t>Empirical Examples: RST Packet Injection, as mentioned above, is most
often paired with identification techniques that require splitting,
such as DPI or protocol identification. In 2007, Comcast was accused of
using RST Packet Injection to interrupt traffic it identified as
BitTorrent <xref target="Schoen-2007"/>, this later led to a US Federal
Communications Commission ruling against Comcast
<xref target="VonLohmann-2008"/>. China has also been known to use RST Packet
Injection for censorship purposes. This interference is especially
evident in the interruption of encrypted/obfuscated protocols, such as
those used by Tor <xref target="Winter-2012"/>.</t>

</section>
</section>
<section anchor="routing-layer" title="Routing Layer">

<section anchor="discon" title="Network Disconnection">

<t>While it is perhaps the crudest of all techniques employed for censorship, there is
no more effective way of making sure undesirable information isn’t
allowed to propagate on the web than by shutting off the network. The
network can be logically cut off in a region when a censoring body
withdraws all of the Boarder Gateway Protocol (BGP) prefixes routing
through the censor’s country.</t>

<t>Trade-offs: The impact to a network disconnection in a region is huge
and absolute; the censor pays for absolute control over digital
information by losing all the benefits the Internet brings; this
rarely a long-term solution for any censor and is normally only used
as a last resort in times of substantial unrest.</t>

<t>Empirical Examples: Network Disconnections tend to only happen in
times of substantial unrest, largely due to the huge social,
political, and economic impact such a move has. One of the first,
highly covered occurrences was with the Junta in Myanmar employing
Network Disconnection to help Junta forces quash a rebellion in 2007
<xref target="Dobie-2007"/>. China disconnected the network in the Xinjiang region
during unrest in 2009 in an effort to prevent the protests from
spreading to other regions <xref target="Heacock-2009"/>. The Arab Spring saw the
the most frequent usage of Network Disconnection, with events in Egypt
and Libya in 2011 <xref target="Cowie-2011"/>, and Syria in 2012
<xref target="Thomson-2012"/>. Russia indicated that it would attempt to
disconnect all Russian networks from the global internet in April 2019
as part of a test of the nation’s network independence. Reports also
indicate that, as part of the test disconnect, Russian telecommunications firms
must now route all traffic to state-operated monitoring points
<xref target="Cimpanu-2019"/>. India was the country that saw the largest number of
internet shutdowns per year in 2016 and 2017 <xref target="Dada-2017"/>.</t>

</section>
<section anchor="advroute" title="Adversarial Route Announcement">

<t>More fine-grained and potentially wide-spread censorship can be achieved with BGP hijacking, which adversarially re-routes BGP IP prefixes incorrectly within a region and beyond. This restricts and effectively censors the correctly known location of information that flows into or out of a jurisdiction and will similarly prevent people from outside your jurisdiction from viewing content generated outside your jurisdiction as the adversarial route announcement propagates. The first can be achieved by an adversarial BGP announcement of incorrect routes that are not intended to leak beyond a jurisdiction, where the latter attacks traffic by deliberately introducing bogus BGP announcements that reach the global internet.</t>

<t>Trade-offs: A global leak of a misrouted website can overwhelm an ISP if the website gets a lot of traffic. It is not a permanent solution because incorrect BGP routes that leak globally can be fixed, though within a jurisdiction only the ISP/IXP is in a position to correct them for local users.</t>

<t>Empirical examples: In 2008 Pakistan Telecom censored Youtube at the request of the Pakistan government by changing its BGP routes for the website. The new routes were announced to the ISP’s upstream providers and beyond. The entire Internet began directing Youtube routes to Pakistan Telecom and continued doing so for many hours. In 2018 nearly all Google services and Google cloud customers like Spotify all lost more than one hour of service after it lost control of several million of its IP addresses. Those IP prefixes were being misdirected to China Telecom, a Chinese government-owned ISP <xref target="Google-2018"/>}, in a manner similar to the BGP hijacking of US government and military websites by China Telecom in 2010. ISPs in both Russia (2022) and Myanmar (2021) have tried to hijack the same Twitter prefix more than once <xref target="MANRS"/>.</t>

</section>
</section>
<section anchor="multi-layer-and-non-layer" title="Multi-layer and Non-layer">

<section anchor="ddos" title="Distributed Denial of Service (DDoS)">

<t>Distributed Denial of Service attacks are a common attack mechanism
used by “hacktivists” and malicious hackers, but censors have used
DDoS in the past for a variety of reasons. There is a huge variety of
DDoS attacks <xref target="Wikip-DoS"/>, but at a high level two possible impacts
tend to occur; a flood attack results in the service being unusable
while resources are being spent to flood the service, a crash attack
aims to crash the service so resources can be reallocated elsewhere
without “releasing” the service.</t>

<t>Trade-offs: DDoS is an appealing mechanism when a censor would like to
prevent all access to undesirable content, instead of only access in
their region for a limited period of time, but this is really the only
uniquely beneficial feature for DDoS as a technique employed for censorship. The
resources required to carry out a successful DDoS against major
targets are computationally expensive, usually requiring renting or
owning a malicious distributed platform such as a botnet, and
imprecise. DDoS is an incredibly crude censorship technique, and
appears to largely be used as a timely, easy-to-access mechanism for
blocking undesirable content for a limited period of time.</t>

<t>Empirical Examples: In 2012 the U.K.’s GCHQ used DDoS to temporarily
shutdown IRC chat rooms frequented by members of Anonymous using the
Syn Flood DDoS method; Syn Flood exploits the handshake used by TCP to
overload the victim server with so many requests that legitimate
traffic becomes slow or impossible
<xref target="Schone-2014"/> <xref target="CERT-2000"/>. Dissenting opinion websites are
frequently victims of DDoS around politically sensitive events in
Burma <xref target="Villeneuve-2011"/>. Controlling parties in Russia
<xref target="Kravtsova-2012"/>, Zimbabwe <xref target="Orion-2013"/>, and Malaysia
<xref target="Muncaster-2013"/> have been accused of using DDoS to interrupt
opposition support and access during elections.
In 2015, China launched a DDoS attack using a true MITM system
collocated with the Great Firewall, dubbed “Great Cannon”, that was
able to inject JavaScript code into web visits to a Chinese search
engine that commandeered those user agents to send DDoS traffic to
various sites <xref target="Marczak-2015"/>.</t>

</section>
<section anchor="censorship-in-depth" title="Censorship in Depth">

<t>Often, censors implement multiple techniques in tandem, creating
“censorship in depth”. Censorship in depth can take many forms; some
censors block the same content through multiple techniques (such as
blocking a domain by DNS, IP blocking, and HTTP simultaneously), some deploy
parallel systems to improve censorship reliability (such as deploying
multiple different censorship systems to block the same domain), and others 
can use complimentary systems to limit evasion (such as by blocking
unwanted protocols entirely, forcing users to use other filtered protocols).</t>

<t>Trade-offs: Censorship in depth can be attractive for censors to deploy,
as it offers additional guarantees about censorship: even if someone evades 
one type of censorship, they may still be blocked by another. The main
drawback to this approach is the cost to initial deployment, as it requires
the system to deploy multiple censorship systems in tandem.</t>

<t>Empirical Examples: Censorship in depth is present in many large censoring
nation states today. Researchers have observed China has deployed
significant censorship in depth, often censoring the same resource across
multiple protocols <xref target="Chai-2019"/>, <xref target="Bock-2020b"/> or deploying additional
censorship systems to censor the same content and protocol <xref target="Bock-2021b"/>. 
Iran also has deployed a complimentary protocol filter to limit which
protocols can be used on certain ports, forcing users to rely on protocols
their censorship system can filter <xref target="Bock-2020"/>.</t>

</section>
</section>
</section>
<section anchor="nontechint" title="Non-Technical Interference">

<section anchor="manualfiltering" title="Manual Filtering">

<t>As the name implies, sometimes manpower is the easiest way to figure
out which content to block.  Manual Filtering differs from the common
tactic of building up blocklists in that it doesn’t necessarily target
a specific IP or DNS, but instead removes or flags content.  Given the
imprecise nature of automatic filtering, manually sorting through
content and flagging dissenting websites, blogs, articles and other
media for filtration can be an effective technique.  This filtration
can occur on the Backbone/ISP level – China’s army of monitors is a
good example <xref target="BBC-2013b"/> – but more commonly manual filtering
occurs on an institutional level.  Internet Content Providers such as
Google or Weibo, require a business license to operate in China.  One
of the prerequisites for a business license is an agreement to sign a
“voluntary pledge” known as the “Public Pledge on Self-discipline for
the Chinese Internet Industry”.  The failure to “energetically
uphold” the pledged values can lead to the ICPs being held liable for
the offending content by the Chinese government <xref target="BBC-2013b"/>.</t>

</section>
<section anchor="selfcensor" title="Self-Censorship">

<t>Self-censorship is difficult to document, as it manifests primarily
through a lack of undesirable content. Tools which encourage
self-censorship are those which may lead a prospective speaker to
believe that speaking increases the risk of unfavourable outcomes for
the speaker (technical monitoring, identification requirements,
etc.). Reporters Without Borders exemplify methods of imposing
self-censorship in their annual World Press Freedom Index reports
<xref target="RWB2020"/>.</t>

</section>
<section anchor="serverko" title="Server Takedown">

<t>As mentioned in passing by <xref target="Murdoch-2011"/>, servers must have a
physical location somewhere in the world. If undesirable content is
hosted in the censoring country the servers can be physically seized
or – in cases where a server is virtualized in a cloud infrastructure
where it may not necessarily have a fixed physical location – the
hosting provider can be required to prevent access.</t>

</section>
<section anchor="notice" title="Notice and Takedown">

<t>In many countries, legal mechanisms exist where an individual or other
content provider can issue a legal request to a content host that
requires the host to take down content. Examples include the systems
employed by companies like Google to comply with “Right to be
Forgotten” policies in the European Union <xref target="Google-RTBF"/>,
intermediary liability rules for electronic platform providers
<xref target="EC-2012"/>, or the copyright-oriented notice and takedown regime of
the United States Digital Millennium Copyright Act (DMCA) Section 512
<xref target="DMLP-512"/>.</t>

</section>
<section anchor="dns-seizures" title="Domain-Name Seizures">

<t>Domain names are catalogued in so-called name-servers operated by
legal entities called registries. These registries can be made to cede
control over a domain name to someone other than the entity which
registered the domain name through a legal procedure grounded in either
private contracts or public law. Domain name seizures is increasingly
used by both public authorities and private entities to deal with
undesired content dissemination <xref target="ICANN2012"/> <xref target="EFF2017"/>.</t>

</section>
</section>
<section anchor="future-work" title="Future work">

<t>In addition to establishing a thorough resource for describing censorship techniques this document implicates critical areas for future work.</t>

<t>Taken as a whole the apparent costs of implementation of censorship techniques indicate a need for better classification of censorship regimes as they evolve and mature and specifying censorship circumvention techniques themselves. Censors maturity refers to the technical maturity required of the censor to perform the specific censorship technique. Future work might classify techniques by essentially how hard a censor must work, including what infrastructure is required, in order to successfully censor content, users or services.</t>

<t>On circumvention, the increase in protocols leveraging encryption is an effective counter-measure against some forms of censorship described in this document, but that thorough research on circumvention and encryption be left for another document. Moreover the censorship circumvention community has developed an area of research on “pluggable transports,” which collects, documents and makes agile methods for obfuscating the on-path traffic of censorship circumvention tools such that it appears indistinguishable from other kinds of traffic <xref target="Tor-2020"/>. Those methods would benefit from future work in the internet standards community, too.</t>

<t>Lastly the empirical examples demonstrate that censorship techniques can evolve quickly, and experience shows that this document can only be a point-in-time statement. Future work might extend this document with updates and new techniques described using a comparable methodology.</t>

</section>
<section anchor="Contributors" title="Contributors">

<t>This document benefited from discussions with and input from
David Belson, Stephane Bortzmeyer, Vinicius Fortuna,
Gurshabad Grover, Andrew McConachie, Martin Nilsson, Michael
Richardson, Patrick Vacek and Chris Wood.</t>

</section>


  </middle>

  <back>


    <references title='Informative References'>





<reference  anchor='RFC0793' target='https://www.rfc-editor.org/info/rfc793'>
<front>
<title>Transmission Control Protocol</title>
<author initials='J.' surname='Postel' fullname='J. Postel'><organization /></author>
<date year='1981' month='September' />
</front>
<seriesInfo name='STD' value='7'/>
<seriesInfo name='RFC' value='793'/>
<seriesInfo name='DOI' value='10.17487/RFC0793'/>
</reference>



<reference  anchor='RFC7754' target='https://www.rfc-editor.org/info/rfc7754'>
<front>
<title>Technical Considerations for Internet Service Blocking and Filtering</title>
<author initials='R.' surname='Barnes' fullname='R. Barnes'><organization /></author>
<author initials='A.' surname='Cooper' fullname='A. Cooper'><organization /></author>
<author initials='O.' surname='Kolkman' fullname='O. Kolkman'><organization /></author>
<author initials='D.' surname='Thaler' fullname='D. Thaler'><organization /></author>
<author initials='E.' surname='Nordmark' fullname='E. Nordmark'><organization /></author>
<date year='2016' month='March' />
<abstract><t>The Internet is structured to be an open communications medium.  This openness is one of the key underpinnings of Internet innovation, but it can also allow communications that may be viewed as undesirable by certain parties.  Thus, as the Internet has grown, so have mechanisms to limit the extent and impact of abusive or objectionable communications.  Recently, there has been an increasing emphasis on &quot;blocking&quot; and &quot;filtering&quot;, the active prevention of such communications.  This document examines several technical approaches to Internet blocking and filtering in terms of their alignment with the overall Internet architecture.  When it is possible to do so, the approach to blocking and filtering that is most coherent with the Internet architecture is to inform endpoints about potentially undesirable services, so that the communicants can avoid engaging in abusive or objectionable communications.  We observe that certain filtering and blocking approaches can cause unintended consequences to third parties, and we discuss the limits of efficacy of various approaches.</t></abstract>
</front>
<seriesInfo name='RFC' value='7754'/>
<seriesInfo name='DOI' value='10.17487/RFC7754'/>
</reference>



<reference  anchor='RFC7624' target='https://www.rfc-editor.org/info/rfc7624'>
<front>
<title>Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement</title>
<author initials='R.' surname='Barnes' fullname='R. Barnes'><organization /></author>
<author initials='B.' surname='Schneier' fullname='B. Schneier'><organization /></author>
<author initials='C.' surname='Jennings' fullname='C. Jennings'><organization /></author>
<author initials='T.' surname='Hardie' fullname='T. Hardie'><organization /></author>
<author initials='B.' surname='Trammell' fullname='B. Trammell'><organization /></author>
<author initials='C.' surname='Huitema' fullname='C. Huitema'><organization /></author>
<author initials='D.' surname='Borkmann' fullname='D. Borkmann'><organization /></author>
<date year='2015' month='August' />
<abstract><t>Since the initial revelations of pervasive surveillance in 2013, several classes of attacks on Internet communications have been discovered.  In this document, we develop a threat model that describes these attacks on Internet confidentiality.  We assume an attacker that is interested in undetected, indiscriminate eavesdropping.  The threat model is based on published, verified attacks.</t></abstract>
</front>
<seriesInfo name='RFC' value='7624'/>
<seriesInfo name='DOI' value='10.17487/RFC7624'/>
</reference>



<reference  anchor='RFC6066' target='https://www.rfc-editor.org/info/rfc6066'>
<front>
<title>Transport Layer Security (TLS) Extensions: Extension Definitions</title>
<author initials='D.' surname='Eastlake 3rd' fullname='D. Eastlake 3rd'><organization /></author>
<date year='2011' month='January' />
<abstract><t>This document provides specifications for existing TLS extensions.  It is a companion document for RFC 5246, &quot;The Transport Layer Security (TLS) Protocol Version 1.2&quot;.  The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6066'/>
<seriesInfo name='DOI' value='10.17487/RFC6066'/>
</reference>



<reference  anchor='RFC8484' target='https://www.rfc-editor.org/info/rfc8484'>
<front>
<title>DNS Queries over HTTPS (DoH)</title>
<author initials='P.' surname='Hoffman' fullname='P. Hoffman'><organization /></author>
<author initials='P.' surname='McManus' fullname='P. McManus'><organization /></author>
<date year='2018' month='October' />
<abstract><t>This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS.  Each DNS query-response pair is mapped into an HTTP exchange.</t></abstract>
</front>
<seriesInfo name='RFC' value='8484'/>
<seriesInfo name='DOI' value='10.17487/RFC8484'/>
</reference>



<reference  anchor='RFC7858' target='https://www.rfc-editor.org/info/rfc7858'>
<front>
<title>Specification for DNS over Transport Layer Security (TLS)</title>
<author initials='Z.' surname='Hu' fullname='Z. Hu'><organization /></author>
<author initials='L.' surname='Zhu' fullname='L. Zhu'><organization /></author>
<author initials='J.' surname='Heidemann' fullname='J. Heidemann'><organization /></author>
<author initials='A.' surname='Mankin' fullname='A. Mankin'><organization /></author>
<author initials='D.' surname='Wessels' fullname='D. Wessels'><organization /></author>
<author initials='P.' surname='Hoffman' fullname='P. Hoffman'><organization /></author>
<date year='2016' month='May' />
<abstract><t>This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS.  Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626.  In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS.</t><t>This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group.  It does not prevent future applications of the protocol to recursive-to-authoritative traffic.</t></abstract>
</front>
<seriesInfo name='RFC' value='7858'/>
<seriesInfo name='DOI' value='10.17487/RFC7858'/>
</reference>


<reference anchor="I-D.ietf-tls-sni-encryption">
   <front>
      <title>Issues and Requirements for Server Name Identification (SNI) Encryption in TLS</title>
      <author fullname="Christian Huitema">
	 <organization>Private Octopus Inc.</organization>
      </author>
      <author fullname="Eric Rescorla">
	 <organization>RTFM, Inc.</organization>
      </author>
      <date month="October" day="28" year="2019" />
      <abstract>
	 <t>This document describes the general problem of encrypting the Server Name Identification (SNI) TLS parameter. The proposed solutions hide a hidden service behind a fronting service, only disclosing the SNI of the fronting service to external observers. This document lists known attacks against SNI encryption, discusses the current &quot;HTTP co-tenancy&quot; solution, and presents requirements for future TLS-layer solutions.

 In practice, it may well be that no solution can meet every requirement and that practical solutions will have to make some compromises.
	 </t>
      </abstract>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-tls-sni-encryption-09" />
   <format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-tls-sni-encryption-09.txt" />
</reference>


<reference anchor="I-D.ietf-tls-esni">
   <front>
      <title>TLS Encrypted Client Hello</title>
      <author fullname="Eric Rescorla">
	 <organization>RTFM, Inc.</organization>
      </author>
      <author fullname="Kazuho Oku">
	 <organization>Fastly</organization>
      </author>
      <author fullname="Nick Sullivan">
	 <organization>Cloudflare</organization>
      </author>
      <author fullname="Christopher A. Wood">
	 <organization>Cloudflare</organization>
      </author>
      <date month="February" day="13" year="2022" />
      <abstract>
	 <t>   This document describes a mechanism in Transport Layer Security (TLS)
   for encrypting a ClientHello message under a server public key.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Source for this draft and an issue tracker can be found at
   https://github.com/tlswg/draft-ietf-tls-esni
   (https://github.com/tlswg/draft-ietf-tls-esni).

	 </t>
      </abstract>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-tls-esni-14" />
   <format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-tls-esni-14.txt" />
</reference>


<reference anchor="I-D.ietf-quic-transport">
   <front>
      <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
      <author fullname="Jana Iyengar">
	 <organization>Fastly</organization>
      </author>
      <author fullname="Martin Thomson">
	 <organization>Mozilla</organization>
      </author>
      <date month="January" day="14" year="2021" />
      <abstract>
	 <t>This document defines the core of the QUIC transport protocol.  QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration.  QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances.  Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.
	 </t>
      </abstract>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-quic-transport-34" />
   <format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-quic-transport-34.txt" />
</reference>


<reference anchor="RWB2020" target="https://rsf.org/en/2020-world-press-freedom-index-entering-decisive-decade-journalism-exacerbated-coronavirus">
  <front>
    <title>2020 World Press Freedom Index: Entering a decisive decade for journalism, exacerbated by coronavirus</title>
    <author >
      <organization>Reporters Without Borders</organization>
    </author>
    <date year="2020"/>
  </front>
</reference>
<reference anchor="HADOPI-2020" target="https://www.hadopi.fr/en/node/3668">
  <front>
    <title>Présentation</title>
    <author >
      <organization>Haute Autorité pour la Diffusion des oeuvres et la Protection des Droits sur Internet</organization>
    </author>
    <date year="2020"/>
  </front>
</reference>
<reference anchor="SSAC-109-2020" target="https://www.icann.org/en/system/files/files/sac-109-en.pdf">
  <front>
    <title>SAC109: The Implications of DNS over HTTPS and DNS over TLS</title>
    <author >
      <organization>ICANN Security and Stability Advisory Committee</organization>
    </author>
    <date year="2020"/>
  </front>
</reference>
<reference anchor="ICANN2012" target="https://www.icann.org/en/system/files/files/guidance-domain-seizures-07mar12-en.pdf">
  <front>
    <title>Guidance for Preparing Domain Name Orders, Seizures &amp; Takedowns</title>
    <author >
      <organization>ICANN Security and Stability Advisory Committee</organization>
    </author>
    <date year="2012"/>
  </front>
</reference>
<reference anchor="Tor-2020" target="https://2019.www.torproject.org/docs/pluggable-transports.html.en">
  <front>
    <title>Tor: Pluggable Transports</title>
    <author >
      <organization>The Tor Project</organization>
    </author>
    <date year="2020"/>
  </front>
</reference>
<reference anchor="WP-Def-2020" target="https://en.wikipedia.org/w/index.php?title=Censorship&amp;oldid=943938595">
  <front>
    <title>Censorship</title>
    <author >
      <organization>Wikipedia contributors</organization>
    </author>
    <date year="2020"/>
  </front>
</reference>
<reference anchor="EC-gambling-2012" target="https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52012SC0345">
  <front>
    <title>Online gambling in the Internal Market</title>
    <author >
      <organization>European Commission</organization>
    </author>
    <date year="2012"/>
  </front>
</reference>
<reference anchor="EC-gambling-2019" target="https://ec.europa.eu/growth/content/evaluation-regulatory-tools-enforcing-online-gambling-rules-and-channelling-demand-towards-1_en">
  <front>
    <title>Evaluation of regulatory tools for enforcing online gambling rules and channeling demand towards controlled offers</title>
    <author >
      <organization>European Commission</organization>
    </author>
    <date year="2019"/>
  </front>
</reference>
<reference anchor="EC-2012" target="https://ec.europa.eu/information_society/newsroom/image/document/2017-4/consultation_summary_report_en_2010_42070.pdf">
  <front>
    <title>Summary of the results of the Public Consultation on the future of electronic commerce in the Internal Market and the implementation of the Directive on electronic commerce (2000/31/EC)</title>
    <author >
      <organization>European Commission</organization>
    </author>
    <date year="2012"/>
  </front>
</reference>
<reference anchor="Bentham-1791" target="https://www.google.com/books/edition/_/Ec4TAAAAQAAJ?hl=en">
  <front>
    <title>Panopticon Or the Inspection House</title>
    <author initials="J." surname="Bentham" fullname="Jeremy Bentham">
      <organization></organization>
    </author>
    <date year="1791"/>
  </front>
</reference>
<reference anchor="Ellul-1973" target="https://www.penguinrandomhouse.com/books/46234/propaganda-by-jacques-ellul/">
  <front>
    <title>Propaganda: The Formation of Men's Attitudes</title>
    <author initials="J." surname="Ellul" fullname="Jacques Ellul">
      <organization></organization>
    </author>
    <date year="1973"/>
  </front>
</reference>
<reference anchor="Reda-2017" target="https://juliareda.eu/2017/11/eu-website-blocking/">
  <front>
    <title>New EU law prescribes website blocking in the name of 'consumer protection'</title>
    <author initials="J." surname="Reda" fullname="Julia Reda">
      <organization></organization>
    </author>
    <date year="2017"/>
  </front>
</reference>
<reference anchor="Knight-2005" target="https://www.newscientist.com/article/dn7589-iranian-net-censorship-powered-by-us-technology/">
  <front>
    <title>Iranian net censorship powered by US technology</title>
    <author initials="W." surname="Knight" fullname="Will Knight">
      <organization></organization>
    </author>
    <date year="2005"/>
  </front>
</reference>
<reference anchor="SIDN2020" target="https://labs.ripe.net/Members/giovane_moura/detecting-and-taking-down-fraudulent-webshops-at-a-cctld">
  <front>
    <title>Detecting and Taking Down Fraudulent Webshops at the .nl ccTLD</title>
    <author initials="G." surname="Moura" fullname="Giovane Moura">
      <organization></organization>
    </author>
    <date year="2020"/>
  </front>
</reference>
<reference anchor="Cimpanu-2019" target="https://www.zdnet.com/article/russia-to-disconnect-from-the-internet-as-part-of-a-planned-test/">
  <front>
    <title>Russia to disconnect from the internet as part of a planned test</title>
    <author initials="C." surname="Cimpanu" fullname="Catalin Cimpanu">
      <organization></organization>
    </author>
    <date year="2019"/>
  </front>
</reference>
<reference anchor="Hertel-2015" target="https://www.sciencesetavenir.fr/high-tech/comment-les-autorites-peuvent-bloquer-un-site-internet_35828">
  <front>
    <title>Comment les autorités peuvent bloquer un site Internet</title>
    <author initials="O." surname="Hertel" fullname="Olivier Hertel">
      <organization></organization>
    </author>
    <date year="2015"/>
  </front>
</reference>
<reference anchor="Eneman-2010" target="https://www.gu.se/forskning/publikation/?publicationId=96592">
  <front>
    <title>ISPs filtering of child abusive material: A critical reflection of its effectiveness</title>
    <author initials="M." surname="Eneman" fullname="Marie Eneman">
      <organization></organization>
    </author>
    <date year="2010"/>
  </front>
</reference>
<reference anchor="Gatlan-2019" target="https://www.bleepingcomputer.com/news/security/south-korea-is-censoring-the-internet-by-snooping-on-sni-traffic/">
  <front>
    <title>South Korea is Censoring the Internet by Snooping on SNI Traffic</title>
    <author initials="S." surname="Gatlan" fullname="Sergiu Gatlan">
      <organization></organization>
    </author>
    <date year="2019"/>
  </front>
</reference>
<reference anchor="Lomas-2019" target="https://techcrunch.com/2019/10/30/github-removes-tsunami-democratics-apk-after-a-takedown-order-from-spain/">
  <front>
    <title>Github removes Tsunami Democràtic’s APK after a takedown order from Spain</title>
    <author initials="N." surname="Lomas" fullname="Natasha Lomas">
      <organization></organization>
    </author>
    <date year="2019"/>
  </front>
</reference>
<reference anchor="Victor-2019" target="https://www.nytimes.com/2019/10/09/world/asia/blizzard-hearthstone-hong-kong.html">
  <front>
    <title>Blizzard Sets Off Backlash for Penalizing Hearthstone Gamer in Hong Kong</title>
    <author initials="D." surname="Victor" fullname="Daniel Victor">
      <organization></organization>
    </author>
    <date year="2019"/>
  </front>
</reference>
<reference anchor="Glanville-2008" target="http://www.theguardian.com/commentisfree/2008/nov/17/censorship-internet">
  <front>
    <title>The Big Business of Net Censorship</title>
    <author initials="J." surname="Glanville" fullname="Jo Glanville">
      <organization></organization>
    </author>
    <date year="2008"/>
  </front>
</reference>
<reference anchor="EFF2017" target="https://www.eff.org/files/2017/08/02/domain_registry_whitepaper.pdf">
  <front>
    <title>Which Internet registries offer the best protection for domain owners?</title>
    <author initials="J." surname="Malcom" fullname="Jeremy Malcolm">
      <organization></organization>
    </author>
    <author initials="M." surname="Stoltz" fullname="Mitch Stoltz">
      <organization></organization>
    </author>
    <author initials="G." surname="Rossi" fullname="Gus Rossi">
      <organization></organization>
    </author>
    <author initials="V." surname="Paxson" fullname="Vern Paxson">
      <organization></organization>
    </author>
    <date year="2017"/>
  </front>
</reference>
<reference anchor="Tschantz-2016" target="https://oaklandsok.github.io/papers/tschantz2016.pdf">
  <front>
    <title>SoK: Towards Grounding Censorship Circumvention in Empiricism</title>
    <author initials="M." surname="Tschantz" fullname="Michael Carl Tschantz">
      <organization></organization>
    </author>
    <author initials="S." surname="Afroz" fullname="Sadia Afroz">
      <organization></organization>
    </author>
    <author initials="A." surname="Anonymous" fullname="Anonymous">
      <organization></organization>
    </author>
    <author initials="V." surname="Paxson" fullname="Vern Paxson">
      <organization></organization>
    </author>
    <date year="2016"/>
  </front>
</reference>
<reference anchor="Cao-2016" target="https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_cao.pdf">
  <front>
    <title>Off-Path TCP Exploits: Global Rate Limit Considered Dangerous</title>
    <author initials="Y." surname="Cao" fullname="Yue Cao">
      <organization></organization>
    </author>
    <author initials="Z." surname="Qian" fullname="Zhiyun Qian">
      <organization></organization>
    </author>
    <author initials="Z." surname="Wang" fullname="Zhongjie Wang">
      <organization></organization>
    </author>
    <author initials="T." surname="Dao" fullname="Tuan Dao">
      <organization></organization>
    </author>
    <author initials="S." surname="Krishnamurthy" fullname="Srikanth V. Krishnamurthy">
      <organization></organization>
    </author>
    <author initials="L." surname="Marvel" fullname="Lisa M. Marvel">
      <organization></organization>
    </author>
    <date year="2016"/>
  </front>
</reference>
<reference anchor="Leyba-2019" target="https://forrest.biodesign.asu.edu/data/publications/2019-compass-chokepoints.pdf">
  <front>
    <title>Borders and Gateways: Measuring and Analyzing National AS Chokepoints</title>
    <author initials="K." surname="Leyba" fullname="Kirtus G. Leyba">
      <organization></organization>
    </author>
    <author initials="B." surname="Edwards" fullname="Benjamin Edwards">
      <organization></organization>
    </author>
    <author initials="C." surname="Freeman" fullname="Cynthia Freeman">
      <organization></organization>
    </author>
    <author initials="J." surname="Crandall" fullname="Jedidiah R. Crandall">
      <organization></organization>
    </author>
    <author initials="S." surname="Forrest" fullname="Stephanie Forrest">
      <organization></organization>
    </author>
    <date year="2019"/>
  </front>
</reference>
<reference anchor="Chai-2019" target="https://www.usenix.org/system/files/foci19-paper_chai_update.pdf">
  <front>
    <title>On the Importance of Encrypted-SNI (ESNI) to Censorship Circumvention</title>
    <author initials="Z." surname="Chai" fullname="Zimo Chai">
      <organization></organization>
    </author>
    <author initials="A." surname="Ghafari" fullname="Amirhossein Ghafari">
      <organization></organization>
    </author>
    <author initials="A." surname="Houmansadr" fullname="Amir Houmansadr">
      <organization></organization>
    </author>
    <date year="2019"/>
  </front>
</reference>
<reference anchor="Patil-2019" target="https://irtf.org/anrw/2019/anrw2019-final44-acmpaginated.pdf">
  <front>
    <title>What Can You Learn from an IP?</title>
    <author initials="S." surname="Patil" fullname="Simran Patil">
      <organization></organization>
    </author>
    <author initials="N." surname="Borisov" fullname="Nikita Borisov">
      <organization></organization>
    </author>
    <date year="2019"/>
  </front>
</reference>
<reference anchor="Wright-2013" target="https://policyreview.info/articles/analysis/internet-filtering-trends-liberal-democracies-french-and-german-regulatory-debates">
  <front>
    <title>Internet filtering trends in liberal democracies: French and German regulatory debates</title>
    <author initials="J." surname="Wright" fullname="Joss Wright">
      <organization></organization>
    </author>
    <author initials="Y." surname="Breindl" fullname="Yana Breindl">
      <organization></organization>
    </author>
    <date year="2013"/>
  </front>
</reference>
<reference anchor="Grover-2019" target="https://cis-india.org/internet-governance/blog/reliance-jio-is-using-sni-inspection-to-block-websites">
  <front>
    <title>Reliance Jio is using SNI inspection to block websites</title>
    <author initials="G." surname="Grover" fullname="Gurshabad Grover">
      <organization></organization>
    </author>
    <author initials="K." surname="Singh" fullname="Kushagra Singh">
      <organization></organization>
    </author>
    <author initials="E." surname="Hickok" fullname="Elonnai Hickok">
      <organization></organization>
    </author>
    <date year="2019"/>
  </front>
</reference>
<reference anchor="Singh-2019" target="https://arxiv.org/abs/1912.08590">
  <front>
    <title>How India Censors the Web</title>
    <author initials="K." surname="Singh" fullname="Kushagra Singh">
      <organization></organization>
    </author>
    <author initials="G." surname="Grover" fullname="Gurshabad Grover">
      <organization></organization>
    </author>
    <author initials="V." surname="Bansal" fullname="Varun Bansal">
      <organization></organization>
    </author>
    <date year="2019"/>
  </front>
</reference>
<reference anchor="NA-SK-2019" target="https://www.newamerica.org/cybersecurity-initiative/c2b/c2b-log/analysis-south-koreas-sni-monitoring/">
  <front>
    <title>Analysis: South Korea's New Tool for Filtering Illegal Internet Content</title>
    <author initials="R." surname="Morgus" fullname="Robert Morgus">
      <organization></organization>
    </author>
    <author initials="J." surname="Sherman" fullname="Justin Sherman">
      <organization></organization>
    </author>
    <author initials="S." surname="Nam" fullname="Seonghyun Nam">
      <organization></organization>
    </author>
    <date year="2019"/>
  </front>
</reference>
<reference anchor="CitizenLab-2018" target="https://citizenlab.ca/2018/03/bad-traffic-sandvines-packetlogic-devices-deploy-government-spyware-turkey-syria/">
  <front>
    <title>Bad Traffic: Sandvine’s PacketLogic Devices Used to Deploy Government Spyware in Turkey and Redirect Egyptian Users to Affiliate Ads?</title>
    <author initials="B." surname="Marczak" fullname="Bill Marczak">
      <organization></organization>
    </author>
    <author initials="J." surname="Dalek" fullname="Jakub Dalek">
      <organization></organization>
    </author>
    <author initials="S." surname="McKune" fullname="Sarah McKune">
      <organization></organization>
    </author>
    <author initials="A." surname="Senft" fullname="Adam Senft">
      <organization></organization>
    </author>
    <author initials="J." surname="Scott-Railton" fullname="John Scott-Railton">
      <organization></organization>
    </author>
    <author initials="R." surname="Deibert" fullname="Ron Deibert">
      <organization></organization>
    </author>
    <date year="2018"/>
  </front>
</reference>
<reference anchor="OONI-2019" target="https://ooni.org/post/2019-china-wikipedia-blocking/">
  <front>
    <title>China is now blocking all language editions of Wikipedia</title>
    <author initials="S." surname="Singh" fullname="Sukhbir Singh">
      <organization></organization>
    </author>
    <author initials="A." surname="Filastò" fullname="Arturo Filastò">
      <organization></organization>
    </author>
    <author initials="M." surname="Xynou" fullname="Maria Xynou">
      <organization></organization>
    </author>
    <date year="2019"/>
  </front>
</reference>
<reference anchor="OONI-2018" target="https://ooni.org/post/2018-iran-protests-pt2/">
  <front>
    <title>Iran Protests: DPI blocking of Instagram (Part 2)</title>
    <author initials="L." surname="Evdokimov" fullname="Leonid Evdokimov">
      <organization></organization>
    </author>
    <date year="2018"/>
  </front>
</reference>
<reference anchor="Dada-2017" target="https://www.accessnow.org/keepiton-shutdown-tracker/">
  <front>
    <title>Launching STOP: the #KeepItOn internet shutdown tracker</title>
    <author initials="T." surname="Dada" fullname="Tinuola Dada">
      <organization></organization>
    </author>
    <author initials="P." surname="Micek" fullname="Peter Micek">
      <organization></organization>
    </author>
    <date year="2017"/>
  </front>
</reference>
<reference anchor="Verkamp-2012" target="https://www.usenix.org/system/files/conference/foci12/foci12-final1.pdf">
  <front>
    <title>Inferring Mechanics of Web Censorship Around the World</title>
    <author initials="J.P." surname="Verkamp" fullname="John-Paul Verkamp">
      <organization></organization>
    </author>
    <author initials="M." surname="Gupta" fullname="Minaxi Gupta">
      <organization></organization>
    </author>
    <date year="2012"/>
  </front>
</reference>
<reference anchor="Nabi-2013" target="http://0b4af6cdc2f0c5998459-c0245c5c937c5dedcca3f1764ecc9b2f.r43.cf2.rackcdn.com/12387-foci13-nabi.pdf">
  <front>
    <title>The Anatomy of Web Censorship in Pakistan</title>
    <author initials="Z." surname="Nabi" fullname="Zubair Nabi">
      <organization></organization>
    </author>
    <date year="2013"/>
  </front>
</reference>
<reference anchor="Tang-2016" target="https://www.cs.tufts.edu/comp/116/archive/fall2016/ctang.pdf">
  <front>
    <title>In-depth analysis of the Great Firewall of China</title>
    <author initials="C." surname="Tang" fullname="Chao Tang">
      <organization></organization>
    </author>
    <date year="2016"/>
  </front>
</reference>
<reference anchor="Aryan-2012" target="https://jhalderm.com/pub/papers/iran-foci13.pdf">
  <front>
    <title>Internet Censorship in Iran: A First Look</title>
    <author initials="S." surname="Aryan" fullname="Simurgh Aryan">
      <organization></organization>
    </author>
    <author initials="H." surname="Aryan" fullname="Homa Aryan">
      <organization></organization>
    </author>
    <author initials="J.A." surname="Halderman" fullname="J. Alex Halderman">
      <organization></organization>
    </author>
    <date year="2012"/>
  </front>
</reference>
<reference anchor="Husak-2016" target="https://link.springer.com/article/10.1186/s13635-016-0030-7">
  <front>
    <title>HTTPS traffic analysis and client identification using passive SSL/TLS fingerprinting</title>
    <author initials="M." surname="Husak" fullname="Martin Husak">
      <organization></organization>
    </author>
    <author initials="M." surname="Cermak" fullname="Milan Cermak">
      <organization></organization>
    </author>
    <author initials="T." surname="Jirsik" fullname="Tomas Jirsik">
      <organization></organization>
    </author>
    <author initials="P." surname="Celeda" fullname="Pavel Celeda">
      <organization></organization>
    </author>
    <date year="2016"/>
  </front>
</reference>
<reference anchor="Dalek-2013" target="http://conferences.sigcomm.org/imc/2013/papers/imc112s-dalekA.pdf">
  <front>
    <title>A Method for Identifying and Confirming the Use of URL Filtering Products for Censorship</title>
    <author initials="J." surname="Dalek" fullname="Jakub Dalek">
      <organization></organization>
    </author>
    <date year="2013"/>
  </front>
</reference>
<reference anchor="Jones-2014" target="http://conferences2.sigcomm.org/imc/2014/papers/p299.pdf">
  <front>
    <title>Automated Detection and Fingerprinting of Censorship Block Pages</title>
    <author initials="B." surname="Jones" fullname="Ben Jones">
      <organization></organization>
    </author>
    <date year="2014"/>
  </front>
</reference>
<reference anchor="Crandall-2010" target="http://www.cs.unm.edu/~crandall/icdcs2010.pdf">
  <front>
    <title>Empirical Study of a National-Scale Distributed Intrusion Detection System: Backbone-Level Filtering of HTML Responses in China</title>
    <author initials="J." surname="Crandall" fullname="Jedediah Crandall">
      <organization></organization>
    </author>
    <date year="2010"/>
  </front>
</reference>
<reference anchor="Senft-2013" target="https://citizenlab.org/2013/11/asia-chats-analyzing-information-controls-privacy-asian-messaging-applications/">
  <front>
    <title>Asia Chats: Analyzing Information Controls and Privacy in Asian Messaging Applications</title>
    <author initials="A." surname="Senft" fullname="Adam Senft">
      <organization></organization>
    </author>
    <date year="2013"/>
  </front>
</reference>
<reference anchor="Rushe-2015" target="http://www.theguardian.com/technology/2014/feb/11/bing-censors-chinese-language-search-results">
  <front>
    <title>Bing censoring Chinese language search results for users in the US</title>
    <author initials="D." surname="Rushe" fullname="Dominic Rushe">
      <organization></organization>
    </author>
    <date year="2013"/>
  </front>
</reference>
<reference anchor="Cheng-2010" target="http://arstechnica.com/tech-policy/2010/06/google-tweaks-china-to-hong-kong-redirect-same-results/">
  <front>
    <title>Google stops Hong Kong auto-redirect as China plays hardball</title>
    <author initials="J." surname="Cheng" fullname="Jacqui Cheng">
      <organization></organization>
    </author>
    <date year="2010"/>
  </front>
</reference>
<reference anchor="Boyle-1997" target="https://scholarship.law.duke.edu/faculty_scholarship/619/">
  <front>
    <title>Foucault in Cyberspace: Surveillance, Sovereignty, and Hardwired Censors</title>
    <author initials="J." surname="Boyle" fullname="James Boyle">
      <organization></organization>
    </author>
    <date year="1997"/>
  </front>
</reference>
<reference anchor="Whittaker-2013" target="http://www.zdnet.com/1168-keywords-skype-uses-to-censor-monitor-its-chinese-users-7000012328/">
  <front>
    <title>1,168 keywords Skype uses to censor, monitor its Chinese users</title>
    <author initials="Z." surname="Whittaker" fullname="Zach Whittaker">
      <organization></organization>
    </author>
    <date year="2013"/>
  </front>
</reference>
<reference anchor="BBC-2013" target="http://www.bbc.com/news/uk-24980765">
  <front>
    <title>Google and Microsoft agree steps to block abuse images</title>
    <author >
      <organization>BBC News</organization>
    </author>
    <date year="2013"/>
  </front>
</reference>
<reference anchor="Condliffe-2013" target="http://gizmodo.com/google-announces-massive-new-restrictions-on-child-abus-1466539163">
  <front>
    <title>Google Announces Massive New Restrictions on Child Abuse Search Terms</title>
    <author initials="J." surname="Condliffe" fullname="Jamie Condliffe">
      <organization></organization>
    </author>
    <date year="2013"/>
  </front>
</reference>
<reference anchor="Zhu-2011" target="http://arxiv.org/ftp/arxiv/papers/1107/1107.3794.pdf">
  <front>
    <title>An Analysis of Chinese Search Engine Filtering</title>
    <author initials="T." surname="Zhu" fullname="Tao Zhu">
      <organization></organization>
    </author>
    <date year="2011"/>
  </front>
</reference>
<reference anchor="Wagner-2009" target="http://advocacy.globalvoicesonline.org/wp-content/uploads/2009/06/deeppacketinspectionandinternet-censorship2.pdf">
  <front>
    <title>Deep Packet Inspection and Internet Censorship: International Convergence on an ‘Integrated Technology of Control'</title>
    <author initials="B." surname="Wagner" fullname="Ben Wagner">
      <organization></organization>
    </author>
    <date year="2009"/>
  </front>
</reference>
<reference anchor="Porter-2010" target="http://www.symantec.com/connect/articles/perils-deep-packet-inspection">
  <front>
    <title>The Perils of Deep Packet Inspection</title>
    <author initials="T." surname="Porter" fullname="Thomas Porter">
      <organization></organization>
    </author>
    <date year="2010"/>
  </front>
</reference>
<reference anchor="Clayton-2006" target="http://link.springer.com/chapter/10.1007/11957454_2">
  <front>
    <title>Ignoring the Great Firewall of China</title>
    <author initials="R." surname="Clayton" fullname="Richard Clayton">
      <organization></organization>
    </author>
    <date year="2006"/>
  </front>
</reference>
<reference anchor="Anonymous-2014" target="https://www.usenix.org/system/files/conference/foci14/foci14-anonymous.pdf">
  <front>
    <title>Towards a Comprehensive Picture of the Great Firewall's DNS Censorship</title>
    <author >
      <organization>Anonymous</organization>
    </author>
    <date year="2014"/>
  </front>
</reference>
<reference anchor="Khattak-2013" target="http://0b4af6cdc2f0c5998459-c0245c5c937c5dedcca3f1764ecc9b2f.r43.cf2.rackcdn.com/12389-foci13-khattak.pdf">
  <front>
    <title>Towards Illuminating a Censorship Monitor's Model to Facilitate Evasion</title>
    <author initials="S." surname="Khattak" fullname="Sheharbano Khattak">
      <organization></organization>
    </author>
    <date year="2013"/>
  </front>
</reference>
<reference anchor="Wilde-2012" target="https://blog.torproject.org/blog/knock-knock-knockin-bridges-doors">
  <front>
    <title>Knock Knock Knockin' on Bridges Doors</title>
    <author initials="T." surname="Wilde" fullname="Tim Wilde">
      <organization></organization>
    </author>
    <date year="2012"/>
  </front>
</reference>
<reference anchor="Wagstaff-2013" target="http://www.reuters.com/article/2013/05/04/uk-malaysia-election-online-idUKBRE94309G20130504">
  <front>
    <title>In Malaysia, online election battles take a nasty turn</title>
    <author initials="J." surname="Wagstaff" fullname="Jeremy Wagstaff">
      <organization></organization>
    </author>
    <date year="2013"/>
  </front>
</reference>
<reference anchor="Hepting-2011" target="https://www.eff.org/cases/hepting">
  <front>
    <title>Hepting vs. AT&amp;T</title>
    <author >
      <organization>Electronic Frontier Foundation</organization>
    </author>
    <date year="2011"/>
  </front>
</reference>
<reference anchor="Hjelmvik-2010" target="https://www.iis.se/docs/hjelmvik_breaking.pdf">
  <front>
    <title>Breaking and Improving Protocol Obfuscation</title>
    <author initials="E." surname="Hjelmvik" fullname="Erik Hjelmvik">
      <organization></organization>
    </author>
    <date year="2010"/>
  </front>
</reference>
<reference anchor="Sandvine-2014" target="https://www.sandvine.com/downloads/general/technology/sandvine-technology-showcases/sandvine-technology-showcase-traffic-classification.pdf">
  <front>
    <title>Technology Showcase on Traffic Classification: Why Measurements and Freeform Policy Matter</title>
    <author >
      <organization>Sandvine</organization>
    </author>
    <date year="2014"/>
  </front>
</reference>
<reference anchor="Winter-2012" target="http://arxiv.org/pdf/1204.0447v1.pdf">
  <front>
    <title>How China is Blocking Tor</title>
    <author initials="P." surname="Winter" fullname="Phillip Winter">
      <organization></organization>
    </author>
    <date year="2012"/>
  </front>
</reference>
<reference anchor="Anonymous-2007" target="https://torrentfreak.com/how-to-bypass-comcast-bittorrent-throttling-071021">
  <front>
    <title>How to Bypass Comcast's Bittorrent Throttling</title>
    <author >
      <organization>Anonymous</organization>
    </author>
    <date year="2012"/>
  </front>
</reference>
<reference anchor="Anonymous-2013" target="https://en.greatfire.org/blog/2013/jan/github-blocked-china-how-it-happened-how-get-around-it-and-where-it-will-take-us">
  <front>
    <title>GitHub blocked in China - how it happened, how to get around it, and where it will take us</title>
    <author >
      <organization>Anonymous</organization>
    </author>
    <date year="2013"/>
  </front>
</reference>
<reference anchor="Ensafi-2013" target="http://arxiv.org/pdf/1312.5739v1.pdf">
  <front>
    <title>Detecting Intentional Packet Drops on the Internet via TCP/IP Side Channels</title>
    <author initials="R." surname="Ensafi" fullname="Roya Ensafi">
      <organization></organization>
    </author>
    <date year="2013"/>
  </front>
</reference>
<reference anchor="Weaver-2009" target="http://www.icir.org/vern/papers/reset-injection.ndss09.pdf">
  <front>
    <title>Detecting Forged TCP Packets</title>
    <author initials="N." surname="Weaver" fullname="Nicholas Weaver">
      <organization></organization>
    </author>
    <author initials="R." surname="Sommer" fullname="Robin Sommer">
      <organization></organization>
    </author>
    <author initials="V." surname="Paxson" fullname="Vern Paxson">
      <organization></organization>
    </author>
    <date year="2009"/>
  </front>
</reference>
<reference anchor="Netsec-2011" target="https://nets.ec/TCP-RST_Injection">
  <front>
    <title>TCP-RST Injection</title>
    <author >
      <organization>n3t2.3c</organization>
    </author>
    <date year="2011"/>
  </front>
</reference>
<reference anchor="Schoen-2007" target="https://www.eff.org/deeplinks/2007/10/eff-tests-agree-ap-comcast-forging-packets-to-interfere">
  <front>
    <title>EFF tests agree with AP: Comcast is forging packets to interfere with user traffic</title>
    <author initials="S." surname="Schoen" fullname="Seth Schoen">
      <organization></organization>
    </author>
    <date year="2007"/>
  </front>
</reference>
<reference anchor="VonLohmann-2008" target="https://www.eff.org/deeplinks/2008/08/fcc-rules-against-comcast-bit-torrent-blocking">
  <front>
    <title>FCC Rules Against Comcast for BitTorrent Blocking</title>
    <author initials="F." surname="VonLohmann" fullname="Fred VonLohmann">
      <organization></organization>
    </author>
    <date year="2008"/>
  </front>
</reference>
<reference anchor="Halley-2008" target="https://www.networkworld.com/article/2277316/tech-primers/tech-primers-how-dns-cache-poisoning-works.html">
  <front>
    <title>How DNS cache poisoning works</title>
    <author initials="B." surname="Halley" fullname="Bob Halley">
      <organization></organization>
    </author>
    <date year="2014"/>
  </front>
</reference>
<reference anchor="Zmijewski-2014" target="https://blogs.oracle.com/internetintelligence/turkish-internet-censorship-takes-a-new-turn">
  <front>
    <title>Turkish Internet Censorship Takes a New Turn</title>
    <author initials="E." surname="Zmijewski" fullname="Earl Zmijewski">
      <organization></organization>
    </author>
    <date year="2014"/>
  </front>
</reference>
<reference anchor="AFP-2014" target="http://www.businessinsider.com/chinas-internet-breakdown-reportedly-caused-by-censoring-tools-2014-1">
  <front>
    <title>China Has Massive Internet Breakdown Reportedly Caused By Their Own Censoring Tools</title>
    <author >
      <organization>AFP</organization>
    </author>
    <date year="2014"/>
  </front>
</reference>
<reference anchor="Anon-SIGCOMM12" target="http://www.sigcomm.org/sites/default/files/ccr/papers/2012/July/2317307-2317311.pdf">
  <front>
    <title>The Collateral Damage of Internet Censorship by DNS Injection</title>
    <author >
      <organization>Anonymous</organization>
    </author>
    <date year="2012"/>
  </front>
</reference>
<reference anchor="Albert-2011" target="https://opennet.net/blog/2011/06/dns-tampering-and-new-icann-gtld-rules">
  <front>
    <title>DNS Tampering and the new ICANN gTLD Rules</title>
    <author initials="K." surname="Albert" fullname="Kendra Albert">
      <organization></organization>
    </author>
    <date year="2011"/>
  </front>
</reference>
<reference anchor="Wikip-DoS" target="https://en.wikipedia.org/w/index.php?title=Denial-of-service_attack&amp;oldid=710558258">
  <front>
    <title>Denial of Service Attacks</title>
    <author >
      <organization>Wikipedia</organization>
    </author>
    <date year="2016"/>
  </front>
</reference>
<reference anchor="Schone-2014" target="http://www.nbcnews.com/feature/edward-snowden-interview/exclusive-snowden-docs-show-uk-spies-attacked-anonymous-hackers-n21361">
  <front>
    <title>Snowden Docs Show UK Spies Attacked Anonymous, Hackers</title>
    <author initials="M." surname="Schone" fullname="Mark Schone">
      <organization></organization>
    </author>
    <author initials="R." surname="Esposito" fullname="Richard Esposito">
      <organization></organization>
    </author>
    <author initials="M." surname="Cole" fullname="Matthew Cole">
      <organization></organization>
    </author>
    <author initials="G." surname="Greenwald" fullname="Glenn Greenwald">
      <organization></organization>
    </author>
    <date year="2014"/>
  </front>
</reference>
<reference anchor="CERT-2000" target="http://www.cert.org/historical/advisories/CA-1996-21.cfm">
  <front>
    <title>TCP SYN Flooding and IP Spoofing Attacks</title>
    <author >
      <organization>CERT</organization>
    </author>
    <date year="2000"/>
  </front>
</reference>
<reference anchor="Kravtsova-2012" target="http://www.themoscowtimes.com/news/article/cyberattacks-disrupt-oppositions-election/470119.html">
  <front>
    <title>Cyberattacks Disrupt Opposition's Election</title>
    <author initials="Y." surname="Kravtsova" fullname="Yekaterina Kravtsova">
      <organization></organization>
    </author>
    <date year="2012"/>
  </front>
</reference>
<reference anchor="Villeneuve-2011" target="http://access.opennet.net/wp-content/uploads/2011/12/accesscontested-chapter-08.pdf">
  <front>
    <title>Open Access: Chapter 8, Control and Resistance, Attacks on Burmese Opposition Media</title>
    <author initials="N." surname="Villeneuve" fullname="Nart Villeneuve">
      <organization></organization>
    </author>
    <date year="2011"/>
  </front>
</reference>
<reference anchor="Orion-2013" target="http://www.theinquirer.net/inquirer/news/2287433/zimbabwe-election-hit-by-hacking-and-ddos-attacks">
  <front>
    <title>Zimbabwe election hit by hacking and DDoS attacks</title>
    <author initials="E." surname="Orion" fullname="Egan Orion">
      <organization></organization>
    </author>
    <date year="2013"/>
  </front>
</reference>
<reference anchor="Muncaster-2013" target="http://www.theregister.co.uk/2013/05/09/malaysia_fraud_elections_ddos_web_blocking/">
  <front>
    <title>Malaysian election sparks web blocking/DDoS claims</title>
    <author initials="P." surname="Muncaster" fullname="Phil Muncaster">
      <organization></organization>
    </author>
    <date year="2013"/>
  </front>
</reference>
<reference anchor="Dobie-2007" target="http://news.bbc.co.uk/2/hi/asia-pacific/7016238.stm">
  <front>
    <title>Junta tightens media screw</title>
    <author initials="M." surname="Dobie" fullname="Michael Dobie">
      <organization></organization>
    </author>
    <date year="2007"/>
  </front>
</reference>
<reference anchor="Heacock-2009" target="https://opennet.net/blog/2009/07/china-shuts-down-internet-xinjiang-region-after-riots">
  <front>
    <title>China Shuts Down Internet in Xinjiang Region After Riots</title>
    <author initials="R." surname="Heacock" fullname="Rebekah Heacock">
      <organization></organization>
    </author>
    <date year="2009"/>
  </front>
</reference>
<reference anchor="Cowie-2011" target="https://archive.nanog.org/meetings/nanog51/presentations/Tuesday/LT-Cowie-Egypt%20Leaves%20The%20Internet.pdf">
  <front>
    <title>Egypt Leaves the Internet</title>
    <author initials="J." surname="Cowie" fullname="Jim Cowie">
      <organization></organization>
    </author>
    <date year="2011"/>
  </front>
</reference>
<reference anchor="Thomson-2012" target="http://www.theregister.co.uk/2012/11/29/syria_internet_blackout/">
  <front>
    <title>Syria Cuts off Internet and Mobile Communication</title>
    <author initials="I." surname="Thomson" fullname="Iain Thomson">
      <organization></organization>
    </author>
    <date year="2012"/>
  </front>
</reference>
<reference anchor="BBC-2013b" target="http://www.bbc.com/news/world-asia-china-2439695">
  <front>
    <title>China employs two million microblog monitors state media say</title>
    <author >
      <organization>BBC</organization>
    </author>
    <date year="2013"/>
  </front>
</reference>
<reference anchor="Calamur-2013" target="http://www.npr.org/blogs/thetwo-way/2013/11/29/247820503/prominent-egyptian-blogger-arrested">
  <front>
    <title>Prominent Egyptian Blogger Arrested</title>
    <author initials="K." surname="Calamur" fullname="Krishnadev Calamur">
      <organization></organization>
    </author>
    <date year="2013"/>
  </front>
</reference>
<reference anchor="AP-2012" target="http://www.huffingtonpost.com/2012/12/03/sattar-beheshit-iran_n_2233125.html">
  <front>
    <title>Sattar Beheshit, Iranian Blogger, Was Beaten In Prison According To Prosecutor</title>
    <author >
      <organization>Associated Press</organization>
    </author>
    <date year="2012"/>
  </front>
</reference>
<reference anchor="Hopkins-2011" target="http://readwrite.com/2011/03/03/communications_blocked_in_libya_this_week_in_onlin">
  <front>
    <title>Communications Blocked in Libya, Qatari Blogger Arrested: This Week in Online Tyranny</title>
    <author initials="C." surname="Hopkins" fullname="Curt Hopkins">
      <organization></organization>
    </author>
    <date year="2011"/>
  </front>
</reference>
<reference anchor="Guardian-2014" target="http://www.theguardian.com/world/2014/apr/17/chinese-blogger-jailed-crackdown-internet-rumours-qin-zhihui">
  <front>
    <title>Chinese blogger jailed under crackdown on 'internet rumours'</title>
    <author >
      <organization>The Gaurdian</organization>
    </author>
    <date year="2014"/>
  </front>
</reference>
<reference anchor="Bristow-2013" target="http://news.bbc.co.uk/2/hi/asia-pacific/7783640.stm">
  <front>
    <title>China's internet 'spin doctors‘</title>
    <author initials="M." surname="Bristow" fullname="Michael Bristow">
      <organization></organization>
    </author>
    <date year="2013"/>
  </front>
</reference>
<reference anchor="Fareed-2008" target="http://www.theguardian.com/media/2008/sep/22/chinathemedia.marketingandpr">
  <front>
    <title>China joins a turf war</title>
    <author initials="M." surname="Fareed" fullname="Malik Fareed">
      <organization></organization>
    </author>
    <date year="2008"/>
  </front>
</reference>
<reference anchor="Gao-2014" target="http://www.nytimes.com/2014/06/04/opinion/tiananmen-forgotten.html">
  <front>
    <title>Tiananmen, Forgotten</title>
    <author initials="H." surname="Gao" fullname="Helen Gao">
      <organization></organization>
    </author>
    <date year="2014"/>
  </front>
</reference>
<reference anchor="Murdoch-2011" target="http://access.opennet.net/wp-content/uploads/2011/12/accessdenied-chapter-3.pdf">
  <front>
    <title>Access Denied: Tools and Technology of Internet Filtering</title>
    <author initials="S.J." surname="Murdoch" fullname="Steven J. Murdoch">
      <organization></organization>
    </author>
    <author initials="R." surname="Anderson" fullname="Ross Anderson">
      <organization></organization>
    </author>
    <date year="2011"/>
  </front>
</reference>
<reference anchor="AFNIC-2013" target="http://www.afnic.fr/medias/documents/conseilscientifique/SC-consequences-of-DNS-based-Internet-filtering.pdf">
  <front>
    <title>Report of the AFNIC Scientific Council: Consequences of DNS-based Internet filtering</title>
    <author >
      <organization>AFNIC</organization>
    </author>
    <date year="2013"/>
  </front>
</reference>
<reference anchor="ICANN-SSAC-2012" target="https://www.icann.org/en/system/files/files/sac-056-en.pdf">
  <front>
    <title>SAC 056: SSAC Advisory on Impacts of Content Blocking via the Domain Name System</title>
    <author >
      <organization>ICANN Security and Stability Advisory Committee (SSAC)</organization>
    </author>
    <date year="2012"/>
  </front>
</reference>
<reference anchor="Ding-1999" target="http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.132.3302&amp;rep=rep1&amp;type=pdf">
  <front>
    <title>Centralized Content-Based Web Filtering and Blocking: How Far Can It Go?</title>
    <author initials="C." surname="Ding" fullname="Chen Ding">
      <organization></organization>
    </author>
    <author initials="C.H." surname="Chi" fullname="Chi-Hung Chi">
      <organization></organization>
    </author>
    <author initials="J." surname="Deng" fullname="Jing Deng">
      <organization></organization>
    </author>
    <author initials="C.L." surname="Dong" fullname="Chun-Lei Dong">
      <organization></organization>
    </author>
    <date year="1999"/>
  </front>
</reference>
<reference anchor="Trustwave-2015" target="https://www3.trustwave.com/software/8e6/hlp/r3000/files/1system_filter.html">
  <front>
    <title>Filter: SNI extension feature and HTTPS blocking</title>
    <author >
      <organization>Trustwave</organization>
    </author>
    <date year="2015"/>
  </front>
</reference>
<reference anchor="Sophos-2015" target="https://www.sophos.com/en-us/support/knowledgebase/115865.aspx">
  <front>
    <title>Understanding Sophos Web Filtering</title>
    <author >
      <organization>Sophos</organization>
    </author>
    <date year="2015"/>
  </front>
</reference>
<reference anchor="Shbair-2015" target="https://hal.inria.fr/hal-01202712/document">
  <front>
    <title>Efficiently Bypassing SNI-based HTTPS Filtering</title>
    <author initials="W.M." surname="Shbair" fullname="Wazen M. Shbair">
      <organization></organization>
    </author>
    <author initials="T." surname="Cholez" fullname="Thibault Cholez">
      <organization></organization>
    </author>
    <author initials="A." surname="Goichot" fullname="Antoine Goichot">
      <organization></organization>
    </author>
    <author initials="I." surname="Chrisment" fullname="Isabelle Chrisment">
      <organization></organization>
    </author>
    <date year="2015"/>
  </front>
</reference>
<reference anchor="RSF-2005" target="http://archives.rsf.org/print-blogs.php3?id_article=15013">
  <front>
    <title>Technical ways to get around censorship</title>
    <author >
      <organization>Reporters Sans Frontieres</organization>
    </author>
    <date year="2005"/>
  </front>
</reference>
<reference anchor="Marczak-2015" target="https://www.usenix.org/system/files/conference/foci15/foci15-paper-marczak.pdf">
  <front>
    <title>An Analysis of China’s “Great Cannon”</title>
    <author initials="B." surname="Marczak" fullname="Bill Marczak">
      <organization></organization>
    </author>
    <author initials="N." surname="Weaver" fullname="Nicholas Weaver">
      <organization></organization>
    </author>
    <author initials="J." surname="Dalek" fullname="Jakub Dalek">
      <organization></organization>
    </author>
    <author initials="R." surname="Ensafi" fullname="Roya Ensafi">
      <organization></organization>
    </author>
    <author initials="D." surname="Fifield" fullname="David Fifield">
      <organization></organization>
    </author>
    <author initials="S." surname="McKune" fullname="Sarah McKune">
      <organization></organization>
    </author>
    <author initials="A." surname="Rey" fullname="Arn Rey">
      <organization></organization>
    </author>
    <author initials="J." surname="Scott-Railton" fullname="John Scott-Railton">
      <organization></organization>
    </author>
    <author initials="R." surname="Deibert" fullname="Ron Deibert">
      <organization></organization>
    </author>
    <author initials="V." surname="Paxson" fullname="Vern Paxson">
      <organization></organization>
    </author>
    <date year="2015"/>
  </front>
</reference>
<reference anchor="Fifield-2015" target="https://petsymposium.org/2015/papers/03_Fifield.pdf">
  <front>
    <title>Blocking-resistant communication through domain fronting</title>
    <author initials="D." surname="Fifield" fullname="David Fifield">
      <organization></organization>
    </author>
    <author initials="C." surname="Lan" fullname="Chang Lan">
      <organization></organization>
    </author>
    <author initials="R." surname="Hynes" fullname="Rod Hynes">
      <organization></organization>
    </author>
    <author initials="P." surname="Wegmann" fullname="Percy Wegmann">
      <organization></organization>
    </author>
    <author initials="V." surname="Paxson" fullname="Vern Paxson">
      <organization></organization>
    </author>
    <date year="2015"/>
  </front>
</reference>
<reference anchor="Google-RTBF" target="https://support.google.com/legal/contact/lr_eudpa?product=websearch">
  <front>
    <title>Search removal request under data protection law in Europe</title>
    <author >
      <organization>Google, Inc.</organization>
    </author>
    <date year="2015"/>
  </front>
</reference>
<reference anchor="DMLP-512" target="http://www.dmlp.org/legal-guide/protecting-yourself-against-copyright-claims-based-user-content">
  <front>
    <title>Protecting Yourself Against Copyright Claims Based on User Content</title>
    <author >
      <organization>Digital Media Law Project</organization>
    </author>
    <date year="2012"/>
  </front>
</reference>
<reference anchor="Kopel-2013" target="http://dx.doi.org/doi:10.15779/Z384Q3M">
  <front>
    <title>Operation Seizing Our Sites: How the Federal Government is Taking Domain Names Without Prior Notice</title>
    <author initials="K." surname="Kopel" fullname="Karen Kopel">
      <organization></organization>
    </author>
    <date year="2013"/>
  </front>
</reference>
<reference anchor="Bortzmeyer-2015" target="https://labs.ripe.net/Members/stephane_bortzmeyer/dns-censorship-dns-lies-seen-by-atlas-probes">
  <front>
    <title>DNS Censorship (DNS Lies) As Seen By RIPE Atlas</title>
    <author initials="S." surname="Bortzmeyer" fullname="Stephane Bortzmeyer">
      <organization></organization>
    </author>
    <date year="2015"/>
  </front>
</reference>
<reference anchor="Wang-2017" target="https://www.cs.ucr.edu/~zhiyunq/pub/imc17_censorship_tcp.pdf">
  <front>
    <title>Your State is Not Mine: A Closer Look at Evading Stateful Internet Censorship</title>
    <author initials="Z." surname="Wang" fullname="Zhongjie Wang">
      <organization></organization>
    </author>
    <author initials="Y." surname="Cao" fullname="Yue Cao">
      <organization></organization>
    </author>
    <author initials="Z." surname="Qian" fullname="Zhiyun Qian">
      <organization></organization>
    </author>
    <author initials="C." surname="Song" fullname="Chengyu Song">
      <organization></organization>
    </author>
    <author initials="S." surname="Krishnamurthy" fullname="Srikanth V. Krishnamurthy">
      <organization></organization>
    </author>
    <date year="2017"/>
  </front>
</reference>
<reference anchor="Wang-2020" target="https://www.cs.ucr.edu/~zhiyunq/pub/ndss20_symtcp.pdf">
  <front>
    <title>SYMTCP: Eluding Stateful Deep Packet Inspection with Automated Discrepancy Discovery</title>
    <author initials="Z." surname="Wang" fullname="Zhongjie Wang">
      <organization></organization>
    </author>
    <author initials="S." surname="Zhu" fullname="Shitong Zhu">
      <organization></organization>
    </author>
    <author initials="Y." surname="Cao" fullname="Yue Cao">
      <organization></organization>
    </author>
    <author initials="Z." surname="Qian" fullname="Zhiyun Qian">
      <organization></organization>
    </author>
    <author initials="C." surname="Song" fullname="Chengyu Song">
      <organization></organization>
    </author>
    <author initials="S." surname="Krishnamurthy" fullname="Srikanth V. Krishnamurthy">
      <organization></organization>
    </author>
    <author initials="K." surname="Chan" fullname="Kevin S. Chan">
      <organization></organization>
    </author>
    <author initials="T." surname="Braun" fullname="Tracy D. Braun">
      <organization></organization>
    </author>
    <date year="2020"/>
  </front>
</reference>
<reference anchor="Li-2017" target="https://david.choffnes.com/pubs/liberate-imc17.pdf">
  <front>
    <title>lib•erate, (n) : A library for exposing (traffic-classification) rules and avoiding them efficiently</title>
    <author initials="F." surname="Li" fullname="Fangfan Li">
      <organization></organization>
    </author>
    <author initials="A." surname="Razaghpanah" fullname="Abbas Razaghpanah">
      <organization></organization>
    </author>
    <author initials="A." surname="Kakhki" fullname="Arash Molavi Kakhki">
      <organization></organization>
    </author>
    <author initials="A." surname="Niaki" fullname="Arian Akhavan Niaki">
      <organization></organization>
    </author>
    <author initials="D." surname="Choffnes" fullname="David Choffnes">
      <organization></organization>
    </author>
    <author initials="P." surname="Gill" fullname="Phillipa Gill">
      <organization></organization>
    </author>
    <author initials="A." surname="Mislove" fullname="Alan Mislove">
      <organization></organization>
    </author>
    <date year="2017"/>
  </front>
</reference>
<reference anchor="Bock-2019" target="https://geneva.cs.umd.edu/papers/geneva_ccs19.pdf">
  <front>
    <title>Geneva: Evolving Censorship Evasion Strategies</title>
    <author initials="K." surname="Bock" fullname="Kevin Bock">
      <organization></organization>
    </author>
    <author initials="G." surname="Hughey" fullname="George Hughey">
      <organization></organization>
    </author>
    <author initials="X." surname="Qiang" fullname="Xiao Qiang">
      <organization></organization>
    </author>
    <author initials="D." surname="Levin" fullname="Dave Levin">
      <organization></organization>
    </author>
    <date year="2019"/>
  </front>
</reference>
<reference anchor="Bock-2020" target="https://geneva.cs.umd.edu/papers/evading-censorship-in-depth.pdf">
  <front>
    <title>Detecting and Evading Censorship-in-Depth: A Case Study of Iran’s Protocol Filter</title>
    <author initials="K." surname="Bock" fullname="Kevin Bock">
      <organization></organization>
    </author>
    <author initials="Y." surname="Fax" fullname="Yair Fax">
      <organization></organization>
    </author>
    <author initials="K." surname="Reese" fullname="Kyle Reese">
      <organization></organization>
    </author>
    <author initials="J." surname="Singh" fullname="Jasraj Singh">
      <organization></organization>
    </author>
    <author initials="D." surname="Levin" fullname="Dave Levin">
      <organization></organization>
    </author>
    <date year="2020"/>
  </front>
</reference>
<reference anchor="Bock-2020b" target="https://geneva.cs.umd.edu/posts/china-censors-esni/esni/">
  <front>
    <title>Exposing and Circumventing China's Censorship of ESNI</title>
    <author initials="K." surname="Bock" fullname="Kevin Bock">
      <organization></organization>
    </author>
    <author initials="." surname="iyouport" fullname="iyouport">
      <organization></organization>
    </author>
    <author initials="." surname="Anonymous" fullname="Anonymous">
      <organization></organization>
    </author>
    <author initials="L." surname="Merino" fullname="Louis-Henri Merino">
      <organization></organization>
    </author>
    <author initials="D." surname="Fifield" fullname="David Fifield">
      <organization></organization>
    </author>
    <author initials="A." surname="Houmansadr" fullname="Amir Houmansadr">
      <organization></organization>
    </author>
    <author initials="D." surname="Levin" fullname="Dave Levin">
      <organization></organization>
    </author>
    <date year="2020"/>
  </front>
</reference>
<reference anchor="Rambert-2021" target="https://www.andrew.cmu.edu/user/nicolasc/publications/Rambert-WWW21.pdf">
  <front>
    <title>Chinese Wall or Swiss Cheese? Keyword filtering in the Great Firewall of China</title>
    <author initials="R." surname="Rampert" fullname="Raymond Rampert">
      <organization></organization>
    </author>
    <author initials="Z." surname="Weinberg" fullname="Zachary Weinberg">
      <organization></organization>
    </author>
    <author initials="D." surname="Barradas" fullname="Diogo Barradas">
      <organization></organization>
    </author>
    <author initials="N." surname="Christin" fullname="Nicolas Christin">
      <organization></organization>
    </author>
    <date year="2021"/>
  </front>
</reference>
<reference anchor="Knockel-2021" target="https://dl.acm.org/doi/10.1145/3473604.3474560">
  <front>
    <title>Measuring QQMail's automated email censorship in China</title>
    <author initials="J." surname="Knockel" fullname="Jeffery Knockel">
      <organization></organization>
    </author>
    <author initials="L." surname="Ruan" fullname="Lotus Ruan">
      <organization></organization>
    </author>
    <date year="2021"/>
  </front>
</reference>
<reference anchor="Bock-2021" target="https://geneva.cs.umd.edu/papers/woot21-weaponizing-availability.pdf">
  <front>
    <title>Your Censor is My Censor: Weaponizing Censorship Infrastructure for Availability Attacks</title>
    <author initials="K." surname="Bock" fullname="Kevin Bock">
      <organization></organization>
    </author>
    <author initials="P." surname="Bharadwaj" fullname="Pranav Bharadwaj">
      <organization></organization>
    </author>
    <author initials="J." surname="Singh" fullname="Jasraj Singh">
      <organization></organization>
    </author>
    <author initials="D." surname="Levin" fullname="Dave Levin">
      <organization></organization>
    </author>
    <date year="2021"/>
  </front>
</reference>
<reference anchor="Bock-2021b" target="https://geneva.cs.umd.edu/papers/foci21.pdf">
  <front>
    <title>Even Censors Have a Backup: Examining China’s Double HTTPS Censorship Middleboxes</title>
    <author initials="K." surname="Bock" fullname="Kevin Bock">
      <organization></organization>
    </author>
    <author initials="G." surname="Naval" fullname="Gabriel Naval">
      <organization></organization>
    </author>
    <author initials="K." surname="Reese" fullname="Kyle Reese">
      <organization></organization>
    </author>
    <author initials="D." surname="Levin" fullname="Dave Levin">
      <organization></organization>
    </author>
    <date year="2021"/>
  </front>
</reference>
<reference anchor="Satija-2021" target="https://sambhav.info/files/blindtls-foci21.pdf">
  <front>
    <title>BlindTLS: Circumventing TLS-based HTTPS censorship</title>
    <author initials="S." surname="Satija" fullname="Sambhav Satija">
      <organization></organization>
    </author>
    <author initials="R." surname="Chatterjee" fullname="Rahul Chatterjee">
      <organization></organization>
    </author>
    <date year="2021"/>
  </front>
</reference>
<reference anchor="Elmenhorst-2021" target="https://dl.acm.org/doi/pdf/10.1145/3487552.3487836">
  <front>
    <title>Web Censorship Measurements of HTTP/3 over QUIC</title>
    <author initials="K." surname="Elmenhorst" fullname="Kathrin Elmenhorst">
      <organization></organization>
    </author>
    <author initials="B." surname="Schuetz" fullname="Bertram Schuetz">
      <organization></organization>
    </author>
    <author initials="S." surname="Basso" fullname="Simone Basso">
      <organization></organization>
    </author>
    <author initials="N." surname="Aschenbruck" fullname="Nils Aschenbruck">
      <organization></organization>
    </author>
    <date year="2021"/>
  </front>
</reference>
<reference anchor="Elmenhorst-2022" target="https://www.opentech.fund/news/a-quick-look-at-quic/">
  <front>
    <title>A Quick Look at QUIC Censorship</title>
    <author initials="K." surname="Elmenhorst" fullname="Kathrin Elmenhorst">
      <organization></organization>
    </author>
    <date year="2022"/>
  </front>
</reference>
<reference anchor="Gilad" target="https://doi.org/10.1145/2597173">
  <front>
    <title>Off-Path TCP Injection Attacks</title>
    <author initials="Y." surname="Gilad" fullname="Yossi Gilad">
      <organization></organization>
    </author>
    <author initials="A." surname="Herzberg" fullname="Amir Herzberg">
      <organization></organization>
    </author>
    <date year="2014"/>
  </front>
</reference>
<reference anchor="MANRS" target="https://www.manrs.org/2022/03/lesson-learned-twitter-shored-up-its-routing-security/">
  <front>
    <title>Lesson Learned: Twitter Shored Up Its Routing Security</title>
    <author initials="A." surname="Siddiqui" fullname="Aftab Siddiqui">
      <organization></organization>
    </author>
    <date year="2022"/>
  </front>
</reference>
<reference anchor="Google-2018" target="https://status.cloud.google.com/incident/cloud-networking/18018">
  <front>
    <title>Google Cloud Networking Incident #18018</title>
    <author >
      <organization></organization>
    </author>
    <date year="2018"/>
  </front>
</reference>


    </references>



  </back>
</rfc>

