[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: August 27, 2013                                             CDT
                                                              O. Kolkman
                                                              NLnet Labs
                                                       February 23, 2013

  Technical Considerations for Internet Service Blocking and Filtering


   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 allegedly illegal
   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 content blocking and filtering in terms of their
   alignment with the overall Internet architecture.  In general, the
   approach to content 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 illegal 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 August 27, 2013.

Copyright Notice

Barnes, et al.           Expires August 27, 2013                [Page 1]

Internet-Draft          Filtering Considerations           February 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.  Architectural Principles . . . . . . . . . . . . . . . . . . .  4
     2.1.  End-to-End Connectivity and "Transparency" . . . . . . . .  4
     2.2.  Layering . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.3.  Distribution and Mobility  . . . . . . . . . . . . . . . .  6
     2.4.  Locality and Autonomy  . . . . . . . . . . . . . . . . . .  6
   3.  Examples of Blocking . . . . . . . . . . . . . . . . . . . . .  7
   4.  Blocking Design Patterns . . . . . . . . . . . . . . . . . . .  9
     4.1.  Network-Based Blocking . . . . . . . . . . . . . . . . . . 10
       4.1.1.  Interaction with Architectural Principles  . . . . . . 11
       4.1.2.  Circumvention  . . . . . . . . . . . . . . . . . . . . 11
     4.2.  Infrastructure-Based Blocking  . . . . . . . . . . . . . . 14
     4.3.  Endpoint-Based Blocking  . . . . . . . . . . . . . . . . . 16
   5.  Summary of Trade-offs  . . . . . . . . . . . . . . . . . . . . 18
   6.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 19
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
   8.  Informative References . . . . . . . . . . . . . . . . . . . . 21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24

Barnes, et al.           Expires August 27, 2013                [Page 2]

Internet-Draft          Filtering Considerations           February 2013

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 arguably undesirable communications.  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 undesirable communications.

   Efforts to restrict or deny access to Internet resources 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 communications 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.

   Entities may seek to block or filter Internet content for a diversity
   of reasons, including defending against security threats, restricting
   access to content thought to be objectionable, and preventing
   nefarious or illegal activity.  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.

   This document aims to clarify the technical implications and trade-
   offs of various blocking strategies and to identify the potential for
   different strategies to come into conflict with the Internet's
   architecture, or potentially cause harmful side effects ("collateral
   damage").  Blocking is principally taken up (whether voluntarily or
   not) by three types of entities:

Barnes, et al.           Expires August 27, 2013                [Page 3]

Internet-Draft          Filtering Considerations           February 2013

   1.  Operators of networks (including enterprises)

   2.  Operators of infrastructure services (for naming, routing, and
       other core Internet functions)

   3.  Operators of endpoints (including end users and application

   Examples of blocking or attempted blocking using the DNS, HTTP
   proxies, spam filters, and RPKI manipulation are used to illustrate
   each category's properties.

   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 filtering
   or are considering 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.  Architectural Principles

   To understand the implications of different blocking strategies, it
   is important to understand the key principles that have informed the
   design of the Internet.  While much of this ground has been well trod
   before, this section highlights four architectural principles that
   have a direct impact on the viability of content blocking: end-to-end
   connectivity and "transparency," layering, distribution and mobility,
   and locality and autonomy.

2.1.  End-to-End Connectivity and "Transparency"

   The end-to-end principle is "the core architectural guideline of the
   Internet" [RFC3724].  Adherence to the principle of vesting endpoints
   with the functionality to accomplish end-to-end tasks results in a
   "transparent" network in which packets are not filtered or

Barnes, et al.           Expires August 27, 2013                [Page 4]

Internet-Draft          Filtering Considerations           February 2013

   transformed en route [RFC2775].  This transparency in turn is a key
   requirement for providing end-to-end security features on the
   network.  Modern security mechanisms that rely on trusted hosts
   communicating via a secure channel without intermediary interference
   enable the network to support e-commerce, confidential communication,
   and an array of other similar uses.

   The end-to-end principle is fundamental for Internet security, and
   the foundation on which Internet security protocols are built.
   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.

   Some blocking strategies require intermediaries to insert themselves
   within the end-to-end communications path (network-based web
   filtering systems, for example), 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.

2.2.  Layering

   "Different Players on Different Layers."

   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.  As a consequence of the end-to-end principle, 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

Barnes, et al.           Expires August 27, 2013                [Page 5]

Internet-Draft          Filtering Considerations           February 2013

   all applications that depend on those functions.

2.3.  Distribution and Mobility

   The Internet is designed as a distributed system both geographically
   and topologically.  Resources can be made globally accessible
   regardless of their physical location or connectivity providers used.
   Resources are also commonly highly mobile -- moving content from one
   physical or logical address to another can often be easily

   This distribution and mobility underlies a large part of the
   resiliency of the Internet.  Internet routing can survive major
   outages such as cuts in undersea fibers because the distributed
   routing system of the Internet allows individual networks to
   collaborate to route traffic and for alternative paths to reach a
   given destination to be rapidly computed.  Application services are
   commonly protected using distributed servers.

   Undesirable communications also benefit from this resiliency --
   resources that are blocked or restricted in one part of the Internet
   can be reconstituted in another part of the Internet (see, for
   example, [Malicious-Resolution]).  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.

   The distributed and mobile nature of Internet resources limits the
   effectiveness of blocking actions.  Because an Internet service can
   be reached from anywhere on the Internet, a service that is blocked
   in one jurisdiction can often be moved or re-instantiated in another
   jurisdiction.  Likewise, services that rely on blocked resources can
   often be rapidly re-configured to use non-blocked resources.  For
   example, 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.  Alternatively, users may choose to use different
   sets of protocols to establish desired service.  If voice
   communication based on SIP [RFC3261] is blocked, users are likely to
   use propriety protocols that allow them to talk to each other.  Thus
   distribution and mobility can hamper efforts to block communications
   in a number of ways.

2.4.  Locality and Autonomy

   The basic unit of Internet routing is an "Autonomous System" -- a
   network that manages its own routing internally.  The concept of
   autonomy is present in many aspects of the Internet, as is the

Barnes, et al.           Expires August 27, 2013                [Page 6]

Internet-Draft          Filtering Considerations           February 2013

   related concept of locality, the idea that local changes should not
   have a broader impact on the network (where "local" may be denote a
   particular service provider or a particular geography).

   These concepts are critical to the stability, scalability, and
   ability to innovate of the Internet.  With millions of individual
   actors engineering different parts of the network, there would be
   chaos if every change had impact across the entire Internet.

   Locality implies that the impact of technical changes made to realize
   blocking will only be within a defined scope.  For example, changes
   to 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.  Changes to a
   particular application service 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/or infrastructure services are so intertwined with
   each other that filtering a single service or in a single location
   can have broad effects in multiple directions.

   Changes made to effectuate blocking are often targeted at a
   particular locality, but result in blocking outside of the intended
   scope.  For example, web filtering systems in India and China have
   been shown to cause "collateral damage" by blocking users in Oman and
   the US from accessing web sites in Germany and Korea

3.  Examples of Blocking

   As noted above, systems to restrict or block Internet communications
   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, with varying degrees of

   o  Firewalls: Firewalls are a very common form of 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 control), or at network boundaries.

Barnes, et al.           Expires August 27, 2013                [Page 7]

Internet-Draft          Filtering Considerations           February 2013

   o  Web Filtering: HTTP and HTTPS are common targets for blocking and
      filtering, typically targeted at specific URLs.  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 URL in an HTTPS request is carried
      inside the secure (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 7.)

   o  Spam Filtering: Spam filtering is one of the oldest forms of
      service blocking, in the sense that it denies spammers access to
      recipients' mailboxes.  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.

   o  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 allegedly 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 the mobility
      principle, since the application using the seized name can simply
      use another name.  Seizures can come into conflict with the
      locality principle, since 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.

   o  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

Barnes, et al.           Expires August 27, 2013                [Page 8]

Internet-Draft          Filtering Considerations           February 2013

      Firefox web browsers 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].

   o  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.2).  These actions have led to
      concerns that the number resource certification system and related
      secure routing technologies developed by the IETF SIDR working
      group might be subject to government manipulation as well
      [RFC6480], potentially for the purpose of denying targeted
      networks access to the Internet.

