[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: L2TP-IPSec feature list

To: William Dixon <wdixon@Exchange.Microsoft.com>
Subject: RE: L2TP-IPSec feature list
From: "Waters, Stephen" <Stephen.Waters@cabletron.com>
Date: Wed, 24 May 2000 11:28:58 +0100
Cc: ipsec@lists.tislabs.com
Sender: owner-ipsec@lists.tislabs.com
I don't see anything here that has not already been achieved or is
achievable without using L2TP.
 
IPSEC or IPIP tunnels+IPSEC implementations can and do support all of there
features - with the exception of the L2TP specific things like L2TP header
compression).
 
The number of vendors testing L2TP+IPSEC at the last bake-off may be a
reflection of the need to support a certain client (point 17)  that will no
doubt become widely used.
 
I can assure you that L2TP Head-ends are unlikely to model L2TP client
connections as 'interfaces'!  The divide between interfaces and tunnels is
an architectural one specific to each implementation. Many vendors support
both models as appropriate - Interfaces for LAN-LAN, 'dynamic-static' routes
for clients.
 
L2TP may go through NAT (has a port), but this is at the expense of UDP
check-sums.
IPSEC is fine for most 'useful' cases (LSNAT/anonymity for head-end).
 
This 'to L2TP, or not to L2TP' debate could run and run.  Personally, as an
engineer involved in 'head-end' design, IPSEC+L2TP+PPP is a nightmare!
'Third generation' head-end devices are just getting their teeth into ASIC
support for IPSEC transform/tunnel processing, and now they have to deal
with L2TP+PPP as well!  It may be O.K. for a 600/700Mhz PC to keep itself
warm that way, but for a scaleable head-end, being able to focus on IPSEC
tunnels is a major plus.
 
Steve.
 
 
 
  
 
 
   
 
 
 

-----Original Message-----
From: William Dixon [mailto:wdixon@Exchange.Microsoft.com]
Sent: Wednesday, May 24, 2000 7:11 AM
To: ipsec@lists.tislabs.com <mailto:ipsec@lists.tislabs.com> 
Subject: L2TP-IPSec feature list



Here is an expansion of the features Skip noted earlier in a deep thread for
L2TP/IPSec from a protocol design view, not what any particular one vendor
implements.  No particular order.  Not a comparison with IPSec tunnel mode
except for a couple of points. 

L2TP benefits --------- 
1) L2TP supports 4 VPN scenarios 
  a.) legacy client PPP dial to NAS - NAS PPP user auth, NAS forwards PPP
through L2TP tunnel to L2TP gateway 
  b.) L2TP/IPSec capable client PPP dial to NAS - voluntary L2TP/IPSec to
L2TP gateway 
  c.) L2TP/IPSec capable client directly on IP network - user voluntary
L2TP/IPSec tunnel to L2TP gateway 
  d.) L2TP/IPSec gateway to gateway 
     (2) PPP options can be varied depending on capabilities of IPSec SA,
since the SA is established first - e.g. encryption & IPCOMP compression on
SA means no PPP compression needed

     (1) idea of a user for tunnel helps scalable management of remote
tunnel end-points via radius. 
2) can have multiple L2TP tunnel sessions inside 1 IPSec SA pair for
efficiency 
3) can have single L2TP tunnel session (choose UDP source port) mapping to
single IPSec SA pair - preserves binding of SA to tunnel to user - to the
extent you can control what user traffic goes into tunnel to start with.

4) keep alives for L2TP 
5) don't have to use L2TP sequence numbers (can't with L2TP header
compression) because IPSec seq numbers can detect packet loss & estimate
path latency

6) new spec for L2TP MUX of PPP packets inside a single L2TP UDP datagram -
popular to reduce overhead for tunneling small IP packets, like VoIP

7) new L2TP header compression draft gets [UDP][L2TP] header overhead down
to 1 or 2 bytes for majority of the tunnel.  This is 1-2 bytes per packet
more than pure IPSec tunnel mode - using PPPMUX mode of L2TP means several
PPP frames per tunnel IP packet

