idnits 2.17.1 draft-ietf-zeroconf-reqts-08.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 114 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.) -- The document date (May 23, 2001) is 8375 days in the past. Is this intentional? 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 732, but no explicit reference was found in the text == Unused Reference: 'RFC 2462' is defined on line 742, 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 (-04) exists of draft-holbrook-ssm-00 -- Possible downref: Normative reference to a draft: ref. 'SSM' -- Possible downref: Normative reference to a draft: ref. 'AAP' Summary: 13 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Zeroconf WG M. Hattig 2 Internet Engineering Task Force Editor 3 INTERNET DRAFT Intel Corp. 4 Expires Nov 2001 May 23, 2001 6 Zeroconf Requirements 7 draft-ietf-zeroconf-reqts-08.txt 9 Status of This Memo 11 This document is a submission by the Zeroconf Working Group of the 12 Internet Engineering Task Force (IETF). Comments should be 13 submitted to the zeroconf@merit.edu mailing list. 15 Distribution of this memo is unlimited. 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of [RFC 2026]. Internet-Drafts are 19 working documents of the Internet Engineering Task Force (IETF), 20 its areas, and its working groups. Note that other groups may 21 also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet-Drafts 26 as reference material or to cite them other than as "work in 27 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 38 1034, RFC 1035], MADCAP [RFC 2730], and LDAP [RFC 2251] must be 39 configured and maintained by an administrative staff. This is 40 unacceptable for emerging networks such as home networks, 41 automobile networks, airplane networks, or ad hoc networks at 42 conferences, emergency relief stations, and many others. Such 43 networks may be nothing more than two isolated laptop PCs 44 connected via a wireless LAN. For all these networks, an 45 administrative staff will not exist and the users of these 46 networks neither have the time nor inclination to learn network 47 administration skills. Instead, these networks need protocols that 48 require zero user configuration and administration. This document 49 is part of an effort to define such zero configuration (zeroconf) 50 protocols. 52 Before embarking on defining zeroconf protocols, protocol 53 requirements are needed. This document states the zeroconf 54 protocol requirements for four protocol areas; they are: IP 55 interface configuration, translation between host name and IP 56 address, IP multicast address allocation, and service discovery. 57 This document does not define specific protocols, just requirements. 58 The requirements for these four areas result from examining 59 everyday use or scenarios of these protocols. 61 Table of Contents 63 1 Introduction................................................2 64 1.1 Key Words.................................................3 65 1.2 Reading This Document.....................................3 66 1.3 Zeroconf Coexistence......................................3 67 1.4 Scalability...............................................3 68 1.5 Routable Protocol Requirement.............................4 69 1.6 Conflicts and State Changes Requirement...................4 70 2 Scenarios & Requirements....................................4 71 2.1 IP Interface Configuration................................4 72 2.2 Translation between Host name and IP Address Scenarios....6 73 2.3 IP Multicast Address Allocation Scenarios.................7 74 2.4 Service Discovery Scenarios...............................9 75 3 Security Considerations....................................10 76 3.1 IP interface configuration...............................11 77 3.2 Name to Address Resolution...............................12 78 3.3 Multicast Address Allocation.............................12 79 3.4 Service Discovery........................................13 80 4 IANA Considerations........................................13 81 5 Full Copyright Statement...................................13 82 6 Acknowledgements...........................................14 83 7 References.................................................15 85 1 Introduction 87 A zeroconf protocol is able to operate correctly in the absence 88 of configured information from either a user or infrastructure 89 services such as conventional DHCP [RFC 2131] or DNS [RFC 1034, 90 RFC 1035] servers. Zeroconf protocols may use configured 91 information, when it is available, but do not rely on it being 92 present. One possible exception is the use of MAC addresses 93 (i.e. layer two addresses) as parameters in zeroconf protocols. 95 The benefits of zeroconf protocols over existing configured 96 protocols are an increase in the ease-of-use for end-users and 97 a simplification of the infrastructure necessary to operate 98 protocols. 100 This document discusses requirements for zeroconf protocols in 101 four areas: 103 - IP interface configuration 104 - Translation between host name and IP address 105 - IP multicast address allocation 106 - Service discovery 108 Security considerations are also discussed. 110 1.1 Key Words 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 113 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 114 in this document are to be interpreted as described in [RFC 2119]. 116 1.2 Reading This Document 118 Introduction, Scenarios & Requirements, and Security 119 Considerations are the major sections of this document. 121 The Scenarios & Requirements section walks through protocol 122 scenarios and then lists the requirements of the protocol needed 123 to accomplish the scenario. 125 The Security Consideration section lists security issues with 126 zeroconf protocols. 128 Requirements dispersed throughout this document begin with the 129 text "Requirements:" or "Requirement:" on a single line, which is 130 followed by a bulleted list of requirements. 132 1.3 Zeroconf Coexistence 134 It is not necessary to simultaneously use zeroconf protocols in 135 all four areas (i.e. IP interface configuration, translation 136 between host name and IP address, IP multicast address allocation, 137 service discovery). For example, it might make sense on some 138 networks to provide a DHCP server for configured IP interface 139 configuration, but perform translation between host name and IP 140 address using a zeroconf protocol. 142 1.4 Scalability 144 The primary reasons to deploy Zeroconf protocols are simplicity 145 and ease-of-use. Scalability is important but it is a secondary 146 goal. Thus, scalability should not detract from the primary goals 147 of simplicity and ease-of-use. 149 1.5 Routable Protocol Requirement 151 If a protocol is intended to span multiple IP subnets it SHOULD 152 NOT use broadcasts or link-local addressing. 154 Requirement: 155 - Protocols intended to span multiple IP subnets SHOULD NOT use 156 broadcasts or link-local addressing. 158 1.6 Conflicts and State Changes Requirement 160 Topology changes or other events such as adding and removing hosts 161 may cause conflicts and state changes within a protocol. Zeroconf 162 protocols must be able to resolve conflicts and state changes caused 163 by topology changes or other events. The scenario in the 2.1.2 Bridge 164 Installed section is the only scenario that illustrates the need for 165 this requirement, thus the below requirement is duplicated in section 166 2.1.2. However, this requirement applies to all protocol areas. 168 Requirement: 169 - MUST respond to state changes and resolve conflicts in a timely 170 manner. 172 2 Scenarios & Requirements 174 This section contains a subsection for each of the four protocol 175 areas. Within each subsection, terms and assumptions are followed 176 by specific representative scenarios that lead to zeroconf 177 protocol requirements in that area. Each subsection ends with 178 IPv6 considerations. 180 2.1 IP Interface Configuration 182 In this document, IP interface configuration always includes the 183 configuration of an IP address and netmask; it may include some 184 routing information (e.g. default route). IP interface configuration 185 is needed before almost any IP communication can take place. 187 Terms: 189 IP subnet - A single logical IP network that may span multiple 190 link layer networks. All IP hosts on the IP subnet communicate 191 without any layer 3 forwarding device (e.g. router). 193 internetwork - Multiple IP subnets connected by routers. 195 network - context sensitive term that may apply to one or more 196 of the terms: a link layer network, an IP subnet, or an 197 internetwork. 199 bridge - a networking device that connects two link layer 200 networks by using only link-layer protocols (e.g. Ethernet). 202 The IP interface configuration scenarios are two IP packet-sending 203 scenarios and a bridge install scenario. 205 2.1.1 IP Packet-Sending 207 These scenarios consist of sending an IP packet from one host to 208 another. These scenarios apply to any IP packets with a unicast 209 destination IP address. There are two sub-scenarios. In the first, 210 both the sender of the IP packet and the receiver of the IP packet 211 are on the same IP subnet. In the second, the two senders are on 212 different IP subnets within an internetwork. 214 Requirements: 215 - MUST configure an appropriate netmask. 216 - MUST have unique IP addresses within an IP subnet. 217 - MUST have some routing information 218 (for the internetwork scenario). 219 - MUST have unique IP subnets within an internetwork 220 (only for the internetwork scenario). 222 2.1.2 Bridge Installed 224 This scenario starts with two completely operational link-layer 225 networks with two distinct IP networks in which IP interface 226 configuration was completed with a zeroconf protocol on each 227 network. These two link-layer networks logically become a single 228 link-layer network after a newly installed bridge connects them. 229 Somehow the hosts operating on the two IP networks must now 230 configure themselves to operate as a single IP network. Since the 231 bridge connects the networks at the link-layer, there is no change 232 in link status from off to on, which is the usual signal used in 233 Ethernet networks for IP hosts to configure. 235 Topology changes from the installation of a bridge or a router may 236 create the following problems: multiple default routes that cause 237 dial out lines to be used instead of broadband connections, 238 duplicate IP addresses within an IP subnet, or duplicate IP 239 subnets within an internetwork. 241 Requirement: 242 - MUST resolve conflicts and state changes in a timely manner. 244 2.1.3 IPv6 Considerations 246 IPv6 allows a host to select an appropriate IP address, netmask, 247 and routing information, thus if a host is using IPv6, a zeroconf 248 IP interface configuration solution already exists. 250 2.2 Translation between Host name and IP Address Scenarios 252 Host names allow users to refer to hosts using names instead of IP 253 addresses. This is among the most fundamental, thus most important, 254 usage paradigms in TCP/IP networking. 256 Terms: 258 host name - A textual name that allows a user to refer to a host 259 by name rather than IP address. 261 domain name - Zero or more textual labels, separated by dots, 262 that identify a DNS domain [RFC 1034] [RFC 1035]. 264 resolver - The host needing a name to IP address translation. 266 The scenario for translation between host name and IP address is 267 Web browsing. In addition, host name selection is discussed. 269 2.2.1 Web Browsing 271 An URL typically contains the name of a Web server. When a user 272 enters an URL into a Web browser, the name must be translated to 273 an IP address before any actual Web browsing occurs. Web servers 274 often record log files of accesses, and wish to map the client's 275 IP address back to a human-readable name for recording in the log 276 file. Thus, a mechanism to translate the IP address to a name is 277 required. 279 Requirement: 280 - MUST translate a name to an IP address. 281 - MUST translate an IP address to a name. 283 2.2.2 Host Name Selection 285 How the host is administratively assigned a domain name is determined 286 by some other configuration protocol or user configuration, and is 287 not part of this zeroconf scenario. A protocol must allow a host 288 to determine if its name is unique. If the name is not unique, the 289 protocol must notify the user or some IP interface configuration 290 software to select another name then repeat the process of verifying 291 the uniqueness of the name. 293 Requirement: 295 - MUST allow a host to determine if its name is unique. Then if 296 not unique, notify the user or configuration software so that 297 another name may be chosen and similarly verified. 299 2.2.3 IPv6 Considerations 301 Protocols to perform translation between host name and IP address 302 have no zeroconf-related differences for IPv4 and IPv6. 304 2.3 IP Multicast Address Allocation Scenarios 306 IP Multicast is used to conserve bandwidth for multi-receiver 307 bulk-delivery applications, such as audio, video, or news. 309 IP Multicast is also used to perform a logical addressing function. 310 For example, when a host needs to communicate with local routers, it 311 can send packets to the all-routers multicast address without having 312 to know in advance the IP address(es) of the router(s). 314 IPv4 multicast addresses range from 224.0.0.0 to 239.255.255.255. 316 [RFC 2365] defined multicast scopes are: 317 node-local (unspecified for IPv4) 318 link-local (224.0.0.0/24) 319 local (239.255.0.0/16) 320 site-local (unspecified for IPv4) 321 organizational-local (239.192.0.0/14) 322 global (224.0.1.0-238.255.255.255) 324 A relative assignment is an integer offset from the highest address 325 in the scope and represents a 32-bit address. For example, within the 326 local scope, 239.255.255.0/24 is reserved for relative allocations. 328 Source-Specific Multicast [SSM] addresses are 232.0.0.0 to 329 232.255.255.255. 331 Assumptions: 332 - The node-local and SSM addresses require no protocol or 333 interaction between multiple hosts, thus are not mentioned 334 further in this document. 335 - Global and organizational scoped addresses are meant for 336 networks of a greater scale than zeroconf protocols, thus are 337 not mentioned further in this document. 338 - Only local, link-local and site-local scopes are considered 339 further in this document. 340 - If it is desirable to restrict multicast packets from entering 341 and leaving a multicast scope boundary, it is assumed that the 342 router at the boundary is a "boundary router" as described in 343 [RFC 2365]. 345 Scenarios are scope enumeration, address allocation, and multiple 346 sources. 348 2.3.1 Scope Enumeration 350 Applications that leave the choice of scope up to the user require 351 the ability to enumerate what scopes the host is operating within. 352 In addition, services that are assigned relative addresses require 353 the ability to enumerate what scopes the host is within; only then 354 will a host be able to apply the relative address to a scope. 356 Requirements: 357 - MUST list which of the scopes (local, link-local, or site-local) 358 are available for hosts. 359 - MUST list per-scope address ranges that may be allocated. 361 2.3.2 Address Allocation 363 IP multicast address allocation (local, link-local and site-local 364 scopes only) requires an application to be able to request the use 365 of a suitable multicast address. Coordination among applications 366 must occur to avoid conflicting allocations of the same address. 367 This coordination must span the entire scope respective to the 368 address. When an allocated address is no longer required, that 369 address MUST become available for use again. 371 Requirements: 372 - MUST select a multicast address. 373 - MUST prevent conflicting allocations of the same address. 374 - MUST allow the multicast address to become available after the 375 address is no longer in use. 377 2.3.3 Multiple Source 379 An intercom system inside a home is an example of a multiple 380 source IP multicast application. In this type of application, 381 several sources may be sending packets destined to the same IP 382 multicast address. 384 This multiple source example illustrates the problem that a 385 particular address may continue to be valid, even after the host 386 that initially allocated the address is no longer present; the 387 zeroconf multicast address allocation must correctly support this 388 type of operation. In other words, if a host allocates a multicast 389 address, then leaves the multicast group, some other host must 390 defend the address. 392 Requirements: 393 - A host other than the allocating host MUST be able to defend 394 or otherwise maintain the allocation of a multicast address. 396 2.3.4 IPv6 Considerations 398 To date, no range has been reserved for source-specific addresses 399 in IPv6. Hence, until such a range is reserved, dynamic allocation 400 of source-specific addresses applies only to IPv4. 402 To date, no range has been reserved for dynamic allocation of 403 Link-scoped addresses in IPv4. Hence, unless such a range is 404 reserved, dynamic allocation of link-scoped addresses applies only 405 to IPv6. 407 2.4 Service Discovery Scenarios 409 Service discovery protocols allow users to select services and/or 410 hosts by a name that is discovered dynamically, rather than requiring 411 that the user know the name in advance and type it in correctly. 413 Terms: 415 service - a particular logical function that may be invoked via 416 some network protocol, such as printing, storing a file on a 417 remote disk, or even perhaps requesting delivery of a pizza. 419 service characteristics - Characteristics provide a finer 420 granularity of description to differentiate services beyond just 421 the service type. For example if the service type is printer, 422 the characteristics may be color, pages printed per second, 423 location, etc. 425 service discovery protocol - A service discovery protocol 426 enables clients to discover servers (or peers to find other 427 peers) of a particular service. A service discovery protocol is 428 an application layer protocol that relies on network and 429 transport protocol layers. 431 service protocol - A service protocol is used between the client 432 and the server after service discovery is complete. 434 The scenarios are the discovery of a simple printer service. 436 2.4.1 Printer Service 438 Network-enabled printers allow various network clients to submit 439 print jobs. A service discovery protocol MUST allow a printer 440 service to be discovered by devices needing to print. This requires a 441 service type as well as a service identifier to distinguish instances 442 of a single service type. Service discovery MUST be independent from 443 any particular printing protocol such as lpd, raw-tcp, ipp. 445 Printers vary in their characteristics such as location, status, 446 dots per inch, etc. Discovering a service based on these 447 characteristics SHOULD be part of the service discovery protocol. 449 Service discovery MUST complete in a timely (10s of seconds) manner. 451 Requirements: 452 - MUST allow a service to be discovered. 453 - MUST discover via service identifier and/or service type. 454 - MUST discover services without use of a service-specific protocol. 455 - SHOULD discover via service characteristics. 456 - MUST complete in a timely (10s of seconds) manner. 458 2.4.2 IPv6 Considerations 460 Service discovery protocols have no zeroconf related differences 461 for IPv4 and IPv6. 463 3 Security Considerations 465 The principal goal of Zero Configuration protocols is to provide 466 network configuration where existing configuration and 467 configuration services are unavailable. This is at odds with 468 secure operation since security mechanisms generally require some 469 pre-configuration (such as keys, certificates, etc.). 471 Generally speaking, security mechanisms in IETF protocols are 472 mandatory to implement. A particular implementation might permit 473 a network administrator to turn off a particular security mechanism 474 operationally. However, implementations should be "secure out of the 475 box" and have a safe default configuration. 477 Zeroconf protocols MUST NOT be any less secure than related 478 current IETF-Standard protocols. This consideration overrides the 479 goal of allowing systems to obtain configuration automatically. 480 This section explicitly describes what this requires of each 481 protocol area. 483 Security threats to be considered include both active attacks 484 (e.g. denial of service) and passive attacks (e.g. eavesdropping). 485 Protocols that require confidentiality and/or integrity should 486 include integrated confidentiality and/or integrity mechanisms or 487 should specify the use of existing standards-track security 488 mechanisms (e.g. TLS [RFC 2246], ESP [RFC 1827], AH [RFC 2402]) 489 appropriate to the threat. 491 3.1 IP interface configuration 493 Specific risks arise due to not securing IP interface configuration. 494 An active attacker could completely or selectively prevent hosts from 495 being properly configured. If an attacker 'hoards' all IP addresses, 496 inappropriately claiming to be configured with them, this would 497 prevent other hosts from effectively participating in IP interface 498 configuration. 500 An active attacker could be more selective and instead of claiming 501 it has all IP addresses, it could claim this only in response to 502 requests from a specific host (or hosts) to deny them service. It 503 might also be possible that an active attacker could partially 504 misconfigure one or more victims to cause these nodes to have 505 partial (but not full) use of the network service. 507 IP communication relies on lower level address resolution protocols 508 (ARP [RFC 826] or IPv6 Neighbor Discovery [RFC 2461]). In the case 509 of ARP and its cousins (e.g. inverse ARP, reverse ARP, proxy ARP), 510 there is no standard security mechanism. Neither the integrity of 511 the message is checked nor is the identity of the message source 512 authenticated. This makes it possible for an active attack to subvert 513 these protocols. Since the scope of these protocols is limited to 514 a single broadcast network, the potential range of the risk due to 515 this attack is limited. The effect of the attack, however, is to 516 potentially disrupt all communication on the local link. 518 It is appropriate not to require IP interface configuration 519 protocols to implement security mechanisms when these hosts (and 520 others) will then proceed to perform subsequent communication 521 using insecure mechanisms such as ARP. Thus hosts using insecure 522 IP interface configuration are ultimately no more vulnerable to 523 attack than other hosts on the network configured using some other 524 more secure mechanism. The security requirements demand that 525 zeroconf protocols MUST NOT compromise security if security is 526 deployed. In the case of IPv4, it is acceptable (though not 527 desirable) for interface configuration to fail to defend against 528 attack from other hosts on the same physical link, since these 529 hosts are already in a position to subvert IPv4 ARP anyway, so 530 securing the interface configuration protocol would not prevent 531 them disrupting subsequent IPv4 communications. For that reason 532 the IPv4 interface configuration protocol MAY include no defence 533 against attack from other hosts on the same physical link. 535 The IPv4 interface configuration protocol MAY omit security 536 mechanisms if and only if that protocol is not used for IPv6 and 537 cannot be extended to support IPv6. It is strongly recommended that 538 it include security mechanisms, because many protocols are extended 539 later in ways not anticipated by the original developer(s). 541 In the case of IPv6 Neighbor Discovery, this protocol can be 542 secured as it uses ICMPv6 messages, which run over IP. IPv6 543 Neighbor Discovery messages can thus be protected for integrity 544 and endpoint authentication using IP Security. [RFC 2401, 2402, 545 2403, 2404] 547 3.2 Name to Address Resolution 549 The security implications of this zeroconf protocol must be 550 compared against the DNS protocol. 552 DNS is a client-server protocol. The zeroconf name to address 553 translation protocol will likely use multicast so that any host 554 may respond to queries. This broadens the possibility that host 555 authentication in the form of hostname-IP address mappings may be 556 compromised, since all hosts effectively may behave as DNS servers. 558 Currently it is possible to subvert DNS in various ways, unless 559 DNSsec [RFC 2535, RFC 2931] is used. For example: 561 - A client may be configured with the address of an attacker's DNS 562 server. For example, an active attacker on the same subnet as the 563 client may respond to DHCP DHCPDISCOVER messages and deliberately 564 configure the client to use a compromised DNS server. 566 - An active attack against a DNS client is possible - where an 567 attacker unicasts a DNS reply to a client request that arrives 568 at the client before the legitimate server's response. 570 DNSsec protects against such attacks as the client can verify that 571 the data it retrieves using the DNS has been signed from a source 572 that the client has been configured to accept. 574 A zeroconf name to address resolution protocol MUST be compatible 575 with the use of DNSsec. Therefore it MUST be possible for a host 576 running a zeroconf protocol to use DNS and DNSsec for authenticated 577 name resolution if that host (or its administrator) chooses to do so. 578 [RFC 2541] 580 3.3 Multicast Address Allocation 582 The zeroconf multicast address allocation protocol MUST NOT be 583 less secure than MADCAP [RFC 2730] and AAP [AAP]. These are the 584 IETF standards track protocols for Multicast Address Allocation. 586 The threat of using an insecure Multicast Address Allocation protocol 587 is that an active attacker could 'hoard' all multicast addresses - 588 inappropriately claiming to have allocated them. This would prevent 589 other hosts from effectively participating in the Multicast Address 590 Allocation protocol. This could be done to stop all participation or 591 selectively, to prevent particular hosts from allocating addresses. 593 Neither AAP nor MADCAP include mechanisms for protecting message 594 integrity or endpoint authentication. These protocols suggest the 595 use of IPsec for this purpose, as AAP and MADCAP are compatible with 596 the IP Authentication Header. A zeroconf multicast address 597 allocation protocol MUST either be compatible with IP AH or provide 598 another mechanism for optional-to-use (but mandatory to implement) 599 authentication. 601 3.4 Service Discovery 603 The zeroconf service discovery protocol MUST NOT be less secure 604 than the IETF standard service discovery protocol: The Service 605 Location Protocol, Version 2 [RFC 2608] (SLPv2). 607 The threat posed by using an insecure service discovery protocol 608 is that unauthorized entities may participate. A client may be 609 misled to communicate with a host that has been compromised or 610 that offers an antagonistic server that the client did not intend 611 to use. This might be easy to detect (e.g. after attempting to 612 use a printer that doesn't exist, no printed upon paper appears.) 613 This may also be difficult to detect (e.g. an illegitimate server 614 copies all data for an attacker's subsequent perusal and the user 615 has no way of knowing). 617 A client could still detect that it is communicating with an 618 unauthorized server, but that would require authentication and 619 authorization mechanisms at a higher level (the client-server 620 protocol). 622 SLPv2 protects against the threat of discovery of unauthorized 623 services. SLPv2 messages that contain an answer may include an 624 associated authorization block. This allows a client receiving a 625 message to verify the answer, using digital signatures and a 626 certificate-based system as the basis for authorization. Other 627 mechanisms are possible. 629 A zeroconf service discovery protocol MUST allow a client to 630 verify that a service advertisement sent by a server was created 631 by an authorized source. 633 4 IANA Considerations 635 No known IANA considerations arise from this document. 637 5 Full Copyright Statement 639 Copyright (C) The Internet Society (2000). All Rights Reserved. 641 This document and translations of it may be copied and furnished 642 to others, and derivative works that comment on or otherwise 643 explain it or assist in its implementation may be prepared, 644 copied, published and distributed, in whole or in part, without 645 restriction of any kind, provided that the above copyright notice 646 and this paragraph are included on all such copies and derivative 647 works. However, this document itself may not be modified in any 648 way, such as by removing the copyright notice or references to the 649 Internet Society or other Internet organizations, except as needed 650 for the purpose of developing Internet standards in which case the 651 procedures for copyrights defined in the Internet Standards 652 process must be followed, or as required to translate it into 653 languages other than English. 655 The limited permissions granted above are perpetual and will not 656 be revoked by the Internet Society or its successors or assigns. 658 This document and the information contained herein is provided on 659 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 660 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 661 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 662 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 663 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 664 PURPOSE." 666 6 Acknowledgements 668 Thanks to Peter Ford and Stuart Cheshire for hosting the NITS 669 (Networking In The Small) BOF that was the catalyst to forming the 670 Zeroconf Working Group. 672 Thanks to Erik Guttman and Stuart Cheshire for forming and 673 chairing the Zeroconf Working Group, which is responsible for this 674 document. 676 Thanks to Erik Guttman for providing key input to the service 677 discovery and the security sections. 679 Thanks to Dave Thaler for providing key input to the IP multicast 680 address allocation sections. 682 Thanks to Stuart Cheshire for providing key input to the 683 introduction and IP interface configuration sections. 685 Additional recognition goes the following people for their 686 influential contributions to this document and its predecessors: 687 Brent Miller, Thomas Narten, Marcia Peters, Bill Woodcock, Bob 688 Quinn, John Tavs, Matt Squire, Daniel Senie, Cuneyt Akinlar, Karl 689 Auerbach, Kanchei Loa, Dongyan Wang, James Kempf, Yaron Goland, 690 and Bernard Aboba, Ran Atkinson. 692 Editor: 694 Myron Hattig 695 Intel Corporation 696 3585 SW 198th Avenue 697 Aloha, OR 97007 698 myron.hattig@intel.com 700 7 References 702 [RFC 826] D. Plummer, "An Ethernet Address Resolution Protocol", 703 RFC 826, November 1982. 705 [RFC 1034] P. Mockapetris, "Host names - Concepts and 706 Facilities", RFC 1034, November 1987 708 [RFC 1035] P. Mockapetris, "Host names - Implementations and 709 Specifications", RFC 1034, November 1987 711 [RFC 1827] R. Atkinson, "IP Encapsulating Security Payload", RFC 712 1827, Aug 1995 714 [RFC 2026] S. Bradner, "The Internet Standards Process -- 715 Revision 3", RFC 2026 Oct 1996 717 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate 718 Requirement Levels", RFC 2119, March 1997. 720 [RFC 2131] R. Droms, "Dynamic Host Configuration Protocol", RFC 721 2131, March 1997. 723 [RFC 2246] T. Dierks, C. Allen, "Transport Layer Security", RFC 724 2246, Jan 1999. 726 [RFC 2251] M. Wahl, T. Howes, and S. Kille, "Lightweight 727 Directory Access Protocol (v3)", RFC 2251, Dec 1997. 729 [RFC 2365] D. Meyer, "Administratively Scoped Multicast Address", 730 RFC 2365,July 1998. 732 [RFC 2401] S. Kent, R. Atkinson, "Security Architecture for the 733 Internet Protocol", RFC 2401 November 1998 735 [RFC 2402] S. Kent, R. Atkinson, "IP Authentication Header", RFC 736 2402 November 1998 738 [RFC 2461] T. Narten, E. Nordmark, W. Simpson, "Neighbor 739 Discovery for IP Version 6 (IPv6)", RFC 2461, 740 December 1998. 742 [RFC 2462] S. Thomson, T. Narten, "IPv6 Stateless Address 743 Autoconfiguration", RFC 2462, December 1998 745 [RFC 2535] D. Eastlake, "Domain Name System Security Extensions", 746 RFC 2535, March 1999. 748 [RFC 2541] D. Eastlake, "DNS Security Operational 749 Considerations", RFC 2541, March 1999 751 [RFC 2608] E. Guttman, et al, "Service Location Protocol, 752 Version 2", RFC 2608, June 1999 754 [RFC 2730] S. Hanna, B. Patel, M. Shah, "Multicast Address 755 Dynamic Client Allocation Protocol (MADCAP)", RFC 756 2730, Dec 1999. 758 [RFC 2931] D. Eastlake, "DNS Request and Transaction Signatures ( 759 SIG(0)s )", RFC 2931, September 2000 761 [SSM] H. Holbrook, "Source-Specific Multicast for IP", 762 draft-holbrook-ssm-00.txt, March 2000. A work in 763 progress. 765 [AAP] M. Handley, S. Hanna, "Multicast Address Allocation 766 Protocol (AAP)", draft-ietf-malloc-aap-04.txt, June 767 2000. A work in progress. 769 Stuart Cheshire 770 * Wizard Without Portfolio, Apple Computer 771 * Chairman, IETF ZEROCONF 772 * www.stuartcheshire.org