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

From: James Kempf <[email-masked]>
Date: Wed, 5 Sep 2001 13:18:06 -0700 (PDT)

Hi Pete,

In general, I like your proposal, as it is alot simpler, but there
are a few points I think we still need to clear up.

>Note that the tunneling type between the FAs is really orthogonal to
>the tunneling type requested by the mobile node.  See below under your
>proposed 'O' flag.
>

OK.

> > G - MN requested GRE encapsulation, use it in any tunnel with FA or HA
> >     (must be accompanied  by the GRE Key Extension if GRE security in 
> >      effect)
>
>This might be a misconception, and I think it was present in your
>original summary: GRE Key != security.  The GRE Key field is for an
>additional layer of demultiplexing.  That is all.  It is called a
>"key" in the sense of an index, not in a cryptographic sense.
>

OK, sorry. I misread the GRE draft. Should go back and check it again.

> > O - old FA is performing optimizations on MNs traffic (compression, 
> >     PPP, etc.), tunnel through the old FA regardless of egress filtering
> >      status on new subnet.
>
>Note that to support this, we MUST have GRE tunneling between the two
>FAs, and the GRE Protocol Type could be used to signal that we will be
>sending already-compressed packets.  The Protocol Type is part of the
>GRE Extension:
>
>ftp://ftp.isi.edu/internet-drafts/draft-calhoun-mobileip-gre-ext-00.txt
>

I will check out the reference. 

> > R - Route optimization is in effect and the MN is using CoA as the source
> >     address. MN's old CoA included in the message instead of the MN's 
> >     home address. The O bit MUST also be set.
>
>I don't understand the concern with route optimization.  As I recall
>(the draft is expired and currently unavailable), R-O is run either
>between MNs and CNs, or MNs and previous FAs.  In either case, it is a
>signaling and security matter between the MN and those other nodes.
>Packets are then tunneled to the MN's care-of address directly from
>CNs or previous FAs, and the care-of address can be either co-located
>or FA-located.  Why would the old FA know or even care whether the MN
>is performing route optimization with CNs?  Why would it affect the
>endpoint of the reverse tunneled traffic?  It seems like R-O only
>affects the path taken by forward direction traffic.
>

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. The current version of HRqst/HRply has the old
FA sending the mobile node's home address and the HA address
in the HRqst/HRply. If the new FA uses the source address to
decide whether to send the packets down the reverse tunnel,
it will not have the right source address with route optimization.
As you point out, there is an issue with the old FA discovering
that route optimization is in effect, and since the draft has expired,
it is not possible at this time to check whether that is covered.

I think this case can be handled by having the new FA use the
mobile node's L2 address to decide whether to send the packets
down the reverse tunnel to the old FA. This won't change regardless
of whether route optimization is used or not, and the new FA
will have that either from the L2 trigger or as a result of
the HRqst(s).

>This seems quite complicated.  I would rather just use the 'T' bit
>that we already have in the Handoff Request/Reply to signal the desire
>by either side to reverse-tunnel packets to the old FA.  If
>either of them set this bit, then reverse tunnel to the old FA is
>enabled.  Either side could set the bit for whatever reason seemed
>aprpropriate.
>

I'm certainly in favor of simplification. In addition, I think
we need to note what you mentioned above that the G bit MUST
be set if the old FA is doing optimizations (compression, PPP, etc.),
and the GRE Protocol Type needs to be set appropriately, as an
additional extension.

>Now, there is an orthogonal question, which is, when we are NOT
>performing reverse tunneling to old FA, we may or may not need to
>reverse tunnel to the HA.  This could be one flag from the old FA to
>the new FA (in either Request or Reply, depending on the trigger type)
>indicating that the FA is currently supporting a reverse tunnel to the
>HA, and that there is currently no security on this tunnel, and the
>new FA SHOULD choose to do so as well.
>

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.

>I think the addition of one new flag such as this, rather than
>redefining all the flags and adding 2 new flags, will cover the cases
>we want to cover adequately, and conveys exactly the information we
>want conveyed.  In other words, the flags in the Handoff messages
>apply to the tunnels established with those messages, not to other
>tunnels that may appear as side effects of the handoff.
>
>In summary: I think your R and O bits could be combined into the
>current T bit.  I would agree with adding an H bit as a form of advice
>from the old FA to the new FA, but it may only be set when the T bit
>is not set.
>

Agreed. Unless there are any other comments, I will write up the
BETH part of low latency with this. 

		jak

---

From: Pete McCann <[email-masked]>
Date: Wed, 5 Sep 2001 18:08:00 -0500

Hi, James,

A few comments/questions:

James Kempf writes:
 > 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.

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?

 > The current version of HRqst/HRply has the old

 > will have that either from the L2 trigger or as a result of

Absolutely, I think this is the right approach.  When reverse
tunneling to the old FA is enabled, the new FA should take ANY packet
from the MN (that is not a registration request intended for itself)
to the old FA.  It should be insensitive to the source address used on
such a packet.  Note that if we are tunneling already-compressed
packets, the new FA would have a hard time discovering the IP address
of a given packet stream anyway because it did not participate in the
header compression context initialization.

 > 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.

 > BETH part of low latency with this. 

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

-Pete