4.  Blocking Design Patterns

   Broadly speaking, completing a typical end-to-end Internet
   communication requires the involvement of three classes of entities,
   each of which has different means available to it for blocking
   communications.  An end user originates the communication, which may
   be destined for another end user or application provider on the other
   end.  At these endpoints, authentication and reputation systems
   enable devices and their users to make decisions about which
   communications should be blocked.

   The endpoints are each connected to a series of networks, the
   operators of which may also be capable of blocking.  Network-based
   mechanisms usually involve an intermediary device in the network that
   observes Internet traffic and decides which communications to block.

   Finally, most communications depend on common "infrastructure"
   services (for lack of a better term) that globally support many
   different kinds of applications.  These include the Domain Name
   System, the routing infrastructure, and their supporting information
   services such as the WHOIS databases.  The operators of these
   services can alter the information they store in their associated
   databases or provide to endpoints in order to block communications
   from occuring.

   In this section, we discuss these three "blocking design patterns"
   and how they align with the Internet architectural principles
   outlined above.  In general, endpoint-based blocking is the most

Barnes, et al.           Expires August 27, 2013                [Page 9]

Internet-Draft          Filtering Considerations           February 2013

   consistent with the Internet architecture.

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

   Common examples of network-based blocking are firewalls and network-
   based web-filtering systems.  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 filter traffic
   based on lower layer criteria (transport protocol and source or
   destination addresses or ports).

   In addition to blocking communications based on their ultimate
   destination or source, network-based blocking may target discovery,
   rendezvous or store-and-forward components that are critical to the
   establishment of an application service but are not operated at
   either end-point of the communications.  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.  Network operators
   can block the use of SIP-based services by blocking access to SIP
   servers.  [Q: Does this actually happen?]

   It should be noted that "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 users.  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.3 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

