idnits 2.17.1 draft-vanderstok-zeroconf-issues-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 26 instances of too long lines in the document, the longest one being 16 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 184 has weird spacing: '...strated netwo...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (30 November 2001) is 8176 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2131' is mentioned on line 67, but not defined == Unused Reference: 'RFC 2131' is defined on line 398, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IDZR' -- Possible downref: Non-RFC (?) normative reference: ref. 'IDLL' -- Possible downref: Non-RFC (?) normative reference: ref. 'IDmDNS' ** Obsolete normative reference: RFC 2543 (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- Possible downref: Non-RFC (?) normative reference: ref. 'IDSIP' Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Egineering Task force Peter van der Stok 3 Internet DRAFT Philips Research 4 30 November 2001 5 Expires in 6 months 7 Issues for ZeroConf Working group 8 draft-vanderstok-zeroconf-issues-00.txt 10 Status of This Memo 12 This document is an individual contribution to the Internet 13 Engineering Task Force (IETF). Comments should be submitted to the 14 srvloc@srvloc.org mailing list. 16 Distribution of this memo is unlimited. 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Table of Contents 37 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 2 38 2. Network utilisation . . . . . . . . . . . . . . . . . . . . . . 2 39 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 40 4. Naming. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 41 5. Security considerations . . . . . . . . . . . . . . . . . . . . 6 42 6. Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . . 8 43 7. References. . . . . . . . . . . . . . . . . . . . . . . . . . . 8 44 8. Author's address. . . . . . . . . . . . . . . . . . . . . . . . 9 45 9. Full Copyright Statement. . . . . . . . . . . . . . . . . . . . 9 47 Abstract 49 This note considers some issues forthcoming from in-home networks 50 that use the ZeroConf protocols at the network layer. 52 1. Introduction 54 A home network is a good candidate for the utilisation of the 55 protocols that are developed by the ZeroConf working group. A home 56 network is interesting because these networks are used by non 57 professionals who may frequently reconfigure the network by just 58 switching on/off a device. This puts a rather stringent restriction 59 on the amount and kind of user administration that can be relied on: 60 practically none. 62 The ZeroConf requirements [IDZR] and the link-local protocol [IDLL] 63 are a good basis for the allocation of network addresses to the hosts 64 in a home network. Both documents consider networks where no 65 management by the user is needed. A home network can range from an 66 ad-hoc network of two hosts to a larger stand-alone network 67 comprising several bridged networks without DHCP server [RFC2131] to 68 a network connected to the Internet with administration by a DHCP 69 server. The DHCP server is possibly configured by the Internet 70 service provider without intervention by the owner or user of the 71 home network. The home network can be connected to more than one 72 Internet service provider with different DHCP contents. 74 The home network is considered one administrative unit. Its 75 boundaries may change dynamically in two ways: one, devices are 76 connected and disconnected (or just switched on and off) and two, the 77 network may connect devices in just one home or temporarily 78 interconnect more than one home. It can be much cheaper to 79 interconnect two home-networks via a private, possibly very cheap, 80 bridge than to start communication via a network provider who needs 81 to be paid. 83 This note considers the utilisation of a ZeroConf protocol in a home 84 network. A number of consumer electronic appliances are 85 interconnected, possibly also connected to one or more general 86 purpose computers. Two specific aspects of these networks that in my 87 opinion fall under the charter of the ZeroConf working group, are 88 discussed: (1) naming of appliances and (2) security, especially in 89 wireless networks. The note starts with an introduction into the 90 utilisation by a user of such a home network. 92 2. Network utilisation 94 A home network will serve the ICED purposes: 96 - Information: for example searching on the WEB. 97 - Communication: for example chatting. 98 - Entertainment: for example viewing an audio/video stream. 99 - Domotica: for example switching on the central heating. 101 Such a home network will need a connection to the outside world. 102 Audio/Video streams will be received from an entertainment 103 broadcaster, possibly via a cable operator. Connections will be made 104 to World Wibe Web to obtain information or to establish contact via 105 an Internet provider, possibly realised with a cable or via a 106 telephone wire (ADSL, ISDN). Connections are established between 107 devices within the home such as set top boxes, TV sets, DVD players, 108 WebCams, PCs, and many others. Some of these devices may be wireless, 109 portable and permanently connected to the home network like a ZapTop. 110 Some devices may be wireless, portable and connected to the home 111 network for only parts of the day like a PDA or the Notebook that is 112 also used in the office. A person can, with his PDA attached to the 113 network of his own home, visit the neighbour and connect to the 114 neighbour's home network to show the video he is currently watching. 116 The above shows that the network may be very dynamic and many 117 devices, authorized or not, may be connected to the home network, 118 either directly or via connections to Internet. Additionally, many 119 communication standards (e.g. IEEE 802.11, Ethernet, IEEE 1394, 120 HomeRF) and interoperability standards (like UPnP, HAVi or JINI) will 121 coexist in the network and need to collaborate. The Internet protocol 122 is probably the best candidate to provide network facilities over the 123 heterogeneous communication media in the home and to act as the 124 vehicle to connect the home to the outside world. In the following 125 sections the facilities provided by the presently proposed ZeroConf 126 protocols are compared with the projected utilisation by future users 127 of home networks. 129 3. Scenarios 131 Four scenarios are considered within the following context: two 132 neighbours have two networks with named devices. Some of these 133 devices are wireless. The scenarios do not represent recommended 134 behaviour but indicate possible behaviour to illustrate an issue. 135 These underlying issues are discussed in more detail in sections 4 136 and 5. 138 Scenario 1: 139 A friend of the children enters the home, takes his portable, 140 wireless device called myDevice and connects it to the network within 141 the home. He displays which devices are present and then establishes 142 the connections he wants. Some time later the owner of the house 143 enters with his portable, wireless device called myDevice and wants 144 to connect it to the home network without being bothered by the 145 friend's myDevice. Some time afterwards the friend notices that his 146 device is not connected any more, changes its name to friendDevice 147 and reconnects the device. 149 Scenario 2: 150 An occupant of the home drives in his car and connects his PDA via an 151 UTMS connection to Internet. He types in the domain name of his home 152 and displays the devices that are operational. The devices respond 153 with the names that were attributed locally suffixed by the current 154 domain name of his home. He switches on the heating and disconnects 155 from his home. 157 Scenario 3 158 Neighbour, A, installs a film that he promised his neighbour B on his 159 DVD player. His neighbour, B, does not have a DVD player and so A 160 visits B's home with his PDA connected to his own home. He connects 161 his PDA also to the network of B and displays the devices connected 162 to the network of B. Many of neigbour A's devices have the same name 163 as the devices of neighbour B. The devices of neigbour B are suffixed 164 with a domain name to the PDA of A. The devices of neighbour A remain 165 known to A's PDA with their original name. Neighbour A starts the 166 film on his DVD player and directs it to the TV of neighbour B. The 167 PDA acts as a bridge for the two networks of A and B. 169 Scenario 4 170 An occupant makes a connection to Internet via an Internet provider. 171 The names of his devices have a different name for the Internet 172 provider than for the occupant. The occupant is not aware of this 173 name change. When a family member connects from Internet to the home, 174 the family member also recognizes the same names that are used 175 locally. Other unauthorised people can from Internet only use the 176 names provided by the Internet provider. 178 4. Naming 180 Users of the network will like to name their appliances (e.g. MyTV or 181 tuner.in.the.bedroom) to address them by name for the execution of 182 commands or the exchange of Audio/Video (A/V) streams. The 183 possibilities created by portable, wireless devices have an impact on 184 the treatment of name clashes. In a fixed, administrated network the 185 addition of a new device with a name already attributed is simply 186 solved. However with portable, wireless devices in a Zero 187 Configuration network it is less clear whether the already present 188 device should keep its name or that the newly arriving device must 189 keep its name. The present device can be a device of a neighbour 190 while the newly arriving one is brought home by the network owner 191 returning from his work. There is a need to distinguish between 192 devices that belong to the network, "resident" devices, and visiting 193 devices. Another example in case is provided by scenario 3. Two home 194 networks are connected by a wireless device that acts as bridge 195 between two network parts. We cannot exclude that both networks hold 196 devices with names like MyTV or Dads.box. Suppose the networks are 197 called N1 and N2. Devices belonging to N1(N2) want to refer to 198 devices in N1(N2) with the same name they used before the connection. 199 Consequently, A device of network N1(N2) has to refer to device of 200 network N2(N1) with a name that is different from the name used by a 201 device of network N2(N1). One may think of a suffixed name like 202 MyTv.N1 to be used by devices of network N2. This suffixing must be 203 done automatically without user assistance. 205 Traditionally, a Domain Name System (DNS) [RFC 1034][RFC 1035] stores 206 these names, associates a name with an IP address and returns an IP 207 address for a given name. In the DNS protocol it is foreseen that 209 - domain names are provided, possibly structured and associated with a zone, and that 210 - a specified server is authoritative for a set of zones. 212 The protocol foresees dynamic updates of the entries in the server by 213 authorised sources [RFC 2136][RFC 3007]. 215 A multicast DNS, mDNS [IDmDNS], is foreseen for small home networks 216 to operate without a DNS server. No authoritative server, in the 217 classical sense, is needed and domain names need not be approved by 218 IANA. Below, this section discusses the issues associated with the 219 management of the name server(s). 221 A home network can be in two possible states: 222 (1) stand alone with no connection to Internet, 223 (2) connected to the Internet (directly or via one or more Internet providers). 225 A connection to the Internet can be provided through a residential 226 gateway via a cable network or via the telephone connected to an 227 Internet provider. In state 2 a DHCP server is present. This DHCP 228 server contains configuration information on (part of) the home 229 network. The presence of a DHCP server or DNS server in state 1 230 depends very much on the business demands as perceived by the 231 manufacturers. At this moment it is completely unclear whether these 232 two servers will be provided by manufacturers of Consumer Electronics 233 equipment. Consequently in state 1, there can be zero, one or more 234 DNS and DHCP servers. A home network may pass from state 1 without 235 DHCP server to state 2 with DHCP server (and vice-versa) because the 236 user starts a connection with Internet from one of the connected 237 appliances. A home network may also pass from state 1 with DHCP and 238 DNS servers to state 2 with an external DHCP and DNS server (and 239 vice-versa). 241 There are a number of questions that need to be considered in the 242 case of a stand alone home network without DHCP server. A boundary 243 condition is that users should not be bothered to specify a server or 244 the server contents. 246 a) It is possible that there are multiple DNS servers. There is no mechanism 247 to automatically decide on the authoritative DNS server. 248 b) When an authoritative DNS server is switched off, the change-over to mDNS or 249 another authoritative DNS server is not clear. 250 c) mDNS gives no choice on keeping an old name at the expense of the new name 251 or vice versa. 252 d) How can mDNS automatically (or with minimum user interaction) provide 253 different domain names within one home network composed of two (or more) 254 temporarily connected home networks. 256 When the network switches from stand-alone to connected, a number of 257 other questions need to be addressed. Within the context of the SIP 258 protocol [RFC 2543] there have been efforts to setup an addressing 259 scheme from the Internet to the home network [IDSIP]. The following 260 additional questions can be asked: 262 e) Which of the named appliances are visible to the whole Internet? Not all 263 need to be visible. 264 f) Do the names of the DNS server mentioned in the DHCP server replace 265 the existing ones or can they coexist with the names distributed with mDNS 266 and what is their visibility? (For example: one name visible to Internet and 267 another to the devices in the home network.) 268 g) What happens if there are clashes between external names and local names? 269 h) Can names distributed with mDNS, using global IP addresses, be entered in the 270 external server? 272 It is interesting to note that names are tightly coupled to devices 273 in the minds of people. IP addresses get randomly attributed to 274 devices and are very loosely coupled to individual devices. It is 275 consequently interesting for mDNS to distribute names coupled to 276 hardware addresses without IP address. This may provide a basis for 277 device recognition and the distinction between resident and visiting 278 devices. 280 5. Security considerations 282 Especially with portable, wireless devices, security is of prime 283 importance. A portable, wireless device (e.g. PDA) may become 284 visible to multiple home networks. It is easy for any passing device 285 to listen to a close wireless network unless special precautions are 286 taken. This contrasts with the wired case where a person has to enter 287 the house and physically connect his device before an application can 288 be started. Therefore it is essential that the connection of the 289 device to the network is protected and encryption takes place as low 290 as the MAC level. Two levels of authorisation can be distinguished: 292 1) Authorisation to connect a device to a network (mechanically for wired, 293 protected for wireless). 294 2) Authorisation to use resources on the network by an application or user. 296 A few security aspects need further attention in the context of name 297 servers. It is necessary to distinguish a stand alone network and a 298 network connected to Internet. 300 Consider the home network connected to Internet. Then all the 301 traditional configured security aspects are needed for devices that 302 are visible to the outside world. In [RFC 3007] already a few 303 recommendations have been done. Assuming that some devices are 304 invisible to the outside world but visible to each other makes it 305 interesting to treat those devices differently from the ones that are 306 visible. For those, the same security treatment should apply as for 307 devices connected to a stand-alone network. 309 Consider a stand-alone home network. A user should be able to (as for 310 your DECT wireless telephone) use the security facilities provided by 311 the network, but needs not if he thinks this is too cumbersome. 312 Clearly, a user only enables security mechanisms that complicate his 313 life when he feels that this effort is worthwhile. In the other case, 314 he should not be bothered by such mechanisms. 316 When many visiting devices are connected to and removed from the home 317 network, the need will arise to spend effort on authorisation. 318 Assigning this task to a trusted device or to a trusted person will 319 be required. For example a trusted device may be asked whether a name 320 proposed by mDNS is a resident name and whether the proposing host is 321 a resident host. 323 The possibility of connecting two or more stand-alone networks makes 324 it probable that an authoritative server per network is needed and 325 mDNS is no longer appropriate. It then needs to be decided which 326 hosts are authoritative servers. One cannot assume that when a 327 device is authorised to connect to the network that it is also 328 authorised to be the authoritative DNS server. In standard DNS, a DNS 329 server has authority over a set of domains. A domain can be 330 associated with a home. Authority for a domain can be passed 331 dynamically by an authorised person (trusted device?) to a server for 332 a given domain when the need arises. 334 The domain name does not need to be known to the users of the home 335 network. In general, one can assume that a domain is allocated to a 336 one or more links. In a stand-alone unconnected network, a default 337 domain name is sufficient. When two networks are temporarily 338 connected, the choice to create different domain names need to be 339 presented. 341 It is essential that a user has the possibility to point out (via 342 browser) which devices together form a resident set. The resident set 343 can also constitute a set of trusted devices to be contrasted with 344 visiting devices. From such a resident set, name server entries may 345 be modified, created or removed. 347 A few questions arise from the above discussion: 348 i) In case of mDNS, must one, two or all connected resident devices authorise 349 a name server modification? 350 j) In case of mDNS, can only one resident device or need at least two resident 351 devices need to propose the name server modification? 352 k) Can an authenticated person on any device propose a name server change? 353 l) Under mDNS with security enabled, does a person always need to authenticate 354 himself, even from a resident device? 356 Four security levels have been discerned in this section: 358 1) Connection to a wireless network can be authorised (MAC level). 359 2) Visiting devices are distinguished from resident devices (ZeroConf). 360 3) Visibility and associated name of a given device with respect other devices 361 (ZeroConf). 362 4) Applications or users are authorised to use devices in a given role 363 (Layers above) 365 Resuming, the following security measures are proposed: 367 - In the case of a stand-alone network, using mDNS, it should be possible 368 for a device to show that it is resident and therefore takes precedence 369 over visiting devices. 370 - Such resident declarations may need to be authorised. 371 - In the case of a connected network, all standard managed security mechanisms 372 apply to all devices visible to Internet. 373 - Depending on necessity, an authoritative DNS server can be required in a 374 stand-alone network. 376 The above cited facilities can be added to the present protocol in an 377 ad-hoc manner. However, this will mean manufacturer dependent 378 incompatible protocols if no directions on their use and 379 implementation are described in RFCs. 381 6. Conclusions 383 A number of network utilisation scenarios have been sketched. It is 384 shown that the current DNS protocols do not address issues that may 385 come up when these protocols are used within a home network. Security 386 issues are far from solved. A few suggestions have been presented and 387 accompanying questions are formulated. 389 7. References 391 [IDZR] H. Hattig. "ZeroConf Requirements", Internet Draft, Work 392 in progress, May 2001. 394 [IDLL] S. Cheshire and B. Aboba. "Dynamic Configuration of IPv4 395 Link-Local Addresses", Internet Draft, Work in Progress, 396 June 2001. 398 [RFC 2131] R. Droms. "Dynamic Host Configuration Protocol", RFC 2131, 399 March 1997. 401 [RFC 1034] P. Mocapetris. "Domain names - Concepts and facilities", 402 RFC 1034, November 1987. 404 [RFC 1035] P. Mocapetris. "Domain names - Implementation and 405 Specification", RFC 1035, November 1987. 407 [IDmDNS] L. Esibov et al. "Multicast DNS", Internet Draft, Work in 408 Progress, July 2001. 410 [RFC 2136] P Vixie et al. "Dynamic Updates in the Domain Name Systems 411 (DNS UPDATE)", RFC 2136, April 1997. 413 [RFC 3007] B. Wellington. "Secure Domain name System (DNS) Dynamic 414 Update", RFC 3007, November 2000. 416 [RFC 2543] M. Handley and al. "SIP: Session Initiation protocol", RFC 417 2543, March 1999. 419 [IDSIP] S. Myer et al. "SIP for Bulbs", Internet Draft, Work in 420 progress, August 2000. 422 8. Author's Contact Information 424 Peter van der Stok 425 Philips Research 426 Prof. Holstlaan 4 427 Bldg WDC 1-015 428 5656 AA Eindhoven 429 The Netherlands 431 Phone: +31 40 27.42649 433 Email: Peter.van.der.Stok@philips.com 435 8. Full Copyright Statement 437 Copyright (C) The Internet Society (1999). All Rights Reserved. 439 This document and translations of it may be copied and furnished to 440 others, and derivative works that comment on or otherwise explain it 441 or assist in its implementation may be prepared, copied, published 442 and distributed, in whole or in part, without restriction of any 443 kind, provided that the above copyright notice and this paragraph 444 are included on all such copies and derivative works. However, 445 this document itself may not be modified in any way, such as by 446 removing the copyright notice or references to the Internet Society 447 or other Internet organizations, except as needed for the purpose 448 of developing Internet standards in which case the procedures 449 for copyrights defined in the Internet Standards process must be 450 followed, or as required to translate it into languages other than 451 English. 453 The limited permissions granted above are perpetual and will not be 454 revoked by the Internet Society or its successors or assigns. 456 This document and the information contained herein is provided on an 457 "AS IS" basis and THE Internet SOCIETY AND THE Internet ENGINEERING 458 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 459 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 460 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 461 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."