Subject: [Mip4] vpn question

From: "Jeremy A. Greene" <[email-masked]>
Date: Fri, 6 Feb 2004 08:58:25 -0500

Having read the vpn traversal draft, I'm left wondering (and amazed at
the 6 tunnel, 129 byte overhead) as to why?!

The definition of 'home' network when talking about wireless seems a bit
misplaced - there is no such thing as 'my' air space.

Granted, if I'm some oddball wandering around with my laptop, come into
my office and connect to a lan, that it may be desirable to drop the
vpn. But a) I don't think that's very real and b) it's probably a very
good thing to have such a nomadic device always use a vpn.

The much more likely use of mip in the near term is for WAN and WiFi
handoff - and in that case you need the vpn!

So, it seems that the premise of a) not wanting to keep my vpn up while
in my 'home' network and b) not wanting data that comes in over a
wireless connection to go through the dmz (and all related security
functions) is not true.

In short, the easiest way to secure a wireless connection is to always
be outside the firewall and vpn in. Given that, why bother with such a
complex and super-high overhead solution? 

I also question the position that routers/vpns/firewalls/etc. are not
likely to have an ha. Maybe true at the inception of mip, but that's a
long, long time ago.

Jeremy

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 6 Feb 2004 16:07:59 +0100

Jeremy,

<chair hat off>

    The only reaon why you would ever consider deploying the mechanisms
in this draft is that you want to deploy mobile-ip, and you have a
legacy VPN setup which you are totally unwilling to change.

In other scenarios, you would be well adviced NOT to go through the
contortions necessary - but real life experience shows that trying to
roll out mobile-ip, one comes across exactly the situation described
here.

> the 6 tunnel, 129 byte overhead) as to why?!

You refer to the 129 bytes as if they were the norm, when they are an
unusual worst case.  The normal case looks like this:

The VPN accounts for 57 bytes without NAT travesal, 65 with.  That is
the baseline for VPNs.

If you were to add Mobile-IP to this in a more regular setup than the
one discussed here, it would add 20 bytes.  If using NAT traversal, 32
bytes; but then you would not need NAT traversal for the VPN, so the
expected MIP overhead would be at most 24 bytes.  This gives a total of
89 bytes as the baseline for VPN + MIP.

The extra contortions this draft uses would add another MIP tunnel, at
the cost of 20 bytes.  You will not reasonably expect to need NAT
traversal for both the MIP tunnels, so it stays at 20 bytes; giving a
net overhead compared to the baseline of _ 20 _ bytes for this solution.

The expected overhead would thus be 109 bytes; where the VPN accounts for
more than half (57), mobility accounts for 40, and NAT traversal accounts
for 12.

> misplaced - there is no such thing as 'my' air space.

Home network is a concept orthogonal to wireless.  It's where your
permanent IP-address is topologically correct, or equivalently where you
Home Agent is situated

> good thing to have such a nomadic device always use a vpn.

Your choice.  The protocols doesn't force you to do it in one particular
way.  But some people want to get rid of the bandwidth limitations of
having to go up to your VPN gateway and down again when they are in the
office.

> handoff - and in that case you need the vpn!

Sure.

> wireless connection to go through the dmz (and all related security

Here we disagree.

> complex and super-high overhead solution? 

You shouldn't. You really shouldn't. But if the network admins won't
change an existing VPN setup, but still want to roll out Mobile-IP,
this is the proposed solution.  If you have an alternative (and there
_are_ other ways, which mostly require changes to IPsec) then do 
write it up!  :-)

> likely to have an ha. Maybe true at the inception of mip, but that's a

It's still a reality for some of the deployment cases we (at ipUnplugged)
come across today.

	Regards,
		Henrik

</chair hat off>

-- 
Mip4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mip4