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 PROTECTED]] > Sent: Thursday, March 28, 2002 10:08 AM > To: Hesham Soliman (ERA) > Cc: Brian E Carpenter; [EMAIL PROTECTED]; Jari Arkko; > [EMAIL PROTECTED]; 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 PROTECTED] --------------------------------------------------------------------
