[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-barnes-blocking-considerations) 00 01 02 03 04 05 06 07 08 09 RFC 7754

Internet Architecture Board                                    R. Barnes
Internet-Draft                                          BBN Technologies
Intended status: Informational                                 A. Cooper
Expires: January 16, 2014                                            CDT
                                                              O. Kolkman
                                                              NLnet Labs
                                                           July 15, 2013


  Technical Considerations for Internet Service Blocking and Filtering
               draft-iab-filtering-considerations-03.txt

Abstract

   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.  In general, 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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 16, 2014.

Copyright Notice




Barnes, et al.          Expires January 16, 2014                [Page 1]


Internet-Draft          Filtering Considerations               July 2013


   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Filtering Examples  . . . . . . . . . . . . . . . . . . . . .   4
   3.  Characteristics of Blocking Systems . . . . . . . . . . . . .   6
     3.1.  Entities that set blocking policies . . . . . . . . . . .   6
     3.2.  Purposes of blocking  . . . . . . . . . . . . . . . . . .   6
     3.3.  Intended targets of blocking  . . . . . . . . . . . . . .   7
     3.4.  Components used for blocking  . . . . . . . . . . . . . .   7
   4.  Evaluation of Blocking Design Patterns  . . . . . . . . . . .   9
     4.1.  Criteria for evaluation . . . . . . . . . . . . . . . . .   9
       4.1.1.  Scope: What content or services can be blocked? . . .   9
       4.1.2.  Granularity: How specific is the blocking?  Will
               blocking one service also block others? . . . . . . .  10
       4.1.3.  Efficacy: How easy is it for a resource or service to
               avoid being blocked?  . . . . . . . . . . . . . . . .  11
       4.1.4.  Security: How does the blocking impact existing trust
               infrastructures?  . . . . . . . . . . . . . . . . . .  11
     4.2.  Network-Based Blocking  . . . . . . . . . . . . . . . . .  12
       4.2.1.  Scope . . . . . . . . . . . . . . . . . . . . . . . .  12
       4.2.2.  Granularity . . . . . . . . . . . . . . . . . . . . .  13
       4.2.3.  Efficacy and security . . . . . . . . . . . . . . . .  14
       4.2.4.  Summary . . . . . . . . . . . . . . . . . . . . . . .  15
     4.3.  Rendezvous-Based Blocking . . . . . . . . . . . . . . . .  16
       4.3.1.  Scope . . . . . . . . . . . . . . . . . . . . . . . .  16
       4.3.2.  Granularity . . . . . . . . . . . . . . . . . . . . .  17
       4.3.3.  Efficacy  . . . . . . . . . . . . . . . . . . . . . .  17
       4.3.4.  Security and other implications . . . . . . . . . . .  17
       4.3.5.  Examples  . . . . . . . . . . . . . . . . . . . . . .  17
       4.3.6.  Summary . . . . . . . . . . . . . . . . . . . . . . .  19
     4.4.  Endpoint-Based Blocking . . . . . . . . . . . . . . . . .  19
       4.4.1.  Scope and granularity . . . . . . . . . . . . . . . .  20
       4.4.2.  Efficacy  . . . . . . . . . . . . . . . . . . . . . .  20
       4.4.3.  Security  . . . . . . . . . . . . . . . . . . . . . .  21
       4.4.4.  Summary . . . . . . . . . . . . . . . . . . . . . . .  21



Barnes, et al.          Expires January 16, 2014                [Page 2]


Internet-Draft          Filtering Considerations               July 2013


   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  21
   6.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .  22
   7.  Informative References  . . . . . . . . . . . . . . . . . . .  23
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  26

