Subject: Re: IESG comments on draft-ietf-zeroconf-ipv4-linklocal-07.txt

From: Stuart Cheshire <[email-masked]>
Date: Thu, 6 Feb 2003 02:41:15 -0800

>The IESG discussed this document recently, and has the following
>comments.
>
>DISCUSS:
>========
>Harald:
>
>Three objections, based on a quick scan:
>
>1)
>The document gives no (zero) examples of applications that can 
>successfully and safely be used with link-local addresses.

*ALL* application protocols can successfully and safely be used with 
link-local addresses on a single isolated link. This is the whole point 
of Zeroconf. If the majority of applications have to be changed, then a 
major part of the benefit of Zeroconf is lost. If the majority of 
applications have to be changed before they work, then why not change 
them to use the USB APIs, or the FireWire APIs, or the Bluetooth APIs? 
One major benefit of Zeroconf is that you can just plug two laptops 
together, and your current ftp client works. Your current NFS client 
works. Your current Web browser works. The entire wealth of software that 
you can use on the world wide Internet can also be used on a tiny network 
consisting of just two laptops and a cable.

Between a group of hosts on a single isolated link, to my best current 
knowledge, *ALL* current application protocols work unchanged. That is 
not to say that all possible *uses* of all application protocols work. 
For example, HTTP can usually be used to buy books from Amazon.com, but 
this use of HTTP is not possible if you are not able to communicate with 
Amazon.com. However, the same Web browser software *can* use the same 
HTTP protocol to communicate with other local devices, such as checking 
the status page showing the ink levels in your local network printer.

Using link-local addresses on a link that also has connectivity to the 
rest of the Internet raises more issues, but I do not believe it creates 
any new issues that do not already exist by virtue of NATs, multi-homing, 
private addressing (e.g. Net 10) and any other issues relating to hosts 
that have multiple addresses with differing reachability with respect to 
the peers that host can talk to.

>2)
>
>The following section:
>
> > 2.10 Higher-Layer Protocol Considerations
> >
> > Similar considerations apply at layers above IP.
> >
> > For example, designers of Web pages (including automatically
> > generated web pages) SHOULD NOT contain links with embedded
> > link-local addresses if those pages are viewable from hosts outside
> > the local link where the addresses are valid.
> >
> > As link-local addresses may change at any time and have limited
> > scope, storing link-layer addresses in the DNS is not well
> > understood and it is NOT RECOMMENDED.
>
>is not sufficiently draconian.
>
>It should probably say something like:
>
>The following set of protocols:
>
>- FTP
>- DNS
>- NFS
>- IPSEC using IPv4 as an identifier
>- BGP
>- OSPF
>- RTP/RTCP
> <<<the list is far longer, I think>>>
>
>will fail if applications use a link-local address instead of a 
>globally unique address when sending the address of its interface in 
>a protocol packet.

This statement is false. Between a group of hosts on a single isolated 
link, all of those protocols work fine, to the extent that they are 
applicable to a group of hosts on a single isolated link (routing 
protocols like BGP are the one case that comes to mind as something that 
makes no sense to run between a group of hosts on a single isolated link).

The fact that FTP, NFS, telnet, http, ssh, RTP, etc., work fine
(in the sense that they allow the user to accomplish useful work)
can be easily verified by connecting two Macs (or two Windows machines)
with an Ethernet cable and trying them.

>3)
>
>Security consideration, section 2.8:
>
> > 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. Any network gateway device
> > that blindly forwards the contents of link-local IP packets off the
> > local link (or onto the local link) exposes simple link-local-only
> > devices to a much greater degree of risk than their designers may
> > have planned for.
>
>In the world of wireless LANs, this seems to be an extremely stupid 
>idea.  (not that it was a smart move before.....for kicks, try plugging 
>an X10 controller into your neighbour's outdoor electrical socket and 
>start playing....)
>I would suggest to add a NOTE:
>
>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.

I have no objection to adding this note to the document, and will do so 
unless I hear opposition from the Working Group.

