<?xml version="1.0" encoding="utf-8"?>

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-irtf-pearg-censorship-10" number="9505" submissionType="IRTF"  category="info" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" updates="" obsoletes="" xml:lang="en" version="3">

  <front>
    <title abbrev="Survey of Censorship Techniques">A Survey of Worldwide Censorship Techniques</title>
    <seriesInfo name="RFC" value="9505"/>
    <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/>
      <address>
        <email>amelia.ietf@andersdotter.cc</email>
      </address>
    </author>
    <author initials="B." surname="Jones" fullname="Ben Jones">
      <organization/>
      <address>
        <email>ben.jones.irtf@gmail.com</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="2023" month="November"/>
    <workgroup>Privacy Enhancements and Assessments</workgroup>
    <keyword>network censorship</keyword>
    <keyword>network blocking</keyword>
    <keyword>network throttling</keyword>
    <keyword>traffic impairment</keyword>
    <keyword>censorship circumvention</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. This document is a product of
      the Privacy Enhancement and Assessment Research Group (PEARG) in the
      IRTF.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro">
      <name>Introduction</name>
      <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, or
      inconvenient <xref target="WP-Def-2020"/>. Although censors that engage
      in censorship must do so through legal, martial, 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 trade-offs in relation to
      such costs in conjunction with each technical method identified
      below.</t>
      <t>This document has seen extensive discussion and review in the IRTF
      Privacy Enhancement and Assessment Research Group (PEARG) and represents
      the consensus of that group. It is not an IETF product and is not a
      standard.</t>
    </section>
    <section anchor="terms">
      <name>Terminology</name>
      <t>We describe three elements of Internet censorship: prescription,
      identification, and interference. This 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 "www.sex.example" are likely to be undesirable.
      Interference is the process by which censors intercede in communication
      and prevent 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">
      <name>Technical Prescription</name>
      <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, databases of image hashes <xref
      target="ekr-2021"/>, 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 area in the effort to
      identify content deemed as morally or commercially harmful to companies
      or consumers in some jurisdictions <xref target="SIDN-2020"/>.</t>
      <t>There are typically a few types of blocklist elements: keyword, domain
