Subject: Re: Application software needs to be "zeroconf-aware"?

From: Ted Lemon <[email-masked]>
Date: Wed, 8 Jan 2003 22:28:48 -0600

> here's the sense in which it "cures" (or at least reduces)
> the problem.

> if the interfaces have to be explicitly configured
> (i.e. explicit action is required on the part of the user before
> the wireless interface is enabled) then the attacks can only be
> made when the wireless interface is enabled

This has nothing to do with link-local addressing - the same attack you 
propose for link-local is equally possible if the attacker just sets up 
a DHCP server.   So although I think this is an issue, and indeed I 
think you're raising an important point here, it is not a link-local 
addressing issue - it is a general issue.   And whether or not this 
draft advances will make zero difference in this case, because the cat 
is already out of the bag - wireless interfaces already use DHCP.   I 
can already attack your computer in the way you've described, if it's 
not buttoned down.

The current state of the art in Linux and MacOS X is to just firewall 
everything unless the user enables it.   I think it would be quite 
worthwhile to write up an informational RFC explaining the issue and 
making recommendations.   I think firewalling by default is probably 
sufficient, but if you don't agree, you should write your draft 
accordingly.   I don't think this would be a zeroconf draft, though.

> you don't need a WAP to have this problem, since wireless hosts can
> talk directly to one another.

Hm, that's true.   Again, not a link-local addressing issue, but 
definitely a problem.

> actually, it's the other way around.  the burden is not on me to
> explain every single security consideration of link local - it
> is on the group to explain why link local meets the criteria for
> proposed standard.  and if more study is indeed required (as it
> seems to be) then I fail to see how it can't be helpful to point
> that out to people who don't seem to realize it.

Well, but the point is that you have some valid security concerns that 
don't really relate specifically to link-local, and you appear to be 
trying to attach them as a rider to the link-local draft.   Also, if 
this were a completely accurate statement, I have trouble imagining how 
_any_ draft could advance in the IETF.

> what you seem to be saying is that because NATs exist and cause some 
> of the
> same problems that link-local addresses do, that the criteria for 
> standardization
> should be relaxed for link-local addresses.  it's the other way around 
> -
> neither NAT nor link-local is suitable for standardization because they
> both cause problems.

No, that's not what I'm saying.   What I said, and you can read it in 
the archive, is that this is probably _not_ a problem for link-local, 
although it is a problem for NATs.   Link-local and NAT are very 
different beasts.

> 1. explicit configuration

So someone puts a link-local address in a config file, and things don't 
work.   This is a configuration error.   Not our problem.

> 2. gethostbyname (gethostname ())

This is indeed a problem if gethostname() returns a .local address.   
Link-local addresses don't get published in the global DNS, so this 
shouldn't be a problem in other cases.   I'm not sure precisely where 
to state this, but I think you're right that it should be stated 
somewhere, possibly in this draft, that gethostname() and equivalent 
system calls should not return domain names in the "local" domain if 
the system has a global IP address.

> 3. getpeername () to get peer's address and use it in a referral to 
> another host
>    (often used as a workaround for some NAT problmes)

Okay, so someone connects to me using a link-local address, I have a 
link-local address, and I use getpeername() and publish the results in 
an internet-visible registry?   Can you give me a specific example of 
when this would happen?   Also, "a workaround for some NAT problems?"   
I thought you'd decided that we couldn't use NAT as a justification for 
saying that something is okay.   So, using getpeername() and sending it 
to a third party to work around a NAT problem can't be used that way 
either.

> 4. getsockname ()

We've already eliminated this as a potential source of problems.

> 5. ioctl to get list of interfaces

The ISC DHCP server uses this.   So does ISC BIND.   BIND uses these 
addresses to figure out on what IP addresses to listen, and to figure 
out if SOA records in zone files are referring to it.   I don't think 
this would cause a problem in either case, unless the user mistakenly 
configured BIND to use

If the ISC DHCP server were to see the link-local address as the first 
address, it would use it in the server-identifier option.   Clients 
would not be able to renew their leases using unicast.

Solution?   Configure the DHCP server with an explicit IP address to 
use as a server identifier.   Don't return the link-local address as 
the first address on the interface.   Hack ISC DHCP to recognize the 
link-local class B and not use addresses from it.   I think the latter 
is probably the correct solution.   Does this mean that link-local 
breaks ISC DHCP?   No.   First, there's a workaround.   Second, the way 
ISC DHCP handles multiply-homed addresses right now is fragile, and 
breaks quite frequently in firewall environments already.   I suspect 
that other examples you could come up with where SIOCGIFCONF is used 
would be similar.   Can you name an example where SIOCGIFCONF is really 
the right thing to do that isn't fragile already?

