Subject: Re: WG LAST CALL: draft-ietf-zeroconf-reqts-05.txt

From: Stuart Cheshire <[email-masked]>
Date: Thu, 05 Oct 2000 04:33:47 -0700

on 25/9/00 12:33 am, Erik Guttman wrote:

> This is a notice of a Working Group Last Call on the document
> 
> http://www.ietf.org/internet-drafts/draft-ietf-zeroconf-reqts-05.txt
> 
> Please send your comments in the next two weeks.  At that time
> (October 9) we will evaluate the working group consensus on the
> document, if necessary revise the document, then submit it to the
> IESG for publication as an Informational RFC.

I like draft-05 a lot, and I think we are very close to being finished. Here
are my comments. There are a fair number, but they are all fairly easy to
fix:

Throughout the document we talk about one of our four areas being "host
configuration".

We should be specific and say what we mean: "IP interface configuration."
Our WG charter has been updated to say interface configuration, and I think
the document should say the same. The "IP Host Configuration" section (2.1)
even begins by saying, "In this document, configuration of an IP interface
on a host is IP host configuration." If we even have to explain that when we
say "host configuration" we mean "configuration of an IP interface", lets
just say what we mean. We should replace all appearances of "host
configuration" with "interface configuration".

Page 3:

The Scalability section has gone through much mutation, and gets better
every time. I have one more refinement. Right now it says:

   As a network grows, the administrators of that network should
   consider migrating away from zeroconf protocols before
   scalability becomes an issue. That being said, a zeroconf
   protocol SHOULD be scalable.

I would suggest the text below. We are not saying that administrators should
consider migrating away from zeroconf protocols because we tell them to. We
are saying that administrators will *want* to migrate away from zeroconf
protocols because configured protocols may serve their needs better in
large-scale networks.

   As a network grows, the administrators of that network will
   eventually want to take an active role in making local policy
   decisions to manage the network's resources. At this point,
   conventional configured protocols may be more appropriate
   than their zeroconf counterparts. Zeroconf protocols SHOULD
   be scalable as far as is reasonable, but they do not need to
   attempt to compete with or replace existing configured
   protocols that already work well in large-scale networks.

Page 4:

   Spurious topology changes or other events such adding ...

Delete the work "Spurious". "Spurious" means "Lacking authenticity or
validity in essence or origin; not genuine; false." I don't think we mean
that. I suggest the following replacement text:

   Topology changes or other events such adding and removing
   hosts may cause state changes and conflicts within a
   protocol. Zeroconf protocols in all four areas must be able
   to respond to state changes and resolve conflicts caused by
   topology changes or other events.
    
   Requirement: 
   - MUST respond to state changes and resolve conflicts in a
   timely manner.

I found the following text confusing:

   This section lists scenarios that lead to zeroconf protocol
   requirements. A subsection exists for each of the four protocol
   areas.

I thought it was saying that this section presents a list of scenarios, and
for each scenario there are subsections covering the four protocol areas.
That is not what it is trying to say. I suggest the following replacement
text:

   This section contains a subsection for each of the four
   protocol areas. Within each subsection, terms and assumptions
   are followed by specific representative scenarios that lead
   to zeroconf protocol requirements in that area. Each
   subsection ends with an IPv6 considerations section.

In section 2.1:

   Terms: 
     IP subnet - A single logical IP network that may span multiple
     link layer networks.

I suggest the following addition:

   Terms: 
     IP subnet - A single logical IP network that may span multiple
     link layer networks. All IP hosts on a subnet are directly
     reachable from all other hosts on that subnet using layer 2
     (e.g. Ethernet) packets, without needing to communicate
     via any layer 3 forwarding device (e.g. an IP router).

Page 5:

   IP host configuration scenarios are ICMP echo request/reply

Can we think of a more compelling example than ping? When 'ping' is the best
example we can think of, it begs the question of why we're even bothering
with this work. If we use the example of establishing a TCP connection
between two machines, then I think it is obvious to everyone why this is a
useful thing to achieve. Alternatively, the example of just "sending an IP
packet between two machines" is clearly useful and real, because every other
useful IP application is layered on top of that basic functionality. Very
little (except troubleshooting broken networks) is layered on top of 'ping'.

   it may include a
   default route

   - MUST have a default route (only for the internet scenario).

   conflict among default routes

