Subject: last call comments on draft-ietf-zeroconf-ipv4-linklocal-07

From: Keith Moore <[email-masked]>
Date: Mon, 23 Sep 2002 19:42:43 -0400

These are Last Call comments on draft-ietf-zeroconf-ipv4-linklocal-07.txt

They are being sent after the last call deadline because it's taken me
that long to put them together in this form.  I realize that much of 
this has been presented before in other forms, I hope that this 
presentation makes it clearer as to how the various concerns fit together.

Unfortunately, I still haven't had time to put together comments on
specific text in the document, but I will try to do that within the
next few days.

Keith

0. Introduction
   
   This proposal subtly changes the behavior of the Internet Protocol.
   As there is a tremendous investment in IP and a great many valuable
   and essential services depend on it, it seems prudent to examine 
   in some detail the potential for this proposal to have an adverse 
   effect on applications, hosts, or networks.  Whereas for most 
   candiates for standards track we are satisfied if the protocol has no
   _known_ technical omissions with respect to the requirements placed on it, 
   for a candidate that affects the fundamental Internet Protocol it seems 
   entirely appropriate to insist that there be _high_confidence_
   that there are no such omissions.  To put it a different way, for 
   proposed changes to fundamental internet protocols there is an
   implicit requirement that the changes not be disruptive to
   existing uses of those fundamental protocols, to the operation
   of IP networks, or to the ability of IP-based networks to support 
   a wide variety of current and future applications.

   This review is an attempt to analyze whether, under what conditions, 
   and for what purposes, such confidence is justified.  It identifies 
   some areas where this level of confidence appears to be justified, 
   and other areas where this level of confidence does not appear to 
   be justified.

   By the word 'analyze' I mean a methodical technique which provides
   exhaustive coverage of scenarios which might cause failure.  Formalism
   is not my strong suit, and I do not claim rigor for these arguments.  
   I also realize that attempting to provide exhaustive coverage of
   potential problems requires at least some discussion of areas that are
   'obviously' not problematic, which is tedious for readers as well as
   for the writer.  However, it also forces consideration of potential
   problem areas that might have been previously ignored.
   
   Introduction of unicast link-local addressing into IPv4 has several
   broad effects which can be further analyzed for potential problems. 
   In particular, 

   - LL generates network traffic, and thus consumes resources,
     during both negotiation and use,

   - The introduction of LL addresses makes those addresses
     visible in some contexts,

   - Special considerations apply to use of LL addresses beyond
     those associated with "normal" IPv4 addresses, and to some
     degree even beyond those associated with "private" IPv4
     addresses, and

   - The introduction of LL facilitates new communications paths.
     Indeed this is its entire purpose.

   From these broad classes the following questions are derived,
   which this document attempts to answer:

   - Can use of LL be avoided if it is found to cause problems?

   - Will the resources consumed by LL traffic cause problems for 
     networks, hosts, or applications?

   - Will the visibility of LL addresses by networks, hosts, and 
     applications cause problems for networks, hosts or applications?

   - Will the special considerations that apply to use of LL addresses
     cause problems for current or future applications?

   - Will the capability to send messages using LL addresses
     cause problems for networks, hosts, or applications?

0.1 Notation

   The arguments below are based on draft-ietf-zeroconf-ipv4-linklocal-07,
   which will be referred to as "the draft specification". 

   For the sake of brevity the letters "LL" will be used to denote
   IPv4 unicast link-local addressing as defined in the draft
   specification.  Use of "LL" is not intended to refer to broadcast
   link-local addressing or multicast link-local addressing, nor
   to IPv6 unicast link-local addressing.
 
   Note: While some of the problems identified here with LL also apply to 
   IPv6 unicast link-local and/or site-local addressing, they are not the
   focus of this document.  For instance, the impact of the late 
   introduction of LL into IPv4 is different than the impact of
   having unicast link-local and site-local addressing as part of the
   original design of IPv6.  While the comparison between the two cases is
   interesting, it would distract from the purpose of this document to 
   consider the v4 and v6 cases separately.

1. Can use of LL be avoided if it is found to cause problems?

1.1 LL will be imposed on applications, hosts, and networks
   
   Several existing Apple and Microsoft platforms currently ship with 
   a pre-standard version of this technology.  Given the similarity
   of their implementations with the protocol described in this 
   draft, and the affiliation of two of the draft authors, it seems 
   reasonable to assume that these two vendors (at least) will 
   implement a standard version of v4 LL if and when it is approved 
   (or perhaps even in anticipation of approval).

   These two vendors supply operating system software for the 
   vast majority of computing platforms in use today, especially
   'desktop' and 'laptop' platforms.   Therefore it seems likely
   that most 'desktop' and 'laptop' computers sold, and most
   operating system upgrades for such systems, will support the 
   IETF v4 LL standard soon after it is adopted and for the next
   several years.  

   Furthermore it also seems likely that, as new computers are 
   added to existing IP networks, and as existing computers are 
   replaced or upgraded to more recent opreating systems, IP networks 
   and IP-based applications will be exposed to LL traffic without 
   either the network operators or the users taking any action 
   to enable it.

   According to the descriptions of existing implementations in the  
   appendix of this document, several existing implementations 
   do not attempt to claim and/or use LL addresses if and when a DHCP
   server responds to queries from the host.  This provides a readily-
   available means of allowing a network to suppress use of LL addresses
   by these implementations.  However this feature is specifically
   forbidden in the draft specification, and the draft specification
   provides no other mechanism with which use of LL addresses may be 
   disabled by either a host or a network.  

   (Note that while the claim-defend protocol provides a means to 
   deny a host the ability to claim any particular LL address,
   it provides no means to discourage a host from attempting to
   claim other addresses, indefinitely, at a rate of up to one 
   address per minute per host)

   Therefore, the draft specification would impose LL on
   existing hosts (as they are upgraded to later operating systems),
   applications, and networks, with little means of avoiding it or 
   disabling it should it be found to have an adverse effect.

1.2 Conditions under which LL traffic will appear

   Since presumably LL will only affect applications, hosts, or 
   networks if it is actually used, in order to understand whether
   LL can be avoided it is necessary to understand the conditions
   under which LL traffic will appear.

   a. Claim-defend protocol

      One kind of LL traffic consists of arp requests and replies
      that are used to claim and defend LL addresses.   These are
      link-local broadcast packets, so they should reach every
      host on the local network.

      The claim-defend protocol will be invoked whenever a host
      wishes to allocate a link-local address.  The draft
      specification seems to assume that this will happen at
      power-on or bootstrap time (after a random delay).
      Other implementations may be consistent with the letter of
      the draft specification.  For instance, a host could allocate a
      link-local address whenever an application requested to send 
      traffic to a link-local address, or whenever an application 
      explicitly requested to listen for traffic on a link-local
      address.  However such implementations would probably violate
      the stated intent of the draft specification to make link-local
      addresses "available all the time".

      Use of the claim-defend protocol continues as long as the
      LL address is "in use" by that host, though no definition
      of "in use" is given.  While a particular platform might 
      provide a nonstandard means to disable use of LL addresses,
      causing them to no longer be "in use" by the host, it seems 
      consistent with the intent of this specification to assume that 
      most hosts that implement this specification will claim a 
      link-local address at power-on or bootstrap time, and 
      defend or claim a new address on a link during any period 
      that the host is operating and has access to the link.

      It is therefore assumed that the claim-defend protocol will
      unavoidably appear on any network to which  LL-capable
      hosts are attached, and that in due time this will apply to
      essentially all IP-based networks.
      
   b. LL addresses used as IP source or destinations

      The other kind of LL traffic consists of IP packets 
      with LL source and/or destination addresses.  Such traffic
      will occur whenever a application sends traffic to an LL 
      destination, or whenever an application on a host with 
      only an LL address sends traffic to a routable destination.

      Most applications do not send unicast traffic to arbitrary hosts,
      or to all "known hosts", but only to specific hosts which they
      have reason to believe will contribute usefully to the purpose
      of the application.  

      Therefore, most applications will send traffic to LL 
      destinations only when those destinations are somehow 
      exposed as being useful to that application.   If 
      LL addresses for those destinations are not exposed,
      they will not be used.

      Such exposure can occur via a variety of means:

      - explicit configuration by users or operators

      - a general-purpose service discovery protocol

      - a referral from another component of the application

      - a referral from a different application
        (for example, a file obtained by FTP can request that
        form data be sent via HTTP to a literal IP address)

      - being associated with the name of a host, service,
        or other resource that is declared to be useful
        (in DNS or another name lookup service)

      - from a host's network interface or ARP tables

      - from the source address of an IP datagram or connection

      - from network management protocols such as SNMP

      Some sources of LL address exposure, and thus some sources of
      LL use, are controllable.  For instance, operators can be 
      cautioned to eschew exposure of LL addresses in DNS, service 
      discovery protocols, etc., and thereby to limit the use of LL
      addresses to some degree. 

      However, application behavior varies widely.  Some applications 
      use the source addresses of IP datagrams as destinations of
      subsequent datagrams, or use such addresses in referrals to other
      components.  (For instance, in a NATted environment the source address
      is more reliable than an address passed in the payload).  Other 
      applications provide referrals to other components using addresses 
      obtained from interface tables.  (For instance, to help the
      application to cope with limited-scope addresses by listing
      each of a host's addresses in referrals to other components 
      of the application, allowing components to try multiple addresses 
      until they find one that works.) Such applications  will use LL
      addresses and generate LL traffic without being explicitly
      configured to do so.

      Thus it is not generally possible to insulate hosts, networks, 
      or applications from LL merely by eshewing use of LL addresses 
      in managed name lookup services, service discovery protocols, and 
      application configuration.  The degree to which LL addresses are
      used "accidentally" depends on the specific set of applications
      that are used on a particular network.  This can be expected
      to vary considerably from one network to the next.

2. Will the resources consumed by LL traffic cause problems for networks,
   hosts, or applications?

2.1 Effects of LL resource consumption on network operations

   a. bandwidth consumption 

   - unicast LL traffic

     Unicast LL traffic imposes no more overhead on the local network
     than unicast traffic to a local routable address.  It is possible
     that introduction of LL will increase the amount of traffic on a 
     network by facilitating new applications.  We would generally
     consider this a sign of success, though the possibility exists
     that increased usage would cause short-term operational problems
     for networks that are nearly saturated.

   - broadcasts resulting from claim-defend protocol

      Under normal conditions (e.g. networks with <= 1000 hosts) LL
      claim-defend appears to generate approximately the same amount
      of traffic as would be generated by a normal use of ARP for
      duplicate address detection of a local routable address.

   - broadcasts resulting from normal ARP requests/replies (not claim/defend)

      One difference between ARP for LL and ARP for routable addresses
      is that ARP replies for LL addresses are broadcast where as 
      normal ARP replies are unicast.  In L2-switched networks this
      will consume bandwidth in portions of the network where unicast
      ARP replies did not.  This is assumed to be a minor effect as long
      as the number of hosts on an L2 network is relatively small.  The
      impact might become significant on large L2 switched networks.

      On a network with an average of 1000 active connections to unique
      (to a host) LL destinations, between hosts whose ARP caches time out
      in 20 minutes, this is an average of 1.67 broadcast packets / second.
      (counting both ARP requests and replies) This could result from 1000
      hosts each with a single active connection to an LL address, or by
      100 hosts each with active connections to ten different LL addresses.
      A network with 1000 hosts, each with 10 active connections to LL
      addresses, would generate 16.7 packets / second on average.  Thus
      the maximum practical size of a network using LL might be somewhat
      smaller than the 1300 hosts cited in section 1.2 of the draft
      specification if a significant fraction of those hosts have active
      connections to LL destinations.

      It should be restated that this is only an issue for switched 
      networks -- for "bus" networks (like classic Ethernet) the
      overhead _on the network_ (not on hosts) for broadcast packets
      is the same as that for unicast packets.  Even for switched
      networks, LL ARP request/replies are only twice as many
      broadcast packets as LL requests on "bus" Ethernets.

   b. network availability / reliablity / stability

      LL does not appear to affect network availability or reliability
      as long as the additional traffic does not cause the network to
      become saturated.

