Subject: Re: [MOBILE-IP] Reverse Tunneling updates?

From: "BINAR, Simon" <[email-masked]>
Date: Tue, 16 Nov 1999 15:47:37 -0000

I totally agree with you about this problem, and I already pointed out
this problem a few months ago (in the attached mail message). The
questions I had and I still have now are:

- If the decision to use reverse tunneling or not lies with the mobile
node, which criteria should the MN use to perform such a decision? If
the MN is from a home network using private addresses, then I guess the
MN will always use reverse tunnelling. However, if this is not the case
and the MN is located in a visited network that has deployed a firewall
that uses ingress filtering, how should the MN decide when to use
reverse tunnelling? Send several registration requests, and after
several time-outs try it again using a reverse tunnel?

- I guess that usage of firewalls will be a quite common scenario in the
future "wireless Internet". If the MN is configured to always use
reverse tunnels, in order to ensure "global roaming", how does this fit
together with the goals of route optimisation? If a correspondent node
can communicate directly with me using an "optimal route" (whatever that
means) but I can't do it because I am "forced" to use a reverse tunnel,
why bother at all about optimising routes? (just being a little
provocative here... :-))

I think there is a dilemma here...
----------------------------------------------
Simon Binar
NEC Europe Ltd.
Tel:   +44 (0)1753 606933
Fax:   +44 (0)1753 606901
EMail: [email-masked]
-----------------------------------------------
DISCLAIMER:  Any views or opinions expressed in
this E-Mail message should be considered as the
personal views/opinions of the author.  They do
not  necessarily  represent  the  views  of the
author's employer.

> -----Original Message-----
> From: Yingchun Xu [mailto:[email-masked]]
> Sent: 13 November 1999 17:05
> To: [email-masked]
> Subject: Re: [MOBILE-IP] Reverse Tunneling updates?
>
>
> Since reverse tunneling is mandatory in certain cases such as
> private network
> access and ISP network access, we really need to make it
> mandatory in all cases
> for the reason that it needs to be transparent to end user.
> Can you imagine poor
> users scratching their heads trying to figure out what is
> reverse tunneling and
> when it should be enabled/disabled for different network access.
>
> Even for application developer, it would be almost impossible
> for them to figure
> out when the reverse tunneling should be turned on/off just
> because some
> wireless carriers may always want to have reverse tunneling
> being forced and the
> others don't. It would be a roaming nightmare if that happens.
>
>
> --Yingchun.
>
>
>
>
> Charles Perkins <[email-masked]> on 11/12/99 02:55:44 PM
>
> Please respond to [email-masked]
>
> Sent by:  Charles Perkins <[email-masked]>
>
>
> To:   [email-masked]
> cc:    (Yingchun Xu/MW/US/3Com)
> Subject:  [MOBILE-IP] Reverse Tunneling updates?
>
>
>
>
> Hello,
>
> During the recent Mobile IP working group meeting, I raised the
> question about whether Reverse Tunneling should be considered
> a mandatory feature for implementation by mobility agents.  There
> are several considerations that bear discussion.
>
> First, the question can be subdivided.  It would be simple to
> require that all home agents support reverse tunneling.  I think
> we should impose this requirement.  Very little additional
> implementation burden is created, and the payoff is considerable.
>
> In addition, we could consider requiring foreign agents to support
> reverse tunneling.  This is a bit more work.  I'm still in favor
> of it, but on the other hand I'm sympathetic to the argument that
> doing so would cause existing foreign agents to become noncompliant.
> Perhaps reverse tunneling can be specified as a SHOULD.
>
>
> Secondly, there is a matter of timing for any such additional
> specification.  If we cycle Mobile IP as a Proposed Standard
> with the recent clarifications, then I think that would be a
> good time to put in any upgrades for Reverse Tunneling.  If this
> does not happen, then it would be difficult to put in at any
> later time, because doing so would insert yet another delay as
> the Mobile IP base specification would again have to cycle at
> Proposed Standard.
>
>
> Comments and discussion is invited.
>
> Your hard-typing editor,
> Charlie P.
>

Subject: A question on reverse tunnelling
From: "BINAR, Simon" <[email-masked]>
To: 'Mobile IP E-Mail List' <[email-masked]>
Date: Thu, 2 Sep 1999 12:49:31 -0000