>Steve:
>How do current hosts behave with respect to this: 
>
>	All ARP packets (*replies* as well as requests) that contain a 
>      link-local 'sender IP address' MUST be sent using link-level 
> 	broadcast instead of link-level unicast. This aids timely 
>	detection of duplicate addresses. An example illustrating how this 
>	helps is given in Section 4.   
>
>(I understand the necessity, but is it done? I suspect not.

1. It is not a "necessity". It aids in faster detection of duplicate 
addresses. This is a good thing, but by no means a "necessity".

2. This has been done in Mac OS since IPv4LL first shipped four years 
ago. As far as I know, it is not done in any version of Windows. As far 
as I know, no work at all has been done on IPv4LL in Windows since it 
first shipped four years ago. I am told that Microsoft is waiting for 
this document to be published as RFC before deciding whether to make any 
changes to their IPv4LL implementation.

>This suggests that there be a warning that link-local addresses 
>SHOULD NOT be manually configured.)  

This is what the document currently says. Is this sufficient?

1.4. 169.254/16 Not To Be Used for Other Purposes

   Note that addresses in the 169.254/16 prefix SHOULD NOT be configured
   manually

>I have vague recollections of an RFC that permits hosts to ignore 
>spontaneous ARP replies, i.e., those not in response to a query, in an 
>effort to block connection hijacking. I think that some hosts actually 
>do this. That would interfere with the claim-and-defend mechanism, and 
>with renumbering, I believe.

1. I am not aware of any such RFC
2. This document does not advocate spontaneous ARP replies
3. In any case, I do not see how it would interfere with the 
claim-and-defend mechanism.

>What use is link-local security in a world of wireless bridges?

What assumption is there that all devices will be connected to wireless 
bridges? One application of IPv4LL is for communication between 
components inside a sealed computer chassis.

Physical security is applicable in those situations where physical 
security is applicable. USB and FireWire connections typically rely on 
the physical security of the cable, and there may be some cases where the 
same level of security is appropriate for IP-based replacements for those 
technologies.

I do not think this document should claim that physical security is 
always adequate security; nor do I think that this document should claim 
that physical security is never adequate security.

>The Security Considerations section should note that address-based IKE 
>certificates [RFC2409, I think] MUST NOT be issued for link-local 
>addresses.

I do not want to draft text on a subject on which I am not an expert. If 
you can offer precise text, I have no objection to adding it to the 
document, in the absence of any opposition from the Working Group.

Are you CERTAIN that there is no situation in which IKE certificates 
could not be usefully used between a group of hosts on a single isolated 
link?

>Alex:
> Seems to me that a "routing considerations" section is required.
>   Some things that should be described:
>
>     - should a route be installed in the routing table based
>         on the link-local address on an interface?

Isn't this an implementation issue, not a protocol issue?

How a host implements its own internal data structures is private to the 
host, is it not?

>     - should/can the 169.254/16 prefix be announced by dynamic
>         routing protocols?
>
>     - if received from a routing protocol, should the prefix
>         be installed in the RT?
>
>     - what the behavior should be if the prefix somehow
>         made it to the RT (static route, old routing proto)?

I do not want to draft text on a subject on which I am not an expert. If 
you can offer precise text, I have no objection to adding it to the 
document, in the absence of any opposition from the Working Group.

However, even though the document doesn't mandate how a host should 
implement its networking software, I think it is already pretty clear on 
what the correct end behavior is:

   If the destination address is in the 169.254/16 prefix ...
   The host MUST NOT send the packet to any router for forwarding.

   ... send its packet, with a link-local source IP address ...
   directly to its destination on the same physical link.
   The host MUST NOT send the packet to any router for forwarding.

   An IPv4 packet whose source and/or destination address is in the
   169.254/16 prefix MUST NOT be sent to any router for forwarding, and
   any network device receiving such a packet MUST NOT forward it,
   regardless of the TTL in the IP header.

   This restriction also applies to multicast packets. IP packets with
   a link-local source address MUST NOT be forwarded off the local link
   even if they have a multicast destination address.

>Erik:
>The abstract and first paragraph in the introduction can easily
>be read as these addresses being a full-fledged replacement of
>DHCP assigned addresses.
>Having the text explicitly say that such addresses can not be used
>for communication outside a single link would make sense.

