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

From: Keith Moore <[email-masked]>
Date: Wed, 08 Jan 2003 19:23:01 -0500

> If you are interested in having an earnest debate, then why don't you 
> say precisely what it is that is a known problem with v4ll in the sense 
> intended by RFC2026, and then we can talk about that?   

I have done so, many times, and in many different ways.

I've written a lengthy document that attempts to outline these problems, 
that I submitted to IESG (and cc'ed to this group) in response to Last
Call.  I've also cited specific applications that linklocal breaks.

I cannot fathom why this isn't precise enough for some people, 
but I'm getting tired of answering the same question again and 
again and still being told that I'm not answering it.

> In another message, I suggested an aspect of the FTP protocol that we 
> could use to have this debate - perhaps you'd like to take a stab at 
> that one?

When you argue that LL breaks 3-party FTP then you get the response
that 3-party FTP is obsolete and/or a security hole anyway, so breaking
3-party FTP is no big deal.  And the only reason you need PORT is for
3-party FTP; PASV works fine for 2-party FTP.  So I'd rather cite 
applications that are currently being used.

Keith

---

From: Alf Watt <[email-masked]>
Date: Wed, 08 Jan 2003 16:47:21 -0800

> Call.  I've also cited specific applications that linklocal breaks.

Perhaps you SHOULD re-introduce that document for review and explain in
detail how one of your specific example applications breaks in the presence
of v4LL addressing.

This has been suggested before, by the groups chair among others. Once your
issues, technical or otherwise, are clear we MAY be able to have a
discussion about how to resolve those issues instead of needlessly running
around in circles.

Best,
Alf

---

From: Ted Lemon <[email-masked]>
Date: Wed, 8 Jan 2003 19:52:39 -0600

> I have done so, many times, and in many different ways.

Sigh.   I had to really hunt for anything substantive - I couldn't find 
the draft to which you referred in your list of publications on your 
web page.   I finally did find in the WG archive a pretty nice general 
analysis of the problem space that you sent before I joined the list (I 
joined the list at Thomas' request because of DHCP-related issues in 
this draft).   Having read your response, I think it's a fine analysis, 
but I have trouble with most of the conclusions you draw as a result of 
your analysis.

For example, you say that link-local should be disabled by default on 
all wireless interfaces.   The only justification I can find for this 
in your article is your example of two companies sharing a wall, where 
WAPs in one company are reachable from the other company.   You say 
this poses a security threat because the firewall has been bypassed.   
Well, okay, but the security threat isn't because of link-local 
addressing, and getting rid of link-local addressing doesn't cure the 
problem.   The problem is a pathologically bad wireless network 
configuration.   In a networking environment where firewall protection 
is needed because of poor internal security, an open wireless link on 
the trusted side of the firewall is just wrong, and the solution is not 
to kill link-local - it's to secure the WAP, or put it outside the 
firewall (probably a better choice, given the wireless security options 
that are currently available).

You also say "more study is required to understand the security 
implications of link-local."   This isn't a helpful recommendation.   
If you think there are security implications, why then trot them out!

You worry about addresses leaking into the DNS.   This is a real 
problem with NATs already.   However, I don't see how link-local 
addressing exacerbates the problem - you can't communicate with the 
external network using your link-local  address, so it's unlikely that 
an application is going to leak it in the first place (see below).   If 
we want to solve this problem, we should standardize NATs and firewalls 
and require that they intercept lookups for private address spaces.

As for the application issues, I just can't come up with a scenario 
where this is going to be a problem.   Normally, the way an application 
would send its address to another host would be to do a getsockname() 
system call.   This requires that the connection be working - that the 
two endpoints be communicating.   If the two endpoints are 
communicating, the correct address is going to be returned by 
getsockname().   The stack does need to be smart enough not to try to 
connect to a non-link-local address using a link-local source address - 
that would simply result in repeated connection timeouts.

It is possible that an application might do a system-specific call like 
ioctl(..., SIOCGIFCONF, ...) to get an interface list and enumerate the 
addresses.   However, in that case I think we can assume that the 
application is smart enough to at least be configurable as to which 
address it advertises.   I don't know of any applications that would be 
adversely affected by this.   It would make sense to suggest that the 
stack always return the link-local address last, I suppose.

I guess my conclusion from all of this is that you've thought about 
this pretty carefully, but that your conclusions are by no means the 
only ones that can be drawn from your analysis.   I do not agree, based 
on carefully reading your analysis, that this proposal needs to be held 
back for further research.   I don't agree that link-local should be 
disabled by default on wireless networks.

Other than that, if you want to write up specific proposals for 
mitigating the problems that you've identified, I think that's a fine 
idea, and I hope the WG would agree with that.   But if the only action 
you think appropriate is to scuttle the draft, it's going to be tough 
for you to have a meaningful discussion with the people who've worked 
on the draft and want to advance it.   Based on the interactions I've 
seen so far, I wonder if that isn't why we're seeing all this 
back-and-forth.

---

From: Keith Moore <[email-masked]>
Date: Wed, 8 Jan 2003 21:18:31 -0500

On Wed, 8 Jan 2003 19:52:39 -0600

> but I have trouble with most of the conclusions you draw as a result of 

thanks.

> problem.   

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, which won't be all 
the time, or for every machine with a wireless interface. OTOH
if the interfaces configure themselves automagically without
interaction with the user, then every machine that supports LL
(which is to say, essentially every machine) that also has
a wireless interface will be potentially vulnerable to attack
at any time it can possibly be in range of an attacker
(which is to say, most of the time).

no, the problem isn't exactly caused by link-local - rather, it's
an unintended consequence of the combination of wireless interfaces
and any kind of automatic configuration.  it used to be that a
host was safe from attack if it wasn't plugged in to a network.
but with wireless+automatic configuration, the host is never
safe from attack.  (unless you can disable it somehow, but even
then the default behavior should not be to leave the host vulnerable.
that's a bit like shipping machines with + in /etc/hosts.equiv)

> The problem is a pathologically bad wireless network 

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

> If you think there are security implications, why then trot them out!

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.

> and require that they intercept lookups for private address spaces.

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.

> system call.

gross overgeneralization.  I know of apps that determine addresses to use
in referrals by each of the following means:

1. explicit configuration
2. gethostbyname (gethostname ())
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)
4. getsockname ()
5. ioctl to get list of interfaces

(to be clear: I don't know of any app that uses all of these; I know of at
least one app for each of these cases)

and as far as I can tell getsockname() isn't "normal" at all.

> address it advertises. 

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

> I don't know of any applications that would be 
> adversely affected by this.   

it happens that I work with people who write and use distributed applications,
and I've also written a couple of those applications, and I've tried to design
workarounds for NATs for such applications.  so I'm more sensitive to this 
issue than most.

> It would make sense to suggest that the 

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. 

> seen so far, I wonder if that isn't why we're seeing all this 

I am not trying to scuttle the draft, I'm trying to get it fixed.
I've tried to suggest the minimal fixes needed to make it mostly harmless.
I do think that LL needs to be disabled by default on wireless interfaces,
for reasons mentioned above.  I also think that LL needs to be able to
be disabled by any managed network on a link-wide basis, and by any host
that supports it, so that there is a workaround for networks that experience
operational problems and for apps that break.    None of these would
prevent LL from being used effectively in ad hoc networks.  The problem is,
many people in this group (including it seems one of the chairs) want LL
to be used in managed networks also, and they want it to always be enabled
so that LL-only devices can talk to ordinary hosts in managed networks.
This goes far beyond the group's charter, and it causes lots of problems.

Keith