<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml2rfc.ietf.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2827 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2827.xml">
<!ENTITY RFC3704 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3704.xml">
<!ENTITY RFC1122 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1122.xml">
<!ENTITY RFC2775 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2775.xml">
<!ENTITY RFC2826 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2826.xml">
<!ENTITY RFC2979 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2979.xml">
<!ENTITY RFC3261 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY RFC3724 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3724.xml">
<!ENTITY RFC4033 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml">
<!ENTITY RFC4084 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4084.xml">
<!ENTITY RFC4301 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4301.xml">
<!ENTITY RFC4924 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4924.xml">
<!ENTITY RFC4948 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4948.xml">
<!ENTITY RFC4949 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4949.xml">
<!ENTITY RFC5246 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY RFC5782 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5782.xml">
<!ENTITY RFC6698 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6698.xml">
<!ENTITY RFC6480 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6480.xml">
<!ENTITY RFC6943 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6943.xml">
<!ENTITY RFC7288 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7288.xml">
<!ENTITY RFC1149 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1149.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
     please see http://xml2rfc.ietf.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<?rfc tocpagebreak="yes"?>
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" 
     submissionType="IAB" ipr="trust200902" number="7754" consensus="yes">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN"
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the
         full title is longer than 39 characters -->

    <title abbrev="Blocking and Filtering Considerations">Technical Considerations for
    Internet Service Blocking and Filtering</title>

    <!--add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

    <author initials="R." surname="Barnes" fullname="Richard Barnes">
          <organization>Mozilla</organization>
          <address>
            <postal>
              <street>Suite 300</street>
              <street>650 Castro Street</street>
              <city>Mountain View</city>
              <region>CA</region>
              <code>94041</code>
              <country>US</country>
            </postal>
            <email>rlb@ipv.sx</email>
          </address>
        </author>

    <author fullname="Alissa Cooper" initials="A." surname="Cooper">
      <organization>Cisco</organization>

      <address>
        <postal>
          <street>707 Tasman Drive</street>

          <city>Milpitas</city>

          <region>CA</region>

          <code>95035</code>

          <country>USA</country>
        </postal>

        <email>alcoop@cisco.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <author fullname="Olaf Kolkman" initials="O." surname="Kolkman">
      <organization abbrev="ISOC">Internet Society</organization>
      <address>
        <email>kolkman@isoc.org</email>
      </address>
    </author>

    <author initials="D." surname="Thaler" fullname="Dave Thaler">
          <organization>Microsoft</organization>
          <address>
            <postal>
              <street>One Microsoft Way</street>
              <city>Redmond</city>
              <region>WA</region>
              <code>98052</code>
              <country>US</country>
            </postal>
            <email>dthaler@microsoft.com</email>
          </address>
        </author>

    <author initials="E." surname="Nordmark" fullname="Erik Nordmark">
          <organization>Arista</organization>
          <address>
            <email>nordmark@arista.com</email>
          </address>
        </author>

    <date month="March" year="2016"/>

    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill
         in the current day for you. If only the current year is specified, xml2rfc will fill
     in the current day and month for you. If the year is not the current one, it is
     necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
     purpose of calculating the expiry date).  With drafts it is normally sufficient to
     specify just the year. -->

    <!-- Meta-data Declarations -->

    <area>General</area>

    <workgroup>Internet Architecture Board</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.
     If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <abstract>
      <t>
    The Internet is structured to be an open communications
    medium. This openness is one of the key underpinnings of
    Internet innovation, but it can also allow communications that
    may be viewed as undesirable by certain parties. Thus, as the
    Internet has grown, so have mechanisms to limit the extent and
    impact of abusive or objectionable communications. Recently,
    there has been an increasing emphasis on "blocking" and
    "filtering", the active prevention of such communications.
    This document examines several technical approaches to
    Internet blocking and filtering in terms of their alignment
    with the overall Internet architecture. When it is possible to do
    so, the approach to blocking and filtering that is most coherent with
    the Internet architecture is to inform endpoints about
    potentially undesirable services, so that the communicants can
    avoid engaging in abusive or objectionable communications.  We
    observe that certain filtering and blocking approaches can cause
    unintended consequences to third parties, and we discuss the
    limits of efficacy of various approaches.
      </t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>
        The original design goal of the Internet was to enable
        communications between hosts. As this goal was met and people
        started using the Internet to communicate, however, it became
        apparent that some hosts were engaging in communications that
        were viewed as undesirable by certain parties. The most famous
        early example of undesirable communications was the Morris
        worm <xref target="Morris" />, which used the Internet to
        infect many hosts in 1988. As the Internet has evolved into a
        rich communications medium, so too have mechanisms to restrict
        communications viewed as undesirable, ranging from acceptable
        use policies enforced through informal channels to technical
        blocking mechanisms.
      </t>

      <t>
        Efforts to restrict or deny access to Internet resources and
        services have evolved over time. As noted in
        <xref target="RFC4084"/>, some Internet service providers
        perform filtering to restrict which applications their customers may
        use and which traffic they allow on their networks. These
        restrictions are often imposed with customer consent, where
        customers may be enterprises or individuals. 
        However, governments, service providers, and enterprises are
	increasingly seeking to block or filter access to certain content, traffic,
        or services without the knowledge or agreement of affected
        users. Where these organizations do not directly control networks
        themselves, they commonly aim to make use of intermediary
        systems to implement the blocking or filtering.
      </t>

      <t>
        While blocking and filtering remain highly contentious in many
        cases, the desire to restrict communications or access to content will likely
        continue to exist.
      </t>

      <t>
        The difference between "blocking" and "filtering" is a matter
        of scale and perspective. "Blocking" often refers to
        preventing access to resources in the aggregate, while
        "filtering" refers to preventing access to specific resources
        within an aggregate. Both blocking and filtering can be
        implemented at the level of "services" (web hosting or video
        streaming, for example) or at the level of particular
        "content." For the analysis presented in this document, the
        distinction between blocking and filtering does not create
        meaningfully different conclusions. Hence, in the remainder of
        this document, we will treat the terms as being generally
        equivalent and applicable to restrictions on both content and
        services.
      </t>

      <t>
        This document aims to clarify the technical implications and
        trade-offs of various blocking strategies and to identify the
        potential for different strategies to potentially cause
        harmful side effects ("collateral damage") for Internet users
        and the overall Internet architecture. This analysis is
        limited to technical blocking mechanisms. The scope of the analyzed
	blocking is limited to intentional blocking, not accidental blocking
	due to misconfiguration or as an unintentional
	side effect of something else.
      </t>

      <t>
        Filtering may be considered legal, illegal, ethical, or
        unethical in different places, at different times, and by
        different parties.  This document is intended for those who
        are conducting filtering or are considering conducting
        filtering and want to understand the implications of their
        decisions with respect to the Internet architecture and the
        trade-offs that come with each type of filtering strategy.
        This document does not present formulas on how to make those
        trade-offs; it is likely that filtering decisions require
        knowledge of context-specific details.  Whether particular
        forms of filtering are lawful in particular jurisdictions
        raises complicated legal questions that are outside the scope
        of this document. For similar reasons, questions about the
        ethics of particular forms of filtering are also out of scope.
      </t>

<!-- Per ticket 366, moved to section 4.3.4
      <t>
        In <xref target="SAC-056"/>, ICANN's Security and Stability
        Advisory Committee (SSAC) assessed the aspects of blocking
        using the DNS. This document attempts to take a broader
        perspective on blocking and filtering and genaralizes from
        some of SSAC's findings.
      </t>
