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

Multi-Protocol: The ability to carry any payload Have: IPv4, IPv6, Ethernet, ATM, FR

Label

Uses Labels to tell a node what to do with a packet; separates forwarding (hop by hop behavior) from routing (control plane)

Switching

Routing based on IPv4 or IPv6 lookup. Everything else is Switching.

Evolution of MPLS 

Evolved from tag switching in 1996 to full IETF standard covering over 130 RFCs



Key application initially were Layer-3 VPNs, followed by for SDN and Cloud Traffic Engineering (TE) and Layer-2 VPNs Optimize MPLS for

Optimize MPLS

packet transport (Planned) First SDN/PCE Deployments

Optimize MPLS for video

Complete base MPLS portfolio

First G-MPLS Deployment

Bring MPLS to Market First L3VPNs Deployed

Cisco ships MPLS

1997 1998

Large Scale L3VPN Deployments

First MPLS TE Deployments

1999

2000

2001

2002

(Planned) First Segment Routing Deployments

Large Scale L2VPN Deployments

First L2VPN Deployments

2003 2004

2005

Large Scale MPLS TE Deployments

First LSM Deployments

2006

2009

2007 2008

(Planned) First PBBEVPN Deployments

First MPLS TP Deployments

2010 2011

2012

2013

2014

2015

MPLS Technology Basics

Basics of MPLS Signaling and Forwarding 

MPLS reference architecture



MPLS Labels



MPLS signaling and forwarding operations MPLS Traffic Engineering



MPLS OAM

Layer-3 VPNs

Layer-2 VPNs

Transport IP/MPLS (LDP/RSVP-TE/BGP/OSPF/IS-IS)

MPLS Forwarding

MPLS OAM



Management

Service (Clients)

MPLS Reference Architecture PE

▪

▪

▪

PE

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 –

▪

P

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

▪

P

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 decision

Multiple labels can be used for MPLS packet encapsulation 





forwarding

MPLS Label Stack Entry Label = 20 bits

TC

S

TTL

TC = Traffic Class: 3 Bits; S = Bottom of Stack; TTL = Time to Live

No limit on the number of labels in a stack

Outer label always used for switching MPLS packets in network

LAN MAC Header

Label, S=1

Layer 3 Packet

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

MPLS Label Stack (2 labels)

Layer 3 Packet

MPLS QoS 

MPLS label has 3 Traffic Class (TC) bits



Used for packet classification and prioritization 



DSCP values of IP packet mapped into TC bits of MPLS label 



Similar to Type of Service (ToS) field in IP packet (DSCP values)

At ingress PE router

Most providers have defined 3–5 service classes (TC values)

MPLS DiffServ Marking in Traffic Class Bits TC

Layer-2 Header

MPLS Header

IP DiffServ Marking

DSCP

Layer 3 Header

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  Have

a forwarding equivalence class (FEC)

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  MPLS

technology 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  The

MPLS is MPLS over ATM.

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-platform

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

MPLS Unicast IP Routing Architecture

MPLS Unicast IP Routing Architecture

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.

Label Allocation in a Frame-Mode MPLS Network: Building the IP Forwarding Table

Label Allocation in a Frame-Mode MPLS Network: Allocating Labels

Label Allocation in a Frame-Mode MPLS Network: LIB and LFIB Setup

Label Allocation in a Frame-Mode MPLS Network: Labels and Table Setup

Label Distribution and Advertisement

Label Distribution and Advertisement: Receiving Label Advertisement

Label Distribution and Advertisement: Interim Packet Propagation

Label Distribution and Advertisement: Further Label Allocation

Label Distribution and Advertisement: 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  MPLS

convergence 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  Routers

forward 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

 Some

resources 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

Traffic Engineering with a Layer 2 Overlay Model: Example

Traffic Engineering with a Layer 2 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  No

bandwidth overhead (“cell tax”)

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:  Path

computation 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  Head end

IP/MPLS

Mid-point TE LSP

Tail end

Link information Distribution* 

ISIS-TE



OSPF-TE



Path Calculation (CSPF)*



Path Setup (RSVP-TE)



Forwarding Traffic down Tunnel* 

Auto-route (announce / destinations)



Static route



PBR



PBTS / CBTS



Forwarding Adjacency



Pseudowire Tunnel select

TE Tunnel Attributes Head end

IP/MPLS

Mid-point TE LSP

Tail end



Unidirectional



Destination – Tail TE RID



