MPLS Security PDF

MPLS Security
Agenda
❖ Introduction
❖ MPLS Technology Basics
❖ MPLS Concept
❖ MPLS LDP
❖ MPLS Traffic Engineering
❖ MPLS L3VPN
❖ MPLS L2VPN
Agenda
❖ MPLS in ISP
❖ Introduce MPLS Security
❖ Security Threats
❖ Defensive techniques
❖ MPLS Security Best Practice
What is MPLS ?
Definition
Multi-Protocol: The ability to carry any

Multi payload
Have: IPv4, IPv6, Ethernet, ATM, FR

Protocol
Uses Labels to tell a node what to do

Label with a packet; separates forwarding
(hop by hop behavior) from routing
(control plane)
Routing based on IPv4 or IPv6 lookup.
Switching Everything else is Switching.
Evolution of MPLS
 Evolved from tag switching in 1996 to full IETF standard

covering over 130 RFCs
Optimize MPLS
 Key application initially were Layer-3 VPNs, followed by for SDN and Cloud
Traffic Engineering (TE) and Layer-2 VPNs Optimize MPLS for
packet transport
(Planned)
Optimize MPLS for video First SDN/PCE
Deployments
Complete base MPLS portfolio
First G-MPLS
Bring MPLS to Market Deployment
(Planned)
Large Scale
First L3VPNs First L2VPN First Segment
L2VPN
Deployed Deployments Routing
Deployments
Deployments
(Planned)
Large Scale Large Scale
Cisco ships First MPLS TE First LSM First MPLS TP First PBB-
L3VPN MPLS TE
MPLS Deployments Deployments Deployments EVPN
Deployments Deployments
Deployments
1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015
MPLS Technology Basics
Basics of MPLS Signaling and Forwarding
 MPLS reference architecture

Service (Clients) Management
 MPLS Labels
 MPLS signaling and forwarding Layer-3 VPNs Layer-2 VPNs
operations
Transport
MPLS OAM
 MPLS Traffic Engineering
IP/MPLS (LDP/RSVP-TE/BGP/OSPF/IS-IS)
 MPLS OAM
MPLS Forwarding
MPLS Reference Architecture
PE P P PE
▪ P (Provider) router = Label Switching Router (LSR)

– Runs an IGP and LDP
▪ PE (Provider Edge) router = edge router (LSR)
– Imposes and removes MPLS labels
– Runs an IGP, LDP and MP-BGP
▪ CE (Customer Edge) router
– Not required
▪ Label Distribution Protocol
– UDP/TCP port 646 (multicast/unicast)
– IGP to label binding
▪ Multi-Protocol BGP
– Address-family support (IPv4, IPv6, multicast, etc…)
– Used for VRF route exchange
8
MPLS Labels
 MPLS Label has local significance

 One router assigns the MPLS label independently
 There is no global assignment for the whole network
 No global authority
 20 bits for the label gives label range of 0-1048575
 Default label range might be lower
 Label range is limited on some platforms
 Normal MPLS labels are: 16-1048575
 Reserved label range is: 0-15
MPLS Labels
 Labels used for making forwarding

decision MPLS Label Stack Entry
Label = 20 bits TC S TTL
 Multiple labels can be used for MPLS
TC = Traffic Class: 3 Bits; S = Bottom of Stack; TTL = Time to Live
packet encapsulation
 No limit on the number of labels in a
stack
LAN MAC Header Label, S=1 Layer 3
 Outer label always used for switching Packet
MPLS packets in network MPLS Label Stack (1 label)
 Inner labels usually used for services
(e.g. L2/L3 VPN)
LAN MAC Header Label, S=0 Label, S=1 Layer 3
Packet
MPLS Label Stack (2 labels)
MPLS QoS
 MPLS label has 3 Traffic Class (TC) bits

 Used for packet classification and
prioritization
 Similar to Type of Service (ToS) field in IP
packet (DSCP values) MPLS DiffServ Marking
in Traffic Class Bits IP DiffServ Marking
 DSCP values of IP packet mapped into TC bits
of MPLS label TC DSCP
 At ingress PE router Layer-2 Header MPLS Header Layer 3 Header
 Most providers have defined 3–5 service

classes (TC values)
MPLS Concept
Control Plane
Data Plane
LSRs
 The LSR forwards labeled packets in the MPLS domain.

 The edge LSR forwards labeled packets in the MPLS domain, and it forwards IP
packets into and out of the MPLS domain.
Architecture of LSRs
LSR Architecture Example
MPLS router functionality is divided into two major parts:

the control plane and the data plane.
LSRs:
Architecture of Edge LSRs
Basic MPLS Example
• MPLS core routers swap labels and forward packets based on simple label lookups.
• MPLS edge routers also perform a routing table lookup, and add or remove labels.
Introducing MPLS Labels and Label Stacks
MPLS Labels
 Are 4 byte identifiers used for forwarding decisions

 Define the destination and services for a packet
 Identify a forwarding equivalence class (FEC)
 Have local significance
 Each LSR independently maps a label to an FEC in a
label binding.
 Label bindings are exchanged between LSRs.
FEC and MPLS Forwarding
 An FEC is a group of packets forwarded:

 In the same manner
 Over the same path
 With the same forwarding treatment
 MPLS packet forwarding consists of:
 Assigning a packet to a specific FEC
 Determining the next hop of each FEC
 MPLS forwarding is connection-oriented.
MPLS Label Format
MPLS uses a 32-bit label field that contains the information that follows:
 20-bit label (a number)
 3-bit experimental field (typically used to carry IP precedence value)
 1-bit bottom-of-stack indicator (indicates whether this is the last label before the
IP header)
 8-bit TTL (equal to the TTL in the IP header)
MPLS Labels
 MPLStechnology is intended to be used anywhere

regardless of Layer 1 media and Layer 2 encapsulation.
 Frame-mode MPLS is MPLS over a frame-based Layer 2
encapsulation
 The label is inserted between the Layer 2 and Layer
3 headers.
 Cell-mode MPLS is MPLS over ATM.
 The fields in the ATM header are used as the label.
MPLS Labels: Frame-Mode MPLS
MPLS Label Stack
 Usually only one label is assigned to a packet, but

multiple labels in a label stack are supported.
 These scenarios may produce more than one label:
 MPLS VPNs (two labels): The top label points to the
egress router, and the second label identifies the VPN.
 MPLS TE (two or more labels): The top label points to the
endpoint of the traffic engineering tunnel and the second
label points to the destination.
 MPLS VPNs combined with MPLS TE (three or more
labels).
Example: MPLS Label Stack
 The outer label is used for switching the packet in the MPLS network (points to the
TE destination).
 Inner labels are used to separate packets at egress points (points to egress router
and identifies VPN).
MPLS LDP
Discovering LDP Neighbors
 LDP establishes a session in two steps:

 Hello messages are periodically sent on all MPLS-enabled interfaces.
 MPLS-enabled routers respond to received hello messages by attempting to
establish a session with the source of the hello messages.
 LDP link hello message is a UDP packet sent to the “all routers on this subnet”
multicast address (224.0.0.2).
 TCP is used to establish the session.
 Both TCP and UDP use well-known LDP port number 646.
LDP Link Hello Message
 Hello messages are sent to all routers reachable through an interface.

 LDP uses well-known port number 646 with UDP for hello messages.
 A 6-byte LDP identifier (TLV) identifies the router
(first 4 bytes) and label space (last 2 bytes).
 The source address used for an LDP session can be set by adding the
