Subject: [mobile-ip] Why not IKE? (was: Re: Drafty draft about key establishment for Binding Update)

From: James Kempf <[email-masked]>
Date: Mon, 26 Mar 2001 10:05:28 -0800 (PST)

Mohan,

>Sorry for the confusion. I was summarizing the IESG (and others) concerns
>about using AH for solving the mobile IPv6 security problem.
>I did not mean to use the word "scale". Hence, if we don't want to use AH
>and not solve the authorization problem, why can't we just use the IKE
>part alone ? If this is also considered heavy weight, all new solutions
>should be compared against this. 
>

I won't presume to say I can contribute much to the security discussion, but
one concern with IKE is deployment. Some network operators may not
want to deploy IKE. Alternative solutions for key distribution (such
as AAA) may be more desirable.

		jak

---

From: Michael Thomas <[email-masked]>
Date: Mon, 26 Mar 2001 10:13:35 -0800 (PST)

> as AAA) may be more desirable.

   Whatever the solution is, it better not rely on
   AAA exclusively. There is no requirement that AAA
   be run uniformly. In fact, a pretty large percentage
   of the devices on the net in the here and now do 
   not use AAA _at all_. The one I'm typing on right 
   now is a fine example.

	  Mike

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 26 Mar 2001 21:33:31 +0300

>    not use AAA _at all_. The one I'm typing on right

To add a tidbit.  In order to cover all cases _really_ securely,
IKE would require a global PKI that contains information about
who "owns" which address, i.e., what is the home address of a
given MN.  In technical terms, the PKI would have to include
information to securely bind a home address and a public key together.

The same applies to AAA.  When you scale up AAA, at some point you
must stop assuming that all parties in the AAA are honest.  Once you
do this, you must start including authorization information for the
AAA parties, basically saying "this ISP owns this block of IP addresses"
for each ISP.  AFAIK, such the current AAA architecture does not fully
cover that, not discussing about the associated deployment problems.

Thus, in both cases, establishing the required infrastructure would be 
quite hard and expensive.  

http://www.ietf.org/internet-drafts/draft-nikander-ipng-address-ownership-00.txt
tries to clarify this and other related problems.

--Pekka

---

From: "Paul Francis" <[email-masked]>
Date: Mon, 26 Mar 2001 12:43:02 -0800

May I suggest a proposal on how to progress standardization of MIPv6?

Take out all of the "route optimization" parts and run it basically like
RFC2002 is run today, including the ability to assign a local home address
to a mobile node in a visited domain.  This is basically what Mohan
suggested in an earlier email (and perhaps others), but I would like to add
my voice to that sentiment.

This would allow us to move forward with standardization of MIPv6 while
giving us time to sort out the security issues of route optimization without
a huge panic.

Not having route optimization (for the time being) is not necessarily that
big a deal.  If you have something akin to the Home Domain Allocation
Function (HDAF), then a mobile can get a new home address when it roams
(powers up in a new location), and any mobility in that region will be
pretty efficient by virtue of proximity to the (visited) home agent.  (This
at least is my understanding of HDAF from reading RFC2794).

Once assigned a (visited) home address, the mobile can use SIP to register
its location with its SIP proxy.  For other applications (web browsing), it
just works as a client as usual.

I suspect that this will cover 90-some % of "optimization" requirements.

PF

---

From: Michael Thomas <[email-masked]>
Date: Mon, 26 Mar 2001 12:51:11 -0800 (PST)

> just works as a client as usual.

   How do you deal with in-progress RTP streams? What
   about their QoS requirements?

	       Mike

---

From: Mohan Parthasarathy <[email-masked]>
Date: Mon, 26 Mar 2001 13:46:19 -0800 (PST)

[Charset iso-8859-1 unsupported, filtering to ASCII...]
> my voice to that sentiment.
I am not sure whether i suggested that or not :-) But what i have
been trying to find out is the usefulness of sending a binding
update if i am just going to exchange a few packets. Then, the
overhead of setting up the SA becomes important. I am not sure
how many packets you need to amortize the cost of setting up
the SA. So, would MN make any discretion (using other information)
in when to send the binding update ? If so, the overhead part
is not an issue.

> giving us time to sort out the security issues of route optimization without
I don't think this will fly. I think one of the main features is route
optimization, at least from all disucssions that i have seen.

> just works as a client as usual.
How secure is the SIP registration part ?

-mohan

---

From: Patrice Calhoun <[email-masked]>
Date: Mon, 26 Mar 2001 13:55:57 -0800 (PST)

> in when to send the binding update ? If so, the overhead part

Just to play the Devil's advocate, is mobility important by itself, or only
with route optimization? (btw, I've heard from folks that route optimization
is less important than getting base Mobile IP out there).

