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

From: Thomas Narten <[email-masked]>
Date: Fri, 04 Oct 2002 15:11:05 -0400

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. I think a 
list of applications would serve two purposes:

- document the motivation for this feature
- serve as target for people arguing that this application has 
serious failure modes when used with link-local addresses

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.

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.

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. This 
suggests that there be a warning that link-local addresses SHOULD NOT 
be manually configured.)  

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.

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

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

How does Windows XP behave?

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?

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

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.

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

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.

 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.

       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.

 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.

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

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. Or, if there are legitimate reasons
why an implementation might not want to use its global address in this
case (knowing that communication will fail as a result) please include
some background explaining why this might be a reasonable approach.

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

---

From: "John C. Welch" <[email-masked]>
Date: Fri, 04 Oct 2002 16:00:01 -0400

On 10/04/2002 15:11, "Thomas Narten" <[email-masked]> wrote:

Minor comments

> serious failure modes when used with link-local addresses

Off the top of my head...any sort of File Transfer applications, any
application that needs access to resources on another machine. Word  and
Acrobat come to mind because when you are dealing with large documents that
require multiple people editing, there are always times when you may need to
pass it around one last time before printing, presenting, etc. Being able to
just set up a network quickly to do this makes this much easier, (Okay, so I
carry a hub and cables with me, but... I'm a geek...some people aren't ;-)
especially considering that most current OS's have some form of HTTP sharing
built into them. 

> globally unique address when sending the address of its interface in

I think that file transfer protocols need to function in an LL environment.
Indeed, getting files to Bob's or Marsha's laptop on the quick without
needing to set up a 'formal' network is one of the useful things about LL,
and Zeroconf as a whole. Media protocols such as RTSP should function in an
LL environment as well. IPSec has less of a case, I can't see how you would
make that work. I agree that any routing protocol should utterly ignore LL
packets. DNS isn't so clear cut, but for other reasons outside of the
immediate LL scope.

>        made it to the RT (static route, old routing proto)?

I would recommend that 169.254/16 simply be non-routable. Keep it simple,
and if there are people who would claim to 'need' this, then there are other
ways to simplify IP configuration in a routed environment. Most modern OS's
allow for multiple IP addresses on a single link, so there is no obvious
need to route LL packets, from my POV at least.

> for communication outside a single link would make sense.

Agreed.

john

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

---

From: Daniel Senie <[email-masked]>
Date: Fri, 04 Oct 2002 16:18:57 -0400

>especially considering that most current OS's have some form of HTTP sharing

File sharing in an ad-hoc network is the #1 reason I use LL. Doesn't matter 
if the media is Ethernet, wireless, Infrared, Firewire, or whatever. (I 
think my laptop supports LL over all of those). The ability to beam data 
between laptops when working away from infrastructure is key.

>I think that file transfer protocols need to function in an LL environment.

File transfer protocols such as FTP will work just fine in an LL 
environment, provided the client and server machines are both on the LL, 
and both use LL addressing. Any case where one machine uses LL and the 
other uses public address space gets into the same issues as are raised 
with these protocols and NAT. Since LL as specified is NOT supposed to 
traverse routers (despite the efforts of some folk) there is really little 
trouble with these protocols with LL.

>make that work.

IPSec appears to be a silly case in conjunction with LL. We're talking in 
general about "zero configuration" networks. IPSec (at least in the 
implementations presently available) are about as far from zero 
configuration as you can get.

>  I agree that any routing protocol should utterly ignore LL

OSPF clearly should not be dealing with LL, since LL packets aren't 
supposed to be routed, and are guaranteed NOT to be universally unique. Any 
attempt by a router to work with LL necessarily involves NAT, at which 
point we need to question whether we're talking about a router (RFC 1812) 
or a NAT gateway box.

>need to route LL packets, from my POV at least.

Routing considerations should read: LL packets are NOT routed. Perhaps it 
should be even stronger (or an additional document written) that says: RFC 
1812 is hereby ammended to declare that packets with source or destination 
addresses in the 169.254/16 address block are to be quietly dropped by the 
input handling mechanism of routers.

> > for communication outside a single link would make sense.

Strong agreement.

---

From: Keith Moore <[email-masked]>
Date: Fri, 04 Oct 2002 16:55:05 -0400

> between laptops when working away from infrastructure is key.

file sharing won't work over LL for long periods of time.  none of the
file sharing protocols of which I'm aware (NFS, CIFS, FTP, etc.) have
the capability to deal with address changes in the middle of a mount
or session.

it might work for brief periods when you're "working away from the
infrastructure" but LL is being touted as something that also works 
just fine within the infrastructure.

> and both use LL addressing. 