transport address TLV to the hello message.
Label Space: Per-Platform
• The label forwarding information base (LFIB) on an LSR does not contain an
incoming interface.
• The same label can be used on any interface and is announced to all adjacent
LSRs.
• The label is announced to adjacent LSRs only once and can be used on any link.
• Per-platform label space is less secure than per-interface
label space.
Negotiating Label Space
 LSRs establish one LDP session per label space.

 Per-platformlabel space requires only one LDP
session, even if there are multiple parallel links
between a pair of LSRs.
 Per-platform label space is announced by setting the
label space ID to 0, for example:
 LDP ID = 1.0.0.1:0
LDP Neighbor Discovery
LDP Session Negotiation
LDP Discovery of Nonadjacent Neighbors
 LDP neighbor discovery of nonadjacent neighbors

differs from normal discovery only in the addressing of
hello packets:
 Hello packets use unicast IP addresses instead of
multicast addresses.
 When a neighbor is discovered, the mechanism to
establish a session is the same.
MPLS Unicast IP Routing
MPLS Unicast IP Routing Architecture
 MPLS introduces a label field that is used for forwarding decisions.

 Although labels are locally significant, they have to be advertised
to directly reachable peers.
 One option would be to include this parameter in existing IP
routing protocols.
 The other option is to create a new protocol to exchange
labels.
 The second option has been used because there are too many
existing IP routing protocols that would have to be modified to
carry labels.
Label-Switched Path
 An LSP is a sequence of LSRs that forwards labeled packets of a certain

forwarding equivalence class.
 MPLS unicast IP forwarding builds LSPs based on the output of IP routing protocols.
 LDP advertises labels only for individual segments in
the LSP.
 LSPs are unidirectional.
 Return traffic uses a different LSP (usually the reverse path because most routing
protocols provide
symmetrical routing).
 An LSP can take a different path from the one chosen by an IP routing
protocol (MPLS TE).
LSP Building
LSP Building
PHP: Before
PHP: After
PHP
 Penultimate hop popping optimizes MPLS performance

(one less LFIB lookup).
 PHP does not work on ATM. (virtual path identifier/virtual channel identifier
cannot be removed.)
 The pop or implicit null label uses a reserved value when being advertised to
a neighbor.
Label Allocation in a Frame-Mode MPLS
Network
 Label allocation and distribution in a frame-mode MPLS network follows these
steps:
 IP routing protocols build the IP routing table.
 Each LSR assigns a label to every destination in the IP routing table independently.
 LSRs announce their assigned labels to all other LSRs.
 Every LSR builds its LIB, LFIB, and FIB data structures based on received labels.
Network: Building the IP Forwarding Table
Network: Allocating Labels
Network: LIB and LFIB Setup
Network: Labels and Table Setup
Label Distribution and Advertisement
Label Distribution and Advertisement:
Receiving Label Advertisement
Interim Packet Propagation
Further Label Allocation
Receiving Label Advertisement
Populating the LFIB
Packet Propagation Across
an MPLS Network
Loop Detection
 LDP relies on loop detection mechanisms built into IGPs that are used to
determine the path.
 If, however, a loop is generated (that is, misconfiguration with static routes),
the TTL field in the label header is used to prevent indefinite looping of
packets.
 TTL functionality in the label header is equivalent to TTL in the IP headers.
 TTL is usually copied from the IP headers to the label headers (TTL
propagation).
Normal TTL Operation
TTL and Loop Detection
Steady-State Operation Description
Link Failure Actions
Routing Protocol Convergence
MPLS Convergence
MPLS Convergence After a Link Failure
 MPLSconvergence in frame-mode MPLS does not affect

the overall convergence time.
 MPLS convergence occurs immediately after the routing
protocol convergence, based on labels already stored
in the LIB.
Link Recovery Actions
Link Recovery Actions:
IP Routing Convergence
Link Recovery Actions:
MPLS Convergence
 Routing protocol convergence optimizes the forwarding path after a link
recovery.
 The LIB might not contain the label from the new next hop by the time the
IGP convergence is complete.
 End-to-end MPLS connectivity might be intermittently broken after link
recovery.
 Use MPLS TE for make-before-break recovery.
Lab Demo
MPLS Traffic Engineering
What Is Traffic Engineering?
 Traffic engineering is manipulating your traffic to fit

your network.
 Network engineering is building your network to carry
your predicted traffic.
 TE is commonly used in voice telephony networks.
 TE is a process of measures, models, and controls of
traffic to achieve various goals.
 TE for data networks provides an integrated approach
to managing traffic at Layer 3.
Traffic Engineering Motivations
 Reduce the overall cost of operations by more

efficient use of bandwidth resources
 Prevent a situation where some parts of a network
are overutilized (congested), while other parts
remain underutilized
 Implement traffic protection against failures
 Enhance SLA in combination with QoS
Business Drivers for Traffic Engineering
 Routersforward traffic along the least-cost route

discovered by routing protocols.
 Network bandwidth may not be efficiently utilized:
 The least-cost route may not be the only possible route.
 The least-cost route may not have enough resources to carry all the traffic.
 Alternate paths may be underutilized.
Business Drivers for Traffic Engineering
 Lack of resources results in congestion in two ways:

 When network resources themselves are insufficient to accommodate offered load
 When traffic streams are inefficiently mapped onto available resources
 Someresources are overutilized while others remain

underutilized.
Congestion Avoidance and Traffic
Engineering
 Network congestion can be addressed by either:
 Expansion of capacity or classical congestion control
techniques (queuing, rate limiting, and so on)
 Traffic engineering, if the problems result from
inefficient resource allocation
 The focus of TE is not on congestion created as a

result of a short-term burst, but on congestion
problems that are prolonged.
Traffic Engineering with a Layer 2
Overlay Model
Overlay Model: Example
Overlay Model
 Drawbacks of the Layer 2 overlay solution
 Extra network devices
 More complex network management:
 Two-level network without integrated network management
 Additional training, technical support, field engineering
 IGP routing scalability issue for meshes

 Additional bandwidth overhead (“cell tax”)
 No differential service (class of service)
Layer 3 Model with No Traffic
Engineering
Traffic Engineering with a Layer 3 Model
 The current forwarding paradigm, centered around

“destination-based,” is clearly inadequate:
 Pathcomputation based just on IGP metric is not
enough.
 Support for “explicit” routing (source routing) is not
available.
 Supported workarounds are static routes, policy
routing.
 Provide controlled backup and recovery.
Traffic Engineering with the MPLS TE
Model
Traffic Engineering with the MPLS TE
Model
 The MPLS TE LSPs are created by RSVP.
 The actual path can be specified:
 Explicitly defined by the system administrator
 Dynamically defined using the underlying IGP protocol
How MPLS TE Works
 Link information Distribution*
Head end
 ISIS-TE
IP/MPLS  OSPF-TE
 Path Calculation (CSPF)*
 Path Setup (RSVP-TE)
 Forwarding Traffic down Tunnel*
 Auto-route (announce / destinations)
 Static route
 PBR
 PBTS / CBTS
Mid-point Tail end  Forwarding Adjacency
 Pseudowire Tunnel select
TE LSP
TE Tunnel Attributes
Head end
 Unidirectional
IP/MPLS  Destination – Tail TE RID
 Priority / Preemption (Setup and
Hold)
 Attributes / Affinity
 Bandwidth / Loadshare
 Local Protection
 Path Options (Explicit / Dynamic)
