Zeroconf WG                                                    M. Hattig 
Internet Engineering Task Force                                   Editor 
INTERNET DRAFT                                               Intel Corp. 
Expires April 2001                                     November 20, 2000 
 
 
                         Zeroconf Requirements 
                    draft-ietf-zeroconf-reqts-06.txt 
 
Status of This Memo 
    
   This document is a submission by the Zeroconf Working Group of the 
   Internet Engineering Task Force (IETF).  Comments should be 
   submitted to the zeroconf@merit.edu mailing list. 
    
   Distribution of this memo is unlimited. 
    
   This document is an Internet-Draft and is in full conformance with 
   all provisions of Section 10 of [RFC 2026].  Internet-Drafts are 
   working documents of the Internet Engineering Task Force (IETF), 
   its areas, and its working groups.  Note that other groups may 
   also distribute working documents as Internet-Drafts. 
    
   Internet-Drafts are draft documents valid for a maximum of six 
   months and may be updated, replaced, or obsoleted by other 
   documents at any time.  It is inappropriate to use Internet-Drafts 
   as reference material or to cite them other than as "work in 
   progress." 
    
   The list of current Internet-Drafts can be accessed at: 
     http://www.ietf.org/ietf/1id-abstracts.txt 
    
   The list of Internet-Draft Shadow Directories can be accessed at: 
      http://www.ietf.org/shadow.html. 
 
Abstract 
 
   Many common TCP/IP protocols such as DHCP [RFC 2131], DNS [RFC 
   1034, RFC 1035], MADCAP [RFC 2730], and LDAP [RFC 1487] must be 
   configured and maintained by an administrative staff. This is 
   unacceptable for emerging networks such as home networks, 
   automobile networks, airplane networks, or adhoc networks at 
   conferences, emergency relief stations, and many others. Such 
   networks may be nothing more than two isolated laptop PCs 
   connected via a wireless LAN. For all these networks, an 
   administrative staff will not exist and the users of these 
   networks neither have the time nor inclination to learn network 
   administration skills. Instead, these networks need protocols that 
   require zero user configuration and administration. This document 
   is part of an effort to define such zero configuration (zeroconf) 
   protocols.  
    
    
    
   Hattig                                                  [Page 1] 
    
    
   Internet Draft      draft-ietf-zeroconf-reqts-06.txt     Nov 2000 
    
    
   Before embarking on defining zeroconf protocols, protocol 
   requirements are needed. This document states the zeroconf 
   protocol requirements for four protocol areas; this document does 
   not define specific protocols. The four areas are: IP interface 
   configuration, host name to IP address resolution, IP multicast 
   address allocation, and service discovery. The requirements for 
   these four areas result from examining everyday use or scenarios 
   of these protocols. 
 
                           Table of Contents 
    
   1 Introduction................................................2 
   1.1 Key words.................................................3 
   1.2 Reading This Document.....................................3 
   1.3 Zeroconf Coexistence......................................3 
   1.4 Scalability...............................................3 
   1.5 Routable Protocol Requirement.............................3 
   1.6 Conflicts and State Changes Requirement...................4 
   2 Scenarios & Requirements....................................4 
   2.1 IP Interface Configuration................................4 
   2.2 Host name to IP Address Resolution Scenarios..............6 
   2.3 IP Multicast Address Allocation Scenarios.................7 
   2.4 Service Discovery Scenarios...............................9 
   3 Security Considerations....................................10 
   3.1 IP interface configuration...............................11 
   3.2 Name to Address Resolution...............................12 
   3.3 Service Discovery........................................13 
   3.4 Multicast Address Allocation.............................14 
   4 IANA Considerations........................................14 
   5 Full Copyright Statement...................................14 
   6 Acknowledgements...........................................15 
   7 References.................................................15 
    
1  Introduction 
 
   A zeroconf protocol is able to operate correctly in the absence of 
   configured information from either a user or infrastructure 
   services such as conventional DHCP [RFC 2131] or DNS [RFC 1034, 
   RFC 1035] servers. Zeroconf protocols may use configured 
   information, when it is available, but do not rely on it being 
   present. One possible exception is the use of MAC addresses (i.e. 
   layer two addresses) as parameters in zeroconf protocols.  
    
   The benefits of zeroconf protocols over existing configured 
   protocols are an increase in the ease-of-use for end-users and a 
   simplification of the infrastructure necessary to operate 
   protocols. 
    
   This document discusses requirements for zeroconf protocols in 
   four areas:  
    
    
   Hattig                                                  [Page 2] 
    
    
   Internet Draft      draft-ietf-zeroconf-reqts-06.txt     Nov 2000 
    
    
   - IP interface configuration 
   - Host name to IP address resolution 
   - IP multicast address allocation 
   - Service discovery 
    
   Security considerations are also discussed. 
 
1.1 Key words 
    
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 
   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 
   in this  document are to be interpreted as described in [RFC 
   2119]. 
    
1.2 Reading This Document 
    
   Introduction, Scenarios & Requirements, and Security 
   Considerations are the major sections of this document.  
    
   The Scenarios & Requirements section walks through protocol 
   scenarios and then lists the requirements of the protocol needed 
   to accomplish the scenario.  
    
   The Security Consideration section lists security issues with 
   zeroconf protocols.  
    
   Requirements dispersed throughout this document begin with the 
   text "Requirements:" or "Requirement:" on a single line, which is 
   followed by a bulleted list of requirements.  
 
1.3 Zeroconf Coexistence 
    
   It is not necessary to simultaneously use zeroconf protocols in 
   all four areas (i.e. IP interface configuration, host name to IP 
   address resolution, IP multicast address allocation, service 
   discovery). For example, it might make sense on some networks to 
   provide a DHCP server for configured IP interface configuration, 
   but perform host name to IP address resolution using a zeroconf 
   protocol. 
 
1.4 Scalability 
    
   The primary reasons to deploy Zeroconf protocols are simplicity 
   and ease-of-use. Scalability is important but it is a secondary 
   goal. Thus, scalability should not detract from the primary goals 
   of simplicity and ease-of-use. 
    
1.5 Routable Protocol Requirement 
    

    
    
   Hattig                                                  [Page 3] 
    
    
   Internet Draft      draft-ietf-zeroconf-reqts-06.txt     Nov 2000 
    
    
   If a protocol is intended to span multiple IP subnets it SHOULD 
   not use broadcasts or link-local addressing.  
    
   Requirement: 
   - Protocols intended to span multiple IP subnets SHOULD not use 
     broadcasts or link-local addressing. 
    
1.6 Conflicts and State Changes Requirement 
    
   Topology changes or other events such as adding and removing hosts 
   may cause conflicts and state changes within a protocol. Zeroconf 
   protocols must be able to resolve conflicts and state changes 
   caused by topology changes or other events. The scenario in the 
   2.1.2 Bridge Installed section is the only scenario that 
   illustrates the need for this requirement, thus the below 
   requirement is duplicated in section 2.1.2. However, this 
   requirement applies to all protocol areas. 
    
   Requirement: 
   - MUST respond to state changes and resolve conflicts in a timely 
     manner. 
           
2  Scenarios & Requirements 
    
   This section contains a subsection for each of the four protocol 
   areas. Within each subsection, terms and assumptions are followed 
   by specific representative scenarios that lead to zeroconf 
   protocol requirements in that area. Each subsection ends with an 
   IPv6 considerations section. 
    
2.1 IP Interface Configuration  
    
   In this document, configuration of an IP interface on a host is IP 
   interface configuration. IP interface configuration always 
   includes the configuration of an IP address and netmask; it may 
   include a default route. IP interface configuration is needed 
   before almost any IP communication can take place. 
    
   Terms: 
     IP subnet - A single logical IP network that may span multiple 
     link layer networks. All IP hosts on the IP subnet communicate 
     without any layer 3 forwarding device (e.g. router). 
      
     internet - Multiple IP subnets connected by routers.  
      
     network - context sensitive term that may apply to one or more 
     the terms link layer network, IP subnet, or internet. 
      
     bridge - a networking device that connects two link layer 
     networks by using only link-layer protocols (e.g. Ethernet). 
    
    
   Hattig                                                  [Page 4] 
    
    
   Internet Draft      draft-ietf-zeroconf-reqts-06.txt     Nov 2000 
    
    
      
   IP interface configuration scenarios are two IP packet-sending 
   scenarios and a bridge install scenario. 
    
2.1.1  IP Packet-Sending  
    
   These scenarios consist of sending an IP packet from one host to 
   another. These scenarios apply to any IP packets with a unicast 
   destination IP address. There are two sub-scenarios. In the first, 
   both the sender of the IP packet and the receiver of the IP packet 
   are on the same IP subnet. In the second, the two senders are on 
   different IP subnets within an internet. 
    
   Requirements: 
   - MUST determine the netmask for an IP subnet. 
   - MUST have unique IP addresses within an IP subnet. 
   - MUST have a default route (only for the internet scenario). 
   - MUST have unique IP subnets within an internet (only for the 
     internet scenario).  
    
2.1.2  Bridge Installed 
    
   This scenario starts with two completely operational link-layer 
   networks with two distinct IP networks in which IP interface 
   configuration was completed with a zeroconf protocol on each 
   network. These two link-layers networks logically become a single 
   link-layer network after a newly installed bridge connects them. 
   Somehow the hosts operating on the two IP networks must now 
   configure themselves to operate as a single IP network. Since the 
   bridge connects the networks at the link-layer, there is no change 
   in link status from off to on, which is the usual signal used in 
   Ethernet networks for IP hosts to configure. 
    
   Topology changes from the installation of a bridge or a router may 
   create the following problems: inconsistent netmasks that cause IP 
   hosts to be on different IP subnets when they should be on a 
   single IP subnet, multiple default routes that cause dial out 
   lines to be used instead of broadband connections, duplicate IP 
   addresses within an IP subnet, or duplicate IP subnets within an 
   internet.  
    
   Requirement:  
   - MUST resolve conflicts and state changes in a timely manner.  
    
2.1.3  IPv6 Considerations  
    
   IPv6 allows a host to select an appropriate IP address, netmask, 
   and find a default route, thus if a host is using IPv6, a zeroconf 
   IP interface configuration solution already exists. 
    
    
    
   Hattig                                                  [Page 5] 
    
    
   Internet Draft      draft-ietf-zeroconf-reqts-06.txt     Nov 2000 
    
    
2.2 Host name to IP Address Resolution Scenarios 
    
   Host names allow users to refer to hosts by name instead of IP 
   addresses. This is among the most fundamental, thus most 
   important, usage paradigms in TCP/IP networking.   
    
   Terms: 
    
     host name - A textual name that identifies a host. The name may 
     include a "." character, thus cannot be easily distinguished 
     from a domain name. 
      
     domain name - Zero or more textual labels, separated by dots, 
     that identify a DNS domain [RFC 1034] [RFC 1035]. 
      
     resolver - The host needing a name resolved to an IP address.  
    
   Assumptions: 
   - Support for multiple hosts with the same name is not a 
     requirement. 
    
   The scenarios for host name to IP address resolution are Web 
   browsing and host name selection.  
 
2.2.1  Web Browsing 
    
   An URL typically contains the name of a Web server. When a user 
   enters an URL into a Web browser, the name must be resolved to an 
   IP address before any actual Web browsing occurs. 
    
   The name of a Web server may be within the same domain along with 
   the name of the resolver or may be part of some other domain. 
    
   Requirement: 
   - MUST resolve a host name to an IP address regardless of whether 
     the name of the resolver and the name being resolve are in the 
     same DNS domain or in different DNS domains.  
    
2.2.2  Host Name Selection  
    
   How the host gets its name (or Domain Name [RFC 1034]) is part of 
   some other configuration protocol or user configuration, and is 
   not part of this zeroconf scenario. This scenario deals with hosts 
   on a network selecting and operating with unique names. A protocol 
   must allow a host to determine if its name is unique. If not 
   unique, the protocol must notify the user or some IP interface 
   configuration software to select another name then repeat the 
   process of verifying the uniqueness of the name. 
    
    
    
    
   Hattig                                                  [Page 6] 
    
    
   Internet Draft      draft-ietf-zeroconf-reqts-06.txt     Nov 2000 
    
    
   Requirement: 
   - MUST allow a host to determine if its name is unique. Then if 
     not unique, notify the user or configuration software so that 
     another name may be chosen.  
    
2.2.3  IPv6 Considerations 
    
   Host name to IP address resolution protocols have no zeroconf 
   related differences for IPv4 and IPv6.   
    
