Subject: ZEROCONF WG Work Items

From: Erik Guttman <[email-masked]>
Date: Thu, 9 Jan 2003 14:06:44 +0100 (CET)

Folks,

We have to complete work on the IPv4 LL document.  There are a 
few outstanding issues in front of us.  Please turn your attention
to addressing the continuing IESG concerns.

  Note:  Keith has made his point, repeatedly, that due to application
  interoperability considerations there should be a way to simply and
  effectively deactiveate v4LL.  The IESG has this input.  The WG has 
  chosen not to accept Keith's argument in their submission to the
  IESG.  It is up to the the IESG to determine how to proceed.  So far,
  the IESG has not chosen to include the lack of a required mechanism to
  deactivate v4LL behavior as one of their considerations for the WG to
  address in order to advance the document.  This is why this issue 
  does not appear in the following list.

Please let's focus on bringing the following questions to conclusion.  I
strongly suggest that discussion participants SUGGEST TEXT or send
comments ON SPECIFIC TEXT.

1. What should the TTL be set to on send?  Should the TTL be
   checked on receive?

   We have been over this repeatedly.  My capsule summary of the
   debate is:
     o Existing implementations set TTL to 255 and 128
     o Some existing implementations check 255 on receive and
       discard TTL != 255
     o There is some security benefit to checking TTL=255 but
       we have not reached a consensus on what the value is
       and its importance
     o Many routers are not configured to not forward v4LL.
       Setting TTL=1 would mean these routers would not forward
       v4LL off the link.

   The current document says MUST send TTL=255, MAY reject if
   TTL != 255.  
     
2. There was a request for a list of example applications which 
   can safely be used with link-local addresses.

   I supplied the following list:  File sharing (NFS, SMB),
     Print sharing (LPD, IPP), Local file sharing & web browsing 
     (FTP, HTTP), Remote login (TELNET)

   This raised questions which I have not had the time, and lack
   enough expertise to answer:

      o Doesn't NFSv3 include addresses?  Will that cause NFSv3
        to fail?
      o Doesn't NFSv4 and IPP carry domain names?  DNS will not
        have LL entries, most likely.  Won't this cause NFSv4
        and IPP to fail?

3. Section 2.10 is not sufficiently draconian, Harald submits.
   It should list a set of protocols which will fail if a link
   local address is sent in a protocol message instead of a 
   global address.

   To discuss FTP, DNS, NFS, IPsec using IPv4 as an identifier,
   BGP, OSPF, RTP, ...

4. There is text in section 2.3 which suggests shorter time outs
   can be used for 802 media.  I suggested some new, less
   specific text which Erik Nordmark had continuing issues with.

>   The time values specified above are intended for use on
>   technologies such as Ethernet, where switches that implement
>   Spanning Tree [802.1d] often silently discard all packets for
>   several seconds. The time values specified above result in a
>   delay of 8-10 seconds before a chosen IP address may be used.
>   For a desktop machine on Ethernet,
>
>FWIW when 802.1d is enabled on the port I plug in my laptop at the
>office, the delay before the switch starts forwarding packets is 45
>seconds. (I think the 802.1d spec indicates a default time of around
>30 seconds.) So 10 seconds don't seem to do much good.

   Later, Erik sent

   If we talk about the protocol and not the text, I know of
   two interesting cases on IEEE 802 media:
    1. No spanning tree on the port to which you connect, or 
       the port has been enabled for a long time before the 
       address claim is done.  In this case it probably makes 
       sense to have slightly shorter timers i.e.  a few packets 
       over a few seconds might suffice. Thus 3 seconds instead 
       of 8.
    2. Spanning tree on the port to which you connect.
       If the address claim is done immediately after bringing up 
       the link the host might as well wait for 45 seconds before 
       sending any packet.

    I don't know if the host can tell the difference between #1 
    and #2 - or if it can "ask" (at the Ethernet layer) if the 
    switch is running STP.

    With RSTP I think the problem goes away and the approach used 
    in #1 can be used.

5. Add the following notes to the security section:

    NOTE: The existence of local links without physical security,
    such as LANs with attached wireless base stations, means that 
    expecting all local links to be secure enough that normal    
    precautions can be dispensed with is an extremely dangerous 
    practice, which will expose users to considerable risks.

6. The following text leads to a problem 

>  section 3.3
>  In addition, this kind of host should probe for, and defend, all
>  of its link-local addresses on all of its active interfaces that
>  are using link-local addresses.
>
>  When bringing up a new interface, the host SHOULD first probe
>  for all of its existing link-local addresses on that new interface.
>  If any of the addresses are found to be already in use by some
>  other host on that new link, then the interfaces in question MUST
>  be reconfigured to select new unique link-local addresses.
>
>  The host should then select a link-local address for the new 
>  interface, and probe on all of its active interfaces to verify 
>  that this new address is unique on all the links that the host 
>  has connections to.

Erik Nordmark remarked:
>  The above breaks if multiple interfaces on the host are connected
>  to the same link. It also isn't clear to me why this is needed;
>  presumably the interfaces can be managed indepdently as long as 
>  the host ensures that it doesn't assign the same link-local 
>  address to more than one interface.

7. There is a security and operational consideration regarding the
   goal of harmonizing link-local address configuration between
   links of a multi-homed host.

   In particular, if a host attempts to configure the same v4LL
   address on all interfaces, an attacker can force the host to
   reconfigure all its interfaces by usurping the address on any
   link.  This is an attack above and beyond the normal ARP based
   spoofing or DOS attacks since it effects multiple links.

   The suggested changed text for the security section follows.
   (The change bar indicates added text).