Mid-point Tail end
TE LSP
Link Information Distribution
IP/MPLS
 Additional link characteristics
 Interface address
 Neighbor address
 Maximum reservable bandwidth
 Unreserved bandwidth
(at eight priorities)
 TE metric (administrative weight)
 Attribute Flags
 IS-IS or OSPF flood link information TE Topology
database
 All TE nodes build a TE topology database (TED)
 Not required if using off-line path computation
Path Calculation
Find shortest
path to R8
 TE nodes can perform constraint-based with 80 Mbps
routing IP/MPLS
R1
 Tunnel head end generally responsible for 150 50 200
100
path calculation R8
100
 Constraints and topology database used as 100
80
input to path computation

100
 Shortest-path-first algorithm ignores links not
meeting constraints TE
Topology
 Tunnel can be signaled once a path is found database
 Not required if using offline path computation

Forwarding Traffic Down Tunnels
Head end
 Traffic enters tunnel at head end
 Multiple traffic selection options
IP/MPLS
 Auto-route (announce / destination)
 Static routes
 Policy Based Routing
 Forward Adjacency
 Pseudowire Tunnel Selection
 Policy / Class Based Tunnel Selection
 PSTS / SPP
 Tunnel path computation independent of
TE LSP routing decision injecting traffic into tunnel
Point-to-Multipoint (P2MP)TE LSP
 Unidirectional
 Explicitly routed IP/MPLS
 One head end, but one or more tail ends

(destinations)
 Same characteristics (constraints,
protection, etc.) for all destinations
TE LSP
P2MP TE LSP Terminology
 Head-end/Source: Node where LSP

Tail end
IP/MPLS
signaling is initiated
Mid-point: Transit node where LSP
Head end

signaling is processed (not a head-
end, not a tail-end)
Mid-point and
Tail-end/Leaf/destination: node
branch point

where LSP signaling ends
IP/MPLS
 Branch point: Node where packet
S2L sub-LSP
replication is performed
S2L sub-LSP
 Source-to-leaf (S2L) sub-LSP: P2MP
TE LSP segment that runs from source
to one leaf
TE LSP
P2MP TE LSP Path Computation
 Constrained Shortest Path First (CSPF)

used to compute an adequate tree IP/MPLS R4
 CSPF executed per destination R2

R1
 TE topology database and tunnel
constraints used as input for path
computation R3 R5
 Path constraints may include loose,
included, excluded hops
TE
 Same constraints for all destinations Topology
(bandwidth, affinities, priorities, etc.) database
 Path computation yields explicit path to

each destination
CSPF
 No changes to OSPF/IS-IS TE extensions
 Static paths possible with offline path Path to R4: (R1, R2, R4)
computation
Path to R5: (R1, R2, R5)
P2MP TE LSP Signaling
 Source sends unique PATH message

IP/MPLS
per destination
PATH
LFIB populated using

PATH

PATH
RSVP labels allocated by RESV
PATH
messages
 Multicast state built by reusing sub-
LSP labels at branch points
IP/MPLS
L=17
L=16 RESV
RESV
L=16
RESV
L=18
Input RESV
Out Label,
Label Interface
16 17, 0
18, 1
MPLS TE Use Cases
Point-to-Point SLA Protection
R1 IP/MPLS R1 IP/MPLS
R8 R8
R2 R2
Bandwidth Optimization
Strategic / Planned Tactical / Reactive
R1 IP/MPLS R1 IP/MPLS
R3
R8
R2
R2
R4
MPLS TE Integration with Network
Services
A TE LSP provides transport for different network services
CE CE
IP/MPLS
PE PE
ATM
CE Ethernet CE
CE
PE
CE CE
PE PE
CE Ethernet Ethernet CE
Low-Latency, BW TE LSP with L2VPN IP (VPN)

Protected TE LSP Reserved BW (Pseudowire) Service
Traffic Protection Using MPLS TE Fast Re-
Route (FRR)
 Sub-second recovery against
node/link failures
IP/MPLS
R1
 Scalable 1:N protection
 Greater protection granularity
R8
 Bandwidth protection
R2
 Topology independent
Primary TE LSP
Backup TE LSP
FRR Link Protection Operation
 Requires pre-signalled next-hop (NHOP) IP/MPLS
backup tunnel R3
25
 Point of Local Repair (PLR) swaps label and 22 22
pushes backup label R1 R2 R6 R7
 Backup terminates
on Merge Point (MP) where traffic re-joins 16 22
primary
 Restoration time expected under ~50 ms R5
LFIB update
Primary TE LSP
Backup TE LSP
FRR Node Protection Operation
IP/MPLS
 Requires pre-signalled next-next-
R3
hop (NNHOP) backup tunnel
25
36 36
 Point of Local Repair (PLR) swaps
R1 R2 R4 R6 R7 next-hop label and pushes
backup label
16 22 36
 Backup terminates on Merge Point
(MP) where traffic re-joins primary
 Restoration time depends on failure
R5
detection time / mechanism
Primary TE LSP
Backup TE LSP
Bidirectional Forwarding Detection
Trigger for FRR
IP/MPLS
R1
 FRR relies on quick PLR failure
detection
 Some failures may not produce loss R8
of signal or alarms on a link

R2
 BFD provides light-weight neighbor
connectivity failure detection
 Much better than RSVP Hellos
BFD session
Primary TE LSP
Backup TE LSP
Bandwidth Protection
 Backup tunnel with associated IP/MPLS

bandwidth capacity (1:N protection) R3
 Backup tunnel may or may not

actually signal bandwidth
R1 R2 R4 R6 R7
 PLR will decide best backup to protect

primary
nhop/nnhop
backup-bw
class-type R5
node-protection flag
Primary TE LSP
Backup TE LSP
AutoTunnel: Primary Tunnels
What’s the Problem?
 FRR can protect TE Traffic IP/MPLS
R1
 Does NOT protect IP or LDP traffic

 How to leverage FRR for all traffic? R8
 What if protection desired without

R2
traffic engineering?
Primary TE LSP
Backup TE LSP
AutoTunnel: Primary Tunnels
What’s the Solution?
 Create protected one-hop tunnels on all TE
links
Forward all traffic through a one-hop
protected primary TE tunnel  Tunnel interfaces not shown on router
configuration
R1
IP/MPLS  Configure desired backup tunnels
(manually or automatically)
R8
R2
Primary TE LSP
AutoTunnel: Backup Tunnels
What’s the Problem?
 MPLS FRR requires backup tunnels to
be preconfigured IP/MPLS
R1
 Automation of backup tunnels is
desirable R8
R2
Primary TE LSP
Backup TE LSP
AutoTunnel: Backup Tunnels
What’s the Solution?
Create backup tunnels automatically
as needed  Detect if a primary tunnel requires
protection and is not protected
IP/MPLS
R1  Verify that a backup tunnel doesn’t already
exist
R8
 Compute a backup path to NHOP and
R2 NNHOP excluding the protected facility
 Optionally, consider shared risk link groups
during backup path computation
 Signal backup tunnels
Primary TE LSP
Backup TE LSP
Shared Risk Link Group (SRLG)
Layer-3 Topology
 Some links may share same physical
IP/MPLS resource (e.g. fiber, conduit)
R2 R4
R1 R5
 AutoTunnel Backup can force or
prefer exclusion of SRLG
R3
to guarantee diversely routed
backup tunnels
Layer-3 Plus underlying Optical Topology
SRLG 10  IS-IS and OSPF flood SRLG

