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