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