1.  Introduction

   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 [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.

   Efforts to restrict or deny access to Internet resources and services
   have evolved over time.  As noted in [RFC4084], some Internet service
   providers impose restrictions on 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.  Increasingly, however, both
   governmental and private sector entities are seeking to block or
   filter access to certain content, traffic, or services without the
   knowledge or agreement of affected users.  Where these entities do
   not directly control networks themselves, they commonly aim to make
   use of intermediary systems to effectuate the blocking or filtering.

   While blocking and filtering remain highly contentious in many cases,
   the desire to restrict access to content will likely continue to
   exist.

   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 effectuated 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.





Barnes, et al.          Expires January 16, 2014                [Page 3]


Internet-Draft          Filtering Considerations               July 2013


   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.  Enforcement of blocking via contractual terms or legal
   action is out of scope, although at times these actions ultimately
   result in the application of technical mechanisms.

   Filtering may be considered legal, illegal, ethical, or unethical in
   different places, at different times, and by different parties.  This
   document is intended for an audience of entities that are conducting
   filtering or are considering conducting filtering and who 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.

   In [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.

2.  Filtering Examples

   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 entities
   and for different purposes.

   Firewalls: Firewalls are a very common tool used for service
   blocking, employed at many points in today's Internet.  Typically,
   firewalls block according to content-neutral rules, e.g., blocking
   all inbound connections or outbound connections on certain ports,
   protocols and network layer addresses.  More advanced configurations
   perform deep packet inspection or traffic flow analysis and filter or
   block based on rich (content-specific) rules and policies.  Many
   firewalls include web filtering capabilities (see below).  Firewalls
   can be deployed either on end hosts (under user or administrator
   control), or at network boundaries.

   Web Filtering: HTTP and HTTPS are common targets for blocking and
   filtering, typically targeted at specific URLs.  Some enterprises use



Barnes, et al.          Expires January 16, 2014                [Page 4]


Internet-Draft          Filtering Considerations               July 2013


   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 URL 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 only on IP
   address, 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."
   These portals present their own HTTPS certificates that are invalid
   for any given domain according to normal validation rules, but may
   still be trusted if the user installs a security exception.  (See
   further discussion in Section 5.)

   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 Reverse Black Lists use the reverse DNS to
   flag whether an IP address is a known spam source [RFC5782].  Spam
   filters are typically either installed on user devices (e.g., in a
   mail client) or operated by a mail domain on behalf of users.

   Domain name seizure: In recent years, US law enforcement authorities
   have been issuing legal orders to domain name registries to seize
   domain names associated with the distribution of counterfeit goods
   and other alleged illegal activity [US-ICE].  When domain names are
   seized, DNS queries for the seized names are typically redirected to
   resolve to U.S. government IP addresses that host information about
   the seizure.  The effectiveness of domain seizures is limited by
   application mobility -- applications using the seized name can switch
   to using another name.  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 [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 [RFC4033], potentially causing validation
   failures by validating end-nodes.

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





Barnes, et al.          Expires January 16, 2014                [Page 5]


Internet-Draft          Filtering Considerations               July 2013


   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 [GhostClickRIPE](also
   see Section 4.3).  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 [RFC6480], potentially for the
   purpose of denying targeted networks access to the Internet.

3.  Characteristics of Blocking Systems

   At a generic level, blocking systems can be characterized by four
   attributes: the entity that sets the blocking policy, the purpose of
   the blocking, the intended target of the blocking, and the Internet
   component(s) used as the basis of the blocking system.

3.1.  Entities that set blocking policies

   Parties that institute blocking policies include governments,
   enterprises, network operators, application providers, and individual
   end users.  In some cases, these parties use their own technical
   assets to conduct blocking; 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.  In other cases, particularly in the case of
   blocking initiated by governments, the entity that institutes the
   blocking policy works with other entities to effectuate blocking
   using technical assets that it does not control.

3.2.  Purposes of blocking

   Entities may be motivated to filter for a variety of purposes:

   o  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.

   o  Restricting objectionable content or services.  Certain
      communications may be viewed as undesirable, harmful, or illegal
      by particular governments, enterprises, or users (e.g., parents).
      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



Barnes, et al.          Expires January 16, 2014                [Page 6]


Internet-Draft          Filtering Considerations               July 2013


      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.

   o  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).

   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.

3.3.  Intended targets of blocking

   Entities institute blocking systems 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 URLs whose content is deemed by the
   enterprise to be inappropriate for the work place.  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.

   As discussed in Section 4, the design of a blocking system may affect
   content, services, or endpoints other than those that are the
   intended targets.  For example, the domain name seizures described
   above target particular web pages associated with illegal activity,
   but 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 unrelated to the illegal activity.

3.4.  Components used for blocking

   Broadly speaking, the process of a delivering an Internet service
   involves three different components:






Barnes, et al.          Expires January 16, 2014                [Page 7]


Internet-Draft          Filtering Considerations               July 2013


   1.  Endpoints: The actual content of the service is an application
       layer protocol between two Internet hosts.  In many protocols,
       there are two endpoints, a client and a server.

   2.  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.

   3.  Rendezvous services: Service endpoints are typically identified
       by identifiers than are more "human-friendly" than IP addresses.
       Rendezvous services allow one endpoint to figure out how to
       contact another endpoint based on an identifier.

   Consider, for example, an HTTP transaction fetching the content of
   the URI <http://example.com/index.html>.  The client endpoint is an
   end host running a browser.  The client uses the DNS as a rendezvous
   service when it 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 then responds to the HTTP request.

   As another example, in the SIP protocol, the client and server are IP
   phones, and the rendezvous service is provided by an application-
   layer SIP proxy as well as the DNS.

   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:

   o  [Endpoint] Preventing the client from making the request

   o  [Endpoint] Preventing the server from responding to the request

   o  [Network] Preventing the request from reaching the server

   o  [Network] Preventing the response from reaching the client

   o  [Network] Preventing the client from reaching the DNS server

   o  [Rendezvous] Preventing the DNS server from providing the client
      the correct IP address of the server

   Most entities that desire to block communications will have access to
   only one or two components, and therefore their choices for how to
   effectuate blocking will be limited.  End users and application



Barnes, et al.          Expires January 16, 2014                [Page 8]


Internet-Draft          Filtering Considerations               July 2013


   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 effectuate filtering.

   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 which
   kind of entity 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 entity that desires to 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.

4.  Evaluation of Blocking Design Patterns

4.1.  Criteria for evaluation

   To evaluate the technical implications of each of the blocking design
   patterns, we compare them based on four criteria: scope, granularity,
   efficacy, and security.

4.1.1.  Scope: What content or services can be blocked?

   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 scope.  For example, blocking within an
   access network will only affect a relatively small, well-defined set
   of users (namely, those connected to the access network), but can
   affect all applications for those users.  Blocking effectuated 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



Barnes, et al.          Expires January 16, 2014                [Page 9]


Internet-Draft          Filtering Considerations               July 2013


   a single service or in a single network location can have broad
   effects in multiple directions.  Blocking systems are generally
   viewed as less objectionable if the scope of their impact is as
   narrow as possible while still being effective.

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

   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 [RFC1122], especially Section 1.1.3).  The
   functions at these layers are developed autonomously and almost
   always operated by different entities.  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.

   As a result of this structure, actions taken at one layer can affect
   functionality or applications at higher 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.

   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.









Barnes, et al.          Expires January 16, 2014               [Page 10]


Internet-Draft          Filtering Considerations               July 2013


   Design flaws in blocking systems may also cause the effects of
   blocking to be overbroad.  For example, web filtering systems in
   India and China have been shown to cause "collateral damage" by
   unwittingly blocking users in Oman and the US from accessing web
   sites in Germany and Korea
   [IN-OM-filtering][CCS-GFC-collateral-damage].

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

   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,
   [Malicious-Resolution]).  Likewise, services that rely on blocked
   resources can often be rapidly re-configured to use non-blocked
   resources.  If a web site is prevented from using a domain name or
   set of IP addresses, the web site can simply move to another domain
   name or network.  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 jursidictions to prevent
   spam blocking from being effective.

   In the presence of either blacklist or whitelist systems, users may
   choose to use different sets of protocols or otherwise alter their
   traffic characteristics to circumvent filters.  As discussed in
   [I-D.blanchet-iab-internetoverport443], many applications shift their
   traffic to port 80 or 443 when other ports are blocked.  If voice
   communication based on SIP [RFC3261] is blocked, users are likely to
   use proprietary protocols that allow them to talk to each other.
   Thus distribution and mobility can hamper efforts to block
   communications in a number of ways.

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

   Modern security mechanisms rely on trusted hosts communicating via a
   secure channel without intermediary interference.  Protocols such as
   TLS and IPsec [RFC5246][RFC4301] are designed to ensure that each
   endpoint of the communication knows the identity of the other
   endpoint, 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.