Barnes, et al.           Expires August 27, 2013               [Page 10]

Internet-Draft          Filtering Considerations           February 2013

   architectural perspective, however, they may create many of the same
   problems as network-based filtering conducted without consent.

4.1.1.  Interaction with Architectural Principles

   Blocking that uses intermediaries in the network conflicts with the
   end-to-end and transparency principles noted above.  The very goal of
   blocking in this way is to impede transparency for particular content
   or communications.  For this reason, intermediary-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.

   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.

   This asymmetry means that an intermediary will often see only one
   half of a given communication (if it sees any of it at all), which
   may limit its ability to effectively 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 often reduce network performance relative
   to asymmetric routing.

   Once an intermediary 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 (in violation of
   the locality principle.)

4.1.2.  Circumvention

   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

Barnes, et al.           Expires August 27, 2013               [Page 11]

Internet-Draft          Filtering Considerations           February 2013

   (see below).  IP addresses must be visible, even if packets are
   protected with IPsec, but blocking based on IP addresses is the
   simplest form of filtering 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

   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 it is impossible to block tunneled traffic through
   an intermediary device without blocking all secure traffic.  (The
   only limitation in practice is the requirement 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

Barnes, et al.           Expires August 27, 2013               [Page 12]

Internet-Draft          Filtering Considerations           February 2013

   as to effectuate blocking, they would expose their users to the
   various attacks that the security protocols were put in place to

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

   In sum, blocking via intermediaries within networks 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), which may be
   resource-prohibitive, especially if tunnel endpoints begin to change
   frequently.  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.

Barnes, et al.           Expires August 27, 2013               [Page 13]

Internet-Draft          Filtering Considerations           February 2013