R2-R4 R2-R3
IP/MPLS
SRLG 20
membership as an additional
R2 R4
R1 R5 R4-R2
R4-R3
link attribute
SRLG 30
R3-R2
R3 R3-R4
What About Path Protection?
 Primary and standby share head and

tail, but expected to be diversely
routed IP/MPLS
 Longer restoration times compared to
Link / Node Protection R8
 Doubles number of TE LSPs R1

(1:1 protection)
 Only option for certain topologies
(e.g. Rings)
Primary TE LSP
Backup TE LSP
P2MP TE LSP Traffic Protection
 No new protocol extensions to support FRR

IP/MPLS R4
 Protection requirement applies to all
destinations R2
R1
 P2P LSP as backup tunnel for a sub-LSP
 No changes to label stacking procedure
R3 R5
 Only link protection supported
 Head-end protection requires path
redundancy (live-standby / live-live)
Primary TE LSP
Backup TE LSP
Lab demo
MPLS in ISP
MPLS design in ISP
Large Network, Multi-Area IGP Design with IP/MPLS Access
MPLS design in ISP
Large Network, Inter-AS Design with IP/MPLS Access
MPLS design in ISP
Large Network, Inter-AS Design with IP/MPLS Access
MPLS design in ISP
Small Network, Integrated Core and Aggregation with IP/MPLS Access
MPLS Virtual Private Networks
MPLS Layer-3 Virtual Private Networks
Service (Clients) Management
Layer-3 VPNs Layer-2 VPNs 

Transport
MPLS OAM
 IP/MPLS (LDP/RSVP-TE/BGP/OSPF/IS-IS)
 MPLS Forwarding
#CLUS © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public
What Is a Virtual Private Network?
 Set of sites which communicate with each other in a secure way

 Typically over a shared public or private network infrastructure
 Defined by a set of administrative policies
 Policies established by VPN customers themselves (DIY)
 Policies implemented by VPN service provider (managed/unmanaged)
 Different inter-site connectivity schemes possible
 Full mesh, partial mesh, hub-and-spoke, etc.
 VPN sites may be either within the same or in different organizations
 VPN can be either intranet (same org) or extranet (multiple orgs)
 VPNs may overlap; site may be in more than one VPN
MPLS VPN Example
 VPN policies
 Configured on PE routers (manual operation) PE-CE BGP Route Reflector PE-CE
Link Link
 VPN signaling
PE VPN PE
 Between PEs CE
Signaling
CE
VPN VPN
 Exchange of VPN policies Policy Policy
VPN VPN
 VPN traffic forwarding CE Policy Policy CE
 Additional VPN-related MPLS label encapsulation PE PE
 PE-CE link
 Connects customer network to MPLS network;
either layer-2 or layer-3
MPLS VPN Models
MPLS VPN Models
 MPLS Layer-3 VPNs

MPLS Layer-2 VPNs MPLS Layer-3 VPNs
 Peering relationship between CE
•CE connected to PE via IP-based
and PE Point-to-Point Multi-Point connection (over any layer-2
Layer-2 VPNs Layer-2 VPNs type)
 MPLS Layer-2 VPNs •CE connected •CE connected
– Static routing
to PE via L2 to PE – PE-CE routing protocol; eBGP,
 Interconnect of layer-2 Attachment (Eth, FR, Ethernet OSPF, IS-IS
Circuits (ACs) ATM, etc)

connection
connection •CE routing has peering
•CE-CE L2 (Eth) relationship with PE router; PE
routers are part of customer
 Peering relationship between CE’s •CE-CE L2 p2p
connectivity
mp
connectivity routing
•CE-CE •CE-CE •PE routers maintain customer-
 SP not involved in routing routing; no SP routing; no SP specific routing tables and
involvement involvement exchange customer=specific
routing information
Topics
 Technology components Service (Clients) Management
 VPN control plane mechanisms Layer-3 VPNs Layer-2 VPNs 

 VPN forwarding plane
 Deployment use cases Transport
MPLS OAM
 Business VPN services
 Network segmentation  IP/MPLS (LDP/RSVP-TE/BGP/OSPF/IS-IS)
 Data Center access

 MPLS Forwarding
#CLUS BRKMPL-1100 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 116
MPLS Layer-3 VPN Overview
 VPN policies
 Separation of customer routing via virtual VPN routing table (VRF)
 In PE router, customer interfaces are connected to VRFs
 VPN signaling
 Between PE routers: customer routes exchanged via BGP (MP-BGP)
 VPN traffic forwarding
 Separation of customer VPN traffic via additional VPN label
 VPN label used by receiving PE to identify VPN routing table
 PE-CE link
 Can be any type of layer-2 connection (e.g., FR, Ethernet)
 CE configured to route IP traffic to/from adjacent PE router
 Variety of routing options; static routes, eBGP, OSPF, IS-IS
Virtual Routing and Forwarding Instance
 Virtual routing and forwarding table
 On PE router
 Separate instance of routing (RIB) and CE
VPN 1 VRF
forwarding table Green
PE
 Typically, VRF created for each customer VPN
MPLS Backbone
 Separates customer traffic CE
 VRF associated with one or more customer VPN 2 VRF
interfaces Blue
 VRF has its own routing instance for PE-CE
configured routing protocols
 E.g., eBGP
Virtual Routing and Forwarding Instance - VRF
 Logical routing context within the same PE device
 Unique to a VPN
 Allows for customer overlapping IP addresses
 Deployment use cases
 Business VPN services
 Network segmentation
 Data Center access
VPN Route Distribution
Exchange of VPN Policies Among PE Routers
 Full mesh of BGP sessions among all PE routers
 Or BGP Route Reflector (common)
 Multi-Protocol BGP extensions (MP-iBGP) to carry
VPN policies
BGP Route Reflector
PE-CE PE-CE
 PE-CE routing options Link Link
 Static routes
PE PE
CE CE
 eBGP
 OSPF Blue VRF Blue VRF
Red VRF
 IS-IS CE
Red VRF
CE
 EIGRP
PE PE
VPN Control Plane Processing
 Make customer routes unique:
 Route Distinguisher (RD):
 8-byte field, VRF parameters; unique value to make VPN IP routes unique
 VPNv4 address: RD + VPN IP prefix
 Selective distribute VPN routes:
 Route Target (RT):
 8-byte field, VRF parameter, unique value to define the import/export rules for
VPNv4 routes
 MP-iBGP: advertises VPNv4 prefixes + labels
Why an RD and VPNv4 Address?
VPNv4 iBGP Relationship
Cust A Site 1 10.1.1.0/24

111:1:10.1.1.0/24
10.2.1.0/24
Cust A Site 2
10.1.1.0/24 111:1:10.2.1.0/24 10.2.1.0/24
CE1 CE2
VRF A P1 P2 VRF A
PE1 PE2
Cust B Site 1 VRF B VRF B Cust B Site 2
10.1.1.0/24 P3 P4 10.2.1.0/24
CE1 OSPF Area 0222:1:10.1.1.0/24 CE2
10.1.1.0/24 10.2.1.0/24
222:1:10.2.1.0/24
1. PE routers service multiple customers