Unless I hear opposition from the Working Group, I will add the following 
text:

   Link-local communication using link-local addresses is only suitable
   for communication with other devices connected to the same physical
   (or logical) link. Link-local communication using link-local
   addresses is not suitable for communication with devices not directly
   connected to the same physical (or logical) link.

>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 document already says:

7.2 Limited Forwarding of Locators

   IPv4 link-local addresses MUST NOT be forwarded via an application
   protocol (for example in a URL), to a destination which is not
   link-local, on the same link. This is discussed further in Section
   2.9 and 3.

Is there additional text you would like to see?

Perhaps it could be worded better as follows?

7.2 Limited Forwarding of Locators

   The forwarding of IPv4 link-local addresses via an application
   protocol (for example in a URL), to a destination which is not
   link-local, on the same link, may result in unexpected failures.
   This is discussed further in Section 2.9 and 3.

Does this wording make the requirement less of a burden on the 
application writer, and more of a warning to the user that if they do 
inappropriate things, things may not work as expected?

Is that better, or worse?

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

This is a common misconception. IPv4 link-local addresses DO NOT change 
randomly at whim.

IPv4 link-local addresses only change in the event of catastrophic 
failure from which there is no other way to recover. Previously, IP hosts 
typically had no recovery mechanism in the even of two hosts using the 
same IP address, leaving the hosts useless until manual intervention 
fixes them. In the case of hosts with no screen and keyboard, which are 
only controlled via telnet or http connections over the network, the 
complete failure of networking left them in an unrecoverable situation. I 
myself have been at IETF meetings where network operators have had to 
physically yank the power cables from wireless base stations that had 
become accidentally misconfigured this way.

The fact that the IPv4 link-local specification includes a provision to 
automatically recover from this previously unrecoverable error scenario 
has frequently been misunderstood and cited as a weakness of the design 
instead of a strength. These frequent arguments have led to people 
demanding that the document includes text that implies that link-local 
address changes are frequent and random and unpredictable and 
unreasonable for applications to deal with. This text in the document 
then leads yet more people to believe that the ability to recover even 
from catastrophic failure scenarios is a weakness of the design, instead 
of a strength.

In reality, IPv4 link-local are frequently *more* stable that other forms 
of address. Every time I take my laptop from home to work and back it 
gets a different DHCP address, yet it rarely (if ever) encounters a 
conflict where it has to change its IPv4 link-local address.

>The text in section 2.5 says that in some cases the host MUST cease 
>using the address. Since it is easy for an on-link attacker to spoof 
>the ARP packets it can cause the host to break all its connections by 
>switching to a new address. The document should at least warn against 
>this in section 2.5, and presumably also discuss it in the security 
>considerations section.

Section 2.5 already says:

   Forced address reconfiguration may be disruptive, causing TCP
   connections to be broken.

However, this notion that this is a weakness of IPv4 link-local is 
another common myth.

In an on-link attacker spoofs ARP packets, then in reality you will lose 
all your TCP connections to resets and timeouts, even if you do refuse to 
pick a new address. The difference is that if you refuse to pick a new 
address, you will be unable to establish any reliable new TCP connections 
either.

If you don't believe me, open a bunch of telnet or ssh connections, and 
then set another local machine to the same IP address and see what 
happens. (Note: don't try to do this with a Mac, because Macs implement 
IPv4ACD to guard against accidentally or deliberately setting two hosts 
to the same IP address. Using some other OS you should be able to set two 
machines to the same IP address and see what happens.)

> And here is a "bonus" I didn't mention on the call:
>       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.

I am also working with IEEE people to solve the spanning tree problem. I 
don't think it is appropriate to put all of that protocol detail into an 
IETF document. The document already says this:

   Should future versions of the IEEE Spanning Tree Protocol be enhanced
   to inform clients when the link is ready to begin forwarding packets,
   then the shorter time values may be used on these networks too.

>       If the destination address is the 255.255.255.255 broadcast 
>	 address or a multicast address, then the host may use either 
>	 its link-local source address or a routable address, as 
>	 appropriate.
>
> OK for a link-local multicast destination. But for other multicast 
> destinations I assume it SHOULD use any routable address instead of 
> the link-local.