> pvm does this.  and no, it's not configurable in this way.

Hm.   Okay, this is an example.   Is there some reason why pvm works 
this way?   Does pvm try every address it gets from SIOCGIFCONF, or 
just the first?   If it only tries the first, do you assert that this 
is correct behavior?   You've made statements to the contrary, but as 
far as I know it is not the position of the IETF that all existing 
behavior is inherently sanctioned, and that no new RFC can ever break 
any existing behavior, no matter how broken it may be.   Also, pvm is 
an open source product, currently under active development, at least 
according to the web page I just visited.   So it beggars the 
imagination to think that if link-local were deployed, a complete fix 
could not be achieved in a matter of minutes.

Now, there's probably some other application out there that also does 
this, and that would break if a link-local address were configured on 
an interface.   Does this mean that this shouldn't go to p-s?   I don't 
think so.   I think the application is broken if it's assuming that 
when an API returns more than one IP address per interface, any one of 
those addresses is just as valid as any other.   An application like 
this _must_ be configurable.

> once upon a time I suggested that stacks respond to SIOGIFCONF in
> such a way that LL addresses were unlikely to be mistaken for
> ordinary addresses and unlikely to be used by apps that weren't 
> LL-aware.
> the group refused to consider it.

There isn't a single reference to that in the mailing list archive.

> I am not trying to scuttle the draft, I'm trying to get it fixed.

This is a touchy point.  You have your idea of what "fixed" means.   
Others have their idea.   For some, your "fixed" is their "scuttled."   
If the only output of this process that you consider valid is that 
every single point you've raised is addressed exactly as you have 
specified, then it may be difficult for you to participate in the rough 
consensus on this draft.

---

From: Keith Moore <[email-masked]>
Date: Thu, 9 Jan 2003 07:41:07 -0500

On Wed, 8 Jan 2003 22:28:48 -0600
Ted Lemon <[email-masked]> wrote:

> a DHCP server. 

well it *does* have to do with link-local addressing, because link-local
addressing is one of the means by which a wireless interface may be
automatically configured.  it also has to do with DHCP.  the fact that
DHCP also causes the problem does not relieve zeroconf of the burden
of documenting the problem that is associated with link-local and/or 
providing a workaround for when link-local addressing causes the problem.
yes, similar workarounds are also needed for DHCP - but that's not
zeroconf's problem.  zeroconf can't avoid doing needed work by saying 
"but DHCP hasn't done that work either!!!" 

> So although I think this is an issue, and indeed I 

bottom line is this is a problem.  does zeroconf want to be part of
the solution or do they want to claim that someone else has to solve
a problem that they're contributing to?

> work.   This is a configuration error.   Not our problem.

I'd say that the most that zeroconf can do is to document it.  But this
isn't a big problem, arguably the current draft already provides adequate
documentation.
 
> This is indeed a problem if gethostname() returns a .local address.  

which it does on my mac, even though I've tried to turn Rendezvous off,
and there doesn't seem to be any way to get it to stop doing so. 

> an internet-visible registry?  

it doesn't have to be a separate registry - all that is needed is to 
pass the address for referral within the app.

> to a third party to work around a NAT problem can't be used that way 

it's perfectly legitimate to use getpeername() to obtain an address,
and to pass that address to another host, whether or not there is a NAT
involved.  I just think it's interesting that a technique that is used
as a workaround to a problem caused by NATs (which use scoped addresses)
ends up causing other problems for link-local (which uses scoped addresses).

> > 5. ioctl to get list of interfaces

you're trying to argue about specific pieces of software.  I don't
believe it is reasonable to say that just because a workaround 
exists for say BIND, that all software that uses SIOCGIFCONF should
have to provide that workaround.  I don't believe it's reasonable for
zeroconf to impose that burden on all users of software that uses
SIOCGIFCONF to generate addresses for referrals.   It's not reasonable
for zeroconf to cause problems and then claim that they're somebody
else's problems to fix.

> There isn't a single reference to that in the mailing list archive.

I might not have mentioned SIOCGIFCONF by name.

> Others have their idea.   For some, your "fixed" is their "scuttled."   

My idea of "fixed" would leave link-local fully functional for 
ad hoc networks - the purpose for which this group was chartered.
For this group to insist on extra functionality for link local which
is far beyond the charter of this group and which has several known
problems is not only a violation of the criteria for proposed standard,
it's also a gross violation of process.

> specified, then it may be difficult for you to participate in the rough 

rough consensus is not the issue.  meeting proposed standard criteria
is the issue.