-->
    </section>

    <section title="Filtering Examples" anchor="examples">
      <t>
        Blocking systems have evolved alongside the Internet
        technologies they seek to restrict.  Looking back at the
        history of the Internet, there have been several such systems
        deployed by different parties and for different purposes.
      </t>

      <t>
        Firewalls: Firewalls of various sorts are very commonly
        employed at many points in today's Internet
        <xref target="RFC2979" />. They can be deployed either on end hosts
        (under user or administrator control) or in the network, typically
        at network boundaries.  While the Internet
        Security Glossary <xref target="RFC4949" /> contains an extended
        definition of a firewall, informally, most people would tend to
        think of a firewall as simply "something that blocks unwanted
        traffic" (see <xref target="RFC4948" /> for a discussion on many
        types of unwanted traffic).  While there are many sorts of
        firewalls, there are several specific types of firewall
        functionality worth noting.
       </t>
       <t>
          <list style ="symbols">
          <t> Stateless Packet Filtering: Stateless packet filters block
              according to content-neutral rules, e.g., blocking all
              inbound connections or outbound connections on certain ports,
              protocols, or network-layer addresses. For example, blocking
              outbound connections to port 25.
          </t>
          <t> Stateful Packet Filtering: More advanced configurations
              require keeping state used to enforce flow-based policies,
              e.g., blocking inbound traffic for flows that have not been
              established.
          </t>
	  <?rfc needLines="4"?>
          <t>
	      Deep Packet Inspection: Yet more advanced configurations
              perform deep packet inspection and filter or block based on
              the content carried.  Many firewalls include web filtering
              capabilities (see below).
          </t>
          </list>
      </t>

      <t>
        Web Filtering: HTTP and HTTPS are common targets for blocking
        and filtering, typically targeted at specific URIs. Some
        enterprises use HTTP blocking to block non-work-appropriate
        web sites, and several nations require HTTP and HTTPS
        filtering by their ISPs in order to block content deemed
        illegal. HTTPS is a challenge for these systems, because the
        URI in an HTTPS request is carried inside the encrypted
        channel. To block access to content made accessible via HTTPS,
        filtering systems thus must either block based on network- and transport-layer headers (IP
        address and/or port), or else obtain a trust anchor certificate that is
        trusted by endpoints (and thus act as a man in the
        middle). These filtering systems often take the form of
        "portals" or "enterprise proxies" presenting their own, dynamically
        generated HTTPS certificates. (See
        further discussion in <xref target="security" />.)
      </t>

      <t>
        Spam Filtering: Spam filtering is one of the oldest forms of
        content filtering. Spam filters evaluate messages based on a
        variety of criteria and information sources to decide whether
        a given message is spam. For example, DNS Blacklists
        use the reverse DNS to flag whether an IP address is a known
        spam source <xref target="RFC5782"/>. Spam filters
        can be installed on user devices (e.g., in a mail
        client), operated by a mail domain on behalf of users, or outsourced
        to a third party that acts as an intermediate MX proxy.
      </t>

      <t>
        <!--
            EL: I've updated this section to be more credible.  There
            are a myriad of ways to seize a domain, and the U.S. isn't
            the only one to do it.  ICANN has a whole process for it.
            But its effectiveness is called into question based on the
            purpose of the block.  Takedowns are quite important for
            certain types of content, but how the takedown occurs is
            also important.  This section may require additional work
            or shifting of text to other sections.
            -->
        Domain Name Seizure: A number of approaches are used to block
        or modify resolution of a domain name.  One approach is to
        make use of ICANN's Uniform Dispute Resolution Policy (URDP)
        for the purposes of dealing with fraudulent use of a name.
        Other authorities may require that domains be blocked within
        their jurisdictions.  Substantial research has been performed
        on the value and efficacy of such
        seizures <xref target="Takedown08"/> <xref target="BlackLists14"/>.
      </t>
      <t>
        The precise method of how domain names are seized will vary
        from place to place.  One approach in use is for queries to be
        redirected to resolve to IP addresses of the authority
        that hosts information about the seizure.
        The effectiveness of domain seizures will similarly vary based
        on the method.  In some cases, the person whose name was
        seized will simply use a new name.  In other cases, the block
        may only be effective within a region or when specific name
        service infrastructure is used.
      </t>
      <?rfc needLines="8"?>
      <t>
        Seizures can also have overbroad effects, since access
        to content is blocked not only within the jurisdiction of the
        seizure, but globally, even when it may be affirmatively legal
        elsewhere <xref target="RojaDirecta"/>. When domain
        redirection is effected via redirections at intermediate
        resolvers rather than at authoritative servers, it directly
        contradicts end-to-end assumptions in the DNS security
        architecture <xref target="RFC4033"/>, potentially causing
        validation failures by validating end-nodes.
      </t>

      <t>
        Safe Browsing: Modern web browsers provide some measures to
        prevent users from accessing malicious web sites. For
        instance, before loading a URI, current versions of Google
        Chrome and Firefox use the Google Safe Browsing service to
        determine whether or not a given URI is safe to load <xref
        target="SafeBrowsing"/>. The DNS can also be used to store
        third party information that mark domains as safe or unsafe
        <xref target="RFC5782"/>.
      </t>

      <t>
        Manipulation of routing and addressing data: Governments have
        recently intervened in the management of IP addressing and
        routing information in order to maintain control over a
        specific set of DNS servers. As part of an internationally
        coordinated response to the DNSChanger malware, a Dutch court
        ordered the RIPE NCC to freeze the accounts of several
        resource holders as a means to limit the resource holders'
        ability to use certain address blocks <xref
        target="GhostClickRIPE"/> (also see <xref
        target="SERVER-BLOCK"/>). These actions have led to concerns
        that the number resource certification system and related
        secure routing technologies developed by the IETF's SIDR
        working group might be subject to government manipulation as
        well <xref target="RFC6480"/>, potentially for the purpose of
        denying targeted networks access to the Internet.
      </t>
      <t>
        Ingress filtering: Network service providers use ingress filtering
        <xref target='RFC2827'/> <xref target='RFC3704'/> as a means to prevent
        source address spoofing which is used as a part of other attacks.
      </t>
      <t>
        Data loss prevention (DLP): Enterprise and other networks are concerned with
        potential leaking of confidential information, whether accidental or
        intentional. Some of the tools used for this are similar to the
        main subject of this document of blocking and filtering. In particular,
        enterprise proxies might be part of a DLP solution.
      </t>
    </section>

    <section title="Characteristics of Blocking Systems">
      <t>
        At a generic level, blocking systems can be characterized by
        four attributes: the party who sets the blocking policy, the
        purpose of the blocking, the intended target of the blocking,
        and the Internet component(s) used as the basis of the blocking
        system.
      </t>

      <section title="The Party Who Sets Blocking Policies">
        <t>
          Parties that institute blocking policies include
          governments, courts, enterprises, network operators, reputation
          trackers, application providers, and individual end users. A
          government might create laws based on cultural norms and/or
          their elected mandate. Enterprises might use cultural, industry,
          or legal norms to guide their policies.
        </t>
        <t>
          There can be several steps of translation and transformation
          from the original intended purpose -- first to laws, then to (government)
          regulation, followed by high-level policies in, e.g.,
          network operators, and from those policies to filtering architecture
          and implementation.
          Each of those steps is a potential source of unintended consequences
          as discussed in this document.
        </t>
        <t>
          In some cases, the policy setting entity is the same as the
          entity that enforces the policy.
          For example, a network operator might install a firewall in
          its own networking equipment, or a web application provider
          might block responses between its web server and certain
          clients. 
        </t>
        <t>
          In other cases, the policy setting entity is different from
          the entity that enforces the policy.  Such policy might be
          imposed upon the enforcing entity, such as in the case of
          blocking initiated by governments, or the enforcing entity
          might explicitly choose to use policy set by others,
          such as in the case of a reputation system used by a spam
          filter or safe browsing service.  Because a policy might
          be enforced by others, it is best if it can
          be expressed in a form that is independent of the enforcing
          technology.
        </t>
      </section>

      <section title="Purposes of Blocking">
        <t>
          There are a variety of motivations to filter:
        </t>
        <t>
          <list style ="symbols">
            <t>
              Preventing or responding to security threats. Network
              operators, enterprises, application providers, and end
              users often block communications that are believed to be
              associated with security threats or network attacks.
            </t>

            <t>
              Restricting objectionable content or services. Certain
              communications may be viewed as undesirable, harmful, or
              illegal by particular governments, enterprises, or users.
              Governments may seek to block
              communications that are deemed to be defamation, hate
              speech, obscenity, intellectual property infringement,
              or otherwise objectionable. Enterprises may seek to
              restrict employees from accessing content that is not
              deemed to be work appropriate. Parents may restrict
              their children from accessing content or services
              targeted for adults.
            </t>

            <t>
              Restricting access based on business arrangements. Some
              networks are designed so as to only provide access to
              certain content or services ("walled gardens"), or to
              only provide limited access until end users pay for full
              Internet services (captive portals provided by hotspot
              operators, for example).
            </t>
          </list>
        </t>

        <section title="Blacklist vs. Whitelist Model">
          <t>
            Note that the purpose for which blocking occurs often dictates
            whether the blocking system operates on a blacklist model,
            where communications are allowed by default but a subset are
            blocked, or a whitelist model, where communications are
            blocked by default with only a subset allowed. Captive
            portals, walled gardens, and sandboxes used for security or
            network endpoint assessment usually require a whitelist model
            since the scope of communications allowed is narrow. Blocking
            for other purposes often uses a blacklist model since only
            individual content or traffic is intended to be blocked.
          </t>
        </section>
      </section>

      <section title="Intended Targets of Blocking">
        <t>
          Blocking systems are instituted so as to target
          particular content, services, endpoints, or some combination
          of these. For example, a "content" filtering system used by
          an enterprise might block access to specific URIs whose
          content is deemed by the enterprise to be inappropriate for
          the workplace. This is distinct from a "service" filtering
          system that blocks all web traffic (perhaps as part of a
          parental control system on an end-user device) and also
          distinct from an "endpoint" filtering system in which a web
          application blocks traffic from specific endpoints that are
          suspected of malicious activity.
        </t>

        <t>
          As discussed in <xref target="evaluation" />, the design of
          a blocking system may affect content, services, or endpoints
          other than those that are the intended targets. For example,
          when domain name seizures described above are intended to
          address specific web pages associated with illegal activity,
          by removing the domains from use, they affect all services
          made available by the hosts associated with those names,
          including mail services and web services that may be
          unrelated to the illegal activity.  Depending on where the
          block is imposed within the DNS hierarchy, entirely
          unrelated organizations may be impacted.
        </t>
	<?rfc needLines="-1" ?>
      </section>

      <section title="Components Used for Blocking">
        <t>
          Broadly speaking, the process of delivering an Internet
          service involves three different components:
        </t>

        <t>
          <list style="numbers">
            <t>
              Endpoints: The actual content of the service is typically an
              application-layer protocol between two or more Internet hosts.
              In many protocols, there are two endpoints, a client and
              a server.
            </t>
            <t>
              Network services: The endpoints communicate by way of a
              collection of IP networks that use routing protocols to
              determine how to deliver packets between the endpoints.
            </t>
            <t>
              Rendezvous services: Service endpoints are typically
              identified by identifiers that are more "human-friendly"
              than IP addresses.  Rendezvous services allow one
              endpoint to figure out how to contact another endpoint
              based on an identifier.  An example of a rendezvous
              service is the domain name system.  Distributed Hash
              Tables (DHTs) have also been used as rendezvous
              services.
            </t>
          </list>
        </t>

        <t>
          Consider, for example, an HTTP transaction fetching the
          content of the URI &lt;http://example.com/index.html&gt;.
          The client endpoint is an end host running a browser.  The
          client uses the DNS as a rendezvous service when it performs
          a AAAA query to obtain the IP address for the server name
          "example.com".  The client then establishes a connection to
          the server, and sends the actual HTTP request.  The server
          endpoint then responds to the HTTP request.
        </t>

        <t>
          As another example, in the SIP protocol, the two endpoints
          communicating are IP phones, and the rendezvous service is provided
          by an application-layer SIP proxy as well as the DNS.
        </t>

        <t>
	  Blocking access to Internet content, services, or endpoints is done
	  by controlling one or more of the components involved in the
	  provision of the communications involved in accessing the content,
	  services, or endpoints.  In the HTTP example above, the successful
	  completion of the HTTP request could have been prevented in several
	  ways:
        </t>

        <t>
          <list style="symbols">
            <t>
              [Endpoint] Preventing the client from making the request
            </t>
            <t>
              [Endpoint] Preventing the server from responding to the request
            </t>

            <t>
              [Endpoint] Preventing the client from making the DNS request needed to resolve example.com
            </t>
            <t>
              [Network] Preventing the request from reaching the server
            </t>
            <t>
              [Network] Preventing the response from reaching the client
            </t>
            <t>
              [Network] Preventing the client from reaching the DNS servers
            </t>
            <t>
              [Network] Preventing the DNS responses from reaching the client
            </t>
            <t>
              [Rendezvous] Preventing the DNS servers from providing
              the client the correct IP address of the server
            </t>
          </list>
        </t>

        <t>
          Those who desire to block communications will typically have
          access to only one or two components; therefore their
          choices for how to perform blocking will be limited. End
          users and application providers can usually only control
          their own software and hardware, which means that they are
          limited to endpoint-based filtering. Some network operators
          offer filtering services that their customers can activate
          individually, in which case end users might have
          network-based filtering systems available to them. Network
          operators can control their own networks and the rendezvous
          services for which they provide infrastructure support
          (e.g., DNS resolvers) or to which they may have access
          (e.g., SIP proxies), but not usually endpoints. Enterprises
          usually have access to their own networks and endpoints for
          filtering purposes. Governments might make arrangements with
          the operators or owners of any of the three components that
          exist within their jurisdictions to perform filtering.
        </t>

        <t>
          In the next section, blocking systems designed according to
          each of the three patterns -- network services, rendezvous
          services, and endpoints -- are evaluated for their technical
          and architectural implications. The analysis is as agnostic
          as possible as to who sets the blocking
          policy (government, end user, network operator, application
          provider, or enterprise), but in some cases the way in which
          a particular blocking design pattern is used might differ,
          depending on the who desires a block. For example,
          a network-based firewall provided by an ISP that parents can
          elect to use for parental control purposes will likely
          function differently from one that all ISPs in a particular
          jurisdiction are required to use by the local government,
          even though in both cases the same component (network) forms
          the basis of the blocking system.
        </t>
      </section>
    </section>

    <section title="Evaluation of Blocking Design Patterns" anchor="evaluation">
      <section title="Criteria for Evaluation">
        <t>
          To evaluate the technical implications of each of the
          blocking design patterns, we compare them based on four
          criteria: scope, granularity, efficacy, and security.
        </t>

        <!-- DT updated the following section because it was confusing and
             convoluted granularity (the next section) with topological
             scope, whereas the text in later Scope sections is in the
             the context of topological scope.
          -->
        <section title="Scope: What set of hosts and users are affected?">
          <t>
            The Internet is comprised of many distinct autonomous
            networks and applications, which means that the impact of
            a blocking system will only be within a defined topological scope. For
            example, blocking within an access network will only
            affect a well-defined set of users
            (namely, those connected to the access network).
            <!-- but can affect all applications for those users. -->
            Blocking performed by an application provider can affect users
            across the entire Internet.
            <!-- but only for that specific
                 application. Thus the scope of the impact might be narrow
                 in one dimension (set of users or set of applications
                 affected) but broad in another. In some cases,
                 applications and rendezvous services are so intertwined
                 with each other that filtering a single service or in a
                 single network location can have broad effects in multiple
                 directions. 
              -->
          </t>
          <!--  EL I've updated the text below to be specific.  The
          IAB is supposed to be technical.  Showing a little geek
          without going into gory detail actually gives us street cred.
            -->
          <t>
            Blocking systems are generally viewed as less
            objectionable if the scope of their impact is as narrow as
            possible while still being effective, and as long as the impact
            of the blocking is within the administrative realm of the policy
            setting entity.  As mentioned
            previously, enterprise blocking systems are commonly
            deployed, and will generally have impact on enterprise
            users.  However, design flaws in blocking systems may cause the
            effects of blocking to be overbroad. For example, 
            at least one service provider blocking content in accordance
            with a regulation has ended up blocking content for
            downstream service providers because it filtered
            routes to particular systems and did not distribute the
            original information to downstream service providers in
            other jurisdictions <xref target="IN-OM-filtering"/>.
            Other service providers have accidentally leaked such
            black hole routes beyond the
            jurisdiction <xref target="NW08"/>.
            A substantial amount of work has gone into BGP security to
            avoid such attacks, but deployment of such systems lags.
          </t>
        </section>

        <section title="Granularity: How specific is the blocking?  Will blocking one service also block others?">
          <t>
            Internet applications are built out of a collection of
            loosely coupled components or "layers".  Different layers
            serve different purposes and rely on or offer different
            functions such as routing, transport, and naming (see
            <xref target="RFC1122"/>, especially Section 1.1.3). The
            functions at these layers are developed autonomously and
            almost always operated by different parties. For example,
            in many networks, physical and link-layer connectivity is
            provided by an "access provider", IP routing is performed
            by an "Internet service provider," and application-layer
            services are provided by completely separate entities
            (e.g., web servers). Upper-layer protocols and
            applications rely on combinations of lower-layer functions
            in order to work. Functionality at higher layers tends to
            be more specialized, so that many different specialized
            applications can make use of the same generic underlying
            network functions.
          </t>
          <t>
            As a result of this structure, actions taken at one layer
            can affect functionality or applications at other layers.
            For example, manipulating routing or naming functions to
            restrict access to a narrow set of resources via specific
            applications will likely affect all applications that
            depend on those functions. As with the scope criteria,
            blocking systems are generally viewed as less
            objectionable when they are highly granular and do not
            cause collateral damage to content or services unrelated
            to the target of the blocking <xref target="RFC4924" />.
          </t>
          <t>
            Even within the application layer, the granularity of
            blocking can vary depending on how targeted the blocking
            system is designed to be. Blocking all traffic associated
            with a particular application protocol is less granular
            than blocking only traffic associated with a subset of
            application instances that make use of that protocol.
            Sophisticated heuristics that make use of information
            about the application protocol, lower-layer protocols,
            payload signatures, source and destination addresses,
            inter-packet timing, packet sizes, and other
            characteristics are sometimes used to narrow the subset of
            traffic to be blocked.
          </t>
        </section>

        <section title="Efficacy: How easy is it for a resource or service to avoid being blocked?">
          <t>
            Although blocking a resource or service might have some
            immediate effect, efficacy must be evaluated in terms of
            whether it is easy to circumvent.  Simply doing a one-time
            policy is often unlikely to have lasting efficacy (e.g.,
            see <xref target="CleanFeed"/> and <xref target="BlackLists14"/>).
	    Experience has shown that, in general, blacklisting requires
	    continual maintenance of the blacklist itself, both to add new
	    entries for unwanted traffic and deleting entries when offending
	    content is removed.  Experience also shows that, depending on the
	    nature of the block, it may be difficult to determine when to
	    unblock.  For instance, if a host is blocked because it has been
	    compromised and used as a source of attack, it may not be plainly
	    evident when that site has been fixed.
          </t>
          <t>
            For blacklist-style blocking, the distributed and mobile
            nature of Internet resources limits the effectiveness of
            blocking actions. A service that is blocked in one
            jurisdiction can often be moved or re-instantiated in
            another jurisdiction (see, for example, <xref
            target="Malicious-Resolution" />). Likewise, services that
            rely on blocked resources can often be rapidly
            reconfigured to use non-blocked resources. If a web site
            is prevented from using a domain name or set of IP
            addresses, the content can simply be moved to another domain
            name or network, or use alternate syntaxes to express
            the same resource name 
            (see the discussion of false negatives in 
            <xref target="RFC6943"/>).
          </t>
	  <?rfc needLines="5"?>
          <t> 
            In a process known as "snowshoe
            spamming," a spam originator uses addresses in many
            different networks as sources for spam. This technique is
            already widely used to spread spam generation across a
            variety of resources and jurisdictions to prevent spam
            blocking from being effective.
          </t>
          <t>
            In the presence of either blacklist or whitelist systems,
            there are several ways in which a user or application can try to
            circumvent the filters.
          </t>
          <t>
            The users may choose to use different sets of protocols or
            otherwise alter their traffic characteristics to
            circumvent the filters. In some cases, 
            applications may shift their traffic to port 80 or 443 when
            other ports are blocked.
            Or, services may be tunneled within other services,
            proxied by a collaborating external host (e.g., an anonymous
            redirector),
            or simply run over an alternate port (e.g., port 8080 vs port
            80 for HTTP). Another means of circumvention is alteration of
            the service behavior to use a dynamic port negotiation phase,
            in order to avoid use of a constant port address.
          </t>
          <t>
            One of the primary motivations for arguing that HTTP/2 should
	    be encrypted by default was that unencrypted HTTP 1.1 traffic was 
	    sometimes blocked or improperly processed.
	    Users or applications shifting
            their traffic to encrypted HTTP has the effect of circumventing
            filters that depend on the HTTP plaintext payload.
          </t>
          <t>
            If voice communication
            based on SIP <xref target="RFC3261" /> is blocked, users
            are likely to use applications which use proprietary protocols
            that allow them to talk to each other.
          </t>
          <t>
            Some filtering systems are only
            capable of identifying IPv4 traffic and therefore, by
            shifting to IPv6, users may be able to evade
            filtering. Using IPv6 with header options, using multiple
            layers of tunnels, or using encrypted tunnels can also
            make it more challenging for blocking systems to find
            transport ports within packets, making port-based blocking
            more difficult. Thus, distribution and mobility can hamper
            efforts to block communications in a number of ways.
          </t>
        </section>

        <section title="Security: How does the blocking impact existing trust infrastructures?">
          <t>
            Modern security mechanisms rely on trusted hosts
            communicating via a secure channel without intermediary
            interference. Protocols such as
	    Transport Layer Security (TLS) <xref target="RFC5246"/>
	    and IPsec <xref target="RFC4301"/> are designed to
            ensure that each endpoint of the communication knows the
            identity of the other endpoint(s) and that only the
            endpoints of the communication can access the secured
            contents of the communication. For example, when a user
            connects to a bank's web site, TLS ensures that the user's
            banking information is securely communicated to the bank
            and nobody else, ensuring the data remains confidential
            while in transit.
          </t>

          <t>
            Some blocking strategies require intermediaries to insert
            themselves within the end-to-end communications path,
            potentially breaking security properties of Internet
            protocols <xref target="RFC4924" />. In these cases, it can be
            difficult or
            impossible for endpoints to distinguish between attackers
            and "authorized" parties conducting blocking. For example,
            an enterprise firewall administrator could gain access to
            users' personal bank accounts when users on the enterprise
            network connect to bank web sites.
          </t>

          <t>
            Finally, one needs to evaluate whether a blocking mechanism
            can be used by an end user to efficiently locate blocked
            resources that can then be accessed via other mechanisms
            that circumvent the blocking mechanism. For example,
            Clayton <xref target="CleanFeed"/> showed how special
            treatment in one blocking system could be detected by
            end users in order to efficiently locate illegal web sites,
            which was thus counterproductive to the policy objective
            of the blocking mechanism.
          </t>
        </section>
      </section>

      <section title="Network-Based Blocking">
        <t>
          Being able to block access to resources without the consent
          or cooperation of either endpoint is
          viewed as a desirable feature by some that deploy
          blocking systems. Systems that have this property are often
          implemented using intermediary devices in the network, such
          as firewalls or filtering systems. These systems inspect
          traffic as it passes through the network, decide based on
          the characteristics or content of a given communication
          whether it should be blocked, and then block or allow the
          communication as desired. For example, web filtering devices
          usually inspect HTTP requests to determine the URI being
          requested, compare that URI to a list of blacklisted or
          whitelisted URIs, and allow the request to proceed only if
          it is permitted by policy.
          Firewalls perform a similar function for other classes of
          traffic in addition to HTTP. Some blocking systems focus on
          specific application-layer traffic, while others, such as
          router Access Control Lists (ACLs), filter traffic based on lower-layer criteria
          (transport protocol and source or destination addresses or
          ports).
        </t>

        <t>
          Intermediary systems used for blocking are often not far
          from the edge of the network. For example, many enterprise
          networks operate firewalls that block certain web sites, as
          do some residential ISPs. In some cases, this filtering is
          done with the consent or cooperation of the affected
          endpoints. PCs within an enterprise, for example, might be
          configured to trust an enterprise proxy, a residential ISP
          might offer a "safe browsing" service, or mail clients might
          authorize mail servers on the local network to filter spam
          on their behalf. These cases share some of the properties of
          the "Endpoint-Based Blocking" scenarios discussed in <xref
          target="End-Point-Blocking" /> below, since the endpoint has
          made an informed decision to authorize the intermediary to
          block on its behalf and is therefore unlikely to attempt to
          circumvent the blocking. From an architectural perspective,
          however, they may create many of the same problems as
          network-based filtering conducted without consent.
        </t>

        <section title="Scope">
          <t>
            In the case of government-initiated blocking, network operators
	    subject to a specific jurisdiction may be required to block or 
	    filter. Thus, it is possible for
            laws to be structured to result in blocking by imposing
            obligations on the operators of networks within
            a jurisdiction, either via direct government action or by
            allowing private actors to demand blocking (e.g., through
            lawsuits).
          </t>

          <t>
            Regardless of who is responsible for a blocking policy,
            enforcement can be done using Stateless Packet Filtering,
            Stateful Packet Filtering, or Deep Packet Inspection as
            defined in <xref target="examples"/>.  While network-based
            Stateless Packet Filtering has granularity issues discussed
            in <xref target="networkgranularity"/>, network-based
            Stateful Packet Filtering and Deep Packet Inspection approaches
            often run into several
            technical issues that limit their viability in practice.
            For example, many issues arise from the fact that an
            intermediary needs to have access to a sufficient amount
            of traffic to make its blocking determinations.
          </t>

          <t>
            For residential or consumer networks with many egress
            points, the first step to obtaining this traffic is
            simply gaining access to the constituent packets. The
            Internet is designed to deliver packets independently from
            source to destination -- not to any particular point along
            the way. Thus, the sequence of packets from the sender can only be
            reliably reconstructed at the intended receiver. In addition,
            inter-network routing is often
            asymmetric, and for sufficiently complex local networks,
            intra-network traffic flows can be asymmetric as well
            <xref target="asymmetry" />. Thus, packets in the reverse direction
            use a different sent of paths than the forward direction.
          </t>

          <t>
            This asymmetry means that an intermediary in a network
            with many egress points may, depending on topology and
            configuration, see only one half of a given communication,
            <!-- (if it sees any of it at all), -->
            which
            may limit the scope of the communications that it can
            filter. For example, a filter aimed at requests destined
            for particular URIs cannot make accurate blocking
            decisions based on the URI if it is only in the data path for HTTP
            responses and not requests, since the URI is not included in the
	    responses. Asymmetry may be surmountable
            given a filtering system with enough distributed,
            interconnected filtering nodes that can coordinate
            information about flows belonging to the same communication
            or transaction, but depending on the size of the network
            this may imply significant complexity in the filtering
            system. Routing can sometimes be
            forced to be symmetric within a given network using
            routing configuration, NAT, or Layer 2 mechanisms (e.g.,
            MPLS), but these mechanisms are frequently brittle,
            complex, and costly -- and can sometimes result in reduced
            network performance relative to asymmetric routing.
            Enterprise networks may also be less susceptible to these
            problems if they route all traffic through a small number
            of egress points.
          </t>
        </section>

        <section title="Granularity" anchor="networkgranularity">
          <t>
            Once an intermediary in a network has access to traffic,
            it must identify which packets must be filtered. This
            decision is usually based on some combination of
            information at the network layer (e.g., IP addresses),
            transport layer (ports), or application layer (URIs or
            other content). Deep Packet Inspection type blocking based 
            on application-layer
            attributes can be potentially more granular and less
            likely to cause collateral damage than blocking all
            traffic associated with a particular address, which can
            impact unrelated occupants of the same address. However,
            more narrowly focused targeting may be more complex, less
            efficient, or easier to circumvent than filtering that
            sweeps more broadly, and those who  seek to block must
            balance these attributes against each other when choosing
            a blocking system.
          </t>
        </section>

        <section title="Efficacy and Security">
          <t>
            Regardless of the layer at which blocking occurs, it may
            be open to circumvention, particularly in cases where
            network endpoints have not authorized the blocking. The
            communicating endpoints can deny the intermediary access
            to attributes at any layer by using encryption (see
            below). IP addresses must be visible, even if packets are
            protected with IPsec, but blocking based on IP addresses
            can be trivial to circumvent. A filtered site may be able
            to quickly change its IP address using only a few simple
            steps: changing a single DNS record and provisioning the
            new address on its server or moving its services to the
            new address <xref target="BT-TPB"/>.
            <!-- DT removed reference to TPB-cloud because there's
                 little relevant there and it's a questionable
                 site in the first place.  Also Pekka in ticket 366
                 pointed out that the old characterization was
                 incorrect and so the reference is no longer useful.

            Indeed, in the face of IP-based blocking in
            some networks, services such as The Pirate Bay are now
            using cloud hosting services so that their IP addresses
            are difficult for intermediaries to predict .
              -->
          </t>
          <t>
            Indeed, Poort, et al.&nbsp;<xref target="Poort"/> found that
            "any behavioural change in
            response to blocking access to The Pirate Bay has had no lasting net
            impact on the overall number of downloaders from illegal
            sources, as new consumers have started downloading from
            illegal sources and people learn to circumvent the blocking
            while new illegal sources may be launched, causing file
            sharing to increase again", and that these
	    <?rfc needLines="-1"?>
	    results
            "are in line with a tendency found in the literature that
            any effects of legal action against file sharing often
            fade out after a period of typically six months."
          </t>

          <t>
            If application content is encrypted with a security
            protocol such as IPsec or TLS, then the intermediary will
            require the ability to decrypt the packets to examine
            application content, or resort to statistical methods to guess
            what the content is.
            Since security protocols are generally designed
            to provide end-to-end security (i.e., to prevent
            intermediaries from examining content), the intermediary
            would need to masquerade as one of the endpoints, breaking
            the authentication in the security protocol, reducing the
            security of the users and services affected, and
            interfering with legitimate private communication.
            Besides, various techniques that use public databases with
            whitelisted keys (e.g., DANE <xref target="RFC6698"/>)
            enable users to detect these sort of intermediaries. Those
            users are then likely to act as if the service is blocked.
          </t>

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

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

          <t>
            Thus, in principle in a blacklist system it is impossible
            to block tunneled traffic through an intermediary device
            without blocking all secure traffic from that system. (The
            only limitation in practice is the requirement for special
            software on the client.) 