5. Security Considerations

   The use of IPv4 Link-Local Addresses may open a network host to new
   attacks. In particular, a host that previously did not have an IP
   address, and no IP stack running, was not susceptible to IP-based
   attacks. By configuring a working address, the host may now be
   vulnerable to IP-based attacks.

   The ARP protocol [RFC 826] is insecure. A malicious host may send
   fraudulent ARP packets on the network, interfering with the correct
   operation of other hosts. For example, it is easy for a host to
   answer all ARP requests with replies giving its own hardware address,
   thereby claiming ownership of every address on the network.

|  A host implementing IPv4 link-local configuration has the additional
|  vulnerability to selective reconfiguration and disruption.  It is
|  possible for an on-link attacker to issue ARP packets which would
|  cause a host to break all its connections by switching to a new
|  address.  The attacker could force the host implementing IPv4
|  link-local configuration to select certain addresses, or prevent it
|  from ever completing address selection.  This is a distinct threat
|  from that posed by fraudulent ARPs, described in the preceding
|  paragraph.

   Implementers are advised that the Internet Protocol architecture
   expects every networked device or host must implement security
   which is adequate to protect the resources to which the device
   or host has access, including the network itself, against known
   or credible threats. Even though use of link-local addresses
   may reduce the number of threats to which a device is exposed,
   implementers of devices supporting the Internet Protocol must
   not assume that a customer's local network is free from security
   risks.

   While there may be particular kinds of devices, or particular
   environments, for which the security provided by the network is
   adequate to protect the resources that are accessible by the
   device, it would be misleading to make a general statement to
   the effect that the requirement to provide security is reduced
   for devices using link-local addresses as a sole means of access.

   In all cases, whether or not link-local addresses are used, it
   is necessary for implementers of devices supporting the Internet
   Protocol to analyze the known and credible threats to which a
   specific host or device might be subjected, and to the extent
   that it is feasible, to provide security mechanisms which
   ameliorate or reduce the risks associated with such threats.

8. The applications considerations section was deemed inadeqate.

> > In the applicability section it would make sense to add explicit
> > warnings about issues for applications. One issue is the addresses
> > are of limited scope which might cause problems for multi-party
> > applications that pass IP addresses between parties.
> > The other issue is that these addresses might have much shorter and
> > unpredictable lifetime, which would have an impact on applications
> > using them on the link. (This is true especially given the
> > suggestions in section 2.5 to pick a new address when a conflict is
> > detected after the address has been used for a while.)
>
> Are Sections 7. 1 and 7.2 insufficient?

   Erik Nordmark replied
   Three issues with those:
    - They don't explicitly mention that the stability of the 
      addresses is affected by late collisions i.e. when the address 
      has been in use for a while
    - They are written as "all applications SHOULD be fixed to be 
      usable in this environment" - it is more realistic for people 
      deploying this technology to turn this around and instead issue 
      a warning that link-locals should not be used unless all 
      applications used in the network are known to not depend
      on X, Y, Z.
    - Warnings about limitations of the applicability makes sense up 
      front in the document - not towards the end.

   The document does not suggest that one use v4LL source
   addresses to communicate with v4LL destination addresses.
   There are failure modes: Send to a global multicast address
   from a v4LL address, Send to a global address from a v4LL
   address, send to a v4LL address from a global address.  In
   each case, if routers are misconfigured, the receiver will
   potentially not be able to return a message to the sender.

   This could be addressed by a requirement, for example, such
   as to send to a v4LL address one MUST send from a v4LL 
   address, and to send from a v4LL address, one MUST send to a 
   v4LL address.  This is highly restrictive and is only posted
   to spur conversation.  If we do not restrict v4LL, however,
   we must meet address scope architecture issues head on.

9. The document does not suggest that one use v4LL source
   addresses to communicate with v4LL destination addresses.
   There are failure modes: Send to a global multicast address
   from a v4LL address, Send to a global address from a v4LL
   address, send to a v4LL address from a global address.  In
   each case, if routers are misconfigured, the receiver will
   potentially not be able to return a message to the sender.

   This could be addressed by a requirement, for example, such
   as to send to a v4LL address one MUST send from a v4LL 
   address, and to send from a v4LL address, one MUST send to a 
   v4LL address.  This is highly restrictive and is only posted
   to spur conversation.  If we do not restrict v4LL, however,
   we must meet address scope architecture issues head on.

Thanks and best regards,

Erik
ZEROCONF WG cochair

---

From: "John C. Welch" <[email-masked]>
Date: Thu, 09 Jan 2003 12:50:44 -0800

>    The current document says MUST send TTL=255, MAY reject if

The current document looks like the most elegant and safe method.

>     practice, which will expose users to considerable risks.

This is very wise to include...perhaps accentuate this even more.

>    ameliorate or reduce the risks associated with such threats.

Works for me.

john 

-- 
John C. Welch
Consultant III
Administrative Computing
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 16 Jan 2003 01:16:26 +0100 (CET)

>   does not appear in the following list.

I don't claim to understand what the right thing is to do here
because I don't yet know how the WG will respond to #9 in your email.

I also haven't seen much discussion about the difference between
the link-local addresses that have been deployed for a long time
(only used when DHCP doesn't configure an address; disabled when DHCP
comes back) and what the document advocates (link-locals used in
parallel with DHCP assigned addresses on the same interface).

I think the WGs answers to the those questions influence how strong
the need is to have a knob to turn of zeroconf.

  Erik