Minutes for ZEROCONF Meeting 1:00pm - 2:00pm, Tuesday, 1st August 2000 48th IETF Meeting, Pittsburgh, Pennsylvania, 30th July - 4th August 2000 Thanks to Steve Hanna for taking notes for these minutes. Agenda: Charter Discussion (30 minutes) Requirements Document Discussion (30 minutes) ------------------------------------------------------------ Charter Discussion ------------------ We have almost completed the primary item of our existing charter (developing a requirements document). This document identifies areas where new work is needed. Should we expand the Zeroconf charter to include the portions of this new work that are not already covered by other working groups? Erik Guttman listed the needed protocols, noting which ones are being addressed elsewhere and which are not: * Service Discovery SLPv2 & DNS SRV are both Proposed Standards. No need for new service discovery protocols. Any comments? Bill Woodcock and one other called out in agreement. * Interface Configuration IPv6 stateless addrconf is already a Draft Standard from IPNGWG. No new protocol work is needed here. IPv4 linklocal address assignment has two drafts but no WG. The DHC working group has stated that it has no interest in pursuing work on this. Should IPv4 linklocal address assignment become an official work item of Zeroconf? Side discussion: IPv4 linklocal address assignment bears on the question of transitions vs. peaceful coexistence. The current charter of Zeroconf assumes that Zeroconf protocols are harmful to large configured networks, and must automatically shut down on such networks. However, the true requirement that the charter should have stated is that Zeroconf protocols must do no harm on large configured networks. Whether that requires them to shut down depends on whether they cause harm to large configured networks if they do not. Given that no transition can be instantaneous, there will always be some period of coexistence, so it is desirable that Zeroconf protocols should not cause harm to large networks in this case. Consequently, if Zeroconf protocols can be created that do not cause harm to large networks, then there is no reason to require them to automatically shut down on such networks. Comment from the floor: Didn't we agree in Adelaide that there was broad consensus that IPv4 LL should coexist with configured addresses? Why are we still discussing this? Erik Guttman then asked anyone who disagreed to come to a microphone to present an opposing argument, and when no one was forthcoming, declared rough consensus on the issue of peaceful coexistence. Question from the floor: Should we update Host Requirements? Erik Guttman: Host Requirements was not written prescriptively, in advance; it was written descriptively, after we had gained considerable experience. We cannot even consider updating Host Requirements until after we have gained a similar level of operational experience with Zeroconf protocols. Return to original question: Should IPv4 linklocal address assignment become an official work item of Zeroconf? No one spoke out to oppose this. Comment from the floor: IPv4 LL draft should be a standard-track document, not Informational. No one spoke out to oppose this. * Name Resolution This is being considered outside Zeroconf, by IPv6 (hostinfo request/reply proposal) and DNSEXT (mDNS proposal). * Multicast Address Allocation Erik Guttman: Address Allocation Protocol, designed in MALLOC WG, is designed for large configured networks. However, it might be feasible to Zeroconf to write a profile document defining how AAP is used in Zeroconf networks. Dave Thaler has published a draft on these lines (draft-thaler-zeroconf-multicast-01.txt). Comment from the floor: AAP is a peer-to-peer protocol anyway. Erik Guttman: AAP does all we need and more. We just need to identify the "more" and remove it. * Security Assertion from Erik Guttman: All Zeroconf security requirements can be met by stating that a host needs to be able to determine whether packets it receives are from a trusted peer. All we need to do is say that there should be a way for packets to be authenticated. This protects claim-and-defend protocols against DOS attacks. This protects against rogue hosts masquerading as infrastructure services like DHCP servers. We've already agreed that securing ARP is out-of-scope. DNS, DHCP and SLP already have application-level authentication methods. Is that sufficient? Zeroconf does not claim to address confidentiality of user data transmitted over the wire. With configured or zeroconf networking, ensuring appropriate confidentiality protection remains the responsibility of higher-layer protocols. Open question is how to make all this application-level authentication easy to do. Perhaps we could consider a future "Securing the LAN" document explaining how to make security set-up easy without requiring 'sneakernet', but we should clearly and simply state that this work is NOT in the Zeroconf charter. Question from the floor: Will you identify another working group that should have responsibility for security? Erik Guttman: I have identified elements of it, namely, SLP security is the responsibility of the SLP WG. DNS security is the responsibility of the DNS WG. DHCP security is the responsibility of the DHCP WG. What I am proposing here is that we find those people who are interested, and take them off to consult with the security directorate and security advisors, and possibly charter a new working group, but we should explicitly state that we are not going to do that work here. Question from the floor. Isn't this the same as the work of the AAA working group? General Consensus: No. Dave Thaler: Requirements document should not solve the security problems, but should state security requirements that need to be addressed in any proposed protocol. Erik Guttman: Agreed. The requirement for Zeroconf networking is not that it solve all security problems. The requirement for Zeroconf networking is that it not make networking less secure than configured networks are today. Discussion from the floor: If light switches and light bulbs and other appliances start using networking, then their security requirements are the same regardless of whether they are using configured networking or zeroconf networking. Erik presented a new list of charter goals: 9/00 Submit requirements draft for Informational 12/00 Submit IPv4 Host Autoconfiguration draft for Proposed Standard 12/00 Submit Zeroconf AAP Profile draft for Proposed Standard 3/01 Submit Zeroconf Protocol Profile draft for Informational The Zeroconf Protocol Profile would list protocols needed for a zero configuration network, pointing at protocol specifications. Since this document would depend on all the protocol specs (including several that are in other working groups), it might have to wait at the IESG for those documents. Question from the floor: Will the profile have to wait for the "Securing the LAN" document? Answer: No. The requirement for Zeroconf networking is that it not make networking less secure than configured networks are today. The "Securing the LAN" document is a step beyond that. Dave Thaler says authors of zeroconf protocol drafts need guidelines for writing their Security Considerations sections. Erik says that will go in the Requirements draft. Stuart Cheshire: In addition, some parts of the charter need some minor rewording. For example, host configuration should be called interface configuration, since "host configuration" is already overloaded with other meanings, such as configuring the address of a DNS server, which may not apply in the Zeroconf case. These minor changes will be discussed on the mailing list. The group generally agreed to the list of work items above. ------------------------------------------------------------ Review of Draft 04 ------------------ Erik listed several open issues pertaining to the requirements document: * "MUST Transition" requirement Erik Guttman: Current draft says "MUST transition to configured operation in the presence of a DHCP server" when a DHCP server is detected. An alternative, which we've heard support for here, is to allow peaceful coexistence, where a host maintains its self-configured link-local address, and any active TCP connections using it, in addition to obtaining an additional address from the DHCP server. Note that if we allow two IPv4 addresses like this, then we've created a scoped address architecture like IPv6. Bill Woodcock: Lets decide this now. Erik Guttman asked for people to hum in support of "MAY retain zeroconfigured operation", and then in support of "MUST transition". Broad support for being able to retain zeroconfigured operation; one person (Bill Manning) supported "MUST transition". Unfortunately, some people were not clear about what was meant by "MAY retain" and "MUST transition": Comment from the floor: When a small network becomes connected to a larger network, do we allow a hybrid state? Stuart Cheshire: The agreement we thought we just reached is that devices should be allowed to implement the hybrid state. We're not mandating that devices MUST support a hybrid state and we're not mandating that devices MUST NOT support a hybrid state. We're saying that implementers are free to implement the hybrid state if they want to. Comment from the floor: I supported "ability to retain zeroconfigured operation" because I thought it meant that devices must stay in zeroconf mode and MUST NOT support a hybrid state where they also get an address from the DHCP server as well. Erik Guttman: So, based on what was just said, you would have hummed into the silence then? Answer: Yes. Thomas Narten: The question is whether zeroconf and non-zeroconf protocols can exist in the same network. Erik Guttman: The current spec says you MUST detect the presence of a DHCP server, and you MUST transition, and you have no choice. This allowed us to simplify a lot of issues by saying that a host is either zeroconf, or not zeroconf, and never both. However, many strong arguments have been made showing that this simple model is inadequate. Bill Simpson: There are many useful potential applications of IP, such as home automation systems, and I don't want us to say that you're not allowed to make an IP-speaking light bulbs unless it also includes a DHCP client. Comment from the floor: Saying that zeroconf protocols MUST NOT coexist with configured protocols simplifies the protocols. Erik Guttman: It's not that simple. When a DHCP server comes up, there is necessarily some period of time before a zeroconf host detects the DHCP server, so there is always some period of overlap, so the protocols will have to accommodate that case anyway. Even if we require a transition, we still have to consider the times when the transition has not fully occurred. All we're doing by saying "may coexist" is that we're taking off the duration requirement on the transition, and allowing that period of overlap to last indefinitely. It just has to be safe. Bill Woodcock: Remember that Zeroconf devices can't use lack of transition as a substitute for security. Even for a device that doesn't transition to configured operation, designers need to be aware that other hosts on the same network may transition and may be accessible to hosts outside the local network. Bill Manning: Saying that devices MUST transition to configured operation is a smaller set of work. Comment from the floor: This WG shouldn't be working on IPv4 problems at all when IPv6 has already solved all these problems. Stuart Cheshire: The primary work of this WG is not IPv4 address assignment. The primary work of this WG is to come to agreement on the requirements for zeroconf networking. The question in front of us right now is whether our requirements document should state that you MUST give up auto-configured operation when configuration information comes into existence on the network. In the context of IPv6 that's saying that you're not allowed to use IPv6 link-local addresses if you're seeing IPv6 router advertisements on the network. The question in front of us right now is whether we think that is a sensible requirement. Erik Guttman again asked for people to hum in support of allowing hosts to continue using zeroconf protocols even in the presence of configured alternatives, or not. Again, the outcome was strongly on the side of allowing hosts to choose. Erik declared rough consensus on this point and asked anyone who still disagreed to present arguments on the mailing list. * "Periodic actions" Requirement Erik Guttman: Several sections of draft-04 include text that says zeroconf protocols MUST require hosts to perform periodic actions. The reason why it states that, is that we have a requirement in many cases to detect state changes, and it so happens that some of the mechanisms that exist today use periodic messages to achieve that state change detection in a timely way. It turns out that what we really want to do is to detect those state changes in a timely way. We have no desire to send out periodic messages for their own sake. Unnecessary periodic messages have been the death of many protocols and they are certainly not a requirement, or even a desirable feature, of a protocol. * Host Name Resolution Erik Guttman: Right now in the document we talk about Domain Name Resolution. We propose that we change this to Host Name Resolution. One reason for this is that the IPv6 hostinfo protocol requests names that are the names of hosts, but not necessarily Domain Names in the Domain Name System. Can we simplify the requirements document by talking about Host Names instead of Domain Names? Stuart Cheshire: The requirements document should focus on the requirements, not the artefacts of the implementation, and the requirement is for users to be able to access hosts by name. Twenty years ago, this was achieved by having a big "/etc/hosts" file. When that became unmanageable the Domain Name System took over, but that's just one way of implementing name resolution. The requirement we want for zeroconf is looking up host names. Because we made the mistake of assuming that we necessarily achieve this using DNS, the current requirements draft is cluttered up with language about domains and subdomains and delegation, which are implementation details of a particular name system, not zeroconf requirements in their own right. The right solution for zeroconf networking may very well turn out to be some variant of DNS running over IP multicast, but the requirements document should not mandate that. The requirement is the ability to access hosts by name. * Interface Configuration Erik Guttman: There is text in the current requirements document that describes the use of netmasks and default routers as pieces of required host configuration. There is a suggestion that the real requirement being expressed is routing table configuration, and describing it as such would be a more general and more correct way of describing how IP hosts actually operate. Also, a default route is *not* required for a zeroconf host to communicate with a peer zeroconf host. * Configuration Servers (DHCP) Erik Guttman: If you deploy a configuration server on your network, and that configuration server then goes and adds configuration to your hosts, then you're no longer in zeroconf any more. If I turn on a DHCP server, then the hosts that use configuration information from that DHCP server are configured. They're not using a zero configuration protocol. Now it could be that that DHCP server is itself automatically configured, but that's a totally different thing. Right now the requirements document is ambiguous about this. At one point it even states that DHCP may be a zero configuration protocol. Erik asked for comments. No disagreements were voiced. * Security Erik Guttman: Proposal for discussion on the mailing list: Zeroconf security requirements can all be met by the single requirement that hosts should be able to verify that messages they receive are from trusted peers. * Final closing comment from the floor: The requirements document should indicate what the assumptions are for zero configuration networking. Is a MAC address required, for example? Erik agreed that this was a good point. ------------------------------------------------------------ // Stuart Cheshire \\ \\ Wizard Without Portfolio, Apple Computer //