Hesham, Brian and others,
[Note that I've changed the subject, since we are not
really speaking about bit reservation/allocation any more.]
> => I have to add myself to the list of tired/jetlagged
> people :). But, in the scenario you mention, it seems to
> me that Alice will not end up talking to Bob and Bob
> will not end up talking to Alice. And both will not end
> up talking to the MITM anyway.
> In fact, If the MITM modified the first message in the,
> lets call it SA establishment, then this SA establishment
> will fail. If it was the last message that was modified
> then it will also fail because the message will be
> inconsistent with the intial ones. So it seems to me
> like a classic DoS attack. Nothing we can do here.
> What am I missing?
Well, the devil seems to lie in the details, as usual. If we make
either Alice or Bob *committing* to the stronger scheme before
Alice contacts Bob, we seem to be safe enough. That we may do
in Mobile IPv6, but that does not, as such, require bit allocation.
That is, in the case that one of the parties has a priori decided
not to support Return Routability (RR), they just end up not
doing Route Optimization if there is an attacker on the path.
I find that acceptable.
Now that the "bit method" has been on the table for some time, I
more and more think that the whole issue has its roots in the
insecurity of Return Routability (RR). The insecurity of RR
creates the so called bombing and future bombing attacks
(see the DT writeups), and perhaps other vulnerabilities that we
just don't know yet. Thus, the real issue wrt RR is to make
stationary hosts protected against these attacks. The current RR
design, with its 5-10 minute maximum binding lifetime, restricts
an attacker's ability to perform the bombing attacks, but it does
not completely remove the threat either. The "bit method" would
provide protection for the stationary hosts, but there are also
other alternatives. Besides, the "bit method" does not protect
against bombing sites, it just protects against bombing hosts.
OTOH, as Brian has pointed out, the bit method does not provide
adequate protection against MitM bidding down in general. Thus,
_allocating_ a bit for _generic_ bidding down protection just does
not seem to work well enough. There are scenarios where it seems
to work, at least to an extend, but there are also scenarios where
it does not. Consequently, I need to withdraw my generalizations
and my suggestion that it could be used as a generic bidding down
protection scheme. Thanks, Brian, for forcing me to think harder.
It is a completely other issue then to _reserve_ a bit or a bit
pattern for future use, as Erik has suggested. The so called
"generic CGA" or "symmetric CGA" idea, originally my Michael Roe,
I guess, may have some value and may need such a bit to be reserved.
The basic "generic CGA" is to use an RFC3041 interface id to
convey semantics:
iid = hash(SEMANTICS, RND)
where
SEMANTICS = a string describing some semantics for the address,
possibly together with some parameters
RND = a freshly generated random number
Using this Alice, Alice contacting Bob would send an initial packet
that contains a Destination Option (DO) that carries the string and
the random number. Bob recieving the message recognized the DO,
hashes together SEMANTICS and RND, and compares the interface id to
the hash result.
Again, when Alice and Bob are far from each other, a MitM could
remove the DO altogether, and change the iid, too. Thus, in this
case reserving a bit seems to fail, again. However, if the
generic CGA idea is used at the local link, instead, the attacker
may not have the option of changing the iid or the packet. OTOH,
an attacker can certainly claim the iid to itself, _possibly_
leading to problems with backward compatibility.
I think this all needs much more thinking and analysis. It just
seems likely that later using a bit to indicate that an iid
encodes semantics may be a good idea, due to the desire to be
*backward compatible*. If we do not care about backward compatibility,
there is no need for any bits ever, it's just that we *may* want to
make a distinction between "old" iids and "new" iids. But maybe
it is just easier to update RFC3041, and make all hosts "new",
and not to worry about RFC3041 backward compatibility.
--Pekka Nikander
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