<!--  EL: We can't really say this.  It may or may not be acceptable
            to a government.  What we can say follows instead.
            In most cases, blocking all
            secure traffic is an unacceptable consequence of blocking,
            since security is often required for services such as
            online commerce, enterprise VPNs, and management of
            critical infrastructure.
            -->
            Those who require that secure traffic be blocked from such
            sites risk blocking content that would be valuable to
            their users, perhaps impeding substantial economic
            activity.  Conversely, those who are hosting a myriad of
            content have an incentive to see that law abiding content
            does not end up being blocked.
	  </t>
	  <?rfc needLines="5"?>
	  <t> Governments and network operators should, however, take care
            not to encourage the use of insecure communications in the
            naming of security, as doing so will invariably expose
            their users to the various attacks that the security
            protocols were put in place to prevent.
          </t>
          <t>
            Some operators may assume that only blocking access to
            resources available via unsecure channels is sufficient
            for their purposes -- i.e., that the size of the user base
            that will be willing to use secure tunnels and/or special
            software to circumvent the blocking is low enough to make
            blocking via intermediaries worthwhile. Under that
            assumption, one might decide that there is no need to
            control secure traffic and thus that network-based
            blocking is an attractive option.
          </t>

          <t>
            However, the longer such blocking systems are in place,
            the more likely it is that efficient and easy-to-use
            tunneling tools will become available. The proliferation
            of the Tor network, for example, and its increasingly
            sophisticated blocking-avoidance techniques demonstrate
            that there is energy behind this trend <xref
            target="Tor"/>. Thus, network-based blocking becomes less
            effective over time.
          </t>
          <t>
            Network-based blocking is a key contributor to the arms
            race that has led to the development of such
            tools, the result of which is to create unnecessary layers
            of complexity in the Internet. Before content-based
            blocking became common, the next best option for network
            operators was port blocking, the widespread use of which
            has driven more applications and services to use ports (80
            and 443 most commonly) that are unlikely to be blocked. In
            turn, network operators shifted to finer-grained content
            blocking over port 80, content providers shifted to
            encrypted channels, and operators began seeking to
            identify those channels (although doing so can be
            resource-prohibitive, especially if tunnel endpoints begin
            to change frequently). Because the premise of
            network-based blocking is that endpoints have incentives
            to circumvent it, this cat-and-mouse game is an inevitable
            by-product of this form of blocking.
          </t>
          <t>One reason above all stands as an enormous challenge to
          network-based blocking: the Internet was designed with the
          premise that people will want to connect and communicate.
          IP will run on anything up to and including carrier
          pigeons <xref target="RFC1149"/>.  It often runs atop TLS
          and has been made to run on other protocols that themselves
          run atop IP.  Because of this fundamental layering approach,
          nearly any authorized avenue of communication can be used as
          a transport.  This same "problem" permits communications to
          succeed in the most challenging of environments.
          </t>
	  <?rfc needLines="-1" ?>
        </section>

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

      <section title="Rendezvous-Based Blocking" anchor="SERVER-BLOCK">
        <t>
          Internet applications often require or rely on support from
          common, global rendezvous services, including the DNS,
          certificate authorities, search engines, WHOIS databases, and Internet Route
          Registries. These services control or register the structure
          and availability of Internet applications by providing data
          elements that are used by application code. Some
          applications also have their own specialized rendezvous
          services. For example, to establish an end-to-end SIP call,
          the end-nodes (terminals) rely on presence and session
          information supplied by SIP servers.
        </t>

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

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

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

          <t>
            The scope of blocking conducted by others will
            depend on which servers they can access. For
            example, network operators and enterprises may be capable
            of conducting blocking using their own DNS resolvers or
            application proxies within their networks, but not
            authoritative servers controlled by others.
          </t>
          <t>
            However, if a service is hosted and operated within a
            jurisdiction where it is considered legitimate, then
            blocking access at a global rendezvous service 
            (e.g., one within a jurisdiction where it is considered
            illegitimate) might deny services in jurisdictions where
	    they are considered legitimate.  This type of collateral damage
            is lessened when blocking is done at a local rendezvous
            server that only has local impact, rather than at a global
            rendezvous server with global impact.
          </t>
        </section>

        <section title="Granularity">
          <t>
            Blocking at a global rendezvous service can be overbroad
            if the resources blocked support multiple services, since
            blocking service can cause collateral damage to legitimate
            uses of other services.  For example, a given address or
            domain name might host both legitimate services as well as
            services that some would desire to block.
          </t>
        </section>

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

          <t>Endpoints can also choose not to use a particular
            rendezvous service. They might switch to a competitor or
            use an alternate mechanism (for example, IP literals in
            URIs to circumvent DNS filtering).
          </t>
        </section>

        <section title="Security and Other Implications">
          <t>
            Blocking of global rendezvous services also has a variety
            of other implications that may reduce the stability,
            accessibility, and usability of the global Internet.
            Infrastructure-based blocking may erode the trust in the
            general Internet and encourage the development of parallel
            or "underground" infrastructures causing forms of Internet
            fragmentation, for example. This risk may become more
            acute as the introduction of security infrastructures and
            mechanisms such as DNSSEC and RPKI "hardens" the
            authoritative data -- including blocked names or routes --
            that the existing infrastructure services provide. Those
            seeking to circumvent the blocks may opt to use
            less-secure but unblocked parallel services. As applied to
            the DNS, these considerations are further discussed in
            RFC 2826 <xref target="RFC2826"/>, in
            the advisory <xref target="SAC-056"/>
            from ICANN's Security and Stability Advisory
            Committee (SSAC), and in the Internet Society's whitepaper on DNS filtering <xref
            target="ISOCFiltering"/>, but they also apply to other
            global Internet resources.
          </t>
        </section>

        <section title="Examples">
          <t>
            Below we provide a few specific examples for routing, DNS,
            and WHOIS services. These examples demonstrate that for
            these types of rendezvous services (services that are
            often considered a global commons), jurisdiction-specific
            legal and ethical motivations for blocking can both have
            collateral effects in other jurisdictions and be
            circumvented because of the distributed nature of the
            Internet.
          </t>

          <t>
            In 2008, Pakistan Telecom attempted to deny access to
            YouTube within Pakistan by announcing bogus routes for
            YouTube address space to peers in Pakistan. YouTube was
            temporarily denied service on a global basis as a result
            of a route leak beyond the Pakistani ISP's scope, but
            service was restored in approximately two hours because
            network operators around the world reconfigured their
            routers to ignore the bogus routes <xref
            target="RenesysPK"/>. In the context of SIDR and secure
            routing, a similar reconfiguration could theoretically be
            done if a resource certificate were to be revoked in order
            to block routing to a given network.
          </t>

          <t>
            In the DNS realm, one of the recent cases of U.S. law
            enforcement seizing domain names involved RojaDirecta, a
            Spanish web site. Even though several of the affected
            domain names belonged to Spanish organizations, they were
            subject to blocking by the U.S. government because certain
            servers were operated in the United States.  Government officials
            required the operators of the parent zones of a target
            name (e.g., "com" for "example.com") to direct queries for
            that name to a set of U.S.-government-operated name servers.
            Users of other services (e.g., email) under a target name 
            would thus be unable to locate the servers providing
            services for that name, denying them the ability to access
            these services.
          </t>

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

          <t>
            The action of the Dutch authorities against the RIPE NCC,
            where RIPE was ordered to freeze the accounts of Internet
            resource holders, is of a similar character. By
            controlling the account holders' WHOIS information, this
            type of action limited the ability of the ISPs in question
            to manage their Internet resources. This example is
            slightly different from the others because it does not
            immediately impact the ability of ISPs to provide
            connectivity. While ISPs use (and trust) the WHOIS
            databases to build route filters or use the databases for
            trouble-shooting information, the use of the WHOIS
            databases for those purposes is voluntary. Thus, seizure
            of this sort may not have any immediate effect on network
            connectivity, but it may impact overall trust in the
            common infrastructure. It is similar to the other examples
            in that action in one jurisdiction can have broader
            effects, and in that the global system may encourage
            networks to develop their own autonomous solutions.
          </t>
        </section>

        <section title="Summary">
          <t>
            In summary, rendezvous-based blocking can sometimes be
            used to immediately block a target service by removing
            some of the resources it depends on. However, such
            blocking actions can have harmful side effects due to the
            global nature of Internet resources and the fact that many
            different application-layer services rely on generic,
            global databases for rendezvous purposes. The fact that
            Internet resources can quickly shift between network
            locations, names, and addresses, together with the
            autonomy of the networks that comprise the Internet, can
            mean that the effects of rendezvous-based blocking can be
            negated on short order in some cases. For some
            applications, rendezvous services are optional to use, not
            mandatory. Hence, they are only effective when the endpoint
            or the endpoint's network chooses to use them; they can be
            routed around by choosing not to use
	    <?rfc needLines="-1"?>
	    the rendezvous
            service or migrating to an alternative one. To adapt a
            quote by John Gilmore, "The Internet treats blocking as
            damage and routes around it".
          </t>
        </section>
      </section>

      <section title="Endpoint-Based Blocking" anchor="End-Point-Blocking">
        <t>
          Internet users and their devices constantly make decisions
          as to whether to engage in particular Internet
          communications.  Users decide whether to click on links in
          suspect email messages; browsers advise users on sites that
          have suspicious characteristics; spam filters evaluate the
          validity of senders and messages. If the hardware and
          software making these decisions can be instructed not to
          engage in certain communications, then the communications
          are effectively blocked because they never happen.
        </t>

        <t>
          There are several systems in place today that advise user
          systems about which communications they should engage in. As
          discussed above, several modern browsers consult with "Safe
          Browsing" services before loading a web site in order to
          determine whether the site could potentially be
          harmful. Spam filtering is one of the oldest types of
          filtering in the Internet; modern filtering systems
          typically make use of one or more "reputation" or
          "blacklist" databases in order to make decisions about
          whether a given message or sender should be blocked.  These
          systems typically have the property that many filtering
          systems (browsers, Mail Transfer Agents (MTAs)) share a single reputation
          service. Even the absence of provisioned PTR records for
          an IP address may result in email messages not being
          accepted.
        </t>

        <section title="Scope">
          <t>
            In an endpoint-based blocking system, blocking actions are
            performed autonomously, by individual endpoints or their
            delegates.  The effects of blocking are thus usually local
            in scope, minimizing the effects on other users or other,
            legitimate services.
          </t>
        </section>

        <section title="Granularity">
          <t>
            Endpoint-based blocking avoids some of the limitations of
            rendezvous-based blocking: while rendezvous-based blocking
            can only see and affect the rendezvous service at hand
            (e.g., DNS name resolution), endpoint-based blocking can potentially see into
            the entire application, across all layers and
            transactions. This visibility can provide endpoint-based
            blocking systems with a much richer set of information for
            making narrow blocking decisions. Support for narrow granularity
            depends on how the application protocol client and server
            are designed, however. A typical endpoint-based firewall
            application
	    <?rfc needLines="-1"?>
	    may have less ability to make fine-grained decisions
            than an application that does its own blocking (see
            <xref target="RFC7288" /> for further discussion).
          </t>
        </section>

        <section title="Efficacy">
          <t>
            Endpoint-based blocking deals well with mobile
            adversaries. If a blocked service relocates resources or
            uses different resources, a rendezvous- or network-based
            blocking approach may not be able to affect the new
            resources (at least not immediately). A network-based
            blocking system may not even be able to tell whether the
            new resources are being used, if the previously blocked
            service uses secure protocols. By contrast, endpoint-based
            blocking systems can detect when a blocked service's
            resources have changed (because of their full visibility
            into transactions) and adjust blocking as quickly as new
            blocking data can be sent out through a reputation system.
          </t>
          <t>
            The primary challenge to endpoint-based blocking is that
            it requires the cooperation of endpoints. Where this
            cooperation is willing, this is a fairly low barrier,
            requiring only reconfiguration or software update. Where
            cooperation is unwilling, it can be challenging to enforce
            cooperation for large numbers of endpoints. That challenge
            is exacerbated when the endpoints are a diverse set of
            static, mobile, or visiting endpoints. If cooperation can
            be achieved, endpoint-based blocking can be much more
            effective than other approaches because it is so coherent
            with the Internet's architectural principles.
          </t>
        </section>

        <section title="Security">
          <t>
            Endpoint-based blocking is performed at one end of an
            Internet communication, and thus avoids the problems
            related to end-to-end security mechanisms that
            network-based blocking runs into and the challenges to
            global trust infrastructures that rendezvous-based
            blocking creates.
          </t>
        </section>

        <section title="Server Endpoints">
          <t>
            In this discussion of endpoint-based blocking, the focus has
            been on the consuming side of the end-to-end
            communication, mostly the client side of a client-server
            type connection. However, similar
            considerations apply to the content-producing side of
            end-to-end communications, regardless of whether that endpoint
            is a server in a client-server connection or a peer
            in a peer-to-peer type of connection.
          </t>
          <t>
            For instance, for blocking of web content, narrow targeting
            can be achieved through whitelisting methods like password
            authentication, whereby passwords are
            available only to authorized clients. For example, a web site
            might only make adult content available to users who provide credit card
            information, which is assumed to be a proxy for age.
          </t>
          <t>
            The fact that content-producing endpoints often do not take it upon
            themselves to block particular forms of content in response to
            requests from governments or other parties can sometimes motivate
            those latter parties to engage in blocking elsewhere within the Internet.
          </t>
          <t>
	    If a service is to be blocked, the best way of doing that is to
	    disable the service at the server endpoint.
          </t>
        </section>

        <section title="Summary">
          <t>
            Out of the three design patterns, endpoint-based blocking
            is the least likely to cause collateral damage to Internet
            services or the overall Internet architecture. Endpoint-based
            blocking systems can potentially see into all layers involved in a
            communication, allowing blocking to be narrowly targeted and can
            minimize unintended consequences. Adversary
            mobility can be accounted for as soon as reputation
            systems are updated with new adversary information. One
            potential drawback of endpoint-based blocking is that
            it requires the endpoint's cooperation; implementing
            blocking at an endpoint when it is not in the endpoint's
            interest is therefore difficult to accomplish because the
            endpoint's user can disable the blocking or switch to a different endpoint.
          </t>
        </section>
      </section>
    </section>

    <section title="Security Considerations" anchor="security">
      <t>
        The primary security concern related to Internet service
        blocking is the effect that it has on the end-to-end security
        model of many Internet security protocols. When blocking is
        enforced by an intermediary with respect to a given
        communication, the blocking system may need to obtain access
        to confidentiality-protected data to make blocking decisions.
        Mechanisms for obtaining such access often require the
        blocking system to defeat the authentication mechanisms built
        into security protocols.
     </t>

     <t>
        For example, some enterprise firewalls will dynamically create
        TLS certificates under a trust anchor recognized by endpoints
        subject to blocking. These certificates allow the firewall to
        authenticate as any web site, so that it can act as a
        man-in-the-middle on TLS
	<?rfc needLines="-1"?>
	connections passing through the
        firewall. This is not unlike an external attacker using
        compromised certificates to intercept TLS connections.
     </t>

     <t>
        Modifications such as these obviously make the firewall itself
        an attack surface. If an attacker can gain control of the
        firewall or compromise the key pair used by the firewall to
        sign certificates, the attacker will have access to the unencrypted data
        of all current and recorded TLS sessions for all users behind
        that firewall, in a way that is undetectable to
        users. Besides, if the compromised key-pairs can be extracted
        from the firewall, all users, not only those behind the
        firewall, that rely on that public key are vulnerable.
     </t>

     <t>
        We must also consider the possibility that a legitimate
        administrator of such a firewall could gain access to
        privacy-sensitive information, such as the bank accounts or health
        records of users who access such secure sites through
        the firewall. These privacy considerations motivate
        legitimate use of secure end-to-end protocols that often
        make it difficult to enforce granular blocking policies.
     </t>

     <t>
        When blocking systems are unable to inspect and surgically
        block secure protocols, it is tempting to completely block
        those protocols. For example, a web blocking system that is
        unable to inspect HTTPS connections might simply block any
        attempted HTTPS connection.  However, since Internet security
        protocols are commonly used for critical services such as
        online commerce and banking, blocking these protocols would
        block access to these services as well, or worse, force them
        to be conducted over insecure communication.
     </t>

     <t>
        Security protocols can, of course, also be used as mechanisms
        for blocking services. For example, if a blocking system can
        insert invalid credentials for one party in an authentication
        protocol, then the other end will typically terminate the
        connection based on the authentication failure. However, it is
        typically much simpler to simply block secure protocols than
        to exploit those protocols for service blocking.
     </t>
    </section>

    <section title="Conclusion">