2.2 Effects of LL resource consumption on hosts

   a. Hosts which implement LL

      Hosts which implement LL can reasonably be expected to cope
      with the amount and type of traffic generated by LL on a 
      reasonably-sized network.  The network code on such hosts will 
      presumably have been implemented with LL in mind and tested
      in an LL environment.

   b. Other hosts 

      Hosts which do not implement LL can still be expected to
      implement ARP on interfaces that require it, and for the most
      part LL usage is consistent with ARP.  There is some chance that
      platforms which do not implement LL might be confused by LL's
      requirement that LL ARP replies be sent using link-layer
      broadcast instead of link-layer unicast (draft spec, bottom page 11).
      A correct implementation of RFC 826 would not be confused, as it
      would only process response for which the answer to the question 
      "Am I the target protocol address?" (from the ARP response
      payload, not the Ethernet header) were "yes".  

  c. All hosts

      The need to process additional broadcast packets generated by
      LL ARP replies may result in increased overhead for all hosts,
      and in increased hardware costs for new hosts to permit them
      to handle an increase in interrupts needed to broadcast packets, 
      even if they are promptly discarded.  This seems unlikely to
      significantly affect general-purpose hosts (desktops, laptops,
      servers) but may affect "appliance" or "fixed-function" hosts
      (especially those designed for the consumer market), which 
      which operate with less margin in CPU cycles. 

2.3 Effect of LL resource consumption on applications

   In general, an application should consume no more resources
   for LL traffic than for traffic between routable unicast addresses.
   However, if an application naively responds to LL traffic in a 
   situation where use of LL will cause the application to fail,
   and that application persists in trying to use LL, the application's
   performance may be adversely impacted.

3. Will the visibility of LL addresses by networks, hosts, and 
   applications, cause problems for networks, hosts, or applications?

3.1 Effects of LL visibility on networks

   Since LL addresses are not tightly bound to hosts, there is no
   association of host identity with LL address, it becomes necessary 
   for traffic monitors to associate hosts with layer 2 addresses rather
   than layer 3 addresses, even if they are monitoring layer 3 traffic.
   With the introduction of LL, DNS cannot be used to provide reliable 
   address-to-name mapping even on networks where it might be reliable
   for routable addresses (e.g. when DHCP and DNS are coordinated).

3.2 Effects of LL visibility on hosts

   The effects of LL visibility on hosts appear to be reasonably
   well covered in the draft specification.  

3.3 Effects of LL visibility on applications

   As implied earlier, when LL addresses become visible to apps
   (e.g. via interface or ARP tables) they will then be used
   by some apps that use addresses in referrals to other apps.

   a. address scope problems due to referrals

      Because LL address-to-host bindings are only valid on a
      particular link, when applications use LL IP addresses in
      referrals to other applications (or other components of the
      same application) those referrals may fail when those IP
      addresses are not valid for the host that received
      those addresses.

   b. address stability problems with referrals

      Because LL address-to-host bindings are only valid on a
      particular link, applications which use LL IP addresses in
      referrals to or from other applications may fail when
      those IP addresses are no longer bound to the same host
      as when the referral was generated, even if the host which
      received the referral has access to the same network link
      for which the LL address was valid.

4. Will the special considerations that apply to use of LL addresses
   cause problems for current or future applications?

   a. address scope problems with multiple intefaces

      Because LL address-to-host bindings are only valid on a
      particular link, applications on hosts that have multiple
      interfaces supporting LL may be unable to connect to LL
      IP addresses, or may find certain LL addresses ambiguous.

      Allowing an application to select a source interface does
      not solve the problem, since existing applications will
      not know how to do this, and even new applications will
      rarely be aware of which interface is associated with which
      address.

   b. non-uniqueness of addresses

      Because LL addresses are not unique, applications which
      use IP addresses as unique tokens may fail.

      Some will say that private addresses and NATs have already
      caused this problem, and that applications can no longer
      depend on addresses being unique.  This is an over-generalization
      that applies only to mass-market apps.  Despite the existence
      and wide deployment of NATs, there are still many cases where 
      some degree of address uniqueness is a reasonable assumption, 
      and for which LL would cause that assumption to fail.  For 
      instance, applications used only within a local network can 
      often assume that addresses of other hosts in that are uniquely 
      assigned to those hosts.  While a network can choose how it 
      uses private address space and how it configures NATs, it will 
      have little choice about the imposition of LL.

   c. address stability effect on connection duration

      Because LL address-to-host bindings are subject to
      (occasional) change without notice, applications may fail
      when their hosts' addresses change.

      It is not always feasible or even possible for applications
      to recover from such failures.  For instance: 

      - TCP lacks the ability to survive an address change of
        either endpoint, so applications cannot count on lower
        layers to effect recovery.

      - Few applications protocols have explicit application-level
        acknowledgements or checkpoint/restart procedures which
        allow them to recover from broken connections in mid-session,
        so the entire session must be restarted.

      - In some cases the IP address is the only usable name
        by which an application component can communicate with a peer.
        When the address is invalidated the peer can no longer be
        reached.

     Some will claim that DHCP already allows addresses to be unstable.
     This is an overgeneralization because DHCP is optional, because
     DHCP is often configured in a way which allows addresses to be 
     moderately stable (by assigning long lease times, indefinitely 
     renewing leases, and/or binding L3 addresses to L2 addresses).    
     A network can choose which DHCP servers to use and how to configure 
     them, but it has little choice about the imposition of LL.