4.2.  Infrastructure-Based Blocking

   Internet applications often require or rely on support from common,
   global infrastructure 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.

   These infrastructure 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).

   As physical objects, the servers that are used to provide
   infrastructure services exist within the jurisdiction of governments,
   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 infrastructure services
   within a jurisdiction, either via direct government action or by
   allowing private actors to demand blocking (e.g., through lawsuits).

   Blocking by infrastructure operators is at odds with the locality
   principle.  On the one hand, the global nature of Internet services
   and resources amplifies blocking actions, in the sense that it
   increases the risk of overblocking -- collateral damage to legitimate
   use of a resource.  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.

   The efficacy of infrastructure-based blocking is further limited by
   the autonomy principle.  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 infrastructure
   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.

Barnes, et al.           Expires August 27, 2013               [Page 14]

Internet-Draft          Filtering Considerations           February 2013

   Below we provide a few specific examples for routing, DNS, and WHOIS
   services.  These examples demonstrate that for these types of
   infrastructure services (services that are often considered a global
   commons), jusrisdiction-specific legal and ethical motivations
   impinge on and are constrained by the principles of locality and

   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 route leak beyond the Pakistan
   ISP's scope (violation of locality), but service was restored in
   approximately two hours because network operators around the world
   re-configured their routers to ignore the bogus routes [RenesysPK]
   (which demonstrates autonomy).  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 (violation of locality).

   Similar work-arounds 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

Barnes, et al.           Expires August 27, 2013               [Page 15]

Internet-Draft          Filtering Considerations           February 2013

   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, violating locality, and in that reduced trust
   in the global system may encourage networks to develop their own
   autonomous solutions.

   Blocking of infrastructure 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.

   In summary, infrastructure-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 often have harmful
   side effects due to the global nature of Internet resources.  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
   infrastructure-based blocking can be negated on short order in some
   cases.  To adapt a quote by John Gilmore, "The Internet treats
   blocking as damage and routes around it".

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

Barnes, et al.           Expires August 27, 2013               [Page 16]

Internet-Draft          Filtering Considerations           February 2013

   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
   blocking systems in the Internet; modern blocking 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 blocking systems (browsers, MTAs) share a single reputation

   This approach to blocking is consistent with the Internet
   architectural principles discussed above, dealing well with the end-
   to-end principle, layering, mobility, and locality/autonomy.

   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 intermediary-based blocking runs into.
   Endpoint-based blocking also lacks some of the limitations of
   infrastructure-based blocking: while infrastructure-based blocking
   can only see and affect the infrastructure 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 on which to
   make blocking decisions.

   In particular, endpoint-based blocking deals well with adversary
   mobility.  If a blocked service relocates resources or uses different
   resources, an infrastructure- 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

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

   The primary challenge to endpoint-based blocking is that it requires

Barnes, et al.           Expires August 27, 2013               [Page 17]

Internet-Draft          Filtering Considerations           February 2013

   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.

5.  Summary of Trade-offs

   Network-based blocking is a relatively low-cost blocking solution in
   some cases, but a poor fit with the Internet architecture, especially
   the end-to-end principle.  It thus suffers from several limitations.

   o  Examples: Firewalls, web filtering systems.

   o  A single intermediary device can be used to block the access of
      many users to many services.

   o  Network-based blocking can be done without the cooperation of
      either endpoint to a communication (although having that
      cooperation makes it more likely to be effective).

   o  Network intermediaries often lack sufficient information to make
      blocking decisions, due to routing asymmetry or encryption.

   o  Network-based blocking sometimes involves breaking end-to-end
      security assurances.

   o  Tunneling through blocking is difficult to prevent without
      preventing legitimate secure services.

   Infrastructure-based blocking can provide rapid effects for resources
   under the control of the blocking entity, but its ultimate
   effectiveness is limited by the global, autonomous nature of Internet
   resources and networks, and it may create undesirable collateral
   damage to Internet services.

   o  Examples: Domain name seizures, WHOIS account freezing, RPKI
      certificate revocation.

   o  Internet services that depend on specific resources can be blocked
      by disabling those resources.

Barnes, et al.           Expires August 27, 2013               [Page 18]