<!-- Updated conclusion text from Eliot Lear, Feb. 4, 2015 -->
      <t>
        Filtering will continue to occur on the Internet.  We conclude that,
        whenever possible, filtering should be done on the endpoint.
        Cooperative endpoints are most likely to have sufficient contextual
        knowledge to effectively target blocking; hence, such blocking minimizes
        unintended consequences.  It is realistic to expect
        that at times filtering will not be done on the endpoints.  In these
        cases, promptly informing the endpoint that blocking has occurred
        provides necessary transparency to redress any errors, particularly
        as they relate to any collateral damage introduced by errant filters.
      </t>
      <t>
        Blacklist approaches are often a game of "cat and mouse", where those
        with the content move it around to avoid blocking.  Or, the content
        may even be naturally mirrored or cached at other legitimate
        sites such as the Internet Archive Wayback Machine <xref target="Wayback"/>.
        At the same time,
        whitelists provide similar risks because sites that had "acceptable"
        content may become targets for "unacceptable content", and similarly,
        access to perfectly inoffensive and perhaps useful or productive
        content is unnecessarily blocked. 
      </t>
      <t>
        From a technical perspective, there
        are no perfect or even good solutions -- there is only least bad.
        On that front, we posit that a hybrid approach that combines
        endpoint-based filtering with network filtering may prove least
        damaging.  An endpoint may choose to participate in a filtering
        regime in exchange for the network providing broader unfiltered
        access. 
      </t>
      <t>
        Finally, we note that where filtering is occurring to address
        content that is generally agreed to be inappropriate or illegal,
        strong cooperation among service providers and governments may provide
        additional means to identify both the victims and the perpetrators
        through non-filtering mechanisms, such as partnerships with the
        finance industry to identify and limit illegal transactions.
      </t>
