230 likes | 408 Views
Land of confusion. l2tpd - L2TP for Unix. Overview of L2TP protocol. Layer 2 Tunnelling Protocol. Product of the PPP Extensions working group of the IETF Largely builds on the work done with L2F at Cisco Backwards compatible with L2F. L2TP features. Encapsulates PPP Utilizes UDP
E N D
Land of confusion l2tpd - L2TP for Unix
Layer 2 Tunnelling Protocol • Product of the PPP Extensions working group of the IETF • Largely builds on the work done with L2F at Cisco • Backwards compatible with L2F
L2TP features • Encapsulates PPP • Utilizes UDP • Reliable Signalling channel ("Control Connection") • Unreliable Data Channel • Data Channel sequencing • Tunnel level authentication
Applications for L2TP • Half of a secure VPN implementation • Overlay network • Avoid University firewalls • Remote static IP address • Global addressing behind NAT
L2TP Header Format 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T|L|x|x|S|x|O|P|x|x|x|x|Version| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length (opt.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number (Ns) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Expected Sequence Number (Nr) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Offset Size (opt.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Offset Pad (opt.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T=Type bit Set for control packets L=Length bit Set if Length field is present S=Sequence bit Set if sequence numbers are present, always set for Control messages O=Offset bit Set if offset field is present Rarely used P=Priority bit Set if this packet should be given preferential treatment I've never seen this used Version Set to 2 currently, 1 indicates L2F as it used substantially the same header format
L2TP Header Format 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T|L|x|x|S|x|O|P|x|x|x|x|Version| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length (opt.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number (Ns) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Expected Sequence Number (Nr) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Offset Size (opt.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Offset Pad (opt.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length Total length of L2TP packet Tunnel ID Identifies Tunnel that this packet is associated with Session ID Identifies Session within the tunnel that this packet is associated with Sequence Number (Ns) Start with 0, increment for each packet in tunnel Expected Sequence Number (Nr) Sequence number expected in next packet from peer Offset Size Size, in octets of Offset Pad field Offset Pad Undefined “filler”
L2TP AVP Format 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|H| rsvd | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...[until length is reached... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ M=Mandatory bit If you don't understand this AVP, shut down the tunnel or session H=Hidden bit This attribute is "hidden" Length Overall length of the AVP, including these headers (minimum value of 6) Vendor ID 0 for IETF defined AVP's Attribute Type What attribute is this? Attribute Value Actual attribute data (if Length field is 6, this field is absent)
L2TP Message Types • 1 - SCCRQ - Start Control Connection ReQuest • 2 - SCCRP - Start Control Connection RePly • 3 - SCCCN - Start Connection Control CoNnected • 4 - StopCCN - Stop Control Connection Notification • 6 - HELLO - HELLO • 7 - OCRQ - Outgoing Call ReQuest • 8 - OCRP - Outgoing Call RePly • 9 - OCCN - Outgoing Call CoNnected • 10 - ICRQ - Incoming Call ReQuest • 11 - ICRP - Incoming Call RePly • 12 - ICCN - Incoming Call CoNnected • 14 - CDN - Call Disconnect Notification • 15 - WEN - Wan Error Notify • 16 - SLI - Set Link Info
The Future of L2TP - L2TPv3 • New data channel header format • Clarify ambiguities in current standard • Encapsulates other types of frames than PPP (work with PWE3 - Pseudo Wire Emulation Edge to Edge) • Ethernet • Frame relay • Circuit emulation
History of l2tpd • Originally written by Mark Spencer http://marko.net last version 0.60 • Forked in 2000 by Scott Balmos and David Stipp, hosted on Sourceforge http://sf.net/projects/l2tpd • Turned over control in Jan. 2002 to me • Obtained support of Mark Spencer for further development as well • Further detail at http://www.l2tpd.org/history.html
l2tpd features • Tunnel level authentication (currently broken) • Works as both LNS and LAC (only with PPP on same system) • "Autodial" • pre-configured peers • "interactive" control (named pipe)
Known bugs • Challenge Response authentication on tunnels broken • Data channel sequencing support doesn't exist • pty handling is horrible, though works after a fashion • Session and tunnel shutdown works, barely
l2tpd - current work directions • Bugfixing, bugfixing, bugfixing • Easily integrated new features (data sequencing) • Knobs for interoperability • Did I mention bugfixing? • No significant new feature work
l2tpd-devel • What I'm calling the "next-generation" l2tpd • No working code available yet • kernel-module • pppd plugin • l2tpd daemon
"Interactive" use of l2tpd echo "t 204.255.233.225" > /var/run/l2tp-control Standard output of l2tpd gives you a tunnel ID: control_finish: Connection established to 204.255.233.225, 1701. Local: 17767, Remote: 86. echo "c 17767" > /var/run/l2tp-control
/etc/l2tp/l2tpd.conf [global] port = 1701 [lns default] ip range = 192.168.0.1-192.168.0.2 lac = 10.0.0.0 - 10.255.255.255 hidden bit = no refuse chap = yes require authentication = yes ppp debug = yes [lac cindsl01] lns = 204.255.233.225 autodial = yes [lac iostest] lns = 199.170.85.70
Encryption Encryption Encryption Protocol overhead Why L2TP vs. IPSec Tunnel Mode L2TP IPSec Tunnel • Multi-Protocol • Authentication flexibility • Works via NAT • Multi-Link PPP avoids MTU issues
Weak encryption Microsoft Non-standard Why L2TP vs. PPTP L2TP PPTP • Open standard • Not Microsoft - 'nuff said
Low protocol overhead Simple configuration No dependancy on PPP Why L2TP vs. GRE or IPIP L2TP GRE/IPIP • Scaleability • Control protocol mechanism • Authentication • Multi-protocol
Can carry varied types of traffic Open Encryption Traffic Shaping Why L2TP vs. VTun L2TP VTun • Interoperability • Open standard