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

From: "Glenn Morrow" <[email-masked]>
Date: Wed, 14 Mar 2001 09:15:48 -0600

Sorry Charlie but I'm not that sorry. 

If four chairs are each missing one leg, they both fall down irrespective of
which particular leg they are missing.

The leg missing from your proposal is single point of failure and there are
already proposed solutions that have the same leg missing and yet require
none or fewer changes to the protocol.

While it is not for me to decide, it appears to me that it would be an
injustice to accept it in light of these other solutions.

Routing policy and configuration can also guarantee arbitrary point with
these other solutions. I also believe your solution conflicts with current
technologies for controlling routing policy.

Thanks,

Glenn

-----Original Message-----
From: Charlie Perkins [mailto:[email-masked]]
Sent: Tuesday, March 13, 2001 10:58 AM
To: Morrow, Glenn [RICH2:C330:EXCH]
Cc: [email-masked]; Basavaraj Patil (NTC/Dallas); Phil
Roberts
Subject: [mobile-ip] Re: Comments on Regional Registration

Hello Glenn,

Thanks for your notes.  I just have one question below,
and then a comment about IPv4 regional registration.

Glenn Morrow wrote:

> Anycast is exactly right, because what the mobile node "wants"
> is for the crossover router to take the appropriate action,
> without the mobile node knowing which router it is.
>
> Anycast even helps to preserve the connectionless nature which
> we would like to preserve for regionalized mobility handling.
>
> 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 don't know whether
we ought to publish the algorithmic steps, but it seems that most
people who have coded network protocols could figure out how
to make this particular anycast idea work.  Thus I am claiming
that we are not invoking magic here -- just to be clear.  And, to
be equally clear, I strongly suspect that you did not intend in your
sentence to classify our anycast solution to be counted among
those in the "magic" bin.

My other comment was that I hope we can forward with the
IPv4 regional registration draft.  That protocol works, has
implementations, has been through last call, and has been
reissued with comments responding to last call.  It is a very
nice protocol (o.k. I am biased).  I hope that it won't
be neglected because of desires for a more robust and
well-controlled host route dissemination mechanism.

Regards,
Charlie P.

---

From: [email-masked]
Date: Wed, 14 Mar 2001 19:47:17 -0600

Hello Hesham,

>	=> I'm not at all trying to discredit anycastl. I'm just 
>	wondering how you could use it in light of the current
>	standards. You still didn't tell me what the solution 
>	is. 
>	Proposing a solution for setting up an SA with an
>	anycast group would be a great proposal, but 
>	I don't think we need several standards to solve
>	this particular problem. We already have a solution
>	and I'm starting to question the need for alternatives
>	if nothing is raised against HMIPv6. Especally if 
>	the alternative is a lot less robust and overrides 
>	the use of standard routing between the anchor point
>	and the MN.
>

actually that there are different proposals on the way to set up Security
Associations and to authenticate the BU using AH in Appendix B of the draft.

---

From: "Glenn Morrow" <[email-masked]>
Date: Thu, 15 Mar 2001 08:58:50 -0600

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,
> > 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: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 15 Mar 2001 17:09:53 +0100

> Associations and to authenticate the BU using AH in Appendix B of the draft.
	=> Yes I saw that, but this is hardly a standard or an accepted 
	method, I don't think we can base it on the appendix surely. 
	Even if we can, my main point is why are we adding all this 
	complication to achieve the same effect that HMIPv6 does ?
	I haven't heard an answer till now.

	Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 15 Mar 2001 22:02:30 +0100

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.

> From:	Glenn Morrow [SMTP:[email-masked]]
> Sent:	Friday, 16 March 2001 1:59
> 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.
> 
> 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.> 
> 
> - It re-uses the existing binding update i.e. we don't burn more air bandwidth. We leverage the existing binding updates.
> 
> - 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 seems to match up well and re-uses the same mechanisms used to monitor bandwidth and signal CoS. 
> 
> - 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 
> 
> From: Charlie Perkins [ <mailto:[email-masked]>]

---

From: [email-masked]
Date: Thu, 15 Mar 2001 16:08:05 -0600

Hello Heshman, 
It seems that in the HMIPv6 draft, you suggest to distribute the session
keys either using IKE or AAA servers and to authenticate the BUs. The same
solution can apply to Regional Registration: we suggest to use AAA servers,
so I don't think that it is more complex.
The only difference when using anycast address is in anti replay attacks: We
suggest to use nonces instead of the sequence number defined in AH.
Franck

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

	Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 16 Mar 2001 02:04:02 +0100