Priority / Preemption (Setup and Hold)



Attributes / Affinity



Bandwidth / Loadshare



Local Protection



Path Options (Explicit / Dynamic)

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



All TE nodes build a TE topology database (TED)



Not required if using off-line path computation

TE Topology database

Path Calculation 







TE nodes can perform constraint-based routing

Find shortest path to R8 with 80 Mbps

IP/MPLS R1

Tunnel head end generally responsible for path calculation Constraints and topology database used as input to path computation Shortest-path-first algorithm ignores links not meeting constraints



Tunnel can be signaled once a path is found



Not required if using offline path computation

150

200

50

100

100

R8

80

100 100

TE Topology database

Forwarding Traffic Down Tunnels Head end

IP/MPLS



Traffic enters tunnel at head end



Multiple traffic selection options

 TE LSP



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 routing decision injecting traffic into tunnel

Point-to-Multipoint (P2MP)TE LSP 

Unidirectional



Explicitly routed



One head end, but one or more tail ends (destinations)



Same characteristics (constraints, protection, etc.) for all destinations

IP/MPLS

TE LSP

P2MP TE LSP Terminology

Tail end



Head-end/Source: Node where LSP signaling is initiated



Mid-point: Transit node where LSP signaling is processed (not a headend, not a tail-end)



Tail-end/Leaf/destination: node where LSP signaling ends



Branch point: Node where packet replication is performed



Source-to-leaf (S2L) sub-LSP: P2MP TE LSP segment that runs from source to one leaf

IP/MPLS Head end

Mid-point and branch point

IP/MPLS S2L sub-LSP

S2L sub-LSP

TE LSP

P2MP TE LSP Path Computation   

    

Constrained Shortest Path First (CSPF) used to compute an adequate tree CSPF executed per destination TE topology database and tunnel constraints used as input for path computation Path constraints may include loose, included, excluded hops Same constraints for all destinations (bandwidth, affinities, priorities, etc.) Path computation yields explicit path to each destination No changes to OSPF/IS-IS TE extensions Static paths possible with offline path computation

IP/MPLS

R4

R2 R1

R3

R5

TE Topology database

CSPF

Path to R4: (R1, R2, R4) Path to R5: (R1, R2, R5)

P2MP TE LSP Signaling 

Source sends unique PATH message per destination



LFIB populated using RSVP labels allocated by RESV messages



Multicast state built by reusing subLSP labels at branch points

IP/MPLS PATH PATH

PATH PATH

IP/MPLS L=17 L=16

RESV

RESV

L=16 RESV

L=18 Input Label

Out Label, Interface

16

17, 0 18, 1

RESV

MPLS TE Use Cases Protection

Point-to-Point SLA R1

R1

IP/MPLS

IP/MPLS R8

R8 R2

R2

Strategic / Planned R1

Bandwidth Optimization

Tactical / Reactive R1

IP/MPLS R3

R2

R8 R2

R4

IP/MPLS

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

CE PE

PE

Ethernet

Low-Latency, BW Protected TE LSP

Ethernet CE

TE LSP with Reserved BW

L2VPN (Pseudowire)

IP (VPN) Service

Traffic Protection Using MPLS TE Fast ReRoute (FRR) R1



Sub-second recovery against node/link failures



Scalable 1:N protection



Greater protection granularity



Bandwidth protection



Topology independent

IP/MPLS

R8 R2

Primary TE LSP Backup TE LSP

FRR Link Protection Operation 

Requires pre-signalled next-hop (NHOP) backup tunnel

IP/MPLS R3 25







Point of Local Repair (PLR) swaps label and pushes backup label Backup terminates on Merge Point (MP) where traffic re-joins primary Restoration time expected under ~50 ms LFIB update

22

22

R1

R2

R6

16

22

R5

Primary TE LSP Backup TE LSP

R7

FRR Node Protection Operation IP/MPLS



Requires pre-signalled next-nexthop (NNHOP) backup tunnel



Point of Local Repair (PLR) swaps next-hop label and pushes backup label



Backup terminates on Merge Point (MP) where traffic re-joins primary



Restoration time depends on failure detection time / mechanism

R3 25 36

36

R1

R2

16

R4

22

R6

36

R5

Primary TE LSP Backup TE LSP

R7

Bidirectional Forwarding Detection Trigger for FRR 

FRR relies on quick PLR failure detection



Some failures may not produce loss of signal or alarms on a link



BFD provides light-weight neighbor connectivity failure detection



