Subject: RE: [Mip6] Draft on Securing Home Agent List

From: "COMBES Jean-Michel RD-MAPS-ISS" <[email-masked]>
Date: Mon, 11 Jul 2005 16:01:06 +0200

> But here, I think, the simplest solution is to use IPsec. 
> Hoping a HA manager knows all his HAs, it is simple to him to 
> set up IPsec between them based on pre-shared keys or certs 
> if SEND is deployed :)

Forget this ... I forgot that the destination address may be a multicast address :(

Regards.

JMC.

France Telecom - R&D Division - MAPS/NSS   
Jean-Michel COMBES, Internet/Intranet Security
E-Mail: [email-masked]
Phone: +33 (0)1 45 29 45 94
Fax: +33 (0)1 45 29 65 19
Mobile: +33 (0)6 07 29 30 16 

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De 
> la part de COMBES Jean-Michel RD-MAPS
> Envoyé : lundi 11 juillet 2005 15:46
> À : Radhakrishnan.S; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Objet : RE: [Mip6] Draft on Securing Home Agent List
> 
> Hi,
> 
> The problem with SEND is that it only proves the router has 
> the rights to be a router for some prefixes (linked to the 
> router's certs).
> But here, I think, the simplest solution is to use IPsec. 
> Hoping a HA manager knows all his HAs, it is simple to him to 
> set up IPsec between them based on pre-shared keys or certs 
> if SEND is deployed :)
> 
> Regards.
> 
> JMC.
> 
> France Telecom - R&D Division - MAPS/NSS   
> Jean-Michel COMBES, Internet/Intranet Security
> E-Mail: [email-masked]
> Phone: +33 (0)1 45 29 45 94
> Fax: +33 (0)1 45 29 65 19
> Mobile: +33 (0)6 07 29 30 16 
>  
> 
> > -----Message d'origine-----
> > De : [email-masked] [mailto:[email-masked]] 
> De la part 
> > de Radhakrishnan.S Envoyé : lundi 11 juillet 2005 15:11 À : 
> > [email-masked]; [email-masked]; [email-masked]; 
> > [email-masked]; [email-masked] Objet : Re: 
> [Mip6] Draft on 
> > Securing Home Agent List
> > 
> > Hi,
> >       This draft has brought out an interesting problem. SEND could 
> > help solve this problem. So why this method??????
> > 
> > Anyway, i am posting few comments i have:
> > (1) I feel the use of STALE and REACHABLE in places referring to 
> > states in both HA List and NCE is little confusing. Maybe use of 
> > different words like VALID/INVALID to indicate state of an 
> entry in HA 
> > List would be better.
> > 
> > (2) Sec 3.1
> >      " o If the entry exists and it state is STALE then 
> simply ignore
> >         this RA message."
> > -> Only if RA parameters are identically same with prev 
> one, isnt it?
> > 
> > (3)  In section 3.1
> > -> What about RAs with global address as source address????
> > 
> > (4)  In section 3.4
> > "      o In case the DHAAD reply message becomes more then 
> > PMTU then HA
> >         must include self Home Agent address. This will ensure at 
> > least
> >         one valid reachable home agent address"
> > -> Very good thought. I feel making it mandatory for the HA
> > to carry its
> > address in HA list in DHAAD reply irrespective of message size will 
> > guarantee atleast one valid reachable HA. :-)
> > 
> > (5) What happens in case of a node replying with bogus NA when HA 
> > sends NS??? SEND can help in such a case. maybe security 
> > considerations section needs to be updated for such a scenario.
> > 
> > (6) There are grammatical errors at quite few places and missing 
> > punctuations.
> > 
> > Regards
> > Radhakrishnan
> > ----- Original Message -----
> > From: "Sachin" <[email-masked]>
> > To: <[email-masked]>; <[email-masked]>; <[email-masked]>; 
> > <[email-masked]>
> > Sent: Monday, July 11, 2005 5:08 PM
> > Subject: [Mip6] Draft on Securing Home Agent List
> > 
> > 
> > > Dear MIP6 Group
> > >
> > > We have submitted a new internet draft for securing home
> > agent list in
> > > Mobile IPV6. A URL for this Internet-Draft is:
> > >
> > > http://www.ietf.org/internet-drafts/draft-dutta-mip6-ra-00.txt
> > >
> > > Technical Summary:
> > > The home agent list is learnt by receiving the RA 
> messages. So any 
> > > rogue node on the link can send spurious RA on behalf of
> > non existent
> > > nodes. This results in non-reachable and non-existent
> > entries in the
> > > home agent list causing delay in getting service for a MN or not 
> > > getting service at all.
> > >
> > > We are looking forward for your feedback. Thanks in advance
> > for your
> > > kind consideration.
> > >
> > > Best Regards
> > >
> > > Mao Shanxiang , Suraj , Deshbandhu &  Sachin
> > > (Authors)
> > >
> > >
> > > _______________________________________________
> > > Mip6 mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/mip6
> > >
> > > 
> > 
> > 
> > _______________________________________________
> > Mip6 mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/mip6
> > 
> 
> _______________________________________________
> Mip6 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mip6
> 

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

---

From: [email-masked]
Date: Mon, 18 Jul 2005 12:18:50 +0300

Hi Jari,

> >My feeling is that if SEND is available, using it to solve this problem
> >is a good idea; however also stating that if SEND is not available, then
> >some configuration mechanisms probably will solve this issue.  I think
> >  
> To me, SEND is the right choice, if people think the configuration
> scheme is insufficient as a solution. But I think it would be
> helpful for the IETF to decide what level of a solution they want
> and recommend that, rather than providing a number of
> different solutions.

Re-reading the draft, I agree that SEND seems to be a good tool to solve
this problem.
 
> >this is relevant information to the problem - for example even if you
> >have SEND implemented and use it to Secure the Home Agent list - what
> >happens when you roam to a network without SEND? A hostile network probably
> >wouldn't deploy SEND in the first place, so the mobile node would not
> >have the ability to secure its home agent list.
> >  
> The intent of this draft was to secure the process where
> the home agents on the home link discover each others'
> presence. As a result, its only the home network admins who
> get to decide how to do it; the availability of various tools
> in the visited networks is not an issue.

Ack.

John