Unless I hear opposition from the Working Group, I will add the following 
text:

   If the destination address is the 255.255.255.255 broadcast address
   or a link-local multicast address, then the host may use either its
   link-local source address or a routable address, as appropriate. If
   the destination address is a multicast address with scope larger than
   link-local then the host SHOULD use an appropriate routable source
   address, if available, or its link-local source address otherwise.

> section 3.2:
>       Some operating systems have networking APIs that allow 
>	 applications to specify network interfaces by name, index value, 
>	 or other local identifier, and to identify interfaces this way 
>	 both for incoming and outgoing packets/connections. For operating 
>	 systems that have this capability (and have application software 
>	 that makes use of it) it is sufficient to configure all interfaces 
>	 with a single common IPv4 link-local address, and defend that 	
>	 address on all interfaces.
>
> Add warning that uses the same address on all interfaces makes the host
> more suceptible to attacks and other reasons for duplicate addresses 
> being detected late, resulting in a shorter lifetime for the link-local 
> addresses. Using a separate address per interface limits the "damage" 
> in such a case to a single link.

Unless I hear opposition from the Working Group, I will add the following 
text:

   Note that this may make forced reconfigurations more costly, since
   a conflict on a single interface in effect causes all interfaces to
   have to reconfigure to a new address.

> 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.
>
> The above breaks if multiple interfaces on the host are connected
> to the same link.

I do not believe it does. Please explain how.

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

3.3.1 "Example Illustrating (Incorrect) Ambiguous Address Re-Use" 
explains why this is beneficial to hosts that choose to implement it that 
way.

>Thomas:
>
>   If the destination address is in the 169.254/16 prefix (including the
>   169.254.255.255 broadcast address), the host SHOULD use its link-
>   local source address, if it has one. If the host does not have a
>   link-local source address, then it MAY choose to ARP for the
>   destination address and then send its packet, with a routable source
>   IP address and a link-local destination IP address, directly to its
>   destination on the same physical link. The host MUST NOT send the
>   packet to any router for forwarding.
>
>The above wording suggests that if host has no LL address, but it does
>have a global address, it is not required to use that global address
>to talk to a device that only has a LL address. This seems
>broken. I.e, it will result in communication failure that is hard to
>diagnose. Two nodes, both with legitimate addresses that should work,
>for some strange reason won't talk to each other. Seems to me like the
>MAY should really be a MUST. You can't NOT use the global address, if
>it's the only address you have.

Unless I hear opposition from the Working Group, I will change the text 
as follows:

   If the destination address is in the 169.254/16 prefix (including the
   169.254.255.255 broadcast address), the host SHOULD use its link-
   local source address, if it has one. If the host does not have a
   link-local source address, then it MUST ARP for the destination
   address and then send its packet, with a routable source IP address
   and a link-local destination IP address, directly to the destination
   on the same physical link. In many network stacks, achieving this
   functionality may be as simple as adding a routing table entry
   indicating that 169.254/16 is directly reachable on the local link.
   The host MUST NOT send a packet with a link-local destination address
   to any router for forwarding.

   If the destination address is a unicast address outside the
   169.254/16 prefix, then the host SHOULD use an appropriate routable
   source address, if it has one. If the host does not have an
   appropriate routable source address, then it MUST ARP for the
   destination address and then send its packet, with a link-local
   source IP address and a routable destination IP address, directly to
   the destination on the same physical link. In the case of a device
   with only a link-local address, this requirement can be paraphrased
   as "ARP for everything". In many network stacks, achieving this "ARP
   for everything" behaviour may be as simple as having no primary IP
   router configured, having the primary IP router address configured to
   0.0.0.0, or having the primary IP router address set to be the same
   as the host's own link-local IP address. In any event, the host MUST
   NOT send a packet with a link-local source address to any router for
   forwarding.

>COMMENT
>-------
>Scott: notes:
>                references not split
>                this can get fixed when Harald's discuss is delt with 

Noted. This will be fixed.

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

---

From: Robert Elz <[email-masked]>
Date: Thu, 06 Feb 2003 21:41:15 +0700

Date:        Thu, 6 Feb 2003 02:41:15 -0800
    From:        Stuart Cheshire <[email-masked]>
    Message-ID:  <[email-masked]>

