Subject: Time to Publish draft-ietf-zeroconf-ipv4-linklocal

From: Stuart Cheshire <[email-masked]>
Date: Thu, 2 May 2002 10:14:29 -0700

Draft-ietf-zeroconf-ipv4-linklocal-05.txt is in the Internet Drafts 
directory.

This draft reflects all the changes agreed from the "Summary of Issues 
for draft-ietf-zeroconf-ipv4-linklocal-04.txt" list posted 11th November 
2001.

It also includes Section 2.3 "Shorter Timeouts on Appropriate Network 
Technologies" which was proposed 8th April. That change met with vocal 
approval from Peter van der Stok and no complaints from anyone else.

There are two other minor wording changes at Keith Moore's request.

1. Keith Moore criticised the definition of "on the same link":

>a better definition might be one that reflects the operational
>realities of the kind of address defense you describe here - if a
>link-level broadcast from node A reaches node B, or vice versa, A
>and B are on the same link.  if that's the case then you can't
>afford address collisions between A and B, and if that's not the
>case then your address defense protocol won't work anyway.

As a result, I modified the text to explicitly mention broadcast packets:

   This document describes link-local addressing, for IP communication
   between two hosts on a single link. Two hosts are considered to be
   on the same link if, when one host sends packets to the other, using
   unicast, multicast, or broadcast, the entire link-layer packet
   payload arrives unmodified. The link-layer *header* may be modified,
   such as in Token Ring Source Routing [802.5], but not the link-layer
   *payload*. In particular, if any device forwarding a packet modifies
   any part of the IP header or IP payload then the packet is no longer
   considered to be on the same link. This means that the packet may
   pass through devices such as Ethernet repeaters, bridges, hubs or
   switches and still be considered to be on the same link for the
   purpose of this document, but not through any device like an IP
   router that decrements the TTL or otherwise modifies the IP header.

2. Keith Moore requested addtional section headings:

>section 2.7:
>
>   this section should be weeded down to include only the stuff
>   that applies to routers.  portions that apply to network
>   operators (DNS configuration) should go in a separate, clearly
>   labelled, section.  portions that apply to application writers
>   should go in yet another separate, clearly labelled section.

As a result, I have created new section headings:

2.8 Devices may Assume Link-Local Packets are Local
2.9 Higher-Layer Protocol Considerations
2.10 Privacy Concerns

---

