Subject: RE: [mobile-ip] MIPv6 security issues: how to move forward

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 27 Mar 2001 08:56:15 +0200

Hello Paul, 

Good to see you on this list :)
I haven't formed an opinion on either way, but 
it is worth noting that the scenario you mention
is possible/valid and can be supported with HMIPv6 as follows:

1. The MN discovers a MAP as specified in the draft
2. The MN gets an SA with the MAP using the AAA
    infrastructure
3. The MN registers with the MAP
4. The MN uses DynDNS or SIP to register its Home 
    address. 

Which is what you were saying (I think) anyway.

We have some framework draft for key generation
/distribution using the AAA infrastructure

http://search.ietf.org/internet-drafts/draft-soliman-mobileip-routeopt-mipv6-01.txt

However, you could argue the opposite also and say that 
the amount of time it would take to get this into a standard 
protocol (the AAA bit) can also be spent into developing a 
key distribution mechanism for the basic spec.
The other disadvantage would be that it won't work if there
is no AAA. 

This is not an ad for the drafts I'm doing but I thought it 
was worth noting the pros and cons

Cheers,
Hesham

> -----Original Message-----
> From:	Paul Francis [SMTP:[email-masked]]
> Sent:	Tuesday, 27 March 2001 2:54
> To:	Charlie Perkins
> Cc:	[email-masked]
> Subject:	Re: [mobile-ip] MIPv6 security issues:  how to move forward
> 
> >
> > Well, I guess that this is a good example of how offense can be
> > taken where none was meant at all.  However, I realize that with
> 
> Or, a good example of how careless wording can lead to offense.
> 
> > all the upheaval about Mobile IPv6, one could imagine a very long
> > delay.  My belief is that we can avoid that delay.
> 
> Understood.
> 
> >
> > Did you see my earlier note to the [mobile-ip] mailing list?  In case
> > not, I'll repeat myself here:
> 
> I did see it.
> 
> > >
> > > I did, in fact, suggest that we should move forward without specifying
> > > a method by which the mobile node and correspondent node would
> > > develop a security association.  That suggestion was denied.  To change
> > > the specification by eliminating the Binding Update would be very hard,
> > > and almost pointless since it's needed for the home agent.
> 
> Nobody (as far as I know, certainly not me) ever suggested that we get rid
> of the binding update, for the very reason you state.  Only that we consider
> separating route optimization from the rest of MIPv6 so that the route
> optimization part doesn't continue to delay moving forward with this
> critical standard.
> 
> >
> > So the current plan is to build a special purpose key establishment
> > protocol, which looks doable given the design parameters.
> 
> Absolutely.  I notice that there does not appear to be concensus of what
> those design parameters are.
> 
> >
> > I do not believe that a wholesale rejustification of the basic
> > protocol is needed. Furthermore (again repeating myself):
> 
> Wow you are putting a lot of words in my mouth that never came out in the
> first place.  I don't think separating off route optimization amounts to a
> whole rejustification of the basic protocol.
> 
> >
> > In an earlier note, I said:
> >
> > >  ....   getting the home agent out of the typical routing path, is an
> > >  important aspect of the scalability of the protocol.
> 
> I said I want to hear *why not*.  The above statement is simply a
> re-affirmation that you believe route optimization is important.  I have
> said it may not be important because in most cases upon power up a mobile
> can get a home address from the visited domain and therefore is not very far
> from its (adopted) HA.
> 
> This is my position, so if you want to explain why this is wrong, you can't
> just repeat your base position...you have to justify it.
> 
> >
> > We need to design this for billions of nodes.
> 
> It doesn't matter if you have one node that rarely needs route optimization
> or a billion nodes that rarely need route optimization.  Either way route> 
> optimization is rarely needed.
> 
> Finally, I'm not exactly saying that we don't need route optimization, just
> that moving forward without is a better strategy than risking further delay
> of the whole spec.  We absolutely need basic MIPv6 today.  We can optimize
> it later when we know how.
> 
> Put another way, we have four possibilities:
> 
> 1. MIPv6 very soon with no route optimization, route optimization later
> 2. MIPv6 very soon with route optimization
> 3. MIPv6 delayed with no route optimization
> 4. MIPv6 delayed with route optimization.
> 
> I'm saying that 1 is the safest and most prudent bet right now, even at a
> risk of 3.  You are saying that going for 2 is better, even at a risk of 4.
> I think 1 is safer and more prudent because I think the probability of 4 is
> much higher than the probability of 3.
> 
> PF
>

---

From: Claude Castelluccia <[email-masked]>
Date: Tue, 27 Mar 2001 10:07:19 +0200

Hello,

An other "short-term" alternative would be to use HMIPv6 with pre-shared keys...
i.e. the MN has pre-shared keys with the MAPs it usually visits (i.e. its MAP at work,
at home, ....).

This would work as follows:
1-The MN discovers a MAP as specified in the HMIPv6 draft
2-if the MN has a pre-shared key with this MAP, it registers with it and registers its
RCoA
with its HA
3-if the MN does not have a pre-shared key it then uses Mobile IPv6 (without RO)

