idnits 2.17.1 draft-iab-filtering-considerations-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 28, 2014) is 3739 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Endpoint' is mentioned on line 372, but not defined == Missing Reference: 'Network' is mentioned on line 380, but not defined == Missing Reference: 'Rendezvous' is mentioned on line 382, but not defined == Unused Reference: 'EarthquakeHT' is defined on line 1129, but no explicit reference was found in the text == Unused Reference: 'GhostClickRIPE' is defined on line 1135, but no explicit reference was found in the text == Unused Reference: 'RFC2775' is defined on line 1174, but no explicit reference was found in the text == Unused Reference: 'RFC3724' is defined on line 1185, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-iab-host-firewalls-00 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Architecture Board R. Barnes 3 Internet-Draft Mozilla 4 Intended status: Informational A. Cooper 5 Expires: August 1, 2014 Cisco 6 O. Kolkman 7 NLnet Labs 8 January 28, 2014 10 Technical Considerations for Internet Service Blocking and Filtering 11 draft-iab-filtering-considerations-06.txt 13 Abstract 15 The Internet is structured to be an open communications medium. This 16 openness is one of the key underpinnings of Internet innovation, but 17 it can also allow communications that may be viewed as undesirable by 18 certain parties. Thus, as the Internet has grown, so have mechanisms 19 to limit the extent and impact of abusive or objectionable 20 communications. Recently, there has been an increasing emphasis on 21 "blocking" and "filtering," the active prevention of such 22 communications. This document examines several technical approaches 23 to Internet blocking and filtering in terms of their alignment with 24 the overall Internet architecture. In general, the approach to 25 blocking and filtering that is most coherent with the Internet 26 architecture is to inform endpoints about potentially undesirable 27 services, so that the communicants can avoid engaging in abusive or 28 objectionable communications. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on August 1, 2014. 47 Copyright Notice 49 Copyright (c) 2014 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Filtering Examples . . . . . . . . . . . . . . . . . . . . . 4 66 3. Characteristics of Blocking Systems . . . . . . . . . . . . . 6 67 3.1. Entities that set blocking policies . . . . . . . . . . . 6 68 3.2. Purposes of blocking . . . . . . . . . . . . . . . . . . 6 69 3.3. Intended targets of blocking . . . . . . . . . . . . . . 7 70 3.4. Components used for blocking . . . . . . . . . . . . . . 8 71 4. Evaluation of Blocking Design Patterns . . . . . . . . . . . 9 72 4.1. Criteria for evaluation . . . . . . . . . . . . . . . . . 9 73 4.1.1. Scope: What content or services can be blocked? . . . 10 74 4.1.2. Granularity: How specific is the blocking? Will 75 blocking one service also block others? . . . . . . . 10 76 4.1.3. Efficacy: How easy is it for a resource or service to 77 avoid being blocked? . . . . . . . . . . . . . . . . 11 78 4.1.4. Security: How does the blocking impact existing trust 79 infrastructures? . . . . . . . . . . . . . . . . . . 12 80 4.2. Network-Based Blocking . . . . . . . . . . . . . . . . . 12 81 4.2.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . 13 82 4.2.2. Granularity . . . . . . . . . . . . . . . . . . . . . 14 83 4.2.3. Efficacy and security . . . . . . . . . . . . . . . . 14 84 4.2.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 16 85 4.3. Rendezvous-Based Blocking . . . . . . . . . . . . . . . . 16 86 4.3.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . 17 87 4.3.2. Granularity . . . . . . . . . . . . . . . . . . . . . 17 88 4.3.3. Efficacy . . . . . . . . . . . . . . . . . . . . . . 17 89 4.3.4. Security and other implications . . . . . . . . . . . 18 90 4.3.5. Examples . . . . . . . . . . . . . . . . . . . . . . 18 91 4.3.6. Summary . . . . . . . . . . . . . . . . . . . . . . . 19 92 4.4. Endpoint-Based Blocking . . . . . . . . . . . . . . . . . 20 93 4.4.1. Scope and granularity . . . . . . . . . . . . . . . . 20 94 4.4.2. Efficacy . . . . . . . . . . . . . . . . . . . . . . 21 95 4.4.3. Security . . . . . . . . . . . . . . . . . . . . . . 21 96 4.4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 21 97 4.4.5. Server Endpoints . . . . . . . . . . . . . . . . . . 22 98 5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 99 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 23 100 7. Informative References . . . . . . . . . . . . . . . . . . . 24 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 103 1. Introduction 105 The original design goal of the Internet was to enable communications 106 between hosts. As this goal was met and people started using the 107 Internet to communicate, however, it became apparent that some hosts 108 were engaging in communications that were viewed as undesirable by 109 certain parties. The most famous early example of undesirable 110 communications was the Morris worm [Morris], which used the Internet 111 to infect many hosts in 1988. As the Internet has evolved into a 112 rich communications medium, so too have mechanisms to restrict 113 communications viewed as undesirable, ranging from acceptable use 114 policies enforced through informal channels to technical blocking 115 mechanisms. 117 Efforts to restrict or deny access to Internet resources and services 118 have evolved over time. As noted in [RFC4084], some Internet service 119 providers impose restrictions on which applications their customers 120 may use and which traffic they allow on their networks. These 121 restrictions are often imposed with customer consent, where customers 122 may be enterprises or individuals. Increasingly, however, both 123 governmental and private sector entities are seeking to block or 124 filter access to certain content, traffic, or services without the 125 knowledge or agreement of affected users. Where these entities do 126 not directly control networks themselves, they commonly aim to make 127 use of intermediary systems to effectuate the blocking or filtering. 129 While blocking and filtering remain highly contentious in many cases, 130 the desire to restrict communications or access to content will 131 likely continue to exist. 133 The difference between "blocking" and "filtering" is a matter of 134 scale and perspective. "Blocking" often refers to preventing access 135 to resources in the aggregate, while "filtering" refers to preventing 136 access to specific resources within an aggregate. Both blocking and 137 filtering can be effectuated at the level of "services" (web hosting 138 or video streaming, for example) or at the level of particular 139 "content." For the analysis presented in this document, the 140 distinction between blocking and filtering does not create 141 meaningfully different conclusions. Hence, in the remainder of this 142 document, we will treat the terms as being generally equivalent and 143 applicable to restrictions on both content and services. 145 This document aims to clarify the technical implications and trade- 146 offs of various blocking strategies and to identify the potential for 147 different strategies to potentially cause harmful side effects 148 ("collateral damage") for Internet users and the overall Internet 149 architecture. This analysis is limited to technical blocking 150 mechanisms. Enforcement of blocking via contractual terms or legal 151 action is out of scope, though usually these actions ultimately 152 result in the application of technical mechanisms. 154 Filtering may be considered legal, illegal, ethical, or unethical in 155 different places, at different times, and by different parties. This 156 document is intended for an audience of entities that are conducting 157 filtering or are considering conducting filtering and who want to 158 understand the implications of their decisions with respect to the 159 Internet architecture and the trade-offs that come with each type of 160 filtering strategy. This document does not present formulas on how 161 to make those trade-offs; it is likely that filtering decisions 162 require knowledge of context-specific details. Whether particular 163 forms of filtering are lawful in particular jurisdictions raises 164 complicated legal questions that are outside the scope of this 165 document. For similar reasons, questions about the ethics of 166 particular forms of filtering are also out of scope. 168 In [SAC-056], ICANN's Security and Stability Advisory Committee 169 (SSAC) assessed the aspects of blocking using the DNS. This document 170 attempts to take a broader perspective on blocking and filtering and 171 genaralizes from some of SSAC's findings. 173 2. Filtering Examples 175 Blocking systems have evolved alongside the Internet technologies 176 they seek to restrict. Looking back at the history of the Internet, 177 there have been several such systems deployed by different entities 178 and for different purposes. 180 Firewalls: Firewalls are a very common tool used for service 181 blocking, employed at many points in today's Internet [RFC2979]. 182 Typically, firewalls block according to content-neutral rules, e.g., 183 blocking all inbound connections or outbound connections on certain 184 ports, protocols and network layer addresses. More advanced 185 configurations perform deep packet inspection or traffic flow 186 analysis and filter or block based on rich (content-specific) rules 187 and policies. Many firewalls include web filtering capabilities (see 188 below). Firewalls can be deployed either on end hosts (under user or 189 administrator control), or at network boundaries. 191 Web Filtering: HTTP and HTTPS are common targets for blocking and 192 filtering, typically targeted at specific URIs. Some enterprises use 193 HTTP blocking to block non-work-appropriate web sites, and several 194 nations require HTTP and HTTPS filtering by their ISPs in order to 195 block content deemed illegal. HTTPS is a challenge for these 196 systems, because the URI in an HTTPS request is carried inside the 197 encrypted channel. To block access to content made accessible via 198 HTTPS, filtering systems thus must either block based on network- and 199 transport-layer headers (IP address and/or port), or else obtain a 200 trust anchor certificate that is trusted by endpoints (and thus act 201 as a man in the middle). These filtering systems often take the form 202 of "portals" or "enterprise proxies." These portals present their 203 own HTTPS certificates that are invalid for any given domain 204 according to normal validation rules, but may still be trusted if the 205 user installs a security exception. (See further discussion in 206 Section 5.) 208 Spam Filtering: Spam filtering is one of the oldest forms of content 209 filtering. Spam filters evaluate messages based on a variety of 210 criteria and information sources to decide whether a given message is 211 spam. For example, DNS Black Lists use the reverse DNS to flag 212 whether an IP address is a known spam source [RFC5782]. Spam filters 213 are typically either installed on user devices (e.g., in a mail 214 client) or operated by a mail domain on behalf of users. 216 Domain name seizure: In recent years, US law enforcement authorities 217 have been issuing legal orders to domain name registries to seize 218 domain names associated with the distribution of counterfeit goods 219 and other alleged illegal activity [US-ICE]. When domain names are 220 seized, DNS queries for the seized names are typically redirected to 221 resolve to U.S. government IP addresses that host information about 222 the seizure. The effectiveness of domain seizures is limited by 223 application mobility -- applications using the seized name can switch 224 to using another name. Seizures can also have overbroad effects, 225 since access to content is blocked not only within the jurisdiction 226 of the seizure, but globally, even when it may be affirmatively legal 227 elsewhere [RojaDirecta]. When domain redirection is effected via 228 redirections at intermediate resolvers rather than at authoritative 229 servers, it directly contradicts end-to-end assumptions in the DNS 230 security architecture [RFC4033], potentially causing validation 231 failures by validating end-nodes. 233 Safe Browsing: Modern web browsers provide some measures to prevent 234 users from accessing malicious web sites. For instance, before 235 loading a URI, current versions of Google Chrome and Firefox use the 236 Google Safe Browsing service to determine whether or not a given URI 237 is safe to load [SafeBrowsing]. The DNS can also be used to store 238 third party information that mark domains as safe or unsafe 239 [RFC5782]. 241 Manipulation of routing and addressing data: Governments have 242 recently intervened in the management of IP addressing and routing 243 information in order to maintain control over a specific set of DNS 244 servers. As part of an internationally coordinated response to the 245 DNSChanger malware, a Dutch court ordered the RIPE NCC to freeze the 246 accounts of several resource holders as a means to limit the resource 247 holders' ability to use certain address blocks [GhostClickRIPE](also 248 see Section 4.3). These actions have led to concerns that the number 249 resource certification system and related secure routing technologies 250 developed by the IETF's SIDR working group might be subject to 251 government manipulation as well [RFC6480], potentially for the 252 purpose of denying targeted networks access to the Internet. 254 3. Characteristics of Blocking Systems 256 At a generic level, blocking systems can be characterized by four 257 attributes: the entity that sets the blocking policy, the purpose of 258 the blocking, the intended target of the blocking, and the Internet 259 component(s) used as the basis of the blocking system. 261 3.1. Entities that set blocking policies 263 Parties that institute blocking policies include governments, 264 enterprises, network operators, application providers, and individual 265 end users. In some cases, these parties use their own technical 266 assets to conduct blocking; for example, a network operator might 267 install a firewall in its own networking equipment, or a web 268 application provider might block responses between its web server and 269 certain clients. In other cases, particularly in the case of 270 blocking initiated by governments, the entity that institutes the 271 blocking policy works with other entities to effectuate blocking 272 using technical assets that it does not control. 274 3.2. Purposes of blocking 276 Entities may be motivated to filter for a variety of purposes: 278 o Preventing or responding to security threats. Network operators, 279 enterprises, application providers, and end users often block 280 communications that are believed to be associated with security 281 threats or network attacks. 283 o Restricting objectionable content or services. Certain 284 communications may be viewed as undesirable, harmful, or illegal 285 by particular governments, enterprises, or users (e.g., parents). 287 Governments may seek to block communications that are deemed to be 288 defamation, hate speech, obscenity, intellectual property 289 infringement, or otherwise objectionable. Enterprises may seek to 290 restrict employees from accessing content that is not deemed to be 291 work appropriate. Parents may restrict their children from 292 accessing content or services targeted for adults. 294 o Restricting access based on business arrangements. Some networks 295 are designed so as to only provide access to certain content or 296 services ("walled gardens"), or to only provide limited access 297 until end users pay for full Internet services (captive portals 298 provided by hotspot operators, for example). 300 Note that the purpose for which blocking occurs often dictates 301 whether the blocking system operates on a blacklist model, where 302 communications are allowed by default but a subset are blocked, or a 303 whitelist model, where communications are blocked by default with 304 only a subset allowed. Captive portals, walled gardens, and 305 sandboxes used for security or network endpoint assessment usually 306 require a whitelist model since the scope of communications allowed 307 is narrow. Blocking for other purposes often uses a blacklist model 308 since only individual content or traffic is intended to be blocked. 310 3.3. Intended targets of blocking 312 Entities institute blocking systems so as to target particular 313 content, services, endpoints, or some combination of these. For 314 example, a "content" filtering system used by an enterprise might 315 block access to specific URIs whose content is deemed by the 316 enterprise to be inappropriate for the work place. This is distinct 317 from a "service" filtering system that blocks all web traffic 318 (perhaps as part of a parental control system on an end user device), 319 and also distinct from an "endpoint" filtering system in which a web 320 application blocks traffic from specific endpoints that are suspected 321 of malicious activity. 323 As discussed in Section 4, the design of a blocking system may affect 324 content, services, or endpoints other than those that are the 325 intended targets. For example, the domain name seizures described 326 above target particular web pages associated with illegal activity, 327 but by removing the domains from use, they affect all services made 328 available by the hosts associated with those names, including mail 329 services and web services unrelated to the illegal activity. 331 3.4. Components used for blocking 333 Broadly speaking, the process of a delivering an Internet service 334 involves three different components: 336 1. Endpoints: The actual content of the service is typically an 337 application layer protocol between two Internet hosts. In many 338 protocols, there are two endpoints, a client and a server. 340 2. Network services: The endpoints communicate by way of a 341 collection of IP networks that use routing protocols to determine 342 how to deliver packets between the endpoints. 344 3. Rendezvous services: Service endpoints are typically identified 345 by identifiers than are more "human-friendly" than IP addresses. 346 Rendezvous services allow one endpoint to figure out how to 347 contact another endpoint based on an identifier. 349 Consider, for example, an HTTP transaction fetching the content of 350 the URI . The client endpoint is an 351 end host running a browser. The client uses the DNS as a rendezvous 352 service when it performs a AAAA query to obtain the IP address for 353 the server name "example.com". The client then establishes a 354 connection to the server, and sends the actual HTTP request. The 355 server then responds to the HTTP request. 357 As another example, in the SIP protocol, the client and server are IP 358 phones, and the rendezvous service is provided by an application- 359 layer SIP proxy as well as the DNS. 361 Blocking access to Internet content, services, or endpoints is done 362 by controlling one or more of the components involved in the 363 provision of the communications involved in accessing the content, 364 services or endpoints. In the HTTP example above, the successful 365 completion of the HTTP request could have been prevented in several 366 ways: 368 o [Endpoint] Preventing the client from making the request 370 o [Endpoint] Preventing the server from responding to the request 372 o [Endpoint] Preventing the client from making a DNS request for 373 example.com 375 o [Network] Preventing the request from reaching the server 377 o [Network] Preventing the response from reaching the client 378 o [Network] Preventing the client from reaching the DNS server 380 o [Network] Preventing the DNS response from reaching the client 382 o [Rendezvous] Preventing the DNS server from providing the client 383 the correct IP address of the server 385 Most entities that desire to block communications will have access to 386 only one or two components, and therefore their choices for how to 387 effectuate blocking will be limited. End users and application 388 providers can usually only control their own software and hardware, 389 which means that they are limited to endpoint-based filtering. Some 390 network operators offer filtering services that their customers can 391 activate individually, in which case end users might have network- 392 based filtering systems available to them. Network operators can 393 control their own networks and the rendezvous services for which they 394 provide infrastructure support (e.g., DNS resolvers) or to which they 395 may have access (e.g., SIP proxies), but not usually endpoints. 396 Enterprises usually have access to their own networks and endpoints 397 for filtering purposes. Governments might make arrangements with the 398 operators or owners of any of the three components that exist within 399 their jurisdictions to effectuate filtering. 401 In the next section, blocking systems designed according to each of 402 the three patterns -- network services, rendezvous services, and 403 endpoints -- are evaluated for their technical and architectural 404 implications. The analysis is as agnostic as possible as to which 405 kind of entity sets the blocking policy (government, end user, 406 network operator, application provider, or enterprise), but in some 407 cases the way in which a particular blocking design pattern is used 408 might differ depending on the entity that desires to block. For 409 example, a network-based firewall provided by an ISP that parents can 410 elect to use for parental control purposes will likely function 411 differently from one that all ISPs in a particular jurisdiction are 412 required to use by the local government, even though in both cases 413 the same component (network) forms the basis of the blocking system. 415 4. Evaluation of Blocking Design Patterns 417 4.1. Criteria for evaluation 419 To evaluate the technical implications of each of the blocking design 420 patterns, we compare them based on four criteria: scope, granularity, 421 efficacy, and security. 423 4.1.1. Scope: What content or services can be blocked? 425 The Internet is comprised of many distinct autonomous networks and 426 applications, which means that the impact of a blocking system will 427 only be within a defined scope. For example, blocking within an 428 access network will only affect a relatively small, well-defined set 429 of users (namely, those connected to the access network), but can 430 affect all applications for those users. Blocking effectuated by an 431 application provider can affect users across the entire Internet, but 432 only for that specific application. Thus the scope of the impact 433 might be narrow in one dimension (set of users or set of applications 434 affected) but broad in another. In some cases, applications and 435 rendezvous services are so intertwined with each other that filtering 436 a single service or in a single network location can have broad 437 effects in multiple directions. Blocking systems are generally 438 viewed as less objectionable if the scope of their impact is as 439 narrow as possible while still being effective. 441 4.1.2. Granularity: How specific is the blocking? Will blocking one 442 service also block others? 444 Internet applications are built out of a collection of loosely- 445 coupled components or "layers." Different layers serve different 446 purposes, and rely on or offer different functions such as routing, 447 transport, and naming (see [RFC1122], especially Section 1.1.3). The 448 functions at these layers are developed autonomously and almost 449 always operated by different entities. For example, in many 450 networks, physical and link-layer connectivity is provided by an 451 "access provider", IP routing is performed by an "Internet service 452 provider," and application-layer services are provided by completely 453 separate entities (e.g., web servers). Upper-layer protocols and 454 applications rely on combinations of lower-layer functions in order 455 to work. Functionality at higher layers tends to be more 456 specialized, so that many different specialized applications can make 457 use of the same generic underlying network functions. 459 As a result of this structure, actions taken at one layer can affect 460 functionality or applications at higher layers. For example, 461 manipulating routing or naming functions to restrict access to a 462 narrow set of resources via specific applications will likely affect 463 all applications that depend on those functions. As with the scope 464 criteria, blocking systems are generally viewed as less objectionable 465 when they are highly granular and do not cause collateral damage to 466 content or services unrelated to the target of the blocking 467 [RFC4924]. 469 Even within the application layer, the granularity of blocking can 470 vary depending on how targeted the blocking system is designed to be. 472 Blocking all traffic associated with a particular application 473 protocol is less granular than blocking only traffic associated with 474 a subset of application instances that make use of that protocol. 475 Sophisticated heuristics that make use of information about the 476 application protocol, lower-layer protocols, payload signatures, 477 source and destination addresses, inter-packet timing, packet sizes, 478 and other characteristics are sometimes used to narrow the subset of 479 traffic to be blocked. 481 Design flaws in blocking systems may also cause the effects of 482 blocking to be overbroad. For example, web filtering systems in 483 India and China have been shown to cause "collateral damage" by 484 unwittingly blocking users in Oman and the US from accessing web 485 sites in Germany and Korea 486 [IN-OM-filtering][CCS-GFC-collateral-damage]. 488 4.1.3. Efficacy: How easy is it for a resource or service to avoid 489 being blocked? 491 For blacklist-style blocking, the distributed and mobile nature of 492 Internet resources limits the effectiveness of blocking actions. A 493 service that is blocked in one jurisdiction can often be moved or re- 494 instantiated in another jurisdiction (see, for example, 495 [Malicious-Resolution]). Likewise, services that rely on blocked 496 resources can often be rapidly re-configured to use non-blocked 497 resources. If a web site is prevented from using a domain name or 498 set of IP addresses, the web site can simply move to another domain 499 name or network. In a process known as "snowshoe spamming," a spam 500 originator uses addresses in many different networks as sources for 501 spam. This technique is already widely used to spread spam 502 generation across a variety of resources and jursidictions to prevent 503 spam blocking from being effective. 505 In the presence of either blacklist or whitelist systems, users may 506 choose to use different sets of protocols or otherwise alter their 507 traffic characteristics to circumvent filters. As discussed in 508 [I-D.blanchet-iab-internetoverport443], many applications shift their 509 traffic to port 80 or 443 when other ports are blocked. This sort of 510 circumvention based on shifting ports can succeed because port 511 selection is designed to only be meaningful to endpoints, not to the 512 network. If voice communication based on SIP [RFC3261] is blocked, 513 users are likely to use proprietary protocols that allow them to talk 514 to each other. Some filtering systems are only capable of 515 identifying IPv4 traffic and therefore by shifting to IPv6 users may 516 be able to evade filtering. Using IPv6 with header options, using 517 multiple layers of tunnels, or using encrypted tunnels can also make 518 it more challenging for blocking systems to find transport ports 519 within packets, making port-based blocking more difficult. Thus 520 distribution and mobility can hamper efforts to block communications 521 in a number of ways. 523 4.1.4. Security: How does the blocking impact existing trust 524 infrastructures? 526 Modern security mechanisms rely on trusted hosts communicating via a 527 secure channel without intermediary interference. Protocols such as 528 TLS and IPsec [RFC5246][RFC4301] are designed to ensure that each 529 endpoint of the communication knows the identity of the other 530 endpoint, and that only the endpoints of the communication can access 531 the secured contents of the communication. For example, when a user 532 connects to a bank's web site, TLS ensures that the user's banking 533 information is securely communicated to the bank and nobody else, 534 ensuring the data remains confidential while in transit. 536 Some blocking strategies require intermediaries to insert themselves 537 within the end-to-end communications path, potentially breaking 538 security properties of Internet protocols [RFC4924]. In these cases 539 it can be difficult or impossible for endpoints to distinguish 540 between attackers and "authorized" entities conducting blocking. 542 4.2. Network-Based Blocking 544 Being able to block access to resources without the consent or 545 cooperation of either endpoint to a communication is viewed as a 546 desirable feature by some entities that deploy blocking systems. 547 Systems that have this property are often implemented using 548 intermediary devices in the network, such as firewalls or filtering 549 systems. These systems inspect traffic as it passes through the 550 network, decide based on the characteristics or content of a given 551 communication whether it should be blocked, and then block or allow 552 the communication as desired. For example, web filtering devices 553 usually inspect HTTP requests to determine the URI being requested, 554 compare that URI to a list of black-listed or white-listed URIs, and 555 allow the request to proceed only if it is permitted by policy (or at 556 least not forbidden). Firewalls perform a similar function for other 557 classes of traffic in addition to HTTP. Some blocking systems focus 558 on specific application-layer traffic, while others, such as router 559 ACLs, filter traffic based on lower layer criteria (transport 560 protocol and source or destination addresses or ports). 562 Intermediary systems used for blocking are often not far from the 563 edge of the network. For example, many enterprise networks operate 564 firewalls that block certain web sites, as do some residential ISPs. 565 In some cases, this filtering is done with the consent or cooperation 566 of the affected endpoints. PCs within an enterprise, for example, 567 might be configured to trust an enterprise proxy, a residential ISP 568 might offer a "safe browsing" service, or mail clients might 569 authorize mail servers on the local network to filter spam on their 570 behalf. These cases share some of the properties of the "Endpoint- 571 Based Blocking" scenarios discussed in Section 4.4 below, since the 572 endpoint has made an informed decision to authorize the intermediary 573 to block on its behalf and is therefore unlikely to attempt to 574 circumvent the blocking. From an architectural perspective, however, 575 they may create many of the same problems as network-based filtering 576 conducted without consent. 578 4.2.1. Scope 580 Network-based approaches to blocking run into several technical 581 issues that limit their viability in practice. In particular, many 582 issues arise from the fact that an intermediary needs to have access 583 to a sufficient amount of traffic to make its blocking 584 determinations. 586 For residential or consumer networks with many egress points, the 587 first challenge to obtaining this traffic is simply gaining access to 588 the constituent packets. The Internet is designed to deliver packets 589 hop-by-hop from source to destination -- not to any particular point 590 along the way. In practice, inter-network routing is often 591 asymmetric, and for sufficiently complex local networks, intra- 592 network traffic flows can be asymmetric as well [asymmetry]. 594 This asymmetry means that an intermediary in a network with many 595 egress points will often see only one half of a given communication 596 (if it sees any of it at all), which may limit the scope of the 597 communications that it can filter. For example, a filter aimed at 598 requests destined for particular URIs cannot make accurate blocking 599 decisions if it is only in the data path for HTTP responses and not 600 requests. Asymmetry may be surmountable given a filtering system 601 with enough distributed, interconnected filtering nodes that can 602 coordinate information about flows belonging to the same 603 communication or transaction, but depending on the size of the 604 network this may imply significant complexity in the filtering 605 system. Routing can sometimes be forced to be symmetric within a 606 given network using routing configuration, NAT, or layer-2 mechanisms 607 (e.g., MPLS), but these mechanisms are frequently brittle, complex, 608 and costly -- and can sometimes result in reduced network performance 609 relative to asymmetric routing. Enterprise networks may also be less 610 susceptible to these problems if they route all traffic through a 611 small number of egress points. 613 4.2.2. Granularity 615 Once an intermediary in a network has access to traffic, it must 616 identify which packets must be filtered. This decision is usually 617 based on some combination of information at the network layer (e.g., 618 IP addresses), transport layer (ports), or application layer (URIs or 619 other content). Blocking based on application-layer attributes can 620 be potentially more granular and less likely to cause collateral 621 damage than blocking all traffic associated with a particular 622 address, which can impact unrelated occupants of the same address. 623 However, more narrowly focused targeting may be more complex, less 624 efficient, or easier to circumvent than filtering that sweeps more 625 broadly, and entities that seek to block may balance these attributes 626 against each other when choosing a blocking system. 628 4.2.3. Efficacy and security 630 Regardless of the layer at which blocking occurs, it may be open to 631 circumvention, particularly in cases where network endpoints have not 632 authorized the blocking. The communicating endpoints can deny the 633 intermediary access to attributes at any layer by using encryption 634 (see below). IP addresses must be visible, even if packets are 635 protected with IPsec, but blocking based on IP addresses can be 636 trivial to circumvent. A filtered site may be able to quickly change 637 its IP address using only a few simple steps: changing a single DNS 638 record and provisioning the new address on its server or moving its 639 services to the new address. Indeed, in the face of IP-based 640 blocking in some networks, services such as The Pirate Bay are now 641 using cloud hosting services so that their IP addresses are difficult 642 for intermediaries to predict [BT-TPB][TPB-cloud]. 644 If application content is encrypted with a security protocol such as 645 IPsec or TLS, then the intermediary will require the ability to 646 decrypt the packets to examine application content. Since security 647 protocols are designed to provide end-to-end security (i.e., to 648 prevent intermediaries from examining content), the intermediary 649 would need to masquerade as one of the endpoints, breaking the 650 authentication in the security protocol, reducing the security of the 651 users and services affected, and interfering with legitimate private 652 communication. Besides, various techniques that use public databases 653 with whitelisted keys (e.g., DANE [RFC6698]) enable users to detect 654 these sort of intermediaries. Those users are then likely to act as 655 if the service is blocked. 657 If the intermediary is unable to decrypt the security protocol, then 658 its blocking determinations for secure sessions can only be based on 659 unprotected attributes, such as IP addresses, protocol IDs and port 660 numbers. Some blocking systems today still attempt to block based on 661 these attributes, for example by blocking TLS traffic to known 662 proxies that could be used to tunnel through the blocking system. 664 However, as the Telex project recently demonstrated, if an endpoint 665 cooperates with a relay in the network (e.g., a Telex station), it 666 can create a TLS tunnel that is indistinguishable from legitimate 667 traffic [Telex]. For example, if an ISP used by a banking website 668 were to operate a Telex station at one of its routers, then a 669 blocking system would be unable to distinguish legitimate encrypted 670 banking traffic from Telex-tunneled traffic (potentially carrying 671 content that would have been filtered). 673 Thus, in principle in a blacklist system it is impossible to block 674 tunneled traffic through an intermediary device without blocking all 675 secure traffic. (The only limitation in practice is the requirement 676 for special software on the client.) In most cases, blocking all 677 secure traffic is an unacceptable consequence of blocking, since 678 security is often required for services such as online commerce, 679 enterprise VPNs, and management of critical infrastructure. If 680 governments or network operators were to force these services to use 681 insecure protocols so as to effectuate blocking, they would expose 682 their users to the various attacks that the security protocols were 683 put in place to prevent. 685 Some operators may assume that only blocking access to resources 686 available via unsecure channels is sufficient for their purposes -- 687 i.e., that the size of the user base that will be willing to use 688 secure tunnels and/or special software to circumvent the blocking is 689 low enough to make blocking via intermediaries worthwhile. Under 690 that assumption, one might decide that there is no need to control 691 secure traffic, and thus that network-based blocking is an attractive 692 option. 694 However, the longer such blocking systems are in place, the more 695 likely it is that efficient and easy-to-use tunneling tools will 696 become available. The proliferation of the Tor network, for example, 697 and its increasingly sophisticated blocking-avoidance techniques 698 demonstrate that there is energy behind this trend [Tor]. Thus, 699 network-based blocking becomes less effective over time. 701 Network-based blocking is a key contributor to the arms race that has 702 led to the development of these kinds of tools, the result of which 703 is to create unnecessary layers of complexity in the Internet. 704 Before content-based blocking became common, the next best option for 705 network operators was port blocking, the widespread use of which has 706 driven more applications and services to use ports (80 and 443 most 707 commonly) that are unlikely to be blocked. In turn, network 708 operators shifted to finer-grained content blocking over port 80, 709 content providers shifted to encrypted channels, and operators began 710 seeking to identify those channels (although doing so can be 711 resource-prohibitive, especially if tunnel endpoints begin to change 712 frequently). Because the premise of network-based blocking is that 713 endpoints have incentives to circumvent it, this cat-and-mouse game 714 is an inevitable by-product of this form of blocking. 716 4.2.4. Summary 718 In sum, network-based blocking is only effective in a fairly 719 constrained set of circumstances. First, the traffic needs to flow 720 through the network in such a way that the intermediary device has 721 access to any communications it intends to block. Second, the 722 blocking system needs an out-of-band mechanism to mitigate the risk 723 of secure protocols being used to avoid blocking (e.g., human 724 analysts identifying IP addresses of tunnel endpoints). If the 725 network is sufficiently complex, or the risk of tunneling too high, 726 then network-based blocking is unlikely to be effective, and in any 727 case this type of blocking drives the development of increasingly 728 complex layers of circumvention. Network-based blocking can be done 729 without the cooperation of either endpoint to a communication, but it 730 has the serious drawback of breaking end-to-end security assurances 731 in some cases. The fact that network-based blocking is premised on 732 this lack of cooperation results in arms races that increase the 733 complexity of both application design and network design. 735 4.3. Rendezvous-Based Blocking 737 Internet applications often require or rely on support from common, 738 global rendezvous services, including the DNS, certificate 739 authorities, WHOIS databases, and Internet Route Registries. These 740 services control or register the structure and availability of 741 Internet applications by providing data elements that are used by 742 application code. Some applications also have their own specialized 743 rendezvous services. For example, to establish an end-to-end SIP 744 call the end-nodes (terminals) will rely on presence and session 745 information supplied by SIP servers. 747 Global rendezvous services are comprised of generic technical 748 databases intended to record certain facts about the network. The 749 DNS, for example, stores information about which servers provide 750 services for a given name; the RPKI about which entities have been 751 allocated IP addresses. To offer specialized Internet services and 752 applications, different entities rely on these generic records in 753 different ways. Thus the effects of changes to the databases can be 754 much more difficult to predict than, for example, the effect of 755 shutting down a web server (which fulfills the specific purpose of 756 serving web content). 758 Although rendezvous services are discussed as a single category, the 759 precise characteristics and implications of blocking each kind of 760 rendezvous service are slightly different. This section provides 761 examples to highlight these differences. 763 4.3.1. Scope 765 In the case of government-initiated blocking, the servers that are 766 used to provide rendezvous services exist within specific 767 jurisdictions, and their operators are thus subject to jurisdictional 768 laws. It is thus possible for laws to be structured to effectuate 769 blocking by imposing obligations on the operators of rendezvous 770 services within a jurisdiction, either via direct government action 771 or by allowing private actors to demand blocking (e.g., through 772 lawsuits). 774 The scope of blocking conducted by other entities will depend on 775 which servers those entities can access. For example, network 776 operators and enterprises may be capable of conducting blocking using 777 their own DNS resolvers or application proxies within their networks, 778 but not authoritative servers controlled by others. 780 4.3.2. Granularity 782 Blocking based on global rendezvous services tends to be overbroad 783 because the resources blocked often support multiple services. This 784 can cause collateral damage to legitimate uses of a resource. For 785 example, a given address or domain name might host both legitimate 786 services and services that governments desire to block. A service 787 hosted under a domain name and operated in a jurisdiction where it is 788 considered undesirable might be considered legitimate in another 789 jurisdiction; a blocking action in the host jurisdiction would deny 790 legitimate services in the other. 792 4.3.3. Efficacy 794 The distributed nature of the Internet limits the efficacy of 795 blocking based on rendezvous services. If the Internet community 796 realizes that a blocking decision has been made and wishes to counter 797 it, then local networks can "patch" the authoritative data that the 798 rendezvous service provides to avoid the blocking (although the 799 development of DNSSEC and the RPKI are causing this to change by 800 requiring updates to be authorized). In the DNS case, registrants 801 whose names get blocked can relocate their resources to different 802 names. 804 Endpoints can also choose not to use a particular rendezvous service. 805 They might switch to a competitor or use an alternate mechanism (for 806 example, IP literals in URIs to circumvent DNS filtering). 808 4.3.4. Security and other implications 810 Blocking of global rendezvous services also has a variety of other 811 implications that may reduce the stability, accessibility, and 812 usability of the global Internet. Infrastructure-based blocking may 813 erode the trust in the general Internet and encourage the development 814 of parallel or "underground" infrastructures causing forms of 815 Internet balkanisation, for example. This risk may become more acute 816 as the introduction of security infrastructures and mechanisms such 817 as DNSSEC and RPKI "hardens" the authoritative data -- including 818 blocked names or routes -- that the existing infrastructure services 819 provide. Those seeking to circumvent the blocks may opt to use less- 820 secure but unblocked parallel services. As applied to the DNS, these 821 considerations are further discussed in ISOC's whitepaper on DNS 822 filtering [ISOCFiltering], but they also apply to other global 823 Internet resources. 825 4.3.5. Examples 827 Below we provide a few specific examples for routing, DNS, and WHOIS 828 services. These examples demonstrate that for these types of 829 rendezvous services (services that are often considered a global 830 commons), jusrisdiction-specific legal and ethical motivations for 831 blocking can both have collateral effects in other jurisdictions and 832 be circumvented because of the distributed nature of the Internet. 834 In 2008, Pakistan Telecom attempted to deny access to YouTube within 835 Pakistan by announcing bogus routes for YouTube address space to 836 peers in Pakistan. YouTube was temporarily denied service on a 837 global basis as a result of a route leak beyond the Pakistan ISP's 838 scope, but service was restored in approximately two hours because 839 network operators around the world re-configured their routers to 840 ignore the bogus routes [RenesysPK]. In the context of SIDR and 841 secure routing, a similar re-configuration could theoretically be 842 done if a resource certificate were to be revoked in order to block 843 routing to a given network. 845 In the DNS realm, one of the recent cases of US law enforcement 846 seizing domain names involved RojaDirecta, a Spanish web site. Even 847 though several of the affected domain names belonged to Spanish 848 entities, they were subject to blocking by the US government because 849 certain servers were operated in the US. Government officials 850 required the operators of the parent zones of a target name (e.g., 851 "com" for "example.com") to direct queries for that name to a set of 852 US-government-operated name servers. Users of other services under a 853 target name (e.g. e-mail) would thus be unable to locate the servers 854 providing services for that name, denying them the ability to access 855 these services. 857 Similar workarounds as those that were used in the Pakistan Telecom 858 case are also available in the DNS case. If a domain name is blocked 859 by changing authoritative records, network operators can restore 860 service simply by extending TTLs on cached pre-blocking records in 861 recursive resolvers, or by statically configuring resolvers to return 862 un-blocked results for the affected name. However, depending on 863 availability of valid signature data, these types of workarounds will 864 not work with DNSSEC-signed data. 866 The action of the Dutch authorities against the RIPE NCC, where RIPE 867 was ordered to freeze the accounts Internet resource holders, is of a 868 similar character. By controlling the account holders' WHOIS 869 information, this type of action limited the ability of the ISPs in 870 question to manage their Internet resources. This example is 871 slightly different from the others because it does not immediately 872 impact the ability of ISPs to provide connectivity. While ISPs use 873 (and trust) the WHOIS databases to build route filters or use the 874 databases for trouble-shooting information, the use of the WHOIS 875 databases for those purposes is voluntary. Thus, seizure of this 876 sort may not have any immediate effect on network connectivity, but 877 it may impact overall trust in the common infrastructure. It is 878 similar to the other examples in that action in one jurisdiction can 879 have broader effects, and in that the global system may encourage 880 networks to develop their own autonomous solutions. 882 4.3.6. Summary 884 In summary, rendezvous-based blocking can sometimes be used to 885 immediately block a target service by removing some of the resources 886 it depends on. However, such blocking actions can have harmful side 887 effects due to the global nature of Internet resources and the fact 888 that many different application-layer services rely on generic, 889 global databases for rendezvous purposes. The fact that Internet 890 resources can quickly shift between network locations, names, and 891 addresses, together with the autonomy of the networks that comprise 892 the Internet, can mean that the effects of rendezvous-based blocking 893 can be negated on short order in some cases. For some applications, 894 rendezvous services are optional to use, not mandatory. Hence they 895 are only effective when the endpoint or the endpoint's network 896 chooses to use them; they can be routed around by choosing not to use 897 the rendezvous service or migrating to an alternative one. To adapt 898 a quote by John Gilmore, "The Internet treats blocking as damage and 899 routes around it". 901 4.4. Endpoint-Based Blocking 903 Internet users and their devices constantly make decisions as to 904 whether to engage in particular Internet communications. Users 905 decide whether to click on links in suspect email messages; browsers 906 advise users on sites that have suspicious characteristics; spam 907 filters evaluate the validity of senders and messages. If the 908 hardware and software making these decisions can be instructed not to 909 engage in certain communications, then the communications are 910 effectively blocked because they never happen. 912 There are several systems in place today that advise user systems 913 about which communications they should engage in. As discussed 914 above, several modern browsers consult with "Safe Browsing" services 915 before loading a web site in order to determine whether the site 916 could potentially be harmful. Spam filtering is one of the oldest 917 types of filtering in the Internet; modern filtering systems 918 typically make use of one or more "reputation" or "blacklist" 919 databases in order to make decisions about whether a given message or 920 sender should be blocked. These systems typically have the property 921 that many filtering systems (browsers, MTAs) share a single 922 reputation service. Even the absence of a provisioned PTR records 923 for an IP address may result in email messages not being accepted. 925 4.4.1. Scope and granularity 927 Endpoint-based blocking lacks some of the limitations of rendezvous- 928 based blocking: while rendezvous-based blocking can only see and 929 affect the rendezvous service at hand (e.g., DNS name resolution), 930 endpoint-based blocking can see into the entire application, across 931 all layers and transactions. This visibility can provide endpoint- 932 based blocking systems with a much richer set of information for 933 making narrow blocking decisions. Support for narrow granularity 934 depends on how the application protocol client and server are 935 designed, however. A typical endpoint-based firewall application may 936 have less ability to make fine-grained decisions than an application 937 that does its own blocking (see [I-D.iab-host-firewalls] for further 938 discussion). 940 In an endpoint-based blocking system, blocking actions are performed 941 autonomously, by individual endpoints or their delegates. The 942 effects of blocking are thus usually local in scope, minimizing the 943 effects on other users or other, legitimate services. 945 4.4.2. Efficacy 947 Endpoint-based blocking deals well with mobile adversaries. If a 948 blocked service relocates resources or uses different resources, a 949 rendezvous- or network-based blocking approach may not be able to 950 affect the new resources (at least not immediately). A network-based 951 blocking system may not even be able to tell whether the new 952 resources are being used, if the previously blocked service uses 953 secure protocols. By contrast, endpoint-based blocking systems can 954 detect when a blocked service's resources have changed (because of 955 their full visibility into transactions) and adjust blocking as 956 quickly as new blocking data can be sent out through a reputation 957 system. 959 The primary challenge to endpoint-based blocking is that it requires 960 the cooperation of endpoints. Where this cooperation is willing, 961 this is a fairly low barrier, requiring only reconfiguration or 962 software update. Where cooperation is unwilling, it can be 963 challenging to enforce cooperation for large numbers of endpoints. 964 That challenge is exacerbated when the endpoints are a diverse set of 965 static, mobile or visiting endpoints. If cooperation can be 966 achieved, endpoint-based blocking can be much more effective than 967 other approaches because it is so coherent with the Internet's 968 architectural principles. 970 4.4.3. Security 972 Endpoint-based blocking is performed at one end of an Internet 973 communication, and thus avoids the problems related to end-to-end 974 security mechanisms that network-based blocking runs into and the 975 challenges to global trust infrastructures that rendezvous-based 976 blocking creates. 978 4.4.4. Summary 980 Out of the three design patterns, endpoint-based blocking is the 981 least likely to cause collateral damage to Internet services or the 982 overall Internet architecture. Endpoint-based blocking systems can 983 see into all layers involved in a communication, allowing blocking to 984 be narrowly targeted. Adversary mobility can be accounted for as 985 soon as reputation systems are updated with new adversary 986 information. One potential drawback of endpoint-based blocking is 987 that it requires the endpoint's cooperation; effectuating blocking at 988 an endpoint when it is not in the endpoint's interest is therefore 989 difficult to accomplish because the endpoint's user can disable the 990 blocking or switch to a different endpoint. 992 4.4.5. Server Endpoints 994 In this discussion of endpoint-based blocking, the focus has been on 995 the consuming side of the end-to-end communication, mostly the client 996 side of a client-server type connection. However, similar 997 considerations apply to the content-producing side of end-to-end 998 communications, regardless of whether that endpoint is a server in a 999 client-server connection or a peer in a peer-to-peer type of 1000 connection. 1002 For instance, for blocking of web content, narrow targeting can be 1003 achieved through whitelisting methods like password authentication 1004 whereby passwords are available only to authorized clients. For 1005 example, a web site might only make adult content available to users 1006 who provide credit card information, which is assumed to be a proxy 1007 for age. 1009 The fact that content-producing endpoints do not take it upon 1010 themselves to block particular forms of content in response to 1011 requests from governments or other parties can sometimes motivate 1012 those latter parties to engage in blocking elsewhere within the 1013 Internet. 1015 5. Security Considerations 1017 The primary security concern related to Internet service blocking is 1018 the effect that it has on the end-to-end security model of many 1019 Internet security protocols. When blocking is enforced by an 1020 intermediary with respect to a given communication, the blocking 1021 system may need to obtain access to confidentiality-protected data to 1022 make blocking decisions. Mechanisms for obtaining such access often 1023 require the blocking system to defeat the authentication mechanisms 1024 built into security protocols. 1026 For example, some enterprise firewalls will dynamically create TLS 1027 certificates under a trust anchor recognized by endpoints subject to 1028 blocking. These certificates allow the firewall to authenticate as 1029 any website, so that it can act as a man-in-the-middle on TLS 1030 connections passing through the firewall. This is not unlike an 1031 external attacker using compromised certificates to intercept TLS 1032 connections. 1034 Modifications such as these obviously make the firewall itself an 1035 attack surface. If an attacker can gain control of the firewall or 1036 compromise the key pair used by the firewall to sign certificates, 1037 the attacker will have access to the unencrypted data of all current 1038 and recorded TLS sessions for all users behind that firewall, in a 1039 way that is undetectable to users. Besides, if the compromised key- 1040 pairs can be extracted from the firewall, all users, not only those 1041 behind the firewall, that rely on that public key are vulnerable. 1043 When blocking systems are unable to inspect and surgically block 1044 secure protocols, it is tempting to completely block those protocols. 1045 For example, a web blocking system that is unable to inspect HTTPS 1046 connections might simply block any attempted HTTPS connection. 1047 However, since Internet security protocols are commonly used for 1048 critical services such as online commerce and banking, blocking these 1049 protocols would block access to these services as well, or worse, 1050 force them to be conducted over insecure communication. 1052 Security protocols can, of course, also be used as mechanisms for 1053 blocking services. For example, if a blocking system can insert 1054 invalid credentials for one party in an authentication protocol, then 1055 the other end will typically terminate the connection based on the 1056 authentication failure. However, it is typically much simpler to 1057 simply block secure protocols than to exploit those protocols for 1058 service blocking. 1060 6. Conclusion 1062 Because it least likely to create technical or architectural 1063 problems, endpoint-based blocking is the form of Internet service 1064 blocking that is least harmful to the Internet. From a technical 1065 perspective, it is the most preferred option because it maintains 1066 transparency of the network, vests functionality at the endpoints, 1067 can be applied granularly so as to avoid collateral damage, and 1068 accommodates mobile adversaries. Entities seeking to filter and for 1069 whom endpoint-based blocking is a potential choice should view its 1070 technical benefits as distinct advantages compared to the other 1071 approaches. 1073 In reality, the various approaches discussed above are all applied 1074 for different reasons, and particular entities may not consider 1075 endpoint-based filtering to be viable. Often, the choice of a 1076 filtering solution is constrained by practical limitations on which 1077 parts of the network are under the control of the entity implementing 1078 filtering, and which parts of the network are trusted to cooperate. 1079 For example, an ISP that is subject to filtering requirements might 1080 implement a network-based filtering approach because it cannot be 1081 sure that endpoints will cooperate in filtering. As discussed above, 1082 government agencies tasked with disabling certain foreign web sites 1083 have done so by manipulating infrastructure servers that are within 1084 their own jurisdictions, based on legal claims to obtain access to 1085 those servers. An enterprise with filtering requirements might 1086 require employees to install a certain filtering software package on 1087 enterprise-owned PCs. 1089 It is therefore realistic to expect that certain entities will 1090 continue to attempt to conduct network- or rendezvous-based filtering 1091 since they may not have control over the endpoints they wish to 1092 affect or because the endpoints do not have incentives to consent to 1093 the filtering. In some cases, an approach that combines one of these 1094 with endpoint-based filtering can help strike a better balance. For 1095 example, a filtering system might make it possible for some endpoints 1096 to cooperate or "opt in" to additional endpoint-based filtering, 1097 rather than deploying a purely network-based solution. 1099 While this document has focused on technical mechanisms used to 1100 filter Internet content, a variety of non-technical mechanisms may 1101 also be available depending on the particular context and goals of 1102 the public or private entity seeking to restrict access to content. 1103 For example, purveyors of illegal online content can be pursued 1104 through international cooperation, by using the criminal justice 1105 system, and by targeting the funding that supports their activities 1106 through collaboration with financial services companies 1107 [click-trajectories]. Thus even in cases where endpoint-based 1108 filtering is not viewed as a viable means of restricting access to 1109 content, entities seeking to filter may find other strategies for 1110 achieving their goals that do not involve the operation of the 1111 Internet. 1113 Those with a desire to filter should take into account the 1114 limitations discussed in this document and holistically assess the 1115 space of technical and non-technical solutions at their disposal and 1116 the likely effectiveness of each combination of approaches. 1118 7. Informative References 1120 [BT-TPB] Meyer, D., "BT blocks The Pirate Bay", June 2012, 1121 . 1124 [CCS-GFC-collateral-damage] 1125 "The Collateral Damage of Internet Censorship by DNS 1126 Injection", July 2012, . 1129 [EarthquakeHT] 1130 Raj Upadhaya, G., ".ht: Recovering DNS from the Quake", 1131 March 2010, . 1135 [GhostClickRIPE] 1136 RIPE NCC, "RIPE NCC Blocks Registration in RIPE Registry 1137 Following Order from Dutch Police", 2012, 1138 . 1142 [I-D.blanchet-iab-internetoverport443] 1143 Blanchet, M., "Implications of Blocking Outgoing Ports 1144 Except Ports 80 and 443", draft-blanchet-iab- 1145 internetoverport443-02 (work in progress), July 2013. 1147 [I-D.iab-host-firewalls] 1148 Thaler, D., "Reflections On Host Firewalls", draft-iab- 1149 host-firewalls-00 (work in progress), June 2013. 1151 [IN-OM-filtering] 1152 Citizen Lab, , "Routing Gone Wild", July 2012, . 1155 [ISOCFiltering] 1156 Internet Society, "DNS: Finding Solutions to Illegal On- 1157 line Activities", 2012, . 1161 [Malicious-Resolution] 1162 Dagon, D., Provos, N., Lee, C., and W. Lee, "Corrupted DNS 1163 Resolution Paths: The Rise of a Malicious Resolution 1164 Authority", 2008, . 1167 [Morris] Kehoe, B., "The Robert Morris Internet Worm", 1992, 1168 . 1171 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1172 Communication Layers", STD 3, RFC 1122, October 1989. 1174 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, February 1175 2000. 1177 [RFC2979] Freed, N., "Behavior of and Requirements for Internet 1178 Firewalls", RFC 2979, October 2000. 1180 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1181 A., Peterson, J., Sparks, R., Handley, M., and E. 1182 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1183 June 2002. 1185 [RFC3724] Kempf, J., Austein, R., and IAB, "The Rise of the Middle 1186 and the Future of End-to-End: Reflections on the Evolution 1187 of the Internet Architecture", RFC 3724, March 2004. 1189 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1190 Rose, "DNS Security Introduction and Requirements", RFC 1191 4033, March 2005. 1193 [RFC4084] Klensin, J., "Terminology for Describing Internet 1194 Connectivity", BCP 104, RFC 4084, May 2005. 1196 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1197 Internet Protocol", RFC 4301, December 2005. 1199 [RFC4924] Aboba, B. and E. Davies, "Reflections on Internet 1200 Transparency", RFC 4924, July 2007. 1202 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1203 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1205 [RFC5782] Levine, J., "DNS Blacklists and Whitelists", RFC 5782, 1206 February 2010. 1208 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 1209 Secure Internet Routing", RFC 6480, February 2012. 1211 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 1212 of Named Entities (DANE) Transport Layer Security (TLS) 1213 Protocol: TLSA", RFC 6698, August 2012. 1215 [RenesysPK] 1216 Brown, M., "Pakistan hijacks YouTube", February 2008, 1217 . 1220 [RojaDirecta] 1221 Masnick, M., "Homeland Security Seizes Spanish Domain Name 1222 That Had Already Been Declared Legal", 2011, 1223 . 1227 [SAC-056] "SSAC Advisory on Impacts of Content Blocking via the 1228 Domain Name System", October 2012, . 1231 [SafeBrowsing] 1232 Google, "Safe Browsing API", 2012, . 1235 [TPB-cloud] 1236 "The Pirate Cloud", October 2012, 1237 . 1239 [Telex] Wustrow, E., Wolchok, S., Goldberg, I., and J. Halderman, 1240 "Telex: Anticensorship in the Network Infrastructure", 1241 August 2011, . 1243 [Tor] "Tor Project: Anonymity Online", 2012, . 1246 [US-ICE] U.S. Immigration and Customs Enforcement, "Operation in 1247 Our Sites", 2011, . 1250 [asymmetry] 1251 John, W., Dusi, M., and K. Claffy, "Estimating routing 1252 symmetry on single links by passive flow measurements", 1253 2010, . 1255 [click-trajectories] 1256 Levchenko, K., Pitsillidis, A., Chacra, N., Enright, B., 1257 Felegyhazi, M., Grier, C., Halvorson, T., Kreibich, C., 1258 Liu, H., McCoy, D., Weaver, N., Paxson, V., Voelker, G., 1259 and S. Savage, "Click Trajectories: End-to-End Analysis of 1260 the Spam Value Chain", 2011, 1261 . 1263 Authors' Addresses 1265 Richard Barnes 1266 Mozilla 1267 Suite 300 1268 650 Castro Street 1269 Mountain View, CA 94041 1270 US 1272 Email: rlb@ipv.sx 1273 Alissa Cooper 1274 Cisco 1275 707 Tasman Drive 1276 Milpitas, CA 95035 1277 USA 1279 Email: alcoop@cisco.com 1281 Olaf Kolkman 1282 NLnet Labs 1283 Science Park 400 1284 Amsterdam 1098 XH 1285 Netherlands 1287 Email: olaf@nlnetlabs.nl