Transcript Mark Townsley Presentation

Pseudowires and L2TPv3
W. Mark Townsley
[email protected]
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
Pseudowire
(Layer 2 Tunnel)
Tunnelled
serial interface
R3
tu1
pos2
pos1
R1
pos3
e2
e1
LAN1
tu2
LAN2
Tunnelled LAN
pos4
IP Network
R2
R4
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
IP + FR PoP
Global IP
Backbone
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
1. An efficient layer 2 tunneling and
multiplexing encapsulation
2. Explicit configuration or signaled
negotiation of service specific parameters
between edge routers
3. Method for signaling, timing, order or
other aspects of the service between edge
routers
4. Light and heavy duty security options
PWE3 Encapsulation Layering
Focus of PWE3 - above a PSN specific multiplexing layer
Bit type
specific
Payload (circuit/cell/packet)
Packet type
Cell type
specific
specific
Optional RTP/Sequencing
Fragmentation
L2TPv3
Length
PWE3 IP
convergence
definition
IPv4
IPv6
Inner Label
MPLS
PWE3 Payload
encapsulation
definition
PWE3 MPLS
convergence
Definition based
on draft-martini
MAC/Data-Link
Physical
[PWE3LYR]
L2TPv3 Encapsulation
int2
R1
IP Network
int3
e2
e1
Payload
R2
IP L2TP Payload
Payload
L2TPv3 L2 Tunnel
L2TPv3 Tunneled LAN
IP
20 Bytes
Session Identifier
4 Bytes
L2TPv3 Tunneled LAN
L2TPv3 Header
4 - 12 Bytes
Payload
Cookie
0,4,8 Bytes
[L2TPv3]
Tunneling Protocol Requirements
for PWE3 over IP
1. An efficient layer 2 tunneling and
multiplexing encapsulation
2. Easy tunnel setup, and negotiation of
service specific parameters between edge
routers
3. Method for signaling, timing, order or
other aspects of the service between edge
routers
4. 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 “lightduty” 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
1. An efficient layer 2 tunneling and
multiplexing encapsulation
2. Explicit configuration or signaled
negotiation of service specific parameters
between edge routers
3. Method for signaling, timing, order or
other aspects of the service between edge
routers
4. 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
1. An efficient layer 2 tunneling and
multiplexing encapsulation
2. Explicit configuration or signaled
negotiation of service specific parameters
between edge routers
3. Method for signaling, timing, order or
other aspects of the service between edge
routers
4. 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