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

From: Pete McCann <[email-masked]>
Date: Tue, 4 Sep 2001 13:15:45 -0500

Hi, James,

I agree with your opinion that the reverse tunnel should go to the old
FA.  As stated below in your initial summary, the new FA and HA are
unlikely to share a security association, and without help from the
mobile node (in the form of a registration request going through AAA)
they are unlikely to get one easily.

On the other hand, the old and new FA should already have an
appropriate pair-wise agreement in place because they are supporting
fast handoff based on link layer triggers.  The two FAs need to have a
pre-arranged security association and some degree of trust that the L2
triggers received by one of the FAs will be honored by the other.
This pre-arranged agreement should be leveraged for the reverse tunnel
as well.

Also, handling the ping-pong case, as well as handoff-to-third, should
be much easier if those effects are confined to the FAs until the MN
re-registers itself with the HA.

I also agree with Ajoy's comments about leaving open the possibility
that we will tunnel already header-compressed packets between the two
FAs, rather than just IP packets.

-Pete

James Kempf writes:
 > Here's my opinion about one particular aspect of this issue:
 > 
 > >...
 > >
 > >In favor of the old FA: ...
 > > In addition,
 > >tunneling them to the HA will require a preregistration transaction
 > >between the HA and the new FA, otherwise the HA is in danger of
 > >dropping the packets because the new FA is not yet known. This
 > >transaction will add to the latency of handover, in particular, because
 > >the topological distance between the new FA and the HA is likely to
 > >be longer than the distance between the old and new FAs.
 > >
 > >In favor of the HA: ...
 > > The additional
 > >amount of latency added by the preregistration should not be extreme,
 > >and the FA can buffer outgoing packets until the registration reply
 > >is received, or opportunistically send them to the HA in anticipation of
 > >a successful preregistration.
 > >
 > 
 > The RTT on the preregistration request/reply could cause
 > a significant increase in latency on the handover (like, say, 60 ms if
 > I am in California and my HA is in New Jersey, or 160 ms if I am
 > in Minneapolis and my HA is in Germany), to say nothing of the packet 
 > getting dropped because it is sent UDP. The indicated
 > mitigating measures are relatively unattractive. Optimistically sending
 > the packets runs the risk of the HA dropping them if the preregistration
 > packet never got there, buffering them runs the risk of propagating
 > the latency and causing user perceptible artifacts in the real time stream.
 > One solution would be to deploy regional registration. This would
 > reduce the latency somewhat, but not eliminate it completely. In addition,
 > regional registration is currently not widely deployed and its prospects
 > are uncertain, whereas the need for low latency handoff is very acute
 > and the prospects for immediate deployment are fairly good.

---

From: James Kempf <[email-masked]>
Date: Wed, 5 Sep 2001 12:35:22 -0700 (PDT)

Pete,

Good points. I'm going to try to finish up the BETH section of the
low latency draft this week so Karim can get it integrated and we
can move the draft along.

Looking forward to your response.

		jak
		
>Date: Wed, 5 Sep 2001 14:30:43 -0500
>From: Pete McCann <[email-masked]>
>To: [email-masked]
>Subject: Re: [mobile-ip] Low Latency Issue: Where to Run the Reverse Tunnel?
>
>Hi, James,
>
>James Kempf writes:
> > Hi Pete,
> > 
> > >
> > >FA.
> > The only issue I can see with this is that routing may be suboptimal
> > when the mobile node requests a reverse tunnel from the anchor FA.
>
>Maybe it is suboptimal, but at least it will work.  In my book this
>is more-optimal than not working. :)
>
> > RFC 2344 has been folded into RFC2002bis, so there is now a flag
> > in the Registration Request that allows the mobile node to request
> > a reverse tunnel from the FA to the HA. RFC 2344 recommends a
> > Foreign to Home Authentication extension as the best way  to
> > protect against attacks. If such a security association is not in
> > place, it also suggests an elegant little
> > hack, requiring the mobile node to set the TTL to 255 on its
> > Registration Requests, to disallow a node more than one hop
> > away from posing as the mobile node (of course, this will not
> > stop  an attack from a node on the same subnet). 
> >
> > Naturally, if a tunnel is extended from the new FA to the HA, the same 
security 
> > requirements apply, except that there will be no communication with
> > the mobile node.
>
>As I understand it, these security mechanisms protect the registration
>traffic but not the data traffic.  It is possible for a malicious node
>to inject traffic into the reverse tunnel if the L2 is not protected.
>However, this is a problem with any Mobile IP scenario where the
>visited link is accessible to untrusted nodes.  The low-latency draft
>relies on trust between the neighboring FAs, but does not introduce
>any new vulnerabilities as far as I am aware.  If you can inject
>packets on the L2 from new FA, you could probably do it from old FA as
>well.
>
> > With regard to the proposal I sent out yesterday, do you see any issue
> > with allowing the old FA to indicate whether the mobile node
> > has requested a tunnel to the HA, and having the new FA do the tunnel,
> > provided the proper security association is available?
>
>I have a couple of issues with the proposal you sent out - I will
>respond to it in a separate message.
>
> > One issue I can see is that the new FA may not be in a position to
> > do so if the proper security association is not in place. So
> > maybe rather than making the H flag a MUST, it could be made a SHOULD.
> > This would allow the new FA to optimize routing if the proper
> > security association was in place, if not, the new FA could run the
> > tunnel back to the old FA, which could take care of the reverse
> > tunnel.
>
>Remember, it might not just be a Mobile IP security association
>protecting control traffic, there might also be an IPSec security
>association protecting data traffic.  It takes several round-trips to
>set up one of those.  In this case tunneling data back to old FA, and
>leveraging the security that is already in place there, is the fastest
>(least interruption) way to get the MN's packets to their destination.
>
>-Pete
>

---

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

Ok, thanx Peter. I guess there is no problem with just sending the
home address and HA address in the RO case as well.

		jak

>Date: Thu, 06 Sep 2001 12:47:44 -0500
>From: Peter Lei <[email-masked]>
>Hi James,
>James Kempf wrote:
>> > > 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.
>
>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
>
> 
>> >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
>