Barnes, et al.          Expires January 16, 2014               [Page 11]


Internet-Draft          Filtering Considerations               July 2013


   Some blocking strategies require intermediaries to insert themselves
   within the end-to-end communications path, potentially breaking
   security properties of Internet protocols.  In these cases it can be
   difficult or impossible for endpoints to distinguish between
   attackers and "authorized" entities conducting blocking.

4.2.  Network-Based Blocking

   Being able to block access to resources without the consent or
   cooperation of either endpoint to a communication is viewed as a
   desirable feature by some entities 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 URL being requested,
   compare that URL to a list of black-listed or white-listed URLs, and
   allow the request to proceed only if it is permitted by policy (or at
   least not forbidden).  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
   ACLs, filter traffic based on lower layer criteria (transport
   protocol and source or destination addresses or ports).

   Intermediary systems used for blocking are often not far from the
   edge of the network.  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 Section 4.4 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.

4.2.1.  Scope








Barnes, et al.          Expires January 16, 2014               [Page 12]


Internet-Draft          Filtering Considerations               July 2013


   Network-based approaches to blocking run into several technical
   issues that limit their viability in practice.  In particular, many
   issues arise from the fact that an intermediary needs to have access
   to a sufficient amount of traffic to make its blocking
   determinations.

   For residential or consumer networks with many egress points, the
   first challenge to obtaining this traffic is simply gaining access to
   the constituent packets.  The Internet is designed to deliver packets
   hop-by-hop from source to destination -- not to any particular point
   along the way.  In practice, inter-network routing is often
   asymmetric, and for sufficiently complex local networks, intra-
   network traffic flows can be asymmetric as well [asymmetry].

   This asymmetry means that an intermediary in a network with many
   egress points will often 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 URLs cannot make accurate blocking
   decisions if it is only in the data path for HTTP responses and not
   requests.  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.