and your sessions are short (I've run ftp sessions lasting for several days), 
and clients know when to use an LL address in referrals (say a PORT command)
and when to not use them,
and you're not doing 3-party transfers.  
there may be one or two other caveats...

> Any case where one machine uses LL and the 
> with these protocols and NAT. 

NAT has its own (half) solution to some of these problems, and at any 
rate the existence of a problem with NAT is not a justification for
introducing a problem in LL.  I'll also note that NAT is not standardized,
and wouldn't meet the criteria for standardization by a long shot.

> Since LL as specified is NOT supposed to 

no, it doesn't follow.  since LL doesn't traverse routers then the
applications have to know when to use it and when not to use it - 
and that's a huge burden to place on the installed base.

> configuration as you can get.

"zeroconf" is a misnomer.   none of this technology is going to scale to 
a production network of any size without per-host configuration.

Keith

---

From: "Jim Fleming" <[email-masked]>
Date: Fri, 4 Oct 2002 16:22:33 -0500

----- Original Message ----- 
From: "Keith Moore" <[email-masked]>
NAT is not standardized,
> and wouldn't meet the criteria for standardization by a long shot.

That is one of the strengths of the IPv8 migration plan, which includes NAT.
Standards can kill innovation. NAT works and has eaten IPv6's lunch.
Some call that evil. Others call it a NetWork, because it works. Standards
do not create networks. Rough consensus and working code does. The
"zeroconf" developers may be best-served by avoiding any attempt to
standardize them out of existence.

Jim Fleming
2002:[IPv4]:000X:03DB:...IPv8 is closer than you think...IPv16 is even closer...
http://www.ietf.com
http://www.iana.org/assignments/ipv4-address-space
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt
http://ipv8.dyndns.tv
http://ipv8.dyns.cx
http://ipv8.no-ip.com
http://ipv8.no-ip.biz
http://ipv8.no-ip.info
http://ipv8.myip.us
http://ipv8.dyn.ee
http://ipv8.community.net.au

---

From: "John C. Welch" <[email-masked]>
Date: Fri, 04 Oct 2002 17:31:57 -0400

> the capability to deal with address changes in the middle of a mount

But long term mounts aren't a major use for a LL setup. As well, people have
been mounting things in a LL-style setup anyway in the AppleTalk world for
years now, and they adapt just fine to the concept that once you unplug this
cable, AppleTalk go bye-bye, and your mounts go away. The OS has to deal
with that part of things gracefully, and most do.

As well, even in a static IP config, or a DHCP config, if you unplug from
the network, the mounts drop, even if you go wireless right away. You simply
re-establish the connection. That particular issue is neither new, nor
unique to LL.

> just fine within the infrastructure.

It does both...you're in a meeting in an area without network hookups or
wireless coverage, you need to transfer files. LL provides you with the
addressing for AFP/IP, FTP, CIFS to work. File transferred, meeting rocks
on. Later, you connect back into the corporate network, and do more work.
The OS's networking implementation handles all of this for you. *That* is
where the work should be done, not at the Application or User levels.

> there may be one or two other caveats...

If you are running week long FTP, then you are probably not on an ad hoc
network without a router anyway. LL also won't work if you need to set up an
Enterprise-wide VOIP system as well, but that's not the point. No solution
fits every single conceivable situation perfectly. For what LL *does* do
well, it's very good at. I wouldn't set up a /8 network with an FC SAN just
to move a PDF of a presentation to my co-presenter either.

> and that's a huge burden to place on the installed base.

Why would an FTP app *care*? As long as it can see the destination machine,
Bob's your uncle. The FTP app has no business deciding if an address is
valid or not. The lower layers can either create a TCP connection on the
proper ports, or they cannot. If they can, you can then transfer data...if
they can't, then you can't, and the FTP app gives you an error.

If a someone is trying to access www.mit.edu, and they are in an LL-only
situation, then the connection attempt will time out. That's how it works
anyway. Let's not overcomplicate this process.

If you are in a situation, as I am this moment, where I am using
LL/Rendezvous/Zeroconf for my iChat session with a co-worker down the hall,
and transferring a file from www.apple.com, then the OS, and the network
stack handle that translation. IE only needs to be able to get the right
response to it's attempt to connect. It doesn't need to care which interface
does what, and, in a multi-homed environment, it had better well *not* be
trying to tickle a specific interface, or when I unplug my Ethernet cable
and start using wireless, it's going to be unable to connect to a web site.
If an application fails because it only works with en0, it's going to fail
anyway, and that's a bug, not a feature.

> a production network of any size without per-host configuration.

<sigh>...nothing is <truly> zeroconf...you have to setup the OS, you have to
apply power to the device, printers need paper, you have to plug in a cable,
you have to physically be in range of a wireless device, you need to be able
to operate the input system for your computer. Can we *please* not pick nits
about the applicability of the name "Zeroconf"? Technically, Ethernet uses
neither the concept of "the ether", the substance Ether, nor is a net used
in any way...but we've managed to look past those minor issues at the big
picture.

john

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

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 4 Oct 2002 19:25:57 -0400

On Friday, Oct 4, 2002, at 16:55 America/Montreal, Keith Moore wrote:
> file sharing won't work over LL for long periods of time.

This is nonsense.  I have an existence proof that the claim above
is bogus in my LAN here in Herndon -- using link-local and NFSv3/TCP.

>  none of the

And the beauty of a LL NFS mount is that the address won't need to 
change
in the middle of a session unless one swaps NIC cards (in which case
the session is interrupted for reasons other than IP addressing).

> just fine within the infrastructure.

It works fine concurrently with me using (10.x.y.z & NAT) to access
web content and process email.

> and when to not use them,

Seems to work fine for me since my LL addresses only change when I swap
NIC cards (at most once per year, usually never).

> and you're not doing 3-party transfers.

3-party transfers are inherently insecure and ought never be used or
implemented regardless of LL.

> and that's a huge burden to place on the installed base.

I'm not actually seeing problems with most protocols using LL, so I am 
having
a hard time believing the bold unqualified claims that Keith keeps 
making.
I can believe there are some corner cases, but Keith would be more 
persuasive
if he made more careful precise claims rather than the bold handwaving 
sorts
of claims.

> a production network of any size without per-host configuration.

Since the primary goal is to support small-scale (AppleTalk-like) 
networks that
don't even have a router, I'm not sure that it is relevant to talk 
about scaling
to a very large network.  The stuff we have seems to scale no worse 
than IEEE
802 bridging, so is probably fine.

Ran

---

From: Keith Moore <[email-masked]>
Date: Fri, 04 Oct 2002 20:11:52 -0400

> is bogus in my LAN here in Herndon -- using link-local and NFSv3/TCP.

okay, let me clarify - file sharing won't work for a long time over LL 
on a network with: conditions that require changing addresses
(e.g. lots of nomadic hosts being attached), or with components that 
do referrals (e.g. NFS mounts) and need to talk to a mixture of hosts 
some of which are accessible via LL and some of which are not.

one of the problems with talking about LL is that nearly all apps
will work over LL some of the time and almost all apps will break
more often with LL than they will break with routable addresses.
so you can always find cases where X works, even if X also breaks
under slightly different conditions.

> change in the middle of a session unless one swaps NIC cards (in which case

the address can also change if another host claims that v4LL address.

> web content and process email.

yes, but you don't have much 'infrastructure' to break.

> implemented regardless of LL.

don't confuse the way FTP does it with 3-party transfers in general.

> having  a hard time believing the bold unqualified claims that Keith keeps 
> making.

that's because you are trying to extrapolate from a small number of
corner cases and claiming they're representative of the whole.

> if he made more careful precise claims rather than the bold handwaving 

it's far bolder handwaving to claim 'if it doesn't break for me, it
won't break for anybody'.  especially if you dismiss any actual 
evidence that you're presented with.

> > "zeroconf" is a misnomer.   none of this technology is going to scale 
> > to  a production network of any size without per-host configuration.
> 

if LL were only going to be used on small scale networks I'd agree with you.

but it's relevant to talk about the effect on LL on such networks since
LL is being imposed on ALL networks (with no way to disable it) -
with anywhere from  2 to thousands of hosts, with or without routers,
with or without DHCP, with or without firewalls, with or without
servers, with or without distributed apps.

the idea that 'we've designed this car for crashworthiness on a test
track at 5 miles/hour, now we are okay putting passengers in it 
on actual highways for use at 80 miles/hour' just doesn't make sense.

Keith

---

From: "John C. Welch" <[email-masked]>
Date: Fri, 04 Oct 2002 20:35:32 -0400

> some of which are accessible via LL and some of which are not.

And if you have statically addressed hosts that are (dis)connecting from the
network a lot, what magic will keep their file sharing connection
functional? If one end of the connection is *gone*, the connection
*dies*...I don't care *how* you have it configured. The only exception to
this are connections created with this in mind, i.e. Citrix Metaframe.
However, if the app/protocol is designed to compensate for this, *then* it
won't matter if you disconnect, link local or not.

> under slightly different conditions.

I can find that for anything. But what you are saying is that it won't work
in LL in the same kind of case it would break under any other sort of link,
ergo, your argument here is moot.

> the address can also change if another host claims that v4LL address.

It can't claim it while a given host already has that address. It can only
do so when the first host is gone. However, the MAC address will change, and
since the MAC address is how Layers 1 & 2 decide to pass the packet up to
the higher layers, the new holder of the address won't get the packets,
unless you are also spoofing the MAC address as well.

By the same token, another host can grab a certain DHCP address, hell, they
can be *reassigned* while the host is still on...people still use DHCP, so
it's obviously not the big problem you say it is.

> yes, but you don't have much 'infrastructure' to break.

I do, and it works fine for me as well...unless you define MIT as not having
much infrastructure.

> corner cases and claiming they're representative of the whole.

You're doing the same thing, only to opposite ends. Ergo, both sides are
either equally valid, or equally invalid.

> evidence that you're presented with.

Show us where it breaks.

> servers, with or without distributed apps.

Well, I can't say for windows, but this type of LL is easy to disable on Mac
OS X. But the point is, it's being used, and *now*, and so far, your dire
predictions aren't coming true. In fact, the only consistent problems I've
seen involve Active Directory.

> on actual highways for use at 80 miles/hour' just doesn't make sense.

Neither does saying that 'we've designed it to survive a crash at 35 miles
per hour, but you might drive it off an overpass, and die in that crash, so
we won't release the car, because of this bizarre possibility.'

john

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