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

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

These are all minor changes which I believe have been discussed on 
the list already but remain to be reworked in draft 05.  I recommend
these changes be made as part of the WG last call.

Erik

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

Regarding:

   A zeroconf protocol is able to operate correctly in the absence of 
   either user configuration or external configuration from 
   infrastructure services such as conventional DHCP [RFC 2131] or 
   DNS [RFC 1034, RFC 1035] servers. Zeroconf protocols may use 
   configuration, when it is available, but do not rely on it being 
   present.  

It is clear on the mailing list and from comments I got directly
that there is a working group consensus that mac address 
configuration should be acceptable in zeroconfiguration protocols, 
if it is available.

That is because many autoconf protocols use it and because there
are few cases where it is not available.  

The upshot is that if there is a protocol which requires the use
of L2 addresses it can't be disallowed and that if one doesn't
require the use of mac addresses it isn't 'better' because of this
alone.

I suggest the following modified text:

   A zeroconf protocol is able to operate correctly in the absence of 
   either user configuration or external configuration from 
   infrastructure services such as conventional DHCP [RFC 2131] or 
   DNS [RFC 1034, RFC 1035] servers. Zeroconf protocols may use 
   configuration, when it is available, but do not rely on it being 
   present. The one exception identified is the use of MAC addresses.
   Layer two addresses MAY be used as parameters in zeroconfiguration
   protocols.

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

Regarding:

   The first host that needs the IP multicast address allocates the 
   address, but some other host may deallocate the address. This is 
   because the first host may leave the multicast group before all 
   the other host leave the group. This requires the last host using 
   the IP multicast address to deallocate the IP multicast address. 
    
   Requirements: 
   - The first host to use the IP multicast address MUST allocate the 
     address. 
   - The last host to use the IP multicast address MUST deallocate 
     the address. 

If a claim & defend protocol is used, there is no explicit 
'deallocation' as the above text would seem to imply.  An
allocation is no longer defended and this implies it is no
longer allocated.  How about modifying the above text for
clarity to:

   The first host that needs the IP multicast address allocates the 
   address, but some other host may deallocate the address. This is 
   because the first host may leave the multicast group before all 
   the other host leave the group. This requires the last host using 
   the IP multicast address to deallocate the IP multicast address
   (or to simply cease 'allocating' it if the protocol does not 
   support a distinct deallocation operation).
    
   Requirements: 
   - The first host to use the IP multicast address MUST allocate the 
     address. 
   - The last host to use the IP multicast address MUST deallocate 
     the address (or cease to allocate the address if the protocol
     does not support a distinct deallocation operation).

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

Regarding:

   Discovery SHOULD be possible by either the client actively 
   soliciting the service or by the service advertising then the 
   client passively listening for the advertisements. At least one  
   method MUST be available. Once a client finds the printer, it can 
   utilize different printing protocols such as raw tcp, lpd, and 
   ipp.  

The important thing is that a client can discover a printer.  This
is a requirement document.  Whether discovery protocols use active
or passive discovery is not appropriate to discuss here.  I believe
the text should be:

   Service discovery MUST be possible so that the client can obtain
   service advertisements from printers on the network.  This could,
   for example, be supported by a service discovery protocol which
   allows the client to solicit service advertisements, or by a protocol
   where the service sends unsolicited service advertisements.

   Once a client finds a printer, it can utilize a printing protocol 
   (such as raw tcp, lpd or ipp) to submit jobs and communicate with 
   the printer.
   
----------------------------------------------------------------------

Regarding:

   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. 

There is nothing in principal different between discovering a printer
and rediscovering it.  I believe the only thing that this text brings
out is that the availability of the printer on the network implies its
discoverability.  I think the following text should be entered in place:

   Printers which are on-line SHOULD be able to be discovered using
   the service discovery protocol.  Printers which are not on-line
   SHOULD NOT be discoverable using the service discovery protocol.

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

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

This statement is inconsistent with the text above which states
that 

   Discovery SHOULD be possible by either the client actively 
   soliciting the service or by the service advertising then the 
   client passively listening for the advertisements. At least one  
   method MUST be available.

This text states that one or the other mechanism MUST be supported.
The requirement text sais that both SHOULD be supported.

As I argued above, the requirements document should not take a 
position on which of active or passive discovery is used.  The
requirement is that service discovery is possible in a timely way.
For that reason, I think the requirement above should be changed
to:
 
  Requirements:
  - Discovery of services actually available on the network MUST 
    be possible by the client. 

----------------------------------------------------------------------
Regarding:

   Topology changes may create any of the following problems: 
   conflict among netmasks, conflict among default routes, duplicate 
   IP addresses within an IP subnet, or duplicate IP subnets within 
   an internet. Note that default routes and duplicate IP subnets are 
   not issues for single IP subnet networks.  

I agree with others who have been confused by the notion of conflict
among netmasks.  What is this supposed to mean?  I think this text
should be struck from the draft.

How should conflict among default routes be a problem?  How should it
arise?  We've been over this before several times and I think this
text needs to be struck from the draft.

How can duplicate IP subnets in an internet arise from installing
a bridge?  I think this text should be struck from the draft.

So the text in 2.1.2 should read:

   Topology changes may give rise to duplicate IP addresses within an
   IP subnet.

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

Text should be added in 2.3.2 to read:

   It is possible that an address assignment which was unique could
   cease to be unique after a topology change.

This implies an additional requirement to section 2.3.2:

   Requirements:
   - MUST detect and resolve conflicts in multicast address assignement 
     in a timely manner.

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

Regarding:

   Spurious topology changes or other events such adding and removing 
   hosts may cause conflicts and state changes within a protocol. 
   Zeroconf protocols must be able to resolve conflicts and state 
   changes caused by topology changes or other events. The scenario 
   in the 2.1.2 Bridge Installed section is the only scenario that 
   illustrates the need for this requirement, thus the below require 
   is duplicated in section 2.1.2. However, this requirement applies 
   to all protocol areas. 
    
   Requirement: 
   - MUST resolve conflicts and state changes in a timely manner.  

I believe that this document should describe three scenarios where
topology changes may result in conflicts:

  1. Address allocation
  2. Name assignment
  3. Multicast Address Allocation

These should be listed here (and unless there are good arguments to
the contrary, this should be all that is listed here).  Address Allocation
conflicts are discussed in section 2.1.2.  Name assignment conflicts
are discussed in 2.2.2.  Multicast Address allocation conflicts are
NOT discussed in 2.3.2, but they should be.  I suggested additional
text for 2.3.2 above.

I suggest the reworked text be:

   Spurious topology changes or other events such adding and removing 
   hosts may cause conflicts and state changes within a protocol. 
   Zeroconf protocols must be able to resolve conflicts and state 
   changes caused by topology changes or other events. Sections 2.1.2,
   2.2.2 and 2.3.2 discuss the implications of this requirement.
    
   Requirement: 
   - MUST resolve conflicts and state changes in a timely manner.

---

From: Glenn Kime <[email-masked]>
Date: Thu, 5 Oct 2000 11:42:52 -0400

Erik,

Wouldn't a "shared secret" be a 2nd item, along with the MAC address, that
is expected to be entered via some other method than zeroconf?

There was good discussion in the DSL Forum meeting on this subject yesterday
supporting the idea.  This way, you can incorporate security into zeroconf.

Thanks,

Glenn
Avail Networks

-----Original Message-----
From: Erik Guttman [mailto:[email-masked]]
Sent: Thursday, October 05, 2000 11:32 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: WG LAST CALL: draft-ietf-zeroconf-reqts-05.txt

Erik

Regarding:

Regarding:

   Requirements: 

    
   Requirements: 

Regarding:

   

Regarding:

Regarding:
    
   Requirements: 

 
  Requirements:

   Requirements:

Regarding:

   Requirement: 

  1. Address allocation
  2. Name assignment

    
   Requirement:

---

From: Stuart Cheshire <[email-masked]>
Date: Mon, 9 Oct 2000 15:11:17 -0700

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

Oops. Typo.

Yes, I meant, "I think we should omit the whole Printer Manager section."

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

---

From: Stuart Cheshire <[email-masked]>
Date: Mon, 16 Oct 2000 16:03:43 -0700

Last week the last-call period ended for 
draft-ietf-zeroconf-reqts-05.txt, and it is now time to summarize the 
comments received during those two weeks:

1. We should consider how the security section could be improved, taking 
into account the guidelines in draft-rescorla-sec-cons-01.txt:

>   Authors MUST describe
>
>     1. which attacks are out of scope (and why!)
>     2. which attacks are in-scope
>     2.1  and the protocol is susceptable to
>     2.2  and the protocol protects against
>   ...

Also, proposed new sections of 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.

>        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.

2. New definition of the term process:
     process - A process is the execution of an algorithm implemented
     in software, hardware, or a combination of software and hardware. 

3. Change "configuration" to "configured information" in:
   Zeroconf protocols may use configured information, when it is
   available, but do not rely on it being present.

4. Remove "spurious" from "spurious topology change"

5. Define what we mean by "bridge"

6. Remove or clarify section 1.5 (Routable Protocol Requirement).

7. Remove text about "conflict among netmasks", "conflict among default 
routes", etc.

8. Remove redundant text:
>   - MUST be able to determine if subsequently chosen names are 
>     unique, if the first name is not. 
>   - 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."

9. Simplify text about, "Discovering based on these particular 
characteristics SHOULD/MAY be part of the service discovery protocol."

10. Clarify whether we require a service discovery protocol to use 
periodic advertisements in addition to client-initiated discovery.

11. Remove "or negotiate characteristics."

12. Remove superfluous distinction between "discovery" and "rediscovery"

13. What is the "Printer Manager" example for?

14. Erik Guttman (Thu, 05 Oct 2000 17:32:04 +0200) and myself (Thu, 05 
Oct 2000 04:33:47 -0700) both sent fairly long lists of comments which I 
will not duplicate here.

After this, we're almost finished.