Hesham,
Agreed. One of the later emails of Pekka (he is really trying hard) is clearing
it up a bit i.e the purpose of the bit is not to prevent MiTm attacks (as you say)
but to prevent the creation of false bindings. May be all the details (there is
quite a bit of them) are not coming together in one piece. May be the promised
draft might clear this up I guess.
-mohan
> -----Original Message-----
> From: Hesham Soliman (ERA) [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, April 04, 2002 12:29 AM
> To: Mohan Parthasarathy; Hesham Soliman (ERA); Brian E
> Carpenter; Pekka Nikander
> Cc: Glenn Morrow; [EMAIL PROTECTED]; Keith Moore; Jari Arkko; Pekka
> Savola; [EMAIL PROTECTED]; Erik Nordmark
> Subject: RE: Allocating a bit in the RFC2374 Interface Identifier
>
>
>
> Mohan,
>
> 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 ?
>
> => The bit was not suggested to remove MiTM
> attacks, it was suggested to disallow bidding
> down attacks by a MiTM. I.e. if the bit was
> replaced by some other piece of information
> in the packet, this can always be modified
> and both sides will simply revert to a weaker
> mechanism. But having it in the address will
> mean that, if modified, the SA can not be
> established, at least not with the intended
> identities. The identities being the owners
> of the IP addresses in question.
>
> Hesham
>
