Subject: RE: Using "a bit" as a protection against bidding down / for some thing else

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 28 Mar 2002 15:02:06 +0100

So just to make sure we're on the same 
wavelength here. The scenario Brian mentioned
will not be an issue for bidding down attacks
related to mobility. I understand Pekka's note
to mean that this bit might not solve all of 
our bidding down attacks for all cases. 

So I still think it's worth having it for those
cases where it will be very important, like 
MIPv6. This is clearly something that can't be
added on later. i also believe that the CGA 
concept will be a potential solution to ND. 

Hesham

  > -----Original Message-----
  > From: Pekka Nikander [mailto:[email-masked]]
  > Sent: Thursday, March 28, 2002 10:08 AM
  > To: Hesham Soliman (ERA)
  > Cc: Brian E Carpenter; [email-masked]; Jari Arkko;
  > [email-masked]; Erik Nordmark
  > Subject: Using "a bit" as a protection against bidding down / for
  > something else
  > 
  > 
  > 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-masked]
--------------------------------------------------------------------