If so, then I agree with Paul's proposal to move the route opt work to a
separate I-D, as it is done in the v4 world. This way, Mobile IPv6 can move
ahead, while the important security aspects of route optimization can be
ironed out.

(btw, I am assuming that such an editorial change is even possible, and not
having read the document, my comments above may be pointless).

PatC

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 26 Mar 2001 14:57:03 -0800

Hello Pat,

> with route optimization?

"Mobility" is "more important" than "route optimization".  But allowing
the correspondent node to send packets to a mobile node, and (just as
important) getting the home agent out of the typical routing path, is an
important aspect of the scalability of the protocol.

> ahead, while the important security aspects of route optimization can be

I think this is premature.  We have only just recently gotten a clear picture
about what is needed from the standpoint of the IESG.  The Binding Update
message is, after all, what the mobile node sends to the Home Agent.

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.

Again, a good solution is, I think, within reach.

Regards,
Charlie P.

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 26 Mar 2001 13:57:16 -0800

Hello Paul,

Your suggestion might amount to pulling defeat from the jaws of
victory.  I am optimistic that we can get a baseline proposal to the
working group in the very near-term.  Maybe you would be
willing to take a look at that before giving up?

Regards,
Charlie P.

---

From: "Paul Francis" <[email-masked]>
Date: Mon, 26 Mar 2001 17:35:42 -0800

> willing to take a look at that before giving up?

My suggestion might also amount to losing the battle in order to win the
war.

Of course I'm willing to look at a baseline proposal.

I'm not giving up, and I resent that characterization.  Quite the contrary,
I'm thinking about the best and fastest way forward.  I'm seriously
concerned that floating any proposal in an attempt to quickly get to
proposed standard with route optimization is going to hurt us in the long
run.

I suspect we can live without route optimization for a while longer.  I
would like to hear why not.

PF

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 26 Mar 2001 18:15:44 -0800

Hello Paul,

> Of course I'm willing to look at a baseline proposal.

Thanks!

> proposed standard with route optimization is going to hurt us in the long

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
all the upheaval about Mobile IPv6, one could imagine a very long
delay.  My belief is that we can avoid that delay.

Did you see my earlier note to the [mobile-ip] mailing list?  In case

> and almost pointless since it's needed for the home agent.

Restated in alternate terms, the specification needs Binding Update
already for the home agent, so that has to stay.  Letting correspondent
nodes use it requires that they have a security association, which we
did NOT specify in the base draft.  However, see above.

So the current plan is to build a special purpose key establishment
protocol, which looks doable given the design parameters.

I do not believe that a wholesale rejustification of the basic
protocol is needed. Furthermore (again repeating myself):

In an earlier note, I said:

>  ....   getting the home agent out of the typical routing path, is an

We need to design this for billions of nodes.

Lastly, I promise that I do not intend to be offensive.  If you thought
this was offensive, just consider it a typo or whatever the logical
equivalent would be at the appropriate level of mistakeness.  And
also consider that we've gone this far after waiting through numerous
process delays to get almost done.  Going back to square one isn't
anywhere within the top 10 alternatives as far as I am concerned.

Regards,
Charlie P.

---

From: "Paul Francis" <[email-masked]>
Date: Mon, 26 Mar 2001 20:53:58 -0800

> taken where none was meant at all.  However, I realize that with

Or, a good example of how careless wording can lead to offense.

> delay.  My belief is that we can avoid that delay.

Understood.

> not, I'll repeat myself here:

I did see it.

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

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

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

> >  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: "Paul Francis" <[email-masked]>
Date: Mon, 26 Mar 2001 22:17:18 -0800

>    about their QoS requirements?

Whats the problem?

PF

---

From: "Paul Francis" <[email-masked]>
Date: Mon, 26 Mar 2001 22:30:44 -0800

> optimization, at least from all disucssions that i have seen.

In other words, because everybody before has assumed route optimization is a
main feature, it must be a main feature?

IPv6 has since its inception been under a lot of pressure to be better than
IPv4.  It wasn't enough just to supply more addresses, it had to supply more
features.  So early on things like route optimization were latched onto as
one of the added benefits.  Combine this with the going idea at the time
that we can piggy-back security on top of IPsec, and it makes sense that
route optimization looked like a great thing.  Now, though, it is holding up
basic MIPv6, and it don't look so great any more.

Now that I think about what I'm suggesting, I'm not proposing that we get
rid of route optimization.  I'm proposing a different, slightly less
efficient form of route optimization.

Classic MIPv6 route optimization is to go bypass the HA and go straight to
the CN.

What I'm suggesting instead is putting the HA close to the MN, so that going
through it is not very costly (by getting an HA in the visited domain).  My
form of route optimization will occasionally end up with a long path, if for
instance a mobile goes very far while maintaining a connection.  I'm saying
that this form of route optimization is worth it if it means we can delay
the hard problem of security.

