IN-OM-filtering]. Other service providers have accidentally leaked such black hole routes beyond the jurisdiction [NW08]. A substantial amount of work has gone into BGP security to avoid such attacks, but deployment of such systems lags. RFC1122], especially Section 1.1.3). The functions at these layers are developed autonomously and almost always operated by different parties. For example, in many networks, physical and link-layer connectivity is provided by an "access provider", IP routing is performed by an "Internet service provider," and application-layer services are provided by completely separate entities (e.g., web servers). Upper-layer protocols and applications rely on combinations of lower-layer functions in order to work. Functionality at higher layers tends to be more specialized, so that many different specialized applications can make use of the same generic underlying network functions. As a result of this structure, actions taken at one layer can affect functionality or applications at other layers. For example, manipulating routing or naming functions to restrict access to a
narrow set of resources via specific applications will likely affect all applications that depend on those functions. As with the scope criteria, blocking systems are generally viewed as less objectionable when they are highly granular and do not cause collateral damage to content or services unrelated to the target of the blocking [RFC4924]. 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. CleanFeed] and [BlackLists14]). Experience has shown that, in general, blacklisting requires continual maintenance of the blacklist itself, both to add new entries for unwanted traffic and deleting entries when offending content is removed. Experience also shows that, depending on the nature of the block, it may be difficult to determine when to unblock. For instance, if a host is blocked because it has been compromised and used as a source of attack, it may not be plainly evident when that site has been fixed. 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 reconfigured to use non-blocked resources. If a web site is prevented from using a domain name or set of IP addresses, the content can simply be moved to another domain name or network, or use alternate syntaxes to express the same resource name (see the discussion of false negatives in [RFC6943]).
In a process known as "snowshoe spamming," a spam originator uses addresses in many different networks as sources for spam. This technique is already widely used to spread spam generation across a variety of resources and jurisdictions to prevent spam blocking from being effective. In the presence of either blacklist or whitelist systems, there are several ways in which a user or application can try to circumvent the filters. The users may choose to use different sets of protocols or otherwise alter their traffic characteristics to circumvent the filters. In some cases, applications may shift their traffic to port 80 or 443 when other ports are blocked. Or, services may be tunneled within other services, proxied by a collaborating external host (e.g., an anonymous redirector), or simply run over an alternate port (e.g., port 8080 vs port 80 for HTTP). Another means of circumvention is alteration of the service behavior to use a dynamic port negotiation phase, in order to avoid use of a constant port address. One of the primary motivations for arguing that HTTP/2 should be encrypted by default was that unencrypted HTTP 1.1 traffic was sometimes blocked or improperly processed. Users or applications shifting their traffic to encrypted HTTP has the effect of circumventing filters that depend on the HTTP plaintext payload. If voice communication based on SIP [RFC3261] is blocked, users are likely to use applications which use proprietary protocols that allow them to talk to each other. Some filtering systems are only capable of identifying IPv4 traffic and therefore, by shifting to IPv6, users may be able to evade filtering. Using IPv6 with header options, using multiple layers of tunnels, or using encrypted tunnels can also make it more challenging for blocking systems to find transport ports within packets, making port-based blocking more difficult. Thus, distribution and mobility can hamper efforts to block communications in a number of ways. RFC5246] and IPsec [RFC4301] are designed to ensure that each endpoint of the communication knows the identity of the other endpoint(s) and that only the endpoints of the communication can access the secured contents of the communication. For example, when a user connects to a bank's web site, TLS ensures
that the user's banking information is securely communicated to the bank and nobody else, ensuring the data remains confidential while in transit. Some blocking strategies require intermediaries to insert themselves within the end-to-end communications path, potentially breaking security properties of Internet protocols [RFC4924]. In these cases, it can be difficult or impossible for endpoints to distinguish between attackers and "authorized" parties conducting blocking. For example, an enterprise firewall administrator could gain access to users' personal bank accounts when users on the enterprise network connect to bank web sites. Finally, one needs to evaluate whether a blocking mechanism can be used by an end user to efficiently locate blocked resources that can then be accessed via other mechanisms that circumvent the blocking mechanism. For example, Clayton [CleanFeed] showed how special treatment in one blocking system could be detected by end users in order to efficiently locate illegal web sites, which was thus counterproductive to the policy objective of the blocking mechanism.
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. Section 2. While network-based Stateless Packet Filtering has granularity issues discussed in Section 4.2.2, network-based Stateful Packet Filtering and Deep Packet Inspection approaches often run into several technical issues that limit their viability in practice. For example, many issues arise from the fact that an intermediary needs to have access to a sufficient amount of traffic to make its blocking determinations. For residential or consumer networks with many egress points, the first step to obtaining this traffic is simply gaining access to the constituent packets. The Internet is designed to deliver packets independently from source to destination -- not to any particular point along the way. Thus, the sequence of packets from the sender can only be reliably reconstructed at the intended receiver. In addition, inter-network routing is often asymmetric, and for sufficiently complex local networks, intra-network traffic flows can be asymmetric as well [asymmetry]. Thus, packets in the reverse direction use a different sent of paths than the forward direction. This asymmetry means that an intermediary in a network with many egress points may, depending on topology and configuration, see only one half of a given communication, which may limit the scope of the communications that it can filter. For example, a filter aimed at requests destined for particular URIs cannot make accurate blocking decisions based on the URI if it is only in the data path for HTTP responses and not requests, since the URI is not included in the responses. Asymmetry may be surmountable given a filtering system
with enough distributed, interconnected filtering nodes that can coordinate information about flows belonging to the same communication or transaction, but depending on the size of the network this may imply significant complexity in the filtering system. Routing can sometimes be forced to be symmetric within a given network using routing configuration, NAT, or Layer 2 mechanisms (e.g., MPLS), but these mechanisms are frequently brittle, complex, and costly -- and can sometimes result in reduced network performance relative to asymmetric routing. Enterprise networks may also be less susceptible to these problems if they route all traffic through a small number of egress points. BT-TPB]. Indeed, Poort, et al. [Poort] found that "any behavioural change in response to blocking access to The Pirate Bay has had no lasting net impact on the overall number of downloaders from illegal sources, as new consumers have started downloading from illegal sources and people learn to circumvent the blocking while new illegal sources may be launched, causing file sharing to increase again", and that these
results "are in line with a tendency found in the literature that any effects of legal action against file sharing often fade out after a period of typically six months." If application content is encrypted with a security protocol such as IPsec or TLS, then the intermediary will require the ability to decrypt the packets to examine application content, or resort to statistical methods to guess what the content is. Since security protocols are generally designed to provide end-to-end security (i.e., to prevent intermediaries from examining content), the intermediary would need to masquerade as one of the endpoints, breaking the authentication in the security protocol, reducing the security of the users and services affected, and interfering with legitimate private communication. Besides, various techniques that use public databases with whitelisted keys (e.g., DANE [RFC6698]) 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, port numbers, packet sizes, and packet timing. Some blocking systems today still attempt to block based on these attributes, for example by blocking TLS traffic to known proxies that could be used to tunnel through the blocking system. However, as the Telex project [Telex] recently demonstrated, if an endpoint cooperates with a relay in the network (e.g., a Telex station), it can create a TLS tunnel that is indistinguishable from legitimate traffic. For example, if an ISP used by a banking web site were to operate a Telex station at one of its routers, then a blocking system would be unable to distinguish legitimate encrypted banking traffic from Telex-tunneled traffic (potentially carrying content that would have been filtered). Thus, in principle in a blacklist system it is impossible to block tunneled traffic through an intermediary device without blocking all secure traffic from that system. (The only limitation in practice is the requirement for special software on the client.) Those who require that secure traffic be blocked from such sites risk blocking content that would be valuable to their users, perhaps impeding substantial economic activity. Conversely, those who are hosting a myriad of content have an incentive to see that law abiding content does not end up being blocked.
Governments and network operators should, however, take care not to encourage the use of insecure communications in the naming of security, as doing so will invariably expose their users to the various attacks that the security protocols were put in place to prevent. 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 such tools, the result of which is to create unnecessary layers of complexity in the Internet. Before content-based blocking became common, the next best option for network operators was port blocking, the widespread use of which has driven more applications and services to use ports (80 and 443 most commonly) that are unlikely to be blocked. In turn, network operators shifted to finer-grained content blocking over port 80, content providers shifted to encrypted channels, and operators began seeking to identify those channels (although doing so can be resource-prohibitive, especially if tunnel endpoints begin to change frequently). Because the premise of network-based blocking is that endpoints have incentives to circumvent it, this cat-and-mouse game is an inevitable by-product of this form of blocking. One reason above all stands as an enormous challenge to network-based blocking: the Internet was designed with the premise that people will want to connect and communicate. IP will run on anything up to and including carrier pigeons [RFC1149]. It often runs atop TLS and has been made to run on other protocols that themselves run atop IP. Because of this fundamental layering approach, nearly any authorized avenue of communication can be used as a transport. This same "problem" permits communications to succeed in the most challenging of environments.
Endpoints can also choose not to use a particular rendezvous service. They might switch to a competitor or use an alternate mechanism (for example, IP literals in URIs to circumvent DNS filtering). RFC2826], in the advisory [SAC-056] from ICANN's Security and Stability Advisory Committee (SSAC), and in the Internet Society's whitepaper on DNS filtering [ISOCFiltering], but they also apply to other global Internet resources. RenesysPK]. In the context of SIDR and secure routing, a similar reconfiguration could theoretically be done if a resource certificate were to be revoked in order to block routing to a given network. In the DNS realm, one of the recent cases of U.S. law enforcement seizing domain names involved RojaDirecta, a Spanish web site. Even though several of the affected domain names belonged to Spanish organizations, they were subject to blocking by the U.S. government because certain servers were operated in the United States.
Government officials required the operators of the parent zones of a target name (e.g., "com" for "example.com") to direct queries for that name to a set of U.S.-government-operated name servers. Users of other services (e.g., email) under a target name would thus be unable to locate the servers providing services for that name, denying them the ability to access these services. Similar workarounds as those that were used in the Pakistan Telecom case are also available in the DNS case. If a domain name is blocked by changing authoritative records, network operators can restore service simply by extending TTLs on cached pre-blocking records in recursive resolvers, or by statically configuring resolvers to return unblocked results for the affected name. However, depending on the availability of valid signature data, these types of workarounds will not work with DNSSEC-signed data. The action of the Dutch authorities against the RIPE NCC, where RIPE was ordered to freeze the accounts of Internet resource holders, is of a similar character. By controlling the account holders' WHOIS information, this type of action limited the ability of the ISPs in question to manage their Internet resources. This example is slightly different from the others because it does not immediately impact the ability of ISPs to provide connectivity. While ISPs use (and trust) the WHOIS databases to build route filters or use the databases for trouble-shooting information, the use of the WHOIS databases for those purposes is voluntary. Thus, seizure of this sort may not have any immediate effect on network connectivity, but it may impact overall trust in the common infrastructure. It is similar to the other examples in that action in one jurisdiction can have broader effects, and in that the global system may encourage networks to develop their own autonomous solutions.
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".
may have less ability to make fine-grained decisions than an application that does its own blocking (see [RFC7288] for further discussion).
For instance, for blocking of web content, narrow targeting can be achieved through whitelisting methods like password authentication, whereby passwords are available only to authorized clients. For example, a web site might only make adult content available to users who provide credit card information, which is assumed to be a proxy for age. The fact that content-producing endpoints often do not take it upon themselves to block particular forms of content in response to requests from governments or other parties can sometimes motivate those latter parties to engage in blocking elsewhere within the Internet. If a service is to be blocked, the best way of doing that is to disable the service at the server endpoint.
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, the attacker will have access to the unencrypted data of all current and recorded TLS sessions for all users behind that firewall, in a way that is undetectable to users. Besides, if the compromised key- pairs can be extracted from the firewall, all users, not only those behind the firewall, that rely on that public key are vulnerable. We must also consider the possibility that a legitimate administrator of such a firewall could gain access to privacy-sensitive information, such as the bank accounts or health records of users who access such secure sites through the firewall. These privacy considerations motivate legitimate use of secure end-to-end protocols that often make it difficult to enforce granular blocking policies. 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.
Blacklist approaches are often a game of "cat and mouse", where those with the content move it around to avoid blocking. Or, the content may even be naturally mirrored or cached at other legitimate sites such as the Internet Archive Wayback Machine [Wayback]. At the same time, whitelists provide similar risks because sites that had "acceptable" content may become targets for "unacceptable content", and similarly, access to perfectly inoffensive and perhaps useful or productive content is unnecessarily blocked. From a technical perspective, there are no perfect or even good solutions -- there is only least bad. On that front, we posit that a hybrid approach that combines endpoint-based filtering with network filtering may prove least damaging. An endpoint may choose to participate in a filtering regime in exchange for the network providing broader unfiltered access. Finally, we note that where filtering is occurring to address content that is generally agreed to be inappropriate or illegal, strong cooperation among service providers and governments may provide additional means to identify both the victims and the perpetrators through non-filtering mechanisms, such as partnerships with the finance industry to identify and limit illegal transactions. [asymmetry] John, W., Dusi, M., and K. Claffy, "Estimating routing symmetry on single links by passive flow measurements", Proceedings of the 6th International Wireless Communications and Mobile Computing Conference, IWCMC '10, DOI 10.1145/1815396.1815506, 2010, <http://www.caida.org/publications/papers/2010/ estimating_routing_symmetry/ estimating_routing_symmetry.pdf>. [BlackLists14] Chachra, N., McCoy, D., Savage, S., and G. Voelker, "Empirically Characterizing Domain Abuse and the Revenue Impact of Blacklisting", Workshop on the Economics of Information Security 2014, <http://www.econinfosec.org/archive/weis2014/papers/ Chachra-WEIS2014.pdf>. [BT-TPB] Meyer, D., "BT blocks The Pirate Bay", June 2012, <http://www.zdnet.com/ bt-blocks-the-pirate-bay-4010026434/>.
[CleanFeed] Clayton, R., "Failures in a Hybrid Content Blocking System", Fifth Privacy Enhancing Technologies Workshop, PET 2005, DOI 10.1007/11767831_6, 2005, <http://www.cl.cam.ac.uk/~rnc1/cleanfeed.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>. [IN-OM-filtering] Citizen Lab, "Routing Gone Wild: Documenting upstream filtering in Oman via India", 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>. [NW08] Marsan, C., "YouTube/Pakistan incident: Could something similar whack your site?", Network World, March 2008, <http://www.networkworld.com/article/2284273/software/ youtube-pakistan-incident--could-something-similar-whack- your-site-.html>. [Poort] Poort, J., Leenheer, J., van der Ham, J., and C. Dumitru, "Baywatch: Two approaches to measure the effects of blocking access to The Pirate Bay", Telecommunications Policy 38:383-392, DOI 10.1016/j.telpol.2013.12.008, 2014, <http://staff.science.uva.nl/~vdham/research/ publications/1401-Baywatch.pdf>.
[RenesysPK] Brown, M., "Pakistan hijacks YouTube", February 2008, <http://research.dyn.com/2008/02/ pakistan-hijacks-youtube-1/>. [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <http://www.rfc-editor.org/info/rfc1122>. [RFC1149] Waitzman, D., "Standard for the transmission of IP datagrams on avian carriers", RFC 1149, DOI 10.17487/RFC1149, April 1990, <http://www.rfc-editor.org/info/rfc1149>. [RFC2826] Internet Architecture Board, "IAB Technical Comment on the Unique DNS Root", RFC 2826, DOI 10.17487/RFC2826, May 2000, <http://www.rfc-editor.org/info/rfc2826>. [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, <http://www.rfc-editor.org/info/rfc2827>. [RFC2979] Freed, N., "Behavior of and Requirements for Internet Firewalls", RFC 2979, DOI 10.17487/RFC2979, October 2000, <http://www.rfc-editor.org/info/rfc2979>. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>. [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, <http://www.rfc-editor.org/info/rfc3704>. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <http://www.rfc-editor.org/info/rfc4033>. [RFC4084] Klensin, J., "Terminology for Describing Internet Connectivity", BCP 104, RFC 4084, DOI 10.17487/RFC4084, May 2005, <http://www.rfc-editor.org/info/rfc4084>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <http://www.rfc-editor.org/info/rfc4301>. [RFC4924] Aboba, B., Ed. and E. Davies, "Reflections on Internet Transparency", RFC 4924, DOI 10.17487/RFC4924, July 2007, <http://www.rfc-editor.org/info/rfc4924>. [RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the IAB workshop on Unwanted Traffic March 9-10, 2006", RFC 4948, DOI 10.17487/RFC4948, August 2007, <http://www.rfc-editor.org/info/rfc4948>. [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, <http://www.rfc-editor.org/info/rfc4949>. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>. [RFC5782] Levine, J., "DNS Blacklists and Whitelists", RFC 5782, DOI 10.17487/RFC5782, February 2010, <http://www.rfc-editor.org/info/rfc5782>. [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, <http://www.rfc-editor.org/info/rfc6480>. [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, <http://www.rfc-editor.org/info/rfc6698>. [RFC6943] Thaler, D., Ed., "Issues in Identifier Comparison for Security Purposes", RFC 6943, DOI 10.17487/RFC6943, May 2013, <http://www.rfc-editor.org/info/rfc6943>. [RFC7288] Thaler, D., "Reflections on Host Firewalls", RFC 7288, DOI 10.17487/RFC7288, June 2014, <http://www.rfc-editor.org/info/rfc7288>.
[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] ICANN SSAC, "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/>. [Takedown08] Moore, T. and R. Clayton, "The Impact of Incentives on Notice and Take-down", Workshop on the Economics of Information Security 2008, <http://www.econinfosec.org/archive/weis2008/papers/ MooreImpact.pdf>. [Telex] Wustrow, E., Wolchok, S., Goldberg, I., and J. Halderman, "Telex: Anticensorship in the Network Infrastructure", <https://telex.cc/>. [Tor] "Tor Project: Anonymity Online", <https://www.torproject.org/>. [Wayback] "Internet Archive: Wayback Machine", <http://archive.org/web/>.