Re: SEND-based protection and related confusions (was RE: AR compromise (Re: [Mipshop] Review ofdraft-haddad-mipship-hmipv6-security-04))

[Wassim Haddad <[e-mail]>]

Hi Christian,

On Wed, 2 Aug 2006, Christian Vogt wrote:

> > Finally, there is also a draft called OMIPv6_CGA_CBA that you should
> > start reading because it is based on the same approach (i.e., CGA)
> > that you may consider also.
>
> Although I'm sure you mean this, it's worth emphasizing that
> draft-arkko-mipshop-cga-cba uses only CGA for IP address ownership
> verification.  It does not use SEND.
>
> Just for clarification.

=> yes that's was my intention.

Thanks for the note!


Cheers,

Wassim H.

>
> Wassim Haddad wrote:
> > On Tue, 1 Aug 2006, Narayanan, Vidya wrote:
> >
> >> I want to get a clear understanding myself on what SEND provides
> >> and what it doesn't.
> >
> > => I don't think this is the right ML for that. There are two RFCs
> > about SEND that you should first start to read then there is another
> > proposal on securing FMIPv6 which is based on the same approach and
> > third there is ongoing proposal on optimizing SEND which you should
> > also consider reading. Finally, there is also a draft called
> > OMIPv6_CGA_CBA that you should start reading because it is based on
> > the same approach (i.e., CGA) that you may consider also.
> >
> > Now if you don't like (as I told your colleague) any solution based
> > on SEND because you don't like SEND itself then this is really
> > unfortunate!
> >
> >> I seem to have an understanding that is different from some views
> >> here. For instance, the following email seems to allude that SEND
> >> protects against AR compromise.
> >
> > => Again this is not the ML to discuss what SEND does and does not.
> >
> >> In some previous discussions, I heard the views that once an MN and
> >> AR use SEND, that link is now secure. Either I am terribly mistaken
> >> in my reading of RFCs 3756, 3971 and 3972 or these misconceptions
> >> really need to cleared up, before we build more protocols based on
> >> SEND.
> >
> > => There is a difference between the "link is secure" and building
> > trust between two entities which enables you to know if a message has
> > been sent by the same entity or not. This is exactly what enables you
> > to build on top of such feature. The problem is that when you feel
> > obliged to accept this one you bring back immediately the "AR
> > compromise" and we start again!
> >
> >> I want to state upfront that I have nothing against enhancing SEND
> >> to protect other protocols or providing other functionality.
> >
> > => I have a strange feeling that it is actually exactly the opposite
> > and you know very well why.
> >
> >> I am only questioning some of the fundamental assumptions being
> >> made about the protection provided by SEND itself. Here are some
> >> points that I think are worth getting clarity on.
> >
> > => and this is NOT the ML to do that. All what you're trying to do is
> >  misleading the others.
> >
> >> 1. SEND protects ND messages only - this does not extend any
> >> protection whatsoever to any future messages exchanged between the
> >> MN and any entity in the network, including the AR.
> >
> >> 2. SEND itself DOES NOT protect against AR compromises. In fact,
> >> RFC3756 seems to explicitly bring this to attention in section
> >> 4.2.3 - "There are currently no known solutions for any of the
> >> presented three trust models."
> >
> > => Add to this that when you compromise an AR there is a list of
> > attacks that you can do which are much more interesting than what you
> > are trying to bring to attention in HMIPsec which can lead to simply
> > denying the MAP service.
> >
> >> 2a. In the case of SEND itself, the AR is one of the signaling
> >> endpoints and nothing can be done about compromise of that.
> >>
> >> 2b. In the case of protocols such as HMIP, the AR has no need to be
> >>  involved in the protocol.
> >
> > => This is a clear proof that you don't want SEND involved!
> >
> >
> > Regards,
> >
> > Wassim H.
>
>
>
>

_______________________________________________
Mipshop mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mipshop