BRKMPL-1100 122
2. Once PE redistributes customer routes into MP-BGP, they must be unique
3. RD is prepended to each prefix to make routes unique
VPNv4 prefixes are the combination of a 64-bit RD and a 32-bit IPv4 prefix. VPNv4 prefixes are 96-bits in length
Why are Route Targets Important?
VPNv4 iBGP Relationship
VRF A
VRF B
Cust A Site 1 Import 222:1 Cust A Site 2
Import 333:1 Import 111:1
10.1.1.0/24 Export 222:1 10.1.2.0/24
CE1 Import 444:1 CE1
Export 111:1
VRF A P1 P2 VRF B
PE1 PE2
Cust A Site 3 VRF C VRF D Cust A Site 4
10.1.3.0/24 VRF C P3 P4 10.1.4.0/24
CE1 VRF D
Import 111:1 OSPF Area 0 CE1
Import 111:1
Export 333:1
Export 444:1
1. Route Targets dictate which VRF will receive what routes
BRKMPL-1100 123
2. Can be used to allow specific sites access to centralized services

3. Cust A Site 2, Site 3 and Site 4 will not be able to exchange routes with each other
Route Targets are a 64-bit value and are carried in BGP as an extended community
VPN Control Plane Processing
Interactions Between VRF and BGP VPN Signaling
BGP advertisement:
 CE1 redistribute IPv4 route to PE1 via VPN-IPv4 Addr = 1:100:16.1.0.0
eBGP BGP Next-Hop = PE1
 PE1 allocates VPN label for prefix Route Target = 100:1
Label=42
learnt from CE1 to create unique eBGP: eBGP:
VPNv4 route 16.1.0.0/16 16.1.0.0/16
 PE1 redistributes VPNv4 route into

MP-iBGP, it sets itself as a next hop PE1 Blue VPN PE2
CE1 CE2
and relays VPN site routes to PE2
 PE2 receives VPNv4 route and, via
processing in local VRF (blue), it
redistributes original IPv4 route to ip vrf blue-vpn
CE2 RD 1:100
VRF parameters:
route-target export
Name = blue-vpn
1:100
RD = 1:100
route-target
Import import = 100:1
Route-Target
1:100
Export Route-Target = 100:1
VPN Forwarding Plane Processing
Forwarding of Layer-3 MPLS VPN Packets
 CE2 forwards IPv4 packet to PE2
 PE2 imposes pre-allocated VPN label to IPv4
packet received from CE2
 Learned via MP-IBGP IPv4 IGP
Label C
VPNv4
Label
IPv4 IGP
Label B
VPNv4
Label
IPv4 IGP
Label A
VPNv4
Label
IPv4 IPv4
IPv4
 PE2 imposes outer IGP label A (learned via IPv4
Packet Packet
LDP) and forwards labeled packet to next-hop
PE1 P1 P2 PE2
P-router P2 CE1 CE2
 P-routers P1 and P2 swap outer IGP label and
forward label packet to PE1
 A->B (P2) and B->C (P1)
 Router PE1 strips VPN label and IGP labels and
forwards IPv4 packet to CE1
Service Provider Deployment Scenario
 Deployment Use Case Managed VPN Service
 Delivery of IP VPN services to business Unmanaged VPN Service
customers
Edge Core Core Edge
 Benefits CPE VPN CPE
 Leverage same network for multiple services
and customers (CAPEX)
 Highly scalable
Network Segment CPE Edge Core
 Service enablement only requires edge node
configuration (OPEX) MPLS Node CE PE P
 Different IP connectivity can be easily Typical Platforms ASR1K ASR9K CRS-3

configured; e.g., full/partial mesh
ISR4K ASR90X GSR
ASR90X ASR1K ASR9K
ASR903 NCS5K
ME3800X
Enterprise Deployment Scenario
 Deployment Use Case
MPLS VPNs for L3 Network Segmentation
 Segmentation of enterprise network to provide
selective connectivity for specific user groups
and organizations Edge Core Core Edge
Access VPN Access
 Benefits
 Network segmentation only requires edge node
configuration
 Flexible routing; different IP connectivity can Network Segment Access Edge Core
be easily configured; e.g., full/partial mesh
MPLS Node CE PE P
Typical Platforms CAT2K N7K ASR9K

CAT3K ASR1K CAT6K
ISR4K CAT6K N7K
CAT9k CAT3K NCS5K
CAT9K
Data Center Deployment Scenario
MPLS VPNs terminating on DC aggregation
MPLS VPNs
 Segmented WAN Layer-3 at Data Center edge at DC edge
 Layer-3 segmentation in Data Center
Access
Distribution Core Core Edge
 Benefits Top Of Rack
 Only single Data Center edge node needed for

segmented layer-3 access
Data Centre
 Enables VLAN/Layer-2 scale (> 4K)
Network Segment Distribution Core Edge
MPLS Node CE or PE P or CE PE
Typical Platforms N7K N7K ASR9K

6500 6500 7600
MPLS Layer-2 Virtual Private
Networks
Topics
 L2VPN technology options
 P2P services (VPWS) Service (Clients) Management
 Overview & Technology Basics

 Layer-3 VPNs Layer-2 VPNs 
 VPN control plane
 VPN forwarding plane
Transport
MPLS OAM
 MP2MP services (VPLS / xEVPN)
 Overview & Technology Basics  IP/MPLS (LDP/RSVP-TE/BGP/OSPF/IS-IS)
 VPN control / forwarding plane

 Deployment use cases  MPLS Forwarding
 L2 Business VPN services

 Data Center Interconnect
Technology Options
 VPWS services
MPLS Layer-2 VPNs
 Point-to-point
 Referred to as Pseudowires (PWs)
Point-to-Point Multipoint-to-Multipoint
 VPLS services Layer-2 VPNs (VPWS) Layer-2 VPNs
 Multipoint
 EVPN
EVPN
 Multipoint with BGP-based MAC learning VPLS
 PBB-EVPN
 Combines scale tools from PBB (aka PBB-EVPN
MAC-in-MAC) with BGP-based MAC
learning from EVPN
Virtual Private Wire Services (VPWS)
Overview of Pseudowire (PW) Architecture
 Based on IETF’s Pseudo-Wire (PW) Reference
Attachment Attachment
Model Circuit (AC) Circuit (AC)
Pseudo-Wire 1
 Enables transport of any Layer-2 traffic over MPLS PE1 PE2
CE CE
 PE-CE link is referred to as Attachment Circuit Layer-2 Layer-2
(AC)
CE CE
 Provides a p2p service
Layer-2 Layer-2
Pseudo-Wire 2
 Discovery: manual (config) PE3 PE4
 Signaling: LDP
Emulated Layer-2 Service
 Learning: none
VPWS Control Plane Processing
Signaling of a New Pseudo-Wire
 (1) New Virtual Circuit (VC) cross-connect connects
customer L2 interface (AC) to new PW via VC ID
and remote PE ID
3 Label Mapping Messages
 (2) New targeted LDP session between PE1 and PE2 4 4
2 LDP session
is established, in case one
CE1 PE1 PE2
does not already exist CE2
 (3) PE binds VC label with customer layer-2 1 1
interface and sends label-mapping to remote PE

Emulated Layer-2 Service
 (4) Remote PE receives LDP label binding message
and matches VC ID with local configured VC cross-
connect
VPWS Forwarding Plane Processing
Forwarding of Layer-2 Traffic Over PWs
 CE2 forwards L2 packet to PE2.
 PE2 pushes VC (inner) label to L2 packet

received from CE2 Eth IGP PW Eth IGP PW Eth IGP PW Eth Eth
Label C Label Label B Label Label A Label
 PE2 pushed outer (Tunnel) label and Ethernet Ethernet

Frame
Frame
forwards packet to P2 P1 P2
PE1 PE2
CE1 CE2
 P2 and P1 forward packet using outer