5. Will the capability to send messages using LL addresses cause
   problems for networks, hosts, or applications?

   a. security problems

      LL facilitates communications between hosts under circumstances,
      and over paths, which did not previously permit communication.
      In the case of wireless links the introduction of LL can cause
      purely "accidental" communications paths to be established,
      as hosts with wireless links can connect to one another in the
      absence of any explicit effort by users or administrators to
      facilitate such communications  (and despite efforts to limit
      such communications).  This introduces new risks for both networks
      and hosts, especially networks and hosts that rely (as most do)
      on the ability to do some kind of ingress filtering as part of
      their security implementation.

      Consider the following example scenario:

      --------------------------+      +--------------------------
         company A meatspace    |      |   company B meatspace
                                |      | 
         company A              |      |           company B
         network                |      |           network
              /                 | wall |                 \
             /  +--------+      |      |      +--------+  \
      ==========| laptop |]~~~~~~~~~~~~~~~~~~[| laptop |=========
                +--------+      |  ^   |      +--------+
                                |  |   | 
                                |  |   | 
      --------------------------+  |   +--------------------------
                                   |
                      covert LL wireless channel

      Company A and company B maintain separate networks.   Each
      has its own policy for what kinds of traffic to permit on
      those network, and each company's network policy is implemented
      using a firewall.  However if the laptops have (presumably
      built-in) wireless interfaces supporting LL, a covert channel
      may exist between machines on the different networks.  This  
      situation can exist anytime the laptops allow "ad hoc" operation
      on their wireless interfaces.  It has several implications:

      - Existing firewalls are bypassed, so existing threat
        countermeasures are circumvented.  Granted, it's a bad idea to
        completely rely on firewalls since many threats are internal,
        but the reality is that this is currently both conventional 
        wisdom and common practice.

      - Company A is implicitly trusting company B's firewall (and the
        security of company B's hosts) and vice versa.

      - Company A's hosts can attack company B's hosts, and vice versa.

      Note that a single compromised host can serve as a platform from
      which other attacks can be launched.  Even if A does not attack
      B or vice versa, a successful attack on a host on either network
      may facilitate a (presumably easier) attack on the other network.
      It is not difficult to see how a worm or virus could propagate 
      using LL covert channels.

      Another scenario is similar -- a nomadic laptop which
      connects to various ad hoc LL networks as it moves potentially
      exposes the laptop to new security threats in each new network.
      A laptop which was compromised using LL may then be used to
      attack a company's private network when it is connected to
      that network.

   b. support issues

      In addition to difficulty of traffic monitoring, introduction of
      LL may cause application failures which are difficult to isolate,
      diagnose, or fix.  This causes issues for those who support networks
      and network-based applications.

6. Summary

   - If the draft specification is implemented in its current form,
     it is impractical to avoid imposition of LL on networks, hosts
     and applications using current measures.

   - LL seems unlikely to cause resource depletion for most networks.
     However it may cause resource depletion in nearly-saturated
     networks and large L2-switched networks.  Some limited function
     hosts may not be able to cope with additional CPU load due to
     additional broadcast packets on large networks.  Applications which
     are incompatible with LL and which use LL "accidentally" may 
     cause additional consumption of network resources if they 
     persistently retry operations that failed due to LL.

   - For various reasons, some applications are incompatible with LL.
     Some of these applications will fail if configured to use an LL
     address or a name that binds to an LL address.  Others will fail
     when LL is introduced merely because those LL addresses are visible
     via interface or ARP tables, and/or because they will begin to
     see traffic from LL addresses.

   - Imposition of LL circumvents existing security mechanisms and 
     creates additional security risks for networks, hosts, and
     applications.

   - Imposition of LL creates new support burdens for users, networks,
     and application maintainers.

7. Recommendations

   - There needs to be a standard way for managed networks to disable LL
     traffic, both on the network and on hosts connected to that network.

     One way to do this that preserves the ability of LL and DHCP-assigned
     addresses to coexist would be to design a different response to the
     claim-defend protocol that disables LL, and which LL hosts were
     required to honor as a matter of standards compliance.  Another way 
     to do this would be to define a DHCP "disable LL" option.
     Either would provide a means of allowing networks to avoid security
     problems associated with LL and/or to avoid impact on existing 
     applications which do not work well in the presence of LL.

   - As a matter of standards compliance, hosts need to be required 
     to provide a means to disable LL traffic, both entirely and on a
     per-interface basis.

   - Because there are valid reasons to disable LL, and for other reasons,
     the specification should discourage the expectation that a host that
     implements only LL can expect to communicate with other IP hosts,
     even those on the same network segment.  Hosts should implement DHCP
     and/or support static address configuration if they wish to have
     the capability to communicate with other hosts using IP.

   - Even when LL is enabled on a host or an interface, there needs 
     to be a way of isolating existing applications from LL traffic 
     and from the visibility of LL addresses. 

   - LL should be disabled by default on wireless interfaces, requiring
     explicit configuration of such interfaces to support LL.   Enabling
     the wireless interface to support LL on a specific wireless network
     should be separate from enabling a wireless interface to support LL
     on an ad hoc network.

   - When wireless interfaces are allowed to use LL on ad hoc networks
     (as opposed to configured wireless networks), there should be a
     means to prevent applications from being exposed to traffic from
     such networks, so the host will accept traffic only for those
     applications that are believed to be safe from arbitrary, anonymous
     traffic.

   - More study is needed before the security implications of LL can
     be fully understood.  LL should not be deployed until those 
     implications are understood and suitable countermeasures exist.
    
   In addition to these major changes, other specific changes to the
   draft specification are also desirable.  But this review is already 
   long enough.

8. Conclusions

  LL is potentially a very useful technology, and there are compelling
  reasons to deploy it.  However if deployed in the form specified in
  the draft specification, it will break some applications, invite
  new kinds of attack on hosts and networks, and create new means
  of propagating viruses.

  I do not believe that the current draft specification meets either 
  explicit or implicit requirements for Proposed Standard status.

---

From: Joshua Graessley <[email-masked]>
Date: Tue, 24 Sep 2002 10:03:26 +0800

Keith, a good analysis. My comments follow.

>    performance may be adversely impacted.

The same could be said of any IPv4 address where connectivity is 
impossible. A similar scenario occurs with firewalls and FTP where an 
FTP client may connect to a server and send it's IP address. The server 
may be unable to establish a connection back to the client due to a 
firewall. Applications should already gracefully handle cases where 
acquire an address that they can not reach.

>       Consider the following example scenario:

In this example, if 802.11 is used, one of the two clients would need 
to be setup as an access point and the other client would need to be 
configured to connect to the access point. This requires some 
configuration. If the laptop in company B was trying to be malicious 
and attack the laptop in company A, the laptop in company B would need 
to be configured as an access point and the laptop on company A would 
need to somehow automatically pick company B's laptop as the access 
point to which it would connect. Since company B's laptop would need to 
be configured as an access point, there is no reason it could not also 
be configured as a DHCP server. Link local addressing has no effect on 
the insecurity of wireless networks.

>      applications which do not work well in the presence of LL.

Most cable modem companies use DHCP to assign addresses and they will 
only assign one address per household (unless a tax is paid to the ISP 
for extra IP addresses). If I have a printer and a few other IP devices 
at home that don't need connectivity to the internet, LL would serve me 
well for communicating with those other devices. If my ISP has an easy 
way to disable LL so they could charge me more, I have no doubt they 
would make use of it.

>   new kinds of attack on hosts and networks, and create new means

You do point out a few situations where applications may break due to 
link local, very similar to the way that private address ranges can 
break network applications. LL does not "invite new kinds of attacks on 
hosts and networks", nor does it "create new means of propagating 
viruses". Your wireless example of how LL could supposedly be used to 
compromise security is bogus. The use of LL addresses makes no 
difference, since an attacker could simply use DHCP to assign 
addresses. In addition, the victim would have to join the attackers 
network by selecting his access point.

-josh

---

From: Keith Moore <[email-masked]>
Date: Mon, 23 Sep 2002 23:05:11 -0400

> firewall. 

indeed, this can happen for other reasons, as you suggest.  however these
are artifacts of the local network configuration (i.e. the network
administrator has a choice of whether to do off-site FTP) and they are
implemented as a matter of security policy.  this is in contrast to LL 
where the failures are not the result of choices made by the network 
administrator and are not 

> Applications should already gracefully handle cases where 

perhaps, but the application has no way of knowing whether the address
is permanently unreachable or temporarily unreachable.  email typically
retries once every 30-60 minutes for several days before giving up.
would you call that graceful handling or too much resource consumption?

I should say that I don't see this particular case as an extremely likely  
scenario - it was just something I noticed while trying to list possible
reasons for failure caused by LL resource consumption.

> the insecurity of wireless networks.

- 802.11 is not the only wireless technology 
- another scenario is that two laptops automatically connect to a 
  neutral access point   
- I considered the DHCP scenario also.  But there's a subtle difference 
  between accidental covert channels and deliberate covert channels
  such as might be set up with DHCP.  
- Also, the existence of a flaw in DHCP does not justify having a
  similar flaw in LL.  And host support for DHCP can generally be turned off.

> way to disable LL so they could charge me more, I have no doubt they 

well, it's a good point to make that the network owner doesn't necessarily
control the DHCP server.  (really unfortunate that we don't have a well-defined
boundary between what the ISP is responsible for and what the customer  
is responsible for, but zeroconf can't solve that).

so perhaps the DHCP option isn't the best idea.  but something is needed.

> network by selecting his access point.

reread the example again.  the assumption is not that either A or B
is actively trying to compromise the other - it's that the existence of
an unwanted "zero configuration" channel between A and B provides a
new path by which attacks can be mounted by a third party.

and again, the existence of a flaw in DHCP does not justify a flaw in LL.

Keith

---

From: "Jim Fleming" <[email-masked]>
Date: Mon, 23 Sep 2002 22:09:16 -0500

----- Original Message ----- 
From: "Joshua Graessley" <[email-masked]>
> for extra IP addresses). 

Are you opposed to paying the I* society $1 per year per domain name (even 3rd level ones) ?

Are you opposed to paying $10 per month for one static 32-bit IP address ?

If so...
How are all of the insiders going to pay for all of their world travel, and
the other parties and .ORGies that they have planned ? There are people lining up to
get one of those $250,000 per year patronage jobs watching the paint dry. They
need more money from you to pay them.

How will they fund all of the people needed to make sure Africa gets plenty of IP addresses ?
Do you see any /8 allocations here for Africa ?...yet...
http://www.iana.org/assignments/ipv4-address-space
http://www.washingtonpost.com/wp-dyn/articles/A43976-2002Sep20.html
"Victory, who heads Commerce's National Telecommunications and Information Administration (NTIA), is on her way today to an
International Telecommunications Union meeting in Marrakech, Morocco, and was not available for comment."
=====

What about all of the parties in Latin America in March 2003 ?...it is Winter in the U.S. time for some fun in the sun.
http://www.icann.org/calendar.htm
      March 2003 ICANN Meetings TBD (in Latin America)

http://lacnic.net/en/transition.html

Jim Fleming
2002:[IPv4]:000X:03DB:...IPv8 is closer than you think...IPv16 is even closer...
http://www.netfilter.org/
http://www.analogx.com/contents/dnsdig.htm
http://ipv8.dyndns.tv
http://ipv8.yi.org
http://ipv8.dyns.cx
http://ipv8.no-ip.com
http://ipv8.no-ip.org
http://ipv8.no-ip.biz
http://ipv8.no-ip.info
http://ipv8.myip.us
http://ipv8.dyn.ee
http://ipv8.community.net.au
http://ipv8.ods.org

---

From: Keith Moore <[email-masked]>
Date: Mon, 23 Sep 2002 23:29:34 -0400

> network by selecting his access point.

On reflection I agree that unqualified "invites new kinds of attacks on
hosts and networks" and "creates new means of propagating viruses"
may be a bit strong - or at least aren't justified by the text.  And yet 
I think that there is something to the wireless example.  It should
hardly be a surprise that if hosts automatically configure themselves
to a wireless network ("zero configuration", remember?) that this
would create commmunications paths that could be used for attacks, 
no matter what means was used to allocate IP addresses for those hosts.
automatic L2 configuration is possible for 802.11, and some consider 
it advantageous.

For this specific problem the fix may be as simple as saying "don't 
automatically run LL on any wireless interface that's not explicitly
configured" - which I hope would not cause either the WG or vendors
much grief.  I think there would still be a need for a way to disable
LL on a host or network, for other reasons mentioned in the review.

Keith

---

From: Erik Guttman <[email-masked]>
Date: Tue, 24 Sep 2002 16:18:19 +0200 (CEST)

Working group members, esteemed IESG members,

I want to point out that this (late) review is the second such
response to an IETF last call.  Indeed, the only reason for the
second last call is the difficult long process in responsing to 
Keith's previous set of issues.

It is also important to note that this protocol has been widely
deployed for some time and the document has received wide and
extensive peer review.

In summary of the points I make below, I argue that Keith has a number
of points where he disagrees with the output of the ZEROCONF WG.  This
is acceptable, as the criteria for advancing a specification on the 
standards track is rough consenses not total agreement.  None of
Keith's points, whether newly made in this set of comments, or 
repeated from his previous last call comments, merit holding the
specification back from being advanced.

I apologize for the length of this response.  I wanted to be 
entirely clear that I no point Keith brings up is neglected.
I omit details of Keith's comments when my response covers an 
entire section.

I strongly urge the IESG to proceed to ballot upon the v4LL
and to advance the specification as it currently reads.

------------------------------------------------------------------
With all due respect, I consider Keith's points to either 

(a) be unsubstantive 
(b) cover ground which has been covered before
(c) pose unreasonable requirements to place on a standards track
    protocol where the burden of proof is never to prove that no 
    harm could be done
(d) be repudiated by experience with Appletalk and Netbios
(e) be repudiated by experience with v4 LL autoconfiguration since 1998
(f) (and in several cases) incorrectly state, exaggerate or mistakenly
    assert features of the protocol

I elide text which is not substantive (introduction or exposition).

>    This proposal subtly changes the behavior of the Internet Protocol.

This is true.  There are rules for how datagrams are sent and received
which differ from established practice and standards.

>    Whereas for most 

This is an unreasonable requirement.

Link local IP is on by default in a significant percentage of internet
hosts and has not proven disruptive.

- - - - - - -

Keith's outline of issues follows.  The outline of my responses
is interjected.

[...]
>      during both negotiation and use,

This question has been debated at length in the WG and is therefore
inappropriate in the WG last call.

>      visible in some contexts,

This question was brought up in the previous last call and we have
WG consenses that there are sufficient caveats in the document in
response to the risks.  It is clear Keith disagrees, but this is a
rehashing of the same issue which is settled, as far as the
working group is concerned.

>      degree even beyond those associated with "private" IPv4

This is true, but all these aspects are dealt with clearly in the 
specification.

>    - Can use of LL be avoided if it is found to cause problems?

The specification considers how to use LL not how to avoid it.

>      networks, hosts, or applications?

No.

>      cause problems for networks, hosts, or applications?
 
They may.  This is acceptable.  

These issues are considered at length in the specification, along with
warnings and limitations to applicability statement. This is not
acknowledged in any way in Keith's remarks.

[...]

>    a pre-standard version of this technology.  
[...] 
>    IETF v4 LL standard soon after it is adopted and for the next

This is the reason that a standard to guide implementation and to
arrive at common practice is so important.
 
>    either the network operators or the users taking any action 

Right.  Network operators should at least know what the protocol is
that is running on their networks.  This is another reason why a
standard for this protocol is vital.
 
>    disabled by either a host or a network.  

This is an *inappropriate comment.*

This was discussed at length in the WG and the WG consensus supports
this decision.  This point was discussed in the preceding IETF last
call.  Keith is pointing out that he does not concur with WG consensus
on this point, as he has before.

>    address per minute per host)

This is an insignificant amount of traffic even with many hosts on
a low bandwidth shared access network.  One must consider that there
is a large amount of ARP traffic on networks with fixed addresses
already.

>    disabling it should it be found to have an adverse effect.

This is *not a substantive statement.*  Any new protocol introduced
to the network is 'imposed' upon existing hosts in the same way.

