1 MPLS VPN Security assessment C. Anselme-Moizan [email protected]

1

MPLS VPNSecurity assessment

C. Anselme-Moizan

[email protected]

MPLS VPN security assessment2

Agenda

MPLS VPN technology overview

security concerns

what to check ?

how to check it ?

conclusion


MPLS VPN

we consider here L3VPN (MPLS also supports L2VPN

e.g. : EoMPLS, VPLS, …)

network based VPN (vs. CE based VPN)

any to any

no ciphering

VPN depends on whole core network configuration

RFC 2547 -> RFC 4364


MPLS VPN vs. FR full mesh

Red CE

Red CE

Red CE

Red CE

Green CE

Green CE

Green CE

Green CE

PE

PE

PE

PE

PE : Provider Edge

CE : Customer Edge

CE : Customer Edge

Red CE Red CE

Red CEGreen CE

Green CE

Red CE Green CEGreen CE


MPLS

RFC 3031

Multi-protocol label switching

Cisco : tag-switching (TDP -> LDP)

MPLS header contains a (stack of) label(s)

no CE participates to tag/label switching


MPLS : label distribution (LDP)

PE

PE

PE

CE

CE

P

InTag Prefix

OutIface

OutTag

- 128.89 1 4

- 171.69 1 5

….. ….. ….. ….

InTag Prefix

OutIface

OutTag

4 128.89 0 9

5 171.69 1 7

….. ….. ….. ….

InTag Prefix

OutIface

OutTag

9 128.89 0 -

….. ….. ….. ….

1

1

0 128.89

171.69

Label 7 for 171.69

Label 9 for 128.89

Label 4 for 128.89

Label 5 for 171.69

0


MPLS : label switching (no VPN)

PE

PE

PE

CE

CE

P

InTag Prefix

OutIface

OutTag

- 128.89 1 4

- 171.69 1 5

….. ….. ….. ….

InTag Prefix

OutIface

OutTag

4 128.89 0 9

5 171.69 1 7

….. ….. ….. ….

InTag Prefix

OutIface

OutTag

9 128.89 0 -

….. ….. ….. ….

1

1

0

128.89

171.69CE

128.89.25.4 data

128.89.25.4 data

128.89.25.4 data

0

4 128.89.25.4 data9


VRF Virtual Routing and Forwarding instance

local to the PE, it contributes to the VPN but it is not the VPN

Route Distinguisher RD (64 bits) => RD + @IPV4 = @VPN-IPV4

IPV4 addresses of two VPN can overlap, VPN-IPV4 addresses are distinct

Interface to “red CE” is associated to “red VRF” :

– Interface does not accept labeled packets, only IPV4

– Ingress traffic is routed through the associated VRF

– Egress traffic could be routed to an interface not associated with the VRF

PE interface to the CE can be considered as “VPN edge”

Using VRF, each VPN has its own routing table on PE. Now, how is the VPN built across the network ?


MP-iBGP

Part of Multiprotocol Extensions for BGP-4 (RFC 4760)

Extension to BGP in order to advertise VPN-IPV4 routes

A MP-iBGP update contains :

– VPN-IPV4 address

– Standard BGP attributes (loc.prf, MED, NH, AS path..)

– Site Of Origin (identifies the originating PE)

– Route Target (defines route propagation across VRFs)

– Route Origin (identifies the originating CE)

– Associated external label (set by originating PE)

no CE participates to MPiBGP


VRF configuration example VRF configuration determines :

– Route distinguisher

– Route Target (RT) attribute(s) to be added to route

update

– Route Target (RT) to import i.e. a MP-iBGP update is

accepted only if RT is imported by the VRF

ip vrf I_SIMPLE320

rd 9999:13191001

route-target import 9999:13191000

route-target export 9999:13191000

maximum routes 1000 80

!


VRF configuration example

RD identifies the VRF, RT identifies the VPN (simple

case)

VRF name could be different on each PE, it is only a

convention to have the same name

VRF of a same VPN on distant PE exchange routes

using MPiBGP. Now, how is the VPN enforced in the

MPLS core ?


MPLS/VPN 2 levels of label :

– Internal label : to transport packet to egress PE in MPLS core

– External label : to identify the VRF on egress PE

P routers only handle internal label, they don’t know VPNs

On Ingress PE, the VRF determines which external label

has to be added to the packet, and which egress PE is

targeted. According to egress PE targeted, the internal

label is added above the external one on label stack.

On egress PE, internal label is discarded, external label

determines by which VRF the packet must be forwarded,

external label is discarded and packet is processed “by”

the VRF


Route Reflector RFC 4456

BGP route reflection

avoid peering meshing

RR knows RD, RT, but not each VRF content (VRF is local

and depends on RT import in VRF)

PE

PEPE

PE

PEPE

PE

PEPE

PE

PEPE

RR RR


Extranet

Extranet is when two VPN exchange routing

information

Use of route import/export between VRF

