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

From: Stuart Cheshire <[email-masked]>
Date: Mon, 23 Jun 2003 20:37:46 -0700

>> 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."
>
>We disagree.  It says something like 'doing this exposes you to
>vulnerabilities.'  Its like driving - you should know that you
>could be smooshed every time you go on the freeway.  You don't
>have to go on the freeway, but it would be extremely negligent
>of your driving instructor to not let you know what you are facing.
>You should not neglect what precautions you have like seat belts
>insurance, etc (higher layer security protocols, no assumptions
>that no one would ever perform an active attack as described).

I'm afraid you are still not seeing the point I am making.

The point is not about the security issue. The point is about the implied 
response to the security issue.

Having understood the security issue, is the correct response to not 
implement IPv4LL AT ALL? Or, is the correct response to implement IPv4LL, 
except the part about changing the address in response to a conflict?

If the former, this is an internally-consistent and reasonable response 
to the problem.

If the latter, this is a completely bogus and pointless response to the 
problem: The entire purpose of IPv4LL, the beginning and end of its 
reason for existence, is one thing and one thing only: An algorithm for a 
group of cooperating hosts, in the absence of any other authority, to 
arrive at a set of mutually unique IP addresses. That its only purpose. 
If you implement IPv4LL, except the part about ensuring that each host 
has a different address, then what have you implemented? Nothing.

I am very serious about this. If there is anyone on this list willing to 
argue in favour of the "Implement IPv4LL but don't change address on 
conflict" position, then we need to have a serious discussion about what 
it is that IPv4LL is supposed to be doing. IPv4LL does *NOTHING* except 
maintain mutually unique IP addresses in the absence of DHCP or manual 
administration. What else is there for it to do?

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

---

From: Erik Guttman <[email-masked]>
Date: Tue, 24 Jun 2003 12:09:52 +0200

> except the part about changing the address in response to a conflict?

The correct response is to make an advised decision whether to implement
it or not.  If one implements the protocol, with the risks in mind,
one can take the necessary precautions - for instance using application
layer security, or whatever.  IPv4LL is absolutely no different in this
respect than any other protocol published by the IETF.

If an implementor does not care about standards compliance, she or he
will probably ignore the standard.  If interoperation and vendor
reputation (delivering quality networking products to the market) is a
high priority, the implementor will not ignore requirements.

You are suggesting toning down security considerations which have 
achieved consensus in the WG.  Your argument is that this will avoid
alarming implementors, that the current wording tempts implementors to
ignore requirements.  This does argument does not persuade me.  What are
others' opinions?

Erik

---

From: Robert Elz <[email-masked]>
Date: Tue, 24 Jun 2003 18:09:58 +0700

Date:        Mon, 23 Jun 2003 20:37:46 -0700
    From:        Stuart Cheshire <[email-masked]>
    Message-ID:  <[email-masked]>

  | If the latter, this is a completely bogus and pointless response to the 
  | problem: The entire purpose of IPv4LL, the beginning and end of its 
  | reason for existence, is one thing and one thing only: An algorithm for a 
  | group of cooperating hosts, in the absence of any other authority, to 
  | arrive at a set of mutually unique IP addresses. That its only purpose.

Yes, and that is fine.   And regardless of whether or not addresses
are changed upon late conflict detection does not make much difference
to that.

That is, the mechanism doesn't have to be perfect in every possible
scenario to be useful, does it?

  | If you implement IPv4LL, except the part about ensuring that each host 
  | has a different address, then what have you implemented? Nothing.

Of course, so you do implement that part, and make sure you get a
unique address.   Then, if it later turns out you were wrong, one
reasonable option is to just say "I give up".

That is, it works most of the time, but in some rare situations, it
might not.

Aside from deliberate attacks, which nothing in the LL draft will allow
a host to survive, the only way this problem can occur, that I'm aware
of, if when two previously independent links are connected to become
one link (bridging enabled, or whatever).

In that circumstance, if address conflicts occur, it is entirely
reasonable for a host, if it wants, to simply cling onto its address
and refuse to let go.   If the other host changes, then everything
is OK, there was no real need for both of them to alter addresses.
If both alter, that's OK too.   If both are determined to hold their
addresses, then those two are effectively locked off the LL link.

For some hosts, that may very well be the best solution - I can't
talk, but I will make sure the other guy can't either.   It all
depends just what the host is doing.

  | I am very serious about this. If there is anyone on this list willing to 
  | argue in favour of the "Implement IPv4LL but don't change address on 
  | conflict" position, then we need to have a serious discussion about what 
  | it is that IPv4LL is supposed to be doing. IPv4LL does *NOTHING* except 
  | maintain mutually unique IP addresses in the absence of DHCP or manual 
  | administration. What else is there for it to do?

You are wanting perfection where no prefection is possible.   If you claim
that IPv4LL should not exist if it fails to guarantee that every host
(implementing it) will always get a usable v4LL address that it can use,
then you might as well abandon v4LL now, as we know that is simply not
possible to achieve.

Much better is to abandon that requirement, and just allow it to work
most of the time.

Also note, that no-one is requiring that hosts hold onto their addresses.
Just that the implementor consider the issues involved with changing,
and whether that allows an unreasonable security issue for the host.

kre