2.3 IP Multicast Address Allocation Scenarios 
    
   IP Multicast is used for multi-receiver bulk-delivery 
   applications, such as audio, video, or news to conserve bandwidth.  
    
   IP multicast addresses range from 224.0.0.0 to 239.255.255.255. 
    
   [RFC 2365] defined multicast scopes are: 
     node-local (unspecified) 
     link-local (224.0.0.0/24) 
     local      (239.255.0.0/16) 
     site-local (unspecified)_ 
     organizational-local (239.192.0.0/14) 
     global (224.0.1.0-238.255.255.255) 
    
   A relative assignment is an integer offset from the highest 
   address in the scope and represents a 32-bit address. For example, 
   within the local scope, 239.255.255.0/24 is reserved for relative 
   allocations. 
    
   Source-Specific Multicast [SSM] addresses are 232.0.0.0 to 
   232.255.255.255. 
    
   Assumptions: 
   - The node-local and SSM addresses require no protocol or 
     interaction between multiple hosts, thus are not mentioned 
     further in this document.  
   - Global and organizational scoped addresses are meant for 
     networks of a greater scale than zeroconf protocols, thus are 
     not mentioned further in this document. 
   - Only local, link-local and site-local scopes are considered 
     further in this document. 
   - If it is desirable to restrict multicast packets from entering 
     and leaving a multicast scope boundary, it is assumed that the 
     router at the boundary is a boundary router as described in 
     [RFC 2365]. 
    
   Scenarios are scope enumeration, address allocation, and multiple 
   sources. 
    
    
    
   Hattig                                                  [Page 7] 
    
    
   Internet Draft      draft-ietf-zeroconf-reqts-06.txt     Nov 2000 
    
    
2.3.1  Scope Enumeration 
    
   Applications that leave the choice of scope up to the user require 
   the ability to enumerate what scopes the host is operating within. 
   In addition, services that are assigned relative addresses require 
   the ability to enumerate what scopes the host is within, only then 
   will a host be able to apply the relative address to a scope.  
    
   Requirements: 
   - MUST list which of the scopes (local, link-local, or site-local) 
     are available for hosts. 
   - MUST list per-scope address ranges that may be allocated. 
    
2.3.2  Address Allocation 
    
   IP multicast address allocation (only local, link-local and site-
   local scopes only) requires a host to specify a given scope, the 
   number of addresses, and a time before the allocation expires. 
   Coordination among hosts must occur to avoid allocating the same 
   address more than once. This coordination must span the entire 
   scope respective to the address. Upon deallocation or expiration 
   of an address, the address must become available to use again.  
    
   Requirements: 
   - MUST select a multicast address with a given scope and lease 
     time. 
   - MUST ensure address is not allocated more than once within the 
     scope of the address. 
   - MUST allow the multicast address to become available for use 
     again after the address expires or becomes deallocated. 
    
2.3.3  Multiple Source 
    
   An intercom system inside a home is an example of a multiple 
   source IP multicast application. In this type of application, 
   several sources may be sending packets destined to the same IP 
   multicast address.  
    
   Multiple source multicasting is unique from single source 
   multicasting in that the host that allocates the multicast address 
   may not be the host that deallocates the multicast address. Also, 
   with a claim and defend protocol where the allocating host is 
   usually responsible for defending an address, the host may not be 
   available to defend. Despite the unavailability of the allocating 
   host, the multicast address must still be deallocated when it is 
   no longer needed and must still be defended from incorrect use 
   while other host are using it.  
    


    
    
   Hattig                                                  [Page 8] 
    
    
   Internet Draft      draft-ietf-zeroconf-reqts-06.txt     Nov 2000 
    
    
   In other words, if the a host allocates a multicast address, then 
   leaves the multicast group, some other host must be designated to 
   defend and deallocate the address.  
    
   Requirements: 
   - A host other than the allocating host MUST be able to deallocate 
     and defend a multicast address. 
 
2.3.4  IPv6 Considerations 
    
   To date, no range has been reserved for dynamic allocation of 
   source-specific addresses in IPv6.  Hence, until such a range is 
   reserved, dynamic allocation of source-specific addresses applies 
   only to IPv4. 
    
   To date, no range has been reserved for dynamic allocation of 
   Link-scoped addresses in IPv4.  Hence, unless such a range is 
   reserved, dynamic allocation of Link-scoped addresses applies only 
   to IPv6. 
 
