"The goal of the Zero Configuration Networking (Zeroconf) is to enable networking in the absence of configuration and administration. Zero configuration networking is required for environments where administration is impractical or impossible, such as in the home or small office, embedded systems 'plugged together' as in an automobile, or to allow impromptu networks as between the devices of strangers on a train.Essentially, to reduce network configuration to zero (or near zero) in Internet Protocol (IP) networks, it is necessary, inter alia, to:
|
Distribute IP addresses (without a Dynamic Host Configuration Protocol [DHCP] server), |
|
Provide name resolution (without a Domain Name System [DNS] server), |
|
Find and list services (without a directory service), and |
|
Distribute multicast IP addresses, if necessary (without a multicast server). |
|
Medium or large networks |
|
Networks where a high degree of security and control is required |
|
Large public access networks |
|
Networks with low bandwidth and high latency (such as some wireless networks) |
|
Home and small office networks |
|
Ad hoc networks at meetings and conferences (especially wireless networks) |
|
Two devices needing to spontaneously share or exchange information |
"Zeroconf protocols are intended to operate in a local scope, in networks containing one or more IP subnets, and potentially in parallel with standard configured network protocols. Application protocols running on networks employing zeroconf protocols will be subject to the same sets of security issues identified for standard configured networks. Examples are: denial of service due to the unauthenticated nature of IPv4 ARP and lack of confidentiality unless IPSec-ESP, TLS, or similar is used. However, networks employing zeroconf protocols do have different security characteristics, and the subsequent sections attempt to draw out some of the implications.Although this document does not address each and every aspect of security issues with Zeroconf, it sets requirements for Zeroconf protocols. As is the case with traditional IPv4 and IPv6, use of such techniques as IP Security Architecture (IPSec) or Transport Layer Security (TLS) may be appropriate in some cases. However, the nonstatic (or one may say nondurable) nature of both IP addresses and names in Zeroconf environment may pose a problem for IPSec and TLS deployment.
Security schemes usually rely on some sort of configuration. Security mechanisms for zeroconf network protocols should be designed in keeping with the spirit of zeroconf, thus making it easy for the user to exchange keys, set policy, etc. It is preferable that a single security mechanism be employed that will allow simple configuration of all the various security parameters that may be required. Generally speaking, security mechanisms in IETF protocols are mandatory to implement. A particular implementation might permit a network administrator to turn off a particular security mechanism operationally. However, implementations should be "secure out of the box" and have a safe default configuration.
Zeroconf protocols MUST NOT be any less secure than related current IETF-Standard protocols. This consideration overrides the goal of allowing systems to obtain configuration automatically. Security threats to be considered iclude both active attacks (e.g. denial of service) and passive attacks (e.g. eavesdropping). Protocols that require confidentiality and/or integrity should include integrated confidentiality and/or integrity mechanisms or should specify the use of existing standards-track security mechanisms (e.g. TLS (RFC 2246), ESP (RFC 1827), AH (RFC 2402) appropriate to the threat."
"The ARP protocol [RFC 826] is insecure. A malicious host may send fraudulent ARP packets on the network, interfering with the correct operation of other hosts. For example, it is easy for a host to answer all ARP requests with responses giving its own hardware address, thereby claiming ownership of every address on the network.Although some may argue about the question of whether or not it is effective, appropriate, and useful to "inform the human user" in this case, this solution nevertheless follows the principle of at least not worsening the current security situation of an existing protocol.
This specification makes this existing ARP vulnerability no worse, and in some ways makes it better: Instead of failing silently with no indication why, hosts implementing this specification are required to either attempt to reconfigure automatically, or if not that, at least inform the human user of what is happening."
"Service discovery requires a central aggregation server. DNS already has one: It's called a DNS server.It is necessary to note that DNS-SD is compatible with mDNS and vice versa, but neither requires the other one to function. However, it is practical to use mDNS for service discovery (using DNS-SD) to have a single protocol and interface and not have to implement another protocol just for service discovery.
Service discovery requires a service registration protocol. DNS already has one: It's called DNS Dynamic Update.
Service discovery requires a security model. DNS already has one: It's called DNSSEC.
Service discovery requires a query protocol. DNS already has one: It's called DNS."
"It is important to understand that the purpose of Zeroconf is not solely to make current personal computer networking easier to use, though this is certainly a useful benefit. The long-term goal of Zeroconf is to enable the creation of entirely new kinds of networked products, products that today would simply not be commercially viable because of the inconvenience and support costs involved in setting up, configuring, and maintaining a network to allow them to operate."References