4.2.2.  Granularity

   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 (URLs or
   other content).  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 entities that seek to block may balance these attributes
   against each other when choosing a blocking system.









Barnes, et al.          Expires January 16, 2014               [Page 13]


Internet-Draft          Filtering Considerations               July 2013


4.2.3.  Efficacy and security

   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.  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 [BT-TPB][TPB-cloud].

   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.  Since security
   protocols are 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) enable users to detect these sort
   of intermediaries.  Those users are then likely to act as if the
   service is blocked.

   If the intermediary is unable to decrypt the security protocol, then
   its blocking determinations for secure sessions can only be based on
   unprotected attributes, such as IP addresses, protocol IDs and port
   numbers.  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.

   However, as the Telex project 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 [Telex].  For example, if an ISP used by a banking website
   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).

   Thus, in principle in a blacklist system it is impossible to block
   tunneled traffic through an intermediary device without blocking all
   secure traffic.  (The only limitation in practice is the requirement



Barnes, et al.          Expires January 16, 2014               [Page 14]


Internet-Draft          Filtering Considerations               July 2013


   for special software on the client.)  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.  If
   governments or network operators were to force these services to use
   insecure protocols so as to effectuate blocking, they would expose
   their users to the various attacks that the security protocols were
   put in place to prevent.

   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.

   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 [Tor].  Thus,
   network-based blocking becomes less effective over time.

   Network-based blocking is a key contributor to the arms race that has
   led to the development of these kinds of 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.