<!-- PREVIOUS TEXT WAS:
      <t>
        Because it is least likely to create technical or architectural
        problems, endpoint-based blocking is the form of Internet
        service blocking that is least harmful to the Internet. From a
        technical perspective, it is the most preferred option because
        it maintains transparency of the network, vests functionality
        at the endpoints, can be applied granularly so as to avoid
        collateral damage, and accommodates mobile
        adversaries. Entities seeking to filter and for whom
        endpoint-based blocking is a potential choice should view its
        technical benefits as distinct advantages compared to the
        other approaches.
      </t>

      <t>
        In reality, the various approaches discussed above are all
        applied for different reasons, and particular entities may not
        consider endpoint-based filtering to be viable. Often, the
        choice of a filtering solution is constrained by practical
        limitations on which parts of the network are under the
        control of the party implementing filtering, and which parts
        of the network are trusted to cooperate. For example, an ISP
        that is subject to filtering requirements might implement a
        network-based filtering approach because it cannot be sure
        that endpoints will cooperate in filtering. As discussed
        above, government agencies tasked with disabling certain
        foreign web sites have done so by manipulating infrastructure
        servers that are within their own jurisdictions, based on
        legal claims to obtain access to those servers. An enterprise
        with filtering requirements might require employees to install
        a certain filtering software package on enterprise-owned PCs.
      </t>

      <t>
        It is therefore realistic to expect that certain entities will
        continue to attempt to conduct network- or rendezvous-based
        filtering since they may not have control over the endpoints
        they wish to affect or because the endpoints do not have
        incentives to consent to the filtering. In some cases, an
        approach that combines one of these with endpoint-based
        filtering can help strike a better balance. For example, a
        filtering system might make it possible for some endpoints to
        cooperate or "opt in" to additional endpoint-based filtering,
        rather than deploying a purely network-based solution.
      </t>

      <t>
        While this document has focused on technical mechanisms used
        to filter Internet content, a variety of non-technical
        mechanisms may also be available depending on the particular
        context and goals of the party seeking to
        restrict access to content. For example, purveyors of illegal
        online content can be pursued through international
        cooperation, by using the criminal justice system, and by
        targeting the funding that supports their activities through
        collaboration with financial services companies <xref
        target="click-trajectories"/>. Thus even in cases where
        endpoint-based filtering is not viewed as a viable means of
        restricting access to content, entities seeking to filter may
        find other strategies for achieving their goals that do not
        involve the operation of the Internet.
      </t>

      <t>
        Those with a desire to filter should take into account the
        limitations discussed in this document and holistically
        assess the space of technical and non-technical solutions at
        their disposal and the likely effectiveness of each
        combination of approaches.
      </t>