We still have this notion that every host "MUST have a default route".
A default route implies that *every* IP address is reachable by you, and if
you don't know how to reach a given destination directly, then the gateway
in your default route entry knows how to reach it for you. This is simply
not true in an isolated (inter)network. We can either remain silent on the
subject of default routes, or we can say that hosts on an isolated network
MUST NOT have them, but saying that hosts on an isolated network MUST
pretend that the entire Internet is reachable when it is not, is just wrong.

In case anyone thinks that an IP host can't use a gateway unless it has a
default route, that is not true. For example, consider two networks 10.1/16
and 10.2/16, connected by router R, with addresses 10.1.0.1 and 10.2.0.1.
Host A on network 10.1/16 has the following routing table entries:

[cheshire@rose cheshire]$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref   Use Iface
10.1.0.0        *               255.255.0.0     U     0      0        0 eth0
10.2.0.0        10.1.0.1        255.255.0.0     UG    0      0        0 eth0

See? No default route. This simply says that 10.1/16 hosts are reachable on
eth0, and 10.2/16 hosts are reachable via 10.1.0.1 on eth0, and all other
destinations should return an immediate "NET UNREACHABLE" (which is correct,
because all other nets *are* unreachable). Adding a default route to this
list would be claiming that we believe that *all* other addresses are
reachable via that route. I don't see why we would require a host to put
false information into its routing table.

The Windows user interface may have given end-users the idea that a default
route is somehow fundamental, but it's not.

Our document should be defining accurate requirements, not perpetuating
misunderstandings, even if they are widely-held misunderstandings.

   thus if a network is using IPv6, a
   zeroconf IP host configuration solution already exists.

I would say, "If a host is using IPv6..." It's not my Ethernet that uses v6,
it's my computers.

     host name - One or more strings separated by dots that identify
     a host. 

The "strings separated by dots" is a DNS concept. A "host name" is just "the
name of a host". We don't even have to specify the allowed character set in
this document, except that it be compatible with current host application
software that allows users to enter host names. I suggest the following
replacement text:

     host name - The textual name used to identify a host

Page 6:

     domain name - One or more strings separated by dots that
     identify a DNS domain.

This seems like an appropriate place to reference RFCs for a precise
definition. I suggest the following replacement text:

     domain name - Zero or more textual labels, separated by dots,
     that identify a DNS domain [RFC 1034] [RFC 1035].

Also on page 6:

   Assumptions: 
   - Support for multiple hosts with the same name is not a
     requirement. 

I don't think this document needs to specify non-requirements. If supporting
a host name that resolves to more than one IP address is useful, and
practical to implement, then I don't think this document should hint,
however obliquely, that this is somehow not worthwhile. Lets delete this
text.

More on page 6:

   Users browsing the Web typically enter the name of a Web server.

I think the more accurate statement is that users generally enter a URL.
A URL usually contains the host name of the Web server as part of the URL,
along with the name of the object being referenced and possibly other
information.

   The Web server may be within the same domain
   along with the resolver or may be part of some other domain.

We can delete this. The DNS is a hierarchical system of names, not a
hierarchical system of computers. A client computer is not "in" a domain,
and nor is the server. The server's DNS *name* has a place within the DNS
hierarchy, but a single server can easily have multiple names that are at
completely different unrelated places in the DNS hierarchy, and the client
needn't have a name at all. Even if the client does have a name (or fifty)
that is still not relevant. The DNS request sent out from the client does
not involve the client's name(s) anywhere; nor does opening a TCP connection
to the server and sending an HTTP "GET" request.

I suggest the following replacement text:

   URLs typically contain the name of the server host. When a
   user enters a URL into a Web browser, the name must be
   resolved to an IP address."

Also:

   Requirement: 
   - MUST resolve a host name to an IP address whether the name of
     the resolver and host name are in the same DNS domain or in
     different DNS domains.

I suggest the following replacement text:

   Requirement: 
   - MUST resolve a host name to an IP address.

More on page 6:

   This scenario only deals with
   learning of other host names on the network.

