Subject: L2TP-IPSec features list

From: "William Dixon" <[email-masked]>
Date: Thu, 18 May 2000 17:11:39 -0700

L2TP list fyi.

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. (bcc'ed to ipsec and ipsra WG
lists to avoid reply-all)

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