Subject: RE: [mobile-ip] Re: Comments on Regional Registration

From: "Glenn Morrow" <[email-masked]>
Date: Fri, 16 Mar 2001 08:26:55 -0600

Hesham,

You have some good points and I will try to explore or re-use some other
mechanisms which can hopefully resolve these points. I apologize that the
suggestion was targeted to just the RR concept. I should have included more
suggestions for HMIP as well such as the one I gave the other day on how to
achieve the arbitrary point. 

This is getting ridiculous. It seems that if I make a suggestion to either I
end up irritating the other - not exactly a hospitable environment to
contribute to either.

The requirement is to make BU authorization faster, more scalable and
eliminate the need to send more than one BU over the air.

Excuse me if I extended it into the RR assumptions alone. It seems obvious
to me on how to do the same thing with HMIP.

The last point I made was definitely out of place and thank you for pointing
that out. 

In the end I do not care what we call it. Perhaps we should come up with
another acronym just to reduce the my idea vs. your idea competition. 

These discussions stink of what I call PWS (Patent War Syndrome). If that is
the case then people will likely end up promoting something that isn't the
most optimal solution as the standard or there will be multiple optional
standards which exacerbate the solution space for future issues.

Glenn

-----Original Message-----
From: Hesham Soliman (ERA) [mailto:[email-masked]]
Sent: Thursday, March 15, 2001 3:03 PM
To: [email-masked]'
Subject: RE: [mobile-ip] Re: Comments on Regional Registration

Hello Glenn,

Before I start commenting on your proposal, I think there are 
some questions that need to be answered. 
Why do we need a multilevel static hierarchy of mobility
aware routers ? This is a mystery to me. The argument 
of delays if the MAP is too far simply doesn't hold. 
If I have an 80ms delay over the air interface and the MAP is 
another 4 ms away, I think such delay is insignificant. 

The other question is, do we want to associate the implementation
of this protocol with an imaginary protocol that generates 
an SA between the MN and the domain and distributes the
key to all mobility aware routers ?
The idea of generating such keys between two nodes is great
and we have presented it in San Diego, but I don't think it 
should be a requirement for this to be used. 

Do we want to have a tree-based hierarchy full of single 
points of failure ?

I don't want any of the above, but I'd like to see what others
think.

As you said Light travels fast and I like to Keep it simple, 
so unless there are strong and well thought requirements 
for the multi-level hierarchy, I think it should be dropped. 

I hope you don't take this as a negative response to your 
proposal, but I like to do things for a reason. The reasons 
and requirements here are not stated. 

Regards,
Hesham

PS: The regional draft for V4, basically says that f the MN
has a colocated CoA , then it just registers with the 
GFA. Sounds familiar ! 
Just something to think about.

