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]