4.2.4.  Summary

   In sum, network-based blocking is only effective in a fairly
   constrained set of circumstances.  First, the traffic needs to flow
   through the network in such a way that the intermediary device has
   access to any communications it intends to block.  Second, the
   blocking system needs an out-of-band mechanism to mitigate the risk
   of secure protocols being used to avoid blocking (e.g., human



Barnes, et al.          Expires January 16, 2014               [Page 15]


Internet-Draft          Filtering Considerations               July 2013


   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.

4.3.  Rendezvous-Based Blocking

   Internet applications often require or rely on support from common,
   global rendezvous services, including the DNS, certificate
   authorities, 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) will rely on presence and session
   information supplied by SIP servers.

   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; the RPKI about which entities have been
   allocated IP addresses.  To offer specialized Internet services and
   applications, different entities 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).

   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.

4.3.1.  Scope

   In the case of government-initated blocking, the servers that are
   used to provide rendezvous services exist within specific
   jurisdictions, and their operators are thus subject to jurisdictional
   laws.  It is thus possible for laws to be structured to effectuate
   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).




Barnes, et al.          Expires January 16, 2014               [Page 16]


Internet-Draft          Filtering Considerations               July 2013


   The scope of blocking conducted by other entities will depend on
   which servers those entities 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.

4.3.2.  Granularity

   Blocking based on global rendezvous services tends to be overbroad,
   causing collateral damage to legitimate uses of a resource.  For
   example, a given address or domain name might host both legitimate
   services and services that governments desire to block.  A service
   hosted under a domain name and operated in a jurisdiction where it is
   considered undesirable might be considered legitimate in another
   jurisdiction; a blocking action in the host jurisdiction would deny
   legitimate services in the other.

4.3.3.  Efficacy

   The distributed nature of the Internet limits the efficacy of
   blocking based on rendezvous services.  If the Internet community
   realizes that a blocking decision has been made and wishes to counter
   it, then local networks can "patch" the authoritative data that the
   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.

4.3.4.  Security and other implications

   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 balkanisation, 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 ISOC's whitepaper on DNS
   filtering [ISOCFiltering], but they also apply to other global
   Internet resources.

4.3.5.  Examples




Barnes, et al.          Expires January 16, 2014               [Page 17]


Internet-Draft          Filtering Considerations               July 2013


   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), jusrisdiction-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.

   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 Pakistan ISP's
   scope, but service was restored in approximately two hours because
   network operators around the world re-configured their routers to
   ignore the bogus routes [RenesysPK].  In the context of SIDR and
   secure routing, a similar re-configuration could theoretically be
   done if a resource certificate were to be revoked in order to block
   routing to a given network.

   In the DNS realm, one of the recent cases of US law enforcement
   seizing domain names involved RojaDirecta, a Spanish web site.  Even
   though several of the affected domain names belonged to Spanish
   entities, they were subject to blocking by the US government because
   certain servers were operated in the US.  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
   US-government-operated name servers.  Users of other services under a
   target name (e.g. e-mail) would thus be unable to locate the servers
   providing services for that name, denying them the ability to access
   these services.

   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
   un-blocked results for the affected name.  However, depending on
   availability of valid signature data, these types of workarounds will
   not work with DNSSEC-signed data.

   The action of the Dutch authorities against the RIPE NCC, where RIPE
   was ordered to freeze the accounts 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



Barnes, et al.          Expires January 16, 2014               [Page 18]


Internet-Draft          Filtering Considerations               July 2013


   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.

4.3.6.  Summary

   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
   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".

