Re: LL11: Add security consideration

    Date:        Wed, 4 Jun 2003 14:36:42 -0700
    From:        Stuart Cheshire <[email protected]>
    Message-ID:  <[email protected]>

  | If it is "the implementers", then that implies we should put information 
  | in the document so that implementers can each think carefully about this 
  | for themselves, arrive at their own separate decisions, and produce a 
  | bunch of implementations that don't do the same thing. Is that what we 
  | want?

I know you're expecting a "no way" answer to that one, but actually,
yes, that's exactly what I think we want.   Different implementations
have different needs.   Keeping on operating, no matter what, is
going to be useful for some implementations, and for those, address
conflict causes immediate selection of a new address, so there is
something that works may be the best solution.

However, implementors need to weigh that against the possibility that
after having been connected for some time, a "bad guy" can drive them
off the net, trivially easily, if they have adopted that strategy - all
that is needed is to claim the address, and then defend every other
address that the node tries.   Bye bye node, and it only takes a second.

Some implementations might actually prefer to keep actively attempting
to use the address upon detecting a conflict.   Two such implementations
will deadlock, until one of them is removed, but depending upon the needs
of the implementation in question, that may be the best result - that is,
only human activity (as in cycling my power) can cause me to abandon
what I was doing and start again.

Implementations only all need to do the same thing when that's required
for interoperability.   Here, that's not needed.

  | When you say you want to "present a tradeoff" to someone, it implies 
  | giving a balanced argument, so that they can weigh up all the evidence on 
  | both sides and reach their own informed decision. Is that what we're 
  | doing here?

Perhaps not, but it is better to at least give some hint that there
may be some problems that should be investigated, than to completely hide
the problem and hope no-one notices.

  | As it stands, the paragraph reads like something saying, "This standard 
  | says you should pick a new address if you detect a conflict; here are 
  | some reasons why making your implementation actually do that would be a 
  | terrible mistake."

When reduced to that simple form, it sounds fairly bizarre.   Maybe we
should simply stop saying that a new address "should" be picked, and just
say that it may be ?    With perhaps some of the reasons why doing so, or
not doing so, will sometimes be the best choice.

kre