-->
    </section>


  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <references title="Informative References">
      &RFC1122;
<!--      &RFC2775;
      &RFC3724;
       <?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.blanchet-iab-internetoverport443.xml"?>
      <reference anchor="US-ICE"
                 target="http://www.ice.gov/doclib/news/library/factsheets/pdf/operation-in-our-sites.pdf">
        <front>
          <title>Operation in Our Sites</title>
          <author>
            <organization>U.S. Immigration and Customs
            Enforcement</organization>
          </author>
          <date year="2011"/>
        </front>
      </reference>

-->
      &RFC2826;
      &RFC2979;
      &RFC3261;
      &RFC4033;
      &RFC4084;
      &RFC4301;
      &RFC4924;
      &RFC4948;
      &RFC4949;
      &RFC5246;
      &RFC5782;
      &RFC6480;
      &RFC6698;
      &RFC6943;
      &RFC7288;
      &RFC1149;

      <reference anchor="RojaDirecta"
                 target="http://www.techdirt.com/articles/20110201/10252412910/homeland-security-seizes-spanish-domain-name-that-had-already-been-declared-legal.shtml">
        <front>
          <title>
            Homeland Security Seizes Spanish Domain Name That Had
            Already Been Declared Legal
          </title>
          <author fullname="Mike Masnick" initials="M.M." surname="Masnick">
            <organization>TechDirt</organization>
          </author>
          <date year="2011"/>
        </front>
      </reference>

      <reference anchor="SafeBrowsing"
                 target="https://developers.google.com/safe-browsing/">
        <front>
          <title>Safe Browsing API</title>
          <author>
            <organization>Google</organization>
          </author>
          <date year="2012"/>
        </front>
      </reference>

      <reference anchor="GhostClickRIPE"
                 target="http://www.ripe.net/internet-coordination/news/about-ripe-ncc-and-ripe/ripe-ncc-blocks-registration-in-ripe-registry-following-order-from-dutch-police">
        <front>
          <title>RIPE NCC Blocks Registration in RIPE Registry Following Order
          from Dutch Police</title>
          <author>
            <organization>RIPE NCC</organization>
          </author>
          <date year="2012"/>
        </front>
      </reference>

      <reference anchor="Telex" target="https://telex.cc/">
        <front>
          <title>Telex: Anticensorship in the Network Infrastructure</title>
          <author fullname="Eric Wustrow" initials="E." surname="Wustrow"/>
          <author fullname="Scott Wolchok" initials="S." surname="Wolchok"/>
          <author fullname="Ian Goldberg" initials="I." surname="Goldberg"/>
          <author fullname="J. Alex Halderman" initials="J.A."
                  surname="Halderman"/>
          <date month="August" year="2011"/>
        </front>
      </reference>

      <reference anchor="RenesysPK"
                 target="http://www.renesys.com/blog/2008/02/pakistan_hijacks_youtube_1.shtml">
        <front>
          <title>Pakistan hijacks YouTube</title>
          <author fullname="Martin A. Brown" initials="M." surname="Brown">
            <organization>Renesys</organization>
          </author>
          <date month="February" year="2008"/>
        </front>
      </reference>