(tunnel) label (swap)
 Router PE1 pops Tunnel label and, based

on VC label, L2 packet is forwarded to
customer interface to CE1, after VC label
is removed
Virtual Private LAN Services
 VPLS network acts like a virtual switch that
emulates conventional L2 bridge Attachment Attachment
Circuit (AC) Circuit (AC)
 Fully meshed or Hub-Spoke topologies supported
 Provides a multipoint ethernet service CE

PE1 PE2
CE
 Discovery: manual or auto (BGP) Eth Eth
 Signaling: LDP or BGP (PW label)

CE CE
 Learning: data plane Eth Eth
PE3 PE4
Emulated Virtual Switch
Pseudo-Wire
EVPN BGP advertisement:
L2VPN/EVPN Addr = CE1.MAC
BGP Next-Hop = PE1
 Ethernet VPN Route Target = 100:1
Label=42
 Provides a multipoint ethernet service
 Discovery: BGP, using MPLS VPN mechanisms

(RT) BGP RR
CE1 PE 1 PE 3 CE3
 Signaling: BGP (MAC prefixes)
 Learning: Control plane (BGP)

CE4
 Allows for multihomed CEs
CE2 PE 2 PE 4
Emulated Virtual Switch
PBB-EVPN BGP advertisement:
L2VPN/EVPN Addr = PE1.B-MAC
BGP Next-Hop = PE1
 Combines Provider Backbone Bridging (MAC-in-MAC)
Route Target = 100:1
with EVPN Label=42
 Scales better than EVPN (CE-CE MAC addresses learned in the data plane)
 Removes the need to advertise Customer MAC addresses in
BGP RR
BGP
CE1 B-MAC PE 1 PE 3 B-MAC CE3
 Provides multipoint ethernet service
 Discovery: BGP, using MPLS VPN mechanisms (RT)

CE2 B-MAC CE4
 Signaling: BGP (B-MAC prefixes)
B-MAC
PE 2 PE 4
 Learning: Control plane (BGP) and forwarding plane
 Allows for multihomed CEs Emulated Virtual Switch
C-MAC = Customer MAC address

B-MAC = Backbone MAC address
MPLS Use Cases
Why Virtualize?
 Logical Segmentation
 Traffic isolation per application, group, service etc…
 Logically separate traffic using one physical infrastructure
Guest Access Merged Company Isolated Services
Virtual Network Virtual Network Virtual Network
Virtual
“Private”
Network
Actual Physical Infrastructure

Enterprise MPLS Deployment Scenario
 Service isolation
 Telephony systems, building control, surveillance
 Security policies are unique to each virtual group/service
 Meet regulatory compliance requirements

Low Medium High
 HIPAA
Security Security Security
 PCI Guest Access Merged Company Isolated Services
 SOX
 etc… Virtual Network Virtual Network Virtual Network
Actual Physical Infrastructure

Service Provider Deployment Scenario
PWs for Offering Layer-2 Business VPN Services
 Delivery of E-LINE services to business

customers
Layer-2 VPN Service
 Benefits
PE P P PE
 Leverage same network for multiple services CE CE
and customers (CAPEX)
 Highly scalable
 Service enablement only requires edge node

configuration (OPEX)
Data Center Deployment Scenario
VPLS for Layer-2 Data Center Interconnect (DCI) Services
 Deployment Use Case Data Center
 E-LAN services for Data Center DC

interconnect Edge
Data Center Core Core

 Benefits Edge
DC Data Center
 Single WAN uplink to connect to multiple Edge Edge
Data Centers DC
Edge
 Easy implementation of segmented
layer-2 traffic between Data Centers Core Core Edge
Lab Demo
Why is MPLS Security Important
 Customer buys “Internet Service”

 Packet from SP are not trusted
 Perception: Need for Firewall, etc.
 Customer buys a “VPN Service”

 Packets from SP are trusted
 Perception: No further Security required
SP Must Ensure Secure MPLS Operations

Security Relies on Three Pillars
Security
Implementation
Architecture
/Algorithm
Operation
Break One, and All Security is Gone
Correct Security Analysis
 Security has to be analyzed on three levels:

 Architecture/Algorithm
 Implementation
 Operation
 Applied to MPLS/VPN:
 The MPLS Architecture is secure (Can be operated securely)
 Implementation/operation issues may exist, like in any other technology
Protection MPLS/VPN Core
 Don’t let packet into the core

 No way to attack core, except through routing, thus
 Secure the routing protocol
 Neighbor authentication, maximum routes, dampening,…
 Design for transit traffic
 QoS to give VPN priority over Internet
 Choose correct router for bandwidth
 Separate PEs where neccesarry
 Operation Securely
Security Threats
 A Successful attack on MPLS Network may cause one or

more of the following ill effects:
 Observation, modification, or deletion of a provider's or user's data.
 Replay of a provider's or user's data.
 Injection of inauthentic data into a provider's or user's traffic stream.
 Traffic pattern analysis on a provider's or user's traffic.
 Disruption of a provider's or user's connectivity.
 Degradation of a provider's service quality.
 Probing a provider's network to determine its configuration, capacity, or usage.
Threats Sources
 Other users whose services are provided by the same MPLS/GMPLS core
 The MPLS/GMPLS SP or persons working for it.
 Other persons who obtain physical access to an MPLS/GMPLS SP’s site
 Other persons who use social engineering methods to influence the behavior
of an SP's personnel.
 Users of the MPLS/GMPLS network itself, e.g., intra-VPN threats.
 Others, e.g., attackers from the Internet at large.
 Other SPs in the case of MPLS/GMPLS inter-provider connection.
 Those who create, deliver, install, and maintain software for network
equipment
Attack on the Control Plane
SP’s
DoS Equipment
LSP attack
Routing
protocol MPLS/VPN
Cross connect of
Traffic between
MPLS
LSP attack
 LSP creation by an Unauthorized Element

 From local CE or router in another domain
 LSP Message Interception
 Monitor traffic to get information
Denial of Service Attacks on the Network
Infrastructure
 Against the mechanism the service provider uses to provide MPLS/VPN
 MPLS, LDP/BGP, RSVP, IPSec …
 Against the general infrastructure of the service provider
 Core Routers
 Deny the other-legitimate activities of another MPLS/VPN user
Attack on the Service Provider equipment via
Management interface
 Reconfigure the equipment
 Extract information (statistics, topology …)
 Malicious entering of the system
 Inadvertently as a consequence of the inadequate inter-
VPN isolation in a MPLS/VPN user self-management
interface
Cross-connection of traffic between
MPLS/VPN
 This included case such as:
 A site being connected into the "wrong" VPN.
 Traffic being replicated and sent to an unauthorized user.
 Two or more VPNs being improperly merged together.
 A point-to-point VPN connecting the wrong two points.
 Any packet or frame being improperly delivered outside the VPN to which
it belongs
 Likelihood of being the result of the service provider or equipment
vendor error
Attacks against MPLS/VPN Routing Protocols
 Routing protocols that are run by the service provider

LDP/BGP
 In layer3 VPNs with dynamic routing this would typically
relate to the distribution of per-VPN routes as well as
backbone routers
 In layer 2 VPNs this would typically relate only to the
distribution of backbone routes
Other attacks on Control traffic
 MPLS signaling (LDP, RSVP-TE)

 PCE signaling
 IPsec signaling (IKE and IKEv2)
 ICMP and ICMPv6
 L2TP
 BGP-based membership discovery
 Database-based membership discovery (e.g., RADIUS)
 Other protocols that may be important to the control infrastructure, e.g.,
