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

From: James Kempf <[email-masked]>
Date: Wed, 5 Sep 2001 10:11:54 -0700 (PDT)

Hi Pete,

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

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.

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.

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?

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.

		jak

---

From: Pete McCann <[email-masked]>
Date: Wed, 5 Sep 2001 14:30:43 -0500

Hi, James,

James Kempf writes:
 > >FA.

Maybe it is suboptimal, but at least it will work.  In my book this
is more-optimal than not working. :)

 > requirements apply, except that there will be no communication with

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.

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

 > tunnel back to the old FA, which could take care of the reverse

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