ZeroConf WG M. Hattig Internet Engineering Task Force Editor INTERNET DRAFT Intel Corp. Expires May 2000 November 24, 1999 ZeroConf Requirements draft-ietf-zeroconf-reqts-01.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 Zero Configuration (ZeroConf) Networks are a particular class of TCP/IP networks that may be established in the home, in small offices or even on an impromptu basis. ZeroConf Networks do not have and should not be expected to have user configurable network infrastructure such as DHCP servers, DNS and other administered services. This is because typical ZeroConf network users neither have the skill nor desire to configure, administer, or manage a network. This document presents ZeroConf protocol requirements for four areas: IP host configuration, domain name to IP address resolution, IP multicast address allocation, and service discovery. Security issues and the transitions between a ZeroConf protocol and a non-ZeroConf protocol are also discussed within the context of these protocol requirements. Hattig [Page 1] Internet Draft draft-ietf-zeroconf-reqts-01.txt Nov 1999 Table of Contents 1 Overview....................................................2 2 Introduction................................................3 2.1 Reading This Document.....................................3 2.2 ZeroConf Protocols........................................4 2.3 ZeroConf Networks.........................................7 3 Scenarios..................................................13 3.1 IP Host Configuration....................................13 3.2 Domain Name to IP Address Resolution.....................15 3.3 IP Multicast Address Allocation..........................16 3.4 Service Discovery........................................16 3.5 Additional Scenarios.....................................16 4 Security Requirements......................................17 4.1 IP Host Configuration....................................17 4.2 Domain name to IP address resolution.....................17 4.3 Multicast Address allocation.............................17 4.4 Service Discovery........................................18 5 Additional Considerations..................................18 5.1 IANA Considerations......................................18 5.2 Internationalization Considerations......................18 5.3 Security Considerations..................................18 6 Full Copyright Statement...................................18 7 Editor.....................................................19 8 References.................................................19 1 Overview Zero Configuration (ZeroConf) Networks are a particular class of TCP/IP networks. These networks may be established in a home, in a small office or even on an impromptu basis. ZeroConf networks typically do not have and should not be expected to have user configurable network infrastructure such as DHCP servers, DNS and other administered services. This is because typical ZeroConf network users neither have the skill nor desire to configure, administer, or manage a network. This document presents ZeroConf protocol requirements for four areas: IP host configuration, domain name to IP address resolution, IP multicast address allocation, and service discovery. Security issues and the transitions between a ZeroConf protocol and a non-ZeroConf protocol are also discussed within the context of these protocol requirements. This ZeroConf requirements document is a companion to a ZeroConf profile document. This requirements document lists requirements for protocols. The profile document relates the protocol requirements to actual protocols. In some cases, a protocol may meet all requirements to become one of the required protocols for ZeroConf networks. When protocols are insufficient or multiple Hattig [Page 2] Internet Draft draft-ietf-zeroconf-reqts-01.txt Nov 1999 protocols are competing, the profile document states the requirements of the protocol and the relationship of the requirements to the existing protocols. The major sections to this requirements document are the Introduction, Scenarios, and Security. The introduction provides the background information to have a meaningful scenarios discussion. The scenarios describe a set of actions then the requirements from protocols to satisfy those actions. The security section re-examines the scenarios with security considerations. 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]. 2 Introduction This introduction presents how to best read this document and provides the restrictions, definitions and assumptions for the remainder of the document. 2.1 Reading This Document The major sections of the document are this Introduction, Scenarios, and Security. This Introduction provides the necessary information to have a concise scenario discussions. This includes reference information, definitions, restriction, and assumptions. All readers should read the entire introduction. The Scenarios Section lists specific scenarios. Each scenario results in protocol requirements. Scenarios are chosen to generate unique requirements. Each scenario has an overview, key points, and protocol requirements. The Security section lists security issues and requirements that relate to the scenarios. Because this document deals with a wide range of networking topics, many sections are divided by topic. The division allows readers focus on particular interests. The topics are: - IP host configuration, - domain name to IP address resolution, - IP multicast address allocation, and - service discovery. Hattig [Page 3] Internet Draft draft-ietf-zeroconf-reqts-01.txt Nov 1999 The below references follow this division with additions of security and general knowledge references. Note that some working groups are listed because they specify protocols that impact ZeroConf protocols. IP host configuration: - [IPv4Auto] Ipv4 Auto-Configuration ID - [RFC 1918] RFC 1918 Private Addresses - [RFC 2131] RFC 2131 DHCP - [RFC 2132] RFC 2132 DHCP Options - [RFC 2462] IPv6 Auto-Configuration - [RFC 2461] IPv6 Neighbor Discovery - [IPv6 WG] Next Generation (Ipv6) WG - [DHC WG] Dynamic Host Configuration WG Domain name to IP address resolution: - [Mcast DNS] Multicast DNS - [RFC 1001] NETBIOS: CONCEPTS AND METHODS - [RFC 1002] NETBIOS: DETAILED SPECIFICATIONS - [RFC 1034] RFC 1034 DNS - [DNS WG] DNS Update WG Multicast address allocation: - [MADCAP] Multicast Address Dynamic Client Alloc Protocol ID - [RFC 2365] RFC 2365, Administratively Scoped Multicast Address - [MALLOC WG] Multicast Address Allocation WG Service discovery: - [SSDP] Simple Service Discovery Protocol ID - [RFC 2608] RFC 2608 Service Location Protcol v2 - [RFC 2609] RFC 2609 SLP Schemes Security: - [RFC 2316] RFC 2316, IAB Security Architecture Workshop - [RFC 2401] RFC 2401, Security Architecture for IP - [RFC 2411] RFC 2411, IP Security Document Roadmap - [RFC 2504] RFC 2504, User's Security Handbook General knowledge: - [STD3] RFC 1122 Requirements for Internet Hosts - Comm Layers - [STD4] RFC 1123 Requirements for Internet Hosts - App Layers - [RFC 1458] RFC 1458 Requirements for Multicast Protocols - [RFC 1812] RFC 1812 Requirements for Internet Gateways All readers should be familiar with the general knowledge references. 2.2 ZeroConf Protocols Hattig [Page 4] Internet Draft draft-ietf-zeroconf-reqts-01.txt Nov 1999 This section defines "ZeroConf protocol". Then, the assumptions and restrictions of protocols are discussed. The assumptions and restrictions are divided by networking topic. 2.2.1 Definition of ZeroConf Protocol A ZeroConf protocol requires no user configuration and does not rely on the existence of a centralized server. A non-ZeroConf protocol requires user configuration or relies on a centralized server. A ZeroConf protocol must easily transition in three ways: 1. from a ZeroConf protocol to a non-ZeroConf protocol, 2. from a non-ZeroConf protocol to a ZeroConf protocol, and 3. from a ZeroConf protocol back to a ZeroConf protocol (possibly with new values). The ZeroConf to non-ZeroConf transition occurs when either a device moves to a different network or when a server becomes accessible on the network. For example, if a DHCP server gets added to a network, then [IPv4Auto] is no longer be needed. The non-ZeroConf to ZeroConf transition occurs when either a device moves to a different network or when a server is no longer accessible. For example, if a DHCP server is no longer on the network so IP host must configure with [IPv4Auto]. The third transition occurs when a device moves from one ZeroConf network to another ZeroConf network or when the ZeroConf network topology changes significantly. For example a bridge is installed between two existing ZeroConf networks. This is more like "restarting" the ZeroConf protocol than transitioning. Ideally these transitions occur due to some active trigger. When there is no active trigger, a periodic timer should passively allow for the transition to occur. DHCP and [IPv4Auto] simply provide a clear illustrative example; these protocols are in no way required by this document. A ZeroConf protocol in one area may coexist with a non-ZeroConf protocol in another area. To illustrate this point, suppose there are standard ZeroConf and non-ZeroConf protocols for IP host configuration and domain name to IP address resolution (two of the four Areas). For IP host configuration, the ZeroConf protocol is "protocol-A." The non-ZeroConf protocol is "protocol-B", supported by a fully conformant "protocol-B" server. Hattig [Page 5] Internet Draft draft-ietf-zeroconf-reqts-01.txt Nov 1999 For domain name to IP address resolution, the ZeroConf protocol is "protocol-C". The non-ZeroConf protocol is "protocol-D" supported by a fully conformant "protocol-D" server. Within a single network, the non-ZeroConf protocol-B (with its server) may co-exist with the ZeroConf protocol-C. 2.2.2 IP Host Configuration Of the four areas, IP host configuration is the most straightforward. IP host configuration is complete when there is a known IP address, netmask, and default route for an interface on an IP host. DHCP is the most prevalent non-ZeroConf solution deployed today. Network topologies greatly affect IP host configuration. While hosts on a single IP network do not need a netmask or default route to communicate, hosts on different IP networks do. 2.2.3 Domain name to IP address resolution Domain names within the ZeroConf network must be resolved to IP addresses. This enables one of the most basic of TCP/IP networking paradigms of applications only being aware of host names and not IP addresses. Domain name to IP address resolution is accomplished in many networks with DNS; therefore, it is highly likely that DNS will play a key role in this area. ZeroConf protocols must allow resolution of fully qualified domain names as well as non-fully qualified domain names. 2.2.4 IP Multicast Address Allocation [MADCAP] defines a sever-based allocation of IP multicast addresses. Much like DHCP and DNS servers, [MADCAP] servers will likely play a key role in the IP multicast address allocation Area. [EDITOR'S NOTE: Help wanted. There has not been a lot of discussion on IP multicast address allocation. ] 2.2.5 Service Discovery While IP Host configuration is the most straightforward, service discovery is the least. The leading protocols in this Area are SLPv2 [RFC 2608] and [SSDP]. Hattig [Page 6] Internet Draft draft-ietf-zeroconf-reqts-01.txt Nov 1999 [EDITOR'S NOTE: HELP!!!! There has been lots of discussion on the list, but before I'm able to write something useful we need some high-level discussion. a) What are the major components of service discovery? b) Definition of a service c) Is service discover conclusive? d) What kinds of services does ZeroConfig network want to discover? or What are the service we are talking about? e) What is the goal of service discovery? f) What is the position of service discovery protocol in network? g) Bootstrapping protocol or not? h) How does a service discovery protocol support both simple and complex devices in a ZeroConfig network? ] 2.3 ZeroConf Networks A ZeroConf network is a network that at some point in time has one or more ZeroConf protocols. By this definition, almost all networks are ZeroConf networks. This definition is intentionally broad because this document does not intend to mandate some networks to be ZeroConf or exclude other networks from using ZeroConf protocols. The sole intention of using the term "ZeroConf network" is to focus the discussion within this document. Generally speaking, the Internet and corporate LANs are non- ZeroConf networks because they have many non-ZeroConf protocols. Also, generally speaking, ZeroConf networks are grouped by the topologies shown below. This section describes the existing Internet network model, the ZeroConf topologies, and a summary of the key points. 2.3.1 Existing Internet Model All networks in this document follow the Internet Model as described in RFC 1812. Specifically, networks consist of bridges, routers, hosts, link layer networks, and IP networks to form internets. [STD 3] and [STD 4] define IP host requirements. A summary of the terms from [RFC 1812] that apply to this document are: - Bridges: a device that routes link layer packets (e.g. Ethernet packets) between link layer networks (e.g. Ethernet) based on the destination link layer addresses (e.g. 48-bit Ethernet address) of a packet. - Routers: a devices that routes IP packets between IP networks based on the destination IP address of a packet. - IP network: a network that consists of hosts with interfaces that share the same network portion of the IP address. A single Hattig [Page 7] Internet Draft draft-ietf-zeroconf-reqts-01.txt Nov 1999 IP network may physically consist of several link layer networks connected by a bridge, but it is one logical IP network; the hosts remain unaware of the bridge or multiple link layer networks. - internet: a network that consists of multiple IP networks connected by routers. 2.3.2 Isolated Single IP Network In an isolated single IP network topology, hosts simply connect directly to each other with no routers. Also, there is no connectivity to non-ZeroConf networks. Enabling these types of simple networks is one of the primary motivations behind this document. The two primary instances of single IP-network topologies are shown in Figure 1 and Figure 2. ***************************************************** * ZeroConf Network * * * * ------ crossover cable ------- * * | | * * | | * * +------+ +------+ * * | Host | | Host | * * +------+ +------+ * * * ***************************************************** Figure 1. Impromptu network The ZeroConf network in Figure 1 has two hosts connected through a crossover cable. A crossover cable between two hosts is one of the most common impromptu ZeroConf networks. Infrared or other point- to-point wireless technologies are other examples. ***************************************************** * ZeroConf Network * * * * -------[ HUB ]------- * * | | | * * | | | * * +------+ +------+ +------+ * * | Host | | Host | | Host | * * +------+ +------+ +------+ * * * ***************************************************** Figure 2. Fixed location network Hattig [Page 8] Internet Draft draft-ietf-zeroconf-reqts-01.txt Nov 1999 The Figure 2 ZeroConf network has a small number of hosts connected through a hub. A hub between hosts is the most common fixed-location ZeroConf network. Only an IP address and netmask is needed for an IP host to communicate with other hosts on these networks. If the IP address is a link-local (169.254/16) address, the netmask is not needed. 2.3.3 Single IP Network with a Gateway In a topology with a single IP network and a gateway, the gateway is a specialized router. It resides between the ZeroConf and non- ZeroConf networks. The single IP network within the ZeroConf network connects directly to the gateway. The gateway is specialized because it restricts packets that pass between the ZeroConf and non-ZeroConf networks to ensure autonomy of the ZeroConf network and to avoid many security problems. For the remainder of this document the term gateway has this meaning. Figure 3 shows the single IP network with a gateway topology. *************************** * * * non-ZeroConf * * Network * * * *************************** | | | +----------------+ **********************| Gateway |************************* * ZeroConf Network +----------------+ * * | * * | * * | IP Network * * ------------------------|----------------------------- * * | | | | | * * | | | | | * * | | | | | * * +------+ +------+ +------+ +------+ +------+ * * | Host | | Host | | Host | | Host | | Host | * * +------+ +------+ +------+ +------+ +------+ * * * ***************************************************************** Figure 3. Single IP Network with gateway Topology Hattig [Page 9] Internet Draft draft-ietf-zeroconf-reqts-01.txt Nov 1999 Examples of this topology include a typical small business network with a single gateway and a single Ethernet segment; a home network with a single gateway and a single Home Phonewire Network Alliance (HomePNA) link connecting a few PCs; and an Internet cafe where people with 802.11 equipped laptops roam into the cafe, lease some Internet connection time, then start surfing the Internet while sipping their mocha. The key points to this topology are that no default route is needed for communication within the ZeroConf network; the netmask and default route allow hosts to easily communicate outside the ZeroConf network through the gateway; and IP broadcast packets can reach all hosts and can be used to query for servers. 2.3.4 Star Topology Star topologies center around a gateway. A gateway is a router that resides between the ZeroConf and non-ZeroConf networks. Multiple link layer networks that resides in the ZeroConf network are directly connected to the gateway. In addition to the above definition of a gateway, the gateway in a star topology provides connectivity between all IP networks within the ZeroConf network. Figure 4 shows the general form of this topology. *************************** * * * Non-ZeroConf * * Network * * * *************************** | | | +----------------+ **********************| Gateway |************************* * ZeroConf Network +----------------+ * * | | | * * | | | * * | | | * * | | | * * IP network A | | | IP network B * * ------------------| | |---------------------- * * | | | | | * * | | | IP network C | | * * | | | | | * * +------+ +------+ +------+ +------+ +------+ * * | Host | | Host | | Host | | Host | | Host | * Hattig [Page 10] Internet Draft draft-ietf-zeroconf-reqts-01.txt Nov 1999 * +------+ +------+ +------+ +------+ +------+ * * * ***************************************************************** Figure 4. Generic Star Topology The primary example of this topology is a future home network with many link layers such as HomePNA, HomeRF, IEEE 802.11, and IEEE 1394-1995. Most agree that home networks will be composed of many different link layers that meet specific needs. These networks either require no new wires to be installed or provide some special function such as the ability to roam or to carry high- quality video streams. This topology requires all hosts to be configured with IP address, netmask, and default route to communicate within the ZeroConf network or outside the ZeroConf network. IP multicast must be used to reach all hosts in the ZeroConf network (or to query for servers) and the gateway must limit that IP multicast traffic from leaving the ZeroConf network. 2.3.5 Ad-hoc Topology Ad-hoc topologies have multiple gateways and/or multiple routers. As with other topologies, gateways in an ad-hoc topology reside between the ZeroConf network and the non-ZeroConf network. The gateways ensure autonomy of the ZeroConf network by restricting packets between the ZeroConf and non-ZeroConf networks. Routers reside somewhere within the ZeroConf network and connect multiple IP networks. Figure 5 shows an instance of an ad-hoc network. *************************** * * * Internet * * * *************************** | |ADSL | +----------------+ **********************| Gateway |************************* * ZeroConf Network +----------------+ * * | | * * | | * * IEEE 1394-1995 +--------+ | | HomePNA * * -----------| Router |---| |-------------------- * * | | +--------+ | | | * * | | | HomeRF | | * * | | | | | * Hattig [Page 11] Internet Draft draft-ietf-zeroconf-reqts-01.txt Nov 1999 * +------+ +------+ +------+ +------+ +------+ * * | Host | | Host | | Host | | Host | | Host | * * +------+ +------+ +------+ +------+ +------+ * * * ***************************************************************** Figure 5. Home Network Figure 5 shows a future home network. Such networks will come about through users installing follow-on networks in their homes over time without a long-term plan. Ad-hoc networking is the expected long-term deployment pattern of many home networks. This topology requires all hosts to be configured with IP address, netmask, and default route to communicate within the ZeroConf network or outside the ZeroConf network. IP multicast must be used to reach all hosts in the ZeroConf network (or to query for servers) and the gateway must limit that IP multicast traffic from leaving the ZeroConf network. In addition, router-to-router protocols may be required. This document does not consider router-to-route ZeroConf protocols; only ZeroConf protocols between hosts. In some limited cases, ZeroConf protocols may require interaction between hosts and routers. [EDITOR'S NOTE: We need to discuss this a little more on the list. We're getting close.] 2.3.6 Summary The purpose of showing topologies is to restrict and focus the discussion in this document. The purpose is not to mandate some networks as ZeroConf and others as non-ZeroConf. The gateway is a specialized router. It restricts packets that pass between the ZeroConf and non-ZeroConf networks to ensure autonomy of the ZeroConf network and to avoid many security problems. All ZeroConf protocols MUST operate in single IP networks and star topologies. ZeroConf protocols SHOULD operate in ad-hoc networks. However, router-to-router communication in such networks is outside the scope of this document. As topologies increase in complexity, the assumptions increase in complexity. For example, hosts in an isolated single IP network topology can use link-local addresses without configuring a netmask or default route. Alternately, hosts in ad-hoc topologies must use a netmask and a default route. Hattig [Page 12] Internet Draft draft-ietf-zeroconf-reqts-01.txt Nov 1999 3 Scenarios This section lists ZeroConf scenarios. This section does not discuss specific protocols. Instead this section lists scenarios that lead to requirements for protocols. Each scenario begins with an explanation or overview. Then, the key points of the scenario are identified along with requirements. To consistently provide this information, each scenario has the following outline: - Overview - Key Points - Protocol Requirements To provide further focus, the scenarios are grouped by networking topic. [EDITOR'S NOTE: These scenarios have not been agreed upon by the ZeroConf WG, thus they will likely change. For this reason, only the limited information is provided for each scenario in the current draft.] 3.1 IP Host Configuration 3.1.1 Single IP Network Communication 3.1.1.1 Overview Hosts on a single IP network within the ZeroConf network communicate to each other. 3.1.1.2 Key Points This scenario applies to single IP network topologies (isolated or with a gateway). As stated, if link-local IP address is used, then only the IP address must be configured. Otherwise, an IP address and netmask must be configured. 3.1.1.3 Protocol Requirements - IP hosts MUST configure an IP address. - IP hosts MUST configure a netmask (if the IP address is not link-local). - The host number of an IP address MUST be unique within a single IP network. - The network number of an IP address MUST equal the network number of other IP addresses within a single IP network (if the IP address is not link-local). Hattig [Page 13] Internet Draft draft-ietf-zeroconf-reqts-01.txt Nov 1999 3.1.2 Multiple IP Network Communication 3.1.2.1 Overview Hosts on multiple IP networks within a ZeroConf network communicate to each other. 3.1.2.2 Key Points This scenario is important for star topologies and ad-hoc topologies. 3.1.2.3 Protocol Requirements - IP hosts MUST configure an IP address. - IP hosts MUST configure a netmask. - IP hosts MUST configure a default route. - The host number of an IP address MUST be unique within a single IP network. - The network number of an IP address MUST equal the network number of other IP addresses within a single IP network. - Network numbers of IP addresses MUST be unique within the entire ZeroConf network. - IP address MUST be routable within the ZeroConf network. 3.1.3 Bridge Installed 3.1.3.1 Overview Between two operational IP networks, a bridge (or hub) is installed. Now, two hosts on the newly formed IP network may share the same IP address. In addition, hosts on different link layer networks may not have been using the same network number and now they must share the same network number. 3.1.3.2 Key Points This is a special case of a previous scenario when IP hosts first communicate on the same IP network. All the key points and requirements to the previous scenario apply. In addition, host must have the ability to re-configure their IP address and net mask. 3.1.3.3 Protocol Requirements - Hosts MUST be able to re-configure their IP address and netmask after networks are connected. - All requirements in section 3.1.1.3. Hattig [Page 14] Internet Draft draft-ietf-zeroconf-reqts-01.txt Nov 1999 3.1.4 Router Installed 3.1.4.1 Overview Within a ZeroConf network, a router is installed after IP hosts have been configured to communicate throughout the ZeroConf network. Multiple IP networks within the ZeroConf network may now share the same IP network number. 3.1.4.2 Key Points This is a special case of a previous scenario when hosts on a multiple IP networks within a ZeroConf network communicate. All the key points and requirements to the previous scenario apply. In addition, host must have the ability to re-configure their IP address, net mask, and default route. 3.1.4.3 Protocol Requirements - Hosts MUST re-configure IP address, net mask, and default route at various times after the initial configuration. - All requirements in section 3.1.2.3. 3.2 Domain Name to IP Address Resolution 3.2.1 Resolve Non-Fully Qualified Name 3.2.1.1 Overview Domain names within the ZeroConf network must be resolved to IP addresses. This enables one of the most basic of TCP/IP networking paradigms of applications only being aware of host names and not IP addresses. 3.2.1.2 Key Points Name resolution must span the entire ZeroConf network, but be limited by the gateway from leaving or entering the ZeroConf network. This protocol should include the ability for a host to choose a name, determine if the name is in use, and then choose a different name if it is re-used. The name resolution protocol must become active at various times such as when previously disconnected yet operational networks now become connected by the installation of a router or a bridge. 3.2.1.3 Protocol Requirements - A host that wishes to be addressable by name MUST select a domain name. Hattig [Page 15] Internet Draft draft-ietf-zeroconf-reqts-01.txt Nov 1999 - A host MUST determine if the domain name is in use by another host. - A host MUST participate to defend the name it uses. - A host MUST be able to reconfigure its name in the case it was unable to successfully defend the name it previously used. - At various times a host MUST actively determine if another host is using its name. - Gateways MUST restrict this protocol from leaving or entering the ZeroConf network. - Routers MUST route this protocol to ensure it spans the entire ZeroConf network. 3.2.2 Resolve Fully Qualified Name [TBD] 3.2.2.1 Overview 3.2.2.2 Key Points 3.2.2.3 Protocol Requirements 3.3 IP Multicast Address Allocation [TBD] 3.3.1 Allocate XX Scoped IP multicast address [TBD, one XX for each relevant scope.] 3.4 Service Discovery 3.4.1 Discover Printer [TBD] 3.4.2 Discover Shared Internet Access Service [TBD] 3.4.3 Discover Internet Web Server [TBD] 3.4.4 Discover Multiple Web Servers 3.5 Additional Scenarios [EDITOR'S NOTE: Please post additional scenarios for discussion to ZeroConf@merit.edu. Eventually this section will be removed.] Hattig [Page 16] Internet Draft draft-ietf-zeroconf-reqts-01.txt Nov 1999 4 Security Requirements The principal goal of security requirements for ZeroConf networking is to not make IP networking less secure than it is without the use of ZeroConf protocols. This is challenging since ZeroConf provides the ability for any host to obtain host configuration, to discover and to use network resources. In the case where ZeroConf access media is physically accessible (e.g. wireless, powerline) or routed to additional network segments, there is no longer any physical security. The following sections are security considerations for the four Areas which this document addresses. The threats fall into three broad categories: Hoarding: Hosts claim all available resources, whether they plan to use them or not. This is a form of denial of service attack. Masquerading: Hosts can respond to requests that they should not so they can masquerade as another host. Antagonistic Server: A server could offer support for a critical service but intentionally misconfigure hosts on the network. [TO DO: Add security requirements after potential threats have been identified and selected as requiring attention by the ZEROCONF Working Group.] 4.1 IP Host Configuration Potential threats include: - A host could hoard IP addresses, denying others access to the network. - A host could pose as an antagonistic DHCP server and misconfigure other hosts on the network. 4.2 Domain name to IP address resolution Potential threats include: - A host could masquerade, responding to names requests illegitimately. - A host could hoard names, responding to all 'claim' requests. - A host could pose as an antagonistic DNS server and fail to resolve names correctly, or intentionally resolve them incorrectly. 4.3 Multicast Address allocation Potential threats include: Hattig [Page 17] Internet Draft draft-ietf-zeroconf-reqts-01.txt Nov 1999 - A host could hoard multicast addresses, denying others the ability to obtain them. 4.4 Service Discovery Potential threats include: - Servers could masquerade by responding to service discovery requests which they shouldn't respond to. - A host could pose as an antagonistic service discovery 'infrastructure element.' Some service discovery protocols offer a 'registry', 'directory', 'proxy' or other infrastructure element for scalability. 5 Additional Considerations 5.1 IANA Considerations There are no known IANA considerations arising from this document. 5.2 Internationalization Considerations ZeroConf protocols may exchange human readable strings. Human readable strings may need to be internationalized. 5.3 Security Considerations ZeroConf security considerations are in Section 5 of this document. 6 Full Copyright Statement Copyright (C) The Internet Society (1997). 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 18] Internet Draft draft-ietf-zeroconf-reqts-01.txt Nov 1999 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." 7 Editor Myron Hattig Intel Corporation 2111 NE 25th Ave. JF3 206 Hillsboro, OR 97124 myron.hattig@intel.com 8 References [STD 3] R. Braden Requirements for Internet Hosts -- Communication Layers RFC 1122, STD 3, October 1989 [STD 4] R. Braden, Requirements for Internet Hosts -- Application and Support RFC 1123, STD 4 October 1989 [RFC 1001] PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A TCP/UDP TRANSPORT: CONCEPTS AND METHODS, RFC 1001 March, 1987 [RFC 1002] PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A TCP/UDP TRANSPORT: DETAILED SPECIFICATIONS, RFC 1002, March 1987 [RFC 1034] P. Mockapetris, Domain Names - Concepts and Facilities, RFC 1034, November 1987 [RFC 1458] R. Braudes, Requirements for Multicast Protocols, RFC 1458, May 1993 [RFC 1918] D. Karrenberg, et al, Address Allocation for Private Internets, RFC 1918, Feb 1996 [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. Hattig [Page 19] Internet Draft draft-ietf-zeroconf-reqts-01.txt Nov 1999 [RFC 2132] S. Alexander, R. Droms DHCP Options and BOOTP Vendor Extension RFC 2132, March 1997. [RFC 2316] S. Bellovin, Report of the IAB Security Architecture Workshop, RFC 2316, April 1998 [RFC 2365] D. Meyer Administratively Scoped Multicast Address RFC 2365,July 1998. [RFC 2401] S. Kent, Security Architecture for the Internet Protocol, RFC 2401, Nov 1998 [RFC 2411] R. Thayer, IP Security Document Roadmap, RFC 2411, Nov 1998 [RFC 2461] T. Narten, E. Nordmark, W. Simpson Neighbor Discovery for IP Version 6 (IPv6) RFC 2461, December 1998. [RFC 2462] S. Thomson, T. Narten IPv6 Address Autoconfiguration RFC 2462, December 1998. [RFC 2504] E. Guttman, Users' Security Handbook, RFC 2504, Feb. 1999 [RFC 2608] E. Guttman, C. Perkins, J. Veizades, and M. Day. Service Location Protocol version 2. RFC 2608, June 1999. [RFC 2609] E. Guttman, C. Perkins, J. Kempf Service Templates and service: Schemes, RFC 2609, June 1999. [IPv4Auto] R. Troll Automatically Choosing an IP Address in an Ad-Hoc IPv4 Network draft-ietf-dhc-ipv4-autoconfig- 04.txt April, 1999. A work in progress. [DisAuto] R. Troll, DHCP Option to Disable Stateless Auto- Configuration in IPv4 Clients draft-ietf-autoconfig- 04.txt February, 1999. A work in progress. [MCAST DNS] B. Woodcock, B. Manning Multicast Discovery of DNS Services draft-manning-multicast-dns-01.txt December, 1998. A work in progress. [MADCAP] iS. Hanna, B. Patel, M. Shah Multicast Address Dynamic Client Allocation Protocol (MADCAP) draft- ietf-malloc-madcap-05.txt May 1999. A work in progress. Hattig [Page 20] Internet Draft draft-ietf-zeroconf-reqts-01.txt Nov 1999 [SSDP] Y. Goand et al, Simple Service Discovery Protocol, draft-cai-ssdp-v1-02.txt, June 1999, A work in progress. [IPv6 WG] IP Next Generation WG, www.ietf.org/html.charters/ipngwg-charter.html. [DHC WG] Dynamic Host Configuration WG, www.ietf.org/html.charters/dhc-charter.html. [NAT WG] Network Address Translation WG, www.ietf.org/html.charters/nat-charter.html. [DNS WG] DNS Update WG, www.ietf.org/html.charters/dnsind- charter.html [MALLOC WG] Multicast Allocation WG Charter, www.ietf.org/html.charters/malloc-charter.html. Hattig [Page 21]