This is now, I believe, the finished document. If you think othewise,
this is your last chance to speak up and say why. (I forgot to add Keith
Moore's name to the Acknowledgements section, but that will be fixed.)

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

---

From: Robert Elz <[email-masked]>
Date: Fri, 03 May 2002 19:38:12 +1000

Date:        Thu, 2 May 2002 10:14:29 -0700
    From:        Stuart Cheshire <[email-masked]>
    Message-ID:  <[email-masked]>

  | As a result, I modified the text to explicitly mention broadcast packets:

I'm not sure that quite matches the intent - not that anything in what
you wrote is incorrect, but that the way broadcast is used to define
a link layer is somewhat simpler than that.

It used to be that a LAN was essentially a cable, and every packet passed
by every possible receiver - two nodes were on the same link if packets sent
by one would be able to be seen by the other, and not otherwise.

Hubs and repeaters were just seen as parts of the wire, they amplified
signals, allowed longer cable lengths (affected collisions on LANS where
collisions occur) and stuff - but had no effect on where packets were
transmitted.

The arrival of bridges (and later switches) changed all that - now the link
layer only sends packets to nodes that are likely to actually want to receive
them, usually, so the definition of a link layer changed.

But - the way that a link level broadcast works hasn't altered - by definition
a broadcast packet (link layer broadcast packet) gets sent to every node on
the LAN (on the link) - switches don't alter that, and can't (or half the
known protocols that use broadcast would break).   So, now a good definition
of whether two nodes are on the same link is whether a (link level) broadcast
packet transmitted by one is visible to the other (whatever its content, if
being visible depends on content, then some kind of helper is probably 
forwarding, and that doesn't count).

So, it isn't really a question of what is, or isn't, modified in various
payloads - it is possible to have two separate links where nothing in the
link level payload is altered when packets move from one to the other, what
really defines a link, as best we can do in these days of dubious and
ambiguous forwarding devices, is where broadcast packets go.

That also relates to Keith's point  ...

  | >if that's the case then you can't
  | >afford address collisions between A and B, and if that's not the
  | >case then your address defense protocol won't work anyway.

as all of this depends upon how broadcast works - the defence protocol depends
upon broadcast (link level) packets being seen at every other possible user
of the address, and the area where address collisions matter is the same set
(where an ARP query might otherwise result in multiple different responses).

kre

---

From: Keith Moore <[email-masked]>
Date: Tue, 14 May 2002 19:02:06 -0400

These are my comments on draft-ietf-zeroconf-ipv4-linklocal-05.

I'm cc'ing IESG on the assumption that the draft would go to IESG
anyway.  As there are still substantial problems with this document,
I don't see any need to wait until IESG issues a Last Call.

NOTE: Many of the criticisms on the -04 version of the document have
not been adequately addressed, so they are re-iterated here for
completeness.  (read: rather than trying to reconcile -05 with those
comments, I simply made a fresh pass over -05.  But I remember making
similar comments about -04 on most of these issues.)

Executive Summary: The protocol has significant deficiencies which
cannot be fixed by simple changes in the text.  More work is needed.

------------------------------------------------------------------------------
Issue 1: This protocol will break distributed applications.

Consider a distributed application that runs on several hosts.  Some
of these hosts are on a local network and support autoconfiguration,
some of these hosts are on a remote network which has intermittent
connection to the local network.  That local network can either be
connected or disconnected from the remainder of the network.  The
components of the application may start when the network is in either
state, and the network can transition from one state to another
without warning (as the connection goes up and down).

There are several reasons why such a scenario is realistic: the
routers and other hardware that connect the local network to the
outside world may suffer frequent power failures; lots of sites have
flaky links to the outside world, etc.  

Each component of the distributed application also needs to be able to
send its address+port to other components.  This is a common and
reasonable thing to do - FTP has long allowed it for third-party
mediated transfers, SIP does it for call setup, Gnutella does it to
inform third parties about the locations of files, distributed
computing and cluster computing applications (Globus, Legion,
NetSolve, PVM, Condor, etc.) do it to allow components to spawn new
components on other hosts which communicate with other components that
are already part of the application.

Now here's the problem: If a component starts operation when the local
network is in a disconnected state, it will only learn of the
link-local address(es) of its host.  If it advertises those addresses
to other components, and the network subsequently transitions to a
connected state, those addresses are likely to propgate to components
for which they are not usable.  This applies to both "smart"
applications that explicitly select their source addresses, and "dumb"
applications that simply use whatever source address they are bound
to.

A similar problem exists when the component starts operation when the
local network is in a connected state - a "smart" application learns
of all of the addresses of the host, including the link-local
addresses.  If it propagates those addresses to other components on
other hosts, they will not be able to use those addresses.  However,
this is a more general problem with scoped addresses.

It has been argued that link-local addresses have been supported on
Windows and MacOS systems for a long time, with no known ill effects.
However, according to the draft, both Windows and MacOS systems first
try to configure an interface with DHCP and only fall back to
link-local if that fails, and both systems discontinue use of the
link-local address once a DHCP server is found and do not use
link-local addresses thereafter. (presumably they also avoid using
link-local addresses if an address is manually configured)

This limits the applicability of link-local addresses on such systems
(basically they're only good for isolated networks or for applications
which have short-duration connections), but by minimizing the
transitions that an application sees it also limits the harm that
would otherwise be done by exposing link-local addresses to
applications that aren't aware of them.  This was a wise decision on
the part of the Windows and MacOS developers which seems to have been
disregarded by the working group.  By contrast, this document proposes
to make link-local addresses usable full-time, without really
considering the impact on applications, and for what seem to be
dubious reasons (e.g. providing a false sense of security).

It's difficult to see how to remedy this problem while still allowing
link-local addresses to be full-time.  In earlier comments I made
suggestions in an attempt to minimize the problem, e.g.:

- that a link-local address should not be selected as a source address
except when there is no routable source address, or when attempts to
contact a device using a link-local destination and a routable source
address have failed.

- that in lists of interface addresses obtained from the OS that
link-local addresses either be hidden, or distinguished from other
addresses in a way that makes "smart" applications unlikely to choose
those local addresses as source addresses.

But these were just my earlier attempts to "fix" the protocol without
changing it much.  I don't think that these are sufficient by
themselves.

------------------------------------------------------------------------------
Issue 2: Definition of "on the same link" is still flawed.

It's simply bogus to define "on the same link" solely in terms of
whether the link-layer payload is changed.  Yes, IP routers should
decrement TTL and thus cause the packet to be "not on the same link"
by this definition, but if a router fails to decrement TTL then it
still shouldn't be "on the same link". 

Having the link-layer payload be unchanged might be a necessary
condition for "on the same link", but - at least if you want this
definition to be useful for describing when link-local addresses are
usable between two hosts - it's not a sufficient condition.  Another
necessary condition is that the hosts be able to receive each other's
broadcasts.  Actually it is probably better to define this not in
terms of "two hosts" but as "a set of hosts": e.g.

A set of hosts is considered to be "on the same link", if:

- when any host A from that set sends a packet to any other host B in
  that set, using unicast, multicast, or broadcast, the entire
  link-layer packet payload arrives unmodified, and

- a broadcast sent over that link by any host from that set of hosts
  can be received by every other host in that set

This problem is easily fixed: just change the definition.

------------------------------------------------------------------------------
Issue 3: The address defense protocol appears to facilitate new kinds of attack

A host supporting link-local addresses is expected to enable them at
all times, and to support the address defense protocol at all times.
So if an ARP packet arrives at a host which conflicts with one of the
host's existing link-local addresses, the host is expected to either
defend the existing address, or configure a new link-local address and
defend that address.  Either way, the host MUST send out multiple ARP
probes (4 probe packets at 2-second intervals to claim the address,
followed by 2 announcements, also at 2-second intervals), each using
broadcast.  

This has a multiplier effect - one or two ARP packets sent by an
attacker results in six ARP packets being sent in response, causing
every host on the link to process each of those requests, and also
breaking any connections that might be using the link-local address.
If several hosts are attacked at once this can produce broadcast
storms.  While each of these storms should be limited in duration to
about 16 seconds (due to the initial random delay, bounded number of
transmissions, and the fixed 2-second interval), they can still be
disruptive.  And nothing stops the attacker from repeating this attack.

A virus that infected several hosts on a link and which attacked the
link in this way would take down the link.  While the virus could just
as easily take down the link by merely sending broadcast packets, an
attack which caused *every* host on the link to send broadcast packets
would be more difficult to diagnose.  Widespread support for full-time
defense of link-local addresses allows an attacker to exploit the
packet-multiplication effect of this protocol.

The security considerations section doesn't adequately address this
attack (it claims that ARP is insecure, which is true, but this
protocol facilitates a new kind of attack using ARP), and it doesn't
provide any means of ameliorating this threat.

Part of the problem is caused by link-local addresses being enabled at
all times, even when there's no need for them, and even by hosts which
don't need or want to talk to hosts which only have link-local
addresses.  Also, this problem is much less severe with existing MacOS
and Windows implementations of link-local addresses because these
disable use of such addresses for any link that supports DHCP.

------------------------------------------------------------------------------
Issue 4: The document (still) makes misleading claims about security

Section 2.8 is still misleading.  In part, it reads:

   The non-forwarding rule is important because it is expected that
   many link-local-only devices will be extremely simple devices of
   the kind that currently use X10 [X10], USB [USB] or FireWire [1394].

   The designers of these devices currently assume that they will
   communicate only with other local devices, and this allows them to
                                                  -------------------
   produce cost-effective devices by implementing a degree of security
   -------------------------------------------------------------------
   appropriate for that expected environment. 
   -----------------------------------------

The underlined portion can be read either as a (bogus) assumption
by the designers of such devices, or as a statement that use of
link-local addresses really does provide some security.

We need to be very clear about this.  Use of link-local addresses is
*not* an appropriate security mechanism.  It is *not* reasonable for
the designers of IP-based devices to assume that the link provides
adequate security for any purpose - first because the designers of
such devices know nothing about the networks to which their users
connect; and second, because the security of other hosts on such
networks cannot be assumed. and such hosts could be used as platforms
from which to attack these devices and expose information from those
devices to other hosts.

The security considerations section (section 5) is also misleading:

- It recognizes the potential for previously non-IP hosts to be
attacked via IP if they acquire an IP interface (this wasn't obvious?)
but it fails to recognize the potential for additional attacks on
existing IP hosts if they implement link-local addresses.

- It recognizes the existing insecurities of ARP but fails to
recognize the additional insecurities resulting from this particular
use of ARP.

(Normally we expect the security considerations section to document
the risks of *this* protocol rather than other protocols...)

It also states that "the use of link-local addresses..." [presumably
instead of routable addresses] "may reduce the breadth of attack to
which a device may be subject" and then goes on to state (correctly)
that "this is not a reason to ignore security issues."

It should still be made even clearer that link-local addresses are not
a security mechanism, and that *any* IP-capable host may potentially
be attacked using IP even if it has no routable addresses - by other
hosts on the same link that have been compromised or by unauthorized
hosts which have obtained access to the link by some means
(e.g. wireless links or wiretaps).

------------------------------------------------------------------------------
Issue 5: Use of link-local addresses in DNS (and other higher-layer protocols)

Section 2.9 reads as if it's reasonable to put link-local addresses in
DNS if some constraints are followed.  It seems to me that practical
constraints on such use are so narrow and so difficult to define that
it would be far better to simply say that link-local addresses SHOULD
NOT be used in DNS and/or that mechanisms specifying link-local
addresses in DNS are currently undefined and for further study.

For instance, on a network where new hosts could join or leave, a DNS
service returning link-local addresses would need to deal with
possible address conflicts and changes.  This could be addressed e.g. 
using DNS dynamic update, but then the host needs to authenticate to 
the DNS server.  This defeats the very purpose of autoconfiguration.
In such cases it would often be simpler to just assign a static IP 
address to the host.

Similar concerns, of course, apply to any use of link-local addresses 
by higher-layer protocols - they're subject to change at a whim.

------------------------------------------------------------------------------
Issue 6: Hosts that have multiple interfaces

The scenario described in section 3.3.2 will break applications, as it
requires them to explicitly select a network interface when sending a
packet, and to know which interface to select.  For instance, if an
application on host A wishes to send a message to an application on
host B, it must explicitly send that packet through interface P.

Even if the stack knows which interface to use for already-open TCP
connections, this doesn't allow an application on host A to reliably
open up a new connection to host B.

It's hard to see how to fix this.  IP is designed with the assumption
that a host or service can be identified with sufficient precision
(for the purpose of establishing a connection to that host) simply by
specifying the host's or service's address and the port number of the
service.  And defending the addresses between separate links seems
undesirable.

------------------------------------------------------------------------------
Conclusions:

The document seems to envision a world where large numbers of
(probably insecure) devices are capable of speaking IP using only
link-local addresses, and where any IP-capable host (on the same link)
can automatically talk to such devices.  It's an interesting world to
think about.  But I don't think that the security problems have been
adequately addressed.

Also, it seems to be trying to solve two separate problems - address
selection in ad hoc networks, and automatic configuration of
limited-function devices.  I suspect that these are better treated as
separate problems, and that different solutions are needed for ad hoc
networks vs. managed networks.  M$ and Apple got that right in their
early implementations.  You really don't want this protocol being used
on your network if you're supporting DHCP.

Bluetooth devices, I've heard, have the capability of being taught
which other devices to trust.  This seems like an essential
capability, and I doubt that any network device can potentially accept
input from large numbers of other hosts and still provide adequate
security without such a mechanism.  "zero configuration" is probably
not desirable as anything other than mechanism for initial
configuration and bootstrapping.

------------------------------------------------------------------------------
Recommendations:

- Provide a means for networks to disable use of link-local addresses
  for any host that is

  - capable of using routable addresses, and
  - not explicitly configured to use link-local addresses.  

  This would still allow use of link-local addresses on ad hoc
  networks, and it would still allow hosts that needed to use
  link-local addresses in order to communicate with devices
  to do so.  But it would not make them the default for all hosts.
 
  e.g. Any host that either has a routable address explicitly
  configured, or which receives an address from DHCP, ceases using
  link-local addresses for new connections, unless it was explicitly
  configured to be able to use link-local addresses.

  This would minimize the potential for "address defense protocol"
  attacks and for disruption of applications.

- Explicitly and clearly state in positive terms that all IP-capable
  devices, including those using only link-local addresses, MUST
  implement security adequate to protect the device's resources 
  those resources to which the device has access, and the network.
  such security almost certainly requires explicit configuration.
  and although link-local addresses may be useful during initial
  configuration, they are not a security mechanism.
  
- Also, I wonder if this protocol be considered only applicable for
  use in ad hoc networks - in particular that it SHOULD NOT be
  considered a substitute for DHCP even for limited-function devices - 
  it doesn't seem any more difficult for a limited-function device 
  to implement DHCP than to implement this protocol.  (though it is
  unfortunate that they need to implement two protocols, the subset
  of DHCP needed to configure the host address, netmask, and default
  route - if any - shouldn't be too bad.  Either that or let the
  DHCP server respond to an ARP request for a link-local address
  with a RARP response to say "no, *this* is your address".  

  The point is that you may want to avoid using these things in 
  managed networks, even for limited-function devices.  If that
  means that such networks need to learn how to disable link-local
  address defense, in order to lessen the burden on those devices,
  that's probably a reasonable tradeoff.

- Beyond the suggestions I made above, I'm not sure how to keep 
  link-local addresses from breaking distributed applications.  
  But I think the potential can be minimized by only using
  link-local addresses on ad hoc networks or on hosts that are
  explicitly configured to use them, and with some of the other
  suggestions I made.  

-Keith

---

From: Peter Johansson <[email-masked]>
Date: Wed, 15 May 2002 09:42:46 +1000

At 07:02 PM 5/14/02, Keith Moore wrote:

>The underlined portion can be read either as a (bogus) assumption by the 
>designers of such devices, or as a statement that use oflink-local 
>addresses really does provide some security.

There's more than one problem with the text cited from clause 2.8: " ... or 
FireWire [1394]. The designers of these devices currently assume that they 
will communicate only with other local devices, and this allows them to 
produce cost-effective devices by implementing a degree of security 
appropriate for that expected environment."

RFC 2734, IPv4 over IEEE 1394, is intended to provide full IP functionality 
with NO assumptions that the hosts communicate only with other local 
devices. Since IEEE 1394b is a suitable candidate for the backbone of a 
home network, there's no reason to assume the limited connectivity stated 
in clause 2.8 above.

Regards,

Peter Johansson

Congruent Software, Inc.
98 Colorado Avenue
Berkeley, CA  94707

(510) 527-3926
(510) 527-3856 FAX

[email-masked]

---

From: Peter Johansson <[email-masked]>
Date: Wed, 15 May 2002 09:42:46 +1000

Regards,

Peter Johansson

Congruent Software, Inc.
98 Colorado Avenue
Berkeley, CA  94707

(510) 527-3926
(510) 527-3856 FAX

[email-masked]

---

From: Peter Johansson <[email-masked]>
Date: Wed, 15 May 2002 09:42:46 +1000

Regards,

Peter Johansson

Congruent Software, Inc.
98 Colorado Avenue
Berkeley, CA  94707

(510) 527-3926
(510) 527-3856 FAX

[email-masked]