idnits 2.17.1 draft-ietf-zeroconf-reqts-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references (RFC, [RFC1034,, 1035], [RFC2131], [RFC2730], [RFC2251]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 4 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 126 has weird spacing: '...in this docum...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC 2401' is defined on line 769, but no explicit reference was found in the text == Unused Reference: 'RFC 2462' is defined on line 779, but no explicit reference was found in the text -- Duplicate reference: RFC1034, mentioned in 'RFC 1035', was also mentioned in 'RFC 1034'. ** Obsolete normative reference: RFC 1827 (Obsoleted by RFC 2406) ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2251 (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 2541 (Obsoleted by RFC 4641) == Outdated reference: A later version (-03) exists of draft-holbrook-ssm-arch-02 -- Possible downref: Normative reference to a draft: ref. 'SSM' Summary: 13 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Zeroconf WG M. Hattig 3 Internet Engineering Task Force Editor 4 INTERNET DRAFT Intel Corp. 5 August 31, 2001 Expires in six months 7 Zeroconf IP Host Requirements 8 draft-ietf-zeroconf-reqts-09.txt 10 Status of This Memo 12 This document is a submission by the Zeroconf Working Group of the 13 Internet Engineering Task Force (IETF). Comments should be submitted 14 to the zeroconf@merit.edu mailing list. 16 Distribution of this memo is unlimited. 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of [RFC 2026]. Internet-Drafts are 20 working documents of the Internet Engineering Task Force (IETF), its 21 areas, and its working groups. Note that other groups may also 22 distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at: 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at: 33 http://www.ietf.org/shadow.html. 35 Abstract 37 Many common TCP/IP protocols such as DHCP [RFC 2131], DNS [RFC 1034, 38 RFC 1035], MADCAP [RFC 2730], and LDAP [RFC 2251] must be configured 39 and maintained by an administrative staff. This is unacceptable for 40 emerging networks such as home networks, automobile networks, 41 airplane networks, or ad hoc networks at conferences, emergency 42 relief stations, and many others. Such networks may be nothing more 43 than two isolated laptop PCs connected via a wireless LAN. For all 44 these networks, an administrative staff will not exist and the users 45 of these networks neither have the time nor inclination to learn 46 network administration skills. Instead, these networks need protocols 47 that require zero user configuration and administration. This 48 document is part of an effort to define such zero configuration 49 (zeroconf) protocols. 51 Before embarking on defining zeroconf protocols, protocol 52 requirements are needed. This document states the zeroconf protocol 53 requirements for four protocol areas; they are: IP interface 54 configuration, translation between host name and IP address, IP 55 multicast address allocation, and service discovery. This document 56 does not define specific protocols, just requirements. The 57 requirements for these four areas result from examining everyday use 58 or scenarios of these protocols. 60 Table of Contents 62 1 Introduction................................................2 63 1.1 Key Words.................................................3 64 1.2 Reading This Document.....................................3 65 1.3 Zeroconf Coexistence......................................3 66 1.4 Scalability...............................................4 67 1.5 Routable Protocol Requirement.............................4 68 1.6 Conflicts and State Changes Requirement...................4 69 2 Scenarios & Requirements....................................4 70 2.1 IP Interface Configuration................................5 71 2.1.1 IP Packet-Sending.......................................5 72 2.1.2 Bridge Installed........................................5 73 2.1.3 IPv6 Considerations.....................................6 74 2.2 Translation between Host name and IP Address Scenarios....6 75 2.2.1 Web Browsing............................................6 76 2.2.2 Host name Selection.....................................7 77 2.2.3 IPv6 Considerations.....................................7 78 2.3 IP Multicast Address Allocation Scenarios.................7 79 2.3.1 Scope Enumeration.......................................8 80 2.3.2 Address Selection.......................................8 81 2.3.3 Multiple Source.........................................9 82 2.3.4 IPv6 Considerations.....................................9 83 2.4 Service Discovery Scenarios...............................9 84 2.4.1 Printer Service........................................10 85 2.4.2 IPv6 Considerations....................................10 86 3 Security Considerations....................................10 87 3.1 IP interface configuration...............................11 88 3.2 Name to Address Resolution...............................12 89 3.3 Multicast Address Allocation.............................13 90 3.4 Service Discovery........................................13 91 4 IANA Considerations........................................14 92 5 Full Copyright Statement...................................14 93 6 Acknowledgements...........................................14 94 7 References.................................................15 96 1 Introduction 98 A zeroconf protocol is able to operate correctly in the absence of 99 configured information from either a user or infrastructure 100 services such as conventional DHCP [RFC 2131] or DNS [RFC 1034, RFC 101 1035] servers. Zeroconf protocols may use configured information, 102 when it is available, but do not rely on it being present. The use 103 of MAC addresses (i.e. layer two addresses) as parameters in 104 zeroconf protocols is generally acceptable because they are 105 globally unique and readily available on most devices of interest. 107 The benefits of zeroconf protocols over existing configured 108 protocols are an increase in the ease-of-use for end-users and 109 a simplification of the infrastructure necessary to operate 110 protocols. 112 This document discusses requirements for zeroconf protocols in 113 four areas: 115 - IP interface configuration 116 - Translation between host name and IP address 117 - IP multicast address allocation 118 - Service discovery 120 Security considerations are also discussed. 122 1.1 Key Words 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 125 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 126 in this document are to be interpreted as described in [RFC 2119]. 128 1.2 Reading This Document 130 Introduction, Scenarios & Requirements, and Security 131 Considerations are the major sections of this document. 133 The Scenarios & Requirements section walks through protocol 134 scenarios and then lists the requirements of the protocol needed 135 to accomplish the scenario. 137 The Security Consideration section lists security issues with 138 zeroconf protocols. 140 Requirements dispersed throughout this document begin with the 141 text "Requirements:" or "Requirement:" on a single line, which is 142 followed by a bulleted list of requirements. 144 1.3 Zeroconf Coexistence 146 It is not necessary to simultaneously use zeroconf protocols in 147 all four areas (i.e. IP interface configuration, translation 148 between host name and IP address, IP multicast address allocation, 149 service discovery). For example, it might make sense on some 150 networks to provide a DHCP server for configured IP interface 151 configuration, but perform translation between host name and IP 152 address using a zeroconf protocol. 154 1.4 Scalability 156 The primary reasons to deploy Zeroconf protocols are simplicity 157 and ease-of-use. Scalability is important but it is a secondary 158 goal. Thus, scalability should not detract from the primary goals 159 of simplicity and ease-of-use. 161 1.5 Routable Protocol Requirement 163 If a protocol is intended to span multiple IP subnets it MUST 164 NOT use broadcasts or link-local addressing. 166 Requirement: 167 - Protocols intended to span multiple IP subnets MUST NOT use 168 broadcasts or link-local addressing. 170 1.6 Conflicts and State Changes Requirement 172 Topology changes or other events such as adding and removing hosts 173 may cause conflicts and state changes within a protocol. Zeroconf 174 protocols must be able to resolve conflicts and state changes caused 175 by topology changes or other events. The scenario in the 2.1.2 Bridge 176 Installed section is the only scenario that illustrates the need for 177 this requirement, thus the below requirement is duplicated in section 178 2.1.2. However, this requirement applies to all protocol areas. 180 Address configuration detects and eliminates duplicate addresses. 182 Name resolution allows resolution of names which could not 183 previously be resolved. In particular, if a host wishes to resolve 184 its own name to determine if it unique, it will be able to detect 185 if responder indicates that it is not. 187 Service discovery allows discovery of previously undiscovered 188 services. 190 Multicast address allocation detects and eliminates duplicate 191 address allocations. 193 Requirement: 194 - MUST respond to state changes and resolve conflicts in a timely 195 manner. 197 2 Scenarios & Requirements 199 This section contains a subsection for each of the four protocol 200 areas. Within each subsection, terms and assumptions are followed 201 by specific representative scenarios that lead to zeroconf 202 protocol requirements in that area. Each subsection ends with 203 IPv6 considerations. 205 2.1 IP Interface Configuration 207 In this document, IP interface configuration always includes the 208 configuration of an IP address and netmask; it may include some 209 routing information (such as default route). IP interface 210 configuration is needed before almost any IP communication can take 211 place. 213 Terms: 215 IP subnet - A single logical IP network that may span multiple 216 link layer networks. All IP hosts on the IP subnet communicate 217 without any layer 3 forwarding device (e.g. router). 219 internetwork - Multiple IP subnets connected by routers. 221 network - context sensitive term that may apply to one or more 222 of the terms: a link layer network, an IP subnet, or an 223 internetwork. 225 bridge - a networking device that connects two link layer 226 networks by using only link-layer protocols (e.g. Ethernet). 228 The IP interface configuration scenarios are two IP packet-sending 229 scenarios and a bridge install scenario. 231 2.1.1 IP Packet-Sending 233 These scenarios consist of sending an IP packet from one host to 234 another. These scenarios apply to any IP packets with a unicast 235 destination IP address. There are two sub-scenarios. In the first, 236 both the sender of the IP packet and the receiver of the IP packet 237 are on the same IP subnet. In the second, the two senders are on 238 different IP subnets within an internetwork. 240 Requirements: 241 - MUST configure an appropriate netmask. 242 - MUST have unique IP addresses within an IP subnet. 243 - MUST allow configuration of zero or more gateways 244 (for the internetwork scenario). 245 - MUST have unique IP subnets within an internetwork (This is 246 only for the case when there is one or more router attached in 247 the network where autoconfigured hosts. How routers obtain 248 their configuration is beyond of the scope of this document.) 250 2.1.2 Bridge Installed 252 This scenario starts with two completely operational link-layer 253 networks with two distinct IP networks in which IP interface 254 configuration was completed with a zeroconf protocol on each 255 network. These two link-layer networks logically become a single 256 link-layer network after a newly installed bridge connects them. 257 Somehow the hosts operating on the two IP networks must now 258 configure themselves to operate as a single IP network. Since the 259 bridge connects the networks at the link-layer, there is no change 260 in link status from off to on, which is the usual signal used in 261 Ethernet networks for IP hosts to configure. 263 Topology changes or other events such as adding and removing hosts 264 may cause changes to the overall system state, invalidate 265 assumptions made by some protocols, and lead to incorrect or 266 undesirable operating states. Zeroconf protocols must be able to 267 detect and resolve conflicts and state changes caused by topology 268 changes or other events in some cases. The scenario in the 2.1.2 269 Bridge Installed section is the only scenario that illustrates the 270 need for this requirement, thus the below requirement is duplicated 271 in section 2.1.2. However, this requirement applies to all protocol 272 areas. 274 Requirement: 275 - MUST resolve conflicts and state changes in a timely manner. 277 2.1.3 IPv6 Considerations 279 IPv6 allows a host to select an appropriate IP address and netmask, 280 using available routing information, thus if a host is using IPv6, 281 a zeroconf IP interface configuration solution already exists. 283 2.2 Translation between Host name and IP Address Scenarios 285 Host names allow users to refer to hosts using names instead of IP 286 addresses. This is among the most fundamental, thus most important, 287 usage paradigms in TCP/IP networking. 289 Terms: 291 host name - A textual name that allows a user to refer to a host 292 by name rather than IP address. 294 domain name - Zero or more textual labels, separated by dots, 295 that identify a DNS domain [RFC 1034] [RFC 1035]. 297 resolver - The host needing a name to IP address translation. 299 The scenario for translation between host name and IP address is 300 Web browsing. In addition, host name selection is discussed. 302 2.2.1 Web Browsing 304 Applications, such as web browsers, make extensive use of DNS 305 resolver functions. A mechanism to support DNS resolver 306 interfaces in the zero configuration environement is required. 308 Requirement: 309 - MUST support DNS application layer interfaces as described 310 in RFC 1123, section 6.1. [RFC 1123] 312 2.2.2 Host Name Selection 314 How the host is administratively assigned a domain name is determined 315 by some other configuration protocol or user configuration, and is 316 not part of this zeroconf scenario. A protocol must allow a host 317 to determine if its name is unique. If the name is not unique, the 318 protocol must notify the user or some IP interface configuration 319 software to select another name then repeat the process of verifying 320 the uniqueness of the name. 322 Requirement: 324 - MUST allow a host to determine if its name is unique. Then if 325 not unique, notify the user or configuration software so that 326 another name may be chosen and similarly verified. 328 2.2.3 IPv6 Considerations 330 Protocols to perform translation between host name and IP address 331 have no zeroconf-related differences for IPv4 and IPv6. 333 2.3 IP Multicast Address Allocation Scenarios 335 IP Multicast is used to conserve bandwidth for multi-receiver 336 bulk-delivery applications, such as audio, video, or news. 338 IP Multicast is also used to perform a logical addressing function. 339 For example, when a host needs to communicate with local routers, it 340 can send packets to the all-routers multicast address without having 341 to know in advance the IP address(es) of the router(s). 343 IPv4 multicast addresses range from 224.0.0.0 to 239.255.255.255. 345 [RFC 2365] defined multicast scopes are: 346 node-local (unspecified for IPv4) 347 link-local (224.0.0.0/24) 348 local (239.255.0.0/16) 349 site-local (unspecified for IPv4) 350 organizational-local (239.192.0.0/14) 351 global (224.0.1.0-238.255.255.255) 353 A relative assignment is an integer offset from the highest address 354 in the scope and represents a 32-bit address. For example, within the 355 local scope, 239.255.255.0/24 is reserved for relative allocations. 357 Source-Specific Multicast [SSM] addresses are 232.0.0.0 to 358 232.255.255.255. 360 Unicast-prefix-based IPv6 multicast addresses are defined, as 361 well as source-specific multicast addresses for IPv6, in [SS6]. 363 Assumptions: 364 - The node-local and SSM addresses require no protocol or 365 interaction between multiple hosts, thus are not mentioned 366 further in this document. 367 - Global and organizational scoped addresses are meant for 368 networks of a greater scale than zeroconf protocols, thus are 369 not mentioned further in this document. 370 - Only local, link-local and site-local scopes are considered 371 further in this document. 372 - If it is desirable to restrict multicast packets from entering 373 and leaving a multicast scope boundary, it is assumed that the 374 router at the boundary is a "boundary router" as described in 375 [RFC 2365]. 377 Scenarios are scope enumeration, address allocation, and multiple 378 sources. 380 2.3.1 Scope Enumeration 382 Applications that leave the choice of scope up to the user require 383 the ability to enumerate what scopes the host is operating within. 384 In addition, services that are assigned relative addresses require 385 the ability to enumerate what scopes the host is within; only then 386 will a host be able to apply the relative address to a scope. 388 Requirements: 389 Application support software used to autoconfigure multicast 390 addresses 391 - MUST list which of the scopes (local, link-local, or site-local) 392 are available for hosts. 393 - MUST list per-scope address ranges that may be allocated. 395 2.3.2 Address Allocation 397 IP multicast address allocation (local, link-local and site-local 398 scopes only) requires an application to be able to request the use 399 of a suitable multicast address. Coordination among applications 400 must occur to avoid conflicting allocations of the same address. 401 This coordination must span the entire scope respective to the 402 address. When an allocated address is no longer required, that 403 address MUST become available for use again. 405 Requirements: 406 - MUST select a multicast address. 407 - MUST prevent conflicting allocations of the same address. 408 - MUST allow the multicast address to become available after the 409 address is no longer in use. 411 2.3.3 Multiple Source 413 An intercom system inside a home is an example of a multiple 414 source IP multicast application. In this type of application, 415 several sources may be sending packets destined to the same IP 416 multicast address. 418 This multiple source example illustrates the problem that a 419 particular address may continue to be valid, even after the host 420 that initially allocated the address is no longer present; the 421 zeroconf multicast address allocation must correctly support this 422 type of operation. In other words, if a host allocates a multicast 423 address, then leaves the multicast group, some other host must 424 defend the address. 426 Requirements: 427 - A host other than the allocating host MUST be able to defend 428 or otherwise maintain the allocation of a multicast address. 430 2.3.4 IPv6 Considerations 432 To date, no range has been reserved for source-specific addresses 433 in IPv6. See [SS6]. Hence, until such a range is reserved, dynamic 434 allocation of source-specific addresses applies only to IPv4. 436 To date, no range has been reserved for dynamic allocation of 437 Link-scoped addresses in IPv4. Hence, unless such a range is 438 reserved, dynamic allocation of link-scoped addresses applies only 439 to IPv6. 441 2.4 Service Discovery Scenarios 443 Service discovery protocols allow users or software to discover and 444 select among available services. This removes the requirement that 445 the user or client software know a server's location in advance in 446 order for the cleint to communicate with the server. 448 Terms: 450 service - a particular logical function that may be invoked via 451 some network protocol, such as printing, storing a file on a 452 remote disk, or even perhaps requesting delivery of a pizza. 454 service characteristics - Characteristics provide a finer 455 granularity of description to differentiate services beyond just 456 the service type. For example if the service type is printer, 457 the characteristics may be color, pages printed per second, 458 location, etc. 460 service discovery protocol - A service discovery protocol 461 enables clients to discover servers (or peers to find other 462 peers) of a particular service. A service discovery protocol is 463 an application layer protocol that relies on network and 464 transport protocol layers. 466 service protocol - A service protocol is used between the client 467 and the server after service discovery is complete. 469 The scenarios are the discovery of a simple printer service. 471 2.4.1 Printer Service 473 Network-enabled printers allow various network clients to submit 474 print jobs. A service discovery protocol MUST allow a printer 475 service to be discovered by devices needing to print. This requires a 476 service type as well as a service identifier to distinguish instances 477 of a single service type. Service discovery MUST be independent from 478 any particular printing protocol such as lpd, raw-tcp, ipp. 480 Printers vary in their characteristics such as location, status, 481 dots per inch, etc. Discovering a service based on these 482 characteristics SHOULD be part of the service discovery protocol. 484 Service discovery MUST complete in a timely (10s of seconds) manner. 486 Requirements: 487 - MUST allow a service to be discovered. 488 - MUST discover via service identifier and/or service type. 489 - MUST discover services without use of a service-specific protocol. 490 - SHOULD discover via service characteristics. 491 - MUST complete in a timely (10s of seconds) manner. 493 2.4.2 IPv6 Considerations 495 Service discovery protocols have no zeroconf related differences 496 for IPv4 and IPv6. 498 3 Security Considerations 500 The principal goal of Zero Configuration protocols is to provide 501 network configuration where existing configuration and 502 configuration services are unavailable. This is at odds with 503 secure operation since security mechanisms generally require some 504 pre-configuration (such as keys, certificates, etc.). 506 Generally speaking, security mechanisms in IETF protocols are 507 mandatory to implement. A particular implementation might permit 508 a network administrator to turn off a particular security mechanism 509 operationally. However, implementations should be "secure out of the 510 box" and have a safe default configuration. 512 Zeroconf protocols MUST NOT be any less secure than related 513 current IETF-Standard protocols. This consideration overrides the 514 goal of allowing systems to obtain configuration automatically. 515 This section explicitly describes what this requires of each 516 protocol area. 518 Security threats to be considered include both active attacks 519 (e.g. denial of service) and passive attacks (e.g. eavesdropping). 520 Protocols that require confidentiality and/or integrity should 521 include integrated confidentiality and/or integrity mechanisms or 522 should specify the use of existing standards-track security 523 mechanisms (e.g. TLS [RFC 2246], ESP [RFC 1827], AH [RFC 2402]) 524 appropriate to the threat. 526 3.1 IP interface configuration 528 Specific risks arise due to not securing IP interface configuration. 529 An active attacker could completely or selectively prevent hosts from 530 being properly configured. If an attacker 'hoards' all IP addresses, 531 inappropriately claiming to be configured with them, this would 532 prevent other hosts from effectively participating in IP interface 533 configuration. 535 An active attacker could be more selective and instead of claiming 536 it has all IP addresses, it could claim this only in response to 537 requests from a specific host (or hosts) to deny them service. It 538 might also be possible that an active attacker could partially 539 misconfigure one or more victims to cause these nodes to have 540 partial (but not full) use of the network service. 542 IP communication relies on lower level address resolution protocols 543 (ARP [RFC 826] or IPv6 Neighbor Discovery [RFC 2461]). In the case 544 of ARP and its cousins (e.g. inverse ARP, reverse ARP, proxy ARP), 545 there is no standard security mechanism. Neither the integrity of 546 the message is checked nor is the identity of the message source 547 authenticated. This makes it possible for an active attack to subvert 548 these protocols. Since the scope of these protocols is limited to 549 a single broadcast network, the potential range of the risk due to 550 this attack is limited. The effect of the attack, however, is to 551 potentially disrupt all communication on the local link. 553 It is appropriate not to require IP interface configuration 554 protocols to implement security mechanisms when these hosts (and 555 others) will then proceed to perform subsequent communication 556 using insecure mechanisms such as ARP. Thus hosts using insecure 557 IP interface configuration are ultimately no more vulnerable to 558 attack than other hosts on the network configured using some other 559 more secure mechanism. The security requirements demand that 560 zeroconf protocols MUST NOT compromise security if security is 561 deployed. In the case of IPv4, it is acceptable (though not 562 desirable) for interface configuration to fail to defend against 563 attack from other hosts on the same physical link, since these 564 hosts are already in a position to subvert IPv4 ARP anyway, so 565 securing the interface configuration protocol would not prevent 566 them disrupting subsequent IPv4 communications. For that reason 567 the IPv4 interface configuration protocol MAY include no defence 568 against attack from other hosts on the same physical link. 570 Since ARP is insecure, dynamic configuration of IPv4 link-local 571 addresses MAY be, as well. IPv6 datagrams may be transported over 572 IPv4 so care is needed to not compromise security requirements for 573 IPv6 in this case. 575 In the case of IPv6 Neighbor Discovery, this protocol can be 576 secured as it uses ICMPv6 messages, which run over IP. IPv6 577 Neighbor Discovery messages can thus be protected for integrity 578 and endpoint authentication using IP Security. [RFC 2401, 2402, 579 2403, 2404] 581 3.2 Name to Address Resolution 583 The security implications of this zeroconf protocol must be 584 compared against the DNS protocol. 586 DNS is a client-server protocol. The zeroconf name to address 587 translation protocol will likely use multicast so that any host 588 may respond to queries. This broadens the possibility that host 589 authentication in the form of hostname-IP address mappings may be 590 compromised, since all hosts effectively may behave as DNS servers. 592 Currently it is possible to subvert DNS in various ways, unless 593 DNSsec [RFC 2535, RFC 2931] is used. For example: 595 - A client may be configured with the address of an attacker's DNS 596 server. For example, an active attacker on the same subnet as the 597 client may respond to DHCP DHCPDISCOVER messages and deliberately 598 configure the client to use a compromised DNS server. 600 - An active attack against a DNS client is possible - where an 601 attacker unicasts a DNS reply to a client request that arrives 602 at the client before the legitimate server's response. 604 DNSsec protects against such attacks as the client can verify that 605 the data it retrieves using the DNS has been signed from a source 606 that the client has been configured to accept. 608 A zeroconf name to address resolution protocol MUST be compatible 609 with the use of DNSsec. Therefore it MUST be possible for a host 610 running a zeroconf protocol to use DNS and DNSsec for authenticated 611 name resolution if that host (or its administrator) chooses to do so. 612 [RFC 2541] 614 3.3 Multicast Address Allocation 616 The zeroconf multicast address allocation protocol MUST NOT be 617 less secure than MADCAP [RFC 2730]. These are the IETF standards 618 track protocols for Multicast Address Allocation. 620 The threat of using an insecure Multicast Address Allocation protocol 621 is that an active attacker could 'hoard' all multicast addresses - 622 inappropriately claiming to have allocated them. This would prevent 623 other hosts from effectively participating in the Multicast Address 624 Allocation protocol. This could be done to stop all participation or 625 selectively, to prevent particular hosts from allocating addresses. 627 MADCAP does not include mechanisms for protecting message integrity 628 or endpoint authentication. This protocol suggests the use of 629 IPsec for this purpose, as MADCAP is compatible with the IP 630 Authentication Header. A zeroconf multicast address allocation 631 protocol MUST either be compatible with IP AH or provide another 632 mechanism for optional-to-use (but mandatory to implement) 633 authentication. 635 3.4 Service Discovery 637 The zeroconf service discovery protocol MUST NOT be less secure 638 than the IETF standard service discovery protocol: The Service 639 Location Protocol, Version 2 [RFC 2608] (SLPv2). 641 The threat posed by using an insecure service discovery protocol is 642 that unauthorized entities may participate. A client may be misled 643 to communicate with a host that has been compromised or that offers 644 an antagonistic server that the client did not intend to use. This 645 might be easy to detect (e.g. after attempting to use a printer 646 that doesn't exist, no paper will appear.) This may also be 647 difficult to detect (e.g. an illegitimate server copies all data 648 for an attacker's subsequent perusal and the user has no way of 649 knowing). 651 A client could still detect that it is communicating with an 652 unauthorized server, but that would require authentication and 653 authorization mechanisms at a higher level (the client-server 654 protocol). 656 SLPv2 protects against the threat of discovery of unauthorized 657 services. SLPv2 messages that contain an answer may include an 658 associated authorization block. This allows a client receiving a 659 message to verify the answer, using digital signatures and a 660 certificate-based system as the basis for authorization. Other 661 mechanisms are possible. 663 A zeroconf service discovery protocol MUST allow a client to 664 verify that a service advertisement sent by a server was created 665 by an authorized source. 667 4 IANA Considerations 669 No known IANA considerations arise from this document. 671 5 Full Copyright Statement 673 Copyright (C) The Internet Society (2000). All Rights Reserved. 675 This document and translations of it may be copied and furnished 676 to others, and derivative works that comment on or otherwise 677 explain it or assist in its implementation may be prepared, 678 copied, published and distributed, in whole or in part, without 679 restriction of any kind, provided that the above copyright notice 680 and this paragraph are included on all such copies and derivative 681 works. However, this document itself may not be modified in any 682 way, such as by removing the copyright notice or references to the 683 Internet Society or other Internet organizations, except as needed 684 for the purpose of developing Internet standards in which case the 685 procedures for copyrights defined in the Internet Standards 686 process must be followed, or as required to translate it into 687 languages other than English. 689 The limited permissions granted above are perpetual and will not 690 be revoked by the Internet Society or its successors or assigns. 692 This document and the information contained herein is provided on 693 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 694 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 695 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 696 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 697 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 698 PURPOSE." 700 6 Acknowledgements 702 Thanks to Peter Ford and Stuart Cheshire for hosting the NITS 703 (Networking In The Small) BOF that was the catalyst to forming the 704 Zeroconf Working Group. 706 Thanks to Erik Guttman and Stuart Cheshire for forming and 707 chairing the Zeroconf Working Group, which is responsible for this 708 document. 710 Thanks to Erik Guttman for providing key input to the service 711 discovery and the security sections. 713 Thanks to Dave Thaler for providing key input to the IP multicast 714 address allocation sections. 716 Thanks to Stuart Cheshire for providing key input to the 717 introduction and IP interface configuration sections. 719 Additional recognition goes the following people for their 720 influential contributions to this document and its predecessors: 721 Brent Miller, Thomas Narten, Marcia Peters, Bill Woodcock, Bob 722 Quinn, John Tavs, Matt Squire, Daniel Senie, Cuneyt Akinlar, Karl 723 Auerbach, Kanchei Loa, Dongyan Wang, James Kempf, Yaron Goland, 724 and Bernard Aboba, Ran Atkinson. 726 Editor: 728 Myron Hattig 729 Intel Corporation 730 3585 SW 198th Avenue 731 Aloha, OR 97007 732 myron.hattig@intel.com 734 7 References 736 [RFC 826] D. Plummer, "An Ethernet Address Resolution Protocol", 737 RFC 826, November 1982. 739 [RFC 1034] P. Mockapetris, "Host names - Concepts and 740 Facilities", RFC 1034, November 1987 742 [RFC 1035] P. Mockapetris, "Host names - Implementations and 743 Specifications", RFC 1034, November 1987 745 [RFC 1123] B. Braden, "Requirements for Internet Hosts -- 746 Application and Support", RFC 1123, October 1989 748 [RFC 1827] R. Atkinson, "IP Encapsulating Security Payload", RFC 749 1827, Aug 1995 751 [RFC 2026] S. Bradner, "The Internet Standards Process -- 752 Revision 3", RFC 2026 Oct 1996 754 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate 755 Requirement Levels", RFC 2119, March 1997. 757 [RFC 2131] R. Droms, "Dynamic Host Configuration Protocol", RFC 758 2131, March 1997. 760 [RFC 2246] T. Dierks, C. Allen, "Transport Layer Security", RFC 761 2246, Jan 1999. 763 [RFC 2251] M. Wahl, T. Howes, and S. Kille, "Lightweight 764 Directory Access Protocol (v3)", RFC 2251, Dec 1997. 766 [RFC 2365] D. Meyer, "Administratively Scoped Multicast Address", 767 RFC 2365,July 1998. 769 [RFC 2401] S. Kent, R. Atkinson, "Security Architecture for the 770 Internet Protocol", RFC 2401 November 1998 772 [RFC 2402] S. Kent, R. Atkinson, "IP Authentication Header", RFC 773 2402 November 1998 775 [RFC 2461] T. Narten, E. Nordmark, W. Simpson, "Neighbor 776 Discovery for IP Version 6 (IPv6)", RFC 2461, 777 December 1998. 779 [RFC 2462] S. Thomson, T. Narten, "IPv6 Stateless Address 780 Autoconfiguration", RFC 2462, December 1998 782 [RFC 2535] D. Eastlake, "Domain Name System Security Extensions", 783 RFC 2535, March 1999. 785 [RFC 2541] D. Eastlake, "DNS Security Operational 786 Considerations", RFC 2541, March 1999 788 [RFC 2608] E. Guttman, et al, "Service Location Protocol, 789 Version 2", RFC 2608, June 1999 791 [RFC 2730] S. Hanna, B. Patel, M. Shah, "Multicast Address 792 Dynamic Client Allocation Protocol (MADCAP)", RFC 793 2730, Dec 1999. 795 [RFC 2931] D. Eastlake, "DNS Request and Transaction Signatures ( 796 SIG(0)s )", RFC 2931, September 2000 798 [SSM] H. Holbrook, B. Cain, "Source-Specific Multicast for 799 IP", draft-holbrook-ssm-arch-02.txt, March 2001. A 800 work in progress. 802 [SS6] B. Haberman, D. Thaler, "Unicast-Prefix-based IPv6 803 Multicast Addresses", draft-ietf-ipngwg-uni-based- 804 mcast-02.txt, June 2001, A work in progress.