Internet DRAFT - draft-arkko-arch-infrastructure-centralisation
draft-arkko-arch-infrastructure-centralisation
Network Working Group J. Arkko
Internet-Draft Ericsson
Intended status: Informational November 05, 2019
Expires: May 8, 2020
Centralised Architectures in Internet Infrastructure
draft-arkko-arch-infrastructure-centralisation-00
Abstract
Centralised deployment models for Internet services and Internet
business consolidation are well-known Internet trends, at least when
it comes to popular and user-visible service. This memo discusses
the impacts of similar trends within the Internet infrastructure, on
functions such as DNS resolution.
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 May 8, 2020.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
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 Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Arkko Expires May 8, 2020 [Page 1]
Internet-Draft Centralised Architectures November 2019
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Issues with Centralisation . . . . . . . . . . . . . . . . . 3
3.1. Single point of failure . . . . . . . . . . . . . . . . . 3
3.2. Surveillance . . . . . . . . . . . . . . . . . . . . . . 3
3.3. Concentration of information . . . . . . . . . . . . . . 4
3.4. Effect scope . . . . . . . . . . . . . . . . . . . . . . 4
3.5. Interaction with other issues . . . . . . . . . . . . . . 4
3.6. The effect of differing expectations and jurisdictions . 5
4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 5
5. Informative References . . . . . . . . . . . . . . . . . . . 6
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
Centralised deployment models for Internet services and Internet
business consolidation are well-known Internet trends, at least when
it comes to popular and user-visible service [ISOC]
[I-D.arkko-iab-internet-consolidation] [I-D.arkko-arch-dedr-report].
This memo discusses the impacts of similar trends within the Internet
infrastructure, on functions such as DNS resolution.
This memo has been inspired by recent attempts to move DNS resolution
from large number of local servers to a more centralized
arrangements, but the principles outlined in this document apply more
generally to other basic Internet services.
Section 2 introduces the context of the memo, Section 3 discusses
some potential issues, and Section 4 makes a recommendation.
2. Context
For the purposes of this discussion, "Internet Infrastructure" is
defined as those parts of the technical Internet infrastructure that
are needed to form a communication substrate for applications to run
on. Applications are not a part of the infrastructure, they run on
it. But packet forwarding, routing, naming as well as higher level
functions such as certificate authorities are included; anything that
is needed to establish an end-to-end HTTPS connection between host is
part of the infrastructure. This also includes all Internet
technology that is needed for these part to work.
The DNS [RFC1035] is a complex system with many different security
issues, challenges, deployment models and usage patterns. While
there are many parts of the DNS system and they are all part of the
Arkko Expires May 8, 2020 [Page 2]
Internet-Draft Centralised Architectures November 2019
infrastructure that is needed for the Internet to function, perhaps
the most relevant for applications to connect is DNS resolution.
Systems are typically configured with a single DNS recursive
resolver, or a set of primary and alternate recursive resolvers.
Recursive resolver services are offered by organisations such as
enterprises, ISPs, and global providers.
3. Issues with Centralisation
The three primary issues are reliance on single points of failure,
the creation of too attractive surveillance targets, and the
concentration of information in a way that may affect other services.
3.1. Single point of failure
The first issue is having a concentrated point may become a single
point of accidental failure, or an attack target. For instance, a
single root for an Internet security system or a single trust anchor
for a routing system increases the risk of something bad happening
which affects everything. This seems a bad practice. Note that the
issue is not necessarily a single physical node that somehow in
control; even a distributed system that is under one administration
is a weak point, as there are typically single management systems and
internal components that, based on experience, can cause large parts
of the distributed system to stop functioning. Or, legal or
commercial structures cause an undesirable effect, such as ability to
access private data across borders [MSCVUS].
Similarly, reliance on single piece of software can cause a single
point of failure.
Weaknesses of single centralised designs is not limited to technical
components. Even an administrative or governance system can become
weak through too much power or imagined power concentratred in one
place. For instance, the IANA system, when there was still a
perception of US government tie to its management, was used as
argument in various debates. Without such a central tie-in, there
would have not been any reason for tying IANA's important, but
essentially clerical duties to political issues.
3.2. Surveillance
The surveillance problem relates to putting too much information or
control in a single entity.
For instance, the DNS resolvers will learn the Internet usage
patterns of their clients. A client might decide to trust a
particular recursive resolver with information about DNS queries.
Arkko Expires May 8, 2020 [Page 3]
Internet-Draft Centralised Architectures November 2019
However, it is difficult or impossible to provide any guarantees
about data handling practices in the general case. And even if a
service can be trusted to respect privacy with respect to handling of
query data, legal and commercial pressures or surveillance activity
could result in misuse of data. Similarly, outside attacks may occur
towards any DNS services. For a service with many clients, these
risks are particularly undesirable.
3.3. Concentration of information
The concentration of information problem is about generating
information (or providing control opportunities) in basic Internet
communications service that may assist whoever gets that information
to be more capable in providing other services on top of the
Internet, in a manner that is not possible for competing other
service providers. This problem appears in particular where there
are machine-learning opportunities in the data being collected.
3.4. Effect scope
When a particular application, such as a social media system, reaches
a dominant position in the market, this position still affects only
that application. However, when Internet infrastructure changes,
this has wide-encompassing effects across all users and all types of
traffic.
Most things in the Internet are of course changeable or configurable,
but while users move from some set of applications to other ones over
time quite easily, normal users rarely configure their Internet
connectivity parameters in any fashion. As a result, the impact of
defaults, operating system and browser settings are wide-ranging.
3.5. Interaction with other issues
The above issues do not, of course, appear in isolation, but are
mixed with other potential developments and deployment models. For
instance, the DNS resolver centralisation problem is growing, as some
web browsers are choosing to deploy encrypted DNS query protocols
such as DNS-over-HTTPS (DOH) [RFC8484], and are doing it with default
servers being centralised ones.
One of the dilemmas in deploying some of these new technologies is
the ability to both make improvements at a quick pace and find
suitable other partners to interact with at the same quick pace.
Arkko Expires May 8, 2020 [Page 4]
Internet-Draft Centralised Architectures November 2019
3.6. The effect of differing expectations and jurisdictions
Many of the centralisation issues are also made more difficult
through differing expectations in different user populations. Some
gladly rely on a particular content provider, for instance, while
others may fear what data collection and leaks may result. It should
also be noted that legal and contractual situations throughout the
world differ, for instance in terms of expectations on user privacy.
4. Recommendations
For background, the current consolidation in ownership of and control
over the Internet infrastructure was not foreseen [Clark], and
arguably the loss of decentralized control goes against its design
objectives. For instance, [RFC1958] says:
This allows for uniform and relatively seamless operations in a
competitive, multi-vendor, multi-provider public network.
and
Heterogeneity is inevitable and must be supported by design.
And [RFC3935] says:
We embrace technical concepts such as decentralized control, edge-
user empowerment and sharing of resources, because those concepts
resonate with the core values of the IETF community.
Given this background, and given the issues listed in Section 3, it
seems prudent to recommend that whenever it comes to Internet
infrastructure services, centralised designs should be avoided where
possible. It is still important to deploy other important features,
such as protected signaling or encryption, and use the most
trustworthy services, but it needs to be done in a fashion that
ensures no single points of failure are created, and no centralised
storage of information are created in the process.
Where such centralised points are created, they will eventually fail,
or they will be misused through surveillance or legal actions
regardless of the best efforts of the Internet community. The best
defense to data leak is to avoid creating that data store to begin
with.
This memo is not an attempt to specify how specific issues can be
solved in a distributed manner, but historically, the Internet
community has been successful in doing this in a manner that does not
Arkko Expires May 8, 2020 [Page 5]
Internet-Draft Centralised Architectures November 2019
rely on a single service, be it about DNS root services, certificate
authorities, mail service, and so on.
5. Informative References
[Clark] Clark, D., "The Design Philosophy of the DARPA Internet
Protocols", In Symposium Proceedings on Communications
Architectures and Protocols, 106-114. SIGCOMM '88. New
York, NY, USA, ACM https://doi.org/10.1145/52324.52336 ,
1988.
[I-D.arkko-abcd-distributed-resolver-selection]
Arkko, J., Thomson, M., and T. Hardie, "Selecting
Resolvers from a Set of Distributed DNS Resolvers",
Internet Draft draft-arkko-abcd-distributed-resolver-
section-00.txt (Work In Progress), IETF , November 2019.
[I-D.arkko-arch-dedr-report]
Arkko, J. and T. Hardie, "Report from the IAB workshop on
Design Expectations vs. Deployment Reality in Protocol
Development", Internet Draft draft-arkko-arch-dedr-report-
00.txt (Work In Progress), IETF , November 2019.
[I-D.arkko-iab-internet-consolidation]
Arkko, J., Trammell, B., Nottingham, M., Huitema, C.,
Thomson, M., Tantsura, J., and N. Oever, "Considerations
on Internet Consolidation and the Internet Architecture",
draft-arkko-iab-internet-consolidation-02 (work in
progress), July 2019.
[ISOC] "Consolidation in the Internet economy", Internet Society,
https://future.internetsociety.org/2019/ , 2019.
[MSCVUS] Wikipedia, ., "Microsoft Corp. v. United States",
https://en.wikipedia.org/wiki/
Microsoft_Corp._v._United_States , n.d..
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the
Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996,
<https://www.rfc-editor.org/info/rfc1958>.
[RFC3935] Alvestrand, H., "A Mission Statement for the IETF",
BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004,
<https://www.rfc-editor.org/info/rfc3935>.
Arkko Expires May 8, 2020 [Page 6]
Internet-Draft Centralised Architectures November 2019
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>.
Appendix A. Acknowledgements
The author would like to thank Christian Huitema, Mark Nottingham,
Stephen Farrell, Gonzalo Camarillo, Mirja Kuehlewind, Ted Hardie,
Alissa Cooper, Martin Thomson, Daniel Migault, Goran AP Eriksson,
Joel Halpern, and many others for interesting discussions in this
problem space.
Author's Address
Jari Arkko
Ericsson
Email: jari.arkko@piuha.net
Arkko Expires May 8, 2020 [Page 7]