DNS, LMP, NTP, SNMP, and GRE.
Attack on the Data Plane
Traffic Pattern
DoS Analysis
Spoofing Impersonation
and Replay MPLS/VPN
Unauthorized
Observation/Modi
fication/Deletion
Insertion of Non-Authentic Data Traffic:
Spoofing and Replay
 Spoofing: insertion into the VPN of packets that do not
belong there
 Replay: copies of once-legitimate packets that have bean
recorded and replayed
Denial of Service Attacks on the MPLS/VPN
 Monopolize network resources and thus prevent other

PPVPNs from accessing those resources
 Inserting an overwhelming quantity of non-authentic data
 Overwhelming the service provider's general (MPLS/VPN-
independent) infrastructure with traffic
 Interfering with its operation
Unauthorized Observation/Modification/Deletion
of Data Traffic
 “Sniffing" VPN packets
 Examining their contents
 Modifying the contents of packets in flight
 Causing packets in flight to be discarded
 Would typically occur
 on links
 in a compromised node
Traffic Pattern Analysis
 “Sniffing" VPN packets and examining aspects or meta-

aspects of them
 Even are encrypted
 Gain useful information
 the amount and timing of traffic
 packet sizes
 source and destination addresses
 etc.
Defensive Techniques
 Cryptographic techniques
 Authentication
 Access Control techniques
 Use of Isolated Infrastructure
 Use of Aggregated Infrastructure
 Service Provider Quality Control Processes
 Deployment of Testable MPLS/VPN Service
Defense Philosophy
 Security threats can be addressed

 Provider's specific service offerings
 MPLS/VPN user should assess the value which these techniques add to the
user's VPN requirements
 Nothing is ever 100% secure - most likely to occur and/or that have the most
dire consequences
 To make the cost of a successful attack greater than what the adversary will
be willing to expend
Cryptographic techniques
 Privacy
 traffic separation
 encryption
 Authentication
 Integrality
 Drawback
 Computational burden
 Complexity of the device configuration
 Incremental labor cost
 Packet lengths are typically increased
 traffic load
 fragmentation
 Other Devices
Authentication
 Prevent
 Denial -of-Service attacks
 Malicious misconfiguration
 Cryptographic techniques
 shared secret keys
 one-time keys generated by accessory devices or software
 user-ID and password pairs
 public-private key systems
 do not protect against some types of denial of service
attacks
Authentication
 VPN Member Authentication

 Management System Authentication
 auto- discovery
 Peer-to-peer Authentication
IPsec in MPLS/VPNs
 PE to PE (can’t be employed )
 PE to CE - weaker links (pass the Internet)
 CE-to-CE (only use tunnel mode)
 Service Level Agreement (SLA) rather than analyzing the specific encryption
techniques
Encryption for device configuration and
management
 Secure Shell (SSH) offers protection for TELNET [STD-8] or terminal-like
connections to allow device configuration
 SNMP v3 [STD62] also provides encrypted and authenticated protection for
SNMP-managed devices
 Transport Layer Security (TLS) (also known as Secure Sockets Layer or SSL)
[RFC-2246]
Security Considerations for MPLS
Pseudowires
 List of PW-specific threats
 Unauthorized setup of a PW (e.g., to gain access to a customer network)
 Unauthorized teardown of a PW (thus causing denial of service)
 Malicious reroute of a PW
 Unauthorized observation of PW packets
 Traffic analysis of PW connectivity
 Unauthorized insertion of PW packets
 Unauthorized modification of PW packets
 Unauthorized deletion of PW packets replay of PW packets
 Denial of service or significant impact on PW service quality
Access Control techniques
 packet-by-packet
 packet-flow-by-packet-flow
 Filtering
 Firewalls
Filtering
 Common for routers

 Filter Characteristics
 Stateless (In most cases )
 Stateful (commonly done in firewalls )
 Actions based on Filter Results
 Discard
 Set CoS
 Count packets and/or bytes
 Rate Limit - MPLS EXP field
 Forward and Copy
Firewalls
 passing between different trusted zones

 SP to SP , PE to CE
 passing between trusted zone and an untrusted zone
 Services
 threshold-driven denial-of-service attack protection
 virus scanning
 acting as a TCP connection proxy
 Advantage
 understanding of the topologies
 understanding of the threat model
Firewalls (conf)
 Within the MPLS/VPN framework, traffic typically is not

allowed to pass between the various user VPNs
 Extranets - provide the services required for secure
extranet implementation
 Protect the user VPNs and core network from the public
Internet
Security Recommendations for ISPs
 Secure devices (PE, P): They are trusted!

 Core (PE+P): Secure with ACLs on all interfaces
 Ideal: deny ip any
 Static PE-CE routing where possible
 If routing: Use authentication (MD5)
 Separation of CE-PE links where possible (Internet / VPN)
 LDP authentication (MD5)
 VRF: Define maximum number of routes
Note: Overall security depends on weakest link!
PE-CE Routing Security
In order of security preference

 1. Static: If no dynamic routing required
(no security implications)
 2. BGP: For redundancy and dynamic updates
(many security features)
 3. IGPs: If BGP not supported
(limited security features)
Securing the MPLS Core
Address Planes: True Separation!
Securing the Core:
Infrastructure ACLs IN MPLS: VRF
belongs to
customer VPN
 On PE: “deny ip any <PE VRF address space>”

 Exception: Routing protocol from host to host
 Idea: No traffic to PE/P Æ you can’t attack
 Prevents intrusions 100%
 DoS: Very hard, but traffic over router theoretically enables DoS.
Securing the Core:
Infrastructure ACLs
 Example This is VPN address

deny ip any 1.1.1.0 0.0.0.255 space, not core
permit ip any any
Caution: This also blocks packets to the CE’s!
Alternatives: List all PE i/f in ACL, or use secondary i/f on CE
Best Practice Security Overview
 Secure devices (PE, P): They are trusted

 PEs: Secure with ACLs on all interfaces
 Static PE-CE routing where possible
 If routing: Use authentication (MD5)
 Maximum number of routes per peer (only BGP)
 Separation of CE-PE links where possible (Internet/VPN)
 LDP authentication (MD5)
 VRF: Define maximum number of routes
Note: Overall security depends on weakest link
MPLS Internet Architectures: Principles
 Core supports VPNs and Internet

 VPNs remain separated
 Internet as an option for a VPN
 Essential: Firewalling
MPLS VPNs Are Quite Secure
 Perfect separation of VPNs

 No intrusions possible
 Perfect separation of the core from VPNs
 Again, no intrusions possible
BUT THERE IS ONE REMAINING ISSUE…

The Key Issue: DoS through a Shared PE
Might Affect VPN Customer
 PE has shared CPU / memory / bandwidth:

 Traffic could affect VPN customer
 (However, risk probably acceptable)
Best Practice:
MPLS VPN Security Recommendation
 PE routers should contain

only VRFs of the same
security level. Example:
 Level 0: Internet
 Level 1: VPN customers
 (Level 2: Mission critical
infrastructure)
Separate VPN and Internet Access
 Separation: +++
 DoS resistance: +++
 Cost: $$$ (Two lines and two PEs: Expensive!)
Separate Access Lines + CEs, one PE
 Separation: +++
 DoS resistance: ++(DoS might impact VPN on PE)
 Cost: $$$ (Two lines, but only one PE !)
