Subject: Re: [mobile-ip] Concerns about draft-mipv6-14 section 4.8

From: Thierry Ernst <[email-masked]>
Date: Wed, 01 Aug 2001 14:44:06 +0200

"T.J. Kniveton" wrote:
> 
> It's fine if the MANET group wants to discuss subnet mobility *as well*,
> but the subject of mobile routers, just as normal mobile nodes, within
> the scope of the Mobile IPv6 protocol, is a Mobile IP issue. What is a
> good reason that it is more appropriate to address it somewhere else?

Indeed, there would be such one good reason: mobile networks have an
implication on other aspects not related to Mobile IP.  For instance, on
routing protocols, but the right place for the discussion is still
Mobile IP because we have to determine whether Mobile IPv6 is the right
base protocol for network mobility support.  Mobile IPv6 may not be able
to address all issues, but it surely can help.

I agree that MANET WG could benefit from this discussion (how do you
manage mobility of an ad-hoc network that changes its point of
attachment ?), but it's not a better place than Mobile IP WG.   MANET WG
is more concerned by "how things are done INSIDE the network" than "how
to manage subsequent point of attachments to the Internet", which is
Mobile IP WG's.

Anyway, seems clear to me that everyone agree that this should not be
addressed in the MIPv6 draft itself, but in a separate document.

Thierry.

> Phillip Neumiller wrote:
> >
> > I agree and a more appropriate place to discuss it may be the
> > MANET group where it has been pretty quiet lately.
> >
> > -Phil
> >
> > > -----Original Message-----
> > > From: Michael Thomas [mailto:[email-masked]]
> > > Sent: Tuesday, July 31, 2001 10:53 AM
> > > To: [email-masked]
> > > Subject: Re: [mobile-ip] Concerns about draft-mipv6-14 section 4.8
> > >
> > >
> > > I'll throw my support backing it out again
> > > too. Mobile routers are going to involve a lot of
> > > consideration, because they have some pretty far
> > > reaching implications. They should be taken up as
> > > a separate working group item instead of letting
> > > it bog down mipv6.
> > >
> > >        Mike
> > >
> > > T.J. Kniveton writes:
> > >  > I agree with Thierry here - the discussions on the list
> > > and at meetings
> > >  > have shown that there is interest in making mobile
> > > prefixes work within
> > >  > the context of MIPv6 handovers. The key phrase here is
> > > problem scope --
> > >  > it should be broken down to a solvable level, and
> > > especially limited
> > >  > within the base draft (which I believe was the intention).
> > > To make it
> > >  > really work, security issues must be solved first. Which
> > > leads us to the
> > >  > question, for MIPv6 expediency's sake, why not leave it as
> > > a separate
> > >  > draft?

--
* mailto:[email-masked]  Tel +33 (0) 4 76 61 52 69 
* INRIA Rhone-Alpes Projet PLANETE       (fax 52 52) 
* and MOTOROLA Labs Paris
* http://www.inrialpes.fr/planete/people/ernst/Welcome.html

---

From: "T.J. Kniveton" <[email-masked]>
Date: Wed, 01 Aug 2001 12:51:33 -0700

Excellent post Thierry. I agree with your points exactly.

-TJ

---

From: "Charles E. Perkins" <[email-masked]>
Date: Sat, 04 Aug 2001 08:43:26 -0700

Hello folks,

As noted, I had made an attempt to update the Mobile IPv6
specification towards assisting the problems with mobile
routers.  However, making it into a separate draft looks
like a better idea.  For the base draft, should the prefix
length bits be marked as "reserved"?  The Mobile Router
Prefix Length Sub-Option would be removed, too.

Regards,
Charlie P.

---

From: Thomas Narten <[email-masked]>
Date: Sun, 05 Aug 2001 09:04:07 -0400

"Charles E. Perkins" <[email-masked]> writes:

> specification towards assisting the problems with mobile routers.
> However, making it into a separate draft looks like a better idea.
> For the base draft, should the prefix length bits be marked as
> "reserved"?  The Mobile Router Prefix Length Sub-Option would be
> removed, too.