I think this is a pretty good tradeoff ....

regards,

Claude.

--

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/

---

From: Francis Dupont <[email-masked]>
Date: Tue, 27 Mar 2001 15:59:29 +0200

=> I agree but my conclusion is a bit different: the new scheme for
Mobile IPv6 security should be able to work with the help of AAA,
for instance:
 - message (Bx) transport must be flexible
 - trusted third party should be able to provide authentication

Regards

[email-masked]

PS: some proposals did already show that some part of the secure
Mobile IPv6 procedures can be greatly simplified by AAA!

---

From: Francis Dupont <[email-masked]>
Date: Tue, 27 Mar 2001 16:14:47 +0200

An other "short-term" alternative would be to use HMIPv6 with
   pre-shared keys...  i.e. the MN has pre-shared keys with the MAPs it
   usually visits (i.e. its MAP at work, at home, ....).
   
=> I disagree: if we have pre-shared keys then we can use certificates.
But the fact we have authentication/authorization is still right.

   This would work as follows:
   1-The MN discovers a MAP as specified in the HMIPv6 draft
   2-if the MN has a pre-shared key with this MAP, it registers with
     it and registers its RCoA with its HA
   3-if the MN does not have a pre-shared key it then uses Mobile IPv6
     (without RO)

=> it is a good one if CNs are not far from HA and MAPs.
I believe this idea doesn't apply in every cases but this is better
than the local HA in all cases where the local HA is interesting.
So we can add a requirement to the new security scheme: still work
with HMIPv6/MAPs (I think this is just a problem of parameters, isn't it?)

Regards

---

From: Michael Thomas <[email-masked]>
Date: Tue, 27 Mar 2001 07:11:34 -0800 (PST)

> 4. The MN uses DynDNS or SIP to register its Home 

   So do you envision 0 length TTL's? 

	 Mike

---

From: "Paul Francis" <[email-masked]>
Date: Tue, 27 Mar 2001 08:32:41 -0800

> with HMIPv6/MAPs (I think this is just a problem of parameters, isn't it?)

Are you saying to use HMIPv6/MAPs, but not local HAs (but rather the true
HA)?  Then won't packet still be traveling through the true HA, and
therefore be potentially long?  I don't see what HMIPv6 would buy you here.

PF

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 27 Mar 2001 10:58:11 -0600

Hi Hesham,

> the scenario you mention

You mean to say that the route optimization should be dropped from
the base standard?

Maybe newcomers to Mobile IP list (of course we welcome newcomers)
may not know, performance studies of mipv4 clearly indicated that the highest cost
incurred in Mobile IP routing stems from the dogleg routing
(ref. links at the mobile IP page of National University of Singapore, if they are
still there).
Anticipating this, mobile IPv6 was designed with route optimization.
  Now removing the route optimization will take us back to the dark ages, I am afraid.
  Another point: in IPv6 one of the RFCs was supposed to mandate binding cache
for all corresponding hosts upon which Mobile IPv6 route optimization was
built. Can someone tell us which RFC? I could not
locate it.

--behcet

---

From: Francis Dupont <[email-masked]>
Date: Tue, 27 Mar 2001 19:07:49 +0200

> with HMIPv6/MAPs (I think this is just a problem of parameters, isn't it?)
   
   Are you saying to use HMIPv6/MAPs, but not local HAs (but rather
   the true HA)?

=> yes. HMIPv6/MAPs are a bit more complex but you can use the hierarchy
for different levels of proximity. The degenerate case (one level) is
very close to your proposal.

   Then won't packet still be traveling through the true HA,

=> why will they? I believe we need a summary of HMIPv6 by an expert
(what I am not).

   and therefore be potentially long?  I don't see what HMIPv6 would
   buy you here.
   
=> argh! I've reread the last I-D about HMIPv6:
 - in basic mode you have just to bind the proper/better RCoA and
   the traffic will be optimized routed through the corresponding MAP
 - the extended mode does essentially the same thing (just replace
   the RCoA by an alternate-COA).
Claude or Hersham should be able to explain more and more clearly...

With Eric's site-local stuff it should be easy to keep the traffic
from the site inside the site.

Regards

PS: IMHO the local HA function is one of the functions of HMIPv6
even if this is not an essential one.

---

From: Francis Dupont <[email-masked]>
Date: Tue, 27 Mar 2001 19:28:20 +0200

Another point: in IPv6 one of the RFCs was supposed to mandate
   binding cache for all corresponding hosts upon which Mobile IPv6 route
   optimization was built. Can someone tell us which RFC? I could not
   locate it.
   
=> no, the proposal is/was to make the support of the home address
destination option mandatory (this provides a direct MN->CN routing
without the ingress filtering issue). It is not in a RFC but in
Mobile IPv6 I-Ds (last is #13) with the definition of this option
and of the binding cache.

Regards

---

From: "Paul Francis" <[email-masked]>
Date: Tue, 27 Mar 2001 13:48:26 -0800

Ok, thanks for the explanation.  I'll read the draft again too.  Last I read
it, it was at the same time as reading a bunch of other drafts, and its all
muddled in my head.

PF