2.4 Service Discovery Scenarios 
    
   Service discovery protocols allow users to select services and/or   
   hosts by a name that is discovered dynamically, rather than the 
   user having to know the name in advance and type it in correctly.  
    
   Terms: 
      
     server - Hardware and/or software that offers services to 
     clients.  A server can make its service(s) known to clients by 
     means of a service discovery protocol. 
      
     service - Hardware and/or software that utilize a particular 
     protocol. Services range from printing to storing a file to 
     providing on-line pizza order and delivery.  
 
     service characteristics - Characteristics provide a finer 
     granularity of description to differentiate services beyond just 
     the service type. For example if the service type is printer, 
     the characteristics may be color, pages printed per second, 
     location, etc. 
      
     service discovery protocol - A service discovery protocol 
     enables a client (or clients) to discover a server (or servers) 
     of a particular service. A service discovery protocol is an 
     application layer protocol that relies on network and transport 
     protocol layers. 
      


    
    
   Hattig                                                  [Page 9] 
    
    
   Internet Draft      draft-ietf-zeroconf-reqts-06.txt     Nov 2000 
    
    
     service identifier - A service identifier allows clients, 
     servers, advertisers, discoverers, and registries to uniquely 
     identify an instance of a service.  
      
     service protocol - A service protocol is used between the client 
     and the server after service discovery is complete. 
 
     service type - A service type allows clients, servers, 
     advertisers, discoverers, and registries to uniquely identify a 
     type of service such as a printer service. 
    
   The scenarios are the discovery of a simple printer service and 
   the discovery of a printer manager that consolidates many printer 
   services.  
    
2.4.1  Printer Service 
    
   Networked enabled printers allow various networked clients to 
   submit print jobs.  A service discovery protocol MUST allow a 
   printer service to be discovered by devices needing to print. This 
   requires a service type as well as a service identifier to 
   distinguish instances of a single service type. Service discovery 
   MUST be independent from any particular printing protocol such as 
   lpd, raw-tcp, ipp. 
    
   Printers vary in their characteristics such as location, status, 
   dots per inch, etc. Discovering a service based on these 
   characteristics SHOULD be part of the service discovery protocol.  
    
   Service discovery MUST complete in a timely (10s of seconds) 
   manner.   
    
   Requirements: 
   - MUST allow a service to be discovered. 
   - MUST discover via service identifier and/or service type. 
   - MUST discover services without use of a service specific 
     protocol.  
   - SHOULD discover via service characteristics. 
   - MUST complete in a timely (10s of seconds) manner.   
 
2.4.2  IPv6 Considerations 
    
   Service discovery protocols have no zeroconf related differences 
   for IPv4 and IPv6.   
 
3  Security Considerations 
  
   The principal goal of Zero Configuration protocols is to provide 
   network configuration where existing configuration and 
   configuration services are unavailable.  This is at odds with 
    
    
   Hattig                                                  [Page 10] 
    
    
   Internet Draft      draft-ietf-zeroconf-reqts-06.txt     Nov 2000 
    
    
   secure operation since security mechanisms generally require some 
   preconfigurion (such as keys, certificates, etc.)  
    
   Generally speaking, security mechanisms in IETF protocols are 
   mandatory to implement.  However, a particular implementation 
   might permit a network administrator to turn off a particular 
   security mechanism operationally. However, implementations should 
   strive to be "secure out of the box" and have a safe default 
   configuration. 
    
   Zeroconf protocols MUST NOT be any less secure than the IETF 
   standard protocols that are used in the Internet.  This 
   consideration overrides the goal of allowing systems to obtain 
   configuration automatically.  This section explicitly describes 
   what this requires of each protocol area. 
    
   Security threats to be considered include both active attacks 
   (e.g. denial of service) and passive attacks (e.g. eavesdropping).  
   Protocols that require confidentiality and/or integrity should 
   include integrated confidentiality and/or integrity mechanisms or 
   should specify the use of existing standards-track security 
   mechanisms (e.g. TLS, ESP, AH) appropriate to the threat. 
 