Another reason for why MR should be stand alone. How one properly
secures and authorizes a BU for an entire prefix would seem to be to
add significant additional non-trivial issues to consider.

It would seem to me that the address ownership problem is plenty hard
for just one address. Trying to extend it to the case where a node
(i.e, the MR) is asserting to a CN that the CN should tunnel *all*
packets covered by an entire prefix would seem to be even harder.

Thomas

---

From: Michael Thomas <[email-masked]>
Date: Sun, 5 Aug 2001 06:19:40 -0700 (PDT)

> add significant additional non-trivial issues to consider.

   I doubt it. While I agree that mobile routers ought
   to be broken out, I'd be very, very afraid of any
   security solution which made a distinction between
   /32 (/128)) and a smaller prefix. They really are
   the exact same routing authorization problem (eg,
   something wants you to modify your routing entry
   for prefix X).

       Mike

---

From: Thomas Narten <[email-masked]>
Date: Sun, 05 Aug 2001 09:54:22 -0400

>    I doubt it. While I agree that mobile routers ought to be broken
>    out, I'd be very, very afraid of any security solution which made
>    a distinction between /32 (/128)) and a smaller prefix. They
>    really are the exact same routing authorization problem (eg,
>    something wants you to modify your routing entry for prefix X).

Authorization seems harder (but perhaps I'm wrong). There are already
drafts that describe ways of for a particular node to assert it "owns"
address X, and then later have that node reassert that it can still
prove that it is the same entity that made the assertion earlier, even
when its address has changed. So, here we have one address being able
to assert that was used by the same entity as a previous addresss.

This would seem to me to be a rather different (and even orthogonal)
problem to that of a router being able to assert that is is authorized
to "intercept" all traffic covered by a prefix.

How can one prove to a correspondent node that some router foo, is
authorized to have all traffic destined to (say) MIT rerouted through
it?

Thomas

---

From: Michael Thomas <[email-masked]>
Date: Sun, 5 Aug 2001 08:09:55 -0700 (PDT)

Thomas Narten writes:
 > Authorization seems harder (but perhaps I'm wrong). 

   Service	        Problem

   Authentication	Impossible to scale globally
   Authorization	Breeds impossible and arbitrary bureaucrats

> There are already

   I think that the concept that needs to be recognized is
   that a host receiving a binding update is conceptually
   a *router*, not a host per se. That is, it creates
   and maintains routing tables. As such, there's really
   no difference between the actions which one performs
   on a /128 vs. a /8, say. Or at least that's how I'd
   view something that causes you to FIB entires, create
   tunnel interfacess, etc. 

 > authorized to have all traffic destined to (say) MIT rerouted through

   Well, the two methods being floated right now are

   1) strong authentication based on some form of strong
      crypto.
   2) weak authentication based on a return routability
      test.

   It seems pretty clear that (1) will suffer the same
   scaling limitations as /128's in a world of Jetson
   car based mobile routers... that seems to leave (2)
   unless we have some sort of breakthrough alternative
   that's neither (1) or (2); unless R, S, A, D, or H
   have another miracle up their sleaves, I'm not real
   confident about that though.

   Maybe this is a case where the security realities
   inform the protocol design rather than the more
   usual reverse? Naw... never happen. :-)

	     Mike

---

From: Thomas Narten <[email-masked]>
Date: Mon, 06 Aug 2001 04:42:07 -0400

>    view something that causes you to FIB entires, create

This may be true, from the specific view of the mechanics of
installing a route into the routing tables of a local device, route
lookup while forwarding a packet, etc. That is not the point I'm
trying to make.

>    1) strong authentication based on some form of strong

My question concerns *authorization*, not authentication.  If a CN
gets a BU from a node claiming to be a router for a prefix (e.g., all
of MIT), how does the CN decide that this is really a legitimate route
entry to install, as opposed to an intruder attempting to hijact MIT's
traffic?

>    Maybe this is a case where the security realities inform the
>    protocol design rather than the more usual reverse?

Indeed. One needs to understand the security requirements prior to
designing the protocol, as some protocol designs may turn out to be
inherently flawed once the security requirements are understood.

