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

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

  | 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