Internet DRAFT - draft-hallambaker-presentation
draft-hallambaker-presentation
Internet Engineering Task Force (IETF) Phillip Hallam-Baker
Internet-Draft Comodo Group Inc.
Intended Status: Standards Track October 23, 2014
Expires: April 26, 2015
An Internet Presentation Level
draft-hallambaker-presentation-00
Abstract
Paper submitted to the IAB Middlebox workshop describing an Internet
architectural model.
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 http://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."
Copyright Notice
Copyright (c) 2014 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
(http://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.
Hallam-Baker April 26, 2015 [Page 1]
Internet-Draft An Internet Presentation Level October 2014
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Success has Consequences . . . . . . . . . . . . . . . . . . . 4
2.1. Middleboxes Emerge as Symptom, not Cause . . . . . . . . 6
2.2. The Deployment Challenge . . . . . . . . . . . . . . . . 7
2.3. Need for a Consistent Discovery Architecture . . . . . . 8
2.4. Limitations of the DNS Infrastructure . . . . . . . . . 9
2.5. Non DNS Discovery Infrastructure . . . . . . . . . . . . 10
2.6. Not Yet Existing Infrastructure . . . . . . . . . . . . 11
2.7. The Administration Gap . . . . . . . . . . . . . . . . . 11
3. An Internet Presentation Level . . . . . . . . . . . . . . . 12
3.1. Authoritative Infrastructures and Ground Truth . . . . . 14
3.2. Anti-Abuse Filtering . . . . . . . . . . . . . . . . . . 15
3.3. IPv6 Transition . . . . . . . . . . . . . . . . . . . . 15
3.4. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.5. Naming Architecture . . . . . . . . . . . . . . . . . . 16
3.5.1. Account Names . . . . . . . . . . . . . . . . . . . 17
3.5.2. Strong Names . . . . . . . . . . . . . . . . . . . 18
3.6. Discovery Services . . . . . . . . . . . . . . . . . . . 19
3.6.1. Consistent Discovery API . . . . . . . . . . . . . 19
4. Implementation . . . . . . . . . . . . . . . . . . . . . . . 20
4.1. Connection Broker . . . . . . . . . . . . . . . . . . . 20
4.2. Private DNS - Eliminating Legacy DNS restrictions . . . 21
4.3. OmniQuery - A Presentation Level Discovery Service . . . 22
4.4. OmniPublish - A Presentation Level Provisioning Service 23
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 23
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.1. Normative References . . . . . . . . . . . . . . . . . . 24
6.2. Informative References . . . . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24
Hallam-Baker April 26, 2015 [Page 2]
Internet-Draft An Internet Presentation Level October 2014
1. Overview
IETF process traditionally favors incremental change over radical
change. But this approach fails when the problem to be solved is
itself caused by divergent incremental change. Every one of the
problems described in this document has been solved and not once but
multiple times. And it is the proliferation and inconsistency of
those solutions that is now the problem.
This first section of this paper surveys the key problems arising
from the current Internet discovery architecture and the constraints
within which any proposed solution must work. It is the view of the
author that the proliferation of middleboxes is a symptom rather than
the cause of these problems. Middleboxes do however represent a
constraint which any solution must work within.
The second section argues that the areas in which the original
Internet architecture now falls short do not properly belong
exclusively to either the transport layer or the application layer.
The need for middle boxes arises because the Internet model lacks a
level of abstraction between the transport and application layers.
The term 'Presentation Level' is used as a term for this new
interface as the term 'Presentation Layer' is firmly established as
the term of art for what lies between OSI layers 5 and 7.
While the idea that the DNS represents an Internet presentation layer
has been advanced on previous occasions, this paper takes the concept
further using the term presentation level to include host and service
discovery, account presence protocols, Kerberos like key services and
PKI.
The final section describes a realization the architecture described
in the previous section through a compact set of simple Web Services
that are individually of limited scope. Each of these proposals has
been tested in an open source implementation and has been described
previously a separate draft. These are:
* Omni-Query [!I-D.hallambaker-omnibroker]
* Omni-Publish [!I-D.hallambaker-omnipublish]
* Private-DNS [!I-D.hallambaker-privatedns]
* SXS-Connect [!I-D.hallambaker-wsconnect]
Each of the first three proposals has its own independent value
proposition that makes it a candidate for deployment even if neither
of the other two ever advances. The last provides common
infrastructure that supports the first three.
Hallam-Baker April 26, 2015 [Page 3]
Internet-Draft An Internet Presentation Level October 2014
2. Success has Consequences
While the IAB call for papers suggests that the need for change
arises from the deployment of middleboxes in the otherwise perfect
Internet architecture, it is the opinion of the author that
middleboxes are just one of the symptoms of the failure of the
Internet architecture to keep pace with Internet growth.
The fact that the Internet architecture has survived with little
major modification in the quarter century since deployment of DNS is
testament to both the foresight of the original architects and the
immense difficulty of making changes to an infrastructure on which
over two billion people and the majority of global commerce depend.
Denying outright the possibility that the Internet architecture model
devised in the 1980s might fall short of current needs is the mindset
that ossified the telephone network. The Internet was developed by
people who had the skill and the vision to question the status quo.
At the time the foundation of the Internet was laid, computers were
expensive and typically singular. The conception of the Inter-network
as a network of networks was radical at a time when computer
networking at most University campuses referred to the means by which
dumb terminals connected to the central mainframe.
The modern Internet is a very different place. [RFC0801] describing
the plan for the 'flag day' transition to TCP gives the number of NTP
hosts in January 1982 as 200. This is roughly the number of networked
devices I currently have in my house. And while my present
residential computing configuration is an outlier today, such
configurations will become typical in only a few years time.
The modern Internet connects between two and twenty billion hosts,
the difference reflecting the difficulty of agreeing a definition of
a host as much as uncertainty in the count. What is a host? A CPU? A
CPU core? A virtual machine running on a CPU? But regardless of
whether the Internet has grown by seven or eight orders of magnitude,
the notion that every aspect the original architecture should be
maintained unchanged is ideology, not respect.
Further, current estimates suggest that the global population will
ultimately peak at between 8 and 10 billion. Extrapolating from
current trends we should expect that every household item that
currently uses electricity will eventually connect to the network. We
should therefore adopt as a planning estimate that the Internet will
eventually expand to at least ten trillion connected devices.
One architectural consequence of the growth of the Internet is that
the Internet is no longer a network of hosts, it is a network of
services. The so-called cloud is after all merely a name we give to
the place Internet services reside because we no longer consider
their physical location to be important. The core principle that
Hallam-Baker April 26, 2015 [Page 4]
Internet-Draft An Internet Presentation Level October 2014
underpins the cloud is that it is whether a function can be trusted
that is important, not where it takes place. So why get excited over
whether functions happen in a middle box or an end point if place
does not matter?
Another significant architectural consequence is that the Internet is
no longer a network of networks. It is a network of networks of
networks and it is possible there are further levels of recursion.
Middlebox appliances owe their existence in part to the fact that the
interests of the user are not always the same as the interests of the
local area network manager and their interests may in turn diverge
from those of the Internet access provider whose interests are almost
certainly divergent from their carrier.
Yet another difference resulting from scale is the need for security.
When the Internet was a purely academic infrastructure and the users
were members of academic institutions, there were few assets worth
attacking and abuse was effectively controlled by an accountability
model. As a result, the Internet culture many of us grew up with is
profoundly maladapted to life in an Internet of 2 billion users. Even
if only 1% of them were malicious (the usual expectation for a
population is 10%) that would be 20 million malicious actors.
In particular we need to recognize that while everyone has the right
to connect to the Internet, there is not a general right to connect
to my part of it. In particular:
* The fact that it is possible to initiate an SMTP session with a
mail server does not entail a guarantee that the server will
accept an email for delivery
* The fact that an email is delivered does not mean it must be
read
* The fact that a DNS name is registered with ICANN by a
notorious Internet crime ring does not mean that my local DNS
service must resolve it
* The fact that an IP address is assigned does not mean that I
must allow my hosts or services to connect to it.
The received Internet security model is profoundly maladapted through
the insistence of a single failure security model. This leads to the
two arguments that are invariably made against any proposal for a new
security control, that the new control is 'unnecessary' because
another existing control is sufficient or that it will be ineffective
because it does not cover every conceivable corner case.
An architecture that allows a breach to occur as a result of the
failure of a single system is a bad architecture. Thus arguments of
the form 'we don't need firewalls because systems should not be
Hallam-Baker April 26, 2015 [Page 5]
Internet-Draft An Internet Presentation Level October 2014
vulnerable to malware' are profoundly wrong because they assert that
if the breach could have been prevented by control X then it is
somehow bad architecture to insist on also deploying control Y. The
correct security approach is to deploy both controls X and Y and a
further infrastructure Z to provide feedback by reporting on breaches
that should have been caught by one control but were not.
The biggest and most concerning consequence of Internet growth is the
difficulty of changing the Internet infrastructures. IPv6, IPSEC and
DNSSEC were all proposed over two decades ago. All were intended to
become ubiquitous within a few years, no more than five at most. None
has succeeded in becoming ubiquitous, not is there any reason to
expect this to change until the reasons for the lack of deployment
are addressed.
2.1. Middleboxes Emerge as Symptom, not Cause
The term middlebox is a generic term for any network infrastructure
that breaks the pure end-to-end IP architecture. As such they have
been generally regarded as the result of ignorance or malice rather
than a response to real world requirements. Only rarely has the
question been asked if the end-to-end principle might not be
universal in scope.
As previously mentioned, I have 200 network enabled devices in my
residence. Ideally these devices would all be IP enabled devices but
many of them are currently not IP enabled precisely because while it
makes perfect sense to have a light switch to communicate using IP
protocol it does not make sense for a lightswitch to be running an
email server.
The principle of least privilege should be given at least equal
respect as the end-to-end principle. And the least privilege
principle states that my light switch does not need to be able to
send email. Nor does my light switch need to be able to perform any
form of communication that is not essential to its purpose.
Set out in these terms, the role and justification for Internet
firewalls becomes obvious. As does the fact that firewalls are
woefully inadequate for their intended purpose. While my firewalls
could in theory prevent an attacker outside my network mounting an
attack on my toaster oven, if the toaster oven is compromised, they
cannot stop it conspiring with the refrigerator. And that is a
serious concern.
The real problem with firewalls is not that they do not have a useful
purpose but that they are unable to fulfill the purposes they are
designed for. The main consequence of Internet firewall port blocking
is that all new Internet services are layered on port 80 and port 443
rather than protocol specific ports, precisely to avoid 'problems
caused by' middleboxes.
Hallam-Baker April 26, 2015 [Page 6]
Internet-Draft An Internet Presentation Level October 2014
A realistic Internet architecture should respect the fact that the
Internet is a network of networks and a network has a natural and
legitimate interest in patrolling its border. The network perimeter
is after all the point where responsibility for packets being emitted
passes from one party to another. For the same reason, perimeter
security will always have an important place in any serious security
architecture. But that does not mean it should be the only place
where filtering should occur.
In a default deny network, no network communication should take place
that is not expressly permitted by network security policy. The
network communications that are permitted for a light switch would
not normally be as broad as those permitted to a desktop computer.
The idea that the local network is separate from the larger Internet
is not new. It is in fact the origin of the Inter-Network itself. My
private machines and my private network are my private domain. While
the impact of cloud computing means that the precise physical
boundaries are no longer clear, the Domain Name System provides the
infrastructure that denotes the logical boundaries between domains.
2.2. The Deployment Challenge
Changing an infrastructure with ten billion moving parts is
inevitably difficult and slow. But one aspect that makes the Internet
particularly difficult to change is the rigidity of the Internet
application interface.
When the Internet was first developed it was only one of many
networking standards and so there was no 'Internet' API, there was a
network API which supported the Internet as one option. A client
application using one of the standard network stacks of the day,
would connect to an Internet host by means of gethostbyname() system
call to obtain the network address(es) of the host to connect to and
then perform whatever platform specific call is required to establish
a socket (or mailbox) to connect to the specified address.
A quarter century later, the application interface is essentially
unchanged. The only difference being that on some object oriented
platforms a socket is now known as a 'stream'. Meanwhile a large
number of changes have taken place in the Internet infrastructure and
the way it is used:
* The hosts.txt file was replaced by the DNS
* DNS names are typically names of services as opposed to hosts
and clients typically are attempting to connect to services.
Hallam-Baker April 26, 2015 [Page 7]
Internet-Draft An Internet Presentation Level October 2014
* There is no standard approach to support establishment of peer
to peer connections.
* DNS has been extended to support records that advertise
services but these records are not visible to application
clients unless they make use of their own DNS libraries.
Further the decision to make use of SRV or NAPTR records is
left to the application protocol designer.
* DNS has been extended to support authentication of
authoritative DNS Resource Records but this information is not
typically available to the application programmer.
* Many applications make use of TLS over TCP transport in place
of TCP but it is left to the application protocol designer and
implementer to manage this and make security sensitive
decisions on the user's behalf by deciding the PKI
configuration to use.
* IPSEC transport may be available but there is no infrastructure
for delivery of keys.
* Even though IP is designed to support many end-to-end
protocols, the only protocols for which platform support is
ubiquitously available are TCP and UDP.
* Middleboxes of various types intercept and frequently transform
IP and DNS communications for purposes that are rarely
documented and frequently irrational.
* Many network applications, in particular, all successful peer-
to-peer applications employ a variety of techniques to
circumvent the limitations imposed by middleboxes.
One of the problems that has prevented progress in this area is that
the Application programmers desire for a new API that allows them the
advantages of the modern Internet is frequently mistaken for a desire
for an API that exposes more of the underlying complexity of the
Internet and DNS.
2.3. Need for a Consistent Discovery Architecture
What many of these defects have in common is that the Internet lacks
a standard architecture for discovery and negotiation of Internet
connections. While this problem has been solved on many occasions in
many different ways there is no single coherent solution to the
connection discovery problem.
The mechanism used for host discovery was not a choice for
application protocol designers in the days of RFC802. The mechanism
used for establishment of peer to peer or service connections should
Hallam-Baker April 26, 2015 [Page 8]
Internet-Draft An Internet Presentation Level October 2014
not be a choice for application protocol designers today. The IETF
should have one mechanism that is consistently implemented and
applied. And this mechanism should provide for all the needs of the
modern Internet and anticipate future needs:
* Internet Protocol version, address and port number.
* Choice of transport protocol: e.g. TCP, UDP, Multicast or new
transports to be developed
* Choice of security enhancement: e.g. None, TLS, DTLS or new
transport to be developed.
* Authentication credentials to be verified
* Authentication credentials to be supplied
It is a truth universally acknowledged that gethostbyname is not a
suitable application layer interface to the DNS. But the truth that
is rather too frequently ignored is that application programmers
really don't want to have to deal with anything more complex. While
new APIs that expose the internals of DNS and PKI and directory
infrastructures are highly desirable in their own right, these are
not and should not be considered tools for use by the application
protocol designer or implementer.
Application protocol designers are very fond of explaining that the
discovery process is not a one-size-fits-all proposition, that there
are subtleties and complications that mean that it is not possible
for one particular discovery approach to meet every need. And these
reasons are sound and correct and are also the reason why such
decisions should not be taken by the application protocol designer at
all. Such considerations are properly the concern of the network
administrators and user and should be presented in a fashion that
puts those parties in direct control.
2.4. Limitations of the DNS Infrastructure
Another common source of deficiency are the limitations of the DNS
protocol and the DNS infrastructure. While the two are frequently
considered to be equivalent they are in fact very different. It being
far easier to change the former than the latter. Adding a Resource
Record type to DNS requires no more than publication of an RFC.
Changing the DNS infrastructure is much more challenging.
The DNS was originally designed as a mechanism to replace the
hosts.txt file mapping Internet host names to addresses and early use
was largely limited to this requirement. By the time more advanced
uses came to be considered the vast majority of the deployed DNS
infrastructure imposed a 500 byte message limit on DNS messages and
each request packet could only specify one domain and one record type
Hallam-Baker April 26, 2015 [Page 9]
Internet-Draft An Internet Presentation Level October 2014
at a time.
Although the DNS protocol has been updated to remove the 500 byte
limit and every major DNS server implementation updated a decade or
more ago, many deployed residential network gateway boxes truncate
messages to conform to the long obsolete requirement. Another rather
more insidious limitation is that some middle boxes and platforms
impose tight limits on the number of outstanding DNS requests that
have not received responses.
While residential customers of an ISP can usually (but by no means
always) overcome such limitations by providing their own network
gateway box, this is by no means the only middle box attack performed
on DNS. Whoever controls the DNS controls the Internet, a fact not
lost on most ISPs.
It is now routine for DNS resolution services provided by ISPs to
return a redirect to a Web site with an advertising page rather than
the NXDOMAIN response code that should be returned when a domain name
is not found. Some ISPs hijack NXDOMAIN responses from third party
open resolvers to ensure that customers cannot avoid their unwanted
intrusions.
DNS is a trusted infrastructure but the mechanism by which clients
discover DNS resolvers is inherently untrustworthy. Internet clients
depend on the DNS resolver returning trustworthy information. It is
utterly ludicrous and unacceptable that the default DNS service be
chosen by network proximity without regard for trustworthiness.
DNSSEC can alert the user to the fact that perfidy has occurred but
does not provide a means of obtaining the correct, unadulterated
result. While government agencies in most liberal democracies are
anxious to conceal the fact that they are censoring and/or
intercepting network traffic, this constraint does not apply to
authoritarian regimes where the purpose of these practices is to
deter rather than prevent expression of dissent. And there is no
reason to believe that ISPs that have already decided that replacing
NXDOMAIN responses from external DNS services that compromise their
commercial interests will not attempt to strip out DNSSEC data if
they choose.
2.5. Non DNS Discovery Infrastructure
The DNS is the discovery infrastructure of the Internet and the
authoritative infrastructure that maps Internet domain names to
assertions about those names. It is not however the only
infrastructure that applications make use of during service discovery
and connection establishment. Nor should it be.
Hallam-Baker April 26, 2015 [Page 10]
Internet-Draft An Internet Presentation Level October 2014
Modern email infrastructures make extensive use of various types of
blocklist. Although these blocklists are frequently distributed using
DNS protocol they are by no means authoritative DNS responses. On the
contrary, the value of these assertions lies in the very fact that
they are provided by a third party and not the holder of the IP
address.
Email was the first Internet infrastructure to make use of account
identifiers of the form <username>@<domain>. Such identifiers are now
used in a wide range of peer to service and peer to peer applications
including authentication, instant messaging, voice and video.
Despite the ubiquity of such applications, no consistent presence
infrastructure has emerged. Depending on the application designer's
whim, names may be resolved by means of a variety of presence
services including LDAP, OpenID, SAML, WebFinger or XMPP and while
the DNS infrastructure is sometimes used as the means of resolving
the <domain> component of the account identifier, this rather obvious
approach is by no means universal or even the most common.
On many occasions, researchers have attempted to employ the DNS
infrastructure itself as a presence infrastructure. There are
structural factors that make this approach unlikely to succeed. In
most medium or larger enterprises the DNS infrastructure is managed
by a network administration team which is quite separate from the
system administrators and IT support staff who issue user accounts.
At any rate the fact that despite repeated attempts over the course
of three decades, such approaches have invariably remained 'research'
suggests that the approach is not ideal.
2.6. Not Yet Existing Infrastructure
The most important gap in the Internet discovery architecture is the
lack of a coherent security policy infrastructure to tell
applications which security enhancements are supported by an Internet
service and what credentials will be supplied. The lack of such
infrastructure is the reason that twenty years after the deployment
of practical PKI, security remains the exception on the Internet
rather than the norm.
This shortcoming has of course been recognized in recent work and
proposals such as certificate pinning and 'strict security' provide
valuable benefits. But the approach in such proposals is necessarily
tactical rather than strategic, designed to provide the best security
in the difficult circumstances of the legacy Internet rather than a
principled architecture.
Hallam-Baker April 26, 2015 [Page 11]
Internet-Draft An Internet Presentation Level October 2014
2.7. The Administration Gap
There has never been a shortage of proposals for ingenious mechanisms
for extracting important and useful information from the DNS. The
problem that has received far less attention is the problem of how to
ensure the important, useful and accurate information can be inserted
into the DNS in the first place and how to keep the inserted
information up to date.
In the early Internet, DNS configuration was essentially static.
Modern network configurations require a more dynamic approach. One of
the more problematic consequences of middlebox proliferation is that
they typically introduce a veto point into the network that must be
configured to allow Internet services and peer to peer applications
to receive inbound connections. This is also one of the main reasons
that the deployers consider them to be attractive. Rather than
attempting to prevent the network administrators from deploying
devices that provide control through ad-hoc heuristics we should
attempt to design a system that gives them the control they seek.
Deployment in the cloud and PKI based security both introduce a whole
additional dimension of dynamic discovery and administration
challenges. A node in a cloud computing surface might support an
Internet service for only a few hours.
3. An Internet Presentation Level
According to Wikipedia, the Internet Application layer includes BGP,
DHCP and RIP. While these are certainly not transport layer protocols
it is hard to argue that they sit any better in the application
layer. If a new model for describing the Internet architecture were
to be developed these would surely sit in a quite separate
compartment to protocols such as Telnet SMTP, IMAP, POP, NNTP and FTP
that support applications.
The OSI layered model is a poor abstraction for the Internet
architecture because it describes what takes place in the layers
rather than the interfaces between the layers.
It is the interfaces between the levels that are the essential part
of the model. We can replace the data link layer with messages
strapped to pigeons provided that the interface to the Network layer
is maintained.
Every level in the model carries the same data content in different
representations. It is the identifiers used between the levels that
changes.
* Application - Presentation: Domain Name, Service Identifier
Hallam-Baker April 26, 2015 [Page 12]
Internet-Draft An Internet Presentation Level October 2014
* Presentation - Transport: IP Address and Port Number
* Transport - Network: Packet Header
We note in passing but do not have the time to go into the topic in
detail, that understanding the model in terms of interfaces rather
than layers is also key to establishing the proper place for Virtual
Private Networks (VPNs) and Software Defined Networking (SDN). A VPN
is not a 'Layer', it is an object that sits above the Network level
and presents the Network/Transport interface to both the Network and
Transport Level. SDN performs the same role at the Data-Link/Network
layer.
In the now defunct OSI model, the Presentation layer was an
intermediary through which all communications between the Transport
and Application layer passed being transformed in the process.
What is proposed instead is that the discovery, performance and
security features that mediate between the Transport and Application
layers reside in a compartment labelled 'Presentation Service' that
does not necessarily fully extend between the two:
+------------------------------------------+
| Application Layer |
+------------------------------------------+
| | |
+--------------+ +--------------+ |
| Presentation | | Presentation | |
| Services | | Layer | |
+--------------+ +--------------+ |
| | |
+------------------------------------------+
| Transport Layer |
+------------------------------------------+
DNS is a Presentation Service. Following the traditional approach, an
application first discovers the IP address using the DNS and then
establishes a direct connection. Once discovery is completed, the DNS
plays no further role in mediating the connection. Kerberos and PKI
are likewise Presentation Services and follow the same use pattern.
In contrast, TLS is a Presentation Layer since all communications
between the application and transport layers are transformed.
One important protocol that does not fit within this architectural
model is HTTP and this is precisely because HTTP was originally
conceived as an application protocol but is now commonly employed as
a presentation layer. One visible consequence of this inconsistency
is the conflict between the requirements of the Web browser and Web
services communities in the design of HTTP/2.0.
Hallam-Baker April 26, 2015 [Page 13]
Internet-Draft An Internet Presentation Level October 2014
Although HTTP/2 eliminates some of the inefficiency arising from the
use of RFC822 style text headers in the HTTP/1.1 protocol design, it
does not provide the features that one would expect or require from a
fully featured multimedia delivery protocol with multiple content
streams being delivered at individually negotiated Packet layer
Quality of Service. Nor does the traditional Internet architecture
suggest such an approach is even possible.
While the realization of such a presentation layer would likely
require innovation at both the Presentation and Transport layers and
is therefore outside the scope of this document, it should be the
function of the Presentation l ayer to inform an application that
such a capability was available and thus enable a graceful transition
between the current protocol and the new. Thus a browser attempting
to connect to http://example.com/ in a 2020 Internet might discover
that the HTTP/1.1 and HTTP/2 protocols are supported over a TCP
transport and that in addition HTTP/3 is supported over an as-yet-
undefined 'Extended' ETCP transport.
3.1. Authoritative Infrastructures and Ground Truth
The DNS infrastructure is regarded as holding a privileged position
in the Internet architecture as it is the authoritative
infrastructure for resolving DNS names. But what does the term
'authoritative' mean and is a result from an authoritative
infrastructure necessarily better than a result that is not
authoritative?
In considering the issue of naming we distinguish an authoritative
infrastructure from a service protocol. What makes a naming
infrastructure authoritative is that it serves as the 'ground truth'
for a set of names. Thus when in the early 1990s a Sun workstation
used the yellow pages protocol to resolve DNS names, the application
clients did not use DNS protocol to resolve DNS names but they were
still logically connected to the Internet since the DNS
infrastructure provided the ground truth for the name resolution
process.
The DNS infrastructure is, was and will always be the authoritative
infrastructure for resolving Internet names. The DNS protocol is
merely a protocol that supports access to the DNS infrastructure and
can change if necessary to meet changing constraints and
requirements.
While results from the DNS infrastructure are authoritative, they do
not necessarily represent a an objective ground truth that is
guaranteed to be the same regardless of who is asking the question
and when the question is being asked. Only cryptography can provide
ground truth in a communication infrastructure and then only with
respect to a key and not to facts.
Hallam-Baker April 26, 2015 [Page 14]
Internet-Draft An Internet Presentation Level October 2014
3.2. Anti-Abuse Filtering
Consider the case in which a DNS registration is known to be used by
organized crime. This situation has occurred on numerous occasions
and is unavoidable in any system that is designed to provide no
obstacles to legitimate registrations. there have even been cases in
which DNS registrars have existed for the sole purpose of
facilitating criminal activity. The mere fact that a DNS name is
registered does not require a discovery service to resolve it.
There is a clear need for a curated discovery service just as
enabling such a service presents a clear threat of abuse. Curated
discovery introduces a new control point and some see a slippery
slope that begins with filtering out criminal activity expands to
block access to pornography and eventually ends up as government
censorship of political speech.
But slippery slope or not, relying on unfiltered authoritative
services replaces the possibility of abuse with certainty of attack.
The real question should be not whether curated discovery is possible
but who is in control. An infrastructure that puts the end user in
direct control of the choice of discovery service can be used as a
mechanism to evade government censorship rather than enforce it.
3.3. IPv6 Transition
The DNS infrastructure provides us with an authoritative answers to
questions about DNS names but not necessarily answers to the
questions that a particular application needs.
An A record binding the name ipv4.example.com to the address 10.1.2.3
does not answer the question a network host that can only speak IPv6
needs to ask.
In the traditional approach to IPv6 transition we introduce some form
of middlebox performing v4-v6 address translation, some form of
discovery mechanism by which the network host can discover the
translation middlebox and some form of addressing convention allowing
the host to direct an IPv6 packet to an IPv4 endpoint. While this
gets the job done, it requires the IPv6 network host to continue to
support IPv4 for as long as there are any IPv4 hosts remaining in the
network which for practical purposes means forever.
In a simpler approach the network host implements a pure IPv6 stack
with no support for legacy IPv4 or any transition mechanism. When the
host attempts to connect to an Internet service that is only
available in the IPv4 network, it would rely on its DNS resolver to
return a non-authoritative AAAA record giving the IPv6 address of a
translation service.
Hallam-Baker April 26, 2015 [Page 15]
Internet-Draft An Internet Presentation Level October 2014
The second approach makes the DNS resolver the mediator of the IPv4-
to-v6 transition process. If a legacy IPv4 network sets up a local
translation gateway, a single change to the resolver configuration
allows every host using that resolver to take advantage of it.
Centralizing the configuration provides the necessary agility.
3.4. DNSSEC
As we have seen, the authoritative response is not necessarily the
one that answers the right question. Where does this leave DNSSEC
which is designed to allow verification of signatures on
authoritative responses?
While some DNSSEC supporters will no doubt argue that allowing a
client to act on non-authoritative DNS information opens up a
Pandora's box of horrors, the true situation is far less worrisome.
Using DNSSEC to sign A and AAAA records is like using an armored
delivery truck for delivering packages to a person living on a park
bench. An IP address is a means and only sometimes an end-point in an
Internet conversation. Resolver modification of A and AAAA should not
therefore be cause for panic. But what should?
The Presentation service model offers a useful framework for
resolving this question. The interfaces between layers are
characterized by a particular type of identifier. The IP address and
protocol type characterize the interface between the Internet and
Transport layer. The IP address and port number characterize the
interface between the Transport layer and the presentation layer. The
interface between the presentation layer and the Application layer is
characterized by DNS names and cryptographic credentials.
It is appropriate therefore to perform end-to-end validation of
signatures on records that bind cryptographic credentials to a DNS
name and to limit other DNSSEC validation to the DNS resolution
service.
3.5. Naming Architecture
Discovery is the process of resolving names to services and names to
accounts. In order to establish a solid basis for a Discovery
architecture we must first establish a consistent approach to naming.
While Uniform Resource Identifiers are commonly considered to be an
'Internet' naming architecture, the scope of URIs is universal and
not limited to the Internet. URIs therefore represent a naming
infrastructure layer above the Internet rather than a part of the
Internet itself.
In practice the Internet has three naming/addressing infrastructures
that are established with clarity:
Hallam-Baker April 26, 2015 [Page 16]
Internet-Draft An Internet Presentation Level October 2014
* Autonomous Service numbers
* Internet Protocol addresses
* Domain Name System labels.
Of these naming conventions, only the last two are visible to
Internet endpoints in normal circumstances. At a pragmatic level, an
IP address is defined as where packets sent to that address will go
and a DNS label is defined by the responses returned by the DNS
infrastructures.
The interpretation of Internet account identifiers is not established
with similar clarity. While SMTP and XMPP both adopt a reasonable and
consistent approach to interpretation of RFC822 account names, the
lack of a coherent discovery architecture has led to what is at best
an unhelpful divergence of approaches and at worst a demonstration of
the fact that a hundred intelligent and accomplished Internet
protocol developers and a dozen major companies can commit resources
to the notion that users will understand a URI is their account name.
3.5.1. Account Names
Internet account names are account names of the form introduced in
RFC822, i.e. <username>@<domain>.
The authoritative source for resolution of an Internet account name
is an Internet service that is advertised in the DNS by the holder of
the corresponding <domain>.
At present there are application protocols, notably SMTP a nd XMPP
that follow this model but the authoritative resolution of the
account is limited to the application. There is no authoritative
Internet service resolving Internet accounts in the general case.
The problem here is not the lack of a protocol. It would be easy
enough to specify a subset of the OpenID protocol that excluded URIs,
XRIs and other identifiers that are not Internet accounts. The
problem is that the service has to be recognized as authoritative.
And this cannot happen when OpenID is still architected as a vehicle
for establishing a new Internet naming infrastructure for accounts
with all the commercial advantages that would imply for the parties
who control the institutions controlling the alleged IPR.
From a practical point of view, the authoritative infrastructure for
Internet accounts is email. Established practice is that when a user
forgets their account identifier or password they are asked to
respond to a message sent to their Internet account address using the
SMTP protocol. While this approach is expedient, the user experience
is awful and so Web site designers avoid consulting the authoritative
service wherever possible. The user experience and the security of
Hallam-Baker April 26, 2015 [Page 17]
Internet-Draft An Internet Presentation Level October 2014
this infrastructure could be greatly improved if a protocol was
designed to meet this specific purpose.
3.5.2. Strong Names
The Personal Privacy Environment introduced the concept of Strong
Email Addresses. A strong email address is of the form
<fingerprint>?<username>@<domain> where the <username> and <domain>
portions have the usual meaning and <fingerprint> is a cryptographic
digest identifying a public key which represents the root of trust
for establishing communication with the specified Internet account.
In the simplest form of strong email address <fingerprint> is a PGP
public key fingerprint associated with the address. In a more general
approach, <fingerprint> is the fingerprint of a public key that is a
root of trust for a PKI. This may be a formal PKI hierarchy
established by a CA, a lightweight personal hierarchy or a Web of
Trust.
In this paper we extend this approach to DNS labels to establish
ground truth for DNS names. Following the convention established by
punycode domain names, a strong domain name label has the form "xx--"
+ <fingerprint> where <fingerprint> is a cryptographic digest
identifying a public key which represents the root of trust for
authenticating the domain name.
Thus if we wish to describe a domain 'example.com' to be interpreted
with respect to the ICANN DNSSEC root of trust we would write:
example.com.xx--49AAC1-1D7B6-F6446-702E5-4A1607-3716
49AAC11.. being the fingerprint of the ICANN DNSSEC root.
Representing the ICANN DNSSEC root in this way is not particularly
interesting as it is the implicit root of trust for all DNSSEC names
(although it could be very useful in the case of a root roll over).
The strong name representation becomes much more interesting when a
third party trust provider is involved such as a CA:
example.com.xx--cd9b97-e67b74-99a33f-59128e-f2cd46-3156e5-f6bd
The advantage of using a strong email address is that it provides a
layer of abstraction that conceals the complexity of the trust
infrastructure that lies beneath it in the same way that IP addresses
provide a layer of abstraction above the routing infrastructure and
URIs provide a layer above the application protocol stack. This has a
profound impact on how we address the problem.
In the traditional approach to Internet PKI (including SAML and
DNSSEC) the approach we follow is to obtain signed assertions
relevant to the proposition at issue from trusted sources, verify the
Hallam-Baker April 26, 2015 [Page 18]
Internet-Draft An Internet Presentation Level October 2014
provenance of the assertions received by attempting to validate the
signatures and decide if the assertions are valid. In this model an
assertion is either valid or invalid. So when a party is acting as an
intermediary on behalf of another they are forced to respond as if
their answer is based on ground truth when it almost certainly is
not.
Simple Distributed Security Infrastructure (SDSI) by Rivest and
Lampson attempted to resolve this dilemma by introducing a key
centric PKI in which the namespace is intrinsically relative. Thus in
SDSI we talk about 'Bob's Alice' rather than 'Bob'. Ground truth is
introduced into the SDSI scheme by giving a small circle of
privileged parties reserved names (the paper suggests verisign!!,
dns!!, usps!!). This approach left SDSI deferring rather than
resolving the ground truth problem.
Using a fingerprint of a public key provides a ground truth that is
objective and unambiguous. We now have a vocabulary in which Web
Service A can describe to B the trust assertion it has received that
is grounded by trust provider C. And that allows us to be explicit as
to whether a B is relying on A or C as the trust provider.
3.6. Discovery Services
The traditional IETF approach to the discovery and maintenance
problems has been piecemeal. Instead of calling gethostbyname and
opening up a socket, the application programmer is expected to
interact with the half dozen components of a disparate discovery and
network configuration infrastructure, hoping that the network
administrators at the service to which connection is to be
established has done their part correctly. While these piecemeal
approaches generally anticipate a gradual migration of the relevant
functions to the DNS, the only process by which the DNS
infrastructure is expected to improve is through the gradual
attrition of non-conformant systems.
In this paper we take a different approach. Rather than burden the
application programmer with new chores, we reduce the effort expected
of them by providing a new Presentation API that provides an
abstraction layer above all the Presentation services that might be
used to establish a connection.
3.6.1. Consistent Discovery API
To establish a connection to an Internet service, the application
programmer need specify only the domain name of the service to
connect to and the service protocol identifier. The implementation
library then returns either a stream (or socket) connection to the
requested service with the best available security and performance
characteristics as specified by the service security policy or an
error report explaining why a connection was not established.
Hallam-Baker April 26, 2015 [Page 19]
Internet-Draft An Internet Presentation Level October 2014
For example, if a Web browser were to attempt to resolve the URL
http://example.com/ the browser client would call the discovery API
specifying "example.com" as the domain name and "_http._tcp" as the
service protocol identifier. The implementation library finds the
service is supported by five points of presence and determines that
the example.com service security policy is to always offer TLS. A TLS
connection is established to an appropriately selected point of
presence consistent with the security credentials specified in the
security policy and delivered to the application programmer.
Offloading the work of establishing the Internet connection from the
application programmer to the implementation library offers agility
as well as simplicity. If a new high performance transport layer
protocol were devised that replaced TCP, every application using the
high level discovery API running on a platform that supported the new
transport layer protocol can make use of it immediately with no
application update required.
The same API would support peer to peer connections in the same
fashion but specifying the account identifiers of the parties
attempting to connect in place of the domain name.
The only precondition for implementing a consistent discovery API is
that the rules of discovery be clearly and precisely specified. The
discovery process might be uniform across all application protocols
or allow for variations to support legacy approaches. For example the
use of MX records rather than SRV records for SMTP service discovery.
It is not even necessary that all the required information be
provided through the DNS provided that the rules for using
information from other sources are precisely specified.
4. Implementation
While this paper proposes a major change to the Internet
architecture, the implementation of this change is surprisingly
simple. This is because the principal change proposed is to recognize
approaches that have been longstanding practice.
The implementation of the Presentation services follows a modular
approach. Each service is implemented as a JSON/REST style Web
service using either HTTPS or a lightweight UDP transport as the
base.
4.1. Connection Broker
SXS-Connect is a JSON-REST Web Service that is used to establish a
connection to a Web Service. As with a DNS SRV record, a service
connection is a logical connection that may comprise connections to
multiple physical hosts. Unlike an SRV connection, the physical hosts
may advertise services that differ in the protocol versions,
Hallam-Baker April 26, 2015 [Page 20]
Internet-Draft An Internet Presentation Level October 2014
features, transport, syntax etc.
Authentication of client and server is supported by means of public
key or one time use credentials. Irregardless of whether the original
connection to the SXS-Connect service was authenticated or not,
communication between the client and the Web service is typically
secured by means of a shared secret that is used to protect the
confidentiality and integrity of every transaction message.
In normal operation a client discovers the SXS-Connect service
through a 'bootstrap discovery' mechanism based on either DHCP or the
DNS. Depending on the type of service provided, bootstrap discovery
might be repeated on a frequent basis (e.g. each time the bootstrap
DNS parameters expire), whenever the service signals a need for
reconfiguration or never.
4.2. Private DNS - Eliminating Legacy DNS restrictions
As shown earlier, one of the biggest obstacles to making effective
use of the DNS as a comprehensive discovery infrastructure are the
limitations of the legacy DNS client-resolver protocol. In particular
the conflicting demands of lowest possible service latency from the
application programmers and the limits of message size and queries
per request imposed by the legacy middlebox infrastructure.
Attempting to sort out the mess on port 53 is pointless. Any proposal
that inherits the legacy DNS UDP port will inevitably inherit the
legacy DNS restrictions as well. But any solution that does not meet
the severe performance criteria demanded of the Web browser
providers, particularly with respect to latency is doomed, as is any
proposal that does not guarantee compatibility with all legacy
network environments.
Private-DNS is a replacement transport for the DNS client-resolver
interface that offers two alternative transports, a new UDP based
transport that is designed to provide optimum performance while being
compatible with roughly 97% of legacy network configurations and a
HTTP transport which is slow but provides the best practical
guarantee of network compatibility. In either case, every message is
encrypted and authenticated and responses securely bound to requests.
Unlike competing proposals based on DTLS, the Private-DNS transport
is designed to support DNS conversations rather than single
transactions. This permits lower latency and more comprehensive
results.
When connecting to a Web site www.example.com, a Web browser today
typically performs queries for A and AAAA records at www.example.com.
In theory, the DNS protocol permits multiple queries per message, in
practice this capability is not viable as a message can only return a
single response and much of the infrastructure does not support it.
Hallam-Baker April 26, 2015 [Page 21]
Internet-Draft An Internet Presentation Level October 2014
The requirement that every query be performed in a separate query
transaction discourages speculative requests for SRV, DANE or other
DNS records that might contain useful information. This in turn
discourages definition of useful record types.
As in the traditional DNS UDP transport, the UDP transport employed
in Private-DNS requires that the request portion of a DNS
conversation fit within a single UDP packet but up to 16 packets may
be returned in a response.
The practical result of this change is that every reasonable DNS
conversation can be realized in a single Private-DNS interaction
without performance penalty. Instead of protocol designers and DNS
administrators constantly having to worry that an overamitious design
would lead to poor performance or protocol failure, it is quite
unlikely that the limits of the transport would be reached
inadvertently.
4.3. OmniQuery - A Presentation Level Discovery Service
Private-DNS provides a low level interface to the DNS system allowing
a network client to implement a Presentation service on the local
machine. But the responses returned by Private-DNS are limited to
those provided by the DNS and as previously noted, the authoritative
answer is not always the one that is desired.
OmniQuery is a Web service that exposes the Presentation level
discovery API as a Web Service.
A client asks 'How can X connect to Y to perform protocol Z' where X
and Y may be Internet accounts or domain names and Z is the name of
an Internet service. The server then returns all the information that
the client might want to know to establish the best connection for
that purpose. In addition to the IP address and port number, a server
might specify the transport to be used (e.g. UDP, TCP, some new
transport) the cryptographic enhancements to be applied (e.g. TLS),
required credentials and any other information that might be needed.
Unlike the traditional DNS discovery infrastructure, OmniQuery allows
both ends of the communication to be specified. The mechanism by
which alice@example.com connects to example.com might be very
different to the mechanism by which other parties connect.
Connections may also be established between peers (e.g.
alice@example.com connects to bob@example.com).
One consequence of this difference in approach is that rather than
accepting service from the closest discovery service, as is typically
the case with DNS, clients select a particular service for OmniQuery
service which is used regardless of client location.
Hallam-Baker April 26, 2015 [Page 22]
Internet-Draft An Internet Presentation Level October 2014
4.4. OmniPublish - A Presentation Level Provisioning Service
One of the principal weaknesses in the current DNS infrastructure is
that while there is a well developed standards based infrastructure
for extracting data from the DNS, there is no similar standards based
infrastructure for entering information. Provisioning services for
other directory infrastructures and PKI are equally unsatisfactory.
OmniPublish provides a high level interface that allows an Internet
host to advertise an Internet Service and to obtain all the necessary
cryptographic credentials to act in that role. In a typical
deployment, an OmniPublish service is connected the DNS service, PKI
and network firewall so that it can perform all the configuration
steps necessary to configure the network to bring up the service.
For example, consider the case that an Internet host is to be
configured to establish a mail service. In the normal approach, the
network administrator would configure the server on the Internet
host, configure the firewall to permit delivery of mail and finally
configure the local DNS settings.
Not only is this approach complex, it is fragile. Any error in the
network configuration is likely to result in an inoperable service.
Network administrators are therefore understandably reluctant to make
unnecessary changes. DNS records and firewall configuration settings
that are not fully understood tend to be left untouched. This makes
manually configured DNS a rather unreliable source of security policy
records. While the records may be authoritative, they are frequently
out of date. Mail abuse filters do not make mail delivery decisions
on DKIM or SPF records without first applying heuristics designed to
limit the impact of stale records.
Generating the network configuration automatically allows the
OmniPublish service to ensure that it is both correct and up to date.
If a major change in network configuration is to be performed, the
OmniPublish service provides a single point of control through which
the change can be administered.
5. Conclusions
Middleboxes have emerged to meet a set of requirements that cannot be
achieved within the traditional Internet model. Middleboxes are
neither the result of ignorance, nor a 'necessary evil'. It is time
to accept that middleboxes serve functions in the Internet
infrastructure that are equally important to those traditionally
recognized.
Describing the Internet model in terms of interfaces rather than
functions and adding a presentation level clarifies the functions of
middleboxes and how those functions might be achieved in ways that do
not compromise functionality in the ways that legacy middleboxes do.
Hallam-Baker April 26, 2015 [Page 23]
Internet-Draft An Internet Presentation Level October 2014
A set of three JSON based Web services are proposed to properly
encapsulate the interaction between the Presentation layer and the
Applications and Transport layers. These are OmniPublish, OmniQuery
and Private DNS, each of which is built on the service connection
protocol SXS-Connect.
6. References
6.1. Normative References
[I-D.hallambaker-privatedns] Hallam-Baker, P, "Private-DNS",
Internet-Draft draft-hallambaker-privatedns-00, 9 May
2014.
[I-D.hallambaker-wsconnect] Hallam-Baker, P, "JSON Service Connect
(JCX) Protocol", Internet-Draft draft-hallambaker-
wsconnect-05, 21 January 2014.
[I-D.hallambaker-omnibroker] Hallam-Baker, P, "OmniBroker Protocol",
Internet-Draft draft-hallambaker-omnibroker-07, 21 January
2014.
[I-D.hallambaker-omnipublish] Hallam-Baker, P, "OmniBroker
Publication Protocol", Internet-Draft draft-hallambaker-
omnipublish-00, 22 May 2014.
6.2. Informative References
[RFC0801] Postel, J., "NCP/TCP transition plan", RFC 801, 1 November
1981.
Author's Address
Phillip Hallam-Baker
Comodo Group Inc.
philliph@comodo.com
Hallam-Baker April 26, 2015 [Page 24]