> -----Original Message-----
> From:	Glenn Morrow [SMTP:[email-masked]]
> Sent:	Friday, 16 March 2001 1:59
> To:	[email-masked]
> Subject:	RE: [mobile-ip] Re: Comments on Regional Registration
> 
> Hesham and Charlie, 
> 
> I'm not too worried about the security association issue with anycast. I
think anycast is extremely useful and is here to stay. It is part of IPv6 -
might as well take advantage of it. 
> 
> I believe the SA establishment and scaling problem for MIP, in general,
has scaling and speed issues. It would actually probably be more productive
for us to focus on that issue than heirarchical models. It seems people have
focused so far on "database in the sky" solutions with AAA protocols to
this.
> 
> I have an alternate idea which I would like to bring up again. 
> 
> Why don't we use a hop by hop option to alert mobile-aware routers to the
binding updates. For instance, a mobile could send a binding update to a CN
and it would be intercepted by the 1st hop router in the visited domain. 
> 
> If the visited domain wanted to support hierarchical, other routers along
the natural routing path to the CN would be configured to care as well at
whatever topological tier the provider deemed necessary. These hirearchical
routers could install a per-host route in the binding cache to achieve route
both optimized hierarchical signaling and traffic flow.
> 
> These heirarchical routers could rebuild the binding update with a tiered
address and use the domains keys i.e. the keys that routers already use to
trust each other for the AH. Routers in the visited and in other domains
that are not configured to care about mobility binding simply forward the
packet towards the CN's address I.e. they are not configured to "recognize"
the particular function. 
> 
> Only when the binding update exits a domain into another domain i.e. the
keys change, the border router again intercepts and recomputes the binding
update using the keys appropriate for the particular border. 
> 
> This process is continued until the binding update arrives at either the
CN itself or a last hop router in the event they want route optimized
location privacy. If the BU is sent to the CN, it is assumed that that CN
has some security association with the subnet where it resides and it trusts
the keys of that subnet. Perhaps the CN can simply trust the subnet routers
without an SA - just as it currently does for ICMP singaling.> 
> 
> The advantage of this method are: 
> 
> - It re-uses the existing binding update i.e. we don't burn more air
bandwidth. We leverage the existing binding updates.
> 
> - It provides the most route optimal form of hierarchical mobility. 
> - It re-uses the existing security associations that SHOULD exist between
domains, internal routers and hosts.>  
> - If one heirarchical router dies other communications and hierarchical
bindings for other communications that mobile is engaged in continue
un-affected. 
> 
> - It does not interfere with the natural routing policy of the domains. 
> - It seems to match up well and re-uses the same mechanisms used to
monitor bandwidth and signal CoS. 
> 
> The disadvantages that I see is: 
> 
> - It makes some of the intermediary routers do extra signaling; however if
you really understand what will have to happen for real time communications
such as DSCP schema's changing between administrative domains, you will see
that this work will be occuring anyway. Why send more than one packet to get
the job done? 
> 
> - I agree it is not needed for best effort unless the excuse it to solve
the security association problems. 
> 
> Another approach might be to send binding updates to the visited subnet
anycast addresses and chain the message up the network i.e. MN subnet to
site, site to site, site to CN subnet and then to CN.
> 
> Is this clear? It seems to me that doing something like this would resolve
many issues. 
> 
> One thing I really can't understand with both of your proposed
hierarchical solutions is why you want to send more than one binding update.
This burns the air resources. The whole idea for doing heirarchical was to
reduce signaling latency for cellular. These networks are the only networks
that I am aware of that someone might be moving so fast as to warrant a
heirarchical scheme. The solutions seem to conflict with requirements. 
> 
> The last thing I would like to say that it seems we are spending way to
much time on something that provides so little gain. Light travels very
fast.
> 
> Thanks, 
> 
> Glenn 
> 
> 
> 
> 
> Glenn 
> 
> -----Original Message----- 
> From: Charlie Perkins [ <mailto:[email-masked]>] 
> Sent: Wednesday, March 14, 2001 5:38 PM 
> To: [email-masked] 
> Subject: Re: [mobile-ip] Re: Comments on Regional Registration 
> 
> 
> Hello Hesham, 
> 
> We want to get the routing part figured out, and I believe 
> we have a pretty good handle on it. 
> 
> Setting up security will allow a mobile node to provide 
> authentication data that can be checked by one of the 
> anycast group members.  I know several ways to do that. 
> It will be more productive to start on that task once two 
> other things are out of the way: 
> - Fixing the authentication mechanism for base Mobile IPv6 
> - Getting the routing part figured out. 
> 
> If you wish to disqualify all anycast-based solutions because 
> there are no standards for establishing security between a 
> node and the members of an anycast group, then I would 
> just prefer to say that we believe the problem is wholly 
> solvable for the particular anycast group we have designed. 
> We don't intend to get in the business of solving it for the 
> general case. 
> 
> Regards, 
> Charlie P. 
> 
> 
> 
> "Hesham Soliman (ERA)" wrote: 
> 
> >         Hello Charlie, 
> > 
> > > 
> > > > GM> I agree, I support anycast too. To vilify a solution which
employs 
> > > > it as magic was wrong and I apologize. 
> > > 
> > > No need for apology, but I wanted to point out that this particular 
> > > use of anycast is easy to implement, assuming that one's IPv6 
> > > implementation supports anycast at all. 
> > > 
> >         => I'm a bit confused by this statement. How can it be easy 
> >         to implement a BU to an anycast address ? 
> >         BUs have to be secured with AH, so how can you setup this 
> >         security association when there are no standards defined 
> >         to do so ? 
> > 
> >         Regards, 
> >         Hesham 
>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 16 Mar 2001 08:55:03 -0800