<!--      <reference anchor="EarthquakeHT"
                 target="http://www.apricot.net/apricot2010/__data/assets/pdf_file/0019/19018/Lightning-Talk_03_Gaurab-Upadhaya-dotht-apricot-lightning.pdf">
        <front>
          <title>.ht: Recovering DNS from the Quake</title>
          <author fullname="Gaurab Raj Upadhaya" initials="G."
                  surname="Raj Upadhaya">
            <organization>PCH</organization>
          </author>
          <date month="March" year="2010"/>
        </front>
      </reference>
-->
      <reference anchor="ISOCFiltering"
                 target="http://www.internetsociety.org/what-we-do/issues/dns/finding-solutions-illegal-line-activities">
        <front>
          <title>DNS: Finding Solutions to Illegal On-line Activities</title>
          <author fullname="" initials="" surname="">
            <organization>Internet Society</organization>
          </author>
          <date month="" year="2012"/>
        </front>
      </reference>

      <reference anchor="Tor" target="https://www.torproject.org/">
        <front>
          <title>Tor Project: Anonymity Online</title>
          <author fullname="" initials="" surname=""/>
          <date month="" year="2012"/>
        </front>
      </reference>

<!--      <reference anchor="click-trajectories"
                 target="http://cseweb.ucsd.edu/~savage/papers/Oakland11.pdf">
        <front>
          <title>Click Trajectories: End-to-End Analysis of the Spam Value
          Chain</title>
          <author fullname="Kirill Levchenko" initials="K."
                  surname="Levchenko"/>
          <author fullname="Andreas Pitsillidis" initials="A."
                  surname="Pitsillidis"/>
          <author fullname="Neha Chachra" initials="N." surname="Chacra"/>
          <author fullname="Brandon Enright" initials="B." surname="Enright"/>
          <author fullname="Mark Felegyhazi" initials="M."
                  surname="Felegyhazi"/>
          <author fullname="Chris Grier" initials="C." surname="Grier"/>
          <author fullname="Tristan Halvorson" initials="T."
                  surname="Halvorson"/>
          <author fullname="Christian Kreibich" initials="C."
                  surname="Kreibich"/>
          <author fullname="He Liu" initials="H." surname="Liu"/>
          <author fullname="Damon McCoy" initials="D." surname="McCoy"/>
          <author fullname="Nicholas Weaver" initials="N." surname="Weaver"/>
          <author fullname="Vern Paxson" initials="V." surname="Paxson"/>
          <author fullname="Geoffrey M. Voelker" initials="G.M."
                  surname="Voelker"/>
          <author fullname="Stefan Savage" initials="S." surname="Savage"/>
          <date month="" year="2011"/>
        </front>
      </reference>