To me, "learning of other host names on the network," sounds like it is
talking about a browser that shows you a list (e.g. the Macintosh Chooser,
or any other service discovery protocol). I don't think we're talking about
browsing here.

   Thus allowing the user or configuration
   protocol to attempt to use a different and hopefully unique name

I don't think we need to say "hopefully unique". We don't have to hope that
it is unique if we have a mechanism to verify whether it is unique. I
suggest the following replacement text:

   How the host gets its name (or Domain Name [RFC 1034]) is
   part of some other configuration protocol or user
   configuration, but is not part of this zeroconf scenario. The
   requirement here is that in cases where uniqueness of names
   is desired, a host should be able to verify whether a name is
   already in use. In the case where the name is already in use,
   the host should request that the user (or the software
   performing the configuration) select a different host name,
   and then repeat the process of verifying its uniqueness. This
   process repeats as often as necessary until an acceptable name
   is found.

Also replace the following text:

   - MUST allow a host to determine if it has a unique name.
   - MUST be able to determine if subsequently chosen names are
     unique, if the first name is not.

with:

   - MUST allow a host to determine if a name is in use by
   another host, so that in cases where it is desired to have
   unique names, the host may select a new name (and repeat
   the process until an acceptable name is found)

It is redundant to also say that you also have to be able to do the same for
subsequent names, as it would be to say that you also have to be able to do
it for the third name as well (and on Tuesdays, and if it is raining... :-)

   - If a domain name and host name exist as separate configuration
     parameters, additional checks for uniqueness SHOULD be
     performed on the combined host name and domain name.

We can delete this. This is notion that your "host name" is only the first
label of the DNS name and the rest of the labels are your "domain name"
sounds like another piece of Windows UI trivia, which is not pertinent to
protocol design.

"rose.bolo.net." is a domain name. (It's a small domain with only one
record, an A record).
"bolo.net." is a domain name. (It is a larger domain.)
"net." is a domain name.
"." is a domain name.

My host name is "rose.bolo.net.":

[cheshire@rose cheshire]$ hostname
rose.bolo.net

It happens to be a name that exists in the hierarchy of the Domain Name
System, hence it is a "domain" name as well as a host name.

If someone made a UI with a series of boxes separated by dots, where you
enter your DNS name by typing one label into each box, then it would be that
person's problem to interpret that data correctly. We don't have to talk
about that.

Also, this is DNS-centric information, and this requirements document does
not require that we use DNS for host names. Even though implementers may
well chose to adopt something like multicast DNS, that is not a requirement.

Page 7:

   IP Multicast is used for multi-receiver bulk-delivery
   applications, such as audio, video, or news to conserver
   bandwidth.  

This should say, "conserve bandwidth." It also misses the logical addressing
function of IP Multicast. I suggest the following replacement text:

   IP Multicast is used to conserve bandwidth in multi-receiver
   bulk-delivery applications, such as audio, video, or news.
   IP Multicast is also used to perform a logical addressing
   function. For example, when a host needs to communicate with
   local routers, it can send packets to the all-routers
   multicast address without having to know in advance the
   IP address(es) of the router(s) .

Also on page 7:

   [RFC 2365] defined scopes are:
     node-local (unspecified)
     ...

This seems a little incongruous to me. I suggest the following replacement
text:

   Multicast scopes (some of which are defined in [RFC 2365]) are:
     node-local (unspecified)
     ...

Also on page 7:

   Source-Specific Multicast [SSM] addresses are 232.0.0.0 to
   232.255.255.255.
    
Do we want to reference an unpublished ID in an RFC submission?

Also on page 7:

   Assumptions: 
   - A boundary router, as described in [RFC 2365], is present ...

Really? Zeroconf *assumes* that there is network infrastructure? I suggest
the following replacement text:

   - If the user chooses to install any router on the network,
   then that user is responsible for deciding whether it needs
   to be configured as a boundary router, as described in [RFC
   2365]."

Page 8:

   IP multicast address allocation (only local, link-local and site-
   local scopes only) requires coordination among hosts

Delete one "only".

Also on page 8:

   To allocate an address, the host specifies a
   given scope, the number of addresses it desires, and the lifetime
   for which it desires.

   Requirements: 
   - MUST select a multicast address with a given scope and lease
     time. 
   - MUST defend an allocated address within a scope.