name, protocol, or IP address. Keyword and domain name
blocking take place at the application level, e.g., HTTP; protocol blocking
often occurs using deep packet inspection (DPI) 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,
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 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, the Ministry of
Culture and Islamic Guidance in Iran, and the organizations specific to copyright law in France <xref target="HADOPI"/>
and consumer protection law across the EU <xref target="Reda-2017"/>.</t>
      <t>Content-layer filtering of images and video requires institutions or
      organizations to store hashes of images or videos to be blocked in
      databases, which can then be compared, with some degree of tolerance, to
      content that is sent, received, or stored using centralized content
      applications and services <xref target="ekr-2021"/>.</t>
    </section>
    <section anchor="tech-id">
      <name>Technical Identification</name>
      <section anchor="poc">
        <name>Points of Control</name>
        <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 ecosystem (e.g., domain name system (DNS) or certificate
        authorities (CAs)), 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 that censors may use for interception mechanisms,
        including, though not limited to, the following:</t>
        <dl spacing="normal" newline="true">
          <dt>Internet Backbone:</dt>
	  <dd>If a censor controls elements of Internet network
	  infrastructure, such as the international gateways into a region or
	  Internet Exchange Points (IXPs), those choke points can be used to filter
	  undesirable traffic that is traveling into and out of the region by
	  packet sniffing and port mirroring.  Censorship at gateways 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, which would
	  have to be accomplished at exchange points or other network
	  aggregation points. Some national network designs naturally serve as
	  more effective choke points and points of control <xref
	  target="Leyba-2019"/>.</dd>
          <dt>Internet Service Providers (ISPs):</dt>
	  <dd>ISPs 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.</dd>
          <dt>Institutions:</dt>
	  <dd>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 schoolchildren, independent of
	  broader society or government goals.</dd>
          <dt>Content Distribution Network (CDN):</dt>
	  <dd>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 QoS. 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 repositories allows for easier
	  interference.</dd>

          <dt>CAs for Public Key Infrastructures (PKIs):</dt>
	  <dd>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 or Local
	  Internet Registries (RIRs or LIRs) that issue Route Origin
	  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 it may
	  not have been possible before. CAs may also be forced to revoke
	  certificates. This may lead to adversarial traffic routing, TLS
	  interception being allowed, or an otherwise rightful origin or
	  destination point of traffic flows being unable to communicate in a
	  secure way.</dd>
          <dt>Services:</dt>
	  <dd>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 discussions of moral
	  imperatives to use censorship tools.</dd>
          <dt>Content Sites:</dt>
	  <dd>On the service side of communications lie many platforms that
	  publish user-generated content and 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.</dd>
          <dt>Personal Devices:</dt>
	  <dd>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 has exacerbated these feasibility problems. This
	  software can also be mandated by institutional actors acting on
	  non-governmentally mandated moral imperatives.</dd>
        </dl>
        <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 Sections <xref
        target="http-req" format="counter"/> and <xref target="http-resp"
        format="counter"/>). For example, a subversive image might make it
        past a keyword filter. However, if later the image is deemed
        undesirable, a censor may then blocklist the provider site's IP
        address.</t>
      </section>
      <section anchor="app-layer">
        <name>Application Layer</name>
        <t>The following subsections describe properties and trade-offs 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">
          <name>HTTP Request Header Identification</name>
          <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 (for example, 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>Trade-offs: HTTP request header identification is a technically
	  straightforward 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 (Hypertext
	  Transport Protocol Secure) 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 and/or 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-2013"/>. Commercial technologies are often purchased
          by censors <xref target="Dalek-2013"/>.  These commercial
          technologies use a combination of HTTP request header 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">
          <name>HTTP Response Header Identification</name>
          <t>While HTTP request header identification relies on the information
contained in the HTTP request from client to server, HTTP response header
identification uses information sent in response by the server to
client to identify undesirable content.</t>
          <t>Trade-offs: 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"/>), it is likely that most censors rely on keyword
filtering over TCP streams instead of HTTP response filtering.</t>
        </section>
        <section anchor="tls">
          <name>Transport Layer Security (TLS)</name>
          <t>Similar to HTTP, censors have deployed a variety of techniques
          towards censoring TLS (and by extension
          HTTPS). Most of these techniques relate to the Server Name
          Indication (SNI) field, including censoring SNI, Encrypted SNI (ESNI), 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">
            <name>Server Name Indication (SNI)</name>
            <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 ClientHello message which
            domain name it seeks to connect to (so that the server can respond
            with the appropriate TLS certificate) using, the SNI TLS extension
            <xref target="RFC6066"/>.  The ClientHello message is unencrypted
            for TCP-based TLS.  When using QUIC, the ClientHello 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 ongoing standardization efforts
            in the TLS Working Group to encrypt SNI <xref target="RFC8744"/>
            <xref target="I-D.ietf-tls-esni"/>, and recent research shows
            promising results in the use of ESNI 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>Trade-offs: 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 (DPI)
            techniques that can be
            expensive in terms of computational complexity and infrastructure, especially when applied to QUIC where DPI requires key
            extraction and decryption of the ClientHello in order to read the
            SNI. Improper configuration of an SNI-based block can result in
            significant over-blocking, e.g., when a second-level domain like
            "populardomain.example" is inadvertently blocked. In the case of
            ESNI, 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-2023"/> <xref
            target="Shbair-2015"/>. The governments of China, Egypt, Iran,
            Qatar, South Korea, Turkey, Turkmenistan, and the United Arab Emirates 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 was first
            observed in Russia in March 2022 <xref
            target="Elmenhorst-2022"/>.</t>
          </section>
          <section anchor="esni">
            <name>Encrypted SNI (ESNI)</name>
            <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 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 over-blocking for the censor but can be
            worth the cost if ESNI is not yet widely deployed within the
            country.  ECH is the emerging standard for protecting the entire
            TLS ClientHello, but it is not yet widely deployed.</t>
            <t>Trade-offs: The cost to censoring 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
            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">
            <name>Omitted SNI</name>
            <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>Trade-offs: 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">
            <name>Server Response Certificate</name>
            <t>During the TLS handshake after the TLS ClientHello, 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>Trade-offs: Censoring based on the server certificate requires DPI 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 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">
          <name>Instrumenting Content Distributors</name>
          <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 websites to
          storage to locally installed programs.</t>
          <t>A commonly
used method of instrumenting content distributors consists of keyword
identification to detect restricted terms on their platforms. Governments
may provide the terms on such keyword lists. Alternatively, the content
provider may be expected to come up with their own list.</t>
          <t>An increasingly common method of instrumenting content distribution consists of hash matching to detect and take action against images and videos known to be restricted either by governments, institutions, organizations or the distributor themselves <xref target="ekr-2021"/>.</t>
          <t>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>Trade-offs: 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 websites 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 trade-offs 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 page 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-2014"/> <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 the
          U.K. to help combat abuse <xref target="BBC-2013"/> <xref
          target="Condliffe-2013"/>.  European Union law, as well as United States 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-2014"/> 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 Catalan 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">
          <name>DPI Identification</name>
          <t>DPI 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 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 (IDSs) configured for
          censorship.</t>
          <t>Trade-offs: DPI is one of the most expensive identification
          mechanisms and can have a large QoS impact <xref
          target="Porter-2005"/>.  When used as a keyword filter for TCP
          flows, DPI systems can cause also major over-blocking 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 to 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 that are not so worried about
          blocking content in real time could use DPI to sort and
          categorically search gathered traffic using technologies such as
          high-speed packet processing <xref target="Hepting-2011"/>.</t>
        </section>
      </section>
      <section anchor="transport">
        <name>Transport Layer</name>
        <section anchor="sec_thid">
          <name>Shallow Packet Inspection and Transport Header Identification</name>
          <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
          do they allow a censor to block undesirable content via IP
          blocklisting but also allow 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>By 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 in some routers, 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
          over-blocking and cannot deal with some services like Content
          Distribution Networks (CDNs) 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 counterexample is that port 25 (SMTP) has long been
          blocked on residential ISP networks to reduce the risk of email
          spam, but doing this also prohibits residential ISP customers from
          running their own email servers.</t>
        </section>
        <section anchor="prot-id">
          <name>Protocol Identification</name>
          <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-2013"/>. A simple protocol
          identification would be to recognize all TCP traffic over port 443
          as HTTPS, but a 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-2015"/>.</t>
          <t>If censors can detect circumvention tools, they can block
          them. Therefore, censors like China are extremely interested in
          identifying the protocols for censorship circumvention tools. In
          recent years, this has devolved into a competition between censors
          and circumvention tool developers. As part of this competition,
          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 the 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 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 Voice over IP (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 are 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. However, 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 Secure Shell (SSH) protocol traffic to make
          it unusable <xref target="Van-der-Sar-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
          (injection of a TCP RST packet into the stream) 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">
        <name>Residual Censorship</name>
        <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, 
        server port), or 4-tuple (client IP, client port, server IP, 
        server 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">
      <name>Technical Interference</name>
      <section anchor="application-layer">
        <name>Application Layer</name>
        <section anchor="dns-mangling">
          <name>DNS Interference</name>
          <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, or lying by
the name server.</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. Some Chinese networks, for
          example, do this. (We are not aware of any other wide-scale uses of
          mangling.) On those Chinese networks, each 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>

          <sourcecode><![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
]]></sourcecode>

          <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-2013"/>.</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 an 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 an active pervasive attacker
          <xref target="RFC7624"/> to rewrite DNS responses) for the mechanism
          to be effective. DNS interference 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. For example, over HTTP, 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 censor's 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 is 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 or recursive resolver validates.</t>
          <t>Previously, techniques were used for 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, including Twitter and YouTube, for almost a week in March
          of 2014. The ease of circumvention resulted in an increase in the
          popularity of Twitter until Turkish ISPs implemented 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, Turkey,
          and the United States have discussed blocking entire Top-Level
          Domains (TLDs) as well <xref target="Albert-2011"/>. DNS blocking is
          commonly deployed in European countries to deal with undesirable
          content, such as</t>
	  <ul>
	    <li>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"/>),</li>
	    <li>online
            gambling (Belgium, Bulgaria, Czech Republic, Cyprus, Denmark,
            Estonia, France, Greece, Hungary, Italy, Latvia, Lithuania, Poland,
            Portugal, Romania, Slovakia, Slovenia, and Spain (see Section 6.3.2
            of <xref target="EC-gambling-2012"/>, <xref target="EC-gambling-2019"/>)),</li>
	    <li>copyright infringement (all European Economic Area countries),</li>
	    <li>hate speech and extremism (France <xref target="Hertel-2015"/>), and</li>
	    <li>terrorism content (France <xref target="Hertel-2015"/>).</li>
	  </ul>
        </section>
      </section>
      <section anchor="transport-layer">
        <name>Transport Layer</name>
        <section anchor="performance-degradation">
          <name>Performance Degradation</name>
          <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 to 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-2013"/>.</t>
        </section>
        <section anchor="packet-dropping">
          <name>Packet Dropping</name>
          <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 subdomain; 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 almost 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 timeout requests it leaves in its
          wake. The Great Firewall of China has been observed using packet
          dropping as one of its primary technical censorship mechanisms <xref
          target="Ensafi-2013"/>. Iran has also used packet dropping as the
          mechanism for throttling SSH <xref target="Aryan-2013"/>. 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 to date (e.g.,
          in India, Iran, Russia, and Uganda <xref target="Elmenhorst-2021"/>
          <xref target="Elmenhorst-2022"/>).</t>
        </section>
        <section anchor="rst-inject">
          <name>RST Packet Injection</name>
          <t>Packet injection, generally, refers to a machine-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 a
          TCP connection know the other side has stopped sending information
          and that 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 set up. 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
          difficult 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="RFC9000"/> 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 QoS bottleneck that 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 machine-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 endpoint accepts a RST packet as
          legitimate; this generally implies a correct IP, port, and TCP
          sequence number. 

	  The sequence number is the hardest to get correct, as <xref target="RFC9293"/> specifies that a RST packet should be in sequence to be
	  accepted, although that RFC also recommends allowing in-window packets. 
	  This in-window
          recommendation is important; 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"/>, subsequently
          leading 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">
        <name>Routing Layer</name>
        <section anchor="discon">
          <name>Network Disconnection</name>
          <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 entity