Internet-Draft          Filtering Considerations           February 2013

   o  Blocked resources can often be easily relocated or reinstantiated
      in a location where they will not be blocked.

   o  Resources used by undesirable services are often also used by
      legitimate services, resulting in collateral damage.

   o  Autonomy of Internet networks and users allows them to "route
      around" blocking.  [OK Perhaps: Autonomy principle allows users to
      innovatively find methods to route around the blocking.]

   Endpoint-based blocking matches well with the overall design of the

   o  Examples: Safe browsing, spam filtering

   o  Endpoints block services by deciding whether or not to engage in a
      given communication.

   o  Blocking system has full visibility into all layers involved in a

   o  Adversary mobility can be quickly observed so that blocking
      systems can be updated to account for it.

   o  Requires cooperation of endpoints.

6.  Conclusion

   Because it agrees so well with Internet architectural principles,
   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 in accordance with the
   end-to-end principle, 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 advtanges
   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 an intermediary-based filtering approach because it cannot

Barnes, et al.           Expires August 27, 2013               [Page 19]

Internet-Draft          Filtering Considerations           February 2013

   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 infrastructure-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 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 interfering with the
   architecture or 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.  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
   typically require the blocking system to defeat the authentication
   mechanisms built into security protocols.

Barnes, et al.           Expires August 27, 2013               [Page 20]

Internet-Draft          Filtering Considerations           February 2013

   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

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

   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 a mechanism 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.

8.  Informative References

   [BT-TPB]   Meyer, D., "BT blocks The Pirate Bay", June 2012, <http://

              "The Collateral Damage of Internet Censorship by DNS
              Injection", July 2012, <http://conferences.sigcomm.org/

              Raj Upadhaya, G., ".ht: Recovering DNS from the Quake",
              March 2010, <http://www.apricot.net/apricot2010/__data/

Barnes, et al.           Expires August 27, 2013               [Page 21]

Internet-Draft          Filtering Considerations           February 2013


              RIPE NCC, "RIPE NCC Blocks Registration in RIPE Registry
              Following Order from Dutch Police", 2012, <http://

              Citizen Lab, "Routing Gone Wild", July 2012,

              Internet Society, "DNS: Finding Solutions to Illegal On-
              line Activities", 2012, <http://www.internetsociety.org/

              Dagon, D., Provos, N., Lee, C., and W. Lee, "Corrupted DNS
              Resolution Paths: The Rise of a Malicious Resolution
              Authority", 2008,

   [Morris]   Kehoe, B., "The Robert Morris Internet Worm", 1992, <http:

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

   [RFC2775]  Carpenter, B., "Internet Transparency", RFC 2775,
              February 2000.

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

   [RFC3724]  Kempf, J., Austein, R., and IAB, "The Rise of the Middle
              and the Future of End-to-End: Reflections on the Evolution
              of the Internet Architecture", RFC 3724, March 2004.

Barnes, et al.           Expires August 27, 2013               [Page 22]

Internet-Draft          Filtering Considerations           February 2013

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

   [RFC4924]  Aboba, B. and E. Davies, "Reflections on Internet
              Transparency", RFC 4924, July 2007.

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

              Brown, M., "Pakistan hijacks YouTube", February 2008, <htt

              Masnick, M., "Homeland Security Seizes Spanish Domain Name
              That Had Already Been Declared Legal", 2011, <http://

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

              Google, "Safe Browsing API", 2012,

              "The Pirate Cloud", October 2012,

   [Telex]    Wustrow, E., Wolchok, S., Goldberg, I., and J. Halderman,
              "Telex: Anticensorship in the Network Infrastructure",

Barnes, et al.           Expires August 27, 2013               [Page 23]

Internet-Draft          Filtering Considerations           February 2013

              August 2011, <https://telex.cc/>.

   [Tor]      "Tor Project: Anonymity Online", 2012,

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

              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,

Authors' Addresses

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

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

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

   Email: acooper@cdt.org

   Olaf Kolkman
   NLnet Labs
   Science Park 400
   Amsterdam  1422 JB

   Email: olaf@nlnetlabs.nl

Barnes, et al.           Expires August 27, 2013               [Page 24]

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