Much better than RSVP Hellos

R1

IP/MPLS

R8

R2

BFD session Primary TE LSP Backup TE LSP

Bandwidth Protection 





Backup tunnel with associated bandwidth capacity (1:N protection) Backup tunnel may or may not actually signal bandwidth

IP/MPLS R3

R1

R2

R4

PLR will decide best backup to protect primary nhop/nnhop backup-bw class-type

R5

node-protection flag Primary TE LSP Backup TE LSP

R6

R7

AutoTunnel: Primary Tunnels What’s the Problem? 

FRR can protect TE Traffic



Does NOT protect IP or LDP traffic



How to leverage FRR for all traffic?



What if protection desired without traffic engineering?

R1

IP/MPLS

R8 R2

Primary TE LSP Backup TE LSP

AutoTunnel: Primary Tunnels What’s the Solution? 

Forward all traffic through a one-hop protected primary TE tunnel

Create protected one-hop tunnels on all TE links



Tunnel interfaces not shown on router configuration

IP/MPLS



Configure desired backup tunnels (manually or automatically)

R1

R8 R2

Primary TE LSP

AutoTunnel: Backup Tunnels What’s the Problem? 



MPLS FRR requires backup tunnels to be preconfigured

R1

IP/MPLS

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 R1

IP/MPLS R8



Detect if a primary tunnel requires protection and is not protected



Verify that a backup tunnel doesn’t already exist



Compute a backup path to NHOP and NNHOP excluding the protected facility



Optionally, consider shared risk link groups during backup path computation



Signal backup tunnels

R2

Primary TE LSP Backup TE LSP

Shared Risk Link Group (SRLG) Layer-3 Topology



Some links may share same physical resource (e.g. fiber, conduit)



AutoTunnel Backup can force or prefer exclusion of SRLG to guarantee diversely routed backup tunnels



IS-IS and OSPF flood SRLG membership as an additional link attribute

IP/MPLS R2

R4

R1

R5

R3

Layer-3 Plus underlying Optical Topology SRLG 10 R2-R4 R2-R3

IP/MPLS R2

R4

R1

R5

R3

SRLG 20 R4-R2 R4-R3 SRLG 30 R3-R2 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



Doubles number of TE LSPs (1:1 protection)



Only option for certain topologies (e.g. Rings)

R8

R1

Primary TE LSP Backup TE LSP

P2MP TE LSP Traffic Protection 

No new protocol extensions to support FRR



Protection requirement applies to all destinations



P2P LSP as backup tunnel for a sub-LSP



No changes to label stacking procedure



Only link protection supported



Head-end protection requires path redundancy (live-standby / live-live)

IP/MPLS

R4

R2 R1

R3

Primary TE LSP Backup TE LSP

R5

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 Management

Service (Clients) Layer-3 VPNs

Layer-2 VPNs



IP/MPLS (LDP/RSVP-TE/BGP/OSPF/IS-IS)



MPLS Forwarding

#CLUS

MPLS OAM

Transport



© 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 





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 



Typically over a shared public or private network infrastructure

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 







Between PEs



Exchange of VPN policies

VPN traffic forwarding Additional VPN-related MPLS label encapsulation

PE-CE link 

Connects customer network to MPLS network; either layer-2 or layer-3

BGP Route Reflector

PE-CE Link

VPN signaling

 

Configured on PE routers (manual operation)

PE

CE

VPN Signaling

PE-CE Link

PE

VPN Policy

CE VPN Policy VPN Policy

VPN

CE Policy PE

PE

CE

MPLS VPN Models MPLS VPN Models



MPLS Layer-3 VPNs 



Peering relationship between CE and PE

MPLS Layer-2 VPNs 

Interconnect of layer-2 Attachment Circuits (ACs)

MPLS Layer-2 VPNs Point-to-Point Layer-2 VPNs

Multi-Point Layer-2 VPNs

•CE connected to PE via L2 (Eth, FR, ATM, etc) connection

•CE connected to PE Ethernet connection



Peering relationship between CE’s

•CE-CE L2 p2p connectivity

•CE-CE L2 (Eth) mp connectivity



SP not involved in routing

•CE-CE routing; no SP involvement

•CE-CE routing; no SP involvement

MPLS Layer-3 VPNs •CE connected to PE via IP-based connection (over any layer-2 type)

– Static routing – PE-CE routing protocol; eBGP, OSPF, IS-IS •CE routing has peering relationship with PE router; PE routers are part of customer routing

