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

 
>
> 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?
>
I think the problem is in using the bit to convey whether you want
a secure exchange or not. And at the end of the exchange (which
effectively created a binding in the mobility case), MN thinks
it established securely with CN which it has not i.e I set the bit
to indicate I want a secure exchange with some arbitrary node (CN),
but this does not really gurantee anything. It does not matter whether
you set the bit or not. It all depends on whether MiTM will occur or not.

So, in the absence of MiTM attack, the bit reaches CN safely and hence tells
CN whether MN needs  a secure exchange or not. But in the
absence of MiTM attack, RR seems sufficient and hence the bit
is not needed. What am I missing ?

-mohan

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

Reply via email to