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