[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: IPSEC tunnels and Mobile IP


I agree,  but that would need IPV6 to fix someday.

I should explain the base meaning behind my original note:  I was
referring to the use that some have made of Mobile IP for Dial-access
VPNs (looks like the L2TP ISP-based model, except both tunnel end-points
are within the VPN carriers network).

I am trying to settle (my mind) on just one tunneling technology, and my
favorite is IPSEC tunnels at the moment.

I do still have some reservations about IPSEC for tunneling that I'd
like to kill-off, fix, or learn how to live with:  

1) What is happening now.  Client-based L2 tunnel (PPTP, L2TP soon) seem
to rule the waves at the moment.  No support is needed from the VPN
carriers.  I know there are problems with this model,  but it is
available and it is simple. IPSEC Clients are offered by some (NewOak,
Ascend, others?),  and I'm sure they are just as flexible, more
scalable, and have less bandwidth overhead.  I guess I've talked my self
out of that one then!

2) ISP-based model for L2TP.  This seems to offer some advantage over
the client-based option.  It  'hides' the client from non-tunnel
traffic; the client does not have a global IP address (saving on
addresses); the client does not need to know the tunnel-server address;
Dial-media information present at the NAS/LAC can be forwarded to the
LNS; and PPP is more suitable for multi-protocol support (e.g. bridged
LANs).  I can think of ways that all these services could be resolved
for IPSEC (filtering, NAT, PPP IPCP, DNS), but what services are offered
by VPN carriers?

3) General LAN-to-LAN problem.  The L2TP spec spends a bit of time
discussing the problems with protocols that dislike reordering
(LAN-based protocols) and protocols that dislike packet loss (standard
PPP compression/encryption) by suggesting that Reliable PPP and L2TP
reordering could be used. IPSEC/IPCOMP fixes the packet-loss issue
(although block-mode encryption and compression is more crackable/less
efficient that history-mode),  but what is the IPSEC response to
encapsulating bridged traffic and insuring there is no reordering?  The
conclusion I have come to at the moment is that I either invent some way
of injecting a reliable data-link into my IPSEC tunnel, or I just wait
for the VPN carriers to offer me a better service for LAN-to-LAN
requirements.

4) Throughput monitoring.  While I'm waiting for VPN carriers to support
an 'SVC' QOS,  it is tempting to think of a high-speed Internet pipe
(Cable Modem/xDSL) as a very good value for money LAN-to-LAN pipe WHEN I
CAN GET GOOD QOS.  As a remote worker (Home Office), I have tried to use
the Internet to connect to work, but the performance can drop-off
alarming at times,  so instead, I dial direct with ISDN.  What I really
want is a smart SOHO router that can detect when things are going
pair-shaped (big drop in QOS) on the VPN tunnel,  shut the tunnel down
for awhile, and dial direct - all without me lifting a finger.  The base
problem is knowing how much of the data you pump into the VPN tunnel
actually gets to the peer tunnel end-point!   If my SOHO router could
monitor that dynamically with reference to some 'Minimum Throughput'
setting, I'd be in with a shout.  For Bridged LANs, the problem is worse
- I need to know how much of the data got to the peer without getting
reordered.  The only way I can see to fix both of these problems is to
either run RPPP (for L2TP case) or squeeze a TCP header into the IPSEC
tunnel (not a popular concept, I know).

Does anyone have such a device?

If you've read all that, thanks. I hope it wasn't too irksome!
Any pointer on 'real world' VPN carrier offerings appreciated - I looked
on a dozen of the larger ISP sites for anything about VPNs, and got
nothing.

Cheers, Steve.






















	-----Original Message-----
	From:	Steve Bellovin [SMTP:smb@research.att.com]
	Sent:	Friday, February 27, 1998 8:07 PM
	To:	ho@earth.hpc.org
	Cc:	rgm-sec@htt-consult.com; ipsec@tis.com
	Subject:	Re: IPSEC tunnels and Mobile IP 

		 > IMNSHO, Mobile IP is for mobile units. ie cars,
tanks, soldiers, and
		 > pedestrians.  A notebook I plug into a phone jack in
a hotel, car de
		aler,
		 > or conference LAN does not need Mobile IP, only
IPsec.
		 
		 While not disagreeing in principle, I'd like to note
that there is
		 tremendous utility in using a dynamically assigned IP
address from the
		 wireless provider and setting up IPSEC tunneling
associations
		 authenticated by user identity.  In this way, a laptop
can be mobile
		 throughout a large wireless service structure and
maintain secure
		 connections without the necessity for level 3 handoffs.

	Yes.  IP addresses -- especially IP addresses of dial-up clients
--
	are transient and meaningless.  The sooner we get away from
them,
	the better.