idnits 2.17.1 draft-iab-filtering-considerations-09.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 (November 2, 2015) is 3097 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Endpoint' is mentioned on line 437, but not defined == Missing Reference: 'Network' is mentioned on line 445, but not defined == Missing Reference: 'Rendezvous' is mentioned on line 447, but not defined == Unused Reference: 'GhostClickRIPE' is defined on line 1308, 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 (~~), 5 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: May 5, 2016 Cisco 6 O. Kolkman 7 ISOC 8 D. Thaler 9 Microsoft 10 E. Nordmark 11 Arista 12 November 2, 2015 14 Technical Considerations for Internet Service Blocking and Filtering 15 draft-iab-filtering-considerations-09.txt 17 Abstract 19 The Internet is structured to be an open communications medium. This 20 openness is one of the key underpinnings of Internet innovation, but 21 it can also allow communications that may be viewed as undesirable by 22 certain parties. Thus, as the Internet has grown, so have mechanisms 23 to limit the extent and impact of abusive or objectionable 24 communications. Recently, there has been an increasing emphasis on 25 "blocking" and "filtering," the active prevention of such 26 communications. This document examines several technical approaches 27 to Internet blocking and filtering in terms of their alignment with 28 the overall Internet architecture. When it is possible to do so, the 29 approach to blocking and filtering that is most coherent with the 30 Internet architecture is to inform endpoints about potentially 31 undesirable services, so that the communicants can avoid engaging in 32 abusive or objectionable communications. We observe that certain 33 filtering and blocking approaches can cause unintended consequences 34 to third parties, and we discuss the limits of efficacy of various 35 approaches. 37 Status of this Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on May 5, 2016. 54 Copyright Notice 56 Copyright (c) 2015 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Filtering Examples . . . . . . . . . . . . . . . . . . . . . . 5 73 3. Characteristics of Blocking Systems . . . . . . . . . . . . . 7 74 3.1. The party who sets blocking policies . . . . . . . . . . . 8 75 3.2. Purposes of blocking . . . . . . . . . . . . . . . . . . . 8 76 3.2.1. Blacklist vs. Whitelist Model . . . . . . . . . . . . 9 77 3.3. Intended targets of blocking . . . . . . . . . . . . . . . 9 78 3.4. Components used for blocking . . . . . . . . . . . . . . . 9 79 4. Evaluation of Blocking Design Patterns . . . . . . . . . . . . 11 80 4.1. Criteria for evaluation . . . . . . . . . . . . . . . . . 11 81 4.1.1. Scope: What set of hosts and users are affected? . . . 11 82 4.1.2. Granularity: How specific is the blocking? Will 83 blocking one service also block others? . . . . . . . 12 84 4.1.3. Efficacy: How easy is it for a resource or service 85 to avoid being blocked? . . . . . . . . . . . . . . . 13 86 4.1.4. Security: How does the blocking impact existing 87 trust infrastructures? . . . . . . . . . . . . . . . . 14 88 4.2. Network-Based Blocking . . . . . . . . . . . . . . . . . . 15 89 4.2.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . 16 90 4.2.2. Granularity . . . . . . . . . . . . . . . . . . . . . 17 91 4.2.3. Efficacy and security . . . . . . . . . . . . . . . . 17 92 4.2.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 19 93 4.3. Rendezvous-Based Blocking . . . . . . . . . . . . . . . . 20 94 4.3.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . 20 95 4.3.2. Granularity . . . . . . . . . . . . . . . . . . . . . 21 96 4.3.3. Efficacy . . . . . . . . . . . . . . . . . . . . . . . 21 97 4.3.4. Security and other implications . . . . . . . . . . . 21 98 4.3.5. Examples . . . . . . . . . . . . . . . . . . . . . . . 22 99 4.3.6. Summary . . . . . . . . . . . . . . . . . . . . . . . 23 100 4.4. Endpoint-Based Blocking . . . . . . . . . . . . . . . . . 23 101 4.4.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . 24 102 4.4.2. Granularity . . . . . . . . . . . . . . . . . . . . . 24 103 4.4.3. Efficacy . . . . . . . . . . . . . . . . . . . . . . . 24 104 4.4.4. Security . . . . . . . . . . . . . . . . . . . . . . . 25 105 4.4.5. Server Endpoints . . . . . . . . . . . . . . . . . . . 25 106 4.4.6. Summary . . . . . . . . . . . . . . . . . . . . . . . 25 107 5. Security Considerations . . . . . . . . . . . . . . . . . . . 26 108 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 27 109 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 110 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 111 9. IAB Members at the Time of This Writing . . . . . . . . . . . 28 112 10. Informative References . . . . . . . . . . . . . . . . . . . . 28 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 115 1. Introduction 117 The original design goal of the Internet was to enable communications 118 between hosts. As this goal was met and people started using the 119 Internet to communicate, however, it became apparent that some hosts 120 were engaging in communications that were viewed as undesirable by 121 certain parties. The most famous early example of undesirable 122 communications was the Morris worm [Morris], which used the Internet 123 to infect many hosts in 1988. As the Internet has evolved into a 124 rich communications medium, so too have mechanisms to restrict 125 communications viewed as undesirable, ranging from acceptable use 126 policies enforced through informal channels to technical blocking 127 mechanisms. 129 Efforts to restrict or deny access to Internet resources and services 130 have evolved over time. As noted in [RFC4084], some Internet service 131 providers perform filtering to restrict which applications their 132 customers may use and which traffic they allow on their networks. 133 These restrictions are often imposed with customer consent, where 134 customers may be enterprises or individuals. Increasingly, however, 135 governments, service providers and enterprises are seeking to block 136 or filter access to certain content, traffic, or services without the 137 knowledge or agreement of affected users. Where these organizations 138 do not directly control networks themselves, they commonly aim to 139 make use of intermediary systems to implement the blocking or 140 filtering. 142 While blocking and filtering remain highly contentious in many cases, 143 the desire to restrict communications or access to content will 144 likely continue to exist. 146 The difference between "blocking" and "filtering" is a matter of 147 scale and perspective. "Blocking" often refers to preventing access 148 to resources in the aggregate, while "filtering" refers to preventing 149 access to specific resources within an aggregate. Both blocking and 150 filtering can be implemented at the level of "services" (web hosting 151 or video streaming, for example) or at the level of particular 152 "content." For the analysis presented in this document, the 153 distinction between blocking and filtering does not create 154 meaningfully different conclusions. Hence, in the remainder of this 155 document, we will treat the terms as being generally equivalent and 156 applicable to restrictions on both content and services. 158 This document aims to clarify the technical implications and trade- 159 offs of various blocking strategies and to identify the potential for 160 different strategies to potentially cause harmful side effects 161 ("collateral damage") for Internet users and the overall Internet 162 architecture. This analysis is limited to technical blocking 163 mechanisms. The scope of the analyzed blocking is limited to 164 intentional blocking, not accidental blocking due to misconfiguration 165 or as an unintentional side effect of something else. 167 Filtering may be considered legal, illegal, ethical, or unethical in 168 different places, at different times, and by different parties. This 169 document is intended for those who are conducting filtering or are 170 considering conducting filtering and who want to understand the 171 implications of their decisions with respect to the Internet 172 architecture and the trade-offs that come with each type of filtering 173 strategy. This document does not present formulas on how to make 174 those trade-offs; it is likely that filtering decisions require 175 knowledge of context-specific details. Whether particular forms of 176 filtering are lawful in particular jurisdictions raises complicated 177 legal questions that are outside the scope of this document. For 178 similar reasons, questions about the ethics of particular forms of 179 filtering are also out of scope. 181 2. Filtering Examples 183 Blocking systems have evolved alongside the Internet technologies 184 they seek to restrict. Looking back at the history of the Internet, 185 there have been several such systems deployed by different parties 186 and for different purposes. 188 Firewalls: Firewalls of various sorts are very commonly employed at 189 many points in today's Internet [RFC2979]. They can be deployed 190 either on end hosts (under user or administrator control), or in the 191 network, typically at network boundaries. While the Internet 192 Security Glossary [RFC4949] contains an extended definition of a 193 firewall, informally, most people would tend to think of a firewall 194 as simply "something that blocks unwanted traffic" (see [RFC4948] for 195 a discussion on many types of unwanted traffic). While there are 196 many sorts of firewalls, there are several specific types of firewall 197 functionality worth noting. 199 o Stateless Packet Filtering: Stateless packet filters block 200 according to content-neutral rules, e.g., blocking all inbound 201 connections or outbound connections on certain ports, protocols, 202 or network-layer addresses. For example, blocking outbound 203 connections to port 25. 205 o Stateful Packet Filtering: More advanced configurations require 206 keeping state used to enforce flow-based policies, e.g., blocking 207 inbound traffic for flows that have not been established. 209 o Deep Packet Inspection: Yet more advanced configurations perform 210 deep packet inspection and filter or block based on the content 211 carried. Many firewalls include web filtering capabilities (see 212 below). 214 Web Filtering: HTTP and HTTPS are common targets for blocking and 215 filtering, typically targeted at specific URIs. Some enterprises use 216 HTTP blocking to block non-work-appropriate web sites, and several 217 nations require HTTP and HTTPS filtering by their ISPs in order to 218 block content deemed illegal. HTTPS is a challenge for these 219 systems, because the URI in an HTTPS request is carried inside the 220 encrypted channel. To block access to content made accessible via 221 HTTPS, filtering systems thus must either block based on network- and 222 transport-layer headers (IP address and/or port), or else obtain a 223 trust anchor certificate that is trusted by endpoints (and thus act 224 as a man in the middle). These filtering systems often take the form 225 of "portals" or "enterprise proxies" presenting their own, 226 dynamically generated HTTPS certificates. (See further discussion in 227 Section 5.) 229 Spam Filtering: Spam filtering is one of the oldest forms of content 230 filtering. Spam filters evaluate messages based on a variety of 231 criteria and information sources to decide whether a given message is 232 spam. For example, DNS Black Lists use the reverse DNS to flag 233 whether an IP address is a known spam source [RFC5782]. Spam filters 234 can be installed on user devices (e.g., in a mail client), operated 235 by a mail domain on behalf of users, or outsourced to a third party 236 that acts as an intermediate MX proxy. 238 Domain Name Seizure: A number of approaches are used to block or 239 modify resolution of a domain name. One approach is to make use of 240 ICANN's Uniform Dispute Resolution Policy (URDP) for the purposes of 241 dealing with fraudulent use of a name. Other authorities may require 242 that domains be blocked within their jurisdictions. Substantial 243 research has been performed on the value and efficacy of such 244 seizures.[Takedown08][BlackLists14] 246 The precise method of how domain names are seized will vary from 247 place to place. One approach in use is for queries to be redirected 248 to resolve to IP addresses of the authority that hosts information 249 about the seizure. The effectiveness of domain seizures will 250 similarly vary based on the method. In some cases, the person whose 251 name was seized will simply use a new name. In other cases, the 252 block may only be effective within a region or when specific name 253 service infrastructure is used. 255 Seizures can also have overbroad effects, since access to content is 256 blocked not only within the jurisdiction of the seizure, but 257 globally, even when it may be affirmatively legal elsewhere 258 [RojaDirecta]. When domain redirection is effected via redirections 259 at intermediate resolvers rather than at authoritative servers, it 260 directly contradicts end-to-end assumptions in the DNS security 261 architecture [RFC4033], potentially causing validation failures by 262 validating end-nodes. 264 Safe Browsing: Modern web browsers provide some measures to prevent 265 users from accessing malicious web sites. For instance, before 266 loading a URI, current versions of Google Chrome and Firefox use the 267 Google Safe Browsing service to determine whether or not a given URI 268 is safe to load [SafeBrowsing]. The DNS can also be used to store 269 third party information that mark domains as safe or unsafe 270 [RFC5782]. 272 Manipulation of routing and addressing data: Governments have 273 recently intervened in the management of IP addressing and routing 274 information in order to maintain control over a specific set of DNS 275 servers. As part of an internationally coordinated response to the 276 DNSChanger malware, a Dutch court ordered the RIPE NCC to freeze the 277 accounts of several resource holders as a means to limit the resource 278 holders' ability to use certain address blocks [GhostClickRIPE](also 279 see Section 4.3). These actions have led to concerns that the number 280 resource certification system and related secure routing technologies 281 developed by the IETF's SIDR working group might be subject to 282 government manipulation as well [RFC6480], potentially for the 283 purpose of denying targeted networks access to the Internet. 285 Ingress filtering: Network service providers use Ingress Filtering 286 [RFC2827] [RFC3704] as a means to prevent source address spoofing 287 which is used as a part of other attacks. 289 Data loss prevention (DLP): Enterprise and other networks are 290 concerned with potential leaking of confidential information, whether 291 accidental or intentional. Some of the tools used for this are 292 similar to the main subject of this document of blocking and 293 filtering. In particular, enterprise proxies might be part of a DLP 294 solution. 296 3. Characteristics of Blocking Systems 298 At a generic level, blocking systems can be characterized by four 299 attributes: the party who sets the blocking policy, the purpose of 300 the blocking, the intended target of the blocking, and the Internet 301 component(s) used as the basis of the blocking system. 303 3.1. The party who sets blocking policies 305 Parties that institute blocking policies include governments, courts, 306 enterprises, network operators, reputation trackers, application 307 providers, and individual end users. A government might create laws 308 based on cultural norms and/or their elected mandate. Enterprises 309 might use cultural, industry, or legal norms to guide their policies. 311 There can be several steps of translation and transformation from the 312 original intended purpose first to laws, then to (government) 313 regulation, followed by high-level policies in, e.g., network 314 operators, and from those policies to filtering architecture and 315 implementation. Each of those steps is a potential source of 316 unintended consequences as discussed in this document. 318 In some cases, the policy setting entity is the same as the entity 319 that enforces the policy. For example, a network operator might 320 install a firewall in its own networking equipment, or a web 321 application provider might block responses between its web server and 322 certain clients. 324 In other cases, the policy setting entity is different from the 325 entity that enforces the policy. Such policy might be imposed upon 326 the enforcing entity, such as in the case of blocking initiated by 327 governments, or the enforcing entity might explicitly choose to use 328 policy set by others, such as in the case of a reputation system used 329 by a spam filter or safe browsing service. Because a policy might be 330 enforced by others, it is best if it can be expressed in a form that 331 is independent of the enforcing technology. 333 3.2. Purposes of blocking 335 There are a variety of motivations to filter: 337 o Preventing or responding to security threats. Network operators, 338 enterprises, application providers, and end users often block 339 communications that are believed to be associated with security 340 threats or network attacks. 342 o Restricting objectionable content or services. Certain 343 communications may be viewed as undesirable, harmful, or illegal 344 by particular governments, enterprises, or users. Governments may 345 seek to block communications that are deemed to be defamation, 346 hate speech, obscenity, intellectual property infringement, or 347 otherwise objectionable. Enterprises may seek to restrict 348 employees from accessing content that is not deemed to be work 349 appropriate. Parents may restrict their children from accessing 350 content or services targeted for adults. 352 o Restricting access based on business arrangements. Some networks 353 are designed so as to only provide access to certain content or 354 services ("walled gardens"), or to only provide limited access 355 until end users pay for full Internet services (captive portals 356 provided by hotspot operators, for example). 358 3.2.1. Blacklist vs. Whitelist Model 360 Note that the purpose for which blocking occurs often dictates 361 whether the blocking system operates on a blacklist model, where 362 communications are allowed by default but a subset are blocked, or a 363 whitelist model, where communications are blocked by default with 364 only a subset allowed. Captive portals, walled gardens, and 365 sandboxes used for security or network endpoint assessment usually 366 require a whitelist model since the scope of communications allowed 367 is narrow. Blocking for other purposes often uses a blacklist model 368 since only individual content or traffic is intended to be blocked. 370 3.3. Intended targets of blocking 372 Blocking systems are instituted so as to target particular content, 373 services, endpoints, or some combination of these. For example, a 374 "content" filtering system used by an enterprise might block access 375 to specific URIs whose content is deemed by the enterprise to be 376 inappropriate for the work place. This is distinct from a "service" 377 filtering system that blocks all web traffic (perhaps as part of a 378 parental control system on an end user device), and also distinct 379 from an "endpoint" filtering system in which a web application blocks 380 traffic from specific endpoints that are suspected of malicious 381 activity. 383 As discussed in Section 4, the design of a blocking system may affect 384 content, services, or endpoints other than those that are the 385 intended targets. For example, when domain name seizures described 386 above are intended to address specific web pages associated with 387 illegal activity, by removing the domains from use, they affect all 388 services made available by the hosts associated with those names, 389 including mail services and web services that may be unrelated to the 390 illegal activity. Depending on where the block is imposed within the 391 DNS hierarchy, entirely unrelated organizations may be impacted. 393 3.4. Components used for blocking 395 Broadly speaking, the process of delivering an Internet service 396 involves three different components: 398 1. Endpoints: The actual content of the service is typically an 399 application layer protocol between two or more Internet hosts. 400 In many protocols, there are two endpoints, a client and a 401 server. 403 2. Network services: The endpoints communicate by way of a 404 collection of IP networks that use routing protocols to determine 405 how to deliver packets between the endpoints. 407 3. Rendezvous services: Service endpoints are typically identified 408 by identifiers than are more "human-friendly" than IP addresses. 409 Rendezvous services allow one endpoint to figure out how to 410 contact another endpoint based on an identifier. An example of a 411 rendezvous service is the domain name system. Distributed hash 412 tables (DHTs) have also been used as rendezvous services. 414 Consider, for example, an HTTP transaction fetching the content of 415 the URI . The client endpoint is an 416 end host running a browser. The client uses the DNS as a rendezvous 417 service when it performs a AAAA query to obtain the IP address for 418 the server name "example.com". The client then establishes a 419 connection to the server, and sends the actual HTTP request. The 420 server endpoint then responds to the HTTP request. 422 As another example, in the SIP protocol, the two endpoints 423 communicating are IP phones, and the rendezvous service is provided 424 by an application-layer SIP proxy as well as the DNS. 426 Blocking access to Internet content, services, or endpoints is done 427 by controlling one or more of the components involved in the 428 provision of the communications involved in accessing the content, 429 services or endpoints. In the HTTP example above, the successful 430 completion of the HTTP request could have been prevented in several 431 ways: 433 o [Endpoint] Preventing the client from making the request 435 o [Endpoint] Preventing the server from responding to the request 437 o [Endpoint] Preventing the client from making the DNS request 438 needed to resolve example.com 440 o [Network] Preventing the request from reaching the server 442 o [Network] Preventing the response from reaching the client 444 o [Network] Preventing the client from reaching the DNS servers 445 o [Network] Preventing the DNS responses from reaching the client 447 o [Rendezvous] Preventing the DNS servers from providing the client 448 the correct IP address of the server 450 Those who desire to block communications will typically have access 451 to only one or two components, and therefore their choices for how to 452 perform blocking will be limited. End users and application 453 providers can usually only control their own software and hardware, 454 which means that they are limited to endpoint-based filtering. Some 455 network operators offer filtering services that their customers can 456 activate individually, in which case end users might have network- 457 based filtering systems available to them. Network operators can 458 control their own networks and the rendezvous services for which they 459 provide infrastructure support (e.g., DNS resolvers) or to which they 460 may have access (e.g., SIP proxies), but not usually endpoints. 461 Enterprises usually have access to their own networks and endpoints 462 for filtering purposes. Governments might make arrangements with the 463 operators or owners of any of the three components that exist within 464 their jurisdictions to perform filtering. 466 In the next section, blocking systems designed according to each of 467 the three patterns -- network services, rendezvous services, and 468 endpoints -- are evaluated for their technical and architectural 469 implications. The analysis is as agnostic as possible as to who sets 470 the blocking policy (government, end user, network operator, 471 application provider, or enterprise), but in some cases the way in 472 which a particular blocking design pattern is used might differ, 473 depending on the who desires a block. For example, a network-based 474 firewall provided by an ISP that parents can elect to use for 475 parental control purposes will likely function differently from one 476 that all ISPs in a particular jurisdiction are required to use by the 477 local government, even though in both cases the same component 478 (network) forms the basis of the blocking system. 480 4. Evaluation of Blocking Design Patterns 482 4.1. Criteria for evaluation 484 To evaluate the technical implications of each of the blocking design 485 patterns, we compare them based on four criteria: scope, granularity, 486 efficacy, and security. 488 4.1.1. Scope: What set of hosts and users are affected? 490 The Internet is comprised of many distinct autonomous networks and 491 applications, which means that the impact of a blocking system will 492 only be within a defined topological scope. For example, blocking 493 within an access network will only affect a well-defined set of users 494 (namely, those connected to the access network). Blocking performed 495 by an application provider can affect users across the entire 496 Internet. 498 Blocking systems are generally viewed as less objectionable if the 499 scope of their impact is as narrow as possible while still being 500 effective, and as long as the impact of the blocking is within the 501 administrative realm of the policy setting entity. As mentioned 502 previously, enterprise blocking systems are commonly deployed, and 503 will generally have impact on enterprise users. However, design 504 flaws in blocking systems may cause the effects of blocking to be 505 overbroad. For example, at least one service provider blocking 506 content in accordance with a regulation has ended up blocking content 507 for downstream service providers because it filtered routes to 508 particular systems and did not distribute the original information to 509 downstream service providers in other jurisdictions.[IN-OM-filtering] 510 Other service providers have accidentally leaked such black hole 511 routes beyond the jurisdiction.[NW08] A substantial amount of work 512 has gone into BGP security to avoid such attacks, but deployment of 513 such systems lags. 515 4.1.2. Granularity: How specific is the blocking? Will blocking one 516 service also block others? 518 Internet applications are built out of a collection of loosely- 519 coupled components or "layers." Different layers serve different 520 purposes, and rely on or offer different functions such as routing, 521 transport, and naming (see [RFC1122], especially Section 1.1.3). The 522 functions at these layers are developed autonomously and almost 523 always operated by different parties. For example, in many networks, 524 physical and link-layer connectivity is provided by an "access 525 provider", IP routing is performed by an "Internet service provider," 526 and application-layer services are provided by completely separate 527 entities (e.g., web servers). Upper-layer protocols and applications 528 rely on combinations of lower-layer functions in order to work. 529 Functionality at higher layers tends to be more specialized, so that 530 many different specialized applications can make use of the same 531 generic underlying network functions. 533 As a result of this structure, actions taken at one layer can affect 534 functionality or applications at other layers. For example, 535 manipulating routing or naming functions to restrict access to a 536 narrow set of resources via specific applications will likely affect 537 all applications that depend on those functions. As with the scope 538 criteria, blocking systems are generally viewed as less objectionable 539 when they are highly granular and do not cause collateral damage to 540 content or services unrelated to the target of the blocking 541 [RFC4924]. 543 Even within the application layer, the granularity of blocking can 544 vary depending on how targeted the blocking system is designed to be. 545 Blocking all traffic associated with a particular application 546 protocol is less granular than blocking only traffic associated with 547 a subset of application instances that make use of that protocol. 548 Sophisticated heuristics that make use of information about the 549 application protocol, lower-layer protocols, payload signatures, 550 source and destination addresses, inter-packet timing, packet sizes, 551 and other characteristics are sometimes used to narrow the subset of 552 traffic to be blocked. 554 4.1.3. Efficacy: How easy is it for a resource or service to avoid 555 being blocked? 557 Although blocking a resource or service might have some immediate 558 effect, efficacy must be evaluated in terms of whether it is easy to 559 circumvent. Simply doing a one-time policy is often unlikely to have 560 lasting efficacy (e.g., see [CleanFeed] and [BlackLists14]). 561 Experience has shown that in general blacklisting requires continual 562 maintenance of the blacklist itself, both to add new entries for 563 unwanted traffic, and deleting entries when offending content is 564 removed. Experience also shows that depending on the nature of the 565 block it may be difficult to determine when to unblock. For 566 instance, if a host is blocked because it has been compromised and 567 used as a source of attack, it may not be plainly evident when that 568 site has been fixed. 570 For blacklist-style blocking, the distributed and mobile nature of 571 Internet resources limits the effectiveness of blocking actions. A 572 service that is blocked in one jurisdiction can often be moved or re- 573 instantiated in another jurisdiction (see, for example, 574 [Malicious-Resolution]). Likewise, services that rely on blocked 575 resources can often be rapidly re-configured to use non-blocked 576 resources. If a web site is prevented from using a domain name or 577 set of IP addresses, the content can simply be moved to another 578 domain name or network, or use alternate syntaxes to express the same 579 resource name (see the discussion of false negatives in [RFC6943]). 581 In a process known as "snowshoe spamming," a spam originator uses 582 addresses in many different networks as sources for spam. This 583 technique is already widely used to spread spam generation across a 584 variety of resources and jurisdictions to prevent spam blocking from 585 being effective. 587 In the presence of either blacklist or whitelist systems, there are 588 several ways in which a user or application can try to circumvent the 589 filters. 591 The users may choose to use different sets of protocols or otherwise 592 alter their traffic characteristics to circumvent the filters. In 593 some cases, applications may shift their traffic to port 80 or 443 594 when other ports are blocked. Or services may be tunneled within 595 other services, proxied by a collaborating external host (e.g., an 596 anonymous redirector), or simply run over an alternate port (e.g., 597 port 8080 vs port 80 for HTTP). Another means of circumvention is 598 alteration of the service behavior to use a dynamic port negotiation 599 phase, in order to avoid use of a constant port address. 601 One of the primary motivations for arguing that HTTP/2 should be 602 encrypted by default was that unencrypted HTTP 1.1 traffic was 603 sometimes blocked or improperly processed. Users or applications 604 shifting their traffic to encrypted HTTP has the effect of 605 circumventing filters that depend on the HTTP plaintext payload. 607 If voice communication based on SIP [RFC3261] is blocked, users are 608 likely to use applications which use proprietary protocols that allow 609 them to talk to each other. 611 Some filtering systems are only capable of identifying IPv4 traffic 612 and therefore by shifting to IPv6 users may be able to evade 613 filtering. Using IPv6 with header options, using multiple layers of 614 tunnels, or using encrypted tunnels can also make it more challenging 615 for blocking systems to find transport ports within packets, making 616 port-based blocking more difficult. Thus distribution and mobility 617 can hamper efforts to block communications in a number of ways. 619 4.1.4. Security: How does the blocking impact existing trust 620 infrastructures? 622 Modern security mechanisms rely on trusted hosts communicating via a 623 secure channel without intermediary interference. Protocols such as 624 TLS and IPsec [RFC5246][RFC4301] are designed to ensure that each 625 endpoint of the communication knows the identity of the other 626 endpoint(s), and that only the endpoints of the communication can 627 access the secured contents of the communication. For example, when 628 a user connects to a bank's web site, TLS ensures that the user's 629 banking information is securely communicated to the bank and nobody 630 else, ensuring the data remains confidential while in transit. 632 Some blocking strategies require intermediaries to insert themselves 633 within the end-to-end communications path, potentially breaking 634 security properties of Internet protocols [RFC4924]. In these cases 635 it can be difficult or impossible for endpoints to distinguish 636 between attackers and "authorized" parties conducting blocking. For 637 example, an enterprise firewall administrator could gain access to 638 users' personal bank accounts when users on the enterprise network 639 connect to bank web sites. 641 Finally, one needs to evaluate whether a blocking mechanism can be 642 used by an end-user to efficiently locate blocked resources that can 643 then be accessed via other mechanisms that circumvent the blocking 644 mechanism. For example, Clayton [CleanFeed] showed how special 645 treatment in one blocking system could be detected by end users in 646 order to efficiently locate illegal web sites, which was thus 647 counter-productive to the policy objective of the blocking mechanism. 649 4.2. Network-Based Blocking 651 Being able to block access to resources without the consent or 652 cooperation of either endpoint is viewed as a desirable feature by 653 some that deploy blocking systems. Systems that have this property 654 are often implemented using intermediary devices in the network, such 655 as firewalls or filtering systems. These systems inspect traffic as 656 it passes through the network, decide based on the characteristics or 657 content of a given communication whether it should be blocked, and 658 then block or allow the communication as desired. For example, web 659 filtering devices usually inspect HTTP requests to determine the URI 660 being requested, compare that URI to a list of blacklisted or 661 whitelisted URIs, and allow the request to proceed only if it is 662 permitted by policy. Firewalls perform a similar function for other 663 classes of traffic in addition to HTTP. Some blocking systems focus 664 on specific application-layer traffic, while others, such as router 665 ACLs, filter traffic based on lower layer criteria (transport 666 protocol and source or destination addresses or ports). 668 Intermediary systems used for blocking are often not far from the 669 edge of the network. For example, many enterprise networks operate 670 firewalls that block certain web sites, as do some residential ISPs. 671 In some cases, this filtering is done with the consent or cooperation 672 of the affected endpoints. PCs within an enterprise, for example, 673 might be configured to trust an enterprise proxy, a residential ISP 674 might offer a "safe browsing" service, or mail clients might 675 authorize mail servers on the local network to filter spam on their 676 behalf. These cases share some of the properties of the "Endpoint- 677 Based Blocking" scenarios discussed in Section 4.4 below, since the 678 endpoint has made an informed decision to authorize the intermediary 679 to block on its behalf and is therefore unlikely to attempt to 680 circumvent the blocking. From an architectural perspective, however, 681 they may create many of the same problems as network-based filtering 682 conducted without consent. 684 4.2.1. Scope 686 In the case of government-initiated blocking, network operators 687 subject to a specific jurisdiction may be required to block or 688 filter. It is thus possible for laws to be structured to result in 689 blocking by imposing obligations on the operators of networks within 690 a jurisdiction, either via direct government action or by allowing 691 private actors to demand blocking (e.g., through lawsuits). 693 Regardless of who is responsible for a blocking policy, enforcement 694 can be done using Stateless Packet Filtering, Stateful Packet 695 Filtering, or Deep Packet Inspection as defined in Section 2. While 696 network-based Stateless Packet Filtering has granularity issues 697 discussed in Section 4.2.2, network-based Stateful Packet Filtering 698 and Deep Packet Inspection approaches often run into several 699 technical issues that limit their viability in practice. For 700 example, many issues arise from the fact that an intermediary needs 701 to have access to a sufficient amount of traffic to make its blocking 702 determinations. 704 For residential or consumer networks with many egress points, the 705 first step to obtaining this traffic is simply gaining access to the 706 constituent packets. The Internet is designed to deliver packets 707 independently from source to destination -- not to any particular 708 point along the way. Thus the sequence of packets from the sender 709 can only be reliably reconstructed at the intended receiver. In 710 addition, inter-network routing is often asymmetric, and for 711 sufficiently complex local networks, intra-network traffic flows can 712 be asymmetric as well [asymmetry]. Thus packets in the reverse 713 direction use a different sent of paths than the forward direction. 715 This asymmetry means that an intermediary in a network with many 716 egress points may, depending on topology and configuration, see only 717 one half of a given communication, which may limit the scope of the 718 communications that it can filter. For example, a filter aimed at 719 requests destined for particular URIs cannot make accurate blocking 720 decisions based on the URI if it is only in the data path for HTTP 721 responses and not requests, since the URI is not included in the 722 responses. Asymmetry may be surmountable given a filtering system 723 with enough distributed, interconnected filtering nodes that can 724 coordinate information about flows belonging to the same 725 communication or transaction, but depending on the size of the 726 network this may imply significant complexity in the filtering 727 system. Routing can sometimes be forced to be symmetric within a 728 given network using routing configuration, NAT, or layer-2 mechanisms 729 (e.g., MPLS), but these mechanisms are frequently brittle, complex, 730 and costly -- and can sometimes result in reduced network performance 731 relative to asymmetric routing. Enterprise networks may also be less 732 susceptible to these problems if they route all traffic through a 733 small number of egress points. 735 4.2.2. Granularity 737 Once an intermediary in a network has access to traffic, it must 738 identify which packets must be filtered. This decision is usually 739 based on some combination of information at the network layer (e.g., 740 IP addresses), transport layer (ports), or application layer (URIs or 741 other content). Deep Packet Inspection type blocking based on 742 application-layer attributes can be potentially more granular and 743 less likely to cause collateral damage than blocking all traffic 744 associated with a particular address, which can impact unrelated 745 occupants of the same address. However, more narrowly focused 746 targeting may be more complex, less efficient, or easier to 747 circumvent than filtering that sweeps more broadly, and those who 748 seek to block must balance these attributes against each other when 749 choosing a blocking system. 751 4.2.3. Efficacy and security 753 Regardless of the layer at which blocking occurs, it may be open to 754 circumvention, particularly in cases where network endpoints have not 755 authorized the blocking. The communicating endpoints can deny the 756 intermediary access to attributes at any layer by using encryption 757 (see below). IP addresses must be visible, even if packets are 758 protected with IPsec, but blocking based on IP addresses can be 759 trivial to circumvent. A filtered site may be able to quickly change 760 its IP address using only a few simple steps: changing a single DNS 761 record and provisioning the new address on its server or moving its 762 services to the new address [BT-TPB]. 764 Indeed, Poort, et al. [Poort] found that "any behavioural change in 765 response to blocking access to The Pirate Bay has had no lasting net 766 impact on the overall number of downloaders from illegal sources, as 767 new consumers have started downloading from illegal sources and 768 people learn to circumvent the blocking while new illegal sources may 769 be launched, causing file sharing to increase again", and that these 770 results "are in line with a tendency found in the literature that any 771 effects of legal action against file sharing often fade out after a 772 period of typically six months." 774 If application content is encrypted with a security protocol such as 775 IPsec or TLS, then the intermediary will require the ability to 776 decrypt the packets to examine application content, or resort to 777 statistical methods to guess what the content is. Since security 778 protocols are generally designed to provide end-to-end security 779 (i.e., to prevent intermediaries from examining content), the 780 intermediary would need to masquerade as one of the endpoints, 781 breaking the authentication in the security protocol, reducing the 782 security of the users and services affected, and interfering with 783 legitimate private communication. Besides, various techniques that 784 use public databases with whitelisted keys (e.g., DANE [RFC6698]) 785 enable users to detect these sort of intermediaries. Those users are 786 then likely to act as if the service is blocked. 788 If the intermediary is unable to decrypt the security protocol, then 789 its blocking determinations for secure sessions can only be based on 790 unprotected attributes, such as IP addresses, protocol IDs, port 791 numbers, packet sizes, and packet timing. Some blocking systems 792 today still attempt to block based on these attributes, for example 793 by blocking TLS traffic to known proxies that could be used to tunnel 794 through the blocking system. 796 However, as the Telex project [Telex] recently demonstrated, if an 797 endpoint cooperates with a relay in the network (e.g., a Telex 798 station), it can create a TLS tunnel that is indistinguishable from 799 legitimate traffic. For example, if an ISP used by a banking web 800 site were to operate a Telex station at one of its routers, then a 801 blocking system would be unable to distinguish legitimate encrypted 802 banking traffic from Telex-tunneled traffic (potentially carrying 803 content that would have been filtered). 805 Thus, in principle in a blacklist system it is impossible to block 806 tunneled traffic through an intermediary device without blocking all 807 secure traffic from that system. (The only limitation in practice is 808 the requirement for special software on the client.) Those who 809 require that secure traffic be blocked from such sites risk blocking 810 content that would be valuable to their users, perhaps impeding 811 substantial economic activity. Conversely, those who are hosting a 812 myriad of content have an incentive to see that law abiding content 813 does not end up being blocked. 815 Governments and network operators should, however, take care not to 816 encourage the use of insecure communications in the naming of 817 security, as doing so will invariably expose their users to the 818 various attacks that the security protocols were put in place to 819 prevent. 821 Some operators may assume that only blocking access to resources 822 available via unsecure channels is sufficient for their purposes -- 823 i.e., that the size of the user base that will be willing to use 824 secure tunnels and/or special software to circumvent the blocking is 825 low enough to make blocking via intermediaries worthwhile. Under 826 that assumption, one might decide that there is no need to control 827 secure traffic, and thus that network-based blocking is an attractive 828 option. 830 However, the longer such blocking systems are in place, the more 831 likely it is that efficient and easy-to-use tunneling tools will 832 become available. The proliferation of the Tor network, for example, 833 and its increasingly sophisticated blocking-avoidance techniques 834 demonstrate that there is energy behind this trend [Tor]. Thus, 835 network-based blocking becomes less effective over time. 837 Network-based blocking is a key contributor to the arms race that has 838 led to the development of such tools, the result of which is to 839 create unnecessary layers of complexity in the Internet. Before 840 content-based blocking became common, the next best option for 841 network operators was port blocking, the widespread use of which has 842 driven more applications and services to use ports (80 and 443 most 843 commonly) that are unlikely to be blocked. In turn, network 844 operators shifted to finer-grained content blocking over port 80, 845 content providers shifted to encrypted channels, and operators began 846 seeking to identify those channels (although doing so can be 847 resource-prohibitive, especially if tunnel endpoints begin to change 848 frequently). Because the premise of network-based blocking is that 849 endpoints have incentives to circumvent it, this cat-and-mouse game 850 is an inevitable by-product of this form of blocking. 852 One reason above all stands as an enormous challenge to network-based 853 blocking: the Internet was designed with the premise that people will 854 want to connect and communicate. IP will run on anything up to and 855 including carrier pigeons.[RFC1149] It often runs atop TLS and has 856 been made to run on other protocols that themselves run atop IP. 857 Because of this fundamental layering approach nearly any authorized 858 avenue of communication can be used as a transport. This same 859 "problem" permits communications to succeed in the most challenging 860 of environments. 862 4.2.4. Summary 864 In sum, network-based blocking is only effective in a fairly 865 constrained set of circumstances. First, the traffic needs to flow 866 through the network in such a way that the intermediary device has 867 access to any communications it intends to block. Second, the 868 blocking system needs an out-of-band mechanism to mitigate the risk 869 of secure protocols being used to avoid blocking (e.g., human 870 analysts identifying IP addresses of tunnel endpoints). If the 871 network is sufficiently complex, or the risk of tunneling too high, 872 then network-based blocking is unlikely to be effective, and in any 873 case this type of blocking drives the development of increasingly 874 complex layers of circumvention. Network-based blocking can be done 875 without the cooperation of either endpoint to a communication, but it 876 has the serious drawback of breaking end-to-end security assurances 877 in some cases. The fact that network-based blocking is premised on 878 this lack of cooperation results in arms races that increase the 879 complexity of both application design and network design. 881 4.3. Rendezvous-Based Blocking 883 Internet applications often require or rely on support from common, 884 global rendezvous services, including the DNS, certificate 885 authorities, search engines, WHOIS databases, and Internet Route 886 Registries. These services control or register the structure and 887 availability of Internet applications by providing data elements that 888 are used by application code. Some applications also have their own 889 specialized rendezvous services. For example, to establish an end- 890 to-end SIP call, the end-nodes (terminals) rely on presence and 891 session information supplied by SIP servers. 893 Global rendezvous services are comprised of generic technical 894 databases intended to record certain facts about the network. The 895 DNS, for example, stores information about which servers provide 896 services for a given name, and the Resource Public Key Infrastructure 897 (RPKI) stores information about which organizations have been 898 allocated IP addresses. To offer specialized Internet services and 899 applications, different people rely on these generic records in 900 different ways. Thus the effects of changes to the databases can be 901 much more difficult to predict than, for example, the effect of 902 shutting down a web server (which fulfills the specific purpose of 903 serving web content). 905 Although rendezvous services are discussed as a single category, the 906 precise characteristics and implications of blocking each kind of 907 rendezvous service are slightly different. This section provides 908 examples to highlight these differences. 910 4.3.1. Scope 912 In the case of government-initiated blocking, the operators of 913 servers used to provide rendezvous service that are subject to a 914 specific jurisdiction may be required to block or filter. It is thus 915 possible for laws to be structured to result in blocking by imposing 916 obligations on the operators of rendezvous services within a 917 jurisdiction, either via direct government action or by allowing 918 private actors to demand blocking (e.g., through lawsuits). 920 The scope of blocking conducted by others will depend on which 921 servers they can access. For example, network operators and 922 enterprises may be capable of conducting blocking using their own DNS 923 resolvers or application proxies within their networks, but not 924 authoritative servers controlled by others. 926 However, if a service is hosted and operated within a jurisdiction 927 where it is considered legitimate, then blocking access at a global 928 rendezvous service (e.g., one within a jurisdiction where it is 929 considered illegitimate) might deny services in jurisdictions where 930 they are considered legitimate. This type of collateral damage is 931 lessened when blocking is done at a local rendezvous server that only 932 has local impact, rather than at a global rendezvous server with 933 global impact. 935 4.3.2. Granularity 937 Blocking at a global rendezvous service can be overbroad if the 938 resources blocked support multiple services, since blocking service 939 can cause collateral damage to legitimate uses of other services. 940 For example, a given address or domain name might host both 941 legitimate services as well as services that some would desire to 942 block. 944 4.3.3. Efficacy 946 The distributed nature of the Internet limits the efficacy of 947 blocking based on rendezvous services. If the Internet community 948 realizes that a blocking decision has been made and wishes to counter 949 it, then local networks can "patch" the authoritative data that a 950 global rendezvous service provides to avoid the blocking (although 951 the development of DNSSEC and the RPKI are causing this to change by 952 requiring updates to be authorized). In the DNS case, registrants 953 whose names get blocked can relocate their resources to different 954 names. 956 Endpoints can also choose not to use a particular rendezvous service. 957 They might switch to a competitor or use an alternate mechanism (for 958 example, IP literals in URIs to circumvent DNS filtering). 960 4.3.4. Security and other implications 962 Blocking of global rendezvous services also has a variety of other 963 implications that may reduce the stability, accessibility, and 964 usability of the global Internet. Infrastructure-based blocking may 965 erode the trust in the general Internet and encourage the development 966 of parallel or "underground" infrastructures causing forms of 967 Internet balkanisation, for example. This risk may become more acute 968 as the introduction of security infrastructures and mechanisms such 969 as DNSSEC and RPKI "hardens" the authoritative data -- including 970 blocked names or routes -- that the existing infrastructure services 971 provide. Those seeking to circumvent the blocks may opt to use less- 972 secure but unblocked parallel services. As applied to the DNS, these 973 considerations are further discussed in RFC 2826 [RFC2826] in the 974 advisory [SAC-056] from ICANN's Security and Stability Advisory 975 Committee (SSAC), and in ISOC's whitepaper on DNS filtering 976 [ISOCFiltering], but they also apply to other global Internet 977 resources. 979 4.3.5. Examples 981 Below we provide a few specific examples for routing, DNS, and WHOIS 982 services. These examples demonstrate that for these types of 983 rendezvous services (services that are often considered a global 984 commons), jusrisdiction-specific legal and ethical motivations for 985 blocking can both have collateral effects in other jurisdictions and 986 be circumvented because of the distributed nature of the Internet. 988 In 2008, Pakistan Telecom attempted to deny access to YouTube within 989 Pakistan by announcing bogus routes for YouTube address space to 990 peers in Pakistan. YouTube was temporarily denied service on a 991 global basis as a result of a route leak beyond the Pakistan ISP's 992 scope, but service was restored in approximately two hours because 993 network operators around the world re-configured their routers to 994 ignore the bogus routes [RenesysPK]. In the context of SIDR and 995 secure routing, a similar re-configuration could theoretically be 996 done if a resource certificate were to be revoked in order to block 997 routing to a given network. 999 In the DNS realm, one of the recent cases of U.S. law enforcement 1000 seizing domain names involved RojaDirecta, a Spanish web site. Even 1001 though several of the affected domain names belonged to Spanish 1002 organizations, they were subject to blocking by the U.S. government 1003 because certain servers were operated in the United States. 1004 Government officials required the operators of the parent zones of a 1005 target name (e.g., "com" for "example.com") to direct queries for 1006 that name to a set of U.S.-government-operated name servers. Users 1007 of other services (e.g., email) under a target name would thus be 1008 unable to locate the servers providing services for that name, 1009 denying them the ability to access these services. 1011 Similar workarounds as those that were used in the Pakistan Telecom 1012 case are also available in the DNS case. If a domain name is blocked 1013 by changing authoritative records, network operators can restore 1014 service simply by extending TTLs on cached pre-blocking records in 1015 recursive resolvers, or by statically configuring resolvers to return 1016 un-blocked results for the affected name. However, depending on 1017 availability of valid signature data, these types of workarounds will 1018 not work with DNSSEC-signed data. 1020 The action of the Dutch authorities against the RIPE NCC, where RIPE 1021 was ordered to freeze the accounts of Internet resource holders, is 1022 of a similar character. By controlling the account holders' WHOIS 1023 information, this type of action limited the ability of the ISPs in 1024 question to manage their Internet resources. This example is 1025 slightly different from the others because it does not immediately 1026 impact the ability of ISPs to provide connectivity. While ISPs use 1027 (and trust) the WHOIS databases to build route filters or use the 1028 databases for trouble-shooting information, the use of the WHOIS 1029 databases for those purposes is voluntary. Thus, seizure of this 1030 sort may not have any immediate effect on network connectivity, but 1031 it may impact overall trust in the common infrastructure. It is 1032 similar to the other examples in that action in one jurisdiction can 1033 have broader effects, and in that the global system may encourage 1034 networks to develop their own autonomous solutions. 1036 4.3.6. Summary 1038 In summary, rendezvous-based blocking can sometimes be used to 1039 immediately block a target service by removing some of the resources 1040 it depends on. However, such blocking actions can have harmful side 1041 effects due to the global nature of Internet resources and the fact 1042 that many different application-layer services rely on generic, 1043 global databases for rendezvous purposes. The fact that Internet 1044 resources can quickly shift between network locations, names, and 1045 addresses, together with the autonomy of the networks that comprise 1046 the Internet, can mean that the effects of rendezvous-based blocking 1047 can be negated on short order in some cases. For some applications, 1048 rendezvous services are optional to use, not mandatory. Hence they 1049 are only effective when the endpoint or the endpoint's network 1050 chooses to use them; they can be routed around by choosing not to use 1051 the rendezvous service or migrating to an alternative one. To adapt 1052 a quote by John Gilmore, "The Internet treats blocking as damage and 1053 routes around it". 1055 4.4. Endpoint-Based Blocking 1057 Internet users and their devices constantly make decisions as to 1058 whether to engage in particular Internet communications. Users 1059 decide whether to click on links in suspect email messages; browsers 1060 advise users on sites that have suspicious characteristics; spam 1061 filters evaluate the validity of senders and messages. If the 1062 hardware and software making these decisions can be instructed not to 1063 engage in certain communications, then the communications are 1064 effectively blocked because they never happen. 1066 There are several systems in place today that advise user systems 1067 about which communications they should engage in. As discussed 1068 above, several modern browsers consult with "Safe Browsing" services 1069 before loading a web site in order to determine whether the site 1070 could potentially be harmful. Spam filtering is one of the oldest 1071 types of filtering in the Internet; modern filtering systems 1072 typically make use of one or more "reputation" or "blacklist" 1073 databases in order to make decisions about whether a given message or 1074 sender should be blocked. These systems typically have the property 1075 that many filtering systems (browsers, MTAs) share a single 1076 reputation service. Even the absence of provisioned PTR records for 1077 an IP address may result in email messages not being accepted. 1079 4.4.1. Scope 1081 In an endpoint-based blocking system, blocking actions are performed 1082 autonomously, by individual endpoints or their delegates. The 1083 effects of blocking are thus usually local in scope, minimizing the 1084 effects on other users or other, legitimate services. 1086 4.4.2. Granularity 1088 Endpoint-based blocking avoids some of the limitations of rendezvous- 1089 based blocking: while rendezvous-based blocking can only see and 1090 affect the rendezvous service at hand (e.g., DNS name resolution), 1091 endpoint-based blocking can potentially see into the entire 1092 application, across all layers and transactions. This visibility can 1093 provide endpoint-based blocking systems with a much richer set of 1094 information for making narrow blocking decisions. Support for narrow 1095 granularity depends on how the application protocol client and server 1096 are designed, however. A typical endpoint-based firewall application 1097 may have less ability to make fine-grained decisions than an 1098 application that does its own blocking (see [RFC7288] for further 1099 discussion). 1101 4.4.3. Efficacy 1103 Endpoint-based blocking deals well with mobile adversaries. If a 1104 blocked service relocates resources or uses different resources, a 1105 rendezvous- or network-based blocking approach may not be able to 1106 affect the new resources (at least not immediately). A network-based 1107 blocking system may not even be able to tell whether the new 1108 resources are being used, if the previously blocked service uses 1109 secure protocols. By contrast, endpoint-based blocking systems can 1110 detect when a blocked service's resources have changed (because of 1111 their full visibility into transactions) and adjust blocking as 1112 quickly as new blocking data can be sent out through a reputation 1113 system. 1115 The primary challenge to endpoint-based blocking is that it requires 1116 the cooperation of endpoints. Where this cooperation is willing, 1117 this is a fairly low barrier, requiring only reconfiguration or 1118 software update. Where cooperation is unwilling, it can be 1119 challenging to enforce cooperation for large numbers of endpoints. 1120 That challenge is exacerbated when the endpoints are a diverse set of 1121 static, mobile or visiting endpoints. If cooperation can be 1122 achieved, endpoint-based blocking can be much more effective than 1123 other approaches because it is so coherent with the Internet's 1124 architectural principles. 1126 4.4.4. Security 1128 Endpoint-based blocking is performed at one end of an Internet 1129 communication, and thus avoids the problems related to end-to-end 1130 security mechanisms that network-based blocking runs into and the 1131 challenges to global trust infrastructures that rendezvous-based 1132 blocking creates. 1134 4.4.5. Server Endpoints 1136 In this discussion of endpoint-based blocking, the focus has been on 1137 the consuming side of the end-to-end communication, mostly the client 1138 side of a client-server type connection. However, similar 1139 considerations apply to the content-producing side of end-to-end 1140 communications, regardless of whether that endpoint is a server in a 1141 client-server connection or a peer in a peer-to-peer type of 1142 connection. 1144 For instance, for blocking of web content, narrow targeting can be 1145 achieved through whitelisting methods like password authentication 1146 whereby passwords are available only to authorized clients. For 1147 example, a web site might only make adult content available to users 1148 who provide credit card information, which is assumed to be a proxy 1149 for age. 1151 The fact that content-producing endpoints often do not take it upon 1152 themselves to block particular forms of content in response to 1153 requests from governments or other parties can sometimes motivate 1154 those latter parties to engage in blocking elsewhere within the 1155 Internet. 1157 If a service is to be blocked, the best way of doing that is to 1158 disable the service at the server endpoint. 1160 4.4.6. Summary 1162 Out of the three design patterns, endpoint-based blocking is the 1163 least likely to cause collateral damage to Internet services or the 1164 overall Internet architecture. Endpoint-based blocking systems can 1165 potentially see into all layers involved in a communication, allowing 1166 blocking to be narrowly targeted and can minimize unintended 1167 consequences. Adversary mobility can be accounted for as soon as 1168 reputation systems are updated with new adversary information. One 1169 potential drawback of endpoint-based blocking is that it requires the 1170 endpoint's cooperation; implementing blocking at an endpoint when it 1171 is not in the endpoint's interest is therefore difficult to 1172 accomplish because the endpoint's user can disable the blocking or 1173 switch to a different endpoint. 1175 5. Security Considerations 1177 The primary security concern related to Internet service blocking is 1178 the effect that it has on the end-to-end security model of many 1179 Internet security protocols. When blocking is enforced by an 1180 intermediary with respect to a given communication, the blocking 1181 system may need to obtain access to confidentiality-protected data to 1182 make blocking decisions. Mechanisms for obtaining such access often 1183 require the blocking system to defeat the authentication mechanisms 1184 built into security protocols. 1186 For example, some enterprise firewalls will dynamically create TLS 1187 certificates under a trust anchor recognized by endpoints subject to 1188 blocking. These certificates allow the firewall to authenticate as 1189 any web site, so that it can act as a man-in-the-middle on TLS 1190 connections passing through the firewall. This is not unlike an 1191 external attacker using compromised certificates to intercept TLS 1192 connections. 1194 Modifications such as these obviously make the firewall itself an 1195 attack surface. If an attacker can gain control of the firewall or 1196 compromise the key pair used by the firewall to sign certificates, 1197 the attacker will have access to the unencrypted data of all current 1198 and recorded TLS sessions for all users behind that firewall, in a 1199 way that is undetectable to users. Besides, if the compromised key- 1200 pairs can be extracted from the firewall, all users, not only those 1201 behind the firewall, that rely on that public key are vulnerable. 1203 We must also consider the possibility that a legitimate administrator 1204 of such a firewall could gain access to privacy-sensitive 1205 information, such as the bank accounts or health records of users who 1206 access such secure sites through the firewall. These privacy 1207 considerations motivate legitimate use of secur end-to-end protocols 1208 that often make it difficult to enforce granular blocking policies. 1210 When blocking systems are unable to inspect and surgically block 1211 secure protocols, it is tempting to completely block those protocols. 1212 For example, a web blocking system that is unable to inspect HTTPS 1213 connections might simply block any attempted HTTPS connection. 1214 However, since Internet security protocols are commonly used for 1215 critical services such as online commerce and banking, blocking these 1216 protocols would block access to these services as well, or worse, 1217 force them to be conducted over insecure communication. 1219 Security protocols can, of course, also be used as mechanisms for 1220 blocking services. For example, if a blocking system can insert 1221 invalid credentials for one party in an authentication protocol, then 1222 the other end will typically terminate the connection based on the 1223 authentication failure. However, it is typically much simpler to 1224 simply block secure protocols than to exploit those protocols for 1225 service blocking. 1227 6. Conclusion 1229 Filtering will continue to occur on the Internet. We conclude that, 1230 whenever possible, filtering should be done on the endpoint. 1231 Cooperative endpoints are most likely to have sufficient contextual 1232 knowledge to effectively target blocking, hence such blocking 1233 minimizes unintended consequences. It is realistic to expect that at 1234 times filtering will not be done on the endpoints. In these cases, 1235 promptly informing the endpoint that blocking has occurred provides 1236 necessary transparency to redress any errors, particularly as they 1237 relate to any collatoral damage introduced by errant filters. 1239 Blacklist approaches are often a game of "Cat and Mouse", where those 1240 with the content move it around to avoid blocking. Or the content 1241 may even be naturally mirrored or cached at other legitimate sites 1242 such as the Internet Archive Wayback Machine [Wayback]. At the same 1243 time, whitelists provide similar risks because sites that had 1244 "acceptable" content may become targets for "unacceptable content", 1245 and similarly, access to perfectly inoffensive and perhaps useful or 1246 productive content is unnecessarily blocked. 1248 From a technical perspective, there are no perfect or even good 1249 solutions. There is only least bad. On that front, we posit that a 1250 hybrid approach that combines endpoint-based filtering with network 1251 filtering may prove least damaging. An endpoint may choose to 1252 participate in a filtering regime in exchange for the network 1253 providing broader unfiltered access. 1255 Finally, we note that where filtering is occurring to address content 1256 that is generally agreed to be inappropriate or illegal, strong 1257 cooperation among service providers and governments may provide 1258 additional means to identify both the victims and the perpetrators 1259 through non-filtering mechanisms, such as partnerships with the 1260 finance industry to identify and limit illegal transactions. 1262 7. IANA Considerations 1264 This document requires no actions by the IANA. 1266 8. Acknowledgments 1268 Thanks to the many reviewers who provided helpful comments, 1269 especially Bill Herrin, Eliot Lear, Patrik Faltstrom, Pekka Savola, 1270 and Russ White. NLnet Labs is also acknowledged as Kolkman's 1271 employer during most of this document's development. 1273 9. IAB Members at the Time of This Writing 1275 Jari Arkko 1276 Mary Barnes 1277 Marc Blanchet 1278 Ralph Droms 1279 Ted Hardie 1280 Joe Hildebrand 1281 Russ Housley 1282 Erik Nordmark 1283 Robert Sparks 1284 Andrew Sullivan 1285 Dave Thaler 1286 Brian Trammell 1287 Suzanne Woolf 1289 10. Informative References 1291 [BT-TPB] Meyer, D., "BT blocks The Pirate Bay", June 2012, . 1294 [BlackLists14] 1295 Chachra, N., McCoy, D., Savage, S., and G. Voelker, 1296 "Empirically Characterizing Domain Abuse and the Revenue 1297 Impact of Blacklisting", Workshop on the Economics of 1298 Information Security 2014, 2014, . 1302 [CleanFeed] 1303 Clayton, R., "Failures in a Hybrid Content Blocking 1304 System", Fifth Privacy Enhancing Technologies Workshop, 1305 PET 2005, 2005, 1306 . 1308 [GhostClickRIPE] 1309 RIPE NCC, "RIPE NCC Blocks Registration in RIPE Registry 1310 Following Order from Dutch Police", 2012, . 1316 [IN-OM-filtering] 1317 Citizen Lab, "Routing Gone Wild", July 2012, 1318 . 1320 [ISOCFiltering] 1321 Internet Society, "DNS: Finding Solutions to Illegal On- 1322 line Activities", 2012, . 1326 [Malicious-Resolution] 1327 Dagon, D., Provos, N., Lee, C., and W. Lee, "Corrupted DNS 1328 Resolution Paths: The Rise of a Malicious Resolution 1329 Authority", 2008, 1330 . 1333 [Morris] Kehoe, B., "The Robert Morris Internet Worm", 1992, . 1337 [NW08] Marsan, C., "YouTube/Pakistan incident: Could something 1338 similar whack your site?", NetWorld 2008, March 2008, . 1343 [Poort] Poort, J., Leenheer, J., van der Ham, J., and C. Dumitru, 1344 "Baywatch: Two approaches to measure the effects of 1345 blocking access to The Pirate Bay", Telecommunications 1346 Policy 38:383-392, 2014, . 1349 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 1350 Communication Layers", STD 3, RFC 1122, DOI 10.17487/ 1351 RFC1122, October 1989, 1352 . 1354 [RFC1149] Waitzman, D., "Standard for the transmission of IP 1355 datagrams on avian carriers", RFC 1149, DOI 10.17487/ 1356 RFC1149, April 1990, 1357 . 1359 [RFC2826] Internet Architecture Board, "IAB Technical Comment on the 1360 Unique DNS Root", RFC 2826, DOI 10.17487/RFC2826, 1361 May 2000, . 1363 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1364 Defeating Denial of Service Attacks which employ IP Source 1365 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 1366 May 2000, . 1368 [RFC2979] Freed, N., "Behavior of and Requirements for Internet 1369 Firewalls", RFC 2979, DOI 10.17487/RFC2979, October 2000, 1370 . 1372 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1373 A., Peterson, J., Sparks, R., Handley, M., and E. 1374 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1375 DOI 10.17487/RFC3261, June 2002, 1376 . 1378 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1379 Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, 1380 March 2004, . 1382 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1383 Rose, "DNS Security Introduction and Requirements", 1384 RFC 4033, DOI 10.17487/RFC4033, March 2005, 1385 . 1387 [RFC4084] Klensin, J., "Terminology for Describing Internet 1388 Connectivity", BCP 104, RFC 4084, DOI 10.17487/RFC4084, 1389 May 2005, . 1391 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1392 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1393 December 2005, . 1395 [RFC4924] Aboba, B., Ed. and E. Davies, "Reflections on Internet 1396 Transparency", RFC 4924, DOI 10.17487/RFC4924, July 2007, 1397 . 1399 [RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the 1400 IAB workshop on Unwanted Traffic March 9-10, 2006", 1401 RFC 4948, DOI 10.17487/RFC4948, August 2007, 1402 . 1404 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1405 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1406 . 1408 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1409 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 1410 RFC5246, August 2008, 1411 . 1413 [RFC5782] Levine, J., "DNS Blacklists and Whitelists", RFC 5782, 1414 DOI 10.17487/RFC5782, February 2010, 1415 . 1417 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 1418 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 1419 February 2012, . 1421 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 1422 of Named Entities (DANE) Transport Layer Security (TLS) 1423 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, 1424 August 2012, . 1426 [RFC6943] Thaler, D., Ed., "Issues in Identifier Comparison for 1427 Security Purposes", RFC 6943, DOI 10.17487/RFC6943, 1428 May 2013, . 1430 [RFC7288] Thaler, D., "Reflections on Host Firewalls", RFC 7288, 1431 DOI 10.17487/RFC7288, June 2014, 1432 . 1434 [RenesysPK] 1435 Brown, M., "Pakistan hijacks YouTube", February 2008, . 1439 [RojaDirecta] 1440 Masnick, M., "Homeland Security Seizes Spanish Domain Name 1441 That Had Already Been Declared Legal", 2011, . 1446 [SAC-056] "SSAC Advisory on Impacts of Content Blocking via the 1447 Domain Name System", October 2012, . 1450 [SafeBrowsing] 1451 Google, "Safe Browsing API", 2012, 1452 . 1454 [Takedown08] 1455 Moore, T. and R. Clayton, "The Impact of Incentives on 1456 Notice and Take-down", Workshop on the Economics of 1457 Information Security 2008, 2008, . 1461 [Telex] Wustrow, E., Wolchok, S., Goldberg, I., and J. Halderman, 1462 "Telex: Anticensorship in the Network Infrastructure", 1463 August 2011, . 1465 [Tor] "Tor Project: Anonymity Online", 2012, 1466 . 1468 [Wayback] "Internet Archive Wayback Machine", 1469 . 1471 [asymmetry] 1472 John, W., Dusi, M., and K. Claffy, "Estimating routing 1473 symmetry on single links by passive flow measurements", 1474 2010, . 1478 Authors' Addresses 1480 Richard Barnes 1481 Mozilla 1482 Suite 300 1483 650 Castro Street 1484 Mountain View, CA 94041 1485 US 1487 Email: rlb@ipv.sx 1488 Alissa Cooper 1489 Cisco 1490 707 Tasman Drive 1491 Milpitas, CA 95035 1492 USA 1494 Email: alcoop@cisco.com 1496 Olaf Kolkman 1497 Internet Society 1499 Email: kolkman@isoc.org 1501 Dave Thaler 1502 Microsoft 1503 One Microsoft Way 1504 Redmond, WA 98052 1505 US 1507 Email: dthaler@microsoft.com 1509 Erik Nordmark 1510 Arista 1512 Email: nordmark@arista.com