Subject: ZEROCONF Minutes

From: Stuart Cheshire <[email-masked]>
Date: Mon, 21 Aug 2000 20:28:08 -0700

The following minutes have been submitted to [email-masked]:

------------------------------------------------------------

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 <[email-masked]>
 * Wizard Without Portfolio, Apple Computer