Internet DRAFT - draft-hallambaker-domain-centric
draft-hallambaker-domain-centric
Internet Engineering Task Force P. Hallam-Baker
Internet-Draft VeriSign Inc
Intended status: Informational June 30, 2007
Expires: January 1, 2008
Domain Centric Administration
draft-hallambaker-domain-centric-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 1, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
The cost and complexity of network administration is the major
difficulty that must be overcome in order to deploy improved security
and IPv6. Domain Centric Administration defines an approach to
network management in which the DNS acts as the central service
directory.
Hallam-Baker Expires January 1, 2008 [Page 1]
Internet-Draft Domain Centric Administration June 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. The Devil is in the Deployment . . . . . . . . . . . . . . . . 4
3. Why the Traditional Approach Fails . . . . . . . . . . . . . . 4
3.1. Network Administration is Hard . . . . . . . . . . . . . . 5
3.2. Network Administration is Getting Harder . . . . . . . . . 5
3.3. Changes to Deployed Protocols Take a Decade . . . . . . . 6
3.4. Lack of Necessary Abstractions . . . . . . . . . . . . . . 7
3.5. Lack of Control . . . . . . . . . . . . . . . . . . . . . 7
3.6. Lack of Automation . . . . . . . . . . . . . . . . . . . . 8
3.7. Lack of Feedback . . . . . . . . . . . . . . . . . . . . . 8
3.8. Inadequate Abuse Reporting . . . . . . . . . . . . . . . . 9
3.9. Lack of Security . . . . . . . . . . . . . . . . . . . . . 9
4. Requirements for an Administration Model . . . . . . . . . . . 10
4.1. Unified service discovery . . . . . . . . . . . . . . . . 10
4.2. Single configuration description . . . . . . . . . . . . . 11
4.3. Coherent Security Model . . . . . . . . . . . . . . . . . 11
4.4. Alignment of Accountability and Control . . . . . . . . . 12
4.5. Support for Virtual and Physical networks . . . . . . . . 13
5. Domain Centric Administration . . . . . . . . . . . . . . . . 13
5.1. DNS Records . . . . . . . . . . . . . . . . . . . . . . . 14
5.1.1. Service Declaration . . . . . . . . . . . . . . . . . 14
5.1.2. Service Discovery . . . . . . . . . . . . . . . . . . 15
5.1.3. Service Configuration . . . . . . . . . . . . . . . . 15
5.1.4. Additional Response Records . . . . . . . . . . . . . 16
5.2. Mitigating IPv4 Address Scarcity . . . . . . . . . . . . . 16
5.3. Objections . . . . . . . . . . . . . . . . . . . . . . . . 17
5.3.1. Change of control . . . . . . . . . . . . . . . . . . 17
5.3.2. Alternative infrastructure . . . . . . . . . . . . . . 17
6. Service Registration Service . . . . . . . . . . . . . . . . . 18
6.1. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.1.1. Discovery . . . . . . . . . . . . . . . . . . . . . . 19
6.1.2. Protocol . . . . . . . . . . . . . . . . . . . . . . . 19
6.1.3. Example . . . . . . . . . . . . . . . . . . . . . . . 19
6.2. Service Description . . . . . . . . . . . . . . . . . . . 20
6.2.1. Capabilities . . . . . . . . . . . . . . . . . . . . . 20
6.2.2. Dependencies . . . . . . . . . . . . . . . . . . . . . 20
6.2.3. Configuration . . . . . . . . . . . . . . . . . . . . 20
6.2.4. Authentication Data . . . . . . . . . . . . . . . . . 20
7. Example Applications . . . . . . . . . . . . . . . . . . . . . 21
7.1. Configuration of Email Server . . . . . . . . . . . . . . 21
7.1.1. Advertising outbound security policy . . . . . . . . . 22
7.1.2. Advertising inbound security policy . . . . . . . . . 22
7.2. Configuration of Email Client . . . . . . . . . . . . . . 24
7.2.1. Finding incoming and outgoing email services . . . . . 24
7.3. Discovering support for security enhancements . . . . . . 24
Hallam-Baker Expires January 1, 2008 [Page 2]
Internet-Draft Domain Centric Administration June 2007
7.4. Determining authentication requirements . . . . . . . . . 25
7.5. Discovering support for Key Management . . . . . . . . . . 26
7.6. Discovering alternative message transfer facilities . . . 27
8. Configuration of Web Services . . . . . . . . . . . . . . . . 27
9. Automatic Configuration of Network Appliances . . . . . . . . 28
9.1. Printer Joins Network . . . . . . . . . . . . . . . . . . 29
9.2. Storage Joins Network . . . . . . . . . . . . . . . . . . 29
9.3. Router Joins Network . . . . . . . . . . . . . . . . . . . 30
9.4. Wireless Devices . . . . . . . . . . . . . . . . . . . . . 31
10. Peer to Peer Incident Handling . . . . . . . . . . . . . . . . 33
10.1. Contacting Source of Attack by IP Address . . . . . . . . 33
10.2. Mitigating Spoofed Source Address Packets . . . . . . . . 33
11. Further Work . . . . . . . . . . . . . . . . . . . . . . . . . 33
11.1. Maintenance . . . . . . . . . . . . . . . . . . . . . . . 33
11.1.1. Identify cause and location of network faults . . . . 33
12. Security Considerations . . . . . . . . . . . . . . . . . . . 33
12.1. Reliance on Security of the DNS . . . . . . . . . . . . . 34
12.2. Security of DNS Updates . . . . . . . . . . . . . . . . . 34
12.3. Consolidation of Control . . . . . . . . . . . . . . . . . 34
13. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 34
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
16. Normative References . . . . . . . . . . . . . . . . . . . . . 35
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 35
Intellectual Property and Copyright Statements . . . . . . . . . . 36
Hallam-Baker Expires January 1, 2008 [Page 3]
Internet-Draft Domain Centric Administration June 2007
1. Introduction
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. The Devil is in the Deployment
The Internet faces two principal architectural challenges today. The
Internet is not sufficiently secure and the IPv4 address space is
approaching exhaustion. Technical solutions for these problems
exist, but there deployment falls far short of what is necessary.
The cost of the necessary network administration changes is too
great.
It is clear that inn order to address the security problem we must
address the network administration problem. On closer examination it
also becomes clear that the reverse is also the case. Many 'network
administration' steps that today require physical access to a machine
could be performed automatically with an adequate and ubiquitous
authentication infrastructure.
3. Why the Traditional Approach Fails
Network administration is hard and getting harder. As a result the
network is becoming harder to manage and less reliable. Each new
service, each change to the network infrastructure has the potential
for unexpected results. The task of network administration is
rapidly approaching the complexity of programming. At the same time
the expansion in Internet use means that more and more people are
being required to learn network administration skills in order to
manage local networks in their home or small office.
Many professional network administrators see their role as resisting
change that may threaten the stability of the network while home
users are limited to the most basic modes of network use. Even the
simplest extension beyond Web and email such as attempting to make
use of video in an instant messaging application is likely to be a
painful and protracted exercise requiring detailed knowledge that
application providers and ISPs usually fail to provide in a useful
form.
These problems are greatly compounded by the rising problem of
Internet crime. As Willie Horton would put it, the Internet is now
Hallam-Baker Expires January 1, 2008 [Page 4]
Internet-Draft Domain Centric Administration June 2007
'where the money is'. Internet crime is now a professional activity.
The capabilities of organized criminal gangs greatly exceed those of
the 'script kiddies' of earlier times. Ad-hoc network configuration
restrictions imposed in response to this threat quickly become
obstacles which everything else must route around.
3.1. Network Administration is Hard
A communication network may be represented as a graph in which the
nodes are the machines (hosts, routers, etc) that make up the network
and the arcs are the communication media (wires, radio connections,
etc.) by which the machines are linked.
In the traditional network administration model the network is
administered by making changes to individual network nodes. To
install an inbound email server we must configure the machine on
which the email server is to run, the DNS for each of the email
services to be provided and configure the external firewall so that
inbound traffic is directed to the machine.
Each of the three discrete administrative configurations required
requires a different skill set and must be must be entered in a
different format. Inconsistencies between the configurations will
result in the system malfunctioning, possibly in ways that are
difficult to correctly diagnose.
In a large enterprise where responsibility for administration of the
various infrastructures is vested in different organizations the
potential for misconfiguration is greatly magnified.
If network administration is to be simplified we must stop trying to
configure the individual nodes and instead configure the network.
3.2. Network Administration is Getting Harder
The traditional network administration model is already undergoing
change.
In the enterprise deperimeterization represents a process that is
already underway regardless of whether it is desired or not. As
enterprises increasingly integrate their networks with customers
suppliers and partners the distinction between the network and the
inter-network is gradually lost.
Web Services offer the prospect of what Bill Gates has called
'frictionless capitalism'. For legions of clerical workers the daily
toil consists of sifting through sheaves of computer generated orders
and invoices in order to enter the details into another computer. As
Hallam-Baker Expires January 1, 2008 [Page 5]
Internet-Draft Domain Centric Administration June 2007
the scope of Web Services reaches beyond the network perimeter to
connect to customers and suppliers the number of Internet services
rapidly increases from the traditional big three (email, instant
messaging, Web) to the essential hundred or more.
In the home the prospects for network are even more daunting. In the
near future every device that currently comes with an embedded clock
will come with a network connection. It will soon become common for
every light switch and every power outlet in newly built houses to be
network controlled.
The traditional model of network administration: that it is an expert
task that must be left to experts is unsustainable.
3.3. Changes to Deployed Protocols Take a Decade
In the mid 1990s the IETF embarked on three major infrastructure
initiatives: the deployment of IPv6, DNSSEC and secure email. Over a
decade later none of these initiatives has seen production use on a
significant scale.
Making changes to deployed Internet protocols is hard. Making
changes to shared infrastructure is particularly hard. Protocol
upgrades percolate slowly as software is upgraded but the deployment
threshold at which a new feature becomes viable for use is frequently
as high as 90% or more.
Most application protocols make some attempt to support upwards
compatibility but these mechanisms come into play only after the
client has committed to connect to a particular host using a
particular protocol. This approach does not support the type of
parallel deployment strategy that is desirable in the case of major
protocol upgrades. The same host machine must simultaneously support
both the new and the old way of doing things. This makes sense for
minor protocol changes but not for a radical upgrade such as
transitioning from SMTP to a Web Services based protocol to support
unified messaging.
This problem is felt with particular force in the security area. As
long as there is a significant deployed base of insecure applications
attempts to deploy secure infrastructure will always be subject to a
downgrade attack. Signing an occasional email allows the recipient
to determine that a signed message is authentic. Only if it is known
that every authentic email is signed can the recipient identify a
fake.
The common factor in these issues is the lack of a protocol
description layer in the Internet architecture.
Hallam-Baker Expires January 1, 2008 [Page 6]
Internet-Draft Domain Centric Administration June 2007
3.4. Lack of Necessary Abstractions
The Internet signaling infrastructure has evolved to identify servers
and not services.
As its name suggests the Internet hosts file was conceived as a means
of providing consistent mnemonic for a host. The DNS continued this
approach being designed primarily to support the resolution of a host
name to a host IP address.
For services such as TELNET the service is intrinsically bound to the
host. TELNET is a means of executing commands on a remote host. The
FTP and MTP protocols layered on top of and in certain respects into
the TELNET protocol continued this approach.
The limitations of this approach was quickly felt in the deployment
of the World Wide Web. The logical DNS name for the CERN Web server
would have been cern.ch. The limitations of the HTTP and DNS
protocol required the insertion of a host prefix. As a result the
first web server was located at info.cern.ch.
Subsequent deployments of Web servers faced the problem of how people
would discover the location of their Web site. The convention
quickly became established that the Web service for example.com would
be located at www.example.com.
In effect the human users of the Web constructed and applied a
signaling convention that should have been provided by the Internet
infrastructure itself. By the time the DNS SRV record was defined it
was too late.
Administration at the level of hosts rather than services focuses
attention on the minutiae of network administration, minutiae that
are better addressed by machines. Information that could and should
be concentrated in a single infrastructure is dispersed, information
that is implicit in the network configuration that could assist the
network administrators task is inaccessible.
Network administration should be of domains and not machines.
3.5. Lack of Control
The domain name system has a critical role in the network. Whoever
controls the DNS resolution of example.com will absolutely control
the use of all services that are accessed by names within that
domain. This degree of dependency is inescapable, if the Internet is
to provide a unified coherent namespace there can only be one party
that determines the resolution of example.com.
Hallam-Baker Expires January 1, 2008 [Page 7]
Internet-Draft Domain Centric Administration June 2007
If example.com offers an email service or blog hosting service
customers must understand that any brand equity they build up in the
name alice@subdomain.example.com or aliceblog.example.com is
inevitably subject to continued service from example.com. Unless the
rules governing control of the domain are well defined and designed
to enfranchise the individual user (such as is the case for ICANN
regulated domains in top level domains) the brand equity is
effectively subject to the goodwill of the domain name owner.
While dependence on the signaling infrastructure is inescapable if
there is to be a uniform resolution of names to services the current
approach to network administration means that there are additional
dependencies that are escapable. In particular the security of the
resolution service is dependent on both the DNS system and the BGP
system for advertising inter-domain routing. The transfer of email
is effectively regulated by a Byzantine network of opaque, obscure
and unaccountable 'blocklist' operators.
There should be a single point of administrative control
3.6. Lack of Automation
Traditional network administration focuses on the configuration of
hosts to support applications rather than the configuration of the
network to provide a service.
The difference between these approaches is demonstrated by the
configuration of a network service to accept inbound email. For such
a service to be reliable redundant hosts should be supported. Spam
filtering and firewall traversal will require additional hosts.
In the traditional network administration model each host
configuration is independent and discrete. At no point is an
explicit statement made that the service is the sum of the
independent configurations.
Network administration tools should be oriented to the configuration
of services rather than hosts.
3.7. Lack of Feedback
Another problem which this document only partly attempts to address
is the lack of feedback on network status in a form that a user can
make use of.
A statement of the form '45% of inbound packets were dropped' is of
no use to a user unless followed by a statement of the form replace
the cable between the cable modem and the router box'.
Hallam-Baker Expires January 1, 2008 [Page 8]
Internet-Draft Domain Centric Administration June 2007
The Internet has no shortage of network diagnostic tools, the problem
lies in the lack of an overarching network description framework that
would allow the network layer diagnostic information to be integrated
and presented in a useful form.
If the goal of the automated home is to be realized in a form where
every electrical appliance, switch and socket is network enabled
fault diagnosis must be automatic. This problem is no less urgent in
the enterprise space where time spent analyzing network failures
translates directly into costs.
The description of the Network Configuration should assist the
identification and reporting of failures.
3.8. Inadequate Abuse Reporting
The lack of feedback mechanisms is felt with particular force when
dealing with network abuse. A system that depends on sending an
email to abuse.example.com is simply inadequate for a network with a
billion users.
Large ISPs spend millions annually processing abuse reports. As the
abuse reporting mechanism assumes a human mediator each report has a
different structure and format even though the content may be
identical. The use of English is assumed.
The attackers understand these gaps in communication and exploit them
to the full. Every large scale operator of Internet infrastructure
has lists of sites suspected of hosting bots, sites from which large
quantities of attacks have originated. Yet at present there is no
peer to peer mechanism for exchange of this attack data. Most ISPs
would like to be told that their customers may have an infected
machine, but processing emails containing lists of suspect IP
addresses is neither an acceptable nor a practical solution.
Reporting of abuse should be automated.
3.9. Lack of Security
The biggest deficiency in the traditional model for network
administration is the lack of security. The attempt to effect a
transition from the original Internet designed without the benefit of
cryptographic security to a secured network is constantly stymied by
the lack of support in the signaling layer.
Without the knowledge that every single email from example.com is
digitally signed without exception there is no means by which a
recipient of an unsigned email can know if it unsigned but authentic
Hallam-Baker Expires January 1, 2008 [Page 9]
Internet-Draft Domain Centric Administration June 2007
or unsigned because it is fake.
Without the knowledge that the mail server for example.com a lways
offers TLS upgrade the confidentiality of the connection is still
subject to a man in the middle downgrade attack.
The network signaling layer should support the exchange of security
policy.
4. Requirements for an Administration Model
The defect analysis of the current network administration model
provides the requirements for a replacement model capable of
sustaining the next phase of Internet growth.
In a world where every light switch and every light bulb are IP
addressable it is unacceptable to be required to spend as much as a
minute configuring or maintaining each network interface.
4.1. Unified service discovery
Given a communication objective the service discovery infrastructure
finds the means to satisfy it.
For example: if Alice wants to send a video mail message to Bob using
his email address bob@example.com the service discovery layer should
allow Alice's client to determine that example.com supports four
messaging transport protocols and that two of the service deployments
are compatible with the client protocol support.
The service discovery infrastructure should permit discovery of
networking restrictions in the originating and receiving networks.
If a protocol selected is incompatible with the local network policy
this should result in a discovery service error rather than the
packets being silently discarded.
There should be a single architecture to support discovery of
Internet services.
The unified architecture should map a DNS name to an abstract
service.
The unified architecture should provide a mechanism for mapping
the abstract service onto one or more physical servers that
supports the following properties:
Hallam-Baker Expires January 1, 2008 [Page 10]
Internet-Draft Domain Centric Administration June 2007
Fault tolerance.
Protocol matching.
Protocol version and feature matching.
Compliance with inbound and outbound network security policy.
Firewall detection
Navigation of inbound and outbound NAT devices.
4.2. Single configuration description
It should be possible to specify all the information necessary for
configuration of a network service in a single description document.
Much of the complexity of the network configuration problem stems
from the need to configure each network device independently. This
inevitably leads to inconsistencies which in turn lead to avoidable
network failures.
This description should specify the nature of the service to be
provided, the DNS names of the specific hosts to support the service
and the reach of the service.
4.3. Coherent Security Model
There should be a coherent security model which fully supports the
principle of least privilege.
Best current practice in this respect is to patrol the border between
the local network and the Inter-network by means of a security
firewall. As many including the proponents of 'deperimeterization'
have observed the border, should be the first line of defense and not
as frequently happens the last.
In a network that fully realizes the principle of least privilege
each router, hub and network interface becomes a local policy
enforcement point. Such an approach is entirely impractical if each
service deployment requires manual reconfiguration of each device.
Generating the security requirements from the single configuration
description allows for much greater visibility and control than the
Hallam-Baker Expires January 1, 2008 [Page 11]
Internet-Draft Domain Centric Administration June 2007
present ad-hoc approach.
For example a network security administrator may readily enforce a
policy that prohibits running an application client such as a Web
browser or email client on a server that provides an externally
facing Web server. Such a policy effectively insulates the Web
server from some of the most commonly used vectors for trojan
attacks.
Explicit network configuration enables tracking of data related
policy violations. For example a laptop computer should know that it
is a mobile device and should refuse to accept data tagged as being
privacy sensitive such as credit card or social security numbers.
4.4. Alignment of Accountability and Control
The administrative model must establish clear lines of accountability
that are closely aligned to control capability.
The distinction between the network and the inter-network will always
remain an important one for network management. The border between
the network and the inter-network marks the point at which
responsibility and control change.
This distinction between the network and the inter-network is
recursive. At the lowest level a host connects to router serving a
local network which may in turn be part of a wider departmental
network which is in turn part of a corporate network which is in turn
served by an ISP whose network connects to 'the Internet' at one or
more peering points.
A network manager has different responsibilities to their network and
to the inter-network. Within the network the network manager has the
responsibility to keep the network running to the satisfaction of the
network users. In order to achieve this goal the network manager has
a considerable degree of control.
A network manager inevitably has a much lesser degree of control over
the management of the inter-network. The recognition of this fact is
one of the key insights that differentiated the Internet from
competing inter-network proposals.
The network manager has a second responsibility to ensure that the
network she is responsible for does not cause harm to the wider
inter-network.
Hallam-Baker Expires January 1, 2008 [Page 12]
Internet-Draft Domain Centric Administration June 2007
4.5. Support for Virtual and Physical networks
The administrative model must provide a coherent management model for
virtual networks spanning multiple physical networks within the
Internet.
In a traditional Internet configuration the physical network and the
scope of a domain name are coextensive. If an Internet host has a
domain name in the zone mit.edu it is almost certain that it has a
network address in the class A allocation 18.*.*.* and is highly
likely to be situated in Cambridge Massachusetts.
Introduction of the DNS enabled a virtual network model in which
network services are supported at remote co-location facilities and
through outsourced services. It is now usual for enterprises to rely
on third parties to provide the bulk of their networking needs. This
trend is likely to increase as the number of Web Services increase.
The administration model must allow for tools to support
administration of remote servers and outsourced services.
5. Domain Centric Administration
In the domain centric administration model the controller of the DNS
name used for the discovery of a service is considered to be the sole
authoritative source of configuration information for that service.
This design decision is a direct consequence of the requirement for a
single unified administration model. The controller of the DNS name
used for discovery of a service inevitably has a great degree of
control over the administration of the service, including the ability
to deny access to the service. Such denial of access cannot properly
be considered a protocol 'attack' although it may well represent a
breach of a contractual duty.
In the domain centric model the controller of a domain name controls
all aspects of protocol configuration for services within a domain.
For example, existing DNS principles allow the controller of the
domain example.com to specify the IP addresses of the mail servers
receiving mail sent to example.com and the preference order for their
use. In the domain centric model the controller of example.com can
exercise control on outgoing mail as well as incoming and set the
protocol options and the security policy for each.
Using the domain name system as the basic for administration provides
a close match between expected and actual control. The expectation
Hallam-Baker Expires January 1, 2008 [Page 13]
Internet-Draft Domain Centric Administration June 2007
of a typical user is that the owner of an Internet domain name is
responsible for its use. Unfortunately the current Internet
administration mechanisms do not meet this expectation and there is a
divergence between responsibility and control. This has in turn led
to the use of ad-hoc enforcement mechanisms at the IP level which
effectively preclude alternative administration arrangements. While
this 'walled garden' model may be acceptable and often desirable in
an enterprise network this is not the case when an ISP is delivering
a service to consumers.
While the domain centric administration model increases the extent to
which the domain name owner can control use of their name this level
is available to anyone who becomes a domain name owner.
5.1. DNS Records
DNS records are used for service declaration, discovery and
configuration. In order to ensure compatibility with existing legacy
DNS services while supporting the necessary range of administrative
support capabilities such as wildcards the extended prefix mechanism
described below is used.
5.1.1. Service Declaration
Service Declaration records specify the range of protocols that
support a specific service.
The service declaration layer supports protocol agility. Publication
of Web services might be supported by the traditional HTTP protocol
and a binary protocol HTTP-NG. Email transfer might be supported by
SMTP and a generalized messaging protocol based on SOAP.
Service Declaration records are represented as prefixed TXT records.
The following example shows service declarations for email and http
services. Email is supported through three protocols and two Web
protocols are supported:
_email.example.com TXT "t=_email p={smtp esmtp msoap}"
_http.example.com TXT "t=_http p={http http-ng}"
The service declaration layer only states the services that are
supported. Details of the configuration of each service are declared
in the service discovery and configuration records.
Hallam-Baker Expires January 1, 2008 [Page 14]
Internet-Draft Domain Centric Administration June 2007
5.1.2. Service Discovery
The existing SRV record is used for service discovery with the same
semantics for discovered records as specified in RFC 2782.
The extended prefix discovery mechanism described below is used to
support extended prefixing. As there is only one significant
protocol that operates over both tcp/ip and udp/ip the hierarchical
division of prefix labels between tcp and udp protocols is abandoned.
The following example shows SRV records corresponding to support of
the hypothetical HTTP-NG protocol referred to above.
_httpng.example.com SRV httpng1.example.com 80 1 1 1
_httpng.example.com SRV httpng2.example.com 80 1 1 1
5.1.3. Service Configuration
Each service discovery point and each service instance may have a
service configuration record defined. The service discovery point
record provides information regarding the service provision as a
whole while the individual service records provide configuration data
corresponding to individual instances.
Service Configuration records are represented as prefixed TXT
records.
The following example shows the service configuration records
corresponding to the configuration of the hypothetical 'http-ng'
service:
_httpng.example.com TXT "t=_httpng v={1.0-1.2 2.0}"
_httpng.httpng1.example.com TXT "t=_httpng v={1.0-1.2}"
_httpng.httpng1.example.com TXT "t=_httpng v={1.0-1.2 2.0}"
The first service configuration record state that http-ng versions
1.0 through 1.2 and 2.0 are supported. The second record specifies a
server that only supports the earlier version of the protocol, the
second a server that supports both versions.
The ability to specify version support at both the aggregate level
and the individual server level is critical in enabling a managed
orderly transition between protocol versions. In this case a new
server has been brought online to support the new 2.0 version of the
Hallam-Baker Expires January 1, 2008 [Page 15]
Internet-Draft Domain Centric Administration June 2007
protocol and this will run in parallel with the older server that
only supports the previous version until software on the older server
is updated.
5.1.4. Additional Response Records
The use of separate records for declaration, configuration and
configuration allows for backwards compatibility with legacy
infrastructure and avoids the risk of a truncated response but is
less efficient than a scheme in which discovery and configuration are
combined.
Fortunately the DNS provides a means for anticipating the need for
additional information in a request; the additional response section.
An aware DNS server SHOULD provide the service configuration records
most likely to be of use to a requestor as additional records if
space permits.
5.2. Mitigating IPv4 Address Scarcity
The domain centric administration approach mitigates the imminent
problem of IPv4 address exhaustion in three ways:
Greater use of NAT addressing is encouraged
Network reconfiguration is simplified reducing the incentive to
hoard IPv4 addresses
The transition to IPv6 is simplified
The ultimate resolution of the IPv4 address scarcity issue must be
the deployment of IPv6. Even with NAT the pool of IPv4 addresses
will continue to dwindle. Once the remaining pool of addresses falls
below a certain threshold it is likely that speculative pressure will
lead to a rapid rise in the depletion rate.
Such speculative pressures may not be entirely counterproductive. An
organization that has an original Class A allocation may well be
persuaded to relinquish it provided that there is an economic
incentive to do so and cost-effective tools to manage the process of
transition to a smaller space.
The domain centric administration approach encourages a declarative
style of network administration in which the original intent of the
administrator is captured and not merely the specific configuration
changes necessary to realize this intent. This approach allows the
transition from IPv4 networking to mixed IPv4/v6 networking and the
transition from mixed networking to pure IPv6 networking to be
Hallam-Baker Expires January 1, 2008 [Page 16]
Internet-Draft Domain Centric Administration June 2007
managed automatically and without fuss.
5.3. Objections
5.3.1. Change of control
The usual objection made to the domain centric approach is that a
person using a service supported by example.com may have a different
view of security policy or other service options. Bob who receives
email as bob@example.com may wish to use a higher degree of security
than that supported by the controller of the domain name or no
security at all.
Since it is generally agreed that a network operator has the right
(and in certain cases the duty) to require a minimum level of
security the second complaint does not appear to be well founded.
It is somewhat difficult to identify cases where the domain name
controller can force Bob to use a lower degree of security that are
markedly distinct from the ability of the domain name controller to
deny service in its entirety.
The usual objection made to this approach is that a person using a
service supported by example.com may have a different view of
security policy or other service options. Bob who receives email as
bob@example.com may wish to use a higher degree of security than that
supported by the controller of the domain name or no security at all.
Since it is generally agreed that a network operator has the right
(and in certain cases the duty) to require a minimum level of
security the second complaint does not appear to be well founded.
The usual objection made to this approach is that a person using a
service supported by example.com may have a different view of
security policy or other service options. Bob who receives email as
bob@example.com may wish to use a higher degree of security than that
supported by the controller of the domain name or no security at all.
Since it is generally agreed that a network operator has the right
(and in certain cases the duty) to require a minimum level of
security the second complaint does not appear to be well founded.
5.3.2. Alternative infrastructure
Several commentators suggest use of a different infrastructure such
as NIS, LDAP or HTTP. Notably lacking in these proposals is how the
policy discovery process would be performed.
Hallam-Baker Expires January 1, 2008 [Page 17]
Internet-Draft Domain Centric Administration June 2007
It is important to distinguish policy discovery from policy
publication. A mechanism for policy discovery provides the
information necessary to resolve the policy. A policy publication
mechanism provides the policy itself.
The Internet has only one ubiquitous naming infrastructure: the DNS.
Only the DNS can provide an authoritative policy discovery mechanism.
Even if another mechanism such as L DAP or NIS were to be employed
for policy publication the use of the DNS to discover the location of
the authoritative service is inescapable.
Clearly the DNS is a highly constrained infrastructure and the
inclusion of large quantities of policy data in the DNS is
undesirable from both the operations and administration point of
view.
In most cases however the quantity of policy information required is
small and the simplest and most convenient approach is to distribute
the information through the DNS rather than require the involvement
of a separate infrastructure.
In cases where the quantity of data is larger than a DNS query result
will allow (500 bytes) a URL reference to a policy document stored
separately or an SRV record advertising a separate service is more
appropriate.
6. Service Registration Service
Although the DNS provides an appropriate infrastructure for service
advertisement and discovery it is not a satisfactory platform for
entering configuration.
Instead we prefer to ensure that configuration data is wherever
possible entered automatically with the minimum amount of operator
intervention and in cases where operator intervention is required to
distinguish the capabilities of the device itself from options
configured on the device.
The service registration service allows a device or service
connecting to a network to advertise the capabilities that it
supports. The SRS service may in turn notify other network discovery
infrastructures supported locally such as NIS, LDAP and of course the
DNS itself.
Hallam-Baker Expires January 1, 2008 [Page 18]
Internet-Draft Domain Centric Administration June 2007
6.1. Protocol
6.1.1. Discovery
A device or service attaching to a network discovers the local SRS
service by performing an SRV lookup on the domain name advertised
when the device connects to the network
6.1.2. Protocol
Service Registration Service (SRS) is a Web Service that supports the
following operations:
Register
The register operation is used to register a service and to specify
the capabilities the device offers to the network
Cancel
The cancel operation is used to cancel an existing registration.
Either operation may be performed by either the service to which the
description refers or by a proxy.
Once accepted a service registration has a 'lease' that will expire
after a specified time unless renewed. Alternatively this lease may
be tied to the lifetime of the DHCP lease for the network connection.
6.1.3. Example
A printer connects to a LAN. DHCP is used to obtain a local IP
address (10.1.2.3) and the local domain address (net1.example.com).
The printer then discovers the location of the local SRS service
(srs1.example.com) by attempting to resolve the SRV record for
_srs.net1.example.com.
Having discovered the local SRS service the device uploads the signed
device description file embedded in the device during manufacture.
The SRS service determines whether the device is authorized to
advertise these services and if so enters the relevant service
descriptions into the DNS, LDAP, NIS and other directory
infrastructure as is appropriate to the services offered and the
permissions granted.
Hallam-Baker Expires January 1, 2008 [Page 19]
Internet-Draft Domain Centric Administration June 2007
6.2. Service Description
The device description specifies the network services offered by the
device or service.
6.2.1. Capabilities
The Capabilities section specifies the capabilities offered by the
device and the protocols by which they may be accessed.
For example a printer might be capable of printing in black and white
from paper stock in one of two trays, support the lpr protocol for
accepting print requests, the SNMP protocol for management and the
PCL6 and Postscript page description language.
6.2.2. Dependencies
The dependencies section allows a service to specify the services on
which it depends. Such dependencies may be marked critical or non-
critical depending on whether the availability of the service will
prevent functioning of the device.
Most network devices would have a critical dependence on the DHCP
service and some devices such as a SIP phone would require the
ability to advertise port addresses visible to the external network.
Network devices that make use of a clock should make use of the local
NTP service for synchronization if one is available.
6.2.3. Configuration
The Configuration section specifies the specific options that are
configured for the device. For example a multi-function device
supporting use as a printer, scanner or fax may not be connected to a
telephone line and so the fax capability may not be available.
6.2.4. Authentication Data
Each SRS request should be authenticated by means of a PKI based
protocol.
In the case of a device the most straightforward approach is to
generate a public key pair and a digital certificate binding the
public key to the device identifier during manufacture. In the case
of a network device the device identifier would normally be the MAC
address of the device or an EUI-48 or EUI-64 identifier.
Hallam-Baker Expires January 1, 2008 [Page 20]
Internet-Draft Domain Centric Administration June 2007
7. Example Applications
The objective of Domain centric administration is to unify and
wherever possible automate the process of network administration. As
a general rule a human should only be involved in the network
administration when there is a choice to be made and wherever
possible that choice should be reduced to a small number of discrete
options.
7.1. Configuration of Email Server
Despite many attempts to add cryptographic security to email only one
email security protocol has achieved ubiquitous deployment and none
has achieved ubiquitous use. Deployment of SSL on the other hand has
been a major success and a clear majority of Web transactions that
might require security enhancements are secured with SSL.
The principal architectural difference between SSL and the email
security protocols is that SSL is applied at the domain level while
PEM, MOSS, PGP and S/MIME all require participation by individual end
users. While 'end-to-end' security offers certain advantages over
domain level security the cost of deploying and managing a
cryptographic key for every Internet user is inevitably much higher
than the cost of maintaining one public key pair per email server.
This experience suggests that applying email security at the domain
level is much more likely to succeed than the exclusive promotion of
end to end security as the sole acceptable solution. As is discussed
later these approaches are not mutually exclusive, while the perfect
has been the enemy of the good in the case of email security the good
can provide a stepping stone towards the better.
Email is an asynchronous protocol. As email messages are frequently
routed through mail relays the originator and the ultimate receiver
of an email do not necessarily ever communicate directly. In modern
email infrastructures this situation is now the rare exception rather
than the rule.
The lack of a direct interaction between the originator and the
receiver of the message precludes the type of security negotiation
that takes place in other security protocols such as SSL. The
originator must generate a message that the ultimate recipient is
likely to be able to accept and use. As a result originators must
continue to be conservative in what they send since they cannot rely
on recipients to meet contemporary expectations of what they should
accept.
Hallam-Baker Expires January 1, 2008 [Page 21]
Internet-Draft Domain Centric Administration June 2007
7.1.1. Advertising outbound security policy
The principle challenge that has faced email operators in recent
years is spam. In particular spam that impersonates another party
may make unauthorized use of the good reputation of a legitimate
sender.
The key to dealing with the problem of spam is accountability. Once
email senders have the ability to accept responsibility for their
actual emails sent receivers can judge senders on their past
behavior, their reputation and the extent to which they have
demonstrated that they can be held accountable.
For accountability to work it is equally important to know when an
email sender denies responsibility for a message as when they accept
responsibility. It is therefore necessary for the receiver to know
that a sender will always authenticate their outgoing mail.
Various proposals have been made to address this need of which SPF/
Sender-ID and DKIM are the best known. In each case the
authentication mechanism provides a means by which the sender can
inform recipients that they should expect messages to be
authenticated.
7.1.2. Advertising inbound security policy
Outbound security policy allows the recipient to know if a message
should carry authentication and thus avoid a downgrade attack.
Inbound security policy provides the complimentary capability for
confidentiality.
As previously noted many email confidentiality schemes have been
proposed but these have not been widely used. A key defect in all
these efforts to date has been the failure to consider the
requirement for security policy and key distribution. The OpenPGP
and S/MIME specifications both take as their starting point the case
where the sender has available the public key certificate or key
signing of the recipient. Although certain commercial products have
recognized this gap and provided their own solutions this approach
must become a widely supported standard if it is to be of value.
Email confidentiality may be achieved at two distinct levels:
At the level of individual users (end-to-end security)
At the domain level (edge-to-edge security)
End to end security in the tradition of PEM, PGP and S/MIME offers a
Hallam-Baker Expires January 1, 2008 [Page 22]
Internet-Draft Domain Centric Administration June 2007
high level of security at the cost of being required to manage and
distribute keys to every user. Domain level security such as DKIM,
the SMTP STARTTLS extension and S/MIME for domains offers a high
level of security with considerably greater flexibility at a much
more modest cost.
Regardless of whether security is applied at the domain level, the
user level or both a policy and key distribution mechanism must be
provided to answer two essential questions:
Does the intended recipient of this email message support a
compatible encryption protocol?
If so what public key should be used to send the message to the
intended recipient?
Answering these questions at the domain level through a domain level
policy statement allows the distinction between user level and domain
level security to be eliminated as far as the sender is concerned.
The message is encrypted to an encryption key specified by the
domain, it is for the domain controller to decide whether to offer
encryption at the domain or user level.
This approach offers considerably greater flexibility which is a
necessity in many modern enterprise messaging systems. In the era in
which PEM was designed email messages passed almost exclusively
between desktop terminals and personal computers. Today users expect
the ability to receive email messages on pagers, phones and at any
desktop or laptop computer they happen to be using at the time.
Users are not willing to accept an end to end encryption system if it
prevents them accessing their mail on the machine of their choice.
The mail service advertises that it always offers the STARTTLS and
S/MIME security enhancements for inbound mail and that keys may be
obtained through DNS resource records for SSL or XKMS for S/MIME
_inbound._smtp._tcp.example.com TXT
("ALWAYS={STARTTLS, KEYSERVER={DNSRR}}"
"ALWAYS=S/MIME KEYSERVER={XKMS}")
Each mail server specifies its own key resource record in the same
format as for DKIM.
This approach is fully compatible with existing practice for
configuration of email servers but protects communication from a man
in the middle downgrade attack provided that the DNS itself is
Hallam-Baker Expires January 1, 2008 [Page 23]
Internet-Draft Domain Centric Administration June 2007
trustworthy (e.g. through use of DNSSEC).
7.2. Configuration of Email Client
Configuration of email clients today is unnecessarily complex. The
user is required to discover arcane details that should remain
'beneath the hood' such as the server name and port number of their
incoming and outgoing email services.
The only information a user should need to know in order to configure
an email client is their email address and whatever information might
be required for authentication.
For example: Alice has the email address 'alice@example.com' and she
authenticates herself to the mail service using her password '1234'.
If Alice is asked for any information other than her email address
and password this should be considered an unacceptable failure of the
configuration mechanism.
7.2.1. Finding incoming and outgoing email services
Standard SRV discovery is used to locate the POP3, IMAP4 and SUBMIT
services:
_pop3._tcp.example.com SRV 1 100 110 inbound.example.com
_imap._tcp.example.com SRV 1 100 143 inbound.example.com
_submit._tcp.example.com SRV 1 100 773 outbound.example.com
7.3. Discovering support for security enhancements
We would much prefer to connect to the mail services using a protocol
that provides confidentiality and integrity services. This is the
case even if an end to end security solution such as PGP or S/MIME is
employed since information that must be present in the email headers
such as the sender and recipient addresses may reveal important
information to an attacker.
The POP3 and IMAP4 protocols use a separate TCP port for service over
SSL and so we would advertise service for the POP3S and IMAPS
protocols instead:
_pop3s._tcp.example.com SRV 1 100 995 inbound.example.com
_imaps._tcp.example.com SRV 1 100 993 inbound.example.com
Hallam-Baker Expires January 1, 2008 [Page 24]
Internet-Draft Domain Centric Administration June 2007
The SUBMIT protocol does not require a separate port for use with SSL
as the SMTP protocol of which SUBMIT is a variation supports the
STARTTLS service.
In either case the client connecting to the service requires an
authoritative statement of the security enhancements supported by the
service. This is provided by a security policy record:
_spss._pop3s._tcp.example.com TXT "KEY=_key.example.com"
_spss._imaps._tcp.example.com TXT "KEY=_key.example.com"
_spss._submit._tcp.example.com TXT "STARTTLS KEY=_key.example.com"
_key.example.com TXT "alg=RSA value=..."
Note that the security policy does not specify the public key to be
used by the server directly. Instead the policy record specifies a
location where the key description can be found. This allows
multiple services to make use of a single key record.
The key record might specify the public key directly or since SSL is
a PKI based protocol specify an X509v3 certificate to be used as a
trust anchor.
7.4. Determining authentication requirements
Having discovered the inbound and outbound email servers the next
step for the client is to determine the authentication mechanism(s)
and protocol(s) that are required in order to gain access. While
username and password is likely to remain the lowest common
denominator for this purpose for some time to come the policy layer
allows the email client to discover the existence of stronger
authentication schemes:
_options._pop3s._tcp.example.com TXT "auth=password,digest"
In this example the POP3 server offers exchange of plaintext
passwords or use of the digest mechanism. While exchange of password
data en-clair is a security risk it is acceptable in this case
because the transport is encrypted.
Alternative authentication mechanisms that might have been offered
include PKI based authentication, or a connection to a distributed
authentication mechanism such as RADIUS, SAML, or OpenID.
Hallam-Baker Expires January 1, 2008 [Page 25]
Internet-Draft Domain Centric Administration June 2007
7.5. Discovering support for Key Management
Having established a secure context for exchange of messages with the
mail servers we may want to go further and establish full end-to-end
cryptographic security.
While domain level security is valuable and easy to deploy precisely
because it is transparent to the end user it is necessarily limited
for the same reason. In particular there are cases where an email
client must know whether an email can be sent using a mechanism that
provides sufficient confidentiality protection.
The problem with achieving end-to-end security is that the ends of
the communication are not necessarily the same as the ends of the
trust relationship. If Alice is acting on her own behalf then her
email client can manage both sets of concern. If Alice is working
for a government agency, a financial institution or other enterprise
it is the enterprise that is the 'end' of the trust relationship and
the protocols should recognize this fact.
XML Key Management Service (XKMS) is a key centric PKI protocol which
is designed to support this mode of management. An XKMS server
exposes the key management services necessary to support a PKI based
application as a service. PKI is inescapably complex because the
problems that PKI addresses are complex. It follows that attempting
to eliminate complexity from a PKI architecture altogether is a
misguided approach that is unlikely to succeed. XKMS does not
attempt to eliminate complexity, instead it allows the network
manager to control where that complexity is placed and managed.
Complexity that is exposed in a client is very had to manage as any
change to the code must be deployed to every end client. Complexity
that is exposed through a service is much easier to manage as the
service is a single point of control.
The XKMS Key Information Service Specification (XKISS) allows a
client to locate a key that may be used to secure a communication
with a specified party using a specified protocol. The XKMS Key
Registration protocol allows a client to register a public key.
The XKMS specification defines SRV prefixes for discovery of XKMS key
information and registration services:
_XKMS_XKISS_SOAP_HTTP SRV 100 100 80 xkms.example.com
_XKMS_XKRSS_SOAP_HTTP SRV 100 100 80 xkrss.example.com
The domain centric administration approach allows additional policy
Hallam-Baker Expires January 1, 2008 [Page 26]
Internet-Draft Domain Centric Administration June 2007
statements to be made to provide additional configuration information
to assist configuration of clients:
The public key used to authenticate XKMS transactions
The security and protocol policy options of the XKMS service
Distinguish between XKISS services that provide only Locate
services from those offering Locate and Validate services.
Identify the necessary authentication context.
The combination of these services allows confidentiality to be
applied on a 'promiscuous' basis. That is the sender will always
send a message using the best encryption service that is offered.
In this scheme the only times where the user need be aware of the use
of encryption is in cases where the default 'promiscuous' encryption
must be overridden. For example requiring a message to be sent en-
clair or requiring the message to be sent encrypted.
Requiring confidentiality protection is the more likely case. A user
interface might allow the user to specify that individual messages
should be sent with confidentiality protection or mark individual
users, companies or types of company for which confidentiality
protection should be specified by default. For example a lawyer
might have an email client configuration that requires all messages
sent to other lawyers and to clients to be marked confidential and
sent encrypted.
7.6. Discovering alternative message transfer facilities
In some cases the email client may be unable to discover a supported
cryptographic enhancement to SMTP. The recipient may not support an
acceptable security protocol or may fail to provide a public key that
the sender considers to be sufficiently trustworthy.
In such cases the message might be sent by an alternative transport,
possibly an email message containing a URL of an SSL secured Web site
from which the message may be retrieved securely. Alternatively a
Web service might accept a message and forward it by facsimile or
even cause the message to be printed out and sent by letter post or
courier service.
8. Configuration of Web Services
Configuration of a Web Service, whether layered on SOAP or basic HTTP
Hallam-Baker Expires January 1, 2008 [Page 27]
Internet-Draft Domain Centric Administration June 2007
would follow the same principles as for email with the proviso that
the Web Services stack provides for a policy layer WS-Policy offering
a rich array of policy options. The principle limitation of WS-
Policy is that to make best use of it the protocol described should
be a SOAP based Web Service layered on the WS-*.
The Domain Centric approach is not intended to rival WS-Policy.
Rather the domain centric approach is proposed as the means of
discovering a WS-Policy statement should it exist.
While the WS-* stack is undoubtedly the preferred approach to
developing standards based Web Services, much of the innovation in
the field is currently taking place in rapidly developed prototypes
layered directly on HTTP that serve to support 'mashups' developed by
a wide range of developers. Over time some of these prototypes will
merge and coalesce into more widely supported protocols, in most
cases based on the standards based WS-* stack. A transition strategy
from prototypes to standards based services is thus essential to the
success of the WS-* approach.
Rather than develop individual WS-Policy profiles for each prototype
specification it makes better sense to employ the lightweight policy
distribution mechanism to specify the range of Web Services supported
and reserve the use of WS-Policy for detailed description of Web
Services based on WS-*.
9. Automatic Configuration of Network Appliances
One of the principal tasks that network managers, whether in the
enterprise or the home are required to perform is to install and
configure new devices. Most peripherals that connect to a personal
computer directly already support automatic configuration using
mechanisms such as 'plug and play'. This is not yet the case for
network attached peripherals such as printers, storage, cameras and
the networking infrastructure itself.
DHCP provides a degree of automatic configuration but is limited by
the assumption that the peripherals share the same logical IP sub-
network and the supported options for service discovery are limited.
It should be possible to attach network attached storage anywhere on
the Internet with the same ease, reliability and security as storage
attached to the local network. No modification of DHCP can possibly
meet this need and therefore DHCP is not the appropriate technology.
Configuration of wireless devices requires the configuration of the
wireless network connection in addition to the device itself.
Hallam-Baker Expires January 1, 2008 [Page 28]
Internet-Draft Domain Centric Administration June 2007
Although this is an important problem the mechanisms that might solve
it are necessarily outside the scope of this particular paper and so
a proof of concept only is provided at the end of this section.
The Domain Centric approach is similar to that adopted in Universal
Plug and Play with the key difference that the DNS is used to enable
discovery as opposed to IP multicast. While IP multicast is a viable
technology within the local area network it has failed to demonstrate
viability as an inter-networking protocol despite many years of
effort. While multicast may be regarded as a simple solution,
analogous to multicast within the local area network the use of
multicast in the inter-network is inescapably complex. Use of
multicast as a means of discovering services within the same logical
network that are deployed at a remote physical location incurs a
considerably greater degree of complexity than the domain centric
approach.
9.1. Printer Joins Network
A printer accepts instructions in one or more page description
formats and produces hardcopy output. This process may be controlled
by a number of option settings to determine choices such as the
output resolution, the size of the paper stock, tray to be used etc.
In order for the user to have the necessary degree of control over
the process the printer should provide potentially useful information
such as supported paper sizes, the current status of the paper stock,
toner level, etc. In a large network it may be useful to know the
physical location of the printer, the building, part of building etc.
Traditionally the user is required to install a device driver for
each model of each printer in the network. This process is both
tedious and unnecessary. The printer knows what model it is and the
capabilities it offers. Installation of a device driver should be
the exception, not the rule.
When the printer joins the network it advertises its configuration
and capabilities using SRS. The SRS service then updates the local
directory service to announce the availability of the printer.
9.2. Storage Joins Network
The rate at which modern disk drives offer increased storage capacity
is matched only by the speed with which demand for that capacity
grows. Digital photography and low cost digital video editing allow
individual home users to consume hundreds of gigabytes of storage
each year. In the enterprise rich document formats and in particular
the repeated exchange of digital documents through email creates
Hallam-Baker Expires January 1, 2008 [Page 29]
Internet-Draft Domain Centric Administration June 2007
similar increasing demand.
Storage capacity is now a commodity. Managed storage: media that is
reliably backed up, indexed and catalogued so that the stored data is
actually usable, remains expensive and administration intensive.
Network Attached Storage (NAS) addresses some of the problems of
storage management. NAS is essentially a dedicated file server
appliance combining one or more hard drives with a CPU. A NAS server
is exposed at the operating system level as a file store attached to
a host device.
If there is only a single file store in the network this model works
well. If many file stores are in use finding the file server where
the data needed is stored is frequently a time consuming task.
As far as the user is concerned the physical storage location of the
data is irrelevant provided that the system ensures that the
necessary performance, reliability and backup criteria are achieved.
The traditional file server model of all currently popular operating
systems is clearly insufficiently abstracted from the user point of
view.
It should be sufficient for the network administrator to buy a
storage appliance, plug it into the network and for the network to
discover that the additional storage is now available and make it
available for use in accordance with pre-existing policies. Adding
storage to a network should require no more thought or consideration
than putting fuel in a car: when the fuel gauge shows that the supply
is nearing exhaustion the operator adds more.
When a new storage device is connected to a network it first attempts
to find a distributed storage service on the network. If a storage
service is found the device reports the additional capacity available
and the performance and reliability characteristics supported. If no
distributed storage service is found the device registers to provide
one using SRS.
9.3. Router Joins Network
Router devices collect packets on one interface and ship them to
another interface. Why is installation any more complex than
plugging the device in and connecting the necessary wires?
Today routers, hubs and bridges are considered to be separate classes
of network device, yet each performs essentially the same function
and in many cases the same hardware platform is used. The
distinction between these device classes is now historical and so for
Hallam-Baker Expires January 1, 2008 [Page 30]
Internet-Draft Domain Centric Administration June 2007
clarity the term router is used for all three.
As security in depth is taken seriously and border firewalls are
considered the first line of defense rather than is at present the
case the last, every router within the network will become a policy
enforcement point. Packets will only be routed if the network
security policy permits. The default configuration of the network
shall be to deny what is not explicitly permitted.
Configuration of a router device requires two levels of connectivity.
First the router must achieve connectivity at the network layer and
obtain one or more IP addresses. Secondly the router must connect at
the logical level and determine the function that it is to perform
within the network.
Today only the first of these steps is supported. Logical
configuration is the task of the administrator. Yet all the
information that is necessary to configure the network is available
within the network itself. This information may be collected by one
or more network description services discoverable through extended
DNS service discovery and maintained using existing protocols such as
SNMP.
When a router device connects to a network it first performs network
layer configuration via DHCP. The device then performs discovery for
SRS services on each interface on which DHCP succeeds and registers
its device description information, including the ability to accept
ARP, BGP or other routing protocol commands.
9.4. Wireless Devices
The power and simplicity of DHCP is due in large measure to the fact
that when a device attaches to a wired network such as Ethernet the
physical network connection maps unambiguously to a single logical
network.
This situation does not apply in the case of a wireless network. At
any one time there may be between zero, one or many wireless networks
available. Moreover a typical mobile device connects to many
different networks as it shuffles between meeting rooms, home, coffee
shops, airports and hotels.
Connection of a wireless device to a network requires two separate
access control steps. The device must establish that it is joining
the right network; the network must determine that the device is
permitted to join.
Simplification of the network access mechanism is highly desirable
Hallam-Baker Expires January 1, 2008 [Page 31]
Internet-Draft Domain Centric Administration June 2007
but oversimplification can lead to a lack of mutual authentication
capability. The security offered by Bluetooth's 'device pairing'
mode is neither convincing nor user friendly. It is now common for
Bluetooth devices to dispense with the device authentication code
intended to provide a measure of security and use the password '0000'
for every device.
In the case of a laptop seeking Internet access in a hotel or coffee
shop the laptop is not so much concerned as to which network it
connects to as whether the network connection is reliable, secure and
offers adequate signal strength. The network provider on the other
hand may want the ability to restrict access capability in certain
ways such as only offering free service to customers or guests. In
some cases the network provider may require payment.
Access control requirements of this type, where there is a potential
choice between networks and a rich scope for user interaction are
outside the scope of this document. Of more direct concern is the
case of connecting devices such as network attached storage, printers
and routers, devices whose function requires a minimal user
interface.
While a device that does not support a keyboard or display can
nevertheless expose a rich user interface through an embedded Web
Server, such services have no functionality until basic network
functionality is achieved. Configuration of such devices today
typically requires connection to a host that is temporarily
configured to use a compatible network IP subnet. Product reviews of
devices that require this mode of configuration written by consumers
demonstrates that this approach is beyond the typical user's
tolerance level.
A better approach to the configuration of wireless devices is to
install necessary configuration data on a mobile storage device such
as a USB flash memory device. Such a device could be manufactured at
minimal cost and supplied with the network access point. A device
that offered the ability to perform public key authentication would
offer additional security benefits. As the device would be a
standardized commodity additional devices would be readily obtainable
from the usual range of suppliers.
In order to configure a device for use with their wireless network
the network installer would first 'prime' the storage device by
plugging it into the receptacle on the principle access point. The
access point would then transfer all the information necessary to
connect a new device to the network.
In order to connect a device to the network the network installer
Hallam-Baker Expires January 1, 2008 [Page 32]
Internet-Draft Domain Centric Administration June 2007
would place the storage device in the corresponding receptacle on the
device being installed. The device would then obtain all the
information necessary to connect to the correct wireless network
including authentication.
Once connected the new device would advertise the services it
provides and requires to the network using SRS as described in the
previous examples. Depending on the site security policy these
services might become available immediately or require authorization
by an administrator.
10. Peer to Peer Incident Handling
Earlier we saw that the service discovery mechanism could be extended
to allow lookup by IP address rather than domain name alone by using
the Reverse DNS. While domain names are clearly the preferred
mechanism for discovery of primary services it is frequently
desirable to report exceptions on the basis of IP Address.
10.1. Contacting Source of Attack by IP Address
10.2. Mitigating Spoofed Source Address Packets
11. Further Work
11.1. Maintenance
11.1.1. Identify cause and location of network faults
The current proposal is designed to simplify the problem of network
configuration, in particular the commissioning and removal of new
network devices and services. Another principal concern of network
managers is locating and responding to faults caused by
malfunctioning devices, broken cables or interference.
The tools described in this document provide a means of collecting an
maintaining a high level description of the expected configuration
and it is thus to be hoped that the task of identifying discrepancies
between the expected and actual configurations is simplified.
12. Security Considerations
The security considerations described in this section are summaries
of the architectural issues raised elsewhere in the document.
Whenever the domain centric architecture is applied to a specific
Hallam-Baker Expires January 1, 2008 [Page 33]
Internet-Draft Domain Centric Administration June 2007
Internet protocol a full security analysis and review MUST be
performed.
12.1. Reliance on Security of the DNS
The Domain Centric model relies on the DNS as the principle point of
control and administration of the network. The use of DNSSEC to
secure the DNS system SHOULD be considered an operational necessity.
12.2. Security of DNS Updates
The Domain Centric Model increases reliance on the mechanisms used to
feed data into the DNS. Whether this is achieved directly through
DNS zone transfer or indirectly through a mechanism such as LDAP or
the Service Registration Service described above all updates must be
authenticated and subject to control by the site authorization
policy.
12.3. Consolidation of Control
The Domain Centric model increases the control exerted by the
controller of the domain name. In the domain centric model the only
choice for a user who does not control their own domain name
configuration is to obtain their own domain name that they can
control themselves.
13. Conclusions
Domain Centric administration is an incremental evolution of
traditional network management practices that allows network
management to be simplified and automated. While the principles
described are applicable to any network protocol it is most likely
that initial deployment would be seen in the field of Web Services
where the current problem faced by the field is the management of
large numbers of protocols that are each undergoing rapid evolution.
14. Acknowledgements
The ideas in this document arose from extensive discussions with the
DKIM amd DNSEXT working groups.
15. IANA Considerations
This document requires no IANA actions.
Hallam-Baker Expires January 1, 2008 [Page 34]
Internet-Draft Domain Centric Administration June 2007
16. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Author's Address
Phillip Hallam-Baker
VeriSign Inc
Email: pbaker@verisign.com
Hallam-Baker Expires January 1, 2008 [Page 35]
Internet-Draft Domain Centric Administration June 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Hallam-Baker Expires January 1, 2008 [Page 36]
