Subject: RE: [mobile-ip] Questions about Route Optimization in MIPv4

From: "Glenn Morrow" <[email-masked]>
Date: Tue, 1 May 2001 11:06:30 -0500

Hyun,
 
Some good points - comments below.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, April 30, 2001 9:29 PM
To: [email-masked]
Subject: [mobile-ip] Questions about Route Optimization in MIPv4

Hello, All ... 

I have some questions about Route Optimization in MIP... 
It is somewhat an old story... 

In IMHP (Internet Mobile Host Protocol), the origin of Route Optimization in
MIP, 
there is a notion of "Cache Agent" that is a intermediate router capable of
caching a binding for MN... 
Why was "Cache Agent" excluded from Route Optimization in MIP I-D when
adopted by WG ?  

[Morrow, Glenn ]

I do not know why. I'd like to know too. It seems to me that the cache is
better suited to be implemented on a purpose-built device than a web server
for the majority of Internet Traffic.

Is it not workable ? And if Yes, Why ? 
cf. "Intercepting Location Updates" by Cheng-Yin Lee, et al. attempted a
similar work... 
    IMHO, it was a good conception. But that internet-draft was rejected at
IETF 49... 

[Morrow, Glenn ] 

This draft was trying to develop a framework for providing location privacy
yet still allowing the simultaneous operation of route optimization. It also
dealt with hierarchy, security. Tunneling or double NAT could be used as
options. 

The draft used the MIP protocol as is. I do not believe the draft was
"rejected" by the WG. There was no consensus check ever made for accepting
or rejecting the draft. Any minutes indicating rejection are in question in
my opinion.

One critic of this framework was that it was not a new idea and the WG had
previously rejected the concept due to the fact that it relied on installing
state in the form of per-node routes and that in working through the
"redundancy" schemes of these previous solutions, the WG found some inherent
flaw in terms of redundancy.

I responded at critic that there was no issue with redundancy, in that if
the router acting as the correspondent agent goes down the packets are again
routed to the home agent where the process of binding occurs again. Another
router that has connectivity to the CN becomes a correspondent agent - no
service disruption at all.

I honestly do not see realistic deployment scenario of route optimization on
IPv4 unless we do do something like the lmk draft.  It seems to me that a
user is not going to want to indicate on every communication that they want
to use optimization or not.

It would be helpful if the persons who critic'd both of the proposals
clarified just what the percieved issues are. I am certainly not satisfied
with the explanations for any percieved rejection of either proposal.

I don't think the problems these drafts are trying to solve are going to go
away. I do not understand the stall tactics that have been used on providing
this functionality.

Thanks for bringing up the concept again. I would definitely like to work
through any issues and arrive at a workable solution for the WG. It seems to
me that the proposals should be WG documents so that the issues can be
worked out by the whole group. 

Thanks,

Glenn

Another question, 
I have just found another work for Route Optimization... 
The title of Internet-Draft was 
        "Routing optimization by a router with cache agent functionality" 
        <draft-okanoue-mobileip-R+A-00.txt> by Kazuhiro Okanoue 
I want to know about that and I tried to get that... 
But I couldn't find that Internet-Draft... 
If anyone know whereabouts of that document, please let me know where I can
get it... 
[Morrow, Glenn ] I'd like to read this as well. 

Thanks in advance.... 

Regards, 
Hyun Seo

---

From: [email-masked]
Date: Wed, 2 May 2001 16:51:21 +0900

Thanks a lot, Glenn
 
My comments below...

-----Original Message-----
From: Glenn Morrow [mailto:[email-masked]]
Sent: Wednesday, May 02, 2001 1:07 AM
To: [email-masked]
Subject: RE: [mobile-ip] Questions about Route Optimization in MIPv4

Hyun,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, April 30, 2001 9:29 PM
To: [email-masked]
Subject: [mobile-ip] Questions about Route Optimization in MIPv4

Hello, All ... 

[Morrow, Glenn ]

[Hyun Seo]

I agree with you... 

As you stated, if a "Cache Agent" or "Correspondent Agent" (the name is not
a problem) realizable, 

it is possible to provide route optimization without requiring any change to
CNs in the Internet...  

And security association for authentication of Binding Update message is
efficiently managed... 

But I think the problem is "HOW" to make "Cache Agent" realizable...

IMHO, there is no perfect solution for that yet...

lmk draft is a good candidate, but NOT every router in the present Internet
does processing IP router alert option...

And there are some security concerns over "intercepting Binding Update or
Reg. Request  midway"...

Am I right ?

I think R+A burdens intermediate routers with bulky datagram discrimination
(Is it IP or IP2 ?)...

Does anyone have another nice approach ? 

Thanks in advance...

          Is it not workable ? And if Yes, Why ? 
          cf. "Intercepting Location Updates" by Cheng-Yin Lee, et al.
attempted a similar work... 
                IMHO, it was a good conception. But that internet-draft was
rejected at IETF 49... 

[Morrow, Glenn ] 

This draft was trying to develop a framework for providing location privacy
yet still allowing the simultaneous operation of route optimization.   It
also dealt with hierarchy, security. Tunneling or double NAT could be used
as options. 

Thanks,

Glenn

Another question, 

[Hyun Seo] I found not a exact match but some helpful documents...  

IP Mobility Support with IP-Squred(IP2) Encapsulation Technique, by K.
Okanoue and T. Ohsawa (IEICE Trans. Commun. Vol.E-80B, No.8)

It was an internet-draft and it contains R+A notion...

 <http://search.ieice.org/1997/pdf/b081198.pdf>
http://search.ieice.org/1997/pdf/b081198.pdf  

Okanoue's presentation at IETF 36th (June 1996) Meeting 

<http://www.ietf.org/proceedings/96jun/area.and.wg.reports/rtg/mobileip-okan
oue-optim/index.html>
http://www.ietf.org/proceedings/96jun/area.and.wg.reports/rtg/mobileip-okano
ue-optim/index.html 
 
I  wish it could be helpful...
 
Thanks a lot...

---

From: "Glenn Morrow" <[email-masked]>
Date: Mon, 7 May 2001 16:00:20 -0500

Hyun,
I've added some more references and comments below. 
I've also decided to go ASCII.

------ original -----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, April 30, 2001 9:29 PM
To: [email-masked]
Subject: [mobile-ip] Questions about Route Optimization in MIPv4

Hello, All ... 

[Morrow, Glenn ]

[Hyun Seo]
I agree with you... 

[GM2] 
I don't care about the name either. 
To refresh other people's memory, here is a link to one of the IMHP papers
from 1994:
http://citeseer.nj.nec.com/perkins94imhp.html
Please refer to section 7.2 for the discussion of intermediate caching
agents. This paper suggested the use of snooping for the indication
mechanism. It seems to me that CAs would add a great deal of value to MIP,
especially for deployment and location-private route-optmization.

[Hyun Seo]

[GM2] Yes, indeed; no one knows if the CN supports route optimization or not
anyway. I really don't expect that a user on an MN - halfway in the middle
of some application, is going to be able or, for that matter, want to have
to push a magic button saying "try to optimize the route". Or it is now O.K.
to give away my location to this node. This is common sense ergonomics. I
don't think people like maintaining lists of people and nodes that it is
O.K. to do route optimization with either.

[Hyun Seo]

[GM2 ]  Yes, indeed again. 5000% agreement.

[Hyun Seo]

[GM2]  
Please expand. It will require change - that's for sure. 

[Hyun Seo]

[GM2]
Right - but routing protocols can convey whether domains and network
portions do support such things. In this manner, each router knows if the
next hop and "domain" supports something or not and can behave accordingly.
With the router alerts and routing protocols, you get controlled
deployability and proxied security associations. Also routers typically get
upgraded on a set of controlled schedules with soak periods, etc.. In many
cases (consumer internet access) there is no method for a provider to
control  the downstream clients' software. In the large enterprise, control
lists could store the capabilities of hosts - but what a pain for the
administrators.

[Hyun Seo]

[GM2]  
Yes, there are some tough engineering choices to make. It seems to me that
you have to trust something or someone. If the goal is to meet a requirement
of location-private route-optimization, you don't want to trust the CN's
anyway. That leaves only routers and service providers.  This is the
assumption about the security associations in the lmk proposal. 
[GM2]
Binding updates are route updates after all. Why not trust routers?  We
trust routers to route our traffic and maintain routes correctly already. We
also trust them to not spike off our traffic to somone else. Why not use
their existing security associations to our advantage. Local mobility
management will greatly increase the scalability. The interior routers of an
administrative domain can ignore the alerts. Only the local hops close to
the mobile, inderdomain hops and the last hop have to pay attention to the
alerts. Tunneling can also be used over interior spans depending on the
implementation of the alerts and policy. The use of routers for security
seems to fit in nicely with the existing social contract that exists between
the users of hosts and the providers of the network. The SA's are there -
might as well use them to our advantage.
[GM2]
If a domain does not support the function it can reply back to the MN
indicating this.
[GM2]
I must say I am very open to other proposals trying to solve these
functional issues. 

[Hyun Seo]
Am I right ?

[GM2]  
I may not understand. Please elaborate on the exact concerns so we can work
together to arrive at an acceptable solution.

[Hyun Seo]

[GM2]  
There has to be some kind of indication. It would be very nice to create a
new hop by hop option  (I think we refer to it as "edge alert" in the lmk
draft) that would only be passed and processed on the slow path based upon
information in the RIP, RPIB, FIB for a particular ingress or egress
interface. 
[GM2]
But really the same thing can be done today even with the existing router
alert. I.e. the router alert has an indication of the protocol which caused
the alert in the option. It seems to me that packet engines could be smart
enough to take a look at the protocol and determine based upon FIB, RPIB,
RIB information whether they should slow path this particular alert or not.
It is an implementation issue, though. Some existing hardware may not be
able to do this slow/fast path discrimination. There is also the tunneling
method similar to how RSVP handles it which can be employed to short circuit
these intermediates not capable of the discrimination. This tunneling would
also allow deployment of a set of custom SA's which could easily be agreed
and administered via routing policy for a consortium of operators such as
cellular and their corresponding infrastructure suppliers. 
[GM2]
I personally favor the discrimination to leverage the existing SA's between
domains but the tunneling of alerts similar to RSVP with arbitrary SA's
could be done as well. These signals can be encrypted between hops to allow
for more privacy, too. It seems to me that more slow path processing MIPs
are pretty cheap with Moore's law and all that. Most commercial router
architectures allow for offboarding of this processing already.
[GM2]
I believe a there are some other folks working on a far more flexible
protocol for  doing alerts for the NSIS work. Hopefully this new work will
deal with these security issues as well; I'm not sure if they have signed up
to all I'm making this out to be yet, though. It will be up to them.

[Hyun Seo]

[GM2]  While mobility is just one application, I can see other uses for a
more flexible and scalable alerting and SA infrastructure as this
convergence occurs. I would recommend focusing these changes towards the
NSIS effort.  

-- SNIP ----

[GM2] 
Interesting intersection of concepts. It suggests to use a more standard
method of snooping for the indication. I'm not sure about the indication
method used when dealing with IPSEC tunnels, VPNs etc..   It doesn't appear
to deal with the fact that a CN may have multiple routes in an out of a
given subnet. The paper may have just been leaving these details out to get
the basic points across, though. I'd like to see how this work has
progressed. This paper at least shows in mathematical terms the advantage of
having a C-A close to CN in terms of route updates.
 
I found it very helpful. 
 
Thanks,
 
Glenn