idnits 2.17.1 draft-hallambaker-domain-centric-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1591. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1602. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1609. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1615. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 30, 2007) is 6139 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force P. Hallam-Baker 3 Internet-Draft VeriSign Inc 4 Intended status: Informational June 30, 2007 5 Expires: January 1, 2008 7 Domain Centric Administration 8 draft-hallambaker-domain-centric-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 1, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 The cost and complexity of network administration is the major 42 difficulty that must be overcome in order to deploy improved security 43 and IPv6. Domain Centric Administration defines an approach to 44 network management in which the DNS acts as the central service 45 directory. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 51 2. The Devil is in the Deployment . . . . . . . . . . . . . . . . 4 52 3. Why the Traditional Approach Fails . . . . . . . . . . . . . . 4 53 3.1. Network Administration is Hard . . . . . . . . . . . . . . 5 54 3.2. Network Administration is Getting Harder . . . . . . . . . 5 55 3.3. Changes to Deployed Protocols Take a Decade . . . . . . . 6 56 3.4. Lack of Necessary Abstractions . . . . . . . . . . . . . . 7 57 3.5. Lack of Control . . . . . . . . . . . . . . . . . . . . . 7 58 3.6. Lack of Automation . . . . . . . . . . . . . . . . . . . . 8 59 3.7. Lack of Feedback . . . . . . . . . . . . . . . . . . . . . 8 60 3.8. Inadequate Abuse Reporting . . . . . . . . . . . . . . . . 9 61 3.9. Lack of Security . . . . . . . . . . . . . . . . . . . . . 9 62 4. Requirements for an Administration Model . . . . . . . . . . . 10 63 4.1. Unified service discovery . . . . . . . . . . . . . . . . 10 64 4.2. Single configuration description . . . . . . . . . . . . . 11 65 4.3. Coherent Security Model . . . . . . . . . . . . . . . . . 11 66 4.4. Alignment of Accountability and Control . . . . . . . . . 12 67 4.5. Support for Virtual and Physical networks . . . . . . . . 13 68 5. Domain Centric Administration . . . . . . . . . . . . . . . . 13 69 5.1. DNS Records . . . . . . . . . . . . . . . . . . . . . . . 14 70 5.1.1. Service Declaration . . . . . . . . . . . . . . . . . 14 71 5.1.2. Service Discovery . . . . . . . . . . . . . . . . . . 15 72 5.1.3. Service Configuration . . . . . . . . . . . . . . . . 15 73 5.1.4. Additional Response Records . . . . . . . . . . . . . 16 74 5.2. Mitigating IPv4 Address Scarcity . . . . . . . . . . . . . 16 75 5.3. Objections . . . . . . . . . . . . . . . . . . . . . . . . 17 76 5.3.1. Change of control . . . . . . . . . . . . . . . . . . 17 77 5.3.2. Alternative infrastructure . . . . . . . . . . . . . . 17 78 6. Service Registration Service . . . . . . . . . . . . . . . . . 18 79 6.1. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 19 80 6.1.1. Discovery . . . . . . . . . . . . . . . . . . . . . . 19 81 6.1.2. Protocol . . . . . . . . . . . . . . . . . . . . . . . 19 82 6.1.3. Example . . . . . . . . . . . . . . . . . . . . . . . 19 83 6.2. Service Description . . . . . . . . . . . . . . . . . . . 20 84 6.2.1. Capabilities . . . . . . . . . . . . . . . . . . . . . 20 85 6.2.2. Dependencies . . . . . . . . . . . . . . . . . . . . . 20 86 6.2.3. Configuration . . . . . . . . . . . . . . . . . . . . 20 87 6.2.4. Authentication Data . . . . . . . . . . . . . . . . . 20 88 7. Example Applications . . . . . . . . . . . . . . . . . . . . . 21 89 7.1. Configuration of Email Server . . . . . . . . . . . . . . 21 90 7.1.1. Advertising outbound security policy . . . . . . . . . 22 91 7.1.2. Advertising inbound security policy . . . . . . . . . 22 92 7.2. Configuration of Email Client . . . . . . . . . . . . . . 24 93 7.2.1. Finding incoming and outgoing email services . . . . . 24 94 7.3. Discovering support for security enhancements . . . . . . 24 95 7.4. Determining authentication requirements . . . . . . . . . 25 96 7.5. Discovering support for Key Management . . . . . . . . . . 26 97 7.6. Discovering alternative message transfer facilities . . . 27 98 8. Configuration of Web Services . . . . . . . . . . . . . . . . 27 99 9. Automatic Configuration of Network Appliances . . . . . . . . 28 100 9.1. Printer Joins Network . . . . . . . . . . . . . . . . . . 29 101 9.2. Storage Joins Network . . . . . . . . . . . . . . . . . . 29 102 9.3. Router Joins Network . . . . . . . . . . . . . . . . . . . 30 103 9.4. Wireless Devices . . . . . . . . . . . . . . . . . . . . . 31 104 10. Peer to Peer Incident Handling . . . . . . . . . . . . . . . . 33 105 10.1. Contacting Source of Attack by IP Address . . . . . . . . 33 106 10.2. Mitigating Spoofed Source Address Packets . . . . . . . . 33 107 11. Further Work . . . . . . . . . . . . . . . . . . . . . . . . . 33 108 11.1. Maintenance . . . . . . . . . . . . . . . . . . . . . . . 33 109 11.1.1. Identify cause and location of network faults . . . . 33 110 12. Security Considerations . . . . . . . . . . . . . . . . . . . 33 111 12.1. Reliance on Security of the DNS . . . . . . . . . . . . . 34 112 12.2. Security of DNS Updates . . . . . . . . . . . . . . . . . 34 113 12.3. Consolidation of Control . . . . . . . . . . . . . . . . . 34 114 13. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 34 115 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 116 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 117 16. Normative References . . . . . . . . . . . . . . . . . . . . . 35 118 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 35 119 Intellectual Property and Copyright Statements . . . . . . . . . . 36 121 1. Introduction 123 1.1. Requirements Language 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119 [RFC2119]. 129 2. The Devil is in the Deployment 131 The Internet faces two principal architectural challenges today. The 132 Internet is not sufficiently secure and the IPv4 address space is 133 approaching exhaustion. Technical solutions for these problems 134 exist, but there deployment falls far short of what is necessary. 135 The cost of the necessary network administration changes is too 136 great. 138 It is clear that inn order to address the security problem we must 139 address the network administration problem. On closer examination it 140 also becomes clear that the reverse is also the case. Many 'network 141 administration' steps that today require physical access to a machine 142 could be performed automatically with an adequate and ubiquitous 143 authentication infrastructure. 145 3. Why the Traditional Approach Fails 147 Network administration is hard and getting harder. As a result the 148 network is becoming harder to manage and less reliable. Each new 149 service, each change to the network infrastructure has the potential 150 for unexpected results. The task of network administration is 151 rapidly approaching the complexity of programming. At the same time 152 the expansion in Internet use means that more and more people are 153 being required to learn network administration skills in order to 154 manage local networks in their home or small office. 156 Many professional network administrators see their role as resisting 157 change that may threaten the stability of the network while home 158 users are limited to the most basic modes of network use. Even the 159 simplest extension beyond Web and email such as attempting to make 160 use of video in an instant messaging application is likely to be a 161 painful and protracted exercise requiring detailed knowledge that 162 application providers and ISPs usually fail to provide in a useful 163 form. 165 These problems are greatly compounded by the rising problem of 166 Internet crime. As Willie Horton would put it, the Internet is now 167 'where the money is'. Internet crime is now a professional activity. 168 The capabilities of organized criminal gangs greatly exceed those of 169 the 'script kiddies' of earlier times. Ad-hoc network configuration 170 restrictions imposed in response to this threat quickly become 171 obstacles which everything else must route around. 173 3.1. Network Administration is Hard 175 A communication network may be represented as a graph in which the 176 nodes are the machines (hosts, routers, etc) that make up the network 177 and the arcs are the communication media (wires, radio connections, 178 etc.) by which the machines are linked. 180 In the traditional network administration model the network is 181 administered by making changes to individual network nodes. To 182 install an inbound email server we must configure the machine on 183 which the email server is to run, the DNS for each of the email 184 services to be provided and configure the external firewall so that 185 inbound traffic is directed to the machine. 187 Each of the three discrete administrative configurations required 188 requires a different skill set and must be must be entered in a 189 different format. Inconsistencies between the configurations will 190 result in the system malfunctioning, possibly in ways that are 191 difficult to correctly diagnose. 193 In a large enterprise where responsibility for administration of the 194 various infrastructures is vested in different organizations the 195 potential for misconfiguration is greatly magnified. 197 If network administration is to be simplified we must stop trying to 198 configure the individual nodes and instead configure the network. 200 3.2. Network Administration is Getting Harder 202 The traditional network administration model is already undergoing 203 change. 205 In the enterprise deperimeterization represents a process that is 206 already underway regardless of whether it is desired or not. As 207 enterprises increasingly integrate their networks with customers 208 suppliers and partners the distinction between the network and the 209 inter-network is gradually lost. 211 Web Services offer the prospect of what Bill Gates has called 212 'frictionless capitalism'. For legions of clerical workers the daily 213 toil consists of sifting through sheaves of computer generated orders 214 and invoices in order to enter the details into another computer. As 215 the scope of Web Services reaches beyond the network perimeter to 216 connect to customers and suppliers the number of Internet services 217 rapidly increases from the traditional big three (email, instant 218 messaging, Web) to the essential hundred or more. 220 In the home the prospects for network are even more daunting. In the 221 near future every device that currently comes with an embedded clock 222 will come with a network connection. It will soon become common for 223 every light switch and every power outlet in newly built houses to be 224 network controlled. 226 The traditional model of network administration: that it is an expert 227 task that must be left to experts is unsustainable. 229 3.3. Changes to Deployed Protocols Take a Decade 231 In the mid 1990s the IETF embarked on three major infrastructure 232 initiatives: the deployment of IPv6, DNSSEC and secure email. Over a 233 decade later none of these initiatives has seen production use on a 234 significant scale. 236 Making changes to deployed Internet protocols is hard. Making 237 changes to shared infrastructure is particularly hard. Protocol 238 upgrades percolate slowly as software is upgraded but the deployment 239 threshold at which a new feature becomes viable for use is frequently 240 as high as 90% or more. 242 Most application protocols make some attempt to support upwards 243 compatibility but these mechanisms come into play only after the 244 client has committed to connect to a particular host using a 245 particular protocol. This approach does not support the type of 246 parallel deployment strategy that is desirable in the case of major 247 protocol upgrades. The same host machine must simultaneously support 248 both the new and the old way of doing things. This makes sense for 249 minor protocol changes but not for a radical upgrade such as 250 transitioning from SMTP to a Web Services based protocol to support 251 unified messaging. 253 This problem is felt with particular force in the security area. As 254 long as there is a significant deployed base of insecure applications 255 attempts to deploy secure infrastructure will always be subject to a 256 downgrade attack. Signing an occasional email allows the recipient 257 to determine that a signed message is authentic. Only if it is known 258 that every authentic email is signed can the recipient identify a 259 fake. 261 The common factor in these issues is the lack of a protocol 262 description layer in the Internet architecture. 264 3.4. Lack of Necessary Abstractions 266 The Internet signaling infrastructure has evolved to identify servers 267 and not services. 269 As its name suggests the Internet hosts file was conceived as a means 270 of providing consistent mnemonic for a host. The DNS continued this 271 approach being designed primarily to support the resolution of a host 272 name to a host IP address. 274 For services such as TELNET the service is intrinsically bound to the 275 host. TELNET is a means of executing commands on a remote host. The 276 FTP and MTP protocols layered on top of and in certain respects into 277 the TELNET protocol continued this approach. 279 The limitations of this approach was quickly felt in the deployment 280 of the World Wide Web. The logical DNS name for the CERN Web server 281 would have been cern.ch. The limitations of the HTTP and DNS 282 protocol required the insertion of a host prefix. As a result the 283 first web server was located at info.cern.ch. 285 Subsequent deployments of Web servers faced the problem of how people 286 would discover the location of their Web site. The convention 287 quickly became established that the Web service for example.com would 288 be located at www.example.com. 290 In effect the human users of the Web constructed and applied a 291 signaling convention that should have been provided by the Internet 292 infrastructure itself. By the time the DNS SRV record was defined it 293 was too late. 295 Administration at the level of hosts rather than services focuses 296 attention on the minutiae of network administration, minutiae that 297 are better addressed by machines. Information that could and should 298 be concentrated in a single infrastructure is dispersed, information 299 that is implicit in the network configuration that could assist the 300 network administrators task is inaccessible. 302 Network administration should be of domains and not machines. 304 3.5. Lack of Control 306 The domain name system has a critical role in the network. Whoever 307 controls the DNS resolution of example.com will absolutely control 308 the use of all services that are accessed by names within that 309 domain. This degree of dependency is inescapable, if the Internet is 310 to provide a unified coherent namespace there can only be one party 311 that determines the resolution of example.com. 313 If example.com offers an email service or blog hosting service 314 customers must understand that any brand equity they build up in the 315 name alice@subdomain.example.com or aliceblog.example.com is 316 inevitably subject to continued service from example.com. Unless the 317 rules governing control of the domain are well defined and designed 318 to enfranchise the individual user (such as is the case for ICANN 319 regulated domains in top level domains) the brand equity is 320 effectively subject to the goodwill of the domain name owner. 322 While dependence on the signaling infrastructure is inescapable if 323 there is to be a uniform resolution of names to services the current 324 approach to network administration means that there are additional 325 dependencies that are escapable. In particular the security of the 326 resolution service is dependent on both the DNS system and the BGP 327 system for advertising inter-domain routing. The transfer of email 328 is effectively regulated by a Byzantine network of opaque, obscure 329 and unaccountable 'blocklist' operators. 331 There should be a single point of administrative control 333 3.6. Lack of Automation 335 Traditional network administration focuses on the configuration of 336 hosts to support applications rather than the configuration of the 337 network to provide a service. 339 The difference between these approaches is demonstrated by the 340 configuration of a network service to accept inbound email. For such 341 a service to be reliable redundant hosts should be supported. Spam 342 filtering and firewall traversal will require additional hosts. 344 In the traditional network administration model each host 345 configuration is independent and discrete. At no point is an 346 explicit statement made that the service is the sum of the 347 independent configurations. 349 Network administration tools should be oriented to the configuration 350 of services rather than hosts. 352 3.7. Lack of Feedback 354 Another problem which this document only partly attempts to address 355 is the lack of feedback on network status in a form that a user can 356 make use of. 358 A statement of the form '45% of inbound packets were dropped' is of 359 no use to a user unless followed by a statement of the form replace 360 the cable between the cable modem and the router box'. 362 The Internet has no shortage of network diagnostic tools, the problem 363 lies in the lack of an overarching network description framework that 364 would allow the network layer diagnostic information to be integrated 365 and presented in a useful form. 367 If the goal of the automated home is to be realized in a form where 368 every electrical appliance, switch and socket is network enabled 369 fault diagnosis must be automatic. This problem is no less urgent in 370 the enterprise space where time spent analyzing network failures 371 translates directly into costs. 373 The description of the Network Configuration should assist the 374 identification and reporting of failures. 376 3.8. Inadequate Abuse Reporting 378 The lack of feedback mechanisms is felt with particular force when 379 dealing with network abuse. A system that depends on sending an 380 email to abuse.example.com is simply inadequate for a network with a 381 billion users. 383 Large ISPs spend millions annually processing abuse reports. As the 384 abuse reporting mechanism assumes a human mediator each report has a 385 different structure and format even though the content may be 386 identical. The use of English is assumed. 388 The attackers understand these gaps in communication and exploit them 389 to the full. Every large scale operator of Internet infrastructure 390 has lists of sites suspected of hosting bots, sites from which large 391 quantities of attacks have originated. Yet at present there is no 392 peer to peer mechanism for exchange of this attack data. Most ISPs 393 would like to be told that their customers may have an infected 394 machine, but processing emails containing lists of suspect IP 395 addresses is neither an acceptable nor a practical solution. 397 Reporting of abuse should be automated. 399 3.9. Lack of Security 401 The biggest deficiency in the traditional model for network 402 administration is the lack of security. The attempt to effect a 403 transition from the original Internet designed without the benefit of 404 cryptographic security to a secured network is constantly stymied by 405 the lack of support in the signaling layer. 407 Without the knowledge that every single email from example.com is 408 digitally signed without exception there is no means by which a 409 recipient of an unsigned email can know if it unsigned but authentic 410 or unsigned because it is fake. 412 Without the knowledge that the mail server for example.com a lways 413 offers TLS upgrade the confidentiality of the connection is still 414 subject to a man in the middle downgrade attack. 416 The network signaling layer should support the exchange of security 417 policy. 419 4. Requirements for an Administration Model 421 The defect analysis of the current network administration model 422 provides the requirements for a replacement model capable of 423 sustaining the next phase of Internet growth. 425 In a world where every light switch and every light bulb are IP 426 addressable it is unacceptable to be required to spend as much as a 427 minute configuring or maintaining each network interface. 429 4.1. Unified service discovery 431 Given a communication objective the service discovery infrastructure 432 finds the means to satisfy it. 434 For example: if Alice wants to send a video mail message to Bob using 435 his email address bob@example.com the service discovery layer should 436 allow Alice's client to determine that example.com supports four 437 messaging transport protocols and that two of the service deployments 438 are compatible with the client protocol support. 440 The service discovery infrastructure should permit discovery of 441 networking restrictions in the originating and receiving networks. 442 If a protocol selected is incompatible with the local network policy 443 this should result in a discovery service error rather than the 444 packets being silently discarded. 446 There should be a single architecture to support discovery of 447 Internet services. 449 The unified architecture should map a DNS name to an abstract 450 service. 452 The unified architecture should provide a mechanism for mapping 453 the abstract service onto one or more physical servers that 454 supports the following properties: 456 Fault tolerance. 458 Protocol matching. 460 Protocol version and feature matching. 462 Compliance with inbound and outbound network security policy. 464 Firewall detection 466 Navigation of inbound and outbound NAT devices. 468 4.2. Single configuration description 470 It should be possible to specify all the information necessary for 471 configuration of a network service in a single description document. 473 Much of the complexity of the network configuration problem stems 474 from the need to configure each network device independently. This 475 inevitably leads to inconsistencies which in turn lead to avoidable 476 network failures. 478 This description should specify the nature of the service to be 479 provided, the DNS names of the specific hosts to support the service 480 and the reach of the service. 482 4.3. Coherent Security Model 484 There should be a coherent security model which fully supports the 485 principle of least privilege. 487 Best current practice in this respect is to patrol the border between 488 the local network and the Inter-network by means of a security 489 firewall. As many including the proponents of 'deperimeterization' 490 have observed the border, should be the first line of defense and not 491 as frequently happens the last. 493 In a network that fully realizes the principle of least privilege 494 each router, hub and network interface becomes a local policy 495 enforcement point. Such an approach is entirely impractical if each 496 service deployment requires manual reconfiguration of each device. 498 Generating the security requirements from the single configuration 499 description allows for much greater visibility and control than the 500 present ad-hoc approach. 502 For example a network security administrator may readily enforce a 503 policy that prohibits running an application client such as a Web 504 browser or email client on a server that provides an externally 505 facing Web server. Such a policy effectively insulates the Web 506 server from some of the most commonly used vectors for trojan 507 attacks. 509 Explicit network configuration enables tracking of data related 510 policy violations. For example a laptop computer should know that it 511 is a mobile device and should refuse to accept data tagged as being 512 privacy sensitive such as credit card or social security numbers. 514 4.4. Alignment of Accountability and Control 516 The administrative model must establish clear lines of accountability 517 that are closely aligned to control capability. 519 The distinction between the network and the inter-network will always 520 remain an important one for network management. The border between 521 the network and the inter-network marks the point at which 522 responsibility and control change. 524 This distinction between the network and the inter-network is 525 recursive. At the lowest level a host connects to router serving a 526 local network which may in turn be part of a wider departmental 527 network which is in turn part of a corporate network which is in turn 528 served by an ISP whose network connects to 'the Internet' at one or 529 more peering points. 531 A network manager has different responsibilities to their network and 532 to the inter-network. Within the network the network manager has the 533 responsibility to keep the network running to the satisfaction of the 534 network users. In order to achieve this goal the network manager has 535 a considerable degree of control. 537 A network manager inevitably has a much lesser degree of control over 538 the management of the inter-network. The recognition of this fact is 539 one of the key insights that differentiated the Internet from 540 competing inter-network proposals. 542 The network manager has a second responsibility to ensure that the 543 network she is responsible for does not cause harm to the wider 544 inter-network. 546 4.5. Support for Virtual and Physical networks 548 The administrative model must provide a coherent management model for 549 virtual networks spanning multiple physical networks within the 550 Internet. 552 In a traditional Internet configuration the physical network and the 553 scope of a domain name are coextensive. If an Internet host has a 554 domain name in the zone mit.edu it is almost certain that it has a 555 network address in the class A allocation 18.*.*.* and is highly 556 likely to be situated in Cambridge Massachusetts. 558 Introduction of the DNS enabled a virtual network model in which 559 network services are supported at remote co-location facilities and 560 through outsourced services. It is now usual for enterprises to rely 561 on third parties to provide the bulk of their networking needs. This 562 trend is likely to increase as the number of Web Services increase. 564 The administration model must allow for tools to support 565 administration of remote servers and outsourced services. 567 5. Domain Centric Administration 569 In the domain centric administration model the controller of the DNS 570 name used for the discovery of a service is considered to be the sole 571 authoritative source of configuration information for that service. 573 This design decision is a direct consequence of the requirement for a 574 single unified administration model. The controller of the DNS name 575 used for discovery of a service inevitably has a great degree of 576 control over the administration of the service, including the ability 577 to deny access to the service. Such denial of access cannot properly 578 be considered a protocol 'attack' although it may well represent a 579 breach of a contractual duty. 581 In the domain centric model the controller of a domain name controls 582 all aspects of protocol configuration for services within a domain. 584 For example, existing DNS principles allow the controller of the 585 domain example.com to specify the IP addresses of the mail servers 586 receiving mail sent to example.com and the preference order for their 587 use. In the domain centric model the controller of example.com can 588 exercise control on outgoing mail as well as incoming and set the 589 protocol options and the security policy for each. 591 Using the domain name system as the basic for administration provides 592 a close match between expected and actual control. The expectation 593 of a typical user is that the owner of an Internet domain name is 594 responsible for its use. Unfortunately the current Internet 595 administration mechanisms do not meet this expectation and there is a 596 divergence between responsibility and control. This has in turn led 597 to the use of ad-hoc enforcement mechanisms at the IP level which 598 effectively preclude alternative administration arrangements. While 599 this 'walled garden' model may be acceptable and often desirable in 600 an enterprise network this is not the case when an ISP is delivering 601 a service to consumers. 603 While the domain centric administration model increases the extent to 604 which the domain name owner can control use of their name this level 605 is available to anyone who becomes a domain name owner. 607 5.1. DNS Records 609 DNS records are used for service declaration, discovery and 610 configuration. In order to ensure compatibility with existing legacy 611 DNS services while supporting the necessary range of administrative 612 support capabilities such as wildcards the extended prefix mechanism 613 described below is used. 615 5.1.1. Service Declaration 617 Service Declaration records specify the range of protocols that 618 support a specific service. 620 The service declaration layer supports protocol agility. Publication 621 of Web services might be supported by the traditional HTTP protocol 622 and a binary protocol HTTP-NG. Email transfer might be supported by 623 SMTP and a generalized messaging protocol based on SOAP. 625 Service Declaration records are represented as prefixed TXT records. 627 The following example shows service declarations for email and http 628 services. Email is supported through three protocols and two Web 629 protocols are supported: 631 _email.example.com TXT "t=_email p={smtp esmtp msoap}" 632 _http.example.com TXT "t=_http p={http http-ng}" 634 The service declaration layer only states the services that are 635 supported. Details of the configuration of each service are declared 636 in the service discovery and configuration records. 638 5.1.2. Service Discovery 640 The existing SRV record is used for service discovery with the same 641 semantics for discovered records as specified in RFC 2782. 643 The extended prefix discovery mechanism described below is used to 644 support extended prefixing. As there is only one significant 645 protocol that operates over both tcp/ip and udp/ip the hierarchical 646 division of prefix labels between tcp and udp protocols is abandoned. 648 The following example shows SRV records corresponding to support of 649 the hypothetical HTTP-NG protocol referred to above. 651 _httpng.example.com SRV httpng1.example.com 80 1 1 1 652 _httpng.example.com SRV httpng2.example.com 80 1 1 1 654 5.1.3. Service Configuration 656 Each service discovery point and each service instance may have a 657 service configuration record defined. The service discovery point 658 record provides information regarding the service provision as a 659 whole while the individual service records provide configuration data 660 corresponding to individual instances. 662 Service Configuration records are represented as prefixed TXT 663 records. 665 The following example shows the service configuration records 666 corresponding to the configuration of the hypothetical 'http-ng' 667 service: 669 _httpng.example.com TXT "t=_httpng v={1.0-1.2 2.0}" 670 _httpng.httpng1.example.com TXT "t=_httpng v={1.0-1.2}" 671 _httpng.httpng1.example.com TXT "t=_httpng v={1.0-1.2 2.0}" 673 The first service configuration record state that http-ng versions 674 1.0 through 1.2 and 2.0 are supported. The second record specifies a 675 server that only supports the earlier version of the protocol, the 676 second a server that supports both versions. 678 The ability to specify version support at both the aggregate level 679 and the individual server level is critical in enabling a managed 680 orderly transition between protocol versions. In this case a new 681 server has been brought online to support the new 2.0 version of the 682 protocol and this will run in parallel with the older server that 683 only supports the previous version until software on the older server 684 is updated. 686 5.1.4. Additional Response Records 688 The use of separate records for declaration, configuration and 689 configuration allows for backwards compatibility with legacy 690 infrastructure and avoids the risk of a truncated response but is 691 less efficient than a scheme in which discovery and configuration are 692 combined. 694 Fortunately the DNS provides a means for anticipating the need for 695 additional information in a request; the additional response section. 696 An aware DNS server SHOULD provide the service configuration records 697 most likely to be of use to a requestor as additional records if 698 space permits. 700 5.2. Mitigating IPv4 Address Scarcity 702 The domain centric administration approach mitigates the imminent 703 problem of IPv4 address exhaustion in three ways: 705 Greater use of NAT addressing is encouraged 707 Network reconfiguration is simplified reducing the incentive to 708 hoard IPv4 addresses 710 The transition to IPv6 is simplified 712 The ultimate resolution of the IPv4 address scarcity issue must be 713 the deployment of IPv6. Even with NAT the pool of IPv4 addresses 714 will continue to dwindle. Once the remaining pool of addresses falls 715 below a certain threshold it is likely that speculative pressure will 716 lead to a rapid rise in the depletion rate. 718 Such speculative pressures may not be entirely counterproductive. An 719 organization that has an original Class A allocation may well be 720 persuaded to relinquish it provided that there is an economic 721 incentive to do so and cost-effective tools to manage the process of 722 transition to a smaller space. 724 The domain centric administration approach encourages a declarative 725 style of network administration in which the original intent of the 726 administrator is captured and not merely the specific configuration 727 changes necessary to realize this intent. This approach allows the 728 transition from IPv4 networking to mixed IPv4/v6 networking and the 729 transition from mixed networking to pure IPv6 networking to be 730 managed automatically and without fuss. 732 5.3. Objections 734 5.3.1. Change of control 736 The usual objection made to the domain centric approach is that a 737 person using a service supported by example.com may have a different 738 view of security policy or other service options. Bob who receives 739 email as bob@example.com may wish to use a higher degree of security 740 than that supported by the controller of the domain name or no 741 security at all. 743 Since it is generally agreed that a network operator has the right 744 (and in certain cases the duty) to require a minimum level of 745 security the second complaint does not appear to be well founded. 747 It is somewhat difficult to identify cases where the domain name 748 controller can force Bob to use a lower degree of security that are 749 markedly distinct from the ability of the domain name controller to 750 deny service in its entirety. 752 The usual objection made to this approach is that a person using a 753 service supported by example.com may have a different view of 754 security policy or other service options. Bob who receives email as 755 bob@example.com may wish to use a higher degree of security than that 756 supported by the controller of the domain name or no security at all. 758 Since it is generally agreed that a network operator has the right 759 (and in certain cases the duty) to require a minimum level of 760 security the second complaint does not appear to be well founded. 762 The usual objection made to this approach is that a person using a 763 service supported by example.com may have a different view of 764 security policy or other service options. Bob who receives email as 765 bob@example.com may wish to use a higher degree of security than that 766 supported by the controller of the domain name or no security at all. 768 Since it is generally agreed that a network operator has the right 769 (and in certain cases the duty) to require a minimum level of 770 security the second complaint does not appear to be well founded. 772 5.3.2. Alternative infrastructure 774 Several commentators suggest use of a different infrastructure such 775 as NIS, LDAP or HTTP. Notably lacking in these proposals is how the 776 policy discovery process would be performed. 778 It is important to distinguish policy discovery from policy 779 publication. A mechanism for policy discovery provides the 780 information necessary to resolve the policy. A policy publication 781 mechanism provides the policy itself. 783 The Internet has only one ubiquitous naming infrastructure: the DNS. 784 Only the DNS can provide an authoritative policy discovery mechanism. 785 Even if another mechanism such as L DAP or NIS were to be employed 786 for policy publication the use of the DNS to discover the location of 787 the authoritative service is inescapable. 789 Clearly the DNS is a highly constrained infrastructure and the 790 inclusion of large quantities of policy data in the DNS is 791 undesirable from both the operations and administration point of 792 view. 794 In most cases however the quantity of policy information required is 795 small and the simplest and most convenient approach is to distribute 796 the information through the DNS rather than require the involvement 797 of a separate infrastructure. 799 In cases where the quantity of data is larger than a DNS query result 800 will allow (500 bytes) a URL reference to a policy document stored 801 separately or an SRV record advertising a separate service is more 802 appropriate. 804 6. Service Registration Service 806 Although the DNS provides an appropriate infrastructure for service 807 advertisement and discovery it is not a satisfactory platform for 808 entering configuration. 810 Instead we prefer to ensure that configuration data is wherever 811 possible entered automatically with the minimum amount of operator 812 intervention and in cases where operator intervention is required to 813 distinguish the capabilities of the device itself from options 814 configured on the device. 816 The service registration service allows a device or service 817 connecting to a network to advertise the capabilities that it 818 supports. The SRS service may in turn notify other network discovery 819 infrastructures supported locally such as NIS, LDAP and of course the 820 DNS itself. 822 6.1. Protocol 824 6.1.1. Discovery 826 A device or service attaching to a network discovers the local SRS 827 service by performing an SRV lookup on the domain name advertised 828 when the device connects to the network 830 6.1.2. Protocol 832 Service Registration Service (SRS) is a Web Service that supports the 833 following operations: 835 Register 837 The register operation is used to register a service and to specify 838 the capabilities the device offers to the network 840 Cancel 842 The cancel operation is used to cancel an existing registration. 844 Either operation may be performed by either the service to which the 845 description refers or by a proxy. 847 Once accepted a service registration has a 'lease' that will expire 848 after a specified time unless renewed. Alternatively this lease may 849 be tied to the lifetime of the DHCP lease for the network connection. 851 6.1.3. Example 853 A printer connects to a LAN. DHCP is used to obtain a local IP 854 address (10.1.2.3) and the local domain address (net1.example.com). 855 The printer then discovers the location of the local SRS service 856 (srs1.example.com) by attempting to resolve the SRV record for 857 _srs.net1.example.com. 859 Having discovered the local SRS service the device uploads the signed 860 device description file embedded in the device during manufacture. 862 The SRS service determines whether the device is authorized to 863 advertise these services and if so enters the relevant service 864 descriptions into the DNS, LDAP, NIS and other directory 865 infrastructure as is appropriate to the services offered and the 866 permissions granted. 868 6.2. Service Description 870 The device description specifies the network services offered by the 871 device or service. 873 6.2.1. Capabilities 875 The Capabilities section specifies the capabilities offered by the 876 device and the protocols by which they may be accessed. 878 For example a printer might be capable of printing in black and white 879 from paper stock in one of two trays, support the lpr protocol for 880 accepting print requests, the SNMP protocol for management and the 881 PCL6 and Postscript page description language. 883 6.2.2. Dependencies 885 The dependencies section allows a service to specify the services on 886 which it depends. Such dependencies may be marked critical or non- 887 critical depending on whether the availability of the service will 888 prevent functioning of the device. 890 Most network devices would have a critical dependence on the DHCP 891 service and some devices such as a SIP phone would require the 892 ability to advertise port addresses visible to the external network. 894 Network devices that make use of a clock should make use of the local 895 NTP service for synchronization if one is available. 897 6.2.3. Configuration 899 The Configuration section specifies the specific options that are 900 configured for the device. For example a multi-function device 901 supporting use as a printer, scanner or fax may not be connected to a 902 telephone line and so the fax capability may not be available. 904 6.2.4. Authentication Data 906 Each SRS request should be authenticated by means of a PKI based 907 protocol. 909 In the case of a device the most straightforward approach is to 910 generate a public key pair and a digital certificate binding the 911 public key to the device identifier during manufacture. In the case 912 of a network device the device identifier would normally be the MAC 913 address of the device or an EUI-48 or EUI-64 identifier. 915 7. Example Applications 917 The objective of Domain centric administration is to unify and 918 wherever possible automate the process of network administration. As 919 a general rule a human should only be involved in the network 920 administration when there is a choice to be made and wherever 921 possible that choice should be reduced to a small number of discrete 922 options. 924 7.1. Configuration of Email Server 926 Despite many attempts to add cryptographic security to email only one 927 email security protocol has achieved ubiquitous deployment and none 928 has achieved ubiquitous use. Deployment of SSL on the other hand has 929 been a major success and a clear majority of Web transactions that 930 might require security enhancements are secured with SSL. 932 The principal architectural difference between SSL and the email 933 security protocols is that SSL is applied at the domain level while 934 PEM, MOSS, PGP and S/MIME all require participation by individual end 935 users. While 'end-to-end' security offers certain advantages over 936 domain level security the cost of deploying and managing a 937 cryptographic key for every Internet user is inevitably much higher 938 than the cost of maintaining one public key pair per email server. 940 This experience suggests that applying email security at the domain 941 level is much more likely to succeed than the exclusive promotion of 942 end to end security as the sole acceptable solution. As is discussed 943 later these approaches are not mutually exclusive, while the perfect 944 has been the enemy of the good in the case of email security the good 945 can provide a stepping stone towards the better. 947 Email is an asynchronous protocol. As email messages are frequently 948 routed through mail relays the originator and the ultimate receiver 949 of an email do not necessarily ever communicate directly. In modern 950 email infrastructures this situation is now the rare exception rather 951 than the rule. 953 The lack of a direct interaction between the originator and the 954 receiver of the message precludes the type of security negotiation 955 that takes place in other security protocols such as SSL. The 956 originator must generate a message that the ultimate recipient is 957 likely to be able to accept and use. As a result originators must 958 continue to be conservative in what they send since they cannot rely 959 on recipients to meet contemporary expectations of what they should 960 accept. 962 7.1.1. Advertising outbound security policy 964 The principle challenge that has faced email operators in recent 965 years is spam. In particular spam that impersonates another party 966 may make unauthorized use of the good reputation of a legitimate 967 sender. 969 The key to dealing with the problem of spam is accountability. Once 970 email senders have the ability to accept responsibility for their 971 actual emails sent receivers can judge senders on their past 972 behavior, their reputation and the extent to which they have 973 demonstrated that they can be held accountable. 975 For accountability to work it is equally important to know when an 976 email sender denies responsibility for a message as when they accept 977 responsibility. It is therefore necessary for the receiver to know 978 that a sender will always authenticate their outgoing mail. 980 Various proposals have been made to address this need of which SPF/ 981 Sender-ID and DKIM are the best known. In each case the 982 authentication mechanism provides a means by which the sender can 983 inform recipients that they should expect messages to be 984 authenticated. 986 7.1.2. Advertising inbound security policy 988 Outbound security policy allows the recipient to know if a message 989 should carry authentication and thus avoid a downgrade attack. 990 Inbound security policy provides the complimentary capability for 991 confidentiality. 993 As previously noted many email confidentiality schemes have been 994 proposed but these have not been widely used. A key defect in all 995 these efforts to date has been the failure to consider the 996 requirement for security policy and key distribution. The OpenPGP 997 and S/MIME specifications both take as their starting point the case 998 where the sender has available the public key certificate or key 999 signing of the recipient. Although certain commercial products have 1000 recognized this gap and provided their own solutions this approach 1001 must become a widely supported standard if it is to be of value. 1003 Email confidentiality may be achieved at two distinct levels: 1005 At the level of individual users (end-to-end security) 1007 At the domain level (edge-to-edge security) 1009 End to end security in the tradition of PEM, PGP and S/MIME offers a 1010 high level of security at the cost of being required to manage and 1011 distribute keys to every user. Domain level security such as DKIM, 1012 the SMTP STARTTLS extension and S/MIME for domains offers a high 1013 level of security with considerably greater flexibility at a much 1014 more modest cost. 1016 Regardless of whether security is applied at the domain level, the 1017 user level or both a policy and key distribution mechanism must be 1018 provided to answer two essential questions: 1020 Does the intended recipient of this email message support a 1021 compatible encryption protocol? 1023 If so what public key should be used to send the message to the 1024 intended recipient? 1026 Answering these questions at the domain level through a domain level 1027 policy statement allows the distinction between user level and domain 1028 level security to be eliminated as far as the sender is concerned. 1029 The message is encrypted to an encryption key specified by the 1030 domain, it is for the domain controller to decide whether to offer 1031 encryption at the domain or user level. 1033 This approach offers considerably greater flexibility which is a 1034 necessity in many modern enterprise messaging systems. In the era in 1035 which PEM was designed email messages passed almost exclusively 1036 between desktop terminals and personal computers. Today users expect 1037 the ability to receive email messages on pagers, phones and at any 1038 desktop or laptop computer they happen to be using at the time. 1039 Users are not willing to accept an end to end encryption system if it 1040 prevents them accessing their mail on the machine of their choice. 1042 The mail service advertises that it always offers the STARTTLS and 1043 S/MIME security enhancements for inbound mail and that keys may be 1044 obtained through DNS resource records for SSL or XKMS for S/MIME 1046 _inbound._smtp._tcp.example.com TXT 1047 ("ALWAYS={STARTTLS, KEYSERVER={DNSRR}}" 1048 "ALWAYS=S/MIME KEYSERVER={XKMS}") 1050 Each mail server specifies its own key resource record in the same 1051 format as for DKIM. 1053 This approach is fully compatible with existing practice for 1054 configuration of email servers but protects communication from a man 1055 in the middle downgrade attack provided that the DNS itself is 1056 trustworthy (e.g. through use of DNSSEC). 1058 7.2. Configuration of Email Client 1060 Configuration of email clients today is unnecessarily complex. The 1061 user is required to discover arcane details that should remain 1062 'beneath the hood' such as the server name and port number of their 1063 incoming and outgoing email services. 1065 The only information a user should need to know in order to configure 1066 an email client is their email address and whatever information might 1067 be required for authentication. 1069 For example: Alice has the email address 'alice@example.com' and she 1070 authenticates herself to the mail service using her password '1234'. 1071 If Alice is asked for any information other than her email address 1072 and password this should be considered an unacceptable failure of the 1073 configuration mechanism. 1075 7.2.1. Finding incoming and outgoing email services 1077 Standard SRV discovery is used to locate the POP3, IMAP4 and SUBMIT 1078 services: 1080 _pop3._tcp.example.com SRV 1 100 110 inbound.example.com 1081 _imap._tcp.example.com SRV 1 100 143 inbound.example.com 1082 _submit._tcp.example.com SRV 1 100 773 outbound.example.com 1084 7.3. Discovering support for security enhancements 1086 We would much prefer to connect to the mail services using a protocol 1087 that provides confidentiality and integrity services. This is the 1088 case even if an end to end security solution such as PGP or S/MIME is 1089 employed since information that must be present in the email headers 1090 such as the sender and recipient addresses may reveal important 1091 information to an attacker. 1093 The POP3 and IMAP4 protocols use a separate TCP port for service over 1094 SSL and so we would advertise service for the POP3S and IMAPS 1095 protocols instead: 1097 _pop3s._tcp.example.com SRV 1 100 995 inbound.example.com 1098 _imaps._tcp.example.com SRV 1 100 993 inbound.example.com 1099 The SUBMIT protocol does not require a separate port for use with SSL 1100 as the SMTP protocol of which SUBMIT is a variation supports the 1101 STARTTLS service. 1103 In either case the client connecting to the service requires an 1104 authoritative statement of the security enhancements supported by the 1105 service. This is provided by a security policy record: 1107 _spss._pop3s._tcp.example.com TXT "KEY=_key.example.com" 1108 _spss._imaps._tcp.example.com TXT "KEY=_key.example.com" 1109 _spss._submit._tcp.example.com TXT "STARTTLS KEY=_key.example.com" 1110 _key.example.com TXT "alg=RSA value=..." 1112 Note that the security policy does not specify the public key to be 1113 used by the server directly. Instead the policy record specifies a 1114 location where the key description can be found. This allows 1115 multiple services to make use of a single key record. 1117 The key record might specify the public key directly or since SSL is 1118 a PKI based protocol specify an X509v3 certificate to be used as a 1119 trust anchor. 1121 7.4. Determining authentication requirements 1123 Having discovered the inbound and outbound email servers the next 1124 step for the client is to determine the authentication mechanism(s) 1125 and protocol(s) that are required in order to gain access. While 1126 username and password is likely to remain the lowest common 1127 denominator for this purpose for some time to come the policy layer 1128 allows the email client to discover the existence of stronger 1129 authentication schemes: 1131 _options._pop3s._tcp.example.com TXT "auth=password,digest" 1133 In this example the POP3 server offers exchange of plaintext 1134 passwords or use of the digest mechanism. While exchange of password 1135 data en-clair is a security risk it is acceptable in this case 1136 because the transport is encrypted. 1138 Alternative authentication mechanisms that might have been offered 1139 include PKI based authentication, or a connection to a distributed 1140 authentication mechanism such as RADIUS, SAML, or OpenID. 1142 7.5. Discovering support for Key Management 1144 Having established a secure context for exchange of messages with the 1145 mail servers we may want to go further and establish full end-to-end 1146 cryptographic security. 1148 While domain level security is valuable and easy to deploy precisely 1149 because it is transparent to the end user it is necessarily limited 1150 for the same reason. In particular there are cases where an email 1151 client must know whether an email can be sent using a mechanism that 1152 provides sufficient confidentiality protection. 1154 The problem with achieving end-to-end security is that the ends of 1155 the communication are not necessarily the same as the ends of the 1156 trust relationship. If Alice is acting on her own behalf then her 1157 email client can manage both sets of concern. If Alice is working 1158 for a government agency, a financial institution or other enterprise 1159 it is the enterprise that is the 'end' of the trust relationship and 1160 the protocols should recognize this fact. 1162 XML Key Management Service (XKMS) is a key centric PKI protocol which 1163 is designed to support this mode of management. An XKMS server 1164 exposes the key management services necessary to support a PKI based 1165 application as a service. PKI is inescapably complex because the 1166 problems that PKI addresses are complex. It follows that attempting 1167 to eliminate complexity from a PKI architecture altogether is a 1168 misguided approach that is unlikely to succeed. XKMS does not 1169 attempt to eliminate complexity, instead it allows the network 1170 manager to control where that complexity is placed and managed. 1171 Complexity that is exposed in a client is very had to manage as any 1172 change to the code must be deployed to every end client. Complexity 1173 that is exposed through a service is much easier to manage as the 1174 service is a single point of control. 1176 The XKMS Key Information Service Specification (XKISS) allows a 1177 client to locate a key that may be used to secure a communication 1178 with a specified party using a specified protocol. The XKMS Key 1179 Registration protocol allows a client to register a public key. 1181 The XKMS specification defines SRV prefixes for discovery of XKMS key 1182 information and registration services: 1184 _XKMS_XKISS_SOAP_HTTP SRV 100 100 80 xkms.example.com 1185 _XKMS_XKRSS_SOAP_HTTP SRV 100 100 80 xkrss.example.com 1187 The domain centric administration approach allows additional policy 1188 statements to be made to provide additional configuration information 1189 to assist configuration of clients: 1191 The public key used to authenticate XKMS transactions 1193 The security and protocol policy options of the XKMS service 1195 Distinguish between XKISS services that provide only Locate 1196 services from those offering Locate and Validate services. 1198 Identify the necessary authentication context. 1200 The combination of these services allows confidentiality to be 1201 applied on a 'promiscuous' basis. That is the sender will always 1202 send a message using the best encryption service that is offered. 1204 In this scheme the only times where the user need be aware of the use 1205 of encryption is in cases where the default 'promiscuous' encryption 1206 must be overridden. For example requiring a message to be sent en- 1207 clair or requiring the message to be sent encrypted. 1209 Requiring confidentiality protection is the more likely case. A user 1210 interface might allow the user to specify that individual messages 1211 should be sent with confidentiality protection or mark individual 1212 users, companies or types of company for which confidentiality 1213 protection should be specified by default. For example a lawyer 1214 might have an email client configuration that requires all messages 1215 sent to other lawyers and to clients to be marked confidential and 1216 sent encrypted. 1218 7.6. Discovering alternative message transfer facilities 1220 In some cases the email client may be unable to discover a supported 1221 cryptographic enhancement to SMTP. The recipient may not support an 1222 acceptable security protocol or may fail to provide a public key that 1223 the sender considers to be sufficiently trustworthy. 1225 In such cases the message might be sent by an alternative transport, 1226 possibly an email message containing a URL of an SSL secured Web site 1227 from which the message may be retrieved securely. Alternatively a 1228 Web service might accept a message and forward it by facsimile or 1229 even cause the message to be printed out and sent by letter post or 1230 courier service. 1232 8. Configuration of Web Services 1234 Configuration of a Web Service, whether layered on SOAP or basic HTTP 1235 would follow the same principles as for email with the proviso that 1236 the Web Services stack provides for a policy layer WS-Policy offering 1237 a rich array of policy options. The principle limitation of WS- 1238 Policy is that to make best use of it the protocol described should 1239 be a SOAP based Web Service layered on the WS-*. 1241 The Domain Centric approach is not intended to rival WS-Policy. 1242 Rather the domain centric approach is proposed as the means of 1243 discovering a WS-Policy statement should it exist. 1245 While the WS-* stack is undoubtedly the preferred approach to 1246 developing standards based Web Services, much of the innovation in 1247 the field is currently taking place in rapidly developed prototypes 1248 layered directly on HTTP that serve to support 'mashups' developed by 1249 a wide range of developers. Over time some of these prototypes will 1250 merge and coalesce into more widely supported protocols, in most 1251 cases based on the standards based WS-* stack. A transition strategy 1252 from prototypes to standards based services is thus essential to the 1253 success of the WS-* approach. 1255 Rather than develop individual WS-Policy profiles for each prototype 1256 specification it makes better sense to employ the lightweight policy 1257 distribution mechanism to specify the range of Web Services supported 1258 and reserve the use of WS-Policy for detailed description of Web 1259 Services based on WS-*. 1261 9. Automatic Configuration of Network Appliances 1263 One of the principal tasks that network managers, whether in the 1264 enterprise or the home are required to perform is to install and 1265 configure new devices. Most peripherals that connect to a personal 1266 computer directly already support automatic configuration using 1267 mechanisms such as 'plug and play'. This is not yet the case for 1268 network attached peripherals such as printers, storage, cameras and 1269 the networking infrastructure itself. 1271 DHCP provides a degree of automatic configuration but is limited by 1272 the assumption that the peripherals share the same logical IP sub- 1273 network and the supported options for service discovery are limited. 1275 It should be possible to attach network attached storage anywhere on 1276 the Internet with the same ease, reliability and security as storage 1277 attached to the local network. No modification of DHCP can possibly 1278 meet this need and therefore DHCP is not the appropriate technology. 1280 Configuration of wireless devices requires the configuration of the 1281 wireless network connection in addition to the device itself. 1283 Although this is an important problem the mechanisms that might solve 1284 it are necessarily outside the scope of this particular paper and so 1285 a proof of concept only is provided at the end of this section. 1287 The Domain Centric approach is similar to that adopted in Universal 1288 Plug and Play with the key difference that the DNS is used to enable 1289 discovery as opposed to IP multicast. While IP multicast is a viable 1290 technology within the local area network it has failed to demonstrate 1291 viability as an inter-networking protocol despite many years of 1292 effort. While multicast may be regarded as a simple solution, 1293 analogous to multicast within the local area network the use of 1294 multicast in the inter-network is inescapably complex. Use of 1295 multicast as a means of discovering services within the same logical 1296 network that are deployed at a remote physical location incurs a 1297 considerably greater degree of complexity than the domain centric 1298 approach. 1300 9.1. Printer Joins Network 1302 A printer accepts instructions in one or more page description 1303 formats and produces hardcopy output. This process may be controlled 1304 by a number of option settings to determine choices such as the 1305 output resolution, the size of the paper stock, tray to be used etc. 1307 In order for the user to have the necessary degree of control over 1308 the process the printer should provide potentially useful information 1309 such as supported paper sizes, the current status of the paper stock, 1310 toner level, etc. In a large network it may be useful to know the 1311 physical location of the printer, the building, part of building etc. 1313 Traditionally the user is required to install a device driver for 1314 each model of each printer in the network. This process is both 1315 tedious and unnecessary. The printer knows what model it is and the 1316 capabilities it offers. Installation of a device driver should be 1317 the exception, not the rule. 1319 When the printer joins the network it advertises its configuration 1320 and capabilities using SRS. The SRS service then updates the local 1321 directory service to announce the availability of the printer. 1323 9.2. Storage Joins Network 1325 The rate at which modern disk drives offer increased storage capacity 1326 is matched only by the speed with which demand for that capacity 1327 grows. Digital photography and low cost digital video editing allow 1328 individual home users to consume hundreds of gigabytes of storage 1329 each year. In the enterprise rich document formats and in particular 1330 the repeated exchange of digital documents through email creates 1331 similar increasing demand. 1333 Storage capacity is now a commodity. Managed storage: media that is 1334 reliably backed up, indexed and catalogued so that the stored data is 1335 actually usable, remains expensive and administration intensive. 1337 Network Attached Storage (NAS) addresses some of the problems of 1338 storage management. NAS is essentially a dedicated file server 1339 appliance combining one or more hard drives with a CPU. A NAS server 1340 is exposed at the operating system level as a file store attached to 1341 a host device. 1343 If there is only a single file store in the network this model works 1344 well. If many file stores are in use finding the file server where 1345 the data needed is stored is frequently a time consuming task. 1347 As far as the user is concerned the physical storage location of the 1348 data is irrelevant provided that the system ensures that the 1349 necessary performance, reliability and backup criteria are achieved. 1350 The traditional file server model of all currently popular operating 1351 systems is clearly insufficiently abstracted from the user point of 1352 view. 1354 It should be sufficient for the network administrator to buy a 1355 storage appliance, plug it into the network and for the network to 1356 discover that the additional storage is now available and make it 1357 available for use in accordance with pre-existing policies. Adding 1358 storage to a network should require no more thought or consideration 1359 than putting fuel in a car: when the fuel gauge shows that the supply 1360 is nearing exhaustion the operator adds more. 1362 When a new storage device is connected to a network it first attempts 1363 to find a distributed storage service on the network. If a storage 1364 service is found the device reports the additional capacity available 1365 and the performance and reliability characteristics supported. If no 1366 distributed storage service is found the device registers to provide 1367 one using SRS. 1369 9.3. Router Joins Network 1371 Router devices collect packets on one interface and ship them to 1372 another interface. Why is installation any more complex than 1373 plugging the device in and connecting the necessary wires? 1375 Today routers, hubs and bridges are considered to be separate classes 1376 of network device, yet each performs essentially the same function 1377 and in many cases the same hardware platform is used. The 1378 distinction between these device classes is now historical and so for 1379 clarity the term router is used for all three. 1381 As security in depth is taken seriously and border firewalls are 1382 considered the first line of defense rather than is at present the 1383 case the last, every router within the network will become a policy 1384 enforcement point. Packets will only be routed if the network 1385 security policy permits. The default configuration of the network 1386 shall be to deny what is not explicitly permitted. 1388 Configuration of a router device requires two levels of connectivity. 1389 First the router must achieve connectivity at the network layer and 1390 obtain one or more IP addresses. Secondly the router must connect at 1391 the logical level and determine the function that it is to perform 1392 within the network. 1394 Today only the first of these steps is supported. Logical 1395 configuration is the task of the administrator. Yet all the 1396 information that is necessary to configure the network is available 1397 within the network itself. This information may be collected by one 1398 or more network description services discoverable through extended 1399 DNS service discovery and maintained using existing protocols such as 1400 SNMP. 1402 When a router device connects to a network it first performs network 1403 layer configuration via DHCP. The device then performs discovery for 1404 SRS services on each interface on which DHCP succeeds and registers 1405 its device description information, including the ability to accept 1406 ARP, BGP or other routing protocol commands. 1408 9.4. Wireless Devices 1410 The power and simplicity of DHCP is due in large measure to the fact 1411 that when a device attaches to a wired network such as Ethernet the 1412 physical network connection maps unambiguously to a single logical 1413 network. 1415 This situation does not apply in the case of a wireless network. At 1416 any one time there may be between zero, one or many wireless networks 1417 available. Moreover a typical mobile device connects to many 1418 different networks as it shuffles between meeting rooms, home, coffee 1419 shops, airports and hotels. 1421 Connection of a wireless device to a network requires two separate 1422 access control steps. The device must establish that it is joining 1423 the right network; the network must determine that the device is 1424 permitted to join. 1426 Simplification of the network access mechanism is highly desirable 1427 but oversimplification can lead to a lack of mutual authentication 1428 capability. The security offered by Bluetooth's 'device pairing' 1429 mode is neither convincing nor user friendly. It is now common for 1430 Bluetooth devices to dispense with the device authentication code 1431 intended to provide a measure of security and use the password '0000' 1432 for every device. 1434 In the case of a laptop seeking Internet access in a hotel or coffee 1435 shop the laptop is not so much concerned as to which network it 1436 connects to as whether the network connection is reliable, secure and 1437 offers adequate signal strength. The network provider on the other 1438 hand may want the ability to restrict access capability in certain 1439 ways such as only offering free service to customers or guests. In 1440 some cases the network provider may require payment. 1442 Access control requirements of this type, where there is a potential 1443 choice between networks and a rich scope for user interaction are 1444 outside the scope of this document. Of more direct concern is the 1445 case of connecting devices such as network attached storage, printers 1446 and routers, devices whose function requires a minimal user 1447 interface. 1449 While a device that does not support a keyboard or display can 1450 nevertheless expose a rich user interface through an embedded Web 1451 Server, such services have no functionality until basic network 1452 functionality is achieved. Configuration of such devices today 1453 typically requires connection to a host that is temporarily 1454 configured to use a compatible network IP subnet. Product reviews of 1455 devices that require this mode of configuration written by consumers 1456 demonstrates that this approach is beyond the typical user's 1457 tolerance level. 1459 A better approach to the configuration of wireless devices is to 1460 install necessary configuration data on a mobile storage device such 1461 as a USB flash memory device. Such a device could be manufactured at 1462 minimal cost and supplied with the network access point. A device 1463 that offered the ability to perform public key authentication would 1464 offer additional security benefits. As the device would be a 1465 standardized commodity additional devices would be readily obtainable 1466 from the usual range of suppliers. 1468 In order to configure a device for use with their wireless network 1469 the network installer would first 'prime' the storage device by 1470 plugging it into the receptacle on the principle access point. The 1471 access point would then transfer all the information necessary to 1472 connect a new device to the network. 1474 In order to connect a device to the network the network installer 1475 would place the storage device in the corresponding receptacle on the 1476 device being installed. The device would then obtain all the 1477 information necessary to connect to the correct wireless network 1478 including authentication. 1480 Once connected the new device would advertise the services it 1481 provides and requires to the network using SRS as described in the 1482 previous examples. Depending on the site security policy these 1483 services might become available immediately or require authorization 1484 by an administrator. 1486 10. Peer to Peer Incident Handling 1488 Earlier we saw that the service discovery mechanism could be extended 1489 to allow lookup by IP address rather than domain name alone by using 1490 the Reverse DNS. While domain names are clearly the preferred 1491 mechanism for discovery of primary services it is frequently 1492 desirable to report exceptions on the basis of IP Address. 1494 10.1. Contacting Source of Attack by IP Address 1496 10.2. Mitigating Spoofed Source Address Packets 1498 11. Further Work 1500 11.1. Maintenance 1502 11.1.1. Identify cause and location of network faults 1504 The current proposal is designed to simplify the problem of network 1505 configuration, in particular the commissioning and removal of new 1506 network devices and services. Another principal concern of network 1507 managers is locating and responding to faults caused by 1508 malfunctioning devices, broken cables or interference. 1510 The tools described in this document provide a means of collecting an 1511 maintaining a high level description of the expected configuration 1512 and it is thus to be hoped that the task of identifying discrepancies 1513 between the expected and actual configurations is simplified. 1515 12. Security Considerations 1517 The security considerations described in this section are summaries 1518 of the architectural issues raised elsewhere in the document. 1519 Whenever the domain centric architecture is applied to a specific 1520 Internet protocol a full security analysis and review MUST be 1521 performed. 1523 12.1. Reliance on Security of the DNS 1525 The Domain Centric model relies on the DNS as the principle point of 1526 control and administration of the network. The use of DNSSEC to 1527 secure the DNS system SHOULD be considered an operational necessity. 1529 12.2. Security of DNS Updates 1531 The Domain Centric Model increases reliance on the mechanisms used to 1532 feed data into the DNS. Whether this is achieved directly through 1533 DNS zone transfer or indirectly through a mechanism such as LDAP or 1534 the Service Registration Service described above all updates must be 1535 authenticated and subject to control by the site authorization 1536 policy. 1538 12.3. Consolidation of Control 1540 The Domain Centric model increases the control exerted by the 1541 controller of the domain name. In the domain centric model the only 1542 choice for a user who does not control their own domain name 1543 configuration is to obtain their own domain name that they can 1544 control themselves. 1546 13. Conclusions 1548 Domain Centric administration is an incremental evolution of 1549 traditional network management practices that allows network 1550 management to be simplified and automated. While the principles 1551 described are applicable to any network protocol it is most likely 1552 that initial deployment would be seen in the field of Web Services 1553 where the current problem faced by the field is the management of 1554 large numbers of protocols that are each undergoing rapid evolution. 1556 14. Acknowledgements 1558 The ideas in this document arose from extensive discussions with the 1559 DKIM amd DNSEXT working groups. 1561 15. IANA Considerations 1563 This document requires no IANA actions. 1565 16. Normative References 1567 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1568 Requirement Levels", BCP 14, RFC 2119, March 1997. 1570 Author's Address 1572 Phillip Hallam-Baker 1573 VeriSign Inc 1575 Email: pbaker@verisign.com 1577 Full Copyright Statement 1579 Copyright (C) The IETF Trust (2007). 1581 This document is subject to the rights, licenses and restrictions 1582 contained in BCP 78, and except as set forth therein, the authors 1583 retain all their rights. 1585 This document and the information contained herein are provided on an 1586 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1587 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1588 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1589 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1590 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1591 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1593 Intellectual Property 1595 The IETF takes no position regarding the validity or scope of any 1596 Intellectual Property Rights or other rights that might be claimed to 1597 pertain to the implementation or use of the technology described in 1598 this document or the extent to which any license under such rights 1599 might or might not be available; nor does it represent that it has 1600 made any independent effort to identify any such rights. Information 1601 on the procedures with respect to rights in RFC documents can be 1602 found in BCP 78 and BCP 79. 1604 Copies of IPR disclosures made to the IETF Secretariat and any 1605 assurances of licenses to be made available, or the result of an 1606 attempt made to obtain a general license or permission for the use of 1607 such proprietary rights by implementers or users of this 1608 specification can be obtained from the IETF on-line IPR repository at 1609 http://www.ietf.org/ipr. 1611 The IETF invites any interested party to bring to its attention any 1612 copyrights, patents or patent applications, or other proprietary 1613 rights that may cover technology that may be required to implement 1614 this standard. Please address the information to the IETF at 1615 ietf-ipr@ietf.org. 1617 Acknowledgment 1619 Funding for the RFC Editor function is provided by the IETF 1620 Administrative Support Activity (IASA).