Existing hosts which do not care about the new protocol will ignore
it except in so far as it generates more traffic.  In this sense,
the above is an *incorrect statement,* as LL autoconf does not 
generate much traffic.  LL autoconf is quite similar to Appletalk,
which has been run unnoticed on many IP networks for over a decade.
 
>    under which LL traffic will appear.

Huh?

We are discussing the LL autoconf protocol, not avoiding it.  We
are not discussing alternatives.  We are discussing only if the
protocol the WG and leading members of industry have put forth
is fit for publication.

>       host on the local network.

LL autoconf uses ARP.  ARP has broadcast requests and unicast
replies.  LL autoconf broadcasts the replies.

>       power-on or bootstrap time (after a random delay).

The specification also indicates that autoconfiguration can be triggered
due to media sense, while running.  The specification does not rule out
autoconfiguration at any time subsequent to booting.

>       addresses "available all the time".

This is an implementation detail, left to vendor discretion.
 
>       that the host is operating and has access to the link.

This is not a substantive statement.  Just as a vendor has discretion
when to use DHCP and when not to, a vendor has discretion when to use
V4LL and when not to.

A host which has an interface configured using V4 LL autoconf will
answer to ARP requests, exactly as it does according to IPv4, except
that the replies are broadcast not unicast.  Only if there is a 
conflict detected, is there any further claiming.  Experince with
Appletalk shows this very rarely occurs.  

>       essentially all IP-based networks.

This is not a substantive statement.

This is little more than saying that ARP will unavoidably appear on
any network with IPv4-capable hosts.  Only during initial configuration
and in case of conflicts is there any additional protocol activity.
Both initial configuration and conflict handling are rare events.

>    b. LL addresses used as IP source or destinations
[...]

The material in this section largely restates concerns which were
brought up in the preceding IETF last call for this document.  A
new section was added to the specification which addresses these
concerns.  In particular, draft 7 states

   Use of IPv4 link-local autoconfigured addresses presents additional
   challenges to writers of applications and may result in existing
   application software failing.

This is acceptable to the (rough consensus expressed by the) WG.

>       [...] applications [...] send unicast traffic [...] to
>       specific hosts [...] only when those destinations are
>       somehow exposed [...] to that application. [...]
 
>       - from network management protocols such as SNMP

While true, this has no bearing on v4LL addressing.  In each
case the destination configured could be v4LL address.

>       addresses to some degree. 

This is only marginally true.  Service discovery and naming protocols
which use LL addresses will operate peer to peer, which is to say,
the operator will have very little control over whether they are 
used.  Appletalk and especially netbios are examples of this.

>       addresses and generate LL traffic without being explicitly

This point was made in the preceding IETF last call comments.

Applications which are sensitive to these problems may break.  New
versions of these applications which follow recommendations from
section 7 of the specification may do better.  These recommendations
include application awareness of v4 LL addresses to counter the
problems Keith considers above.

>       to vary considerably from one network to the next.

This is correct.  The ZEROCONF WG (rough) consensus is that this is 
acceptable.  

The rhetorical emphasis of the statement (eschew, accidentally, etc)
indicate that the author considers the protocol to be undesirable and
unavoidable.  If this were the case, there would be great concern over
the use of Netbios on LANs, which has most of the same functions Keith
describes (local and dynamic name to address resolution, entirely beyond
an operator's ability to control or avoid).  This concern does not exist.

>      for networks that are nearly saturated.

This is argument fails to introduce material not previously covered
by the previous last call.  It is also a very weak argument.

First, theoretically, because normal operation, outside of initial
configuration, does not increase traffic at all.  The only increase in
activity, from a host perspective, is in that V4LL address ARP replies
are broadcast instead of unicast.  

Second, this has not proven disruptive on existing appletalk networks. 

Third, the only case where one sees a substantial amount of broadcast
ARP replies or lengthy and inconclusive claim and defend cycles is when
the limit of O(10^3) is approached.  The specification clearly warns
that this is the scaling limit of the protocol, after which operators
should arrange links differntly. 

Last, the WG has extensively reviewed this result and (rough)  consensus
strongly supports it.

>       as long as the additional traffic does not cause the network to

This statement disagrees with the consensus of the WG.  Network
availability, reliability and stability are radically improved for hosts
using v4LL as they can operate in environments where IP hosts fail
otherwise.  For example, in the presense of improperly configured DHCP
servers, or the absense of configuration and knowledgeable operators.

>       reasonably-sized network.

This traffic is negligible and acceptable within the domain of 
applicability of the protocol.  See Section 1.2.

>       broadcast instead of link-layer unicast (draft spec, bottom page 11).

This has not proven the case so far, where the protocol has been used.
It is not required that a protocol prove that it will not break any
existing code to advance to proposed standard.

>       which operate with less margin in CPU cycles. 

How significant are these effects?

Normally, ARP requests are broadcasts, while ARP replies are unicast.
Networks with thousands of hosts produce more broadcast ARP requests
than a v4LL network could produce (given the protocol), and yet on such
networks, ARP has not been identified as a limit to scalability.  The
point is v4LL adds 50% more broadcast messages to ARP exchanges, which
are infrequent.

Since no one seriously suggests that ARP is inappropriate on a
network with > 2600 hosts, it is not a reasonable argument that 
v4LL is inappropriate on a network with < 1300 hosts.

This argument explores only the limit cases, which is beside the point.

This protocol is used on networks with a handful of hosts: homes,
small offices, conference rooms, ad hoc networks.  In these cases, the
overhead of the protocol is modest.  In cases where there are many
hosts, additional overhead exists, but is acceptable, as per prior
discussion and consensus actions in the ZEROCONF WG. (Note that
equivalent comments arose during the previous IETF last call for this
document and were not accepted by the WG then.)

>    for LL traffic than for traffic between routable unicast addresses.

Why not?  Why shouldn't an incremental cost be acceptable?
The incremental cost is extremely modest, as has been argued.

>    performance may be adversely impacted.

  7. Application Programming Considerations

     Use of IPv4 link-local autoconfigured addresses presents additional
     challenges to writers of applications and may result in existing
     application software failing.

>    than layer 3 addresses, even if they are monitoring layer 3 traffic.

This protocol does not facilitate traffic monitoring.  This is fine.

>    for routable addresses (e.g. when DHCP and DNS are coordinated).

Yes.  Section 2.9:

   As link-local addresses may change at any time and have limited
   scope, storing link-local addresses in the DNS is not well
   understood and it is NOT RECOMMENDED.

> [...]
>    LL addresses become visible to apps [...] will then be used

This point was raised in the preceding IETF last call.  Section 7.2
of the document was added.  WG (rough) consensus supports the current
text (warning and admonishing the implementor to consider these
issues).

These issues arise with all scoped addresses.
 
>    c. address stability effect on connection duration

These issues are well documented in the v4LL specification, as well
as a thorough discussion of application implications in section 7.
These identical points were raised in the preceding IETF last call.
(Rough) WG consenss supports the current text.
 
>       purely "accidental" communications paths to be established,

I leave aside the wireless aspect of the comment, because I believe
it exacerbates the issue, but is not fundamental to it.

Configuration of IP has been so difficult for IP that it either
required manual address configuration or DHCP.  This has no longer
been true since 98.  A Windows system using v4LL and Netbios allows
communication without configuration (except of some names on the
host).  Similarly, Appletalk has allowed hosts without configuration
to communicate.

In neither case is this communication 'accidental.'  Applications
communicate using established protocols, users locate resources
by name and type.  The fact that the addresses they use are 
established automatically is unimportant.  

The question is whether use of v4LL addresses constitutes a 'different
path' than use of configured addresses.  The answer is no.

>       such communications).  

This is again a de jure argument.  The possibility of doing this has
been true de facto for 5 years.

>       This introduces new risks for both networks

This comment is wrong in that it states there are new risks and
objectionable in that it introduces the requirement for ingress
filtering.

From a security perspective, it is important to document the risks
introduced by use of the protocol.  This has been done by the v4LL
spec.

There is no requirement to support ingress filtering in order to 
advance a protocol to proposed standard.

The domain of applicability of this protocol is an IPv4 link, which
uses ARP.  Anyone with access to a link that can listen to and 
inject ARP messages can already spoof L2 and L3 addresses.  There
is no force in the argument above that anything new has been 
introduced.  If anything is new, it is that hosts can communicate
easier, with fewer hurdles.  The IPv4 network is just as dangerous
as it was; v4LL makes it easier than ever to join it.
 
>       Consider the following example scenario:

This example has nothing specific to do with v4LL.  It illustrates the
risks of insecured wireless link layers and neighbor discovery.  The
same scenario could occur if the host used DHCP on the foreign network
or simply scavenged an address (take one which appears to be unused in
the same range as those which are being used actively.)

v4LL may facilitate illicit access but it neither allows it nor
significantly changes the fundamental risk.

>       attack a company's private network when it is connected to

This comment does not address v4LL directly and poses unreasonable
expectionations.

The only true network security is to stay off the network entirely.  
A nomadic computer can be compromised if it is manually configured
or configured using DHCP when it attaches to a new network.

>       and network-based applications.

This is true.  It is much much worse if vendor implementations vary and
there is no standards based document one can refer to and attempt to 
hold vendors accountable to.  Without a standards track document, it 
will be extremely difficult to understand what v4LL behavior is or
should be.  This is one of the main reasons why publication of the
specification as a proposed standard is urgent!

>      and applications using current measures.

Or from a users perspective, it is impossible to be prevented from
local communication by an improperly configured network.  Home users
will not be prevented from using local networking by a home gateway,
cable modem, etc.  Who is imposing on whom?

>      persistently retry operations that failed due to LL.

There is a domain of applicability for the protocol and well
specified mechanisms to cause it to fail gracefully in networks 
which excede its intended scope.

It is not reasonable to require a proof that a protocol will not
harm any conceivable network before it gets advanced to proposed
standard.

>      see traffic from LL addresses.

These objections were raised in the preceding IETF last call.  They
were met with section 7 in the current draft.  No new objections are
added by this set of last call comments.

>      creates additional security risks for networks, hosts, and

This has been shown to be false in the arguments above.
 
>      and application maintainers.

While this may be true, one could argue that IPv4 creates its own
support burdens for users netowrk and application maintainers which
are significantly alleviated through adoption of v4 LL.  This is
certainly the opinion of WG participants (from major client and
network infrastucture vendor companies) involved with this work.

>      traffic, both on the network and on hosts connected to that network.

This point was made in the last IETF last call and rejected by the WG.

>      to provide a means to disable LL traffic, both entirely and on a

Vendors are free to add this feature.  There are many vendors who
produce equipment for which any manual configuration is impossible.
It is definitely not acceptable to exclude this equipment from the
protocol's domain of applicability.
 
>      the capability to communicate with other hosts using IP.

This statement was made and rejected during extensive debate on the WG
mailing list.  Keith was in the minority (of one) during these debates.
Further, this point was included in the previous set of last call
comments and rejected by WG consensus action.

>      and from the visibility of LL addresses. 

Others disagree.

Under most circumstances, those in which v4LL is likely to be used, 
LL works just fine and not bother most common applications at all.  
Address assignment will be stable and communication, restricted to 
the LAN anyway, will function fully as the application expects.  If
there is a link local web proxy most users will not know the difference.