8) extensibility of L2TP with Attrib Value (AV) pairs, avoid extending,
complicating IKE key management protocol 
  a.) AV delivered dynamic redirection of gateway dest IP for global load
balancing 
  b.) AV delivered QOS values 
9) can use IPSec tunnel and transport filters which apply to assigned tunnel
IP address above L2TP/PPP interface 
  a.) enables tunnel within a tunnel with full interface support 
  b.) enables static filtering & routes applied via Radius policy to tunnel
interfaces 
10) basic L2TP is most interoperable - even before IKE & IPSec, RFC solution
designed specifically for remote access, dial remote access in particular -
which estimates show to be 60-70% of the worldwide Internet connection
method (PPP in general by all platforms, not L2TP/IPSec) in 2003.

11) more vendors testing L2TP/IPSec interop (14) at last bakeoff than
testing XAUTH/IKECFG (7) 
12) use of MM/QM in transport mode makes IPSec policy consistently transport
- just an ease of maintenance thing.  So IKE negotiation for L2TP (UDP port
1701) protections are just another port QM, as are QMs for other things like
connections to application proxies that run on the same box.  Your transport
packet filters for permit & block & secure are easy to see and evaluate.
You don't have to worry about a tunnel policy for access from any Client IP
to an internal subnet in conflict with transport filters to block a specific
type of traffic regardless of addresses. 

13) Some vendors implement IPSec tunnels as routable interfaces, some
implement as strictly filter driven - don't have to worry about this for
L2TP - they are all interfaces.

  a.) can run routing protocols across tunnel interoperable with other
vendors 
  b.) can carry standard, routable IP across tunnel, e.g. multicast,
broadcast, unicast IP 
14) L2TP can be used in clear text mode without IPSec and get all of the
tunneling benefits when security is not a problem.

15) Without IPSec, L2TP over IP can go through NATs because it uses UDP
1701. 
16) L2TP/IPSec 
17) L2TP/IPSec VPN clients are becoming widely available by their inclusion
in Windows 2000 and future releases.  Their availability for VPN has been
announced since August 1998 when the L2TP/IPSec client was included in Beta2
of Windows 2000.

18) Most remote access implementations support both machine auth first with
either preshared key, or much stronger certificate auth, then user auth

19) L2TP/IPSec fully replaces and is a superset of PPTP functionality and is
much more secure 
20) L2TP/IPSec today offers more features as RFC standard than IPSec tunnel
mode does currently 
21) L2TP is defined to run over ATM, frame relay and X.25 non-IP transports 
22) IPSec encryption & integrity protection and IPCOMP can be hardware
accelerated 


PPP Benefits ---------- all RFC standard methods, I believe 
1) IP/DNS/WINs assignment through IPCP 
2) User authentication 
  a.) userid/password 
  b.) EAP and EAP/TLS - for certificate, smartcard, SecurID, token card,
biometric 
3) AAA integration - with existing AAA servers, RADIUS TACACS 
4) multi-protocol support 
5) Link layer negotiation for MRU (this may help in the fragmentation arena)

6) Keepalives for both PPP 
7) Multilink PPP for bundling bandwidth 
8) Routable interface 
9) PPP compression 
10) supports idea of demand dial, so you can have demand dial filters that
kick off the PPP dial activity, and different filters which apply above the
interface 

11) supports idea of persistent and autostart connections, so links can come
up automatically and be maintained 

Wm 


William Dixon 
Program Manager - Internet Protocol Security 
Windows Operating Systems Division 
Microsoft Corporation 
One Microsoft Way 
Redmond, WA 98052-6399 
Email: WDixon@microsoft.com (preferred), Work: 425-703-8729 

Newly updated Windows 2000 IPSec end-to-end walkthrough & mini-whitepaper
(which covers IKE's use of certificates):
http://www.microsoft.com/windows2000/library/technologies/security/default.a
sp
<http://www.microsoft.com/windows2000/library/technologies/security/default.
asp>
Prev by Date: RE: L2TP+IPsec and IKE authentication
Next by Date: RE: NAT and IPSEC issues:- Question
Prev by thread: L2TP-IPSec feature list
Next by thread: L2TP+IPsec and IKE authentication
Index(es):
- Main
- Thread