Subject: [MOBILE-IP] I-D ACTION:draft-ietf-mobileip-reg-tunnel-01.txt

From: [email-masked]
Date: Wed, 18 Aug 1999 07:07:19 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF.

        Title           : Mobile IP Regional Tunnel Management
        Author(s)       : E. Gustafsson,  A. Jonsson, C. Perkins
        Filename        : draft-ietf-mobileip-reg-tunnel-01.txt
        Pages           : 27
        Date            : 17-Aug-99

In Mobile IP a mobile node registers with its home agent each time it
changes care-of address.  If the distance between the visited network
and the home network of the mobile node is large, the signaling delay
for these registrations may be long.  We propose a solution for
performing registrations locally in the visited domain:  regional
registrations.  Regional registrations reduce the number of signaling
messages to the home network, and reduce the signaling delay when a
mobile node moves from one foreign agent to another, within the same
visited domain.  This may, for instance, improve the performance of
handover.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-reg-tunnel-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
        "get draft-ietf-mobileip-reg-tunnel-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
        [email-masked].
In the body type:
        "FILE /internet-drafts/draft-ietf-mobileip-reg-tunnel-01.txt".

NOTE:   The mail server at ietf.org can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Pete McCann <[email-masked]>
Date: Tue, 24 Aug 1999 10:59:34 -0500

[email-masked] (I) writes:

I> http://www.ietf.org/internet-drafts/draft-ietf-mobileip-reg-tunnel-01.txt

I read through this draft and I have a couple of problems with it.

1) I do not believe it can correctly handle MNs with private IP addresses.

To quote:

   If the GFA receives a tunneled packet from a foreign agent in its
   domain, then after decapsulation the GFA looks to see whether it
   has an entry in its visitor list for the source IP address of the
   inner IP header after decapsulation.  If so, then it checks the
   visitor list to see whether reverse tunneling has been requested;
   if requested, then the GFA re-encapsulates the packet with its own
   address as the source IP address, and the address of the home agent
   as the destination IP address.

Thus demultiplexing is based explicitly on the IP address of the MN.  What
about the case where these addresses come from overlapping private address
spaces?  The GFA will get confused about to which HA these packets should
be tunneled.  It seems that to properly handle this case GRE tunnels must
be used on the leg from FA to GFA.

2) Complexity

Do we really need to expose all of this machinery to MNs?  It seems to
me that a greater degree of transparency (like that provided by THEMA)
would provide a cleaner architecture.

In this draft, the MN must explicitly realize that it is on a
regionalized network by looking at the 'I' bit, and must be capable of
using the new GFA extension.

3) Security

While most of the regional registration request is protected by a
mobile-foreign authentication extension, one key piece (the Hierarchical
Foreign Agent Extension) is not.  Is a denial of service attack possible
by a MN at a different FA?  Maybe the replay protection between MN and
GFA will help here but I can imagine cases where that would not be
sufficient.

This draft seems incapable of leveraging any link-layer security that
may exist, such as in a cellular network.

-Pete

---

From: Jari T Malinen <[email-masked]>
Date: Wed, 25 Aug 1999 23:13:08 +0200

Hello, Pete,

> 1) I do not believe it can correctly handle MNs with private IP addresses.

Right, as far as I understood, the support is not there and would be
reconsidered in the future after the private addressing issues
hopefully clear out. Then, I would vouch for the use of GRE tunnels
which would be straightforward even here. In Oslo there was a comment
that disapproved with the idea of relying on GRE tunnels. Why was that?

> would provide a cleaner architecture.

Perhaps, though decision making needed in the MN is simple.  And both
a non-regional-aware MN and a similar HA can be used with a regional FA
hierarchy alhough they do not use the localized location updates.

> GFA will help here but I can imagine cases where that would not be

Correct me if I am wrong, but isn't it easy to cause a DOS attack, anyway?
Besides a misconfigured microwave oven in the WLAN environment,
what if an attacker, call it MN2, snoops the address of the victim
MN, has a conspiring HA2, and sends a location update to the FA
which redirects the home link to HA2? MN2 and HA2 naturally use
the same shared secret. What if the MN uses itself (an alias interface,
perhaps), as HA2? How about this with a RFC-only FA?

> may exist, such as in a cellular network.

This does not prevent from statically configuring link-layer encryption,
at least in a WLAN environment. To get other security aspects besides
privacy, which was considered out of scope for the Mobile IP protocol,
maybe use of a network-level solution, such as the IPSec would be more
in line with the spirit of this draft?

Key management assisting the use of link-level security would be nice,
but aren't such extensions independent enough from the actual issue of
the draft so that they could be defined in another draft, in the regkey,
perhaps?

> -Pete

--jari

Jari Malinen (http://www.cs.hut.fi/~jtm)
Researcher, HUT/CS Lab. Tel. +358 9 451 4774, fax +358 9 451 5351.

---

From: Pete McCann <[email-masked]>
Date: Wed, 25 Aug 1999 17:35:27 -0500

Hi, Jari,

Jari T Malinen <[email-masked]> (JTM) writes:

JTM> In Oslo there was a comment that disapproved with the idea of
JTM> relying on GRE tunnels. Why was that?

I suspect it was the fact that GRE is only an Informational RFC.  I
hope that GRE or something like it can be moved forward in the near
future; these kinds of tunnels seem to require the extra
demultiplexing information.

JTM> what if an attacker, call it MN2, snoops the address of the victim
JTM> MN, has a conspiring HA2, and sends a location update to the FA
JTM> which redirects the home link to HA2? MN2 and HA2 naturally use
JTM> the same shared secret. What if the MN uses itself (an alias interface,
JTM> perhaps), as HA2? How about this with a RFC-only FA?

You are correct that an RFC-2002 compliant FA may be attacked in this
way.  However, a simple work-around is to maintain a separation
between traffic from different link-layer addresses.  In the cellular
environment, we are assured that these link-layer addresses are indeed
authentic.  My point was simply that passing through a IP-in-IP tunnel
destroys this information - it is unavailable to the GFA even if it
was available at the FA.

>> may exist, such as in a cellular network.

JTM> This does not prevent from statically configuring link-layer encryption,
JTM> at least in a WLAN environment. To get other security aspects besides
JTM> privacy, which was considered out of scope for the Mobile IP protocol,
JTM> maybe use of a network-level solution, such as the IPSec would be more
JTM> in line with the spirit of this draft?

Yes, you could use IPsec but that places a greater processing burden on
the MN.

JTM> Key management assisting the use of link-level security would be nice,
JTM> but aren't such extensions independent enough from the actual issue of
JTM> the draft so that they could be defined in another draft, in the regkey,
JTM> perhaps?

Key management and authenticated roaming will be necessary for
commercial deployment of Mobile IP; the visited network will want to
ensure that it gets paid for the services used.  Yes, these protocols
should be independent of regionalized registrations but any protocol
used in the access network should make sure not to destroy information
needed to ensure security properties.

-Pete