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]