3.1 IP interface configuration  
 
   Specific risks arise due to not securing IP interface 
   configuration. An active attacker could completely or selectively 
   prevent hosts from being properly configured.  If an attacker 
   'hoards' all IP addresses, inappropriately claiming to be 
   configured with them, this would prevent other hosts from 
   effectively participating in IP interface configuration.  
    
   An active attacker could be more selective and instead of claiming 
   it has all IP addresses, it could claim this only in response to 
   requests   from a specific host (or hosts) to deny them service.  
   It might also be possible that an active attacker could *partially 
   misconfigure* one or more victims to cause these nodes to have 
   partial (but not full) use of the network service. 
    
   This zeroconf protocol requires use of lower level address 
   resolution protocols (ARP [RFC 826] or IPv6 Neighbor Discovery 
   [RFC 2461]). 
    
   In the case of ARP and its cousins (e.g. Inverse ARP, reverse ARP, 
   Proxy ARP), there is no standard security mechanism.  Neither the 
   integrity of the message nor the endpoint authentication is 
   checked.  This makes it possible for an active attack to subvert 
   both of these protocols.  Since the scope of these protocols is 
   limited to a single broadcast network, the potential range of the 
   risk due to this attack is limited.  The effect of the attack, 
    
    
   Hattig                                                  [Page 11] 
    
    
   Internet Draft      draft-ietf-zeroconf-reqts-06.txt     Nov 2000 
    
    
   however, is to potentially disrupt all communication on the local 
   link. 
    
   It is appropriate to not require IP interface configuration 
   protocols to implement security mechanisms when the underlying 
   mechanisms themselves (used by all hosts) are not secure.  Thus 
   hosts using insecure IP interface configuration are no less secure 
   than hosts on the network that do not use an insecure protocol.  
   The security requirements demand that zeroconf protocols MUST NOT 
   compromise security if security is deployed.  In the case of IPv4, 
   it is acceptable (though not desirable) that address resolution is 
   insecure.  For that reason the IPv4 interface configuration 
   protocol MAY include no security mechanisms. 
    
    
   The IPv4 interface configuration protocol MAY omit security 
   mechanisms if and only if that protocol is not used for IPv6 and 
   cannot be extended to support IPv6.  It is strongly recommended 
   that it include security mechanisms, because many protocols are 
   extended later in ways not anticipated by the original 
   developer(s). 
    
   In the case of IPv6 Neighbor Discovery, this protocol can be 
   secured as it uses ICMPv6 messages, which run over IP.  IPv6 
   Neighbor Discovery messages can thus be protected for integrity 
   and endpoint authentication using IP Security.  [RFC 2401, 2402, 
   2403, 2404] 
    
   The zeroconf protocol for IPv6 interface configuration can 
    
   RANT - The zeroconf protocol for IPv6 interface configuration 
   MUST contain mandatory-to-implement mechanisms (either inside the 
   protocol itself or via external mechanisms such as TLS or AH) so 
   it can be protected from the threats described above. [RFC 2462] 
 
3.2 Name to Address Resolution 
 
   The security implications of this zeroconf protocol must be 
   compared against the DNS protocol.   
    
   DNS is a client-server protocol.  The zeroconf name to address 
   resolution protocol will likely use multicast so that any host may 
   respond to queries.  This broadens the possibility that host 
   authentication in the form of hostname-IP address mappings may be 
   compromised, since there all hosts effectively may behave as DNS 
   servers. 
    
   Currently it is possible to subvert DNS in various ways, unless 
   DNSsec [RFC 2535, 2931] is used.  For example: 
    
    
    
   Hattig                                                  [Page 12] 
    
    
   Internet Draft      draft-ietf-zeroconf-reqts-06.txt     Nov 2000 
    
    
   - A client may be configured with the address of an attacker's DNS 
     server.  For example, an active attacker on the same subnet as 
     the client may respond to DHCP DHCPDISCOVER messages and 
     deliberately configure the client to use a compromised DNS 
     server. 
    
   - An active attack against a DNS client is possible - where an 
     attacker unicasts a DNS reply to a client request that arrives 
     at the client before the legitimate server's response. 
    
   DNSsec makes such attacks ineffective as the client can verify the 
   data it retrieves using the DNS has been signed from a source that 
   the client has been configured to accept. 
    
   A zeroconf name to address resolution protocol MUST be compatible 
   with the use of DNSsec.  Therefore it MUST be possible for a host 
   running a zeroconf protocol to use DNS and DNSsec for 
   authenticated name resolution if that host (or its   
   administrator) chooses to do so. [RFC 2541]   
 
