idnits 2.17.1 draft-barnes-blocking-considerations-01.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 16, 2012) is 4301 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Barnes 3 Internet-Draft BBN Technologies 4 Intended status: Informational A. Cooper 5 Expires: January 17, 2013 Center for Democracy & 6 Technology 7 O. Kolkman 8 NLnet Labs 9 July 16, 2012 11 Technical Considerations for Internet Service Blocking 12 draft-barnes-blocking-considerations-01.txt 14 Abstract 16 The Internet is structured to be an open communications medium. This 17 openness is one of the key underpinnings of Internet innovation, but 18 it can allow communications that may be viewed as either desirable or 19 undesirable by different parties. Thus, as the Internet has grown, 20 so have mechanisms to limit the extent and impact of abusive or 21 allegedly illegal communications. Recently, there has been an 22 increasing emphasis on "blocking", the active prevention of abusive 23 or allegedly illegal communications. This document examines several 24 technical approaches to Internet content blocking in terms of their 25 alignment with the overall Internet architecture. In general, the 26 approach to content blocking that is most coherent with the Internet 27 architecture is to inform endpoints about potentially undesirable 28 services, so that the communicants can avoid engaging in abusive or 29 illegal communications. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 17, 2013. 48 Copyright Notice 49 Copyright (c) 2012 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Architectural Principles . . . . . . . . . . . . . . . . . . . 4 66 2.1. End-to-End Connectivity and "Transparency" . . . . . . . . 4 67 2.2. Layering . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 2.3. Distribution and Mobility . . . . . . . . . . . . . . . . 5 69 2.4. Locality and Autonomy . . . . . . . . . . . . . . . . . . 6 70 3. Examples of Blocking . . . . . . . . . . . . . . . . . . . . . 6 71 4. Blocking Design Patterns . . . . . . . . . . . . . . . . . . . 8 72 4.1. Intermediary-Based Blocking . . . . . . . . . . . . . . . 8 73 4.2. Server-Based Blocking . . . . . . . . . . . . . . . . . . 11 74 4.3. Endpoint-Based Blocking . . . . . . . . . . . . . . . . . 13 75 5. Summary of Trade-offs . . . . . . . . . . . . . . . . . . . . 14 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 78 8. Informative References . . . . . . . . . . . . . . . . . . . . 17 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 81 1. Introduction 83 The original design goal of the Internet was to enable communications 84 between hosts. As this goal was met and people started using the 85 Internet to communicate, however, it became apparent that some hosts 86 were engaging in arguably undesirable communications. The most 87 famous early example of undesirable communications was the Morris 88 worm, which used the Internet to infect many hosts in 1988. As the 89 Internet has evolved into a rich communications medium, so have 90 mechanisms to restrict undesirable communications. 92 Efforts to restrict or deny access to Internet resources have evolved 93 over time. As noted in [RFC4084], some Internet service providers 94 impose restrictions on which applications their customers may use and 95 which traffic they allow on their networks. These restrictions are 96 often imposed with customer consent, where customers may be 97 enterprises or indiviuals. Increasingly, however, both governmental 98 and private sector entities are seeking to block access to certain 99 content, traffic, or communications without the knowledge or 100 agreement of affected users. Where these entities do not directly 101 control networks, they aim to make use of intermediary systems to 102 effectuate the blocking. 104 Entities may seek to block Internet content for a diversity of 105 reasons, including defending against security threats, restricting 106 access to content thought to be objectionable, and preventing illegal 107 activity. While blocking remains highly contentious in many cases, 108 the desire to restrict access to content will likely continue to 109 exist. 111 This document aims to clarify the technical implications and trade- 112 offs of various blocking strategies and to identify the potential for 113 different strategies to come into conflict with the Internet's 114 architecture or cause harmful side effects ("collateral damage"). 115 The strategies broadly fall into three categories: 117 1. Control by intermediaries 119 2. Manipulation of authoritative data 121 3. Reputation and authentication systems 123 Examples of blocking or attempted blocking using the DNS, HTTP 124 proxies, domain name seizures, spam filters, and RPKI manipulation 125 are used to illustrate each category's properties. 127 Whether particular forms of blocking are lawful in particular 128 jurisdictions raises complicated legal questions that are outside the 129 scope of this document. 131 2. Architectural Principles 133 To understand the implications of different blocking strategies, it 134 is important to understand the key principles that have informed the 135 design of the Internet. While much of this ground has been well trod 136 before, this section highlights four architectural principles that 137 have a direct impact on the viability of content blocking: end-to-end 138 connectivity, layering, distribution and mobility, and locality and 139 autonomy. 141 2.1. End-to-End Connectivity and "Transparency" 143 The end-to-end principle is "the core architectural guideline of the 144 Internet" [RFC3724]. Adherence to the principle of vesting endpoints 145 with the functionality to accomplish end-to-end tasks results in a 146 "transparent" network in which packets are not filtered or 147 transformed en route [RFC2775]. This transparency in turn is a key 148 requirement for providing end-to-end security features on the 149 network. Modern security mechanisms that rely on trusted hosts 150 communicating via a secure channel without intermediary interference 151 enable the network to support e-commerce, confidential communication, 152 and other similar uses. 154 The end-to-end principle is fundamental for Internet security, and 155 the foundation on which Internet security protocols are built. 156 Protocols such as TLS and IPsec [RFC5246][RFC4301] are designed to 157 ensure that each endpoint of the communication knows the identity of 158 the other endpoint, and that only the endpoints of the communication 159 can access the secured contents of the communication. For example, 160 when a user connects to a bank's web site, TLS ensures that the 161 user's banking information is communicated to the bank and nobody 162 else. 164 Some blocking strategies require intermediaries to insert themselves 165 within the end-to-end communications path, potentially breaking 166 security properties of Internet protocols. In these cases it can be 167 difficult or impossible for endpoints to distinguish between 168 attackers and the entities conducting blocking. 170 A similar notion to the end-to-end principle is the notion of 171 "transparency," that is, the idea that the network should provide a 172 generic connectivity service between endpoints, with minimal 173 interaction by intermediaries aside from routing packets from source 174 to destination. In "Reflections on Internet Transparency" [RFC4924], 175 the IAB assessed the relevance of this principle and concluded that 176 "far from having lessened in relevance, technical implications of 177 intentionally or inadvertently impeding network transparency play a 178 critical role in the Internet's ability to support innovation and 179 global communication". 181 2.2. Layering 183 Internet applications are built out of a collection of loosely- 184 coupled components or "layers." Different layers serve different 185 purposes, such as routing, transport, and naming (see [RFC1122], 186 especially Section 1.1.3). The functions at these layers are 187 developed autonomously and almost always operated by different 188 entities. For example, in many networks, physical and link-layer 189 connectivity is provided by an "access provider", while IP routing is 190 performed by an "Internet service provider" -- and application-layer 191 services are provided by a completely separate entity (e.g., a web 192 server). Upper-layer protocols and applications rely on combinations 193 of lower-layer functions in order to work. As a consequence of the 194 end-to-end principle, functionality at higher layers tends to be more 195 specialized, so that many different specialized applications can make 196 use of the same generic underlying network functions. 198 As a result of this structure, actions taken at one layer can affect 199 functionality or applications at higher layers. For example, 200 manipulating routing or naming functions to restrict access to a 201 narrow set of resources via specific applications will likely affect 202 all applications that depend on those functions. 204 In a similar manner, physical distances grow as one moves up the 205 stack. A host must be physically connected to a link-layer access 206 provider network, and its distance from its ISP is limited by the 207 length of a link, but Internet applications can be delivered by a 208 host anywhere in the world. 210 Thus, as one considers changes at each layer of the stack, changes at 211 higher layers become more specific in terms of application, but more 212 broad in terms of impact. Changes to an access network will only 213 affect a relatively small, well-defined set of users (namely, those 214 connected to the access network), but can affect all applications for 215 those users. Changes to an application service can affect users 216 across the entire Internet, but only for that specific application. 218 2.3. Distribution and Mobility 220 The Internet is designed as a distributed system both geographically 221 and topologically. Resources can be made globally accessible 222 regardless of their physical location or connectivity providers used. 223 Resources are also highly mobile -- moving content from one physical 224 or logical address to another can often be easily accomplished. 226 This distribution and mobility underlies a large part of the 227 resiliency of the Internet. Internet routing can survive major 228 outages such as cuts in undersea fibers because the distributed 229 routing system of the Internet allows individual networks to 230 collaborate to route traffic. Application services are commonly 231 protected using distributed servers. For example, even though the 232 2010 earthquake in Haiti destroyed almost all of the Internet 233 infrastructure in the country, the Haitian top-level domain name 234 (.ht) had no interruption in service because it was also accessible 235 via servers in the United States, Canada, and France. 237 Undesirable communications also benefit from this resiliency -- 238 resources that are blocked or restricted in one part of the Internet 239 can be reconstituted in another part of the Internet, creating a 240 "water balloon" effect. If a web site is prevented from using a 241 domain name or set of IP addresses, the web site can simply move to 242 another domain name or network. 244 2.4. Locality and Autonomy 246 The basic unit of Internet routing is an "Autonomous System" -- a 247 network that manages its own routing internally. The concept of 248 autonomy is present in many aspects of the Internet, as is the 249 related concept of locality, the idea that local changes should not 250 have a broader impact on the network. 252 These concepts are critical to the stability and scalability of the 253 Internet. With millions of individual actors engineering different 254 parts of the network, there would be chaos if every change had impact 255 across the entire Internet. 257 Locality implies that the impact of technical changes made to realize 258 blocking will only be within a defined scope. As discussed above, 259 this scope might be narrow in one dimension (set of users or set of 260 applications affected) but broad in another. Changes made to 261 effectuate blocking are often targeted at a particular locality, but 262 result in blocking outside of the intended scope. 264 3. Examples of Blocking 266 As noted above, systems to restrict or block Internet communications 267 have evolved alongside the Internet technologies they seek to 268 restrict. Looking back at the history of the Internet, there have 269 been several such systems deployed, with varying degrees of 270 effectiveness. 272 o Firewalls: Firewalls are a very common form of service blocking, 273 employed at many points in today's Internet. Typically, firewalls 274 block according to content-neutral rules, e.g., blocking all 275 inbound connections or outbound connections on certain ports. 276 Firewalls can be deployed either on end hosts (under user 277 control), or at network boundaries. 279 o Web Filtering: HTTP and HTTPS are common targets for blocking and 280 filtering, typically targeted at specific URLs. Some enterprises 281 use HTTP blocking to block non-work-appropriate web sites, and 282 several nations require HTTP and HTTPS filtering by their ISPs in 283 order to block illegal content. HTTPS is a challenge for these 284 systems, because the URL in an HTTPS request is carried inside the 285 secure channel. To block access to content made accessible via 286 HTTPS, filtering systems thus must either block based only on IP 287 address, or else obtain a trust anchor certificate that is trusted 288 by endpoints (and thus act as a man in the middle). 290 o Spam Filtering: Spam filtering is one of the oldest forms of 291 service blocking, in the sense that it denies spammers access to 292 recipients' mailboxes. Spam filters evaulate messages based on a 293 variety of criteria and information sources to decide whether a 294 given message is spam. For example, DNS Reverse Black Lists use 295 the reverse DNS to flag whether an IP address is a known spam 296 source [RFC5782]. Spam filters are typically either installed on 297 user devices (e.g., in a mail client) or operated by a mail domain 298 on behalf of users. 300 o Domain name seizure: In recent years, US law enforcement 301 authorities have been issuing legal orders to domain name 302 registries to seize domain names associated with the distribution 303 of counterfeit goods and other allegedly illegal activity 304 [US-ICE]. When domain names are seized, DNS queries for the 305 seized names are typically redirected to resolve to U.S. 306 government IP addresses that host information about the seizure. 307 Domain name seizures conflict with the DNS security architecture 308 [RFC4033] (since they involve manipulation of authoritative DNS 309 data), layering (since it is the content that is the target, not 310 the name itself), mobility (since the allegedly illegal activity 311 can easily relocate to a different domain name), and locality 312 (since content is blocked not only within the jursidiction of the 313 seizure, but globally, even when it may be affirmatively legal 314 elsewhere [RojaDirecta]). 316 o Safe Browsing: Modern web browsers provide some measures to 317 prevent users from accessing malicious web sites. For instance, 318 before loading a URL, current versions of Google Chrome and 319 Firefox web browsers use the Google Safe Browsing service to 320 determine whether or not a given URL is safe to load 321 [SafeBrowsing]. The DNS can also be used to mark domains as safe 322 or unsafe [RFC5782]. 324 o Interference with routing and addressing data: Governments have 325 recently intervened in the management of IP addressing and routing 326 information in order to maintain control over a specific set of 327 DNS servers. As part of an internationally coordinated response 328 to the DNSChanger malware, a Dutch court ordered the RIPE NCC to 329 freeze the accounts of several resource holders as a means to 330 limit the resource holders' ability to use certain address blocks 331 [GhostClickRIPE]. These actions have led to concerns that the 332 resource certification system and related secure routing 333 technologies developed by the IETF SIDR working group might be 334 subject to government manipulation as well [RFC6480], potentially 335 for the purpose of denying targeted networks access to the 336 Internet. 338 4. Blocking Design Patterns 340 Considering a typical end-to-end Internet communcation, there are 341 three logical points at which blocking mechanisms can be put in 342 place: the middle and either end. Mechanisms based in the middle 343 usually involve an intermediary device in the network that observes 344 Internet traffic and decides which communications to block. At the 345 service end of a communication, authoritative databases (such as the 346 DNS) and servers can be manipulated to deny or alter service 347 delivery. At the user end of a communication, authentication and 348 reputation systems enable user devices (and users) to make decisions 349 about which communications should be blocked. 351 In this section, we discuss these three "blocking design patterns" 352 and how they align with the Internet architectural principles 353 outlined above. In general, the third pattern -- informing user 354 devices of which services should be blocked -- is the most coherent 355 with the Internet architecture. 357 4.1. Intermediary-Based Blocking 359 A common goal for blocking systems is for the system to be able to 360 block communications without the consent or cooperation of either 361 endpoint to the communication. Such systems are thus implemented 362 using intermediary devices in the network, such as firewalls or 363 filtering systems. These systems inspect user traffic as it passes 364 through the network, decide based on the content of a given 365 communication whether it should be blocked, and then block or allow 366 the communication as desired. 368 Common examples of intermediary-based filtering are firewalls and 369 network-based web-filtering systems. For example, web filtering 370 devices usually inspect HTTP requests to determine the URL being 371 requested, compare that URL to a list of black-listed or white-listed 372 URLs, and allow the request to proceed only if it is permitted by 373 policy (or at least not forbidden). Firewalls perform a similar 374 function for other classes of traffic in addition to HTTP. Note that 375 this class does not cover cases where the intermediary is authorized 376 by the endpoints to act on an endpoint's behalf (e.g., mail servers), 377 since these involve the cooperation of at least one affected 378 endpoint. 380 Accomplishing blocking in this way conflicts with the end-to-end and 381 transparency principles noted above. The very goal of blocking in 382 this way is to impede transparancy for particular content or 383 communications. For this reason, they run into several technical 384 issues that limit their viability in practice. In particular, many 385 issues arise from the fact that an intermediary needs to have access 386 to a sufficient amount traffic to make its blocking determination. 388 The first challenge to obtaining this traffic is simply gaining 389 access to the constituent packets. The Internet is designed to 390 deliver packets from source to destination -- not to any particular 391 point along the way. In practice, inter-network routing is often 392 asymmetric, and for sufficiently complex local networks, intra- 393 network traffic flows can be asymmetric as well. 395 This asymmetry means that an intermediary will often see only one 396 half of a given communication (if it sees any of it at all), limiting 397 its ability to make decisions based on the content of the 398 communication. For example, a URL-based filter cannot make blocking 399 decisions if it only has access to HTTP responses (not requests). 400 Routing can sometimes be forced to be asymmetric within a given 401 network using routing configuration or layer-2 mechanisms (e.g., 402 MPLS), but these mechanisms are frequently brittle, complex, and 403 costly -- and often reduce network performance relative to asymmetric 404 routing. 406 If an intermediary blocking device can access the packets that 407 constitute a communication, then the next question is whether the 408 intermediary can access the application content within these packets. 409 If the application content is encrypted with a security protocol 410 (e.g., IPsec or TLS), then the intermediary will require the ability 411 to decrypt the packets to examine application content. Since 412 security protocols are designed to provide end-to-end security (i.e., 413 to prevent intermediaries from examining content), the intermediary 414 would need to masquerade as one of the endpoints, breaking the 415 authentication in the security protocol, reducing the security and of 416 the users and services affected, and interfering with private 417 communication. 419 If the intermediary is unable to decrypt the security protocol, then 420 its blocking determinations for secure sessions can only be based on 421 unprotected attributes, such as IP addresses and port numbers. Some 422 blocking systems today still attempt to block based on these 423 attributes, for example, blocking TLS traffic to known proxies that 424 could be used to tunnel through the blocking system. 426 However, as the Telex project recently demonstrated, if an endpoint 427 cooperates with a server, it can create a TLS tunnel that is 428 indistinguishable from legitimate traffic [Telex]. For example, if a 429 banking website operated a Telex server, then a blocking system would 430 be unable to distinguish legitimate encrypted banking traffic from 431 Telex-tunneled traffic to that server (potentially carrying content 432 that the blocking system would have blocked). 434 Thus, in principle it is impossible to prevent tunnelling through an 435 intermediary device without blocking all secure traffic. (The only 436 limitation in practice is the requirement for special software on the 437 client.) In most cases, blocking all secure traffic is an 438 unacceptable consequence of blocking, since security is often 439 required for services such as online commerce, enterprise VPNs, and 440 management of critical infrastructure. If governments or network 441 operators were to force these services to use insecure protocols so 442 as to effectuate blocking, they would expose their users to the 443 various attacks that the security protocols were put in place to 444 prevent. 446 Some network operators may assume that only blocking access to 447 resources available via unsecure channels is sufficient for their 448 purposes -- i.e., that the size of the user base that will be willing 449 to use secure tunnels and/or special software to circumvent the 450 blocking is low enough to make blocking via intermediaries 451 worthwhile. However, the longer such a blocking system is in place, 452 the more likely it will become that efficient and easy-to-use 453 circumvention tools that make use of secure tunnelling will become 454 widespread. 456 It may be tempting for those operating blocking systems to assume 457 that tunneling through intermediaries is sufficiently difficult that 458 the average user will not attempt it. Under that assumption, one 459 might decide that there is no need to control secure traffic, and 460 thus that intermediary-based blocking is an attractive option. 461 However, the longer such blocking systems are in place, the more 462 likely it is that efficient and easy-to-use tunnelling tools will 463 become available. The proliferation of the ToR network, for example, 464 and its increasingly sophisticated blocking-avoidance techniques 465 demonstrate that there is energy behind this trend [Tor]. 467 Blocking via intermediaries is thus only effective in a fairly 468 constrained set of circumstances. First, the routing structure of 469 the network needs to be such that the intermediary has access to any 470 communications it intends to block. Second, the blocking system 471 needs an out-of-band mechanism to mitigate the risk of secure 472 protocols being used to avoid blocking (e.g., human analysts 473 identifying IP addresses of tunnel endpoints), which may be resource- 474 prohibitive, especially if tunnel endpoints begin to change 475 frequently. If the network is sufficiently complex, or the risk of 476 tunneling too high, then intermediary-based blocking is unlikely to 477 be effective. 479 4.2. Server-Based Blocking 481 Internet services are driven by physical devices such as web servers, 482 DNS servers, certificate authorities, or WHOIS databases. These 483 devices control the structure and availability of Internet 484 applications by providing data elements that are used by application 485 code. For example, changing an A or AAAA record on a DNS server will 486 change the IP address that is bound to a given domain name; 487 applications trying to communicate with the host at that name will 488 then communicate with the host at the new address. 490 As physical objects, the servers that underlie Internet applications 491 exist within the jurisdiction of governments, and their operators are 492 thus subject to certain local laws. It is thus possible for laws to 493 be structured to facilitate blocking of Internet services operated 494 within a jurisdiction, either via direct government action or by 495 allowing private actors to demand blocking (e.g., through lawsuits). 497 The "seizure" of domain names discussed above is an example of this 498 type of blocking. Government officials required the operators of the 499 parent zones of a target name (e.g., "com" for "example.com") to 500 direct queries for that name to a set of government-operated name 501 servers. Users of services under a target name would thus be unable 502 to locate the correct servers for that name, denying them the ability 503 to access these services. The action of the Dutch police against the 504 RIPE NCC is of a similar character, limiting the ability of certain 505 ISPs to manage their Internet services by controlling their WHOIS 506 information. 508 Blocking services by disabling or manipulating servers does respect 509 the end-to-end principle, since the affected server is one end of the 510 blocked communication. However, its iteractions with layering, 511 resource mobility, and autonomy can limit its effectiveness and cause 512 undesirable consequences. 514 The layered architecture of the Internet means that there are several 515 points at which access to a service can be blocked. The service can 516 be denied Internet access (via control of routers), DNS services (DNS 517 servers), or application-layer services (application servers, e.g, 518 web servers). Blocking via these channels, however, is both 519 amplified and limited by the global nature of the Internet. 521 On the one hand, the global nature of Internet resources amplifies 522 blocking actions, in the sense that it increases the risk of 523 overblocking -- collateral damage to legitimate use of a resource. A 524 given network or domain name might host both legitimate services and 525 services that governments desire to block. A service hosted under a 526 domain name and operated in a jurisdiction where it is considered 527 undesirable might be considered legitimate in another jurisdiction; a 528 blocking action in the host jurisdiction would deny legitimate 529 services in the other. 531 On the other hand, the distributed and mobile nature of Internet 532 resources limits the effictiveness of blocking actions. Because an 533 Internet service can be reached from anywhere on the Internet, a 534 service that is blocked in one jurisdiction can often be moved or re- 535 instantiated in another jurisdiction. Likewise, services that rely 536 on blocked resources can often be rapidly re-configured to use non- 537 blocked resources. For example, the technique of "snowshoe spamming" 538 is already widely used to spread spam generation across a variety of 539 resources and jursidictions to prevent spam blocking from being 540 effective. 542 The efficacy of server-based blocking is further limited by the 543 autonomy principle discussed above. If the Internet community 544 realizes that a blocking decision has been made and wishes to counter 545 it, then local networks can "patch" the authoritative data to avoid 546 the blocking. For example, in 2008, Pakistan Telecom attempted to 547 deny access to YouTube within Pakistan by announcing bogus routes for 548 YouTube address space to peers in Pakistan. YouTube was temporarily 549 denied service on a global basis due to a route leak, but service was 550 restored in approximately two hours because network operators around 551 the world re-configured their routers to ignore the blocking routes 552 [RenesysPK]. In the context of SIDR and secure routing, a similar 553 re-configuration could be done if a resource certificate were to be 554 revoked in order to block routing to a given network. 556 In the DNS context, similar work-arounds are available. If a domain 557 name were blocked by changing authoritative records, network 558 operators can restore service simply by extending TTLs on cached pre- 559 blocking records in recursive resolvers, or by statically configuring 560 resolvers to return un-blocked results for the affected name. Indeed 561 these techniques are commonly used in practice to provide service to 562 domains that have been disrupted, such as the .ht domain during the 563 2010 earthquake in Haiti [EarthquakeHT]. 565 Server-based blocking also has a variety of non-technical 566 implications. The considerations discussed in ISOC's whitepaper on 567 DNS filtering [ISOCFiltering] also apply to other global Internet 568 resources. 570 In summary, server-based blocking can sometimes be used to 571 immediately block a target service by removing some of the resources 572 it depends on. However, such blocking actions often have harmful 573 side effects due to the global nature of Internet resources. The 574 global mobility of Internet resources, together with the autonomy of 575 the networks that comprise the Internet, can mean that the effects of 576 server-based blocking can be quickly be negated. To adapt a quote by 577 John Gilmore, "The Internet treats blocking as damage and routes 578 around it". 580 4.3. Endpoint-Based Blocking 582 Internet users and their devices make thousands of decisions every 583 day as to whether to engage in particular Internet communications. 584 Users decide whether to click on links in suspect email messages; 585 browsers advise users on sites that have suspicious characteristics; 586 spam filters evaluate the validity of senders and messages. If the 587 hardware and software making these decisions can be instructed not to 588 engage in certain communications, then the communications are 589 effectively blocked because they never happen. 591 There are several systems in place today that advise user systems 592 about which communications they should engage in. As discussed 593 above, several modern browsers consult with "Safe Browsing" services 594 before loading a web site in order to determine whether the site 595 could potentially be harmful. Spam filtering is one of the oldest 596 blocking systems in the Internet; modern blocking systems typically 597 make use of one or more "reputation" or "blacklist" databases in 598 order to make decisions about whether a given message or sender 599 should be blocked. These systems typically have the property that 600 many blocking systems (browsers, MTAs) share a single reputation 601 service. 603 This approach to blocking is coherent with the Internet architectural 604 principles discussed above, dealing well with the end-to-end 605 principle, layering, mobility, and locality/autonomy. 607 Much like server-based blocking, endpoint-based blocking is performed 608 at one end of an Internet communication, and thus avoids the problems 609 related to end-to-end security mechanisms that intermediary-based 610 blocking runs into. Endpoint-based blocking also lacks some of the 611 limitations of server-based blocking: While server-based blocking can 612 only see and affect the portion of an application that happens at a 613 given server (e.g., DNS name resolution), endpoint-based blocking has 614 visibility into the entire application, across all layers and 615 transactions. This visibility provides endpoint-based blocking 616 systems with a much richer set of information on which to make 617 blocking decisions. 619 In particular, endpoint-based blocking deals well with adversary 620 mobility. If a blocked service relocates resources or uses different 621 resources, a server-based blocking approach may not be able to affect 622 the new resources. An intermediary-based blocking system may not 623 even be able to tell whether the new resources are being used, if the 624 blocked service uses secure protocols. By contrast, endpoint-based 625 blocking systems can detect when a blocked service's resources have 626 changed (because of their full visibility into transactions) and 627 adjust blocking as quickly as new blocking data can be sent out 628 through a reputation system. 630 Finally, in an endpoint-based blocking system, blocking actions are 631 performed autonomously, by individual endpoints or their delegates. 632 The effects of blocking are thus local in scope, minimizing the 633 effects on other users or other, legitimate services. 635 The primary challenge to endpoint-based blocking is that it requires 636 the cooperation of endpoints. Where this cooperation is willing, 637 this is a fairly low barrier, requiring only reconfiguration or 638 software update. Where cooperation is unwilling, it can be 639 challenging to enforce cooperation for large numbers of endpoints. 640 If cooperation can be achieved, endpoint-based blocking can be much 641 more effective than other approaches because it is so coherent with 642 the Internet's architectural principles. 644 5. Summary of Trade-offs 646 Intermediary-based blocking is a relatively low-cost blocking 647 solution in some cases, but a poor fit with the Internet 648 architecture, especially the end-to-end principle. It thus suffers 649 from several limitations. 651 o Examples: Firewalls, web filtering systems. 653 o A single intermediary device can be used to block access by many 654 users to many services. 656 o Intermediary blocking can be done without the cooperation of 657 either endpoint to a communication (although having that 658 cooperation makes it more likely to be effective). 660 o Intermediaries often lack sufficient information to make blocking 661 decisions, due to routing asymmetry or encryption. 663 o Intermediary blocking sometimes involves breaking end-to-end 664 security assurances. 666 o Tunneling through blocking is difficult to prevent without 667 preventing legitimate secure services. 669 Server-based blocking can provide rapid effects for resources under 670 the control of the blocking entity, but can have limited effects due 671 to the global, autonomous nature of Internet resources and networks. 673 o Examples: Domain name seizures, WHOIS account freezing, RPKI 674 certificate revocation. 676 o Internet services that depend on specific resources can be blocked 677 by disabling those resources. 679 o Blocked resources can often be easily relocated or reinstantiated 680 in a location where they will not be blocked. 682 o Resources used by undesirable services are often also used by 683 legitimate services, resulting in collateral damage. 685 o Autonomy of Internet networks and users allows them to "route 686 around" blocking. 688 Endpoint-based blocking matches well with the overall design of the 689 Internet. 691 o Examples: Safe browsing, spam filtering, enterprise HTTPS proxies. 693 o Endpoints block services by deciding whether or not to engage in a 694 given communication. 696 o Blocking system has full visibility into all layers involved in a 697 communication. 699 o Adversary mobility can be quickly observed so that blocking 700 systems can be updated to account for it. 702 o Requires cooperation of endpoints. 704 Because it agrees so well with Internet architectural principles, 705 endpoint-based blocking is the most effective form of Internet 706 service blocking, and the least harmful to the Internet. 708 6. IANA Considerations 710 This document makes no request of IANA. 712 7. Security Considerations 714 The primary security concern related to Internet service blocking is 715 the affect that it has on the end-to-end security model of many 716 Internet security protocols. When blocking is enforced by an 717 intermediary with respect to a given communication, the blocking 718 system may need to obtain access to confidentiality-protected data to 719 make blocking decisions. Mechanisms for obtaining such access 720 typically require the blocking system to defeat the authentication 721 mechanisms built into security protocols. 723 For example, some enterprise firewalls will dynamically create TLS 724 certificates under a trust anchor recognized by endpoints subject to 725 blocking. These certificates allow the firewall to authenticate as 726 any website, so that it can act as a man-in-the-middle on TLS 727 connections passing through the firewall. 729 Modifications such as these obviously make the firewall itself a 730 point of weakness. If an attacker can gain control of the firewall 731 or compromise the key pair used by the firewall to sign certificates, 732 he will have access to the plaintext of all TLS sessions for all 733 users behind that firewall, in a way that is undetectable to users. 735 When blocking systems are unable to inspect and block secure 736 protocols, it is tempting to simply block those protocols. For 737 example, a web blocking system that is unable to hijack HTTPS 738 connections might simply block any attempted HTTPS connection. 739 However, since Internet security protocols are commonly used for 740 critical services such as online commerce and banking, blocking these 741 protocols would block access to these services as well, or worse, 742 force them to be conducted over insecure protocols. 744 Security protocols can, of course, also be used a mechanism for 745 blocking services. For example, if a blocking system can insert 746 invalid credentials for one party in an authentication protocol, then 747 the other end will typically terminate the connection based on the 748 authentication failure. However, it is typically much simpler to 749 simply block secure protocols than to exploit those protocols for 750 service blocking. 752 8. Informative References 754 [EarthquakeHT] 755 Raj Upadhaya, G., ".ht: Recovering DNS from the Quake", 756 March 2010, . 761 [GhostClickRIPE] 762 RIPE NCC, "RIPE NCC Blocks Registration in RIPE Registry 763 Following Order from Dutch Police", 2012, . 769 [ISOCFiltering] 770 Internet Society, "DNS: Finding Solutions to Illegal On- 771 line Activities", 2012, . 775 [RFC1122] Braden, R., "Requirements for Internet Hosts - 776 Communication Layers", STD 3, RFC 1122, October 1989. 778 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 779 February 2000. 781 [RFC3724] Kempf, J., Austein, R., and IAB, "The Rise of the Middle 782 and the Future of End-to-End: Reflections on the Evolution 783 of the Internet Architecture", RFC 3724, March 2004. 785 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 786 Rose, "DNS Security Introduction and Requirements", 787 RFC 4033, March 2005. 789 [RFC4084] Klensin, J., "Terminology for Describing Internet 790 Connectivity", BCP 104, RFC 4084, May 2005. 792 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 793 Internet Protocol", RFC 4301, December 2005. 795 [RFC4924] Aboba, B. and E. Davies, "Reflections on Internet 796 Transparency", RFC 4924, July 2007. 798 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 799 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 801 [RFC5782] Levine, J., "DNS Blacklists and Whitelists", RFC 5782, 802 February 2010. 804 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 805 Secure Internet Routing", RFC 6480, February 2012. 807 [RenesysPK] 808 Brown, M., "Pakistan hijacks YouTube", February 2008, . 812 [RojaDirecta] 813 Masnick, M., "Homeland Security Seizes Spanish Domain Name 814 That Had Already Been Declared Legal", 2011, . 819 [SafeBrowsing] 820 Google, "Safe Browsing API", 2012, 821 . 823 [Telex] Wustrow, E., Wolchok, S., Goldberg, I., and J. Halderman, 824 "Telex: Anticensorship in the Network Infrastructure", 825 August 2011, . 827 [Tor] "Tor Project: Anonymity Online", 2012, 828 . 830 [US-ICE] U.S. Immigration and Customs Enforcement, "Operation in 831 Our Sites", 2011, . 834 Authors' Addresses 836 Richard Barnes 837 BBN Technologies 838 1300 N. 17th St 839 Arlington, VA 22209 840 USA 842 Phone: +1 703 284 1340 843 Email: rbarnes@bbn.com 844 Alissa 845 Center for Democracy & Technology 847 Email: acooper@cdt.org 849 Olaf 850 NLnet Labs 852 Email: olaf@nlnetlabs.nl