4.4.  Endpoint-Based Blocking

   [TO DO: Should this section only address "user"-based blocking or
   should it also discuss server-based blocking (e.g., a web server that
   prevents abusive users from accessing content?)]

   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.

   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"



Barnes, et al.          Expires January 16, 2014               [Page 19]


Internet-Draft          Filtering Considerations               July 2013


   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, MTAs) share a single
   reputation service.  Even the absence of a provisioned PTR records
   for an IP address may result in email messages not being accepted.

4.4.1.  Scope and granularity

   Endpoint-based blocking lacks 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 (depending on how it is designed) can have
   visibility 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.

   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.

4.4.2.  Efficacy

   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.

   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.





Barnes, et al.          Expires January 16, 2014               [Page 20]


Internet-Draft          Filtering Considerations               July 2013


4.4.3.  Security

   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.

4.4.4.  Summary

   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 have
   full visibility into all layers involved in a communication, allowing
   blocking to be narrowly targeted.  Adversary mobility can be
   accounted for as soon as reputation systems are updated with new
   adversary information.  The one potential drawback of endpoint-based
   blocking is that it requires the endpoint's cooperation; effectuating
   blocking at an endpoint when it is not in the endpoint's interest is
   therefore difficult to accomplish.

5.  Security Considerations

   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.

   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 website, so that it can act as a man-in-the-middle on TLS
   connections passing through the firewall.  This is not unlike an
   external attacker using compromised certificates to intercept TLS
   connections.

   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, he
   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.



Barnes, et al.          Expires January 16, 2014               [Page 21]


Internet-Draft          Filtering Considerations               July 2013


   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.

   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.

6.  Conclusion

   Because it 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.

   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 entity 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.

   It is therefore realistic to expect that certain entities will
   continue to attempt to conduct network- or rendezvous-based filtering



Barnes, et al.          Expires January 16, 2014               [Page 22]