We accept that some applications will not work with v4LL addresses or
may work less than perfectly in some circumstances.  The user has 
choices.  She can get a new application that works better.  She can
demand better software from her vendors.  She can demand a switch to
turn link local addressing off.  Last I checked, this can be done 
using all versions of Mac OS and Windows that support v4LL.

Scoped, renumberable address awareness is required for applications to
support IPv6, in any case.

>      should be separate from enabling a wireless interface to support LL

The WG has consistently disagreed with Keith on the question of whether
v4LL should be on by default and whether it should be turned off.  

The only argumented presented above concerning the use of v4LL over
wireless links was in the security section.  I demonstrated that v4LL
exposes no new security threats over that of an unsecured link layer
using insecure neighbor discovery.

>      applications that are believed to be safe from arbitrary, anonymous

There are mechanisms to do this:  L2, L3 and L7 security.  It is
inaccurate to blame address autoconfiguration for reduced security in
networks without these mechanisms.  An attacker could easily pursue
the same vulnerabilities, and more, simply by monitoring and injecting
the right ARP messages on the unsecured link.
 
>      implications are understood and suitable countermeasures exist.

It is absolutely inappropriate to insist that a protocol not be 
advanced solely on the basis of it not being fully understood.
There has been careful security assessment of this protocol, that
has not been challenged in this set of remarks.  Further, there is
going on five years of actual deployment.  If the bar is this high,
the IETF might just as well shut down immediately.

>   reasons to deploy it.  

It is useful and it is deployed.  This is not open to debate.

>   However if deployed in the form specified in
>   the draft specification, it will break some applications,

Yes, it could.  The WG accepts this and text specifically warning
and admonishing implementors was added as a result of the previous
IESG last call.

>   invite new kinds of attack on hosts and networks, 

The comments above dispute this point.

>   and create new means of propagating viruses.

This is specious.

>   explicit or implicit requirements for Proposed Standard status.

This is clearly the case.   This email documents precisely the way
in which Keith forms the 'rough' part of ZEROCONF WG consensus. 

I would support Keith's publication of these arguments in a document,
say an Informational RFC, entitled "A Dissenting Opinion on Dynamic
Configuration of IPv4 Link-Local Addresses". 

Respectfully,

Erik
ZEROCONF WG cochair

---

From: "John C. Welch" <[email-masked]>
Date: Tue, 24 Sep 2002 14:37:37 -0400

On 09/24/2002 10:18, "Erik Guttman" <[email-masked]> wrote:

Comments from an IT/implementation use perspective, where LL addressing is a
fact of life, and dealt with rather simply, and pretty much, in support of

> hosts and has not proven disruptive.

If there is a better argument that 4+ years of LL is on, working, and hasn't
killed the internet, or anyone's network in that time, I'd be surprised.
While not a substitute for analysis, and Keith's is thorough, even if I
really think he is being unreasonable in some of his objections, (with his
requirements, we wouldn't have DHCP.), that fact that Link Local is working
and has worked with no real disruptions to non-LL traffic is something to be
heavily weighted.

> inappropriate in the WG last call.

Keith argues that LL creates traffic. So does everything that uses a
network. That is rather an obvious point, and I'm unsure as to it's
significance. Web connections, FTP, Telnet, all services that use a network,
regardless of underlying protocol. NFS creates a great deal of network
traffic when in use. If generating traffic is a bad thing, then sneakernet
is our only choice. The correct question would be, does it generate a
*harmful* amount of traffic, which is answered as "Maybe". It really depends
on the individual network's definition of harmful. In any event, it is not
the WG's place to define that for network admins. Show us the traffic
generated, we're all smart enough to decide for ourselves if it's acceptable
or not.

> The specification considers how to use LL not how to avoid it.

If you know how to use it, then avoiding it is easy enough. But again, it's
not the WG's place to define that. If that was the case, then how many other
IETF specifications list how to avoid using the protocol/new toy that the
specification refers to?

> acknowledged in any way in Keith's remarks.

I can ask the same questions of anything about the future. Will DNS cause me
problems? Well, in the future, we don't know. Will something bad happen? We
don't know. We cannot predict the future, and if someone has the protocol
for that, where's *that* working group's mailing list? In all seriousness,
as long as the current state of v4LL addressing is well documented, then it
is up to the individual network admins to decide on suitability for their
environment. No two networks will have the same answer.

> standard for this protocol is vital.

This is all the standard needs to do. For example, I don't need the FTP
standard to list every possible bad thing that can happen with FTP. That's
not what a standard does.  I need the standard to give me the information on
FTP so I can make an informed decision as an admin, and so ISV's can make
informed decisions as ISVs.

> which has been run unnoticed on many IP networks for over a decade.

Um...IPv6 is going to be 'imposed' on my network regardless of my opinions
on using it. If I never use it, then I really don't care, as long as I can
get work done. If I need to block it for some odd reason, then the standard
will give me enough information on how it works and how to use it so I can
block it in accordance with my needs. To come up with every way to avoid a
standard would bog down the IETF even more than it already is, and shove the
IETF at high speeds to a condition of uselessness. We can all agree this is
a bad thing.

> This is an implementation detail, left to vendor discretion.

It wouldn't be a used implementation for long either.

> Both initial configuration and conflict handling are rare events.

Well, any network with a Mac or a windows box running any versions of those
OS's built since 1998 is doing that now. Experience dictates that no real
problems arise in systems that ignore LL addressing.

> servers, or the absense of configuration and knowledgeable operators.

Poorly configured Ethernet hardware can cause problems, yet we accept the
risks of stupidity, and use Ethernet. I have found *far* more problems from
multimedia streams eating a network alive than I have from LL addressing,
and my colleagues in the area network management generally concur. Being
slashdotted is *far* more hazardous to your web site than two Macs using
iChat over Rendezvous.

> The incremental cost is extremely modest, as has been argued.

Um...the application's use of bandwidth should be *totally* independent of
the IP address assignment method. In fact, unless the application is
designed around networking at that layer, it shouldn't care. As well, how
will the addressing method affect the fact that an MPEG4 server eats a lot
of bandwidth?

>    application software failing.

This happened when multihoming became more common. Networked application
programmers had to learn that you can't just directly tickly en0, it may not
be the interface that will work. This happened with DHCP, when you couldn¹t
guarantee a predefined address in a config file. If the application is
written correctly, then it should have minimal, if any problems. If it isn't
then it was broken anyway, and needed fixing.

>>       addresses are not valid for the host that received

There are very few reasons for an application to statically bind to specific
interface and IP address. For those that do need that, there are well
documented ways to establish which interface and address should be bound to.

> it exacerbates the issue, but is not fundamental to it.

In any case, LL isn't *creating* a new physical layer connection. It cannot,
unless you have a computer that is building it's own circuitry on the fly.
It can only use access methods that are already there. If the security and
configuration of those access methods are poorly set up, that is not the
fault of the LL machine, and LL isn't responsible for fixing a bad network
config.

> been true de facto for 5 years.

How is LL going to generate a WEP/VPN/RADIU/KERBEROS connection? If the
device isn't equipped with a wireless card, it's not going to use wireless.
If a wireless device's MAC address isn't on the ACL for that wireless link,
LL isn't going to spoof it.

> significantly changes the fundamental risk.

As well, it would be very odd for a network admin to go through the trouble
of protecting wired access and then install an open wireless network behind
a firewall. LL has nothing to do with the humans being silly.
> or configured using DHCP when it attaches to a new network.

Indeed, that laptop could be just as exposed by a DHCP network at a trade
show. It will cause just as many problems as the LL laptop. So should we now
stop all forms of non-mannual address assignment. I can do far more damage
with a wireless packet sniffer and a big hard drive than I can trying to
pervert a LL laptop.

> specification as a proposed standard is urgent!

Those support issues apply in precisely the same way to all aspects of
computing, or indeed any device more complicated than a rock. And rocks
cause problems too, especially if flung through a laptop.

> cable modem, etc.  Who is imposing on whom?

As opposed to the last four years of LL traffic anyway? This standard is
playing catch-up to something that's in use by *millions* of devices. Don't
confuse that fact with the idea that the standard is predicting anything.
That's why we *need* a standard, so that new devices at least have the
possibility of being based on the same specifications. That *reduces*
problems. LL addressing is here to stay.

> harm any conceivable network before it gets advanced to proposed

If 200 laptops doing LL kills your network, it was about to die anyway, and
you were already having problems.

> network infrastucture vendor companies) involved with this work.

If I wanted to drop my support burden *radically*, I'd go all Mac, ban
anything but straight AppleTalk, and sleep late for the rest of my life.
Avoidance of support issues is a guideline not a requirement. If you can
make something easy to support, great. But if the benefits are clear, and
real, which they are here, then you just make sure the spec is clear, to
help mitigate support issues.

> This point was made in the last IETF last call and rejected by the WG.

That's out of scope for a standard.

> protocol's domain of applicability.

There are well over a hundred different operating environments on the
Internet today. How do you propose to create a standard way to configure all
of them?

> the IETF might just as well shut down immediately.

That is a completely, (pardon my descent into slang) bogus requirement that
is not, and has not ever been required of *any* protocol or standard. I fail
to see how LL is SO harmful, outside of personal prejudice, as to impose an
absolutely unique set of requirements on it that will de facto guarantee
that it will never get past the 'mailing list argument' stage...which I
suspect is the intent of those requirements.

> and admonishing implementors was added as a result of the previous

This applies to all new protocols. Note by 'new', I mean something that
hasn't been in use for the last four years.

> The comments above dispute this point.

You mean for a change? There's some group of l33t sk8t3r b0yz just waiting
for an LL standard to work their evil? This is just alarmist.

>>   and create new means of propagating viruses.

And more correctly, simply FUD.

john

-- 
John C. Welch
IT Manager
MIT Police
(617) 253 - 3093 work
(508) 579 - 7380 cell
(617) 253 - 8822 fax

---

From: Keith Moore <[email-masked]>
Date: Tue, 24 Sep 2002 15:59:26 -0400

okay, I want to make a few things clear:

1. I have not disputed whether there is WG consensus on the current
   document.  I suspect that there is such consensus, though I really
   haven't tried to see (for instance) whether each topic was discussed
   and consensus reached for each topic, on the mailing list.  But 
   as 2026 makes clear, WG consensus is not sufficient justification 
   to put this document on the standards track.  

   The issues I have raised are mostly about the quality of the protocol
   that is proposed in the document.   There are also a few issues about 
   the quality of the document itself and whether the document is within 
   the WG's scope.  But if it weren't for the protocol quality problems 
   I probably wouldn't be pressing on the other issues.

2. Similarly, "satisfying Keith" is not the issue.  It never has been.
   The issue is fixing the technical problems with this document.

3. Most of the delays in getting this document out the door are due to
   the working group's failure to either consider, or to adequately
   address the problems with the document.    Fixing these problems
   does not require substantial changes to either the protocol or
   the document text, nor does it break compatibility with existing
   deployed implementations.   Fixing these problems mostly requires 
   a willingness to admit that the current proposal does cause problems 
   for apps and networks and the willingness to make minimal changes 
   to address them.
   
> second last call is the difficult long process in responding to 

you make it sound like I'm the one causing the problem when it's
the WG that has failed to adequately consider those issues in the
first place.  in other words, you're trying to cast this as
a personal issue rather than a technical one - which I find highly
inappropriate.

