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

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

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)

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.

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

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

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

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].

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

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

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

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

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.

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

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.

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

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

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

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

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

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

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.

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.

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

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

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

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

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

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

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.

End