Pseudowires and L2TPv3

1. Pseudowires and L2TPv3 W. Mark Townsley townsley@cisco.com

2. Goals • Define the term“Pseudowire” and its relation to an “L2VPN” • Discuss motivations for a converged network • Overview of the IETF PWE3 framework • Overview of L2TP as a tunneling protocol for PWE3 over IP

3. Pseudowire • Defined by the IETF PWE3 (Pseudowire Edge to Edge Emulation) WG • Emulates the essential attributes of a (typically layer 2) service, such as Frame Relay, PPP, T1, Ethernet, ATM, etc. over a packet switched network. • The packet switched network could be an IP network or an MPLS network (this talk will focus more on IP)

4. L2VPN • A collection of pseudowires carrying emulated data links over a converged network. • For operation over an IP network, an important building block is an interoperable tunneling protocol for carrying each link to the participating edge routers.

5. Pseudowire (Layer 2 Tunnel) Tunnelled serial interface tu1 pos3 pos2 R4 R3 pos4 IP Network pos1 R2 e2 R1 e1 tu2 LAN1 LAN2 Tunnelled LAN Sample L2VPN Using Pseudowires

6. Network Convergence • Before: Parallel Networks • Duplication of international links • Separate equipment in the PoPs for each distinct service Paris Miami IP PoP IP PoP Global IP Backbone FR PoP FR PoP Global FR Backbone Milan IP PoP FR PoP

7. Network Convergence • After: Unified Network • Single set of backbone links for the IP network • FR and IP services from the same set of platforms in the IP + FR PoP • L2TPv3 tunnels across the IP backbone for FR services Paris Miami IP + FR PoP Global IP Backbone IP + FR PoP Milan IP + FR PoP

8. Other Examples of Convergence • Frame Relay over ATM networks [FRF.5] • T1, E1 and T3 circuits over ATM networks [ATMCES]. • Voice over ATM (AAL2), Frame Relay [FRF.11], IP (VoIP) and MPLS networks. • PPP is carried over IP, ATM and Frame Relay networks [L2TP].

9. Tunneling Protocol Requirements for PWE3 over IP • An efficient layer 2 tunneling and multiplexing encapsulation • Explicit configuration or signaled negotiation of service specific parameters between edge routers • Method for signaling, timing, order or other aspects of the service between edge routers • Light and heavy duty security options

10. PWE3 Encapsulation Layering Focus of PWE3 - above a PSN specific multiplexing layer Payload (circuit/cell/packet) Bit type specific Packet type specific Cell type specific PWE3 Payload encapsulation definition Optional RTP/Sequencing PWE3 IP convergence definition Fragmentation L2TPv3 Length PWE3 MPLS convergence Definition based on draft-martini Inner Label IPv6 IPv4 MPLS MAC/Data-Link Physical [PWE3LYR]

11. IP 20 Bytes L2TPv3 Header 4 - 12 Bytes Payload int2 int3 IP Network R1 R2 e2 e1 IP L2TP Payload Payload Payload Session Identifier 4 Bytes Cookie 0,4,8 Bytes L2TPv3 L2 Tunnel L2TPv3 Tunneled LAN L2TPv3 Tunneled LAN L2TPv3 Encapsulation [L2TPv3]

12. Tunneling Protocol Requirements for PWE3 over IP • An efficient layer 2 tunneling and multiplexing encapsulation • Easy tunnel setup, and negotiation of service specific parameters between edge routers • Method for signaling, timing, order or other aspects of the service between edge routers • Light and heavy duty security options

13. L2TP Control Plane • L2TP has an in-band, reliable, control plane used for tunnel setup and maintenance • Control plane operates its own reliable datagram protocol, documented as a part of RFC2661 • By design, it is not TCP, though it borrows from TCP with adapted windowing, congestion control, and slow start methods.

14. SCCRQ SCCRP SCCCN L2TP Control Connection Three message handshake establishes the reliable Control Connection and advertises capabilities between peers.

15. L2TP Control Connection • Once a Control Connection is established, multiple tunnels (sessions) may be setup “automagically” as needed • Includes optional Challenge/Handshake mutual peer authentication method (a “light-duty” security choice) • 3-way handshake is used to establish identity, advertise, and negotiate capabilities between peers.

