Subject: RE: Allocating a bit in the RFC2374 Interface Identifier

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 28 Mar 2002 08:52:43 +0100

Brian and Pekka, 

  > > I am tired, and probably the situation is more complex, 
  > but this my initial
  > > reaction.  It looks like in the scenario you describe 
  > Alice and Bob
  > > would end up running different protocols:  Alice the 
  > strong one, which
  > > the attacker presumedly cannot break, and Bob the 
  > not-so-strong one,
  > > which the attacker presumedly can break.  Thus, Bob would 
  > end up running
  > > the not-so-strong protocol with the attacker, but the 
  > address used would
  > > not be Alice's address.
  > > 
  > It depends on how smart the MITM is, but I think in the 
  > simplest case,
  > Alice will hear from pseudo-Bob "I can't support strong 
  > security" (this
  > will be fabricated by the MITM) so she will be bid down, 
  > but Bob never knows
  > about this because he falsely believes that Alice can't 
  > support strong security.

=> 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?

  > > But I start to believe that I am missing here things, and that the
  > > reality is more complex than what we thought at the MIPv6 
  > DT.  That is,
  > > at least we need a mechanism for Alice to securely learn about the
  > > mechanisms Bob supports.  Maybe we could use "the bit" 
  > here, too, but
  > > my brains just fail to analyze what happens to the 
  > address-spoofing
  > > MitM in that case; maybe you could perform the attack in 
  > both directions?
  > 
  > Exactly

=> But then we end up with Alice talking to Sam
and Bob talking to Homer! So what ?

  > > But would that matter?  If there is an attacker that can 
  > spoof packets
  > > and break the less secure protocol, it can create 
  > security associations
  > > with the less-secure protocol anyway, be there the 
  > legitimite peer or not.
  > 
  > Yes. There's a recursion here, and also a moral I think: 
  > don't allow weak
  > security, period.

=> I used to wonder about the strength of RR only for
MIPv6. But after a long thread with Erik, I am 
convinced that it is as strong as the weakest 
link. I.e. ND. So I agree with Erik's statement
during the presentation in Minneapolis, which said
that securing ND will make RR seem less secure.
Hence the need for allowing this stronger mechanism
in future. I.e. put the bit in the iid. 

Hesham

--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 28 Mar 2002 11:07:40 +0200

Hesham, Brian and others,

[Note that I've changed the subject, since we are not
  really speaking about bit reservation/allocation any more.]

> like a classic DoS attack. Nothing we can do here.

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