Subject: LL11: Add security consideration

From: Stuart Cheshire <[email-masked]>
Date: Tue, 20 May 2003 15:42:38 -0700

I've been busy working on products for the last couple of months, but I'm 
making time now to catch up again with the Zeroconf mailing list. More 
comments will follow later today or tomorrow, but for now, here's a 
simple editorial request:

    Issue LL11: Add security consideration for the threat where
                an attacker forces address reconfiguration

    <http://www.spybeam.org/ll11.html>

    A host implementing IPv4 link-local configuration has the additional
    vulnerability to selective reconfiguration and disruption. It is
    possible for an on-link attacker to issue ARP packets that would
    cause a host to believe the address it is using is also being
    used by someone else and must be given up. Giving up the address
    and configuring another address will cause a host to break all its
    connections by switching to a new address. The attacker could force
    the host implementing IPv4 link-local configuration to select
    certain addresses, or prevent it from ever completing address
    selection. This is a distinct threat from that posed by fraudulent
    ARPs, described in the preceding paragraph.

I'd like to request some editorial softening of this text.

We need to remember the point of this document:

The point of this document is to help vendors make products that work 
well, and interoperate. This is not an academic research paper read by a 
handful of experts. This document will be read (and the draft is 
currently being read) by a lot of inexperienced implementers. Many of 
them are contract programmers who know little about networking, working 
on short-term contracts for hardware manufacturers who know even less. 
They assume that if text is in the document, it is there for a reason. 
They assume that if the document says something, it wouldn't say it if it 
didn't require some specific action on their part.

Recently I have had to persuade implementers that simply ignoring address 
conflicts is not acceptable.

They were happy with the part of IPv4LL that entailed picking a random IP 
address at boot time, but not the part about detecting conflicts, or 
changing the IP address if a conflict occurs. I'm confident that if the 
LL11 text is put in the draft as-is, then implementers will seize on it 
to justify their position that there's no need to pick a new IP address 
if a conflict occurs; indeed, it is better ("more secure") NOT to change 
IP address if a conflict occurs (and they get the added benefit of not 
having to implement that part of the code).

The LL11 text may be technically true, but is it helpful? It's like 
printing a label on car seat belts that says, "WARNING: Wearing your seat 
belt may cause you to be trapped in a burning vehicle and die." This 
statement is technically true (in the sense that it probably happened to 
someone once, or at least it could happen), but not helpful (in the sense 
that printing this warning on car seat belts would encourage people not 
to wear them, leading to thousands of deaths).

Perhaps we can add the following text:

  Nevertheless, all hosts implementing IPv4LL MUST implement
  the rules described in Section 2.5, and MUST configure a new
  IP address when required by those rules. While there is
  a theoretical risk of a host being tricked into changing
  its IP address unnecessarily, the problems that would result
  from hosts ignoring address conflicts would be even worse.

Remember that the whole basis of IPv4 LL is that it is a method to 
configure workable IP addresses in the absence of any kind of central 
authority. In the absence of any kind of central authority, no 
participant has any more authority than any other, so all participants 
have to be willing to participate with each other equally to arrive at an 
acceptable distribution of addresses. If one or more of those 
participants is malicious or destructive, then the problem fundamentally 
can't be solved without some kind of outside intervention.

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