Ok, so the choice is not between route optimization and no route
optimization, it is between "HA bypass route optimization" and "Nearby HA
route optimization".  Doesn't sound so bad now.

PF

---

From: "Paul Francis" <[email-masked]>
Date: Mon, 26 Mar 2001 22:43:04 -0800

> having read the document, my comments above may be pointless).

I'm not sure either.   Actually, there are two possible ways to jettison BUs
between MN and CN:

1.  Just get rid of MN<>CN BUs, but otherwise make no changes.
2.  Both get rid of MN<>CN BUs, and also add the ability to obtain local HAs
in a visited domain as in RFC 7494.  (Either that or some variant of the
Gateway FA or MAP or some such hierarchical/regional scheme that has already
been specified).

The latter is clearly more work, but should in any event not involve
techniques that haven't been discussed at length already.

Anybody care to volunteer to work with me to sketch out both choices 1 and 2
above so that we can better understand what is involved?

PF

---

From: "Paul Francis" <[email-masked]>
Date: Mon, 26 Mar 2001 23:55:11 -0800

----- Original Message -----
From: "Charlie Perkins" <[email-masked]>
To: "Pat Calhoun" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, March 26, 2001 2:57 PM
Subject: Re: [mobile-ip] MIPv6 security issues: how to move forward

> important aspect of the scalability of the protocol.

Not if the HA is already in or close to in the normal route the packet would
otherwise take (i.e., "Nearby HA Route Optimization").

> message is, after all, what the mobile node sends to the Home Agent.

Though the IESG didn't say so in so many words, my distinct impression was
that the issue is with the security association between MN and CN, not
between MN and HA.  I don't think anyone is suggesting getting rid of the
latter.  I certainly wasn't.  Am I wrong on this?

> Again, a good solution is, I think, within reach.

I don't know.  The IESG is suggesting a design team.  Sounds like a time
comsuming process.  Also, Pekka's attack classification has like 15 attack
capabilities and 10 attack scenarios.  Presumably this represents a minimum
of the sort of analysis that has to be done on a new scheme.  I just don't
finishing the process of designing another scheme happening any time soon.

Charlie, if we assume that the existing method for establishing SAs and
sending BUs between MN and HA remain the same as now, are you less opposed
to the idea of just dropping the MN<>CN SA and BUs only?

PF

---

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

=> I agree but we should add unoptimized/paranoid modes in the current
mobile IPv6:
 - make sending of BUs to new CNs explicitely optional (ie. the last
   SHOULD of page 88 is a bit too strong)
 - add a bidir HA-MN tunnel mode (ie. "reverse tunnel" mode for
   superparanoid visited networks)
But these should be marked as degraded modes of operation, not as basic
modes which can be optionally optimized.

Thanks

[email-masked]

PS: local home agents still need a good security (ie. strong authentication),
this is a place where an improved AAA can help (ie. not only get the
authorization to use a local address, but get the authorization to use
it as a home address in the near future).
PPS: about section 10.8, a statement about policy in the page 88-89 list
should be enough.

---

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