Internet-Draft          Filtering Considerations               July 2013


   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.

   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 public or private entity 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
   [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.

   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.

7.  Informative References

   [BT-TPB]   Meyer, D., "BT blocks The Pirate Bay", June 2012, <http://
              www.zdnet.com/bt-blocks-the-pirate-bay-4010026434/>.

   [CCS-GFC-collateral-damage]
              , "The Collateral Damage of Internet Censorship by DNS
              Injection", July 2012, <http://conferences.sigcomm.org/
              sigcomm/2012/paper/ccr-paper266.pdf>.

   [GhostClickRIPE]
              RIPE NCC, "RIPE NCC Blocks Registration in RIPE Registry
              Following Order from Dutch Police", 2012, <http://
              www.ripe.net/internet-coordination/news/about-ripe-ncc-
              and-ripe/ripe-ncc-blocks-registration-in-ripe-registry-
              following-order-from-dutch-police>.

   [I-D.blanchet-iab-internetoverport443]
              Blanchet, M., "Implications of Blocking Outgoing Ports
              Except Ports 80 and 443", draft-blanchet-iab-
              internetoverport443-01 (work in progress), October 2012.



Barnes, et al.          Expires January 16, 2014               [Page 23]


Internet-Draft          Filtering Considerations               July 2013


   [IN-OM-filtering]
              Citizen Lab, ., "Routing Gone Wild", July 2012, <https://
              citizenlab.org/2012/07/routing-gone-wild/>.

   [ISOCFiltering]
              Internet Society, "DNS: Finding Solutions to Illegal On-
              line Activities", 2012, <http://www.internetsociety.org/
              what-we-do/issues/dns/finding-solutions-illegal-line-
              activities>.

   [Malicious-Resolution]
              Dagon, D., Provos, N., Lee, C., and W. Lee, "Corrupted DNS
              Resolution Paths: The Rise of a Malicious Resolution
              Authority", 2008, <http://www.citi.umich.edu/u/provos/
              papers/ndss08_dns.pdf>.

   [Morris]   Kehoe, B., "The Robert Morris Internet Worm", 1992, <http:
              //groups.csail.mit.edu/mac/classes/6.805/articles/morris-
              worm.html>.

   [RFC1122]  Braden, R., "Requirements for Internet Hosts -
              Communication Layers", STD 3, RFC 1122, October 1989.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements", RFC
              4033, March 2005.

   [RFC4084]  Klensin, J., "Terminology for Describing Internet
              Connectivity", BCP 104, RFC 4084, May 2005.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

   [RFC5782]  Levine, J., "DNS Blacklists and Whitelists", RFC 5782,
              February 2010.

   [RFC6480]  Lepinski, M. and S. Kent, "An Infrastructure to Support
              Secure Internet Routing", RFC 6480, February 2012.

   [RenesysPK]



Barnes, et al.          Expires January 16, 2014               [Page 24]


Internet-Draft          Filtering Considerations               July 2013


              Brown, M., "Pakistan hijacks YouTube", February 2008,
              <http://www.renesys.com/blog/2008/02/
              pakistan_hijacks_youtube_1.shtml>.

   [RojaDirecta]
              Masnick, M., "Homeland Security Seizes Spanish Domain Name
              That Had Already Been Declared Legal", 2011, <http://
              www.techdirt.com/articles/20110201/10252412910/homeland-
              security-seizes-spanish-domain-name-that-had-already-been-
              declared-legal.shtml>.

   [SAC-056]  , "SSAC Advisory on Impacts of Content Blocking via the
              Domain Name System", October 2012, <http://www.icann.org/
              en/groups/ssac/documents/sac-056-en.pdf>.

   [SafeBrowsing]
              Google, "Safe Browsing API", 2012, <https://
              developers.google.com/safe-browsing/>.

   [TPB-cloud]
              , "The Pirate Cloud", October 2012,
              <http://thepiratebay.se/blog/224>.

   [Telex]    Wustrow, E., Wolchok, S., Goldberg, I., and J. Halderman,
              "Telex: Anticensorship in the Network Infrastructure",
              August 2011, <https://telex.cc/>.

   [Tor]      , "Tor Project: Anonymity Online", 2012, <https://
              www.torproject.org/>.

   [US-ICE]   U.S. Immigration and Customs Enforcement, "Operation in
              Our Sites", 2011, <http://www.ice.gov/doclib/news/library/
              factsheets/pdf/operation-in-our-sites.pdf>.

   [asymmetry]
              John, W., Dusi, M., and K. Claffy, "Estimating routing
              symmetry on single links by passive flow measurements",
              2010, <http://dl.acm.org/citation.cfm?id=1815506>.

   [click-trajectories]
              Levchenko, K., Pitsillidis, A., Chacra, N., Enright, B.,
              Felegyhazi, M., Grier, C., Halvorson, T., Kreibich, C.,
              Liu, H., McCoy, D., Weaver, N., Paxson, V., Voelker, G.,
              and S. Savage, "Click Trajectories: End-to-End Analysis of
              the Spam Value Chain", 2011,
              <http://cseweb.ucsd.edu/~savage/papers/Oakland11.pdf>.





Barnes, et al.          Expires January 16, 2014               [Page 25]


Internet-Draft          Filtering Considerations               July 2013


Authors' Addresses

   Richard Barnes
   BBN Technologies
   1300 N. 17th St
   Arlington, VA  22209
   USA

   Phone: +1 703 284 1340
   Email: rbarnes@bbn.com


   Alissa Cooper
   CDT
   1634 Eye St. NW, Suite 1100
   Washington, DC  20006
   USA

   Email: acooper@cdt.org


   Olaf Kolkman
   NLnet Labs
   Science Park 400
   Amsterdam  1422 JB
   Netherlands

   Email: olaf@nlnetlabs.nl























Barnes, et al.          Expires January 16, 2014               [Page 26]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/