Hello folks,

> Glenn Morrow wrote:

> end up irritating the other - not exactly a hospitable environment to

I'm not irritated by any suggestion you've made regarding HMIP.

> another acronym just to reduce the my idea vs. your idea competition.

Actually, as I have mentioned several times, I have no problem
with trying to merge.  There are several things about the existing
HMIP document that I think need serious reconsideration (e.g., load
balancing) but that's to be the subject of a different note.

> standards which exacerbate the solution space for future issues.

As far as I know, Nokia doesn't intend to pursue any patents on the
ideas in the Regional Registration draft.

To be clear, I do not maintain my involvement with Regional Registration
because of any NIH syndrome, and if you have found any trace of that
in my mailings to this list I would appreciate that you point it out
to me.

> aware routers ?

It doesn't have to be static.  For our purposes, we only have to
know that it is multilevel.  The method of organizing the relationships
between the regional-aware routers does not have to be part of our
initial specification.

I am suggesting that for IPv6 we have to think about billions.
That means we have to be very, very careful about scalability.
I do not believe the HMIPv6 proposal is sufficiently scalable
(in the dimension of size of mobile node population).

> key to all mobility aware routers ?

Gee Hesham, one could easily read that as a slur.

> Do we want to have a tree-based hierarchy full of single

An anycast group is a very good mechanism by which one can
avoid such single points of failure.

> I don't want any of the above, but I'd like to see what others

Maybe you didn't exactly intend to do so, but you have come
very close to setting up straw men for others to knock over.
I do not view it as constructive.

> for the multi-level hierarchy, I think it should be dropped.

Light doesn't travel faster than mathematics, and I think that
the advantages for hierarchical localization of routing updates
are well accepted.

 -----Original Message-----
> > I believe the SA establishment and scaling problem for MIP, in general, has
> scaling and speed issues. It would actually probably be more productive for us
> to focus on that issue than heirarchical models. It seems people have focused
> so far on "database in the sky" solutions with AAA protocols to this.

I agree that key establishment issues need more work.  There will be a
lot of work on this in the immediate future.  However, the regional
stuff is too important to ignore, and deciding on a good model for
localizing binding updates is an important current discussion.

> and it would be intercepted by the 1st hop router in the visited domain.

Hop-by-hop options are automatically less scalable than other
possible solutions, and so I reckon we ought to use them very
carefully.  It would make sense if we could imagine requiring that
all visited-domain routers should be regional-aware.  Otherwise,
the hop-by-hop option will just look like unwanted work to a
significant fraction of the routers that process it.

I hope you'll excuse that I do not comment on the further
detailed proposal.  I think it has definite merit, and should
be carefully considered.  So far, all the security information
for Binding Updates has been engineered to be provided by the
mobile nodes.  Allowing regional routers to rebuild the
authentication is intriguing, but I think it will take a LOT
of work and discussion to see if the security model can be
made to work out well.

However, as far as I can see your approach COULD be retrofitted as
an backwards compatible upgrade to a regional approach that did not
involve rewriting authentication data.

> anycast addresses and chain the message up the network i.e. MN subnet to site,
> site to site, site to CN subnet and then to CN.

Hmmm!

> > One thing I really can't understand with both of your proposed hierarchical
> solutions is why you want to send more than one binding update. This burns the
> air resources. The whole idea for doing heirarchical was to reduce signaling
> latency for cellular. These networks are the only networks that I am aware of
> that someone might be moving so fast as to warrant a heirarchical scheme. The
> solutions seem to conflict with requirements.

We have suggested something similar multiple times.  I agree that it
would be nice to coalesce the signaling.  We had defined something called
a "Previous Access Router Notification" (PARN) extension that has some
of the same properties you suggest.  However, it's more important to
get the basic model right, and then apply such optimizations.  I hope
we can do so.

> > The last thing I would like to say that it seems we are spending way to much
> time on something that provides so little gain. Light travels very fast.

But packets sitting in non-local routing queues are delayed sometimes
by things that don't depend on the speed of light.  We're not dealing
with optimizing the transmission speed between the local link and the
GMA/MAP/GFA/etc.  We're trying to figure out how to cause binding
updates to be processed and forwarded by the fewest number of network
elements.

Regards,
Charlie P.