withdraws all of the Border Gateway Protocol (BGP) prefixes routing
through the censor's country.</t>
          <t>Trade-offs: The impact of a network disconnection in a region is huge
and absolute; the censor pays for absolute control over digital
information by losing the benefits a globally accessible Internet brings. Network disconnections are also politically expensive as citizens accustomed to accessing Internet platforms and services see such disconnections as a loss of civil liberty. 
Network disconnection is rarely a long-term solution for any censor and is normally only used
as a last resort in times of substantial civil unrest in a country.</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 when the junta in Myanmar employed
          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 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 saw the largest number of Internet
          shutdowns per year in 2016 and 2017 <xref target="Dada-2017"/>.</t>
        </section>
        <section anchor="advroute">
          <name>Adversarial Route Announcement</name>
          <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 that 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, but leaks within a jurisdiction can only be corrected by an ISP/IXP 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 Google 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="Siddiqui-2022"/>.</t>
        </section>
      </section>
      <section anchor="multi-layer-and-non-layer">
        <name>Multi-layer and Non-layer</name>
        <section anchor="ddos">
          <name>Distributed Denial of Service (DDoS)</name>
          <t>Distributed Denial of Service attacks are a common attack
          mechanism used by "hacktivists" and malicious hackers. Censors have
          also used DDoS in the past for a variety of reasons. There is a wide
          variety of DDoS attacks <xref target="Wikip-DoS"/>. However, at a
          high level, two possible impacts from the attack tend to occur: a
          flood attack results in the service being unusable while resources
          are being spent to flood the service, and 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 (not just regional access) to undesirable content
   for a limited period of time. Temporal impermanence is really the only uniquely
 beneficial feature of DDoS as a technique employed for censorship. The resources required to carry
          out a successful DDoS against major targets are computationally
          expensive, usually requiring rental or ownership of a malicious
          distributed platform such as a botnet, and they are 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 signals intelligence organization, the Government Communications Headquarters (GCHQ), used DDoS to temporarily