-->
      <reference anchor="BT-TPB"
                 target="http://www.zdnet.com/bt-blocks-the-pirate-bay-4010026434/">
        <front>
          <title>BT blocks The Pirate Bay</title>
          <author fullname="David Meyer" initials="D." surname="Meyer"/>
          <date day="20" month="June" year="2012"/>
        </front>
      </reference>

      <!--
          <reference anchor="TPB-cloud" target="http://thepiratebay.se/blog/224">
            <front>
              <title>The Pirate Cloud</title>
              <author/>
              <date day="17" month="October" year="2012"/>
            </front>
          </reference>
        -->

      <reference anchor="IN-OM-filtering"
                 target="https://citizenlab.org/2012/07/routing-gone-wild/">
        <front>
          <title>Routing Gone Wild</title>
          <author fullname="Citizen Lab" surname="Citizen Lab"/>
          <date day="12" month="July" year="2012"/>
        </front>
      </reference>

<!--      <reference anchor="CCS-GFC-collateral-damage"
                 target="http://conferences.sigcomm.org/sigcomm/2012/paper/ccr-paper266.pdf">
        <front>
          <title>The Collateral Damage of Internet Censorship by DNS
          Injection</title>
          <author/>
          <date day="" month="July" year="2012"/>
        </front>
      </reference>
-->
      <reference anchor="SAC-056"
         target="http://www.icann.org/en/groups/ssac/documents/sac-056-en.pdf">
        <front>
          <title>SSAC Advisory on Impacts of Content Blocking via the Domain Name System</title>
          <author/>
          <date day="09" month="October" year="2012"/>
        </front>
      </reference>

      <reference anchor="Wayback"
         target="http://archive.org/web/">
        <front>
          <title>Internet Archive Wayback Machine</title>
          <author/>
          <date/>
        </front>
      </reference>

    <reference anchor="Morris"
                 target="http://groups.csail.mit.edu/mac/classes/6.805/articles/morris-worm.html">
        <front>
          <title>The Robert Morris Internet Worm</title>
          <author fullname="Brendan P. Kehoe" initials="B.P." surname="Kehoe"/>
          <date year="1992"/>
        </front>
      </reference>

      <reference anchor="Malicious-Resolution"
                 target="http://www.citi.umich.edu/u/provos/papers/ndss08_dns.pdf">
        <front>
          <title>Corrupted DNS Resolution Paths: The Rise of a Malicious Resolution Authority</title>
          <author fullname="David Dagon" initials="D." surname="Dagon"/>
          <author fullname="Niels Provos" initials="N." surname="Provos"/>
          <author fullname="Christopher P. Lee" initials="C.P." surname="Lee"/>
          <author fullname="Wenke Lee" initials="W." surname="Lee"/>
          <date year="2008"/>
        </front>
      </reference>

      <reference anchor="asymmetry"
         target="http://www.caida.org/publications/papers/2010/estimating_routing_symmetry/estimating_routing_symmetry.pdf">
        <front>
          <title>Estimating routing symmetry on single links by passive flow measurements</title>
          <author fullname="Wolfgang John" initials="W." surname="John"/>
          <author fullname="Maurizio Dusi" initials="M." surname="Dusi"/>
          <author fullname="K.C. Claffy"   initials="K." surname="Claffy"/>
          <date year="2010" />
        </front>
      </reference>

      <reference anchor="Poort"
         target="http://staff.science.uva.nl/~vdham/research/publications/1401-Baywatch.pdf">
        <front>
          <title>Baywatch: Two approaches to measure the effects of
 blocking access to The Pirate Bay</title>
          <author fullname="Joost Poort" initials="J." surname="Poort"/>
          <author fullname="Jorna Leenheer" initials="J." surname="Leenheer"/>
          <author fullname="Jeroen van der Ham" initials="J." surname="van der Ham"/>
          <author fullname="Cosmin Dumitru" initials="C." surname="Dumitru"/>
          <date year="2014" />
        </front>
        <seriesInfo name="Telecommunications Policy" value="38:383-392"/>
      </reference>
      <reference anchor="CleanFeed"
         target="http://www.cl.cam.ac.uk/~rnc1/cleanfeed.pdf">
        <front>
          <title>Failures in a Hybrid Content Blocking System</title>
          <author fullname="Richard Clayton" initials="R." surname="Clayton"/>
          <date year="2005" />
        </front>
        <seriesInfo name="Fifth Privacy Enhancing Technologies Workshop, PET" value="2005"/>
      </reference>
      <reference anchor="Takedown08"
         target="http://www.econinfosec.org/archive/weis2008/papers/MooreImpact.pdf">
        <front>
          <title>The Impact of Incentives on Notice and Take-down </title>
          <author fullname="Tyler Moore" initials="T." surname="Moore"/>
          <author fullname="Richard Clayton" initials="R." surname="Clayton"/>
          <date year="2008" />
        </front>
        <seriesInfo name="Workshop on the Economics of Information
        Security" value="2008"/>
      </reference>
      <reference anchor="BlackLists14"
         target="http://www.econinfosec.org/archive/weis2014/papers/Chachra-WEIS2014.pdf">
        <front>
          <title>Empirically Characterizing Domain Abuse and the
          Revenue Impact of Blacklisting</title>
          <author fullname="Neha Chachra" initials="N." surname="Chachra"/>
          <author fullname="Damon McCoy" initials="D." surname="McCoy"/>
          <author fullname="Stefan Savage" initials="S." surname="Savage"/>
          <author fullname="Geoffrey M. Voelker" initials="G.M." surname="Voelker"/>
          <date />
        </front>
        <seriesInfo name="Workshop on the Economics of Information
        Security" value="2014"/>
      </reference>
      <reference anchor="NW08"
        target="http://www.networkworld.com/article/2284273/software/youtube-pakistan-incident--could-something-similar-whack-your-site-.html">
        <front>
          <title>YouTube/Pakistan incident: Could something similar
            whack your site?</title>
          <author fullname="Carolyn Duffy Marsan" initials="C.D"
                  surname="Marsan"/>
          <date year="2008" month="March"/>
        </front>
        <seriesInfo name="NetWorld" value="2008"/>
        </reference>
      &RFC2827;
      &RFC3704;
    </references>

    <section title="IAB Members at the Time of Approval" numbered="no">
        <figure>
            <artwork>
Jari Arkko
Mary Barnes
Marc Blanchet
Ralph Droms
Ted Hardie
Joe Hildebrand
Russ Housley
Erik Nordmark
Robert Sparks
Andrew Sullivan
Dave Thaler
Brian Trammell
Suzanne Woolf
            </artwork>
        </figure>
      <?rfc needLines="-1"?>
    </section>

    <section title="Acknowledgments" numbered="no">
        <t> Thanks to the many reviewers who provided helpful comments,
            especially Bill Herrin, Eliot Lear, Patrik Faltstrom,
            Pekka Savola, and Russ White.  NLnet Labs is also
            acknowledged as Kolkman's employer during most of this
            document's development.
        </t>
    </section>


  </back>



</rfc>