Hello.

I would have a question on reverse tunnelling. I understand that the
motivation for the specification of reverse tunnelling was to enable MNs
to send packets to correspondent nodes even when the MNs are located
behind a firewall that has implemented ingress filtering.

Now I have the following question. I assume that ingress filtering in
firewalls is a "silent process", meaning that the firewall will not
notify a user that his packets have been filtered. Now the question I
have is how a mobile node should know when it has arrived in a domain
that is protected by this type of firewall?

I guess one scenario would be for the MN to send several registration
requests, and after not having received any registration replys to
conclude that it might be located in a network that is protected by a
firewall. The MN would then revert to the use of reverse tunnels.
However, this process doesn't sound very efficient, and could easily
frustrate the user (because it takes ages to get registered).

The other possibility would be for the MN to always use reverse tunnels.
However, this could result in sub-optimal routes, and would not be in
line with the goals of route optimisation. Is there any way out of this
dilemma?

Simon Binar

DISCLAIMER:  Any views or opinions expressed in
this E-Mail message should be considered as the
personal views/opinions of the author.  They do
not  necessarily  represent  the  views  of the
author's employer.

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 16 Nov 1999 08:20:18 -0800

I just started thinking about an idea that may have some potential. In the
PPP world, the PPP client has very little knowledge about the services that
will be provided by the NAS, as most of the service description comes in
the form of authorization information from the AAA infrastructure.

Is there anyway that we could have the AAA dictate to the HA and FA that the
Mobile Node requires reverse tunneling? This would allow the feature to be
turned on/off by the network administrator, and would require less intelligence
(read: minimize configuration problems) on the mobile.

if no AAA is present, then the mobile needs to request reverse tunneling.

Comments?

PatC

---

From: Tom Hiller <[email-masked]>
Date: Tue, 16 Nov 1999 10:27:49 -0600

We discussed mobiles using reverse tunneling all the time in TR45.6 meetings but
not enough people were in favor because ingress filtering does not appear to be
widely deployed, and users can be advised by carriers when to use reverse
tunneling otherwise (i.e. when the HA is in a private network).

Share specific ideas or counter arguments with us and we will consider at our
next TR45.6 meeting.

Tom Hiller

"BINAR, Simon" wrote:
>   --------------------------------------------------------------------------------
>

---

From: Tom Hiller <[email-masked]>
Date: Tue, 16 Nov 1999 11:15:05 -0600

To summarize your idea: The HAAA returns to the FA an "indication" for reverse
tunneling, and the FA provides reverse tunneling independent of the mobile's
registration request?

We already plan an AAA attribute the FA receives that requests various levels of
security with the HA, so we have a place to put such an "indication". Is there
any issue with over-riding the mobile's lack of request for reverse tunneling?

Tom Hiller

---

From: Pete McCann <[email-masked]>
Date: Thu, 18 Nov 1999 11:22:30 -0600

This idea appeared in our "IP Transform Distribution using Mobile IP/
DIAMETER" draft:

http://www.ietf.org/internet-drafts/draft-mccann-transform-00.txt

Look for the "Reverse Tunnel Policy" extension.  Although there was a
lot of disagreement about whether keys for IPSec should be distributed
through AAA, there may still be reasons to distribute the policies
such as which legs require IPSec protection and whether reverse
tunneling is required.

Of course, the specific format of any AAA extension will have to wait
until the AAA protocol is finalized.  As Tom mentioned, the CDMA
carriers plan to do something like this with vendor-specific
extensions to RADIUS in the short term.

-Pete

"[email-masked]" <[email-masked]> (psc) writes:

psc> I just started thinking about an idea that may have some
psc> potential. In the PPP world, the PPP client has very little
psc> knowledge about the services that will be provided by the NAS, as
psc> most of the service description comes in the form of
psc> authorization information from the AAA infrastructure.

psc> Is there anyway that we could have the AAA dictate to the HA and
psc> FA that the Mobile Node requires reverse tunneling? This would
psc> allow the feature to be turned on/off by the network
psc> administrator, and would require less intelligence (read:
psc> minimize configuration problems) on the mobile.

psc> if no AAA is present, then the mobile needs to request reverse
psc> tunneling.

psc> Comments?