These should be deleted. We're specifying mechanism here, and we should not.
The requirement is that a host, or group of hosts using a multicast-based
protocol, should be able to obtain a multicast address which is available
for them to use, and (except for forced reconfigurations due to network
topological changes) that address should remain available for them to use
for as long as any participant in that group (sender or receiver) needs to
use it. Furthermore, the participants of that group may change over time,
including the case where none of the original participants remain, without
losing the address.

Also on page 8:

   some other host may deallocate the address.
    
   Requirements: 
   - The last host to use the IP multicast address MUST deallocate
     the address. 

The word, "deallocate," sounds too much like an active verb to me, as if we
are specifying that the protocol must take some explicit action to inform
other hosts that the address is now relinquished. I don't think this is
necessary. In a pure claim-and-defend protocol, you don't have to take any
particular protocol action when you no longer needs something -- you simply
stop defending it.

The requirement is that the address must remain available (excepting
topology changes) for as long as any participant needs it.

I'm deliberately using the word "participant" instead of "member" because
"member" means "receiver" to multicast people.

Page 9:

     service - A service is a set of processes that utilize a
     particular protocol. Services range from printing to
     transferring a file to providing on-line pizza order and
     delivery.  

Transferring a file is usually done with TCP, and TCP is not a service that
you discover on the network. It would be better to say, "storing a file on a
file server," since it is the storage that is the service being provided,
not the transfer. I suggest the following replacement text:

     service - A service is a set of processes that utilize a
     particular protocol. Services range from printing to
     storing a file on a file server to providing on-line pizza
     order and delivery.

Also on page 9:

     service discovery protocol - A service discovery protocol
     enables a client (or clients) to discover a server (or servers)
     of a particular service. A service discovery protocol is an
     application layer protocol that relies on network and transport
     protocol layers.

Saying, "servers of a service" sounds odd to me. How about, "servers which
implement a particular service." I suggest the following replacement text:

     service discovery protocol - A service discovery protocol
     enables a client (or clients) to discover a server (or
     servers) which implement a particular service. A service
     discovery protocol is an application layer protocol that
     relies on network and transport protocol layers.

Page 10:

     service type - A service type allows clients, servers,
     advertisers, discoverers, and registries to uniquely identify a
     type of service...

To paraphrase, "A service type [identifies] a type of service." I don't
think this defines it very well. I suggest the following replacement text:

     service type - A service type is used by advertisers and
     discoverers to identify the service that the advertiser
     offers and the service that the discoverer seeks. The
     service type typically identifies a human-level concept,
     such as "printing". It may or may not imply a particular
     network protocol or protocols used to communicate between
     the client and the server that implements the service.

Also on page 10:

   Networked enabled printers allow various networked clients to
   submit print jobs.  A service discovery protocol MUST allow a
   printing clients to discover the printer service.

Should say:

   Network-enabled printers allow various networked clients to
   submit print jobs.  A service discovery protocol MUST allow
   printing clients to discover the printer service.

Also on page 10:

   Printers vary in their characteristics such as location, status,
   dots per inch, drivers, etc.

Delete "drivers". "Driver software" is a characteristic of the client, not
the printer. At the IETF meetings we all can print on the common shared
printers, and the people using Macs and Windows and Linux, etc. all use
different driver software, but those differences are a function of the
client software, not a function of the printer. The important characteristic
of the printer is what network protocol it speaks. I suggest the following
replacement text:

   Printers vary in their characteristics such as location, status,
   dots per inch, network printing protocols, etc.

Page 10/11:

   In the case of a printer service, a printer may be temporarily
   taken off-line for repair or everyday maintenance. This requires
   clients to be able to rediscover a service.

   - MUST allow clients to rediscover a service.

We can delete these. How is "rediscovering" a service different to
"discovering it"? We could say similar things for every section, e.g., "A
device must be able to configure an IP address. In the case of a device that
is turned off and then turned on again, it must be able to reconfigure an IP
address. If it is turned on yet once more, then it must be able to
rereconfigure an IP address..." And so on.

Page 11:

   - MUST allow discovery by client actively soliciting the service
     or by the client passively listening for advertisements. Both
     methods SHOULD be available.