•PE routers maintain customerspecific routing tables and exchange customer=specific routing information

MPLS Layer-3 Virtual Private Networks Topics  Technology

components

 VPN

control plane mechanisms

 VPN

forwarding plane use cases

 Business

VPN services

 Network

segmentation

 Data

Center access

Layer-3 VPNs

Layer-2 VPNs

Transport



IP/MPLS (LDP/RSVP-TE/BGP/OSPF/IS-IS)



MPLS Forwarding

#CLUS

BRKMPL-1100

 MPLS OAM

 Deployment

Management

Service (Clients)

© 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

#CLUS

© 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public

Virtual Routing and Forwarding Instance 



Virtual routing and forwarding table 

On PE router



Separate instance of routing (RIB) and forwarding table

CE VPN 1

VRF Green

Typically, VRF created for each customer VPN 



VRF associated with one or more customer interfaces



VRF has its own routing instance for PE-CE configured routing protocols 

MPLS Backbone

CE

Separates customer traffic VPN 2

PE

VRF Blue

E.g., eBGP

#CLUS

© 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public

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

#CLUS

© 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public

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 PE-CE routing options 

Static routes



eBGP



OSPF



IS-IS



EIGRP

BGP Route Reflector

PE-CE Link

PE

PE

CE

PE-CE Link

Blue VRF

CE

CE Blue VRF Red VRF

Red VRF

CE PE

PE

#CLUS

© 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public

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

#CLUS

© 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public

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.1.1.0/24 111:1:10.2.1.0/24

CE2

CE1

VRF A VRF B

Cust B Site 1 10.1.1.0/24

Cust A Site 2

10.2.1.0/24

P1

PE2

P3 CE1

VRF A

P2

PE1

Cust B Site 2

VRF B

P4

OSPF Area 0222:1:10.1.1.0/24

10.1.1.0/24

10.2.1.0/24

CE2

10.2.1.0/24

10.2.1.0/24

222:1:10.2.1.0/24

1.

PE routers service multiple customers

2.

Once PE redistributes customer routes into MP-BGP, they must be unique

3.

RD is prepended to each prefix to make routes unique

BRKMPL-1100

122

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? VRF A

Cust A Site 1 10.1.1.0/24

CE1

VRF A VRF C

Cust A Site 3 10.1.3.0/24

CE1

VPNv4 iBGP Relationship

Import 222:1

VRF B

Import 333:1

Import 111:1

Import 444:1

Export 222:1

Export 111:1

P1

PE2

Import 111:1

P3

P4

OSPF Area 0

Export 333:1

1.

CE1

10.1.2.0/24

VRF B

P2

PE1 VRF C

Cust A Site 2

VRF D Import 111:1

Export 444: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

Cust A Site 4

VRF D CE1

10.1.4.0/24

VPN Control Plane Processing Interactions Between VRF and BGP VPN Signaling 

CE1 redistribute IPv4 route to PE1 via eBGP



PE1 allocates VPN label for prefix learnt from CE1 to create unique VPNv4 route





PE1 redistributes VPNv4 route into MP-iBGP, it sets itself as a next hop and relays VPN site routes to PE2

eBGP: 16.1.0.0/16

CE1

PE1

PE2 receives VPNv4 route and, via processing in local VRF (blue), it redistributes original IPv4 route to CE2

BGP advertisement: VPN-IPv4 Addr = 1:100:16.1.0.0 BGP Next-Hop = PE1 Route Target = 100:1 Label=42

PE2

Blue VPN

eBGP: 16.1.0.0/16 CE2

ip vrf blue-vpn RD 1:100 VRF parameters: route-target export Name = blue-vpn 1:100 RD = 1:100 route-target import = 100:1 Import Route-Target 1:100 Export Route-Target = 100:1

#CLUS

© 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public

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 





IPv4

IGP Label C

IPv4 PE2 imposes outer IGP label A (learned via Packet LDP) and forwards labeled packet to next-hop PE1 P-router P2 CE1

VPNv4 Label

IGP Label B

IPv4

VPNv4 Label

IGP Label A

IPv4

VPNv4 Label

IPv4

IPv4

IPv4 Packet

P1

P2

PE2

P-routers P1 and P2 swap outer IGP label and forward label packet to PE1 



Learned via MP-IBGP

A->B (P2) and B->C (P1)

Router PE1 strips VPN label and IGP labels and forwards IPv4 packet to CE1

#CLUS

© 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public