Most of what was in this message I have no great problems with, but
this one ...

  | This is a common misconception. IPv4 link-local addresses DO NOT change 
  | randomly at whim.

"At whim" no - they change (as currently documented) whenever some random
other node tells the node in question to change its addresses (which it
does by simply claiming to own the address in question, of course).

  | IPv4 link-local addresses only change in the event of catastrophic 
  | failure from which there is no other way to recover.

This is clearly false - you also have addresses changing when ever a
node enables a new interface, if the address (on some other interface)
happens to be in use on the new one.   That's not "catastrophic failure"
by any definition.

And nor should "I like that address you've got, so I'm taking it for
myself" be really considered as a failure - it is the definition of the
protocol that allows that (if nodes wouldn't renumber in that situation,
communications might fail, but the other node wouldn't be able to take
the address, and with it, perhaps any TCP connections that happened to
be established at the time, if the interloper so desires).

  | Previously, IP hosts 
  | typically had no recovery mechanism in the even of two hosts using the 
  | same IP address, leaving the hosts useless until manual intervention 
  | fixes them.

Believe it or not, there are times where that is the best possible
outcome.   It isn't nice for this to happen, but "you can take over
my identity, whenever you want" which is the current solution to this
problem, is much worse.

  | In reality, IPv4 link-local are frequently *more* stable that other forms 
  | of address. Every time I take my laptop from home to work and back it 
  | gets a different DHCP address, yet it rarely (if ever) encounters a 
  | conflict where it has to change its IPv4 link-local address.

Actually, while it probably rarely encounters a conflict, its address *is*
changing every time it moves links that way.   It is just (I assume) managing
to hide that from the applications (which in some cases really ought to be
able to find out) by not changing the bit pattern that represents the
address.   But I can assure you that 169.254.1.1 on one link is not the
same address as 169.254.1.1 on a different link.

So, what you're describing is a situation where the address actually is
changing, but you're deceiving the applications into thinking it has not.

You'd almost certainly be better off not deceiving them, and deliberately
picking a different bit pattern to represent the address when it has in
fact changed, so that the applications can be aware of that.  And often,
they need to be aware.

  | > 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.
  | 
  | I am also working with IEEE people to solve the spanning tree problem. I 
  | don't think it is appropriate to put all of that protocol detail into an 
  | IETF document.

I suspect that you missed the point.   That is, if the delay isn't going to
be 45 seconds (which, counting from when the link became active, not from
when LL assignment commenced) is the delay it really needs to be, then there's
no point making it as long as 10 seconds, that does nothing at all when
dealing with most popular 802.1d implementations.   If you don't get an
answer in 1 second, you won't get one in 10 either (though you might after
45, or perhaps 30).

Or in other words, the algorithm (well, the timers that the algorithm uses)
in section 2.2 are useless, and nodes might just as well use 2.3's timers
always.   If things are to be reliable in the presence of 802.1d devices,
then the timers in 2.2 need to be made much longer (and be measured from
the correct timebase, which isn't when the LL algorithm starts, it would
be before that - sometimes very soon before, other times, much earlier,
one example being when a node is selecting a new address because of a
conflict that has appeared.)

kre

ps: I totally fail to understand why a multi-homed node would want to defend
its LL address from interface 1, on interface 2 as well (section 3.3).   I
understand why it wants to have different LL addresses on each interface
(in this OS model), but not why it would care whether some other host on
link 1 happens to have the address this host assigned to its interface to
link 2.   The justification (3.3.1) is that someone might believe the host
might get confused, and think it is trying to talk to itself - but that would
have to be broken software, as the draft (correctly) requires the strong ES
model for LL addresses, so one interface cannot directly communicate with
another.  So, that cannot be it.   Ie: there is no potential for confusion
here (a host that wants to talk to itself already has 127/8 available).

---

From: "John C. Welch" <[email-masked]>
Date: Thu, 06 Feb 2003 11:06:08 -0500

> does by simply claiming to own the address in question, of course).

No, they don't. They only give up their existing address when the new node
insists on claiming that address, and won't seek another address. That is to
prevent multiple nodes getting into an endless 'acquire and defend' loop,
and spewing ARP packets with no way of stopping. It is a very logical way to
deal with a broken device.

john

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