Delete "Both methods SHOULD be available." Periodic advertisements are
widely believed to have problems. We do not need to say that a protocol
SHOULD do something widely believed to be bad.

Page 11:

2.4.2  Printer Manager
     
   A printer manager acts as a proxy to various printers...

I think we should the whole Printer Manager section.

If you have a PC running some Printer Manager software, with a printer
connected to its parallel port, then that's a "printer manager". Now if you
take the whole thing, and miniaturize the electronics a bit, and put it in a
single box so you can't see the parallel port ribbon cable any more, it's
called a "network-enabled printer." What's the difference?

If the point is that it is possible to write network proxies, then I think
that is a big quagmire we want to avoid in this document. An FTP server
could in truth be just a proxy that is speaking AFP to AppleShare servers on
the back end. A DNS server could in truth be just a proxy that is speaking
to an X.500 directory service. All this is true, but I don't think we need
to cover it in the zeroconf protocol requirements document.

Page 12:

   The security threats considered are sniffing (data hijacking) and
   denial of service attacks. These attacks MUST be considered for
   each protocol area.

Delete "(data hijacking)". I think "hijacking" means "To seize control of (a
moving vehicle) by use of force, especially in order to reach an alternate
destination." Hijacking a TCP connection means stealing control of it from
the legitimate user. Neither of those are merely passive observation or
eavesdropping.

   Experience may show that encryption is not necessary as long
   as ... encryption and firewalls are used.

I think what we're trying to say is this:

   The security threats considered are eavesdropping and denial-
   of-service attacks. Zeroconf protocols do not attempt to
   protect higher layer protocols from eavesdropping. Higher
   layer protocols that require protection against eavesdropping should use
   encryption.

Page 12:

3.1 IPv6 Considerations
    
   IPv6 has built in security, thus if a network is using IPv6, a
   security solution already exists.

I think we should delete this. IPv6 has IPSEC. IPv4 has IPSEC. IPv6 does not
have some magic pixie dust that makes all security worries go away.

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer
 * Chairman, IETF ZEROCONF
 * www.stuartcheshire.org

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 05 Oct 2000 10:03:07 -0400

At 07:33 05/10/00, Stuart Cheshire wrote:

>Delete "(data hijacking)". I think "hijacking" means "To seize 
>control of (a moving vehicle) by use of force, especially in order 
>to reach an alternate destination." Hijacking a TCP connection 
>means stealing control of it from  the legitimate user. Neither 
>of those are merely passive observation or
>eavesdropping.

        It is true that sniffing != data hijacking.  However, the 
Security Threats ought to also consider active attacks such as 
TCP session hijacking.   Restricting the consideration to
passive attacks is not sound, given that active attacks are
common, both in the Global Internet and in corporate intranets.

>   layer protocols that require protection against eavesdropping 
>   should use encryption.

        Encryption is a mechanism, not a property.  We should talk
about desired/needed properties rather than mechanisms.

I'd proposed this text:

        Security threats to be considered include both active 
        attacks (e.g. denial of service) and passive attacks
        (e.g. eavesdropping).  Zeroconf protocols do not attempt
        to protect other protocols from attack.  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, ESP, AH) appropriate to
        the threat.

>I think we should delete this. IPv6 has IPSEC. IPv4 has IPSEC. 
>IPv6 does not have some magic pixie dust that makes all 
>security worries go away.

        Yes.  Thank you very kindly. ESP and AH are the same for
both IPv6 and IPv4.  The only difference is that (in theory) ESP
and AH are "must implement" for IPv6.  Neither ESP nor AH should
be mistaken for magic security pixie dust.

Possible replacement text:
        With IPv6, implementation of ESP and AH is mandatory.
        Hence, ESP and AH are particularly interesting candidate
        security mechanisms in a pure IPv6 environment.  However,
        other security mechanisms (e.g. TLS) should also be
        considered.  It is important that the security mechanisms
        selected provided the security properties appropriate to
        the threat being countered.  Different threats will usually
        require different security properties for effective
        protection.

Ran
[email-masked]

---

From: Erik Guttman <[email-masked]>
Date: Thu, 5 Oct 2000 17:30:55 +0200 (MET DST)

Page 11:
	
	2.4.2  Printer Manager

	
You mean you think we should omit the whole section, right?

Erik