CE2

Service Provider Deployment Scenario 

Deployment Use Case 





Delivery of IP VPN services to business customers

Benefits 

Managed VPN Service Unmanaged VPN Service

CPE

Edge

Core

VPN

Core

Edge

CPE

Leverage same network for multiple services and customers (CAPEX)

Highly scalable 

Service enablement only requires edge node configuration (OPEX)



Different IP connectivity can be easily configured; e.g., full/partial mesh

Network Segment MPLS Node Typical Platforms

CPE

Edge

Core

CE

PE

P

ASR1K

ASR9K

CRS-3

ISR4K

ASR90X

GSR

ASR90X

ASR1K

ASR9K

ASR903

NCS5K

ME3800X

#CLUS

© 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public

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

Benefits 

Network segmentation only requires edge node configuration



Flexible routing; different IP connectivity can be easily configured; e.g., full/partial mesh

Access

Edge

Network Segment MPLS Node Typical Platforms

Core

VPN

Core

Edge

Access

Access

Edge

Core

CE

PE

P

CAT2K

N7K

ASR9K

CAT3K

ASR1K

CAT6K

ISR4K

CAT6K

N7K

CAT9k

CAT3K

NCS5K

CAT9K

#CLUS

© 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public

Data Center Deployment Scenario MPLS VPNs terminating on DC aggregation





Deployment Use Case 

Segmented WAN Layer-3 at Data Center edge



Layer-3 segmentation in Data Center

Benefits 

Only single Data Center edge node needed for segmented layer-3 access



Enables VLAN/Layer-2 scale (> 4K)

MPLS VPNs at DC edge

Access Top Of Rack

Distribution

Core

Core

Edge

Data Centre Network Segment MPLS Node Typical Platforms

#CLUS

Distribution

Core

Edge

CE or PE

P or CE

PE

N7K

N7K

ASR9K

6500

6500

7600

© 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public

MPLS Layer-2 Virtual Private Networks

MPLS Layer-2 Virtual Private Networks Topics 

L2VPN technology options



P2P services (VPWS)



Overview & Technology Basics



VPN control plane



VPN forwarding plane

 Layer-3 VPNs

Layer-2 VPNs



Transport

MP2MP services (VPLS / xEVPN) 

Overview & Technology Basics



VPN control / forwarding plane

Deployment use cases 

L2 Business VPN services



Data Center Interconnect



IP/MPLS (LDP/RSVP-TE/BGP/OSPF/IS-IS)



MPLS Forwarding

#CLUS

© 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public

MPLS OAM





Management

Service (Clients)

MPLS Layer-2 Virtual Private Networks Technology Options 



VPWS services 

Point-to-point



Referred to as Pseudowires (PWs)

VPLS services 



Point-to-Point Layer-2 VPNs (VPWS)

Multipoint-to-Multipoint Layer-2 VPNs

Multipoint

EVPN 



MPLS Layer-2 VPNs

Multipoint with BGP-based MAC learning

VPLS

EVPN

PBB-EVPN 

Combines scale tools from PBB (aka MAC-in-MAC) with BGP-based MAC learning from EVPN

PBB-EVPN

#CLUS

© 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public

Virtual Private Wire Services (VPWS) Overview of Pseudowire (PW) Architecture 

Based on IETF’s Pseudo-Wire (PW) Reference Model

Attachment Circuit (AC)

Attachment Circuit (AC)

Pseudo-Wire 1



Enables transport of any Layer-2 traffic over MPLS



PE-CE link is referred to as Attachment Circuit (AC)



Provides a p2p service



Discovery: manual (config)



Signaling: LDP



Learning: none

PE2

PE1

CE Layer-2

CE Layer-2

CE

CE Layer-2

PE3

Pseudo-Wire 2

Layer-2

PE4

Emulated Layer-2 Service

#CLUS

© 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public

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

(2) New targeted LDP session between PE1 and PE2 is established, in case one does not already exist (3) PE binds VC label with customer layer-2

3 4 CE1

2

Label Mapping Messages

4 LDP session

PE1

PE2

1

1

interface and sends label-mapping to remote PE 

(4) Remote PE receives LDP label binding message and matches VC ID with local configured VC crossconnect

#CLUS

Emulated Layer-2 Service

© 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public

CE2

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



PE2 pushed outer (Tunnel) label and forwards packet to P2



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

Eth

IGP Label C

PW Label

IGP Label B

Eth

PW Label

IGP Label A

Eth

Eth

Eth

Ethernet Frame

Ethernet Frame

PE1

CE1

PW Label

P1

P2

PE2

is removed

#CLUS

© 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public

CE2

Virtual Private LAN Services 

VPLS network acts like a virtual switch that emulates conventional L2 bridge



Fully meshed or Hub-Spoke topologies supported



Provides a multipoint ethernet service



Discovery: manual or auto (BGP)



Signaling: LDP or BGP (PW label)



Learning: data plane

Attachment Circuit (AC)

Attachment Circuit (AC)

PE2

PE1

CE Eth

CE Eth

CE

CE Eth

Eth

PE4

PE3

Emulated Virtual Switch

Pseudo-Wire #CLUS

© 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public

EVPN 

Ethernet VPN



Provides a multipoint ethernet service



Discovery: BGP, using MPLS VPN mechanisms (RT)



Signaling: BGP (MAC prefixes)



Learning: Control plane (BGP)



BGP advertisement: L2VPN/EVPN Addr = CE1.MAC BGP Next-Hop = PE1 Route Target = 100:1 Label=42

BGP RR CE1

PE 3

PE 1

CE3

CE4

Allows for multihomed CEs CE2

PE 4

PE 2

Emulated Virtual Switch

#CLUS

© 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public

PBB-EVPN 

BGP advertisement: L2VPN/EVPN Addr = PE1.B-MAC BGP Next-Hop = PE1 Route Target = 100:1 Label=42

Combines Provider Backbone Bridging (MAC-in-MAC) with EVPN 

Scales better than EVPN



Removes the need to advertise Customer MAC addresses in

(CE-CE MAC addresses learned in the data plane)

BGP

BGP RR PE 3 B-MAC CE3

CE1 B-MAC PE 1



Provides multipoint ethernet service



Discovery: BGP, using MPLS VPN mechanisms (RT)



Signaling: BGP (B-MAC prefixes)



Learning: Control plane (BGP) and forwarding plane



Allows for multihomed CEs

CE2

B-MAC B-MAC

PE 4

PE 2

Emulated Virtual Switch

C-MAC = Customer MAC address B-MAC = Backbone MAC address #CLUS

© 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public

CE4

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 #CLUS

© 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public

Enterprise MPLS Deployment Scenario 

Service isolation



Telephony systems, building control, surveillance



Security policies are unique to each virtual group/service



Meet regulatory compliance requirements



HIPAA



PCI



SOX



etc…

Low Security

Medium Security

High Security

Guest Access

Merged Company

Isolated Services

Virtual Network

Virtual Network

Virtual Network

Actual Physical Infrastructure #CLUS

BRKMPL-1100

© 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public

140

Service Provider Deployment Scenario PWs for Offering Layer-2 Business VPN Services 

Deployment Use Case 

Delivery of E-LINE services to business customers Layer-2 VPN Service



Benefits 

Leverage same network for multiple services and customers (CAPEX)

 

CE

PE

P

P

PE

CE

Highly scalable

Service enablement only requires edge node configuration (OPEX)

#CLUS

BRKMPL-1100

© 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public

141

Data Center Deployment Scenario VPLS for Layer-2 Data Center Interconnect (DCI) Services 

Deployment Use Case 



E-LAN services for Data Center interconnect

Benefits 



Data Center

Single WAN uplink to connect to multiple Data Centers

DC Edge

Data Center DC Edge

Core

Core

Edge Data Center

Edge

DC Edge

Easy implementation of segmented layer-2 traffic between Data Centers

Core

#CLUS

BRKMPL-1100

Core

Edge

© 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public

142

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

Operation

Implementation

Architecture /Algorithm

Security

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 



Secure the routing protocol 





No way to attack core, except through routing, thus

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 Equipment

DoS

Routing protocol

Cross connect of Traffic between MPLS

LSP attack MPLS/VPN

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 



Against the general infrastructure of the service provider 



MPLS, LDP/BGP, RSVP, IPSec …

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 interVPN 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 Analysis

DoS

Spoofing and Replay

Unauthorized Observation/Modi fication/Deletion

MPLS/VPN

Impersonation

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/VPNindependent) 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 metaaspects 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 ” 

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 deny ip any 1.1.1.0 0.0.0.255 permit ip any any

This is VPN address space, not core

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



Customer must trust both SPs

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



Customer must trust both SPs

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 



Potential Security hole: 



Employee can make mistake, or malicious misconfiguration

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