Brian E Carpenter wrote:
> This I still don't understand. A header option can assert "weak"
> or "strong" (or better, "algorithm ID")
This works to express preference for which type of mechanism the node
wants to use for route optimization. But it does not work if what you want
to express is: "I don't want route optimization." By simply inserting the right
fields in the (potentially spoofed) packet, anybody can insert you in the
"I implement and practice route optimization" camp, and then exploit
weaknesses thereoff to attack you.
> just as well as magic
> bits in an address, without overloading the address and stealing
> bits already allocated in EUI-64. A header option can also be
> cryptographically authenticated.
>
> I fully understand why we need bidding-down protection and the
> newly suggested step down procedure. I just can't see a case
> for putting the required semantics in the address.
In all this, it is essential to think about the effects on unsuspecting, stationary,
legacy IPv6 nodes (let's call them non-mobile nodes).
You're right in that it is not absolutely necessary to separate "strong"
from "weak" addresses. It is enough to expect all mobile nodes to prove
cryptographically that their address is usable for "route optimization." This has
been referred to
in some previous messages, but essentially it involves deriving ALL route-optimisable
addresses to be derived from a secure hash (not necessarily of a Public Key) and
require
proof of that derivation as part of the route optimisation procedure.
The problem is that the only known way to do that has IPR concerns.
There are folks working on solving those issues, but we don't know if that'll ever
happen.
In the absence of that solution, the only thing we can think of is to separate
"weak" from "strong" adresses to implement the following solution:
Think of "strong" addresses as expressing 2 things to the peer:
"(1) I do not engage in redirection operations on my address, or, if I do,
(2) I only do so with cryptographically strong mechanisms in which I will prove to
your
satisfaction that I do have authorization to use that address"
Think of "weak" addresses as expressing one thing to the peer:
"(3) I engage in redirection operations on my address and do not intend to
prove conclusively that I do have authorization to use this address (e.g. RR
is ok)"
(3) is a viable tradeoff for mobile nodes to make: yes, there are some
vulnerabilities, but
they get route optimization in a lightweight manner with a mechanism free of
intellectual
property.
For unsuspecting stationary nodes that are not interested in redirecting their
addresses,
(3) is not a viable tradeoff. It essentially means they only get the negative side of
the
tradeoff (they are now potential victims of the vulnerabilities in RR) as they are not
at all interested in the benefit (route optimization).
If we unleash RR on the world, very likely victims of route optimization attacks
are poor unsuspecting stationary nodes that may very well have no interest ( or
knowledge)
whatsoever on mobility.
Mallory could just claim that address is his and insert a binding cache entry (a host
route)
into any correspondent node. This will break communications between the correspondent
node and the stationary node. If, on the other hand, the correspondent node can tell
it is
(1) or (2) above, this is no longer possible, as it will expect a cryptographic proof
of
authorization. If the attacker can produce it, we have much more serious problems.
Another consideration is that today, weaknesses in ND may be more immediate problems
than the above attack. However, the RR attack does not necessarily make use of those
weaknesses in ND. If we ever solve these weaknesses (there's several ideas currently on
how to do this), then RR vulnerabilities will remain as the largest weakness in IPv6.
And
unless we put in some mechanism to opt out of RR *from the very beginning* we will have
to live with the pollution of the RR oilspill for the entire lifetime of IPv6.
Hope this helps,
-gabriel
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
