Internet Egineering Task force Peter van der Stok Internet DRAFT Philips Research 30 November 2001 Expires in 6 months Issues for ZeroConf Working group draft-vanderstok-zeroconf-issues-00.txt Status of This Memo This document is an individual contribution to the Internet Engineering Task Force (IETF). Comments should be submitted to the srvloc@srvloc.org 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 RFC2026. 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. Table of Contents 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Network utilisation . . . . . . . . . . . . . . . . . . . . . . 2 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Naming. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Security considerations . . . . . . . . . . . . . . . . . . . . 6 6. Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. References. . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Author's address. . . . . . . . . . . . . . . . . . . . . . . . 9 9. Full Copyright Statement. . . . . . . . . . . . . . . . . . . . 9 Abstract This note considers some issues forthcoming from in-home networks that use the ZeroConf protocols at the network layer. van der Stok, Peter Expires: 21 May 2002 [Page 1] Internet Draft ZeroConf issues November 2001 1. Introduction A home network is a good candidate for the utilisation of the protocols that are developed by the ZeroConf working group. A home network is interesting because these networks are used by non professionals who may frequently reconfigure the network by just switching on/off a device. This puts a rather stringent restriction on the amount and kind of user administration that can be relied on: practically none. The ZeroConf requirements [IDZR] and the link-local protocol [IDLL] are a good basis for the allocation of network addresses to the hosts in a home network. Both documents consider networks where no management by the user is needed. A home network can range from an ad-hoc network of two hosts to a larger stand-alone network comprising several bridged networks without DHCP server [RFC2131] to a network connected to the Internet with administration by a DHCP server. The DHCP server is possibly configured by the Internet service provider without intervention by the owner or user of the home network. The home network can be connected to more than one Internet service provider with different DHCP contents. The home network is considered one administrative unit. Its boundaries may change dynamically in two ways: one, devices are connected and disconnected (or just switched on and off) and two, the network may connect devices in just one home or temporarily interconnect more than one home. It can be much cheaper to interconnect two home-networks via a private, possibly very cheap, bridge than to start communication via a network provider who needs to be paid. This note considers the utilisation of a ZeroConf protocol in a home network. A number of consumer electronic appliances are interconnected, possibly also connected to one or more general purpose computers. Two specific aspects of these networks that in my opinion fall under the charter of the ZeroConf working group, are discussed: (1) naming of appliances and (2) security, especially in wireless networks. The note starts with an introduction into the utilisation by a user of such a home network. 2. Network utilisation A home network will serve the ICED purposes: - Information: for example searching on the WEB. - Communication: for example chatting. - Entertainment: for example viewing an audio/video stream. - Domotica: for example switching on the central heating. Such a home network will need a connection to the outside world. Audio/Video streams will be received from an entertainment van der Stok, Peter Expires: 21 May 2002 [Page 2] Internet Draft ZeroConf issues November 2001 broadcaster, possibly via a cable operator. Connections will be made to World Wibe Web to obtain information or to establish contact via an Internet provider, possibly realised with a cable or via a telephone wire (ADSL, ISDN). Connections are established between devices within the home such as set top boxes, TV sets, DVD players, WebCams, PCs, and many others. Some of these devices may be wireless, portable and permanently connected to the home network like a ZapTop. Some devices may be wireless, portable and connected to the home network for only parts of the day like a PDA or the Notebook that is also used in the office. A person can, with his PDA attached to the network of his own home, visit the neighbour and connect to the neighbour's home network to show the video he is currently watching. The above shows that the network may be very dynamic and many devices, authorized or not, may be connected to the home network, either directly or via connections to Internet. Additionally, many communication standards (e.g. IEEE 802.11, Ethernet, IEEE 1394, HomeRF) and interoperability standards (like UPnP, HAVi or JINI) will coexist in the network and need to collaborate. The Internet protocol is probably the best candidate to provide network facilities over the heterogeneous communication media in the home and to act as the vehicle to connect the home to the outside world. In the following sections the facilities provided by the presently proposed ZeroConf protocols are compared with the projected utilisation by future users of home networks. 3. Scenarios Four scenarios are considered within the following context: two neighbours have two networks with named devices. Some of these devices are wireless. The scenarios do not represent recommended behaviour but indicate possible behaviour to illustrate an issue. These underlying issues are discussed in more detail in sections 4 and 5. Scenario 1: A friend of the children enters the home, takes his portable, wireless device called myDevice and connects it to the network within the home. He displays which devices are present and then establishes the connections he wants. Some time later the owner of the house enters with his portable, wireless device called myDevice and wants to connect it to the home network without being bothered by the friend's myDevice. Some time afterwards the friend notices that his device is not connected any more, changes its name to friendDevice and reconnects the device. Scenario 2: An occupant of the home drives in his car and connects his PDA via an UTMS connection to Internet. He types in the domain name of his home and displays the devices that are operational. The devices respond with the names that were attributed locally suffixed by the current van der Stok, Peter Expires: 21 May 2002 [Page 3] Internet Draft ZeroConf issues November 2001 domain name of his home. He switches on the heating and disconnects from his home. Scenario 3 Neighbour, A, installs a film that he promised his neighbour B on his DVD player. His neighbour, B, does not have a DVD player and so A visits B's home with his PDA connected to his own home. He connects his PDA also to the network of B and displays the devices connected to the network of B. Many of neigbour A's devices have the same name as the devices of neighbour B. The devices of neigbour B are suffixed with a domain name to the PDA of A. The devices of neighbour A remain known to A's PDA with their original name. Neighbour A starts the film on his DVD player and directs it to the TV of neighbour B. The PDA acts as a bridge for the two networks of A and B. Scenario 4 An occupant makes a connection to Internet via an Internet provider. The names of his devices have a different name for the Internet provider than for the occupant. The occupant is not aware of this name change. When a family member connects from Internet to the home, the family member also recognizes the same names that are used locally. Other unauthorised people can from Internet only use the names provided by the Internet provider. 4. Naming Users of the network will like to name their appliances (e.g. MyTV or tuner.in.the.bedroom) to address them by name for the execution of commands or the exchange of Audio/Video (A/V) streams. The possibilities created by portable, wireless devices have an impact on the treatment of name clashes. In a fixed, administrated network the addition of a new device with a name already attributed is simply solved. However with portable, wireless devices in a Zero Configuration network it is less clear whether the already present device should keep its name or that the newly arriving device must keep its name. The present device can be a device of a neighbour while the newly arriving one is brought home by the network owner returning from his work. There is a need to distinguish between devices that belong to the network, "resident" devices, and visiting devices. Another example in case is provided by scenario 3. Two home networks are connected by a wireless device that acts as bridge between two network parts. We cannot exclude that both networks hold devices with names like MyTV or Dads.box. Suppose the networks are called N1 and N2. Devices belonging to N1(N2) want to refer to devices in N1(N2) with the same name they used before the connection. Consequently, A device of network N1(N2) has to refer to device of network N2(N1) with a name that is different from the name used by a device of network N2(N1). One may think of a suffixed name like MyTv.N1 to be used by devices of network N2. This suffixing must be done automatically without user assistance. van der Stok, Peter Expires: 21 May 2002 [Page 4] Internet Draft ZeroConf issues November 2001 Traditionally, a Domain Name System (DNS) [RFC 1034][RFC 1035] stores these names, associates a name with an IP address and returns an IP address for a given name. In the DNS protocol it is foreseen that - domain names are provided, possibly structured and associated with a zone, and that - a specified server is authoritative for a set of zones. The protocol foresees dynamic updates of the entries in the server by authorised sources [RFC 2136][RFC 3007]. A multicast DNS, mDNS [IDmDNS], is foreseen for small home networks to operate without a DNS server. No authoritative server, in the classical sense, is needed and domain names need not be approved by IANA. Below, this section discusses the issues associated with the management of the name server(s). A home network can be in two possible states: (1) stand alone with no connection to Internet, (2) connected to the Internet (directly or via one or more Internet providers). A connection to the Internet can be provided through a residential gateway via a cable network or via the telephone connected to an Internet provider. In state 2 a DHCP server is present. This DHCP server contains configuration information on (part of) the home network. The presence of a DHCP server or DNS server in state 1 depends very much on the business demands as perceived by the manufacturers. At this moment it is completely unclear whether these two servers will be provided by manufacturers of Consumer Electronics equipment. Consequently in state 1, there can be zero, one or more DNS and DHCP servers. A home network may pass from state 1 without DHCP server to state 2 with DHCP server (and vice-versa) because the user starts a connection with Internet from one of the connected appliances. A home network may also pass from state 1 with DHCP and DNS servers to state 2 with an external DHCP and DNS server (and vice-versa). There are a number of questions that need to be considered in the case of a stand alone home network without DHCP server. A boundary condition is that users should not be bothered to specify a server or the server contents. a) It is possible that there are multiple DNS servers. There is no mechanism to automatically decide on the authoritative DNS server. b) When an authoritative DNS server is switched off, the change-over to mDNS or another authoritative DNS server is not clear. c) mDNS gives no choice on keeping an old name at the expense of the new name or vice versa. d) How can mDNS automatically (or with minimum user interaction) provide different domain names within one home network composed of two (or more) temporarily connected home networks. van der Stok, Peter Expires: 21 May 2002 [Page 5] Internet Draft ZeroConf issues November 2001 When the network switches from stand-alone to connected, a number of other questions need to be addressed. Within the context of the SIP protocol [RFC 2543] there have been efforts to setup an addressing scheme from the Internet to the home network [IDSIP]. The following additional questions can be asked: e) Which of the named appliances are visible to the whole Internet? Not all need to be visible. f) Do the names of the DNS server mentioned in the DHCP server replace the existing ones or can they coexist with the names distributed with mDNS and what is their visibility? (For example: one name visible to Internet and another to the devices in the home network.) g) What happens if there are clashes between external names and local names? h) Can names distributed with mDNS, using global IP addresses, be entered in the external server? It is interesting to note that names are tightly coupled to devices in the minds of people. IP addresses get randomly attributed to devices and are very loosely coupled to individual devices. It is consequently interesting for mDNS to distribute names coupled to hardware addresses without IP address. This may provide a basis for device recognition and the distinction between resident and visiting devices. 5. Security considerations Especially with portable, wireless devices, security is of prime importance. A portable, wireless device (e.g. PDA) may become visible to multiple home networks. It is easy for any passing device to listen to a close wireless network unless special precautions are taken. This contrasts with the wired case where a person has to enter the house and physically connect his device before an application can be started. Therefore it is essential that the connection of the device to the network is protected and encryption takes place as low as the MAC level. Two levels of authorisation can be distinguished: 1) Authorisation to connect a device to a network (mechanically for wired, protected for wireless). 2) Authorisation to use resources on the network by an application or user. A few security aspects need further attention in the context of name servers. It is necessary to distinguish a stand alone network and a network connected to Internet. Consider the home network connected to Internet. Then all the traditional configured security aspects are needed for devices that are visible to the outside world. In [RFC 3007] already a few recommendations have been done. Assuming that some devices are invisible to the outside world but visible to each other makes it interesting to treat those devices differently from the ones that are van der Stok, Peter Expires: 21 May 2002 [Page 6] Internet Draft ZeroConf issues November 2001 visible. For those, the same security treatment should apply as for devices connected to a stand-alone network. Consider a stand-alone home network. A user should be able to (as for your DECT wireless telephone) use the security facilities provided by the network, but needs not if he thinks this is too cumbersome. Clearly, a user only enables security mechanisms that complicate his life when he feels that this effort is worthwhile. In the other case, he should not be bothered by such mechanisms. When many visiting devices are connected to and removed from the home network, the need will arise to spend effort on authorisation. Assigning this task to a trusted device or to a trusted person will be required. For example a trusted device may be asked whether a name proposed by mDNS is a resident name and whether the proposing host is a resident host. The possibility of connecting two or more stand-alone networks makes it probable that an authoritative server per network is needed and mDNS is no longer appropriate. It then needs to be decided which hosts are authoritative servers. One cannot assume that when a device is authorised to connect to the network that it is also authorised to be the authoritative DNS server. In standard DNS, a DNS server has authority over a set of domains. A domain can be associated with a home. Authority for a domain can be passed dynamically by an authorised person (trusted device?) to a server for a given domain when the need arises. The domain name does not need to be known to the users of the home network. In general, one can assume that a domain is allocated to a one or more links. In a stand-alone unconnected network, a default domain name is sufficient. When two networks are temporarily connected, the choice to create different domain names need to be presented. It is essential that a user has the possibility to point out (via browser) which devices together form a resident set. The resident set can also constitute a set of trusted devices to be contrasted with visiting devices. From such a resident set, name server entries may be modified, created or removed. A few questions arise from the above discussion: i) In case of mDNS, must one, two or all connected resident devices authorise a name server modification? j) In case of mDNS, can only one resident device or need at least two resident devices need to propose the name server modification? k) Can an authenticated person on any device propose a name server change? l) Under mDNS with security enabled, does a person always need to authenticate himself, even from a resident device? Four security levels have been discerned in this section: van der Stok, Peter Expires: 21 May 2002 [Page 7] Internet Draft ZeroConf issues November 2001 1) Connection to a wireless network can be authorised (MAC level). 2) Visiting devices are distinguished from resident devices (ZeroConf). 3) Visibility and associated name of a given device with respect other devices (ZeroConf). 4) Applications or users are authorised to use devices in a given role (Layers above) Resuming, the following security measures are proposed: - In the case of a stand-alone network, using mDNS, it should be possible for a device to show that it is resident and therefore takes precedence over visiting devices. - Such resident declarations may need to be authorised. - In the case of a connected network, all standard managed security mechanisms apply to all devices visible to Internet. - Depending on necessity, an authoritative DNS server can be required in a stand-alone network. The above cited facilities can be added to the present protocol in an ad-hoc manner. However, this will mean manufacturer dependent incompatible protocols if no directions on their use and implementation are described in RFCs. 6. Conclusions A number of network utilisation scenarios have been sketched. It is shown that the current DNS protocols do not address issues that may come up when these protocols are used within a home network. Security issues are far from solved. A few suggestions have been presented and accompanying questions are formulated. 7. References [IDZR] H. Hattig. "ZeroConf Requirements", Internet Draft, Work in progress, May 2001. [IDLL] S. Cheshire and B. Aboba. "Dynamic Configuration of IPv4 Link-Local Addresses", Internet Draft, Work in Progress, June 2001. [RFC 2131] R. Droms. "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC 1034] P. Mocapetris. "Domain names - Concepts and facilities", RFC 1034, November 1987. [RFC 1035] P. Mocapetris. "Domain names - Implementation and Specification", RFC 1035, November 1987. van der Stok, Peter Expires: 21 May 2002 [Page 8] Internet Draft ZeroConf issues November 2001 [IDmDNS] L. Esibov et al. "Multicast DNS", Internet Draft, Work in Progress, July 2001. [RFC 2136] P Vixie et al. "Dynamic Updates in the Domain Name Systems (DNS UPDATE)", RFC 2136, April 1997. [RFC 3007] B. Wellington. "Secure Domain name System (DNS) Dynamic Update", RFC 3007, November 2000. [RFC 2543] M. Handley and al. "SIP: Session Initiation protocol", RFC 2543, March 1999. [IDSIP] S. Myer et al. "SIP for Bulbs", Internet Draft, Work in progress, August 2000. 8. Author's Contact Information Peter van der Stok Philips Research Prof. Holstlaan 4 Bldg WDC 1-015 5656 AA Eindhoven The Netherlands Phone: +31 40 27.42649 Email: Peter.van.der.Stok@philips.com 8. Full Copyright Statement Copyright (C) The Internet Society (1999). 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 van der Stok, Peter Expires: 21 May 2002 [Page 9] Internet Draft ZeroConf issues November 2001 revoked by the Internet Society or its successors or assigns. 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." van der Stok, Peter Expires: 21 May 2002 [Page 10]