> deployed for some time and the document has received wide and

most versions of the protocol that have been widely deployed do not
exhibit the worst flaw that the proposed specification has - which 
is that there is no way for a network to disable LL.  so using the 
wide deployment to justify the current proposal simply doesn't wash -
it makes far more sense to use the wide deployment to justify  some
of the changes I'm recommending.

> standards track is rough consensus not total agreement.  None of

I respectfully disagree.  

> >    Whereas for most 
> >    candidates for standards track we are satisfied if the protocol has no

False.  As the draft spec clearly indicates, for most of these implementations
LL is not "on" whenever DHCP is in use, and my experiments with a couple of 
these implementations indicate that (for those I've tested) LL is not "on" 
when an address is statically assigned.  Thus I suspect that LL is not
"on" by default for the vast majority of Internet hosts.

Even if it were, this misses the point.  There is no disagreement that 
many apps and networks are tolerant of LL.    The question is whether
apps and networks that aren't tolerant of LL are forced to deal with the
disruption that LL causes, or whether they can turn it off.

> inappropriate in the WG last call.

- This is an IESG last call, not a WG last call.  IESG has to make
  a determination about the quality of this protocol, and it's 
  entirely appropriate to provide input to IESG about that decision.

- Perhaps more to the point, my LC message was attempting to do analysis
  of possible problem areas.  In order to do that it has to consider
  various areas where problems _might_ occur whether or not there is 
  ultimately a conclusion that those areas do have problems.  
  So I mentioned this area of potential problems mostly to be sure that I
  was covering all of the bases, as explained in my LC message.

  WRT this problem the conclusion is that consumption of bandwidth was 
  unlikely to be significant except in marginal cases - large L2 switched
  networks, nearly-saturated networks, appliance hosts with limited CPUs.
  Whether these are significant enough by themselves to require changes
  to the protocol or to the document is up for IESG to decide - personally 
  I doubt I would think that protocol changes were necessary, though
  some additional documentation might be appropriate.

> WG consensus that there are sufficient caveats in the document in

again, WG consensus is only  one of the necessary conditions.
even if the WG has consensus on a protocol, IESG has the responsibility
to determine whether it meets the requirements for standards track,
and these comments were intended as input to those deliberations.

> This is true, but all these aspects are dealt with clearly in the 

False.  They are scarcely touched on by the specification, and in
cases where the specification does mention these issues it imposes 
unreasonable requirements on both existing and future applications.

(my previous LC comments didn't address the actual text - this is
one area where comments on the actual text are also needed)

> The specification considers how to use LL not how to avoid it.

true, but the fact that the specification essentially forces the user 
to use LL is probably it's most serious flaw.  

> They may.  This is acceptable.  

I think it's inexcusably arrogant for this WG to assume that it
has either the technical ability or the authority to determine whether 
or not the harm that LL will cause is "acceptable" for the wide variety
of applications, networks, and users that it will affect.

> acknowledged in any way in Keith's remarks.

again, the worst problem is not that LL causes problems for some apps,
hosts, or networks, it's that there's no way to turn LL off.

> arrive at common practice is so important.

It's also the reason that a standard needs to avoid causing harm.

> This is an *inappropriate comment.*

No, Erik, it's entirely appropriate.  The fact that the WG has discussed
this before is irrelevant if the WG did not fix the problem.  

Again, these comments are input to IESG deliberations, not WG deliberations.
The WG was cc'ed on these comments as a courtesy to the WG, and to allow 
the WG to respond to those comments more quickly and more directly than 
would normally be the case.
 
> is a large amount of ARP traffic on networks with fixed addresses

If you're seriously proposing that the way to "turn off" LL on a network
is to defeat the claim-defend protocol, then the document needs to say so.
and the impact needs to be analyzed.  Offhand I think (a) it's a pretty 
inefficient way of doing it, (b) the interrupt overhead might be onerous 
for some hosts, and (c) might also be onerous for some networks - 
particularly if the per-minute broadcasts were to sync up - as periodic 
broadcasts tend to do on loaded networks.

But for the present document I'll continue to claim that there's no
good way to "turn off" LL and the problems it causes.

> to the network is 'imposed' upon existing hosts in the same way.

False.  Most protocols are quite obviously optional.

I can think of few other protocol extensions that 
a) affect every application that uses IP, and 
b) insist that they always be enabled.    

> it except in so far as it generates more traffic.  

perhaps true, but "hosts" are not the only affected party.

> In this sense,
> generate much traffic.  

False.  "much" is a relative term.  I tried to explore this in sufficient
detail to see when "much" was "too much".  I agree that in most cases
LL autoconf does not generate "much" traffic, but I also was able to identify
a few corner cases where the impact could be significant.  

I believe that IESG is in a much better position to make decisions 
about whether the impact is acceptable if it understands the cases
in which the impact is likely to be significant.

> protocol the WG and leading members of industry have put forth

if avoiding the LL protocol is operationally necessary for some parties,
then whether the protocol can be avoided is a valid question for the 
technical evaluation of the protocol.  Perhaps the WG has failed to 
provide for that, but I argue that by failing to provide for that
the WG has failed to produce a protocol that meets the requirements
for standards track.

> autoconfiguration at any time subsequent to booting.

we concur on this.

> This is an implementation detail, left to vendor discretion.

it's actually a fairly important detail because it can tremendously
affect the impact on applications.

> when to use DHCP and when not to, a vendor has discretion when to use

this is not clear from the specification, especially when the specification
states that LL addresses should be available all the time.

> This is not a substantive statement.

False.  It's used to support the argument (later on) that the 
claim-defend protocol can cause harm in corner cases.  If the claim-
defend protocol could be avoided, then the harm that it occasionally
does could also be avoided, and that protocol would not impose the 
same burden on hosts and networks that this one does.

> any network with IPv4-capable hosts.  

The only substantive difference is in the frequency of broadcasts,
as my comments took pains to point out.  Still there are cases where
this will make a difference.  I've seen a sane IP stack melt down 
when connected to a network with lots of broadcast packets, because
its network drivers imposed too much overhead.  so I know it can happen.

> This is acceptable to the (rough consensus expressed by the) WG.

Whether it is acceptable for PS status is a separate question.

> While true, this has no bearing on v4LL addressing.  

False.  the exposure of v4LL addresses to applications that quite
reasonably expect well-behaved (stable, global, and/or routable) v4 
addresses will cause problems for those applications.  the point 
of this section is to illustrate that e.g. merely not exposing them 
in DNS is not sufficient to prevent those addresses from causing 
problems.

> used.  Appletalk and especially netbios are examples of this.

I said "some" sources were controllable.  certainly not all of them are,
which was the very point I was trying to make.

> This point was made in the preceding IETF last call comments.

Indeed.  I'm repeating this and other points in the hope of making them
clearer than last time - on the assumption (and also based on some feedback)
that my previous comments were unclear.

> >       or applications from LL merely by eschewing use of LL addresses 

Again, it's not within the purview of this WG to determine what is
acceptable for all applications, hosts, or networks that use IP.

> unavoidable.  

you're reading too much into this.  actually I believe the protocol to 
be highly desirable - *provided* that (a) it doesn't ultimately compromise 
the flexibility of the network to support existing kinds of applications
(granted that the applications may need some tweaking) and (b) reasonable 
measures are taken to minimize harm to existing apps, hosts, and networks
(which is why there needs to be a way to disable it).

I don't think either of these is unreasonable or requires substantial
changes to what is being proposed. but I'm extremely frustrated with this
WG's refusal to fix these problems and its willingness to say (in effect)
"screw the existing apps... LL works fine on my laptop".

> If this were the case, there would be great concern over

Netbios is not IP, and applications written to expect IP behavior are
not generally affected by Netbios.

> by the previous last call.  It is also a very weak argument.

The discussion of this case is included only for completeness, so that 
all of the cases are covered.  The introduction to my comments made 
this clear.

Indeed these comments were not written as "arguments against LL".
They were written as "what kinds of problems can LL cause?".
the idea is to clearly identify the problems so that the fixes
become apparent, not to defeat adoption of LL.

> >    b. network availability / reliability / stability
> > 
> otherwise.  For example, in the presence of improperly configured DHCP
> servers, or the absence of configuration and knowledgeable operators.

Agreed that LL _can_ increase _effective_ network availability in some 
cases where the failure of a DHCP server could cause an app to fail that
might work in the presence of LL.  But this particular section is about 
the effect of bandwidth consumption, and in general these comments are 
about the harm that can be caused to existing functionality.  It is of 
course the case that LL provides new functionality, including in some 
cases the ability to use networks when DHCP etc. is down or not present.

I do not think it's axiomatically appropriate to "trade off" existing 
functionality for new functionality, especially not without a clear 
understanding of what existing functionality is being compromised.

> applicability of the protocol.  See Section 1.2.

agreed, and that's pretty much what you're expected to conclude from
reading this section.

> existing code to advance to proposed standard.

perhaps not explicitly, but surely operational concerns are worthy of
consideration?  and IIRC it's not clear from the spec whether existing
implementations use broadcast for LL ARP replies in all cases (as opposed
to just claim-defend).

> How significant are these effects?

IMHO, not very, in most cases.  which is why I said "this seems 
unlikely to significantly affect...".

however I have seen hosts affected by large #s of broadcasts on an
Ethernet, and most of those broadcasts were ARPs.  so I know that it
_can_ happen.

> This argument explores only the limit cases, which is beside the point.

the limit cases are not beside the point - they are the only thing
that give you an idea of whether the design decision is reasonable.
that doesn't mean the limit cases should all be accommodated - but
unless you take the time to understand which cases could cause 
problems you have no reason to have confidence that the protocol 
will not cause problems.

> overhead of the protocol is modest.  

this protocol, as currently defined, will be used (whether it is wanted
or not) in essentially every IP network in existence.  whether the
overhead is modest in small networks is irrelevant if the overhead
causes problems for large networks.

> The incremental cost is extremely modest, as has been argued.

perhaps my wording is unclear here - what I meant is that I don't 
expect the additional resources consumed by LL traffic to impact
applications.

>      application software failing.

merely mentioning that LL may cause problems for apps does not automatically 
make the document meet the requirements for proposed standard.

surely it's appropriate to at least attempt to minimize those problems?

> This protocol does not facilitate traffic monitoring.  This is fine.

again, (a) I'm trying to examine a wide variety of possible impacts
for LL, and (b) it's not within the purview or expertise of this WG
to determine what is "fine" for operations of others' networks.

>    understood and it is NOT RECOMMENDED.

the point of this comment is that LL impairs existing network monitoring
functionality.  there is increased difficulty in monitoring network traffic 
between routable addresses, compared with monitoring LL network traffic.
one way in which the difficulty is increases is that existing techniques 
of associating traffic with host names (e.g. looking up the L3 address 
in DNS) no longer work.

this is one of many reasons that a network might want to disallow LL traffic.

> These issues arise with all scoped addresses.

again, I don't think it's appropriate for the zeroconf WG to impose
constraints on all present and future applications running on all 
IP networks.  the zeroconf WG lacks the necessary breadth and expertise
(not to mention charter) to make such decisions.

and yes, these issues do arise with scoped addresses (and I'm working
on a draft about that) - but the fact that the problems exist elsewhere 
and for other reasons is not a justification for this WG to exacerbate 
those problems.