3.3 Service Discovery 
 
   The zeroconf service discovery protocol MUST NOT be less secure 
   than the IETF standard service discovery protocol:  The Service 
   Location Protocol, Version 2 [RFC 2608] (SLPv2). 
    
   The threat posed by using an insecure service discovery protocol 
   is that unauthorized entities may participate.  A client may be 
   misled to communicate with a host that has been compromised or 
   offers an antagonistic server that the client did not intend to 
   use.  This might be easy to detect (e.g. after attempting to use a 
   printer that doesn't exist, no printed upon paper appears.)   This 
   may also be difficult to detect (e.g. an illegitimate server 
   copies all data for an attacker's subsequent perusal and the user 
   has no way of knowing.)    
    
   A client could still detect that it is communicating with an 
   unauthorized server, but that would require authentication and 
   authorization mechanisms at a higher level (the client-server 
   protocol.) 
    
   SLPv2 protects against the threat of discovery of unauthorized 
   services.  SLPv2 messages that contain an answer may include an 
   associated authorization block.  This allows a client receiving it 
   to verify the answer, using digital signatures and a certificate-
   based system as the basis for authorization.  Other mechanisms are 
   possible.   
    


    
    
   Hattig                                                  [Page 13] 
    
    
   Internet Draft      draft-ietf-zeroconf-reqts-06.txt     Nov 2000 
    
    
   A zeroconf service discovery protocol MUST allow a client to 
   verify that a service advertisement sent by a server was created 
   by an authorized source. 
 
3.4 Multicast Address Allocation 
 
   The zeroconf multicast address allocation protocol MUST NOT be 
   less secure than MADCAP [RFC 2730] and AAP [AAP].  These are the 
   IETF standards track protocols for Multicast Address Allocation. 
    
   The threat of using an insecure Multicast Address Allocation 
   protocol is that an active attacker could 'hoard' all multicast 
   addresses - inappropriately claiming to have allocated them.  This 
   would prevent other hosts from effectively participating in the 
   Multicast Addresss Allocation protocol.  This could be done to 
   stop all participation or selectively, preventing particular hosts 
   from allocating addresses. 
    
   Both AAP and MADCAP do not include mechanisms for protecting 
   message integrity or end-point authentication.  These protocols 
   suggest the use of IPsec for this purpose, as they are compatible 
   with the IP Authentication Header.  A zeroconf multicast address 
   allocation protocol MUST either be compatible with IP AH or 
   provide another mechanism for optional-to-use (but mandatory to 
   implement) authentication. 
 
4  IANA Considerations  
    
   No known IANA considerations arise from this document. 
    
5  Full Copyright Statement  
    
   Copyright (C) The Internet Society (2000). All Rights Reserved.  
    
   This document and translations of it may be copied and furnished 
   to others, and derivative works that comment on or otherwise 
   explain it or assist in its implementation may be prepared, 
   copied, published and distributed, in whole or in part, without 
   restriction of any kind, provided that the above copyright notice 
   and this paragraph are included on all such copies and derivative 
   works. However, this document itself may not be modified in any 
   way, such as by removing the copyright notice or references to the 
   Internet Society or other Internet organizations, except as needed 
   for the purpose of developing Internet standards in which case the 
   procedures for copyrights defined in the Internet Standards 
   process must be followed, or as required to translate it into 
   languages other than English.  
    
   The limited permissions granted above are perpetual and will not 
   be revoked by the Internet Society or its successors or assigns.  
    
    
   Hattig                                                  [Page 14] 
    
    
   Internet Draft      draft-ietf-zeroconf-reqts-06.txt     Nov 2000 
    
    
    
   This document and the information contained herein is provided on 
   an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 
   ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 
   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 
   PURPOSE." 
    
6  Acknowledgements 
    
   Thanks to Peter Ford and Stuart Cheshire for hosting the NITS 
   (Networking In The Small) BOF that was the catalyst to forming the 
   Zeroconf Working Group.  
    
   Thanks to Erik Guttman and Stuart Cheshire for forming and 
   chairing the Zeroconf Working Group, which is responsible for this 
   document.  
    
   Thanks to Erik Guttman for providing key input to the service 
   discovery and the security sections.   
    
   Thanks to Dave Thaler for providing key input to the IP multicast 
   address allocation sections.   
    
   Thanks to Stuart Cheshire for providing key input to the 
   introduction and IP interface configuration sections.   
    
   Additional recognition goes the following people for their 
   influential contributions to this document and its predecessors: 
   Brent Miller, Thomas Narten, Marcia Peters, Bill Woodcock, Bob 
   Quinn, John Tavs, Matt Squire, Daniel Senie, Cuneyt Akinlar, Karl 
   Auerbach, Kanchei Loa, Dongyan Wang, James Kempf, Yaron Goland, 
   and Bernard Aboba, Ran Atkinson. 
    
   Editor: 
    
   Myron Hattig 
   Intel Corporation 
   3585 SW 198th Avenue 
   Aloha, OR 97007 
   myron.hattig@intel.com 
    
    
7  References 
    
   [RFC 826]   D. Plummer, "An Ethernet Address Resolution Protocol", 
                RFC 826, November 1982.  
    

    
    
   Hattig                                                  [Page 15] 
    
    
   Internet Draft      draft-ietf-zeroconf-reqts-06.txt     Nov 2000 
    
    
   [RFC 1034]  P. Mockapetris, Host names - Concepts and Facilities, 
                RFC 1034, November 1987 
    
   [RFC 1035]  P. Mockapetris, Host names - Implementations and 
                Specifications, RFC 1034, November 1987 
 
   [RFC 1487]  Yeong, W., Howes, T., and S. Kille, Lightweight 
                Directory Access Protocol, RFC 1487, July 1993. 
    
   [RFC 2026]  S. Bradner, The Internet Standards Process -- Revision 
                3, RFC 2026 Oct 1996 
    
   [RFC 2119]  S. Bradner.  Key words for use in RFCs to Indicate 
                Requirement Levels.  RFC 2119, March 1997. 
    
   [RFC 2131]  R. Droms.  Dynamic Host Configuration Protocol.  RFC 
                2131, March 1997. 
    
   [RFC 2365]  D. Meyer  Administratively Scoped Multicast Address  
                RFC 2365,July 1998. 
    
   [RFC 2401]  S. Kent, R. Atkinson, "Security Architecture for the 
                Internet Protocol", RFC 2401 November 1998 
    
   [RFC 2402]  S. Kent, R. Atkinson, "IP Authentication Header", RFC 
                2402 November 1998 
    
   [RFC 2461]  Narten, T., Nordmark, E., Simpson, W., "Neighbor 
                Discovery for IP Version 6 (IPv6)", RFC 2461, 
                December 1998. 
    
   [RFC 2462]  S. Thomson, T. Narten, "IPv6 Stateless Address 
                Autoconfiguration", RFC 2462, December 1998 
    
   [RFC 2535]  D. Eastlake, "Domain Name System Security Extensions", 
                RFC 2535, March 1999. 
    
   [RFC 2541]  D. Eastlake, "DNS Security Operational 
                Considerations", RFC 2541, March 1999 
    
   [RFC 2608]  E. Guttman, et all, "Service Location Protocol, 
                Version 2", RFC 2608, June 1999 
    
   [RFC 2730]  S. Hanna, B. Patel, M. Shah,  Multicast Address 
                Dynamic Client Allocation Protocol (MADCAP), RFC 
                2730, Dec 1999.  
    
   [RFC 2931]  D. Eastlake, "DNS Request and Transaction Signatures ( 
                SIG(0)s )", RFC 2931, September 2000 
    
    
    
   Hattig                                                  [Page 16] 
    
    
   Internet Draft      draft-ietf-zeroconf-reqts-06.txt     Nov 2000 
    
    
   [SSM]        H. Holbrook, "Source-Specific Multicast for IP", 
                draft-holbrook-ssm-00.txt, March 2000. A work in 
                progress. 
    
   [AAP]       Handley, M., Hanna, S., " Multicast Address Allocation  
                 Protocol (AAP)", draft-ietf-malloc-aap-04.txt, June 
                2000. A work in progress. 











































    
    
   Hattig                                                  [Page 17]