Thomas

---

From: Michael Thomas <[email-masked]>
Date: Mon, 6 Aug 2001 02:37:29 -0700 (PDT)

> entry to install, as opposed to an intruder attempting to hijact MIT's

   Both /128 and /8 are about authentication and authorization.
   The main difference seems to be the stakes. If I subvert
   a /128, I only dork one node. If I subvert a /8 it's... more.
   The question is whether either is more or less acceptible.
   Is /128 ok, but /64 not? How about /48? I rather doubt that
   devine artificial boundaries is going to be especially 
   productive.
   
 > inherently flawed once the security requirements are understood.

   Considering that routing table update at a distance
   is a fundamental shift in the current security
   practices of the internet, I'd say that this is
   pretty important problem to be considered, and may
   very well be the lynch pin. Indeed, it's quite possible
   that if the requirements are significantly different than what is
   currently being proposed with the varoius return
   routability test, it's not solvable at all within the
   current MIP design. It would probably be nice to know that
   sooner rather than later.

		 Mike

---

From: Mattias Pettersson <[email-masked]>
Date: Mon, 06 Aug 2001 13:10:05 +0200

Hi Thomas,

> entry to install, as opposed to an intruder attempting to hijact MIT's

Is there such a big need for sending BUs covering an entire prefix
rather than /128? If a MH behind the MR needs to update a CN, there is
pretty low probability that another MH behind the MR would be talking to
the same CN and thus send a BU to that. So each MH should take care of
sending BUs to CNs, and the MR should not aggregate them. So, we don't
need to allow more than /128.

> Thomas

/Mattias

---

From: Michael Thomas <[email-masked]>
Date: Mon, 6 Aug 2001 05:09:53 -0700 (PDT)

> need to allow more than /128.

   This depends a whole lot on whether MH behind MR
   is aware of its mobility. If it's not, then MH 
   clearly won't be sending any BU's at all. There's
   quite a bit of appeal to not having the MH's 
   realize they are mobile (what for example would
   happen when an aircraft carrier full of PC's
   moved it's attachment point?).

   This is a pretty fundamental question that needs
   to be answered, and needs to be evaluated in the
   context of renumbering and security.

	      Mike

---

From: Mattias Pettersson <[email-masked]>
Date: Mon, 06 Aug 2001 14:48:32 +0200

>    moved it's attachment point?).

I can see two quite different paths to go:

1. Allow only the simpliest mobile networks. They have one MR (which is
single point of failure) and the MHs behind are in fact only Hs (i.e.
not mobile-aware). MR takes care of the mobility and maybe use a
bi-directional tunnel between itself and HA.
draft-ernst-mobileip-v6-network-0x focuses on this.

2. Make things end-to-end. Let MNs in the mobile network be aware of
that the network is mobile. At a higher cost, that is. Hopefully this
can also take into consideration multiple MRs, MNs leaving the mobile
network, multihoming, etc. The requirements draft doesn't exclude this
case.

/Mattias

---

From: Alexandru Petrescu <[email-masked]>
Date: 06 Aug 2001 17:00:18 +0200

Hi Mattias,

Mattias Pettersson <[email-masked]> writes:
> the same CN

The scenario you present is only one of so many.  PC's on the seats in
a plane will probably do mostly browsing to various servers.  But
brake sensors in a train will send data to one fixed surveillance PC
at the closest station.  This comes down to sending many BU's to the
same CN.  An MR would be useful.

Alex

---

From: Mattias Pettersson <[email-masked]>
Date: Mon, 06 Aug 2001 17:28:58 +0200

> same CN.  An MR would be useful.

I don't question an MR would be useful. The question is what functions
we put in it.

For me, what it boils down to is that I prefer not to have some nodes
perform operations on behalf of other nodes. It's needed at times, but
hopefully in static configurations (a home agent is rather static). I
don't see a mobile network as (always) a static entity, so I would look
for other solutions.

Also, the trust model for a mobile network with an MR doing registration
on behalf of MNs is more complex than one where each MN is out on its
own.

/Mattias