intarea L. Giuliano Internet-Draft Intended status: Best Current Practice M. Aelmans Expires: 8 September 2022 T. Li 7 March 2022 Regional Internet Blocking Considerations draft-giuliano-blocking-considerations-00 Abstract Geopolitical conflicts can cause policy makers to question whether or not blocking the Internet connectivity for an opposing region is a constructive tactic. This document provides an overview of the various technologies that can be used to implement regional blocking of Internet connectivity and discusses the implications of these options. This document does not advocate any policy or given blocking mechanism, but does attempt to articulate the implications of these blocking technologies for policy makers. The document also intends to help inform policy makers from countries who could be exposed to such blocking techniques on the implications of these methods. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 8 September 2022. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. Giuliano, et al. Expires 8 September 2022 [Page 1] Internet-Draft Blocking Considerations March 2022 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Disconnection Methods . . . . . . . . . . . . . . . . . . . . 3 3.1. Physical layer . . . . . . . . . . . . . . . . . . . . . 4 3.2. Routing layer . . . . . . . . . . . . . . . . . . . . . . 4 3.2.1. Autonomous System Number Filtering . . . . . . . . . 5 3.2.2. De-peering . . . . . . . . . . . . . . . . . . . . . 5 3.2.3. Countering De-peering . . . . . . . . . . . . . . . . 6 3.2.4. Prefix Filtering . . . . . . . . . . . . . . . . . . 7 3.3. Packet Filtering . . . . . . . . . . . . . . . . . . . . 7 3.3.1. GeoIP ACLs . . . . . . . . . . . . . . . . . . . . . 8 3.4. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Gaps . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Information Dissemination . . . . . . . . . . . . . . . . 9 4.1.1. Information Value . . . . . . . . . . . . . . . . . . 9 4.2. Information Concealment . . . . . . . . . . . . . . . . . 10 4.3. Misinformation . . . . . . . . . . . . . . . . . . . . . 10 4.4. Target Inaccuracy . . . . . . . . . . . . . . . . . . . . 10 4.4.1. Accuracy of Registry Information . . . . . . . . . . 11 4.5. Spoofing ASNs and Hijacking Prefixes . . . . . . . . . . 11 4.6. Porous Borders . . . . . . . . . . . . . . . . . . . . . 12 4.7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 7.2. Informative References . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Giuliano, et al. Expires 8 September 2022 [Page 2] Internet-Draft Blocking Considerations March 2022 1. Introduction Geopolitical conflicts can cause policy makers to question whether or not blocking the Internet connectivity for an opposing region is a constructive tactic. This document provides an overview of the various technologies that can be used to implement regional blocking of Internet connectivity and discusses the implications of these options. This document does not advocate any policy or given blocking mechanism, but does attempt to articulate the implications of these blocking technologies for policy makers. The document also intends to help inform policy makers from countries who could be exposed to such blocking techniques on the implications of these methods. The content expressed in this document solely reflects the views of the authors and do not necessarily reflect the views or positions of any of our organizations, affiliates, friends, or enemies. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Scope The scope of this document it limited to a description of well-known methods for disrupting core Internet services including physical cabling, Internet routing, filtering, and the Domain Name System. The document does not intend to give any political directions or advocate for implementing the described methods, nor does it intend to be a guide for malicious attackers hence it will purely describe concepts and does not provide actual configuration or implementation methods. 3. Disconnection Methods There are many ways of blocking a region's Internet connectivity. In this section, we discuss some of them, their implications, capabilities, advantages, and disadvantages. Giuliano, et al. Expires 8 September 2022 [Page 3] Internet-Draft Blocking Considerations March 2022 3.1. Physical layer Disconnection at the physical layer is the most definitive method. Cutting cables and severing fibers will most definitely stop bits from passing. Unfortunately, this approach is also the most expensive to repair. In the optimistic view that disconnection is only intended to be temporary, creating downstream costs of physical repair is distinctly suboptimal. This approach may also be selected by the unscrupulous who have physical access to the media, but do not have further physical or managerial access. A less destructive physical layer disconnection is simply disconnecting the fiber or cable, either at the terminating device, optical module, patch panel, amplifier, repeater, or transponder. This is easily repaired, but still requires physical access. Unscrupulous parties that wish to prevent easy repairs would be unlikely to select this option. The simplest physical layer disconnection is administrative shutdown. Managerially disabling a physical circuit is a trivial configuration option that will sever communications. It is trivial to revert. 3.2. Routing layer The Internet is a collection of many enterprises, web and cloud hosting, access-providers, etc. networks connected to each other using the Border Gateway Protocol (BGP) [RFC4271] to exchange routing information between those networks. The simplest explanation of how BGP works is to compare it to a group of networks using the earlier described physical connections to gossip with each other on their knowledge about their own and neighboring networks. In other words, they exchange routing information describing how to reach destinations on the Internet. Connected entities play different roles in this ecosystem, some will know how to reach all destinations on the Internet. These networks are so-called Tier 1 providers and provide connectivity to Tier 2 and Tier 3 networks. They offer services on a global scale and connect thousands of networks. Tier 2 providers are large regional or national operators (for example the national service providers) offering services in country or regional. They have connections to many other networks, provide services to Tier 3 networks, but also purchase services from Tier 1 networks to reach destinations on the Internet they cannot reach themselves. Giuliano, et al. Expires 8 September 2022 [Page 4] Internet-Draft Blocking Considerations March 2022 Tier 3 providers don't provide routing information knowledge to other networks and are dependent from Tier 1 and Tier 2 networks to reach destinations on the Internet. In this category are small service providers or webhosting providers. The BGP protocols offers several options to manipulate the routing information that is exchanged between these networks. 3.2.1. Autonomous System Number Filtering Networks participating in the exchange of routing information with other networks use unique Autonomous System Numbers (ASNs) to identify themselves. These numbers are assigned to them by the Regional Internet Registries. The ASN is used to construct a path to a destination prefix on the Internet. For example, a Tier 1 advertises its prefix to a Tier 2 originating from its own ASN. Next the Tier 2 advertises the prefix to a Tier 1 and adds its own ASN to the path. The route to reach this prefix now looks as follows: ASN2 ASN1. As networks are highly connected there are many ASN paths through the Internet to reach destinations. The 'further away' the destination is the longer the ASN path will be. On average most destinations on the Internet are reachable in a maximum of 5 hops. In other words, most destinations on the Internet can be reached via a maximum of 5 networks. Networks that have a need to filter out another network with which they don't have a direct peering session completely have, next to filtering prefixes, the option to filter on ASN. When applying an ASN filter, it will filter out all prefixes originating from that specific ASN. Mitigating ASN filtering requires similar measures as mitigating prefix filters; networks with many upstream connections to Tier 1 and 2 networks will have a much lower chance of being completely filtered as, if one out of many upstream peers filters the ASN (and so its originating prefixes), others might still propagate them. This could still result in prefixes not being globally reachable anymore, but the chances are much lower. 3.2.2. De-peering BGP uses a TCP session between two networks to exchange routing information. Such a session is called a peering session. Disabling such a session is referred to as de-peering. Giuliano, et al. Expires 8 September 2022 [Page 5] Internet-Draft Blocking Considerations March 2022 3.2.2.1. De-peering Tier 3 networks In many cases Tier 3 networks are using a single Tier 1 or 2 network for their connectivity to the Internet. In that case it's relatively easy to disconnect such networks from the Internet by disabling their peering sessions on the Tier 1 or 2 side. 3.2.2.2. De-peering Tier 2 networks As described earlier these networks have multiple connections to other Tier 2 providers and typically between 2-8 Tier 1 providers to provide connectivity to the Internet. Subsequently, they could also receive routing information via Internet Exchange Points giving them even more options to reach destinations on the Internet. De-peering such a network is much harder as one would need to disable peering sessions in many networks and at multiple (probably international) locations. Tier 2 networks will likely have international connections as well. Pursuing networks to disable these peering sessions in another jurisdiction could be very complicated. 3.2.2.3. De-peering Tier 1 networks By their nature, Tier 1 networks have global span and have thousands of connections with other Tier 1, 2 and 3 networks. Fully disconnecting such networks is considered almost impossible without having physical and administrative access to the network itself. Pursuing other networks to de-peer a Tier 1 network is impossible because of the many countries they are present in and their jurisdictions. 3.2.3. Countering De-peering Entities that want to protect themselves against de-peering would have a diversified connectivity strategy including multiple Tier 1 and 2 peers, actively peering on Internet Exchange Points, and preferably possessing its own physical infrastructure to connect to other networks in different countries or regions. Tier 3 networks are most vulnerable to de-peering. Giuliano, et al. Expires 8 September 2022 [Page 6] Internet-Draft Blocking Considerations March 2022 3.2.4. Prefix Filtering Each network that is part of the Internet uses unique IPv4 and IPv6 address prefixes ranges to expose services to its directly connected (local) customers but also those connected via the Internet. These prefixes are advertised over a BGP peering session to the neighboring network so they will learn which prefixes originate from their neighbor and know how to reach them. Subsequently, they will advertise any routing knowledge they have about their neighboring networks and the neighboring network of their neighbors, etc. This way every network builds it own view of the Internet and map of how to reach destinations. For example, Tier 1 and 2 networks will both have 'downstream' (customer) peering sessions with networks of which they have knowledge about; the prefixes they are advertising. If one of these networks wants to filter a neighbor, they could de-peer them as discussed earlier but that would basically filter all prefixes. In many cases, for example when intending to filter out social media, a subset of the prefixes is enough to accomplish this goal. With this method a Tier 1 could also filter out prefixes from a Tier 3 that it learns via a Tier 2. De-peering the Tier 2 would result in all Tier 2 and all its customer prefixes becoming unreachable via this Tier 1. If only prefixes advertised by the single Tier 3 need to be filtered, the Tier 1 applies a prefix filter to the peering session from which it receives the advertisements. Contrary, networks with many upstream connections to Tier 1 and 2 networks will have a much lower chance of being completely filtered as, if one out of many upstream peers filters the prefixes, others might still propagate them. This could still result in the prefix not being globally reachable anymore, but the chances are much lower. 3.3. Packet Filtering Most network layer devices have the ability to filter traffic. The mechanism for doing this is commonly called an "Access Control List" (ACL). This is a possible mechanism for implementing a disconnection. Typically, an ACL allows filtering on a combination of source address, destination address, protocol number, and TCP/UDP source or destination port number. Giuliano, et al. Expires 8 September 2022 [Page 7] Internet-Draft Blocking Considerations March 2022 3.3.1. GeoIP ACLs The question then becomes one of ACL construction. However, this is not simple. IP address space is delegated in large sets, commonly known as 'prefixes.' Each prefix is assigned to an organization. Some organizations, such as Internet Service Providers (ISPs) will in turn delegate a portion of their address space to a customer. Customers and service providers do not necessarily fall along clean regional lines. Large multi-national corporations can receive a prefix from an ISP in one region and may use it in an entirely different region or even globally. They may also receive a prefix directly from a Regional Internet Registry (RIR). Service providers can obtain a prefix from an RIR and delegate parts of that prefix to customers from another region. This can create both false positives and false negatives when trying to map between a prefix and a region. There are services which attempt to provide mappings from an IP address or prefix to a region, commonly called 'GeoIP' services. However, due to the above issues, these services cannot guarantee their accuracy. Constructing an ACL based on GeoIP services is likely to have unintended consequences, both filtering unintended addresses and not filtering intended addresses. Some commercial applications (notably streaming video) are willing to accept these inaccuracies, but this may not be acceptable in all circumstances. Virtual Private Networks (VPNs) and other tunneling mechanisms can be used to create virtual topologies. If a single VPN server within a target region is not blocked, then it can provide access to innumerable other systems within the region, effectively bypassing GeoIP filtering services. When these are discovered, they are typically added to GeoIP databases, but this creates an ongoing battle between VPN service providers and GeoIP providers. As a result, this is an imperfect solution that may or may not be sufficiently accurate. 3.4. DNS Blocking DNS capabilities can be an effective method for inhibiting end users from easily accessing Internet resources in a given region. For example, removing the delegation entries in the root servers for a given country code can prevent users from resolving the names of all domains for that country code. This approach can be circumvented to an extent with the creation of stub zones on resolving nameservers, which can provide a shortcut delegation to the country code top-level domain servers (ccTLDs) that are authoritative for that country code. But these stub zone entries would have to be manually created on any resolving nameserver that serves the resolution requests of users seeking resolution of domains for that Giuliano, et al. Expires 8 September 2022 [Page 8] Internet-Draft Blocking Considerations March 2022 particular country code. In the opposite direction, blocking resolution requests can inhibit users coming from a region from easily accessing Internet resources. Specifically, filters can be used to block resolving nameservers from a given region, or can block resolution requests from end users within a given region from making resolution requests to resolving nameservers that reside outside that region. 4. Gaps The mechanisms discussed above cover the salient technical points for blocking a region. In this section, we discuss the various other considerations that are relevant to regional blocking. 4.1. Information Dissemination At the very lowest level, the Internet copies bits from one location to another. Bits that are injected at one point are packetized, forwarded, and hopefully show up at their intended destination. The technology of the Internet does not care what is encoded in those bits. Whether it is state secrets or yesterday's grocery list, the Internet will happily ship it all the way around the world in milliseconds. The intrinsic value, properties, and attributes of the information conveyed in those bits is immaterial at the technological level. 4.1.1. Information Value Policies considering blocking the transfer of information must also consider the value of the information that is being blocked. Filtering mechanisms can be extremely coarse and block all information, and this may not match the purposes of the policy. Thus, a blocking policy may need to be extremely specific about its goals and purposes. A policy may want some information to be able to enter into a region. Sending certain messages into the region may be beneficial to the policy maker. Similarly, being able to get information out of a region may be beneficial. Further, parties within a region may be depending on global Internet connectivity to coordinate activities. A policy that blocks too much information may be counterproductive to the aims of the policy maker. A more selective policy would want some information to be communicated and not other information. Further, a selective policy is likely to be highly directional. Information that should flow into the region may not be permitted back out, and vice versa. Giuliano, et al. Expires 8 September 2022 [Page 9] Internet-Draft Blocking Considerations March 2022 4.2. Information Concealment If a policy allows any information to transit a boundary, then there is the technological possibility that other information may also transit that boundary. Information can be disguised or concealed through the use of cryptography, steganography, or other techniques. Policy makers should assume that any mechanism that allows any information to transit a boundary would eventually be used to transfer information against the purposes of the policy. 4.3. Misinformation If a policy blocks information from flowing into a region, that may allow parties within that region to generate misinformation that is not disputed by outside information. This may be highly advantageous to the parties within the region. In the past, there have been many occurrences when parties within a region disconnected from the Internet precisely so that internal information could not be disputed. 4.4. Target Inaccuracy The Internet infrastructure does not assign address space or ASNs according to strict regional, national, or continental boundaries. While there is some rough correlation, that is the result of administrative convenience. Thus, a prefix that is allocated from the general pool of European address space may end up covering part of Europe and Greenland. An ASN that was allocated for Singapore may be used in Australia. This is further complicated by the fact that the parties that receive an ASN or prefix are not obligated or constrained to use it in a given region. If an organization acquires an ASN and subsequently grows outside of its original region, it may still use that ASN. If a company is assigned a prefix and the company is acquired by another firm, then that prefix could be used in a completely different hemisphere. Consequently, if a policy elects to block traffic based on ASNs and prefixes, it may have unintended consequences, potentially blocking unintended traffic and not blocking proscribed traffic. Giuliano, et al. Expires 8 September 2022 [Page 10] Internet-Draft Blocking Considerations March 2022 4.4.1. Accuracy of Registry Information Many public resources are available to query Internet routing related information including, IPv4, IPv6 and ASN resource holders, routing intentions and actual reachability data. Unfortunately, the data doesn't always represent the actual situation, can be incomplete and in quite a few occasions outdated. 4.4.1.1. Internet Routing Registries Internet Routing Registry (IRR) databases hold information about network operators routing intentions. For example, ASN holders can specify with whom they have peering relationships. This could give an indication which networks a specific ASN is connected to, however the data is entered (manually or automated) by network operators and isn't per se verified. In practice IRR databases are between 40-70% accurate. However, some show an accuracy of around 95%. 4.4.1.2. RPKI Resource Public Key Infrastructure (RPKI) is a public key infrastructure (PKI) framework to support improved security for the Internet's BGP routing infrastructure. The most important property is that in RPKI only legitimate resource holders can make statements about the IPv4, IPv6 and ASN resources they hold. This means that any information, right or wrong, found in RPKI databases represents the intention of, or at least is entered into RPKI by, the rightful holder. RPKI is therefore considered to be 100% accurate. The downside of RPKI is that there aren't records for every resource and a large portion of the IPv4, IPv6 and ASN resources don't have records in RPKI. 4.5. Spoofing ASNs and Hijacking Prefixes If a policy attempts to filter routing advertisements based on an ASN, then the opposition may attempt to counter that filtering attempt by using an alternate ASN. The alternate ASN may be an unused one, an ASN that has been assigned but is not actively in use elsewhere, or could be one that is actively assigned to another party. Using this ASN, the opposition could advertise its prefixes into BGP, bypass the ASN filter, and regain connectivity. Giuliano, et al. Expires 8 September 2022 [Page 11] Internet-Draft Blocking Considerations March 2022 Similarly, if a policy attempts to filter routing advertisements or implement forwarding plane filters based on assigned prefixes, then the opposition may attempt to circumvent these policies by obtaining, advertising, and deploying alternate prefixes. As with ASNs, these prefixes could come from unassigned address space, address space that has been assigned but is not actively advertised, or even address space that is actively advertised by other parties. There are security mechanisms that have been developed to help counter these possible attacks (IRR filtering [RFC7682], RPKI [RFC6811], and BGPsec [RFC8205]), but they are not ubiquitously deployed and may or may not be effective, depending on the operational procedures of ISPs that provide connectivity to the region. 4.6. Porous Borders The Internet is, by design, a decentralized system of interconnections. Thus, it is nearly impossible to completely block Internet access for a region. Simply put, there will always be ways to circumvent any blocking attempts by sufficiently motivated parties. However, there are certain chokepoints and various methods, as described above, that can significantly inhibit connectivity and throughput for users going to/coming from a given region. 4.7. Acknowledgments This document was inspired by the thoughtful comments of many friends and colleagues. 5. IANA Considerations This document makes no requests of IANA. 6. Security Considerations This document discusses technical and policy considerations of blocking Internet access for regions, and their potential impact on global security. This document does not present new attack or defense strategies and merely discusses the implications of a variety of technical approaches. This document does not advocate or dissuade any policy about blocking Internet connectivity, it discusses various considerations that policy makers should understand prior to setting policy. 7. References Giuliano, et al. Expires 8 September 2022 [Page 12] Internet-Draft Blocking Considerations March 2022 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 7.2. Informative References [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, DOI 10.17487/RFC6811, January 2013, . [RFC7682] McPherson, D., Amante, S., Osterweil, E., Blunk, L., and D. Mitchell, "Considerations for Internet Routing Registries (IRRs) and Routing Policy Configuration", RFC 7682, DOI 10.17487/RFC7682, December 2015, . [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol Specification", RFC 8205, DOI 10.17487/RFC8205, September 2017, . Authors' Addresses Lenny Giuliano Email: lenny@lenny.net Melchior Aelmans Email: melchior@aelmans.eu Tony Li Email: tony.li@tony.li Giuliano, et al. Expires 8 September 2022 [Page 13]