[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPSEC tunnels and Mobile IP
Stephen Waters wrote:
>
> 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!
L2TP has alot of momentum at this time. Support from Carriers is really
required at this time since most L2TP implementations exist in either
NAS' and LNS'. There are very few client implementations (if any) at
this time.
Yes, the overhead is enormous. This is especially true for what is
commonly called Voluntary Tunneling, which allows the 'PPP' client to
setup its own L2TP tunnel to the LNS. In this case, the protocol headers
look like PPP|IP|UDP|PPP|IP.
>
> 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?
Well, the saving of addresses is a moot point. ISPs allocate blocks of
addresses equal to the number of ports on their NASes to ensure that all
dial-in clients get access. Although many would prefer to disagree,
multi-protocol is very valuable.
This is where TEP comes into play. It provides the same functionality as
MobileIP, but also provides Multi-Protocol support (among other
features).
>
> 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.
I suppose I see things differently. I would prefer the application to
handle retransmission. This allows real time protocols to work better in
"tunneled" scenarios.
>
> 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).
Studies I have seen seem to show that VPNs over the Internet will NOT
happen until QOS is widely deployed. The functionality you are
suggesting is interesting, but it assumes that the SOHO router
understands the type of traffic being tunneled in order to know when
data loss occurs.
PatC
Sun