shutdown Internet Relay Chat (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="NBC-2014"/> <xref target="CERT-2000"/>. Dissenting opinion websites are
frequently victims of DDoS around politically sensitive events like the DDoS 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 (dubbed "Great Cannon"),
collocated with the Great Firewall, 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">
          <name>Censorship in Depth</name>
          <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 that 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">
      <name>Non-technical Interference</name>
      <section anchor="manualfiltering">
        <name>Manual Filtering</name>
        <t>As the name implies, sometimes manual labor 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 on its own or
        combined with other automated techniques of detection that are then
        followed by an action that would require manual confirmation. This
        filtration can occur on the backbone or 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.  ICPs,
        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">
        <name>Self-Censorship</name>
        <t>Self-censorship is difficult to document as it manifests primarily
        through a lack of undesirable content. Tools that encourage
        self-censorship may lead a prospective speaker to believe that
        speaking increases the risk of unfavorable 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="RWB-2020"/>.</t>
      </section>
      <section anchor="serverko">
        <name>Server Takedown</name>
        <t>As mentioned in passing by <xref target="Murdoch-2008"/>, 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">
        <name>Notice and Takedown</name>
        <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">
        <name>Domain Name Seizures</name>
        <t>Domain names are catalogued in 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 that
        registered the domain name through a legal procedure grounded in
        either private contracts or public law. Domain name seizure is
        increasingly used by both public authorities and private entities to
        deal with undesired content dissemination <xref target="ICANN-2012"/>
        <xref target="EFF-2017"/>.</t>
      </section>
    </section>
    <section anchor="future-work">
      <name>Future Work</name>
      <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 better specification of censorship
      circumvention techniques themselves. Censor 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 countermeasure against some forms of censorship described
      in this document, but that thorough research on circumvention and
      encryption is left for another document. Moreover, the censorship
      circumvention community has developed an area of research on "pluggable
      transports," which collect, document, and make 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-2019"/>. 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>    
      <name>IANA Considerations</name>
      <t>
	This document has no IANA actions.
      </t>
    </section>
    <section>    
      <name>Security Considerations</name>
      <t>
	This document is a survey of existing literature on network censorship
	techniques. As such, it does not introduce any new security
	considerations to be taken into account beyond what is already
	discussed in each paper surveyed.
      </t>
    </section>

  </middle>
  <back>

<displayreference target="I-D.ietf-tls-esni" to="TLS-ESNI"/>

    <references>

      <name>Informative References</name>

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7754.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7624.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6066.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8484.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7858.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8744.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9293.xml"/>

<!-- [I-D.ietf-tls-esni] IESG state I-D Exists -->

<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-tls-esni.xml"/>


      <reference anchor="RWB-2020" 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 (RSF)</organization>
          </author>
	  <date month="April" year="2020"/>
        </front>
      </reference>

      <reference anchor="HADOPI" target="https://www.hadopi.fr/">
        <front>
          <title>Hadopi | Haute Autorité pour la diffusion des oeuvres et la protection des droits sur internet</title>
          <author>
            <organization>Hadopi</organization>
          </author>
        </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
            (SSAC)</organization>
          </author>
          <date month="March" year="2020"/>
        </front>
      </reference>

      <reference anchor="ICANN-2012" 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 month="January" year="2012"/>
        </front>
      </reference>

      <reference anchor="Tor-2019" target="https://2019.www.torproject.org/docs/pluggable-transports.html.en">
        <front>
          <title>Tor: Pluggable Transports</title>
          <author>
            <organization>Tor</organization>
          </author>
	  <date year="2019"/>
        </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</organization>
          </author>
          <date month="March" 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 Accompanying the document Communication from the Commission to the European Parliament, the Council, the Economic and Social Committee and the Committee of the Regions Towards a comprehensive framework for online gambling</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 channelling demand towards controlled offers</title>
          <author>
            <organization>European Commission</organization>
          </author>
          <date month="January" 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 month="January" year="2012"/>
        </front>
     </reference>

      <reference anchor="Reda-2017" target="https://felixreda.eu/2017/11/eu-website-blocking/">
        <front>
          <title>New EU law prescribes website blocking in the name of "consumer protection"</title>
          <author initials="F." surname="Reda" fullname="Felix Reda">
            <organization/>
          </author>
          <date month="November" 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/>
          </author>
          <date month="June" year="2005"/>
        </front>
      </reference>

      <reference anchor="SIDN-2020" 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/>
          </author>
          <date month="February" 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/>
          </author>
          <date month="February" year="2019"/>
        </front>
      </reference>

      <reference anchor="Hertel-2015" quoteTitle="false" 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" [How authorities can block a website]</title>
          <author initials="O." surname="Hertel" fullname="Olivier Hertel">
            <organization/>
          </author>
          <date month="March" year="2015"/>
        </front>
      </reference>

<reference anchor="Eneman-2010" target="https://www.tandfonline.com/doi/abs/10.1080/13552601003760014">
        <front>
          <title>Internet service provider (ISP) filtering of child-abusive material: A critical reflection of its effectiveness</title>
          <author initials="M." surname="Eneman" fullname="Marie Eneman">
            <organization/>
          </author>
          <date month="June" year="2010"/>
        </front>
	<seriesInfo name="DOI" value="10.1080/13552601003760014"/>
      </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/>
          </author>
          <date month="February" 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/>
          </author>
          <date month="October" 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/>
          </author>
          <date month="October" year="2019"/>
        </front>
	<refcontent>The New York Times</refcontent>
      </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/>
          </author>
          <date month="November" year="2008"/>
        </front>
        <refcontent>The Guardian</refcontent>
      </reference>

      <reference anchor="EFF-2017" 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/>
          </author>
          <author initials="G." surname="Rossi" fullname="Gus Rossi">
            <organization/>
          </author>
          <author initials="M." surname="Stoltz" fullname="Mitch Stoltz">
            <organization/>
          </author>
          <date month="July" year="2017"/>
        </front>
	<refcontent>Electronic Frontier Foundation</refcontent>
      </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/>
          </author>
          <author initials="S." surname="Afroz" fullname="Sadia Afroz">
            <organization/>
          </author>
          <author fullname="Anonymous">
            <organization/>
          </author>
          <author initials="V." surname="Paxson" fullname="Vern Paxson">
            <organization/>
          </author>
          <date month="May" year="2016"/>
        </front>
	<seriesInfo name="DOI" value="10.1109/SP.2016.59"/>
      </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/>
          </author>
          <author initials="Z." surname="Qian" fullname="Zhiyun Qian">
            <organization/>
          </author>
          <author initials="Z." surname="Wang" fullname="Zhongjie Wang">
            <organization/>
          </author>
          <author initials="T." surname="Dao" fullname="Tuan Dao">
            <organization/>
          </author>
          <author initials="S." surname="Krishnamurthy" fullname="Srikanth V. Krishnamurthy">
            <organization/>
          </author>
          <author initials="L." surname="Marvel" fullname="Lisa M. Marvel">
            <organization/>
          </author>
          <date month="August" year="2016"/>
        </front>
      </reference>

      <reference anchor="Leyba-2019">
        <front>
          <title>Borders and gateways: measuring and analyzing national as chokepoints</title>
          <author initials="K." surname="Leyba" fullname="Kirtus G. Leyba">
            <organization/>
          </author>
          <author initials="B." surname="Edwards" fullname="Benjamin Edwards">
            <organization/>
          </author>
          <author initials="C." surname="Freeman" fullname="Cynthia Freeman">
            <organization/>
          </author>
          <author initials="J." surname="Crandall" fullname="Jedidiah R. Crandall">
            <organization/>
          </author>
          <author initials="S." surname="Forrest" fullname="Stephanie Forrest">
            <organization/>
          </author>
          <date month="July" year="2019"/>
        </front>
	<seriesInfo name="DOI" value="10.1145/3314344.3332502"/>
	<refcontent>COMPASS '19: Proceedings of the 2nd ACM SIGCAS Conference on Computing and Sustainable Societies, pages 184-194</refcontent>
      </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/>
          </author>
          <author initials="A." surname="Ghafari" fullname="Amirhossein Ghafari">
            <organization/>
          </author>
          <author initials="A." surname="Houmansadr" fullname="Amir Houmansadr">
            <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/>
          </author>
          <author initials="N." surname="Borisov" fullname="Nikita Borisov">
            <organization/>
          </author>
          <date month="July" year="2019"/>
        </front>
	<seriesInfo name="DOI" value="10.1145/3340301.3341133"/>
	<refcontent>Proceedings of the Applied Networking Research Workshop, Pages 45-51</refcontent>
      </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/>
          </author>
          <author initials="Y." surname="Breindl" fullname="Yana Breindl">
            <organization/>
          </author>
          <date month="April" year="2013"/>
        </front>
	<seriesInfo name="DOI" value="10.14763/2013.2.122"/>
      </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/>
          </author>
          <author initials="K." surname="Singh" fullname="Kushagra Singh">
            <organization/>
          </author>
          <author initials="E." surname="Hickok" fullname="Elonnai Hickok" role="editor">
            <organization/>
          </author>
          <date month="November" 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/>
          </author>
          <author initials="G." surname="Grover" fullname="Gurshabad Grover">
            <organization/>
          </author>
          <author initials="V." surname="Bansal" fullname="Varun Bansal">
            <organization/>
          </author>
          <date month="December" year="2019"/>
        </front>
	<seriesInfo name="DOI" value="10.48550/arXiv.1912.08590"/>
      </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/>
          </author>
          <author initials="J." surname="Sherman" fullname="Justin Sherman">
            <organization/>
          </author>
          <author initials="S." surname="Nam" fullname="Seonghyun Nam">
            <organization/>
          </author>
          <date month="March" 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/>
          </author>
          <author initials="J." surname="Dalek" fullname="Jakub Dalek">
            <organization/>
          </author>
          <author initials="S." surname="McKune" fullname="Sarah McKune">
            <organization/>
          </author>
          <author initials="A." surname="Senft" fullname="Adam Senft">
            <organization/>
          </author>
          <author initials="J." surname="Scott-Railton" fullname="John Scott-Railton">
            <organization/>
          </author>
          <author initials="R." surname="Deibert" fullname="Ron Deibert">
            <organization/>
          </author>
          <date month="March" 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/>
          </author>
          <author initials="A." surname="Filastò" fullname="Arturo Filastò">
            <organization/>
          </author>
          <author initials="M." surname="Xynou" fullname="Maria Xynou">
            <organization/>
          </author>
          <date month="May" 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/>
          </author>
          <date month="February" 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/>
          </author>
          <author initials="P." surname="Micek" fullname="Peter Micek">
            <organization/>
          </author>
          <date month="September" 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/>
          </author>
          <author initials="M." surname="Gupta" fullname="Minaxi Gupta">
            <organization/>
          </author>
          <date month="August" 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/>
          </author>
          <date month="August" 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/>
          </author>
          <date month="December" year="2016"/>
        </front>
      </reference>

      <reference anchor="Aryan-2013" 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/>
          </author>
          <author initials="H." surname="Aryan" fullname="Homa Aryan">
            <organization/>
          </author>
          <author initials="J. A." surname="Halderman" fullname="J. Alex Halderman">
            <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="Husák" fullname="Martin Husák">
            <organization/>
          </author>
          <author initials="M." surname="Čermák" fullname="Milan Čermák">
            <organization/>
          </author>
          <author initials="T." surname="Jirsík" fullname="Tomáš Jirsík">
            <organization/>
          </author>
          <author initials="P." surname="Čeleda" fullname="Pavel Čeleda">
            <organization/>
          </author>
          <date month="February" year="2016"/>
        </front>
	<seriesInfo name="DOI" value="10.1186/s13635-016-0030-7"/>
      </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/>
          </author>
          <author initials="B." surname="Haselton" fullname="Benett Haselton">
            <organization/>
          </author>
          <author initials="H." surname="Noman" fullname="Helmi Noman">
            <organization/>
          </author>
          <author initials="A." surname="Senft" fullname="Adam Senft">
            <organization/>
          </author>
          <author initials="M." surname="Crete-Nishihata" fullname="Masashi Crete-Nishihata">
            <organization/>
          </author>
          <author initials="P." surname="Gill" fullname="Phillipa Gill">
            <organization/>
          </author>
          <author initials="R. J." surname="Deibert" fullname="Ronald J. Deibert">
            <organization/>
          </author>
          <date month="October" year="2013"/>
        </front>
	<seriesInfo name="DOI" value="10.1145/2504730.2504763"/>
	<refcontent>IMC '13: Proceedings of the 2013 conference on Internet measurement conference, Pages 23-30</refcontent>
      </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/>
          </author>
          <author initials="T-W." surname="Lee" fullname="Tzu-Wen Lee">
            <organization/>
          </author>
          <author initials="N." surname="Feamster" fullname="Nick Feamster">
            <organization/>
          </author>
          <author initials="P." surname="Gill" fullname="Phillipa Gill">
            <organization/>
          </author>
          <date month="November" year="2014"/>
        </front>
	<seriesInfo name="DOI" value="10.1145/2663716.2663722"/>
	<refcontent>IMC '14: Proceedings of the 2014 Conference on Internet
	Measurement Conference, Pages 299-304</refcontent>
      </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.C." surname="Park" fullname="Jong Chun Park">
            <organization/>
          </author>
          <author initials="J." surname="Crandall" fullname="Jedediah Crandall">
            <organization/>
          </author>
          <date month="June" 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="" surname="" fullname="">
            <organization/>
          </author>
          <author initials="M." surname="Crete-Nishihata" fullname="Masashi Crete-Nishihata">
            <organization/>
          </author>
          <author initials="J." surname="Dalek" fullname="Jakub Dalek">
            <organization/>
          </author>
          <author initials="S." surname="Hardy" fullname="Seth Hardy">
            <organization/>
          </author>
          <author initials="A." surname="Hilts" fullname="Andrew Hilts">
            <organization/>
          </author>
          <author initials="K." surname="Kleemola" fullname="Katie Kleemola">
            <organization/>
          </author>
          <author initials="J." surname="Ng" fullname="Jason Ng">
            <organization/>
          </author>
          <author initials="I." surname="Poetranto" fullname="Irene Poetranto">
            <organization/>
          </author>
          <author initials="A." surname="Senft" fullname="Adam Senft">
            <organization/>
          </author>
          <author initials="A." surname="Sinpeng" fullname="Aim Sinpeng">
            <organization/>
          </author>
          <author initials="B." surname="Sonne" fullname="Byron Sonne">
            <organization/>
          </author>
          <author initials="G." surname="Wiseman" fullname="Greg Wiseman">
            <organization/>
          </author>
          <date month="November" year="2013"/>
        </front>
      </reference>

      <reference anchor="Rushe-2014" 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/>
          </author>
          <date month="February" year="2014"/>
        </front>
        <refcontent>The Guardian</refcontent>
      </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/>
          </author>
          <date month="June" 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/>
          </author>
          <date year="1997"/>
        </front>
      <refcontent>66 University of Cincinnati Law Review 177-205</refcontent>
      </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/>
          </author>
          <date month="March" 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 month="November" 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/>
          </author>
          <date month="November" 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/>
          </author>
          <author initials="C." surname="Bronk" fullname="Christopher Bronk">
            <organization/>
          </author>
          <author initials="D.S." surname="Wallach" fullname="Dan S. Wallach">
            <organization/>
          </author>
          <date month="July" year="2011"/>
        </front>
	<seriesInfo name="DOI" value="10.48550/arXiv.1107.3794"/>
      </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/>
          </author>
          <date year="2009"/>
        </front>
	<refcontent>Global Voices Advocacy</refcontent>
      </reference>

      <reference anchor="Porter-2005" 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/>
          </author>
          <date year="2010"/>
        </front>
      </reference>

      <reference anchor="Clayton-2006" target="https://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/>
          </author>
          <author initials="S.J." surname="Murdoch" fullname="Steven J. Murdoch">
            <organization/>
          </author>
          <author initials="R.N.M." surname="Watson" fullname="Robert N. M. Watson">
            <organization/>
          </author>
          <date year="2006"/>
        </front>
<seriesInfo name="DOI" value="10.1007/11957454_2"/>
<refcontent>Lecture Notes in Computer Science, Volume 4258</refcontent>
      </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 month="August" 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/>
          </author>
          <author initials="M." surname="Javed" fullname="Mobin Javed">
            <organization/>
          </author>
          <author initials="P.D." surname="Anderson" fullname="Philip D. Anderson">
            <organization/>
          </author>
          <author initials="V." surname="Paxson" fullname="Vern Paxson">
            <organization/>
          </author>
          <date month="August" 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/>
          </author>
          <date month="July" year="2012"/>
        </front>
	<refcontent>The Tor Project</refcontent>
      </reference>

      <reference anchor="Wagstaff-2013" target="https://www.nbcnews.com/tech/tech-news/malaysia-online-election-battles-take-nasty-turn-flna6c9783842">
        <front>
          <title>In Malaysia, online election battles take a nasty turn</title>
          <author initials="J." surname="Wagstaff" fullname="Jeremy Wagstaff">
            <organization/>
          </author>
          <date month="May" year="2013"/>
        </front>
	<refcontent>NBC News</refcontent>
      </reference>

      <reference anchor="Hepting-2011" target="https://en.wikipedia.org/wiki/Hepting_v._AT%26T&amp;oldid=1175143505">
        <front>
          <title>Hepting v. AT&amp;T</title>
          <author>
            <organization>Wikipedia</organization>
          </author>
          <date month="September" year="2023"/>
        </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/>
          </author>
          <author initials="W." surname="John" fullname="Wolfgang John">
            <organization/>
          </author>
          <date month="July" year="2010"/>
        </front>
	<refcontent>Technical Report No. 2010-05, ISSN 1652-926X</refcontent>
      </reference>

      <reference anchor="Sandvine-2015" target="https://www.researchgate.net/profile/Nirmala-Svsg/post/Anybody-working-on-Internet-traffic-classification/attachment/59d63a5779197b807799782d/AS%3A405810988503040%401473764287142/download/traffic-classification-identifying-and-measuring-internet-traffic.pdf">
        <front>
          <title>Internet Traffic Classification: A Sandvine Technology Showcase</title>
          <author>
            <organization>Sandvine</organization>
          </author>
          <date year="2015"/>
        </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/>
          </author>
          <author initials="S." surname="Lindskog" fullname="Stefan Lindskog">
            <organization/>
          </author>
          <date month="April" year="2012"/>
        </front>
      </reference>

      <reference anchor="Van-der-Sar-2007" target="https://torrentfreak.com/how-to-bypass-comcast-bittorrent-throttling-071021">
        <front>
          <title>How To Bypass Comcast's BitTorrent Throttling</title>
          <author initials="E." surname="Van der Sar" fullname="Ernesto Van der Sar">
            <organization></organization>
          </author>
          <date month="October" 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 month="January" 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: Extended Version</title>
          <author initials="R." surname="Ensafi" fullname="Roya Ensafi">
            <organization/>
          </author>
          <author initials="J." surname="Knockel" fullname="Jeffrey Knockel">
            <organization/>
          </author>
          <author initials="G." surname="Alexander" fullname="Geoffrey Alexander">
            <organization/>
          </author>
          <author initials="J.R." surname="Crandall" fullname="Jedidiah R. Crandall">
            <organization/>
          </author>
          <date month="December" year="2013"/>
        </front>
	<seriesInfo name="DOI" value="10.48550/arXiv.1312.5739"/>
      </reference>

      <reference anchor="Weaver-2009" target="http://www.icir.org/vern/papers/reset-injection.ndss09.pdf">
        <front>
          <title>Detecting Forged TCP Reset Packets</title>
          <author initials="N." surname="Weaver" fullname="Nicholas Weaver">
            <organization/>
          </author>
          <author initials="R." surname="Sommer" fullname="Robin Sommer">
            <organization/>
          </author>
          <author initials="V." surname="Paxson" fullname="Vern Paxson">
            <organization/>
          </author>
          <date month="September" 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 month="October" 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/>
          </author>
          <date month="October" 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/>
          </author>
          <date month="August" 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/>
          </author>
          <date month="October" year="2008"/>
        </front>
      </reference>

      <reference anchor="Zmijewski-2014" target="http://web.archive.org/web/20200726222723/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/>
          </author>
          <date month="March" year="2014"/>
        </front>
	<refcontent>Wayback Machine archive</refcontent>
      </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 month="January" 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 month="July" 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/>
          </author>
          <date month="June" 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 attack</title>
          <author>
            <organization>Wikipedia</organization>
          </author>
          <date month="March" year="2016"/>
        </front>
      </reference>

      <reference anchor="NBC-2014" target="http://www.nbcnews.com/feature/edward-snowden-interview/exclusive-snowden-docs-show-uk-spies-attacked-anonymous-hackers-n21361">
        <front>
          <title>Exclusive: Snowden Docs Show UK Spies Attacked Anonymous, Hackers</title>
          <author>
            <organization>NBC News</organization>
          </author>
          <date month="February" year="2014"/>
        </front>
      </reference>

      <reference anchor="CERT-2000" target="https://vuls.cert.org/confluence/display/historical/CERT+Advisory+CA-1996-21+TCP+SYN+Flooding+and+IP+Spoofing+Attacks">
        <front>
          <title>CERT Advisory CA-1996-21 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/>
          </author>
          <date month="October" year="2012"/>
        </front>
	<refcontent>The Moscow Times</refcontent>
      </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/>
          </author>
          <author initials="M." surname="Crete-Nishihata" fullname="Masashi Crete-Nishihata">
            <organization/>
          </author>
          <date month="January" year="2011"/>
        </front>
      </reference>

      <reference anchor="Orion-2013" target="https://web.archive.org/web/20130825010947/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/>
          </author>
          <date month="August" year="2013"/>
        </front>
	<refcontent>Wayback Machine archive</refcontent>
      </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/>
          </author>
          <date month="May" year="2013"/>
        </front>
	<refcontent>The Register</refcontent>
      </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/>
          </author>
          <date month="September" year="2007"/>
        </front>
	<refcontent>BBC News</refcontent>
      </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/>
          </author>
          <date month="July" year="2009"/>
        </front>
	<refcontent>OpenNet Initiative</refcontent>
      </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/>
          </author>
          <date month="February" year="2011"/>
        </front>
	<refcontent>NANOG 51</refcontent>
      </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/>
          </author>
          <date month="November" year="2012"/>
        </front>
	<refcontent>The Register</refcontent>
      </reference>

      <reference anchor="BBC-2013b" target="https://www.bbc.com/news/world-asia-china-24396957">
        <front>
          <title>China employs two million microblog monitors state media say</title>
          <author>
            <organization>BBC</organization>
          </author>
          <date year="2013"/>
        </front>
      </reference>


      <reference anchor="Murdoch-2008" quoteTitle="false">
        <front>
          <title>"Tools and Technology of Internet Filtering" in "Access Denied: The Practice and Policy of Global Internet Filtering"</title>
          <author initials="S. J." surname="Murdoch" fullname="Steven J. Murdoch">
            <organization/>
          </author>
          <author initials="R." surname="Anderson" fullname="Ross Anderson">
            <organization/>
          </author>
          <date year="2008"/>
        </front>
	<seriesInfo name="DOI" value="10.7551/mitpress/7617.003.0006"/>
      </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 month="January" 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 month="October" 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/>
          </author>
          <author initials="C. H." surname="Chi" fullname="Chi-Hung Chi">
            <organization/>
          </author>
          <author initials="J." surname="Deng" fullname="Jing Deng">
            <organization/>
          </author>
          <author initials="C. L." surname="Dong" fullname="Chun-Lei Dong">
            <organization/>
          </author>
          <date month="October" year="1999"/>
        </front>
<seriesInfo name="DOI" value="10.1109/ICSMC.1999.825218"/>
<refcontent>IEEE SMC'99 Conference Proceedings</refcontent>
      </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-2023" target="https://support.sophos.com/support/s/article/KB-000036518?language=en_US">
        <front>
         <title>Sophos Firewall: Web filtering basics</title>
          <author>
            <organization>Sophos</organization>
          </author>
          <date year="2023"/>
        </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/>
          </author>
          <author initials="T." surname="Cholez" fullname="Thibault Cholez">
            <organization/>
          </author>
          <author initials="A." surname="Goichot" fullname="Antoine Goichot">
            <organization/>
          </author>
          <author initials="I." surname="Chrisment" fullname="Isabelle Chrisment">
            <organization/>
          </author>
          <date month="May" year="2015"/>
        </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/>
          </author>
          <author initials="N." surname="Weaver" fullname="Nicholas Weaver">
            <organization/>
          </author>
          <author initials="J." surname="Dalek" fullname="Jakub Dalek">
            <organization/>
          </author>
          <author initials="R." surname="Ensafi" fullname="Roya Ensafi">
            <organization/>
          </author>
          <author initials="D." surname="Fifield" fullname="David Fifield">
            <organization/>
          </author>
          <author initials="S." surname="McKune" fullname="Sarah McKune">
            <organization/>
          </author>
          <author initials="A." surname="Rey" fullname="Arn Rey">
            <organization/>
          </author>
          <author initials="J." surname="Scott-Railton" fullname="John Scott-Railton">
            <organization/>
          </author>
          <author initials="R." surname="Deibert" fullname="Ron Deibert">
            <organization/>
          </author>
          <author initials="V." surname="Paxson" fullname="Vern Paxson">
            <organization/>
          </author>
          <date month="August" 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/>
          </author>
          <author initials="C." surname="Lan" fullname="Chang Lan">
            <organization/>
          </author>
          <author initials="R." surname="Hynes" fullname="Rod Hynes">
            <organization/>
          </author>
          <author initials="P." surname="Wegmann" fullname="Percy Wegmann">
            <organization/>
          </author>
          <author initials="V." surname="Paxson" fullname="Vern Paxson">
            <organization/>
          </author>
          <date month="May" year="2015"/>
        </front>
<seriesInfo name="DOI" value="10.1515/popets-2015-0009"/>
      </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="https://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 month ="May" year="2012"/>
        </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="Stéphane Bortzmeyer">
            <organization/>
          </author>
          <date month="December" 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/>
          </author>
          <author initials="Y." surname="Cao" fullname="Yue Cao">
            <organization/>
          </author>
          <author initials="Z." surname="Qian" fullname="Zhiyun Qian">
            <organization/>
          </author>
          <author initials="C." surname="Song" fullname="Chengyu Song">
            <organization/>
          </author>
          <author initials="S.V." surname="Krishnamurthy" fullname="Srikanth V. Krishnamurthy">
            <organization/>
          </author>
          <date month="November" year="2017"/>
        </front>
	<seriesInfo name="DOI" value="10.1145/3131365.3131374"/>
      </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/>
          </author>
          <author initials="S." surname="Zhu" fullname="Shitong Zhu">
            <organization/>
          </author>
          <author initials="Y." surname="Cao" fullname="Yue Cao">
            <organization/>
          </author>
          <author initials="Z." surname="Qian" fullname="Zhiyun Qian">
            <organization/>
          </author>
          <author initials="C." surname="Song" fullname="Chengyu Song">
            <organization/>
          </author>
          <author initials="S.V." surname="Krishnamurthy" fullname="Srikanth V. Krishnamurthy">
            <organization/>
          </author>
          <author initials="K.S." surname="Chan" fullname="Kevin S. Chan">
            <organization/>
          </author>
          <author initials="T.D." surname="Braun" fullname="Tracy D. Braun">
            <organization/>
          </author>
          <date month="February" year="2020"/>
        </front>
	<seriesInfo name="DOI" value="10.14722/ndss.2020.24083"/>
      </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/>
          </author>
          <author initials="A." surname="Razaghpanah" fullname="Abbas Razaghpanah">
            <organization/>
          </author>
          <author initials="A." surname="Molavi Kakhki" fullname="Arash Molavi Kakhki">
            <organization/>
          </author>
          <author initials="A." surname="Akhavan Niaki" fullname="Arian Akhavan Niaki">
            <organization/>
          </author>
          <author initials="D." surname="Choffnes" fullname="David Choffnes">
            <organization/>
          </author>
          <author initials="P." surname="Gill" fullname="Phillipa Gill">
            <organization/>
          </author>
          <author initials="A." surname="Mislove" fullname="Alan Mislove">
            <organization/>
          </author>
          <date month="November" year="2017"/>
        </front>
	<seriesInfo name="DOI" value="10.1145/3131365.3131376"/>
      </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/>
          </author>
          <author initials="G." surname="Hughey" fullname="George Hughey">
            <organization/>
          </author>
          <author initials="X." surname="Qiang" fullname="Xiao Qiang">
            <organization/>
          </author>
          <author initials="D." surname="Levin" fullname="Dave Levin">
            <organization/>
          </author>
          <date month="November" year="2019"/>
        </front>
	<seriesInfo name="DOI" value="10.1145/3319535.3363189"/>
      </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/>
          </author>
          <author initials="Y." surname="Fax" fullname="Yair Fax">
            <organization/>
          </author>
          <author initials="K." surname="Reese" fullname="Kyle Reese">
            <organization/>
          </author>
          <author initials="J." surname="Singh" fullname="Jasraj Singh">
            <organization/>
          </author>
          <author initials="D." surname="Levin" fullname="Dave Levin">
            <organization/>
          </author>
          <date month="January" 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/>
          </author>
          <author>
            <organization>iyouport</organization>
          </author>
          <author>
            <organization>Anonymous</organization>
          </author>
          <author initials="L-H." surname="Merino" fullname="Louis-Henri Merino">
            <organization/>
          </author>
          <author initials="D." surname="Fifield" fullname="David Fifield">
            <organization/>
          </author>
          <author initials="A." surname="Houmansadr" fullname="Amir Houmansadr">
            <organization/>
          </author>
          <author initials="D." surname="Levin" fullname="Dave Levin">
            <organization/>
          </author>
          <date month="August" 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/>
          </author>
          <author initials="Z." surname="Weinberg" fullname="Zachary Weinberg">
            <organization/>
          </author>
          <author initials="D." surname="Barradas" fullname="Diogo Barradas">
            <organization/>
          </author>
          <author initials="N." surname="Christin" fullname="Nicolas Christin">
            <organization/>
          </author>
          <date month="April" year="2021"/>
        </front>
<seriesInfo name="DOI" value="10.1145/3442381.3450076"/>
      </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/>
          </author>
          <author initials="L." surname="Ruan" fullname="Lotus Ruan">
            <organization/>
          </author>
          <date month="April" year="2021"/>
        </front>
	<refcontent>FOCI '21: Proceedings of the ACM SIGCOMM 2021 Workshop on Free and Open Communications on the Internet, Pages 8-15</refcontent>
	<seriesInfo name="DOI" value="10.1145/3473604.3474560"/>
      </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/>
          </author>
          <author initials="P." surname="Bharadwaj" fullname="Pranav Bharadwaj">
            <organization/>
          </author>
          <author initials="J." surname="Singh" fullname="Jasraj Singh">
            <organization/>
          </author>
          <author initials="D." surname="Levin" fullname="Dave Levin">
            <organization/>
          </author>
          <date month="May" year="2021"/>
        </front>
	<seriesInfo name="DOI" value="10.1109/SPW53761.2021.00059"/>
      </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/>
          </author>
          <author initials="G." surname="Naval" fullname="Gabriel Naval">
            <organization/>
          </author>
          <author initials="K." surname="Reese" fullname="Kyle Reese">
            <organization/>
          </author>
          <author initials="D." surname="Levin" fullname="Dave Levin">
            <organization/>
          </author>
          <date month="August" year="2021"/>
        </front>
	<seriesInfo name="DOI" value="10.1145/3473604.3474559"/>
	<refcontent>FOCI '21: Proceedings of the ACM SIGCOMM 2021 Workshop on Free and Open Communications on the Internet, Pages 1-7</refcontent>
      </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/>
          </author>
          <author initials="R." surname="Chatterjee" fullname="Rahul Chatterjee">
            <organization/>
          </author>
          <date month="August" year="2021"/>
        </front>
	<seriesInfo name="DOI" value="10.1145/3473604.3474564"/>
	<refcontent>FOCI '21: Proceedings of the ACM SIGCOMM 2021 Workshop on Free and Open Communications on the Internet, Pages 43-49</refcontent>
      </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/>
          </author>
          <author initials="B." surname="Schuetz" fullname="Bertram Schuetz">
            <organization/>
          </author>
          <author initials="N." surname="Aschenbruck" fullname="Nils Aschenbruck">
            <organization/>
          </author>
          <author initials="S." surname="Basso" fullname="Simone Basso">
            <organization/>
          </author>
          <date month="November" year="2021"/>
        </front>
	<seriesInfo name="DOI" value="10.1145/3487552.3487836"/>
	<refcontent>IMC '21: Proceedings of the 21st ACM Internet Measurement Conference, Pages 276-282</refcontent>
      </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/>
          </author>
          <date month="April" 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/>
          </author>
          <author initials="A." surname="Herzberg" fullname="Amir Herzberg">
            <organization/>
          </author>
          <date month="April" year="2014"/>
        </front>
	<seriesInfo name="DOI" value="10.1145/2597173"/>
	<refcontent>ACM Transactions on Information and System Security, Volume 16, Issue 4, Article No.: 13, pp. 1-32</refcontent>
      </reference>

      <reference anchor="Siddiqui-2022" 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/>
          </author>
          <date month="March" 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/>
          </author>
          <date month="November" year="2018"/>
        </front>
      </reference>

      <reference anchor="ekr-2021" target="https://educatedguesswork.org/posts/apple-csam-intro/">
        <front>
          <title>Overview of Apple's Client-side CSAM Scanning</title>
          <author initials="E." surname="Rescorla" fullname="Eric Rescorla">
            <organization/>
          </author>
          <date month="August" year="2021"/>
        </front>
      </reference>
    </references>

    <section anchor="acks" numbered="false">
      <name>Acknowledgments</name>
      <t>This document benefited from discussions with and input from
<contact fullname="David Belson"/>, <contact fullname="Stéphane Bortzmeyer"/>, <contact fullname="Vinicius Fortuna"/>,
<contact fullname="Gurshabad Grover"/>, <contact fullname="Andrew McConachie"/>, <contact fullname="Martin Nilsson"/>, <contact fullname="Michael
Richardson"/>, <contact fullname="Patrick Vacek"/>, and <contact fullname="Chris Wood"/>.</t>

      <t>Coauthor Hall performed work on this document before employment at the Internet Society, and his affiliation listed in this document is for identification purposes only.</t>

    </section>

  </back>

</rfc>