> >    a. address scope problems with multiple interfaces
> (Rough) WG consensus supports the current text.

again, if WG consensus is that it's okay to cause harm to current
apps, then I hope IESG has the good sense to tell the WG that it's wrong.

> it exacerbates the issue, but is not fundamental to it.

the difference is that plugging in a wire requires an explicit act
on the part of a user - if the user wants to avoid connecting to a
network for fear of security problems he can avoid plugging in the wire.
with a wireless network the connection can potentially exist even
though the user has taken no explicit action at all.

> host).  Similarly, Appletalk has allowed hosts without configuration

yes, but the vast majority of existing IP networks use either manual 
address configuration or DHCP (or a combination of both) and so the
experience "since 98" of the impact on production networks is 
actually fairly minimal.

> established automatically is unimportant.  

here's the thing - if there was previously a barrier that prevented
accidental communication between hosts, and that barrier is removed
by the introduction of LL, then LL may expose a security hole even
though that hole is incidental to LL.  

the point is that sometimes these barriers are useful, or even
necessary, and LL should not insist that these barriers be removed
as a matter of standards compliance.

> path' than use of configured addresses.  The answer is no.

it would be more correct to say that introduction of LL may remove a 
barrier that previously existed to use of paths that previously existed.  

> been true de facto for 5 years.

false, because for most deployed implementations the LL will have been
disabled as a consequence of normal network operations.

> advance a protocol to proposed standard.

the point is that existing networks rely on ingress filtering
for security (for better or worse).  bypassing this filtering creates
an operational concern, which IMHO is appropriate for IESG to consider.

> easier, with fewer hurdles.  

yes but those hurdles were at least occasionally useful from a security
perspective.

[security example omitted]
 
> This example has nothing specific to do with v4LL.  

LL removes one barrier to an attacker exploiting the wireless channel -
with LL the laptop can connect to the wireless channel whether or not
it is explicitly configured to do so.  At least with DHCP you can usually
turn it off.

> significantly changes the fundamental risk.

I think it does significantly change the risk, precisely by 'facilitating
illicit access'.

> This comment does not address v4LL directly and poses unreasonable

again, the point is that LL allows the laptop to connect to networks
completely without the user's knowledge or approval.  this is probably
not desirable.

> hold vendors accountable to.  

well, in this case, most of the existing implementations seem to be 
better (in the sense that they have less impact on existing managed
networks) than the standard.  so while in general I think standardization
is a Good Thing, it's not axiomatic that a poor standard is better
than current practice.

> Without a standards track document, it 

don't you think it's appropriate to understand what v4LL behavior 
"should be" in order to minimize impact _before_ publishing it?

hurried publication of a flawed standard can do more harm than good.

> cable modem, etc.  Who is imposing on whom?

Home users are not prevented from using local networking in any case.
But it's not axiomatic that having hosts talk to each other without
any configuration or approval is better than requiring that configuration
or approval.

> which exceed its intended scope.

where are those well-specified mechanisms?  I don't see them.

> harm any conceivable network before it gets advanced to proposed

strongly disagree.  it's quite reasonable for new standards to avoid 
breaking existing standards.  what's unreasonable - no, downright
irresponsible - is for a single WG to assume that it has the authority 
or the expertise to decide when it's okay to break existing standards 
or applications, without even bothering to do an analysis so that it 
could understand what is being broken!

> This has been shown to be false in the arguments above.

false.

> support burdens for users network and application maintainers which
> network infrastructure vendor companies) involved with this work.

IPv4 certainly does have support burdens.  but LL doesn't alleviate 
them; it increases the number of cases that have to be dealt with. 

> This point was made in the last IETF last call and rejected by the WG.

we agree that the WG has spoken.  this is input to IESG.

> protocol's domain of applicability.

first, the spec is not clear that vendors are free to add this
feature, and it implies the opposite.

second, the feature is operationally necessary for some networks.

third, manual configuration is not the only means by which LL can
be disabled even on a per-interface basis.  (it should be sufficient 
to control it from the network with that granularity)

> comments and rejected by WG consensus action.

again, this is not for the WG to decide.

> >      and from the visibility of LL addresses. 

perhaps they don't know what they're talking about.  

I tend to disregard arguments of the form "the apps on my laptop 
work just fine" when I work daily with apps that will be affected
by this.

> Under most circumstances, those in which v4LL is likely to be used, 

as currently defined, v4LL is likely to be used on all networks,
whether the users or network admins want it or not.

> LL works just fine and not bother most common applications at all.  

it's not sufficient for LL to work for "most common applications"
those are the wrong criteria.  

> the LAN anyway, will function fully as the application expects.  

false.

> If there is a link local web proxy most users will not know the difference.

there are a lot more applications out there than the web.

> using all versions of Mac OS and Windows that support v4LL.

since it's obviously necessary, why not require it as part of the 
standard?  

> support IPv6, in any case.

that's a separate problem that needs to be solved elsewhere.  the existence 
of a problem with v6 is not a justification for introducing a problem to v4 -
especially to existing apps that aren't written with v6 in mind.

> v4LL should be on by default and whether it should be turned off.  

the WG has consistently disregarded the impact of its proposals on existing
apps and networks.  it's entirely possible that the WG is wrong.  

> using insecure neighbor discovery.

actually you demonstrated that it does introduce new security threats, by
removing barriers to communication that were previously there and
which in many cases were previously relied on to provide security.
 
> networks without these mechanisms.  

so you create a problem and then claim that it's somebody else's problem...

> advanced solely on the basis of it not being fully understood.

we *know* this protocol will do harm, and you're insisting that it 
be standardized anyway, in clear violation of both the spirit and
the letter of 2026.  

> going on five years of actual deployment.  

existing deployment is irrelevant as it is not of the same protocol 
that is being proposed here.

> and admonishing implementors was added as a result of the previous

this is not for the WG to "accept" and impose on users.

> The comments above dispute this point.

no, they validate it.

Keith

---

From: "Philip Nye" <[email-masked]>
Date: Tue, 24 Sep 2002 23:25:01 +0100

While it is late in the day, I want to back up Keith's concerns here.

There is big difference between the major commonly deployed LL implementations
and the current proposal in that those implementations use an "either/or"
approach while the current proposal mandates "as well". While these issues
have indeed been recirculated ad-nauseam by Keith, I have seen little in the
way of hard technical counters to his arguments and justification for the
requirement in the draft seems weak. In the light of this difference the
argument that LL "protocol has been widely deployed for some time" is almost
entirely spurious yet that seems to be the main thrust of the argument.

At the very least the difference means that LL traffic is likely to appear all
sorts of places where it has previously been absent because hosts were
configured with alternatives.

regards,
Philip Nye

---

From: "John C. Welch" <[email-masked]>
Date: Tue, 24 Sep 2002 22:41:30 -0400

> configured with alternatives.

While I will definitely agree that we have not seen this *type* of LL
deployment before, that is the only change. LL traffic is not new, neither
are ARP broadcasts. In fact, not much with this spec is *new* in the sense
of "Not ever seen before", but rather "Never been implemented like this
before".

Rather than making things harder to troubleshoot, I say it will make things
easier, because you don't have as much new info to learn. It's rather like
going from a '68 Beetle to a 2003 Beetle, as opposed to going from a '68
Beetle to a Boeing 777.

The security/virus arguments are just FUD, and belong in dev/null. LL
introduces nothing new in this arena.

john

-- 
John C. Welch
IT Manager
MIT Police
(617) 253 - 3093 work
(508) 579 - 7380 cell
(617) 253 - 8822 fax

---

From: Erik Guttman <[email-masked]>
Date: Wed, 25 Sep 2002 11:51:41 +0200 (MEST)

Keith,

Thank you for clarifying your position.  I believe the matter is now
in the hands of the IESG who have to make a decision about advancing
the draft or not.  Your position is clearly that of the 'rough' part
of the consensus.

I reply only to a few of the points below.

>    address the problems with the document.

As WG chair, and now coauthor of this document I accept a large part of
the blame for the delays.  I should have pushed for 'rough consensus'
earlier.  The debate we are reiterating will not change the outcome.

> a personal issue rather than a technical one - which I find highly

The process by which disagreements are supposed to be resolved is the
last call. It is to your credit that you worked long and diligently,
despite opposition to see the specification improved.  And it has
substantially improved due to your input. 

That said, it is unfortunate that you did not bring up these issues
during the WG last call on the changes which were intended to answer
your objections in the first IETF last call!

> "on" by default for the vast majority of Internet hosts.

Many environments lack DHCP.  LL is on by default in this case in
most PCs and Macs today. In the case where addresses assigned are used
instead of LL addresses, this does not invalidate the point that LL is
on by default.  
 
> to use LL is probably it's most serious flaw.  

No host is forced to use LL.  Today, no one *is able to communicate
with* an unconfigured host.  Hosts that do not support LL will be in 
the same position as they are in today.

> good way to "turn off" LL and the problems it causes.

You are right. There is no way to "turn off" LL.  This is not part of
the protocol.  The WG input to the IESG does not have this feature.

> b) insist that they always be enabled.    

No one is proposing that this protocol be anything other than an
elective standard.

> technical evaluation of the protocol.

We have yet to hear that this is an issue from network operators,
except for one case:  a university which wanted to prevent students
from using LANs without first registering their equipment.  This
led to RFC 2563 "DHCP Option to Disable Stateless Auto-Configuration
in IPv4 Clients"  This standard has not yet been implemented, but if
customers demanded it, I am sure vendors would support it.

> states that LL addresses should be available all the time.

The specification does not mandate *use* of LL, when a host 
supports it.  Nor does it state when a host can or cannot stop 
using LL autoconfiguration.  The specification simply describes
how the protocol works, *when* it is used.

On this point the spec says only

   This document describes a method by which a host may
                                                    ^^^
   automatically configure an interface with an IPv4 address in the
   169.254/16 prefix that is valid for link-local communication on that
   interface.

and

   This document describes a method by which a host may automatically
                                                    ^^^
   configure an interface with an IPv4 address in the 169.254/16 prefix
   that is valid for link-local communication on that interface. 

and

   in previous
   implementations, link-local addresses were only available after a
   host had tried and failed to contact a DHCP server. This standard
   removes that restriction, making link-local addresses available all
   ^^^^^^^^^^^^^^^^^^^^^^^^
   the time, independent of DHCP.

> problems you have no reason to have confidence that the protocol 

We have explored the limit cases in the WG.  Your contribution to the 
IESG will help them to assess whether or not we have done a good job.
 
> as a matter of standards compliance.

The vulnerabilities exposed by LL should be fixed.  LL exposes but does
not cause these problems.  Further, LL is unable to solve these problems
since it uses ARP.  There are workable L2 solutions for securing ARP.

> where are those well-specified mechanisms?  I don't see them.

   When a host wishes to configure a link-local address, it selects
   an address using a pseudo-random number generator
   ...
   After it has selected an address, a host MUST test to see if the
   address is already in use before beginning to use it. On a network
   such as Ethernet that supports ARP, this test is done using ARP
   probes.
   ...
   When ready to begin probing, the host should then wait for a
   random time interval selected uniformly in the range zero to two
   seconds, and should then send four probe packets, spaced two
   seconds apart. This initial random delay helps ensure that a
   large number of hosts powered on at the same time do not all send
   their initial probe packets simultaneously.
   ...
   A host should maintain a counter of the number of address collisions
   it has experienced in the process of trying to acquire an address,
   and if the number of collisions exceeds ten then the host MUST limit
   the rate at which it probes for new addresses to no more than one new
   address per minute. This is to prevent catastrophic ARP storms in
   pathological failure cases ...
 
