Subject: RE: security between MN and the MAP (was Re: [Mipshop] RE: IESG evaluation - Steve Bellovin's comments)

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 17 Nov 2004 16:53:18 -0500

> > => Hmm, are you saying that a MN cannot attach to several
 > > HAs? That would contradict the MIPv6 spec. A MN can certainly
 > > send BUs to many HAs. 
 > 
 > not as many MAPs that a MN might encounter. in addition, HA
 > and MN belong to the same administrative domain.

=> The administrative domain issue is not relevant, provided
that we add the text discussed below. 
Regarding the number of MAPs. The MN is expected to be associated
with one at most and two in a transient manner during an
inter-MAP handover. 

Let me clarify the _real_ difference between the MN-MAP
relationship and MN-HA one, which is discussed in the draft.
The real difference is that the MAP does not care which address
the MN gets, provided that it is not used by another MN. So
it's a simple "internal" DAD issue. This is not the case for the MN-HA.
The MN MUST get one of the addresses that are assigned to it
by the HA. So in this sense, the MN-MAP security is easier.

The price for this simplicity is that the MAP has to trust
the MN's cert and vice versa, which is the issue being
addressed right now. But this trust is aggregatable, i.e.
each entity need only trust the CA of the other entity.

Hesham 

 > 
 > >  > 
 > >  > between the MN and the HA, one could use shared secrets with
 > >  > IKE in addition to certificates. but between the MN and the
 > >  > MAP, I dont see shared secretes being used. 
 > > 
 > > => This is already stated on the list and in the draft.
 > > 
 > >     you probably
 > >  > need certificates, which means, that unless the MAP is able
 > >  > to verify the certificate presented by the MN, the MN wont
 > >  > get HMIPv6 service. similarly, unless the MN can verify the
 > >  > certificate presented by the MAP, it cant use HMIPv6.
 > > 
 > > => Again, this is already agreed on this list and will be 
 > > added to the draft. 
 > 
 > good. it wasnt clear that this was the conclusion.
 > 
 >  > I'm not sure if you're asking for
 > > additional words here?
 > 
 > I will wait for the revised security considerations section.
 > 
 > Vijay
 > 

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================

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