idnits 2.17.1 draft-arkko-arch-infrastructure-centralisation-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 05, 2019) is 1634 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.arkko-abcd-distributed-resolver-selection' is defined on line 250, but no explicit reference was found in the text -- No information found for draft-arkko-abcd-distributed-resolver-section - is the name correct? Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Arkko 3 Internet-Draft Ericsson 4 Intended status: Informational November 05, 2019 5 Expires: May 8, 2020 7 Centralised Architectures in Internet Infrastructure 8 draft-arkko-arch-infrastructure-centralisation-00 10 Abstract 12 Centralised deployment models for Internet services and Internet 13 business consolidation are well-known Internet trends, at least when 14 it comes to popular and user-visible service. This memo discusses 15 the impacts of similar trends within the Internet infrastructure, on 16 functions such as DNS resolution. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on May 8, 2020. 35 Copyright Notice 37 Copyright (c) 2019 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 3. Issues with Centralisation . . . . . . . . . . . . . . . . . 3 55 3.1. Single point of failure . . . . . . . . . . . . . . . . . 3 56 3.2. Surveillance . . . . . . . . . . . . . . . . . . . . . . 3 57 3.3. Concentration of information . . . . . . . . . . . . . . 4 58 3.4. Effect scope . . . . . . . . . . . . . . . . . . . . . . 4 59 3.5. Interaction with other issues . . . . . . . . . . . . . . 4 60 3.6. The effect of differing expectations and jurisdictions . 5 61 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 5 62 5. Informative References . . . . . . . . . . . . . . . . . . . 6 63 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 7 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 66 1. Introduction 68 Centralised deployment models for Internet services and Internet 69 business consolidation are well-known Internet trends, at least when 70 it comes to popular and user-visible service [ISOC] 71 [I-D.arkko-iab-internet-consolidation] [I-D.arkko-arch-dedr-report]. 72 This memo discusses the impacts of similar trends within the Internet 73 infrastructure, on functions such as DNS resolution. 75 This memo has been inspired by recent attempts to move DNS resolution 76 from large number of local servers to a more centralized 77 arrangements, but the principles outlined in this document apply more 78 generally to other basic Internet services. 80 Section 2 introduces the context of the memo, Section 3 discusses 81 some potential issues, and Section 4 makes a recommendation. 83 2. Context 85 For the purposes of this discussion, "Internet Infrastructure" is 86 defined as those parts of the technical Internet infrastructure that 87 are needed to form a communication substrate for applications to run 88 on. Applications are not a part of the infrastructure, they run on 89 it. But packet forwarding, routing, naming as well as higher level 90 functions such as certificate authorities are included; anything that 91 is needed to establish an end-to-end HTTPS connection between host is 92 part of the infrastructure. This also includes all Internet 93 technology that is needed for these part to work. 95 The DNS [RFC1035] is a complex system with many different security 96 issues, challenges, deployment models and usage patterns. While 97 there are many parts of the DNS system and they are all part of the 98 infrastructure that is needed for the Internet to function, perhaps 99 the most relevant for applications to connect is DNS resolution. 100 Systems are typically configured with a single DNS recursive 101 resolver, or a set of primary and alternate recursive resolvers. 102 Recursive resolver services are offered by organisations such as 103 enterprises, ISPs, and global providers. 105 3. Issues with Centralisation 107 The three primary issues are reliance on single points of failure, 108 the creation of too attractive surveillance targets, and the 109 concentration of information in a way that may affect other services. 111 3.1. Single point of failure 113 The first issue is having a concentrated point may become a single 114 point of accidental failure, or an attack target. For instance, a 115 single root for an Internet security system or a single trust anchor 116 for a routing system increases the risk of something bad happening 117 which affects everything. This seems a bad practice. Note that the 118 issue is not necessarily a single physical node that somehow in 119 control; even a distributed system that is under one administration 120 is a weak point, as there are typically single management systems and 121 internal components that, based on experience, can cause large parts 122 of the distributed system to stop functioning. Or, legal or 123 commercial structures cause an undesirable effect, such as ability to 124 access private data across borders [MSCVUS]. 126 Similarly, reliance on single piece of software can cause a single 127 point of failure. 129 Weaknesses of single centralised designs is not limited to technical 130 components. Even an administrative or governance system can become 131 weak through too much power or imagined power concentratred in one 132 place. For instance, the IANA system, when there was still a 133 perception of US government tie to its management, was used as 134 argument in various debates. Without such a central tie-in, there 135 would have not been any reason for tying IANA's important, but 136 essentially clerical duties to political issues. 138 3.2. Surveillance 140 The surveillance problem relates to putting too much information or 141 control in a single entity. 143 For instance, the DNS resolvers will learn the Internet usage 144 patterns of their clients. A client might decide to trust a 145 particular recursive resolver with information about DNS queries. 147 However, it is difficult or impossible to provide any guarantees 148 about data handling practices in the general case. And even if a 149 service can be trusted to respect privacy with respect to handling of 150 query data, legal and commercial pressures or surveillance activity 151 could result in misuse of data. Similarly, outside attacks may occur 152 towards any DNS services. For a service with many clients, these 153 risks are particularly undesirable. 155 3.3. Concentration of information 157 The concentration of information problem is about generating 158 information (or providing control opportunities) in basic Internet 159 communications service that may assist whoever gets that information 160 to be more capable in providing other services on top of the 161 Internet, in a manner that is not possible for competing other 162 service providers. This problem appears in particular where there 163 are machine-learning opportunities in the data being collected. 165 3.4. Effect scope 167 When a particular application, such as a social media system, reaches 168 a dominant position in the market, this position still affects only 169 that application. However, when Internet infrastructure changes, 170 this has wide-encompassing effects across all users and all types of 171 traffic. 173 Most things in the Internet are of course changeable or configurable, 174 but while users move from some set of applications to other ones over 175 time quite easily, normal users rarely configure their Internet 176 connectivity parameters in any fashion. As a result, the impact of 177 defaults, operating system and browser settings are wide-ranging. 179 3.5. Interaction with other issues 181 The above issues do not, of course, appear in isolation, but are 182 mixed with other potential developments and deployment models. For 183 instance, the DNS resolver centralisation problem is growing, as some 184 web browsers are choosing to deploy encrypted DNS query protocols 185 such as DNS-over-HTTPS (DOH) [RFC8484], and are doing it with default 186 servers being centralised ones. 188 One of the dilemmas in deploying some of these new technologies is 189 the ability to both make improvements at a quick pace and find 190 suitable other partners to interact with at the same quick pace. 192 3.6. The effect of differing expectations and jurisdictions 194 Many of the centralisation issues are also made more difficult 195 through differing expectations in different user populations. Some 196 gladly rely on a particular content provider, for instance, while 197 others may fear what data collection and leaks may result. It should 198 also be noted that legal and contractual situations throughout the 199 world differ, for instance in terms of expectations on user privacy. 201 4. Recommendations 203 For background, the current consolidation in ownership of and control 204 over the Internet infrastructure was not foreseen [Clark], and 205 arguably the loss of decentralized control goes against its design 206 objectives. For instance, [RFC1958] says: 208 This allows for uniform and relatively seamless operations in a 209 competitive, multi-vendor, multi-provider public network. 211 and 213 Heterogeneity is inevitable and must be supported by design. 215 And [RFC3935] says: 217 We embrace technical concepts such as decentralized control, edge- 218 user empowerment and sharing of resources, because those concepts 219 resonate with the core values of the IETF community. 221 Given this background, and given the issues listed in Section 3, it 222 seems prudent to recommend that whenever it comes to Internet 223 infrastructure services, centralised designs should be avoided where 224 possible. It is still important to deploy other important features, 225 such as protected signaling or encryption, and use the most 226 trustworthy services, but it needs to be done in a fashion that 227 ensures no single points of failure are created, and no centralised 228 storage of information are created in the process. 230 Where such centralised points are created, they will eventually fail, 231 or they will be misused through surveillance or legal actions 232 regardless of the best efforts of the Internet community. The best 233 defense to data leak is to avoid creating that data store to begin 234 with. 236 This memo is not an attempt to specify how specific issues can be 237 solved in a distributed manner, but historically, the Internet 238 community has been successful in doing this in a manner that does not 239 rely on a single service, be it about DNS root services, certificate 240 authorities, mail service, and so on. 242 5. Informative References 244 [Clark] Clark, D., "The Design Philosophy of the DARPA Internet 245 Protocols", In Symposium Proceedings on Communications 246 Architectures and Protocols, 106-114. SIGCOMM '88. New 247 York, NY, USA, ACM https://doi.org/10.1145/52324.52336 , 248 1988. 250 [I-D.arkko-abcd-distributed-resolver-selection] 251 Arkko, J., Thomson, M., and T. Hardie, "Selecting 252 Resolvers from a Set of Distributed DNS Resolvers", 253 Internet Draft draft-arkko-abcd-distributed-resolver- 254 section-00.txt (Work In Progress), IETF , November 2019. 256 [I-D.arkko-arch-dedr-report] 257 Arkko, J. and T. Hardie, "Report from the IAB workshop on 258 Design Expectations vs. Deployment Reality in Protocol 259 Development", Internet Draft draft-arkko-arch-dedr-report- 260 00.txt (Work In Progress), IETF , November 2019. 262 [I-D.arkko-iab-internet-consolidation] 263 Arkko, J., Trammell, B., Nottingham, M., Huitema, C., 264 Thomson, M., Tantsura, J., and N. Oever, "Considerations 265 on Internet Consolidation and the Internet Architecture", 266 draft-arkko-iab-internet-consolidation-02 (work in 267 progress), July 2019. 269 [ISOC] "Consolidation in the Internet economy", Internet Society, 270 https://future.internetsociety.org/2019/ , 2019. 272 [MSCVUS] Wikipedia, ., "Microsoft Corp. v. United States", 273 https://en.wikipedia.org/wiki/ 274 Microsoft_Corp._v._United_States , n.d.. 276 [RFC1035] Mockapetris, P., "Domain names - implementation and 277 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 278 November 1987, . 280 [RFC1958] Carpenter, B., Ed., "Architectural Principles of the 281 Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996, 282 . 284 [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", 285 BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004, 286 . 288 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 289 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 290 . 292 Appendix A. Acknowledgements 294 The author would like to thank Christian Huitema, Mark Nottingham, 295 Stephen Farrell, Gonzalo Camarillo, Mirja Kuehlewind, Ted Hardie, 296 Alissa Cooper, Martin Thomson, Daniel Migault, Goran AP Eriksson, 297 Joel Halpern, and many others for interesting discussions in this 298 problem space. 300 Author's Address 302 Jari Arkko 303 Ericsson 305 Email: jari.arkko@piuha.net