> could understand what is being broken!

Scoped addresses and address renumbering exists.  LL exposes this.
The document describes the issues and remedies in Section 7.

> apps and networks.  it's entirely possible that the WG is wrong.  

This remark is unjustified.  Your input resulted in section 7
and a complete rewrite of the security section - which is now
mostly text you wrote as input, verbatim.  The WG has not followed
*all* your suggestions, however.

Erik

---

From: Keith Moore <[email-masked]>
Date: Wed, 25 Sep 2002 09:45:01 -0400

> earlier.  The debate we are reiterating will not change the outcome.

well, respectfully, I hope it does change the document that is approved.

Frankly I think it usually works better (in general, perhaps not in this
case) to try to address substantive technical disagreements before going 
to IESG - even if it's an disagreement between one and the many.  But 
clearly there's a point of diminishing returns at which the WG should say
"here's the document we have near/rough consensus on, and there's also
this disagreement that we were unable to resolve, we'll let that party 
tell you about it".  And perhaps it would speed things up to work that way.

> your objections in the first IETF last call!

Agreed.  I was swamped due to having to meet deadlines.

> instead of LL addresses, this does not invalidate the point that LL is

I'll concede that point, though I'll note that "on by default" does not 
mean "on in most existing networks that are connected to the internet"
and I'll continue to maintain that the experience with the existing LL
is not a good indicator of how the draft specification would affect
applications or networks.

> No host is forced to use LL.  

well, no.  not if you leave the host turned off, or if you don't run
the OS on the host that you need to use to run the applications that
you are required to use, you're not forced to use LL.  but the bottom 
line is most hosts will end up using LL without any choice being made 
to enable it (that choice being forced by the choice of OS), and (as 
I read the draft specification) without any way to disable it.

> Today, no one *is able to communicate
> with* an unconfigured host.  

true, but sometimes this is an advantage, and it's not a huge deal to 
configure the host.  granted that LL could be an immense benefit to
unsophisticated users _who choose_ to allow their hosts to communicate
with other hosts - it would let them do so without having to allocate
and specify an address, netmask, etc.    but I don't think it's a good
idea for that choice to be made simply by using an OS (often there
is no choice in that matter) that happens to implement LL.

> Hosts that do not support LL will be in 

not quite true, because there are some impacts on such hosts, as I
outlined earlier.

> No one is proposing that this protocol be anything other than an

no, but if an implementor does "elect" to include LL, it will 
cause problems for apps and networks.  it's easier and more beneficial
to "fix" LL to minimize those problems (e.g. by providing ways to turn
it off as a matter of standards compliance) than to "fix" LL by not 
including it in a product.  the latter is just too coarse-grained a 
knob to be useful. 

> from using LANs without first registering their equipment.  

like most WGs, I doubt this WG is terribly visible outside of IETF, 
especially to network operators - or for that matter, to authors of
distributed computing software like myself.

> This

Why not at least refer to it in this document?  For that matter, why
is this WG so reluctant to give users and network operators the ability 
to minimize the harm that LL will cause?   Why wait for customers to
experience the problems which analysis indicates _will_ exist and
force them to wait months for vendors to provide ways to resolve them?

> supports it.  

I'll go through the spec and identify the places that seem to imply that
LL is used "all the time" and send those in a separate message.

> since it uses ARP.  There are workable L2 solutions for securing ARP.

I think this is missing the point.  LL exposes vulnerabilities other
than those which exist with ARP.

>    pathological failure cases ...

I don't think it's reasonable to cite these as a mechanism for disabling
LL, at least not with the current text which doesn't mention even 
mention the potential to use this to disable LL and which implies that
this scenario is a pathological failure case rather than something that
might reasonably be used in normal operation.  I also doubt that it's 
technically reasonable to "disable" LL in a way that causes each host to 
ARP once a minute, particularly when there is no specified mechanism to 
keep those ARPs from synchronizing. 

> Scoped addresses and address renumbering exists.  

strictly speaking, as a matter of standards, scoped addresses do not exist 
in IPv4 except on isolated networks, where scope isn't an issue anyway.
use of private addresses by NATs violates not only IP but also RFC 1918.
even when such addresses are used as scoped addresses, this is generally
an explicit choice - not something that is forced on hosts and applications
everywhere on the net without anyone's knowledge.  

addess renumbering currently exists on networks as a managed event, not
something that happens at random without notice and without the potential
for consideration of its effects on applications.

there are ISPs that impose NAT on their customers and there are ISPs that
force their customers to renumber frequently.  one hopes those customers
have the ability to choose other ISPs.  the fact that some ISPs can
cause problems for their customers is not a justification for zeroconf
causing problems for IP users.

> LL exposes this.

I need to separately address section 7 also - some of the suggested
remedies are onerous.

Keith

---

From: "John C. Welch" <[email-masked]>
Date: Wed, 25 Sep 2002 10:26:48 -0400

> including it in a product.  the latter is just too coarse-grained a

The problem is, that now the standard is specifying Implementation
techniques. This is of course way out of scope for a standard, because what
environments do you include? Well, to be a standard, all of them. And as we
all know, there is no such thing as a standard implementation of anything
across platforms. The only realistic choice, and the only one that won't be
ignored by vendors *anyway* is to give all the information about LL in the
standard, so that *if* a vendor has a need to add an 'off' switch, they can.
It is not the IETF's place to tell anyone how to implement. It is their
place to make the standard as simple and clean as possible so that
implementations can be simple and clean. If you have too convoluted of a
standard, (which adding in howto's on avoiding the standard will guarantee)
then you won't ever get a decent implementation.

> distributed computing software like myself.

Um...maybe not to programmers, but the IT community is *very* interested in
ZeroConf. We are the ones who are going to support it and deal with the
implementations that arise from these standards. In fact, you'll find most
IT managers quite conversant with IETF standards, as they are a great
troubleshooting tool. Perhaps if more authors of networked applications were
more conversant with the IETF, then things wouldn't break so much.

> force them to wait months for vendors to provide ways to resolve them?

Because again, you cannot tell a vendor *how* to implement a standard. You
simply cannot allow for all the variations that exist. You can only give
them the 'what' and the 'why'. The 'how' and the 'when' aren't the domain of
the IETF, and any attempts by the IETF to change that will be ignored
anyway. Besides, if a vendor's work is breaking a network, and they take
months to fix it, they won't be a vendor for long.

> than those which exist with ARP.

Exposes. Not creates. Exposes. *If* LL *created* vulnerabilities, then you'd
have an excellent point. But *any* new use of a network is going to show up
holes that you didn't know/think about before. NFS, LPR, FTP, etc, they've
all done this. You'll note that BugTraq doesn't have messages about a
standard being buggy. Standards don't create bugs. Hardware and software
create bugs. Standards are not a lockstep development howto. They're a guide
that tells you how your implementation should behave when in use.

> keep those ARPs from synchronizing.

If you are going to require specific disabling techniques, then we need
specific techniques to re-enable it. That's only logical here. In fact, if
we do this here, then from now on *every* IETF standard needs to include
this information, and it would be a good idea to retrofit existing standards
too. FTP is a horrible security hole, why doesn't the standard tell me how
to disable it. The same for telnet. Let's stop doing anything at all until
instead of a standard, the IETF is now creating API's for all platforms.
Why, that would give the world decades to adjust to a new standard, because
that's about how long it would take. The argument over languages to support
alone would be a good five years of flame wars.

Yes, the IETF should take implementation in to account when creating a
standard. They should think about the effort required to implement a
standard, and if reasonable analysis shows that the implementation will be
more difficult than it needs to be, perhaps simplify the standard to deal
with this. But when the standard starts telling a vendor *how* to do
something, it is instantly irrelevant.

john

-- 
John C. Welch
IT Manager
MIT Police
(617) 253 - 3093 work
(508) 579 - 7380 cell
(617) 253 - 8822 fax

---

From: Erik Guttman <[email-masked]>
Date: Wed, 25 Sep 2002 16:27:19 +0200 (MEST)

On Wed, 25 Sep 2002, Keith Moore wrote:

>>{section 2.1 and 2.2 text}
>>
> LL, 

This text is not about disabling the protocol.  The citation is my
response to your assertion that there are no mechanisms to ensure that
the protocol will fail gracefully in networks which exceed the intended
scope. 

Best regards,

Erik

---

From: "Jim Fleming" <[email-masked]>
Date: Wed, 25 Sep 2002 09:37:04 -0500

From: "John C. Welch" <[email-masked]>
"It is not the IETF's place to tell anyone how to implement."
====

Most standards bodies are trailing edge. They come around after the fact and after
the marketplace has set the standard. Some people **think** they can be leading edge
and set the standard and dictate to the market what they will use. The marketplace just
routes around those dictators.

The.C@t says...
Vote Early and Often...
http://www.kvtek.com/ddnsservices.asp

128-bit DNS AAAA Record Flag Day Formats
2002:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address]
[YMDD]:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address]
1-bit to set the Reserved/Spare ("SNOOPY") bit in Fragment Offset [S]
1-bit to set the Don't Fragment (DF) bit [D]
2-bits to select 1 of 4 common TTL values (255, 128, 32, 8) [LL]
1-bit for Options Control [O]
7-bits to set the Identification Field(dst) [FFFFFFF]
4-bits to set the TOS(dst) Field [TTTT]
Default SDLL.OFFF.FFFF.TTTT = 0000.0000.0000.0000
FFF.FFFF.TTTT = GGG.SSSS.SSSS

SNOOPY = 0 on all these packets...

---

From: "John C. Welch" <[email-masked]>
Date: Wed, 25 Sep 2002 11:27:45 -0400

> routes around those dictators.

The idea with standards, IMO, is to say, "We have a lot of people using
blah. To make life easier, and avoid problems with blah, let's sit down, and
standardize how blah should work, interact with blech and yearg, etc."

Telling anyone how to implement a standard is a fool's errand.

john

-- 
John C. Welch
IT Manager
MIT Police
(617) 253 - 3093 work
(508) 579 - 7380 cell
(617) 253 - 8822 fax

---

From: "Jim Fleming" <[email-masked]>
Date: Wed, 25 Sep 2002 10:44:47 -0500

----- Original Message ----- 
From: "John C. Welch" <[email-masked]>
To: "Zeroconf" <[email-masked]>
Sent: Wednesday, September 25, 2002 10:27 AM
Subject: Re: "It is not the IETF's place to tell anyone how to implement."

> Telling anyone how to implement a standard is a fool's errand.

Agreed.....and most standards efforts are composed of people who really do not
care about the details of the outcome, because they have a more global common objective.
As an example, do people really care if the bit order is SDLL, or DSLL, or LLDS ?

There are only 128-bits, not 129. They can only have so many values. People writing
code just want to know what order other people writing code are using. They also of
course do not want some Innovation Extermination Task Force coming in and saying,
you can't arrange the bits that way, or all of the arrangements have changed, because we
need to fund our insiders with jobs changing the bits.

The.C@t says...
Vote Early and Often...