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

Hi Wassim.

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

Take care,
- Christian

-- 
Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH)
www.tm.uka.de/~chvogt/pubkey/

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
Mipshop@ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop