Subject: RE: [mobile-ip] Low Latency Issue: Where to Run the Reverse Tunnel?

From: James Kempf <[email-masked]>
Date: Thu, 6 Sep 2001 10:08:46 -0700 (PDT)

Hi Pete,

> > My concern was that packets originating at the MN will be
> > sent with the source address set to the care of address and
> > not the home address, as would be the case if no route optimization
> > were in effect. 
>
>Ok, I'm lost.  I managed to find an old (-07) version of the route
>optimization draft, and I quickly searched through the new Reverse
>Tunneling RFC.  I couldn't find where this requirement is stated.  My
>current understanding of Route Optimization is that it only affects
>the forward direction traffic.
>

Right, but the MN will still put its CoA in as the source address
on outgoing packets, I think.

>RFC 3024 states:
>
>   Route optimization [4] introduces forward tunnels initiated at a
>   correspondent host.  Since a mobile node may not know if the
>   correspondent host can decapsulate packets, reverse tunnels in that
>   context are not discussed here.
>
>Does the new -11 version of R-O contain some text about reverse
>tunnels?  It's too bad I can't look at it.  I think you are saying
>that, even if the MN is using an FA-located COA, it would "borrow"
>this address for the purpose of sending packets to CNs with which it
>had arranged for route optimization, while implementing reverse
>tunneling.  Essentially these "reverse tunnels" would go back to CNs,
>but as we can't expect the FA to do source routing per-CN, the MN must
>take care of it.  However, I'm just making up protocol now - could
>someone tell me whether -11 R-O deals with this?  Better yet, could
>someone put a copy up somewhere that I can read?
>

I wasn't proposing that the reverse tunnel go back to  the CN, only
that the new FA be able to use the MN CoA to index to the reverse tunnel
to the old FA, since the packet coming from the MN will have the
CoA and not the home address as the source address. But, as mentioned,
this is unnecessary if the old FA uses the L2 address to
identify which packet should go through the tunnel to the old FA.

But you do bring up an interesting point about how to deal with the
case where the reverse tunnel needs to run to the CN. As far as
low latency is concerned, I think we can basically punt since
the route optimization draft doesn't propose to solve the
fundamental problem.

> > I think saying there is no security is a bit strong, there
> > could be security, it could be prearranged via context transfer
> > or even some configuration step. I think it would be more precise
> > to say that the new FA is not expected to set up a security 
> > association in real time during the handover, but that it SHOULD,
> > at its discretion, choose to support a reverse tunnel as well.
>
>Pre-arranged I could buy (although it would require some other MN from
>that HA to have visited previously), but I hope we don't end up
>transferring security associations.  SAs, especially IPSec SAs, are
>indexed by IP address and I think it would be a bad idea to allow an
>HA to start using an SA for a different communication endpoint just
>because it started getting packets on it.
>

OK.

>OK.  Does anyone have a copy of route optimization -11 that we could
>use to resolve some of the questions above?
>

I'll see if I can find one, but I think that I've got enough to go
on now to rework the POST-REG/BETH  section of the low latency draft.
Thanx.

		jak

---

From: Peter Lei <[email-masked]>
Date: Thu, 06 Sep 2001 12:47:44 -0500

Hi James,

> on outgoing packets, I think.

I think the only time the MN would do this is if it is doing local
decapsulation (ie. colocated COA).  Otherwise, I think the RFC's state
that the MN use its home address as the source address (for both direct
and encasulating delivery styles).  If you could point to some text
that states otherwise, then I've got some code to fix...

--peter