Using a Single Access Line
Requirements to share a line:

 PE requires separate sub-interfaces
 CE requires separate sub-interfaces
 CE side requires separate routing
Hub-and-Spoke VPN with Internet Access
Alternative Topologies
 Full VPN mesh, one Internet Access

 Internet access at several sites
 Several firewalls needed
 More complex
 Internet Access from all sites
 Complex, one firewall per site
Data Plane Protection
 A backbone router does not accept labeled packets over a particular data
link, unless it is known that that data link attaches only to trusted systems,
or unless it is known that such packets will leave the backbone before the IP
header or any labels lower in the stack will be inspected, and …
 Inter-AS should only be provisioned over
secure, private peerings
 Specifically NOT: Internet Exchange Points
(anyone could send labelled packets!! No
filtering possible!!)
Control Plane Protection
 labeled VPN-IPv4 routes are not accepted from untrusted or

unreliable routing peers,
 Accept routes with labels only from trusted peers
 Plus usual BGP filtering
Inter-AS:
VRF-VRF back-to-back
 Control plane: No signalling, no labels

 Data plane: IPv4 only, no labels accepted
 Security: as in 2547
 Customer must trust both SPs
Inter-AS:
VRF-VRF back-to-back
 Static mapping
 SP1 does not “see” SP2’s network
 And does not run routing with SP2, except within the VPNs.
 Quite secure
 Potential issues:
 SP 1 can connect VPN connection wrongly
Inter-AS:
ASBR exchange labelled VPNv4 routes
 Control plane: MP-BGP, labels

 Data plane: Packets with one label
 AS1 can insert traffic into any shared VPN of AS2
Inter-AS:
ASBR exchange labelled VPNv4 routes
 ASBR1 does signalling with ASBR2
 MP-BGP: has to be secured, dampening etc
 Otherwise no visibility of the other AS (ASBR1 – ASBR2 is the only interface
between the SPs.)
 Potential Issues:
 SP1 can bring wrong CEs into any shared VPN
 SP1 can send packets into any shared VPN (not into VPNs that are not shared,
since label is checked);
 SP can make any shared VPN insecure
Inter-AS:
ASBRs exchange PE loopbacks
 Control plane: ASBR: just PE loopback + labels;

 PE/RR: VPNv4 routes + labels
 Data plane: PE label + VPN label
 AS1 can insert traffic into VPNs in AS2
Inter-AS:
ASBRs exchange PE loopbacks
 ASBR-ASBR signalling (BGP)
 RR-RR signalling (MP-BGP)
 Much more “open”
 LSPs between PEs, BGP between RR, ASBR
 Potential Issues:
 SP1 can bring a CE into any VPN on “shared” Pes
 SP1 can intrude into any VPN on “shared” Pes
 Very open architecture
 probably only applicable for ASes controlled by the same SP.
Inter-AS Summary and Recommendation
 Three different models for Inter-AS

 Different security properties
 Most secure: Static VRF connections, but least scalable
 Basically the SPs have to trust each other
 Hard / impossible to secure against other SP in this model
 Okay if all ASes in control of one SP
 Current Recommendation: Use First Case
Secure Operations
Key: PE Security
 What happens if a single PE in the core gets compromised?

 Intruder has access to all VPNs; GRE tunnel to “his” CE in the Internet, bring
that CE into any VPN.
 That VPN might not even notice…
 Worst Case!
 Therefore: PE SECURITY IS PARAMOUNT!
 Therefore: No PE on customer premises!
 (Think about console access, password recovery…)
Solution: Operational Security
 Security depends on SP
 Employee can make mistake, or malicious misconfiguration
 Potential Security hole:
 If PE compromised, VPNs might be insecure
 Cannot *prevent* all misconfigs
 Need to operationally control this
Operational Security
 Logging config changes

 Dual Control: Network operators must have no access to logging
facility
 Otherwise they can hack the network, and delete the logs
 AAA for access
 AAA for command authorization
 Keep logs in a secure place
 (Malicious employee might change logs too)
 Tight control
 No service password-recovery where available
IPSEC and MPLS
 Use IPsec if you need:

 Encryption of traffic
 Direct authentication of Ces
 Integrity of traffic
 Replay detection
 Or: If you don’t want to trust your ISP for traffic

separation!
Where to Apply IPSec
Applications of PE-PE IPSec
 If core is not pure MPLS, but IP based

 PE-PE IPSec does not
 Alternative: MPLS in IP/GRE/L2TPv3, but with PE-PE IPSec spoofing impossible
 Protect against misbehaving transit nodes
 Protection against sniffing on core lines
Non-Application: Customer Security

MPLS Security PDF

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

MPLS Security PDF

Diunggah oleh

Hak Cipta:

Format Tersedia

MPLS Security

Multi-Protocol: The ability to carry any

Have: IPv4, IPv6, Ethernet, ATM, FR

Uses Labels to tell a node what to do

 Evolved from tag switching in 1996 to full IETF standard

 MPLS reference architecture

▪ P (Provider) router = Label Switching Router (LSR)

 MPLS Label has local significance

 Labels used for making forwarding

 MPLS label has 3 Traffic Class (TC) bits

 At ingress PE router Layer-2 Header MPLS Header Layer 3 Header

 Most providers have defined 3–5 service

 The LSR forwards labeled packets in the MPLS domain.

MPLS router functionality is divided into two major parts:

 Are 4 byte identifiers used for forwarding decisions

 An FEC is a group of packets forwarded:

 MPLStechnology is intended to be used anywhere

 Usually only one label is assigned to a packet, but

 LDP establishes a session in two steps:

 Hello messages are sent to all routers reachable through an interface.

 LSRs establish one LDP session per label space.

 LDP neighbor discovery of nonadjacent neighbors

 MPLS introduces a label field that is used for forwarding decisions.

 An LSP is a sequence of LSRs that forwards labeled packets of a certain

 Penultimate hop popping optimizes MPLS performance

 MPLSconvergence in frame-mode MPLS does not affect

 Traffic engineering is manipulating your traffic to fit

 Reduce the overall cost of operations by more

 Routersforward traffic along the least-cost route

 Lack of resources results in congestion in two ways:

 Someresources are overutilized while others remain

 The focus of TE is not on congestion created as a

 IGP routing scalability issue for meshes

 The current forwarding paradigm, centered around

Mid-point Tail end

input to path computation

 Not required if using offline path computation

 One head end, but one or more tail ends

 Head-end/Source: Node where LSP

 Constrained Shortest Path First (CSPF)

 CSPF executed per destination R2

 Path computation yields explicit path to

 Source sends unique PATH message

LFIB populated using

Point-to-Point SLA Protection

Low-Latency, BW TE LSP with L2VPN IP (VPN)

 Requires pre-signalled next-hop (NHOP) IP/MPLS

 Point of Local Repair (PLR) swaps label and 22 22

pushes backup label R1 R2 R6 R7

of signal or alarms on a link

 Backup tunnel with associated IP/MPLS

 Backup tunnel may or may not

 PLR will decide best backup to protect

 Does NOT protect IP or LDP traffic

 What if protection desired without

SRLG 10  IS-IS and OSPF flood SRLG

 Primary and standby share head and

 Doubles number of TE LSPs R1

 No new protocol extensions to support FRR

Service (Clients) Management

Layer-3 VPNs Layer-2 VPNs 

 Set of sites which communicate with each other in a secure way

 Additional VPN-related MPLS label encapsulation PE PE