MPLS VPN Security assessment

1
MPLS VPNSecurity assessment

• C. Anselme-Moizan
• christophe.anselmemoizan_at_orange-ftgroup.com

2
Agenda

• MPLS VPN technology overview
• security concerns
• what to check ?
• how to check it ?
• conclusion

3
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 -gt RFC 4364

4
MPLS VPN vs. FR full mesh
5
MPLS

• RFC 3031
• Multi-protocol label switching
• Cisco tag-switching (TDP -gt LDP)
• MPLS header contains a (stack of) label(s)
• no CE participates to tag/label switching

6
MPLS label distribution (LDP)
In Tag Prefix Out Iface Out Tag
9 128.89 0 -

.. .. .. .
In Tag Prefix Out Iface Out Tag
4 128.89 0 9
5 171.69 1 7
.. .. .. .
In Tag Prefix Out Iface Out Tag
- 128.89 1 4
- 171.69 1 5
.. .. .. .
0
0
128.89
PE
CE
Label 9 for 128.89
1
Label 4 for 128.89 Label 5 for 171.69
1
PE
P
Label 7 for 171.69
171.69
PE
CE
7
MPLS label switching (no VPN)
In Tag Prefix Out Iface Out Tag
9 128.89 0 -

.. .. .. .
In Tag Prefix Out Iface Out Tag
4 128.89 0 9
5 171.69 1 7
.. .. .. .
In Tag Prefix Out Iface Out Tag
- 128.89 1 4
- 171.69 1 5
.. .. .. .
CE
128.89
0
0
PE
1
128.89.25.4
data
128.89.25.4
data
9
1
128.89.25.4
data
4
PE
P
128.89.25.4
data
171.69
CE
PE
CE
8
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) gt RD _at_IPV4
  _at_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 ?

9
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

10
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 999913191001
• route-target import 999913191000
• route-target export 999913191000
• maximum routes 1000 80
• !

11
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 ?

12
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 dont
  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

13
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)

RR
RR
PE
PE
PE
PE
PE
PE
PE
PE
PE
PE
PE
PE
14
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

15
Admin/Service VPN

• How to reach customer devices from operators
  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 999913191001 rd 999920001
• route-target import 999920000 route-target
  import 999930000
• route-target import 999913191000
  route-target export 999920000
• route-target export 999930000 maximum routes
  100000 80
• route-target export 999913191000 !
• maximum routes 1000 80
• !

16
Admin/Service VPN
Management
999930000
999930000
999920000
999920000
Red
Green
99990001
99990002
17
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 999913191001
• export map VPN-export
• route-target import 999920000
• route-target import 999913191000
• route-target export 999913191000
• maximum routes 1000 80
• !

18
Import map, Export map

• route-map VPN-export permit 30
• match tag 9000
• set community 999920103
• set extcommunity rt 999930000
• !
• 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)

19
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)
• gt to check one VPN, you must check the whole
  network

20
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

21
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

22
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

23
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

24
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

25
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 dont depend on customer VPN
  architecture ex RD uniqueness, admin/service
  routes/RT use
• VPN perimeter problem noncompliance with
  allocation tool
• Tool provides statistics

26
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)

27
(No Transcript)
28
(No Transcript)
29
(No Transcript)
30
(No Transcript)
31
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)