16. L2TP Session Establishment • In L2TP, each tunnel between the same endpoints is referred to as a “session”. A similar 3 message exchange is used to establish each session. ICRQ ICRP ICCN

17. L2TP Control Messages • Control plane is designed to easily accept new messages for reliable delivery • Standard methods for “vendor specific” message type number space, as well as IETF number space • Attribute-value pair (AVP) message construction

18. Tunneling Protocol Requirements for PWE3 over IP • An efficient layer 2 tunneling and multiplexing encapsulation • Explicit configuration or signaled negotiation of service specific parameters between edge routers • Method for signaling, timing, order or other aspects of the service between edge routers • Light and heavy duty security options

19. L2TP Maintenance • Messages are sent over the in-band reliable control plane to signal all line events, advertise a state changes, establish and teardown new sessions, etc. • Single keepalive operates for all sessions between two endpoints • Sequencing and TDM emulation operates above the tunnel

20. Tunneling Protocol Requirements for PWE3 over IP • An efficient layer 2 tunneling and multiplexing encapsulation • Explicit configuration or signaled negotiation of service specific parameters between edge routers • Method for signaling, timing, order or other aspects of the service between edge routers • Light and heavy duty security options

21. L2TP Security • “Heavy Duty” choice: RFC 3193 “Securing L2TP with IPsec” • IPSec operates in Transport Mode, L2TP is responsible for tunneling • Gives operator the option of turning security on or off at will, decoupling the tunneling system from the security method

22. L2TP Security • Light duty options: • Control Connection Authentication • L2TPv3 “Cookie field” random 64 bit value in each data packet associated with session to protect against a malicious blind attack, or inadvertent insertion of data into the tunnel stream.

23. Blind Insertion Attack • Blind – The attacker as no access to any data flowing on the provider’s network, only the ability to insert spoofed data at will. • In order for the packet to not be dropped, the attacker will have to guess a 64-bit random value.

24. Brute Force Insertion • Goal, to get one 40 byte spoofed packet inserted onto a VPN at OC48 • 20 bits – 130 ms • 32 bits – Under 10 min • 64 bits – 75K years

25. Brute Force Insertion • Goal, to get one 40 byte spoofed packet inserted onto a VPN at OC192 • 20 bits – 34 ms • 32 bits – Under 3 min • 64 bits – 18K years

26. What’s new in L2TPv3? • Majority of functionality unchanged • Tunnel setup, control channel, maintenance… • New encapsulation for IP, resurrection of Cookie field • Separation of the base tunneling protocol from PPP • draft-ietf-l2tpext-l2tp-base-01.txt • draft-ietf-l2tpext-l2tp-ppp-01.txt

27. L2TP Timeline • August 1996 - First version of L2TP Internet Draft published • May 1997 - First multivendor interoperability workshop (“bakeoff”) at Pacific Bell • Nov 1997 - First version of L2TP over IPsec Internet Draft submitted • Aug 1999 – RFC2661 published

28. L2TP Timeline • Jun 2000 – Ethernet over L2TP Internet draft submitted • July 2001 – First version of “l2tp-base” a.k.a. L2TPv3 submitted to WG • Aug 2001 – First PWE3 WG Meets at 51st IETF in London

29. Summary • Pseudowires provide network convergence by emulating a variety of data links over a common packet switched network • Pseudowires may be operated over IP without modification of IP core routers • L2TPv3 is a tunneling protocol that has a large base of operational experience and standardization in the IETF that is being used for pseudowire tunneling

30. References • [PWE3] draft-ietf-pwe3-framework-00.txt • [PWE3LYR] draft-bryant-pwe3-protocol-layer-00.txt • [L2TPv3]draft-ietf-l2tpext-l2tp-base-01.txt • [L2TP] RFC2661 • [ATMCES] ATM Forum, "Circuit Emulation Service Interoperability Specification Version 2.0" (af-vtoa-0078-000), January 1997. • [FRF.5] O'Leary et al, "Frame Relay/ATM PVC Network Interworking Implementation Agreement", Frame Relay Forum FRF.5, December 20, 1994. ITU Recommendation Q.933, Annex A, Geneva, 1995. • [FRF.11] R. Kocen and T. Hatala, "Voice over frame relay implementation agreement", Implementation Agreement FRF.11, Frame Relay Forum, Foster City, California, Jan. 1997.

31. End