Subject: Re: LL11 Security consideration for the threat where an attacker forces address reconfiguration

From: Stuart Cheshire <[email-masked]>
Date: Wed, 30 Jul 2003 18:27:13 -0700

Recap (it's been a while):

We were discussing whether the "Security Considerations" text might lead 
some implementers to conclude that it's better to cling to a conflicting 
address and fight over it, rather than give up and pick another.

I wrote:
>What is the typical implementer to conclude?
Robert Elz wrote:
>That there is an issue that needs careful consideration, and for which
>there is not one right answer that will necessarily suit everybody.

This was precisely the point I was making:

If a vendor of home Hi-Fi equipment hires me as a consultant to advise 
them, I'll tell them the device should pick a new address on conflict.

If a vendor hires Robert Elz as a consultant to advise them, he will tell 
them the device should cling to its address and not pick a new one.

This is no good. The spec needs to define the rules for the protocol 
objectively, not subject to individual interpretation.

I wrote:
>I do not want a document with this ambiguity in it.
Robert Elz wrote:
>I do.   Even more than is there now preferably.

This is no good.

I wrote:
>If there's a hidden agenda that some people do want implementers
>to make products that cling to their address no matter what,
>then we need to get that out in the open and discuss it properly.
Robert Elz wrote:
>There is nothing hidden about it - there's no question but that for
>some environments (not all, certainly) keeping addresses rather than
>silently releasing them is the right choice.

So, it is very clear. We have absolutely no prospect of agreement on 
this. The Working Group needs to come to a decision. Are devices required 
to pick a new address on conflict or not?

I believe that in the hostile environments Robert Elz is talking about, 
IPv4LL is simply not suitable at all, so warping it to accommodate an 
environment where we know it can never work anyway, is pointless. We 
should just say that IPv4LL requires cooperating hosts, and if you don't 
have cooperating hosts, then don't use IPv4LL. It's that simple.

When it is not possible to please everyone, the Working Group needs to 
make a decision and accept that some group of people will be unhappy with 
the result. To try to please everyone just results in unending stalemate. 
It has now been five years since IPv4LL shipped in Windows 98 and Mac OS 
8.5.

The way to make a protocol specification is not to make it sufficiently 
vague that all of the participants are able to interpret it differently, 
such that they all think it can be read to support their point of view.
That gives only the illusion of consensus, not real consensus.

Let's try to make a decision here, and make the document state that 
decision clearly, so that it's not subject to individual 
re-interpretation.

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

---

From: Alex Karahalios <[email-masked]>
Date: Wed, 30 Jul 2003 18:34:45 -0700

If we are "voting" on this then I vote for devices picking a new 
address.

Alex Karahalios

---

From: "Philip Nye" <[email-masked]>
Date: Thu, 31 Jul 2003 09:26:30 +0100

> From: "Stuart Cheshire" <[email-masked]>
>

The draft seems fairly clear to me - Section 2.5 says that you have a single
chance to defend your LL address but MUST reconfigure if the conflict
persists.

Section 5 points out some risks and says that security is up to the
implementer. It notes that 2.5 requires reconfiguration. It recommends that
you attempt to close existing connections as a part of reconfiguring your
address. I cannot see that section 5 provides a getout clause for an
implementer who doesn't want to reconfigure.

Is there an ambiguity that I have missed?

Philip

---

From: Robert Elz <[email-masked]>
Date: Thu, 31 Jul 2003 21:31:19 +0700

Date:        Wed, 30 Jul 2003 18:27:13 -0700
    From:        Stuart Cheshire <[email-masked]>
    Message-ID:  <[email-masked]>

  | If a vendor hires Robert Elz as a consultant to advise them, he will tell 
  | them the device should cling to its address and not pick a new one.

No, I wouldn't.   You could only come to that conclusion if you
were stuck in the mire of believing that everything must do the same
thing.   As I believe I have said before (but yes, it has been a
while), not all devices are the same.   For a Hi-Fi device, I would
most probably just pick a new address if there was a conflict.

On the other hand, for my laptop, that is to be controlling that
Hi-Fi device, and most likely connecting to my home file server, and
running who knows what else, I will instead make quite sure that it
does not allow its address to be yanked from under it (nor the address
of the file server) by some misbehaving piece of audio equipment.

  | This is no good. The spec needs to define the rules for the protocol 
  | objectively, not subject to individual interpretation.

Nonsense.   That's important only when it is required for interoperability.
It isn't here, there is no interoperability with LL addresses, beyond
the technique with which they're chosen (and defended) which isn't in
issue here.

All that failing to pick a new address can ever do, is to (perhaps) cause
the device to fail to be able to communicate on the network (using LL
addresses).    That's certainly something to take into account when
deciding what approach the implementation should adopt, but it doesn't
mean that the only strategy is to simply follow the herd and always do
what everyone else does.

There is no impact on anyone else at all - if the other device (the one
with whom we're conflicting) is doing as you wish, and simply picks a
new address, then it keeps on functioning as well as that allows (regardless
of what my device does).  If the other device is also stubborn, and
decides to hang onto its address, then neither one of us is going to be
able to function, until we are (by whatever means) reset.  That is the choice
the implementors of those devices made (and the purchasers of the devices
when they picked them over other available options).   You seem to
believe that is unacceptable, but I have no idea by what right you get
to tell my system that it is always required to work, are you going to
remove my control of the power switch as well?

  | I wrote:
  | >I do not want a document with this ambiguity in it.
  | Robert Elz wrote:
  | >I do.   Even more than is there now preferably.
  | 
  | This is no good.

I'm not sure if I said last time, but I think I did, "ambiguity" is of
course not good - what there should be is an implementation choice.
The consequences of each choice should be clearly spelled out, then
the implementor should choose which is best for the device in question.

  | I believe that in the hostile environments Robert Elz is talking about,

This need not relate to a hostile environment.   Just consider a device
that powers up while a bridge/hub is down, or disconnected (so it is on
an isolated, but working, LAN segment).   It (by chance) happens to pick
an address that is the same as my home fileserver (which lots of other
things depend upon remaining stable to work, changing NFS server addresses
is not done lightly).   Then, the bridge is reconnected, and this radio,
or speaker, or something, is reconnected to the rest of the house, and
the address conflict appears.   It happily goes and picks a new address
(but it has only a very slow processor on a slow link, so this takes some
time).   Meanwhile my fast server has sent its 2nd allowed query, still
got the "I have this address" from the speaker, and according to your
theory, is now required to give up its address, completely wrecking
everything with a connection to it, for no good reason at all?

But if it were a truly hostile environment ...

  | IPv4LL is simply not suitable at all,

How is that supposed to work?   How can the speaker/tuner/amp/... possibly
know whether it is a hostile environment or a friendly one?   It
wasn't that long ago when there were people in this group (in fact,
they're probably still here) who wanted all devices to always have LL
addresses, in all circumstances, no matter what.

  | We 
  | should just say that IPv4LL requires cooperating hosts, and if you don't 
  | have cooperating hosts, then don't use IPv4LL. It's that simple.

It isn't that simple, really.   One of the frequent supposed uses for
LL addresses is for "friends who meet on a train" (or at the bus terminal,
or in a hotel bar, or ...).    How could such an environment, which is
almost by necessity, at least potentially hostile, ever to use LL
addresses if that rule were in place.

And in any case, as above, even in friendly environments, the correct
behaviour for every host is simply *not* to simply let go of addresses
because someone else claims one.  Once again, it depends upon the device.

  | When it is not possible to please everyone, the Working Group needs to 
  | make a decision and accept that some group of people will be unhappy with 
  | the result.

Yes.   And LL11 was closed with the WG having made a decision some
time ago.   If this is your attitude, why are you still debating this
point?

  | The way to make a protocol specification is not to make it sufficiently 
  | vague that all of the participants are able to interpret it differently, 
  | such that they all think it can be read to support their point of view.

No, of course not.   Nor is that the aim.   The aim is to make sure that
people (implementors) understand the choices that they have to make.
Choices do not imply vagueness.  Nor are choices necessarily evil.

kre