=> if you want to put the HA close to one of the two peers
the CN is better in general because the MN is known to be mobile.
(This is essentialy my proposal for site-local stuff - first IPngWG
session, I don't know if you attended this one but minutes are available,
I'll ask to add a statement about this :-).
I've seen there is a message from a HMIPv6 person so I'll read it in order
to discover if we have a good solution using a hierarchical scheme.

Regards

PS: even with some social engineering I don't know a good way to avoid
delays so we should leave the "panic mode", please.

---

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

> the hard problem of security.

   I think you've falled into a pretty easy trap.
   The main (though perhaps not only) motiviation
   of a home agent is reachability as a server. So
   how do you plan to migrate the A6 records as you
   are moving in the visited network?

   I believe that you end up with two previously 
   unsolved problems instead of one. Perhaps three,
   because this is really just renumbering in 
   disguise.

		     Mike

---

From: Patrice Calhoun <[email-masked]>
Date: Tue, 27 Mar 2001 07:14:46 -0800 (PST)

>    because this is really just renumbering in 

Allocation of a Home Agent in a visited network does require some additional
infrastructure, such as AAA, and yes this does require a dynamic home address
(and dynamic DNS updates from AAA in the home domain). I am sorry to say that
not only is still solved, interoperability was achieved (for v4) at the last
Connectathon. So, figuring out the MIPv6->AAA interactions would solve this
problem.

Of course, this mandates AAA for (scalable) MIPv6, which is probably not a
good thing.

PatC

---

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

> Connectathon. So, figuring out the MIPv6->AAA interactions would solve this

   So did you use 0 length TTL's?
 
 > Of course, this mandates AAA for (scalable) MIPv6, which is probably not a

   Amongst other things. Anything that posits DNS
   as being a real time transaction system is dead
   in the water. 

	  Mike

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 27 Mar 2001 09:32:07 -0800

Hello Paul,

> latter.  I certainly wasn't.  Am I wrong on this?

I am glad to hear you weren't suggesting getting rid of using
the Binding Update.  That was my reaction to your previous message,
and prompted my worried characterization of your suggestion as
an extensive rewrite.  So let's imagine keeping the Binding Update,
revised as necessary for use with a different authentication
mechanism (not AH).  That much is pretty straightforward, and
I've already done a lot of it.

> finishing the process of designing another scheme happening any time soon.

My impression is that the design team was going to be pretty sharply
focussed on solving the problem at hand.  We have enough tools at
hand to be pretty effective, I think.  I hope that we don't have
to equate "design teams" with "committees", because the latter seem
to have an inglorious history.

> to the idea of just dropping the MN<>CN SA and BUs only?

To answer your question, yes that would be less problematic.  Nevertheless,
I am still very much persuaded that enabling direct communications between
IPv6 nodes (as much as possible) is quite important.

To put this discussion in context, let me make a quick summary of the
current situation:

- Last fall, a decision was taken to expedite the then-stalled
  Mobile IPv6 specification.  Engineers were polled, issues were
  raised, solutions were found, and interoperability was tested.

- All of these inputs were taken together as part of revising the
  specification.  This is the time-honored IETF process in action.

- The IESG raised concerns about key establishment with correspondent
  nodes.  It was thought that the current specification might be
  abused in such a way to engender a security vulnerability, because
  engineers _might_ (in the absence of any key establishment protocol)
  build network systems that did not securely check authentication.

- Last week, further discussion (centering on the idea of "First, do
  no harm") helped to clarify the technical requirements for what
  might be considered an acceptable key establishment protocol.
  Ideas have been floated (including PBK and my drafty draft) that
  could meet the requirement.  As I understand it, the requirement
  can be stated as not introducing any vulnerability not already
  present between two non-moving network nodes in the Internet today.

- A design team is to look at the problem(s), propose a solution, and
  make sure it fits the requirement(s).  I'm pretty sure we can do
  it if the scope of the problem is narrowly defined.

So what I see is that we've changed the base specification from stalled
into almost done, and now we are in the process of meeting some challenging
guidelines from the IESG that weren't clearly enough articulated
until recently.  In fact, the basic specification needs to be slightly
retooled to avoid AH no matter what, and to revise the renumbering
section.  The new stuff about key establishment would properly fit
in a new draft, I think.  I know life doesn't have to be fair, but
anyway we should be cognizant of how close we are to the solution
most people seem to want in the end.

We should continue the considerable forward momentum we have now for at
least a few more weeks before stepping back and re-evaluating.  And, I
think that even after that point any such re-evaluation should be carried
out with the benefit of a great deal of consideration to what has gone
before.

Regards,
Charlie P.

---

From: "Paul Francis" <[email-masked]>
Date: Tue, 27 Mar 2001 10:52:45 -0800

>    as being a real time transaction system is dead

I'm not suggesting that DNS be updated for this.  I'm not suggesting
anything different from what we can do today with IPv4 (for the time being).

I'm not suggesting we need a new AAA infrastructure.

I'm not suggesting DynDNS.

I'm not suggesting we stop pursueing true route optimization.

All I'm saying is that we move forward with a simple form of MIPv6 that
provides us with no more capability than we have today with MIPv4.  When you
roam and authenticate with the local AAA infrastrucuture (PPP and RADIUS and
CHAP or whatever protocols and infrastructure is already out there today),
you get assigned an address that ties you to a local HA.  When you are
mobile, traffic still goes through the local HA.  Your A6 records are not
updated, so if you want to act as a server, then it must be through your
true original HA (not local HA).  (Hmmmm, does MIPv6 today allow for the
possibility of multiple HAs?  If not, then rather than add functionality for
that, better to say that for the time being that the MN cannot act as a
server.)  If you are running SIP, and you do a SIP REGISTER with the address
of your local HA, then parties calling you can go through your local HA.

Lets not go down the rat-hole of trying to perfect a partial and temporary
solution.  If the temporary solution isn't dead simple, then there is no
point in pursuing it.

PF

---

From: Michael Thomas <[email-masked]>
Date: Tue, 27 Mar 2001 12:06:08 -0800 (PST)

> anything different from what we can do today with IPv4 (for the time being).

   Well, one of the things I can do with IP4 today
   is send a SYN to a web server based upon a DNS
   A record lookup. If you localize the HA in the
   visited network, how does that SYN get there
   without going through my home subnet? 

   I hope that you're not suggesting that the mobile
   server problem is not as important, because that
   makes SIP UA's pretty hard to implement.

 > solution.  If the temporary solution isn't dead simple, then there is no

   That's fine by me. I'm afraid that we're not
   going to find a simple temporary solution though.

	    Mike