> IKE requires too many messages to be exchanged so that may be not be the
> most optimized solution to set up the security associations between the MN
> and Mobility agents: IPsec WG is already designing a new protocol "Son of
> IKE". 
> In addition, IKE requires either PKI or a pre shared secret between the two
> entities that are setting up the SA !
> 
	=> That's all fair and I presented the exact same arguments 
	in San Diego, but I don't think this is a reason to mandate
	AAA _only_ solutions. You also didn't mention that IKE 
	is a more secure mechnism than the AAA one. So 
	it' not all gloomy with IKE. Nothing comes for free, 
	and if people want to use MIPv6 with IKE then I don't 
	think we should have a standard that stops them from
	doing so. That would be a mistake IMO.

> Do you believe that PKI will be ready soon ?
> 
	=> Some people already have Public Keys, not 
	widely deployed yes, but we shouldn't stop them
	from using it. 

> As for the pre-shared secret between the MN and Mobility agents, do you
> think that such solutions is really scalable ?
> 
	=> No.

> For those reasons, we suggest to use AAA servers.
> 
	=> I hope I made myself clear above, I also like AAA, Kerberos
	and other mechanisms and I'm not trying to say they're
	bad, but tying a standard to AAA only is not a good idea IMO.

	Hesham

> Sent: 15 March, 2001 6:16 PM
> 	=> Please read your statement above carefully. You just said HMIPv6
> 	works with either IKE or AAA, but regional only works with AAA.
> 	I think that's a significant difference. 
> 	BTW the HMIPv6 draft only talks about AAA in terms of context
> 	transfer, not for SA establishment. We presented another 
> 	draft for that purpose and we certainly do NOT want to restrict
> 	the use of HMIPv6 to the AAA SA generation scenario.
> 
> 	=> Can you use IKE for a key exchange with an anycast address ???
> 
> 	Thanks,
> 	Hesham
> 
> 
> > 	Even if we can, my main point is why are we adding all this >

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 20 Mar 2001 21:15:38 +0100

G'day Glenn, 

	A late reply....

> 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.
> 
	=> Actually, I am not offended or irritated at all. I can't emphasise
	enough the need for technical feedback. So no need to worry about 
	that. 

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

> 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. 
> 
	=> No need to feel guilty ;) I look forward to your feedback.

> 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.
> 
	=> Here I have to disagree. If our sole purpose is to protect 
	IPR (which BTW we don't know much about what it covers)
	we would not ave welcomed and included other comments 
	or merged with other drafts as we did with Claude. 
	We're happy to modify _anything_ in HMIPv6
	provided there is a good technical argument behind it. 
	I really hope you don't get that impression. It's definitely 
	not what we've been thinking about. 
	 
	Regards,
	Hesham

> From: Hesham Soliman (ERA) [ <mailto:[email-masked]>] 
> Sent: Thursday, March 15, 2001 3:03 PM 
> > 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. 
> > 
> > From: Charlie Perkins [ < <mailto:[email-masked]>>]

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Mon, 26 Mar 2001 01:28:56 +0200

>  > > Do you _really_ not at all understand the need for multiple
>  > > levels of hierarchy? 
>  > > 
>  > 	=> Yes. I'm sorry if this is a trivial question but I
>  > 	honestly don't see why it's needed and would 
>  > 	appreciate an explanation. 
> 
> One quick note that occurred to me at the meeting
> on this subject. We are not the protocol police,
> so if there is a way protocolwise to do it, people
> can do it and that is that. 
> 
	=> Yes, but there is a way to stop it. You 
	can easily configure a MAP to not receive a BU
	that requests traffic to be forwarded to "certain"
	MAPs. But the best way to stop it is to design
	your network in such a way. That is also very 
	easy, just put overlapping MAP domains if you 
	need more than one. 

	I agree that people will use it if they see the need, 
	but what's that need ?

> Frankly, I find the
> admonitions against multiple levels of hierarchy
> somewhat hollow: MIP at least has a basic
> connectivity problem; all the rest of the *MIP's
> floating around are for optimization and they all
> have single point of failure issues. If you're
> willing to live with one failure point for
> optimization -- which you've assumedly made
> backhoe-proof somehow -- 
> 
	=> If you want one node to be redundant 
	that will cost you X $$, if you want 
	3 nodes to be redudant it will probably cost you  
	3 X, so you can do it of course but what would 
	you do that for ? There are no less states 
	kept in the top MAP anyway, so what's the 
	point ?

	Even the IPv4 RR kept that solution (multi-level)
	in the appendix and it is not part of the main
	draft. They limited it to 2 levels because in V4 
	you have an FA, in V6 you don't so one level 
	is enough.

	Hesham