For some customers, VPN is built with several VRFs

exchanging routes (to reflect customer organization)

A VRF can learn routes from another without

exporting routes to this other VRF and vice versa

– i.e. main customer site may know routes to each

branch but each branch does not know routes to other

branches


Admin/Service VPN How to reach customer devices from operator’s management

network without exchanging routes between customers ?

assymetric RT

Hub and spoke topology

2 types of access to such a VPN :

– client : knows only routes to servers

– server : knows routes to clients and servers

ip vrf I_SIMPLE320 ip vrf MGT

rd 9999:13191001 rd 9999:20001

route-target import 9999:20000 route-target import 9999:30000

route-target import 9999:13191000 route-target export 9999:20000

route-target export 9999:30000 maximum routes 100000 80

route-target export 9999:13191000 !


!


Admin/Service VPN

9999:0001 9999:0002

9999:20000

9999:20000

9999:30000 9999:30000

Management

Green Red


Import map, Export map

Not all import/export are declared statically

Use of import and/or export map that define rules for setting route targets in routing updates

For example :

ip vrf I_SIMPLE320

rd 9999:13191001

export map VPN-export



route-target export 9999:13191000


!


Import map, Export map

route-map VPN-export permit 30

match tag 9000

set community 9999:20103

set extcommunity rt 9999:30000

!

ip route vrf I_SIMPLE320 10.10.99.2 255.255.255.255 ATM2/0/1.271 tag

9000

Allow to choose routes that are exported to management

network (not all customer addresses, only management

addresses)


Security concerns

MPLS/VPN security is reputed to be comparable to

FR/ATM security assuming that :

– Attacker cannot gain access to the core

– Mistakes (or unwanted changes) in configurations are

avoided

a VPN configuration depends on whole network

configuration (not only configuration of VRF on the

access PE for that VPN)

=> to check one VPN, you must check the whole

network


Security concerns

Then, following points are mandatory :

– PE and P are in operator premises and physically

protected

– Each node (P/PE) is protected against intrusion

– Only PE and P participate in tag switching

– Only PE participate in MPiBGP (no CE)

– Each VPN configuration on each PE must be correct

– All the above points must be regularly checked

It is important that provisioning process is fully reliable

It is important to be able to check the whole network

configuration for all VPN


What to check about MPLS/VPN

configuration ? VPN access points

– PE interfaces

VRF configuration

– RD presence

– RD uniqueness

– Max route

VPN connectivity

– RT Import/Export

– Routes/VRF consistency (do we route to an interface which do not belong to the VRF ?)

Admin/Service VPN security

– RT use

– Routes use

Compliance with provisioning/ressource allocation


How to check

SAFE (OBS security assessment tool) feature

Collect periodically VPN related information in all VPN

aware (PE) routers configurations :

– VRF name

– RD

– RT import/export

Static

Through route-map

– Interfaces in VRF

– Static routes


How to check

Get information from ressource allocation tool

– VRF name

– VPN id (RD and main RT are built from VPN id)

– Interfaces

– RT import

– RT export


How to check

Store information in order to be able to :

– Provide information on VPN perimeter

– Provide details where problems occur

Check consistency (what is referenced is declared and vice-versa)

Check compliancy of configuration data with allocation tool data

Check service/admin RT use

Check service/admin routes use

Check RD presence and uniqueness

Check static routes/interface consistency


Results exploitation

Even if we keep information for each PE, results are

provided for the whole VPN.

i.e. VPN A export to VPN B means that there is at least one

PE where VRF A exports at least one route with a route

target imported by VRF B on at least one PE. This does not

mean that all routes known in VPN A are known in VPN B.

Results are provided by VPN

Two type of results :

– Obvious errors don’t depend on customer VPN architecture :

ex: RD uniqueness, admin/service routes/RT use

– VPN perimeter problem : noncompliance with allocation tool

Tool provides statistics


Results exploitation Who may use the tool ?

– Backbone ops : operate the backbone (PE and P global

configuration)

– VPN owner : is responsible for one (or more) VPN (Customer

access

Depends on error type

– Obvious errors :

Can be identified by backbone ops

All obvious errors are reported in dashboards (excel files)

May require VPN owner action/validation

– VPN perimeter problem :

can only be confirmed by VPN owner (knowledge of

customer VPN architecture is needed)






Conclusion A tool to keep an eye on VPN configurations

Other tools may also contribute (production tools, routing

supervision tools)

But tool does not all the job, it is part of a whole set of security

actions :

– provisioning tools are designed to minimize errors in configurations

– VPN owner checks his VPN perimeter (using his knowledge of

customer network architecture)

– Network architects follow design rules (no CE involved in MPi-BGP,

no PE out of AS)

– Backbone operators enforce PE and P protection against intrusion

and check configurations for this protection periodically (also

automated with a tool)

Documents

1 MPLS VPN Security assessment C. Anselme-Moizan [email protected]