MPLS VPN Security BRKSEC-2145
Session Objective Learn how to secure networks which run MPLS VPNs. 100% network focus! Securing routers & the whole network against DoS and abuse Not discussed: Security appliances such as firewall and IPS Content and application security Target audience: People running, architecting or securing MPLS network Should be familiar with the fundamentals of MPLS 2
MPLS Security: History 2001: First MPLS deployments; little security concerns 2002: First security concerns raised by SP and Enterprises; first Gartner report 2003: MPLS Security becoming key concern; Miercom test; first white papers; second Gartner report 2004: RFC 4381: Security of the MPLS VPN Architecture 2005: MPLS VPN Security book; focus on inter-as, L2VPN, other advanced subjects 2006-2008: No major security debates 2009: Renewed interest; hacker reports; insider threats 3
MPLS VPN Security Agenda Analysis of the Architecture Secure MPLS VPN Design General Best Practices Internet Access Inter-AS and CsC Layer 2 VPN Security Multicast VPN Security IPsec and MPLS Summary 4
Analysis of the MPLS VPN Architecture (RFC 4364) Presentation_ID 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 5
Comparison with ATM/FR ATM/FR MPLS Address Space Separation Yes Yes Routing Separation Yes Yes Resistance to Attacks Yes Yes Resistance to Label Spoofing Direct CE-CE Authentication (Layer 3) Yes Yes Yes With IPsec 6
Basic RFC 4364 Security: Today s Arguments Can be mis-configured (operation) Routers can have bugs (implementation) PEs can be accessed from Internet, thus intrinsically insecure Floods over Internet can impact VPN traffic True, but same on ATM/FR PEs can be secured, as Internet routers Engineering/QoS 7
mbehring Address Planes: True Separation! (Example is IPv4 also applies to IPv6) CE VPN1 Address Space 0.0.0.0 255.255.255.255 CE CE VPN2 Address Space 0.0.0.0 255.255.255.255 CE Several Data Planes: VPNv4 Addr. Control Plane: IPv4 Addr. PE P PE Core Address Space 0.0.0.0 255.255.255.255 PE-CE Interfaces Belong to VPN; Only Attack Point!! 8
Secure MPLS VPN Design General Security Best Practices Presentation_ID 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 9
Secure MPLS/VPN Core Design 1. Secure each router individually 2. Don t let packets into (!) the core No way to attack core, except through routing, thus: 3. Secure the routing protocol Neighbor authentication, maximum routes, dampening, 4. Design for transit traffic QoS to give VPN priority over Internet Choose correct router for bandwidth Separate PEs where necessary 5. Operate Securely Still Open : Routing Protocol Only Attack Vector: Transit Traffic Now Only Insider Attacks Possible Avoid Insider Attacks 10
Securing the Core: Infrastructure ACLs Easy with MPLS! CE PE VPN 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: hard, but theoretically possible with transit traffic 11
Securing the Core: Infrastructure ACLs CE.2 1.1.1.0/30.1 PE VPN PE VPN.1 1.1.1.8/30.2 CE CE.2 1.1.1.4/30.1 PE VPN PE VPN.1 1.1.1.12/30.2 CE 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, or ACL with dis-contiguous subnet masks (11111101) 12
VRF Maximum Prefix Number Injection of too many routes: Potential memory overflow Potential DoS attack For a VRF: Specify the maximum number of routes allowed In This VRF ipvrf red maximum routes 45 80 Accept Max 45 Prefixes, and Log a Warning at 80% (of 45), 13
Control of Routes from a BGP Peer Injection of too many routes: Potential memory overflow Potential DoS attack Control with maximum prefix command (under the BGP neighbor definition) From This Neighbor Accept Max 45 Prefixes, Then Reset Session router bgp 13 neighbor 140.0.250.2 maximum-prefix 45 80 restart 2 Log a Warning at 80% (of 45), and Restart the BGP Session After Two Min. 14
Best Practice Security Overview Secure devices (PE, P): They are trusted! See next slide for risks PEs: Secure with ACLs on all interfaces Static PE-CE routing where possible For routing, LDP: Use authentication (MD5) Maximum number of routes per VRF and per peer (only BGP) Separation of CE-PE links where possible (Internet/VPN) Note: Overall security depends on weakest link! 15
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 ) 16
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 17
The 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) MPLS core Customer VPN PE P P VPN Customer VRF CE1 P Internet Customer Internet VRF P P 18
Customer Network Today s Best Practice: MPLS VPN Security Recommendation: PE Routers Should Contain Only VRFs of the Same Security Level; Example: To Internet CE1 CE2 PE1 PE2 VRF Internet VRF VPN Level 0: Internet Level 1: VPN customers (Level 2: Mission critical infrastructure) To VPN Note: This is negotiable: Shared Internet/VPN PE may be acceptable if price and conditions are right 19
Secure MPLS VPN Design Internet Access Presentation_ID 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 20
Internet Provisioning on an MPLS Core Two basic possibilities: 1. Internet in global table, either: 1a) Internet-free core (using LSPs between PEs) 1b) hop-by-hop routing 2. Internet in VRF Internet carried as a VPN on the core This is the default!!! 21
Internet in the Global Routing Table Using LSPs Between PEs Internet Service Provider Internet CE VPN Customer Customer PE P Internet PE P Customer PE VPN Customer VPN Customer Internet Routing Table (Global Routing Table) VPN Routing Table (VRF) LSP Internet Customer 22
Internet in the Global Routing Table Using LSPs Between PEs Default behavior, if Internet in global table!! On ingress PE: BGP next hop: Egress PE loopback Next hop to egress usually has label! LSP is used to reach egress PE P routers do not need to know Internet routes (nor run BGP) Security consequence: PE routers are fully reachable from Internet, by default (bi-directional) P routers are also by default reachable from Internet; but only uni-directional, they don t know the way back! 23
Internet in the Global Routing Table Using LSPs Between PEs Recommendations: Fully secure each router! Do not advertise IGP routes outside (This is a general security recommendation for all cores!) P routers not reachable (unless someone defaults to you) PE routers not reachable (possible exception: Peering PE) Infrastructure ACLs to block core space: Additional security mechanism Even if someone defaults to you, he cannot reach the core 24
Internet in the Global Routing Table Hop-by-Hop Routing Internet Service Provider Internet CE VPN Customer Customer PE P Internet PE P Customer PE VPN Customer VPN Customer Internet Routing Table (Global Routing Table) VPN Routing Table (VRF) Internet Customer 25
Internet in the Global Routing Table Hop-by-Hop Routing Like in standard IP core Each router speaks BGP, and carries Internet routes Not default, must be configured! Security consequence: P and PE routers by default fully reachable from Internet Recommendations: (like before) Fully secure each router! Do not advertise IGP routes outside Infrastructure ACLs 26
Internet in a VRF Internet Service Provider Internet CE VPN Customer Customer PE P Internet PE P Customer PE VPN Customer VPN Customer Internet Routing Table (Global Routing Table) VPN Routing Table (VRF) Internet in a VRF Internet Customer 27
Internet in a VRF Internet is a VPN on the core Full separation to other VPNs, and the core, by default! Connection between Internet and a VPN (for service) must be specifically configured Security consequence: But!!! P routers not reachable from anywhere! PE routers only reachable on outbound facing interfaces; Very limited Much easier to secure Routes in a VRF take more memory Convergence times increase on old systems 28
Alternatively: No Internet on the Core Pure MPLS VPN service considered most secure But what about: PE PE CE B VRF B VRF B CE B CE A VRF A mbehring VRF Ambehring CE A Internet Service Provider however, bandwidth usually limited and some firewall / control applied 29
Secure MPLS VPN Design Inter-AS and Carrier s Carrier Presentation_ID 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 30
security functionality Inter-AS: The Options Option A VRF back to back; IP interface Option B ASBRs exchange labelled VPN prefixes; labelled interface Option C ASBRs don t hold VPN information - only Route Reflectors do; labelled interface ASBR: Autonomous System Border Router VRF: Virtual Routing and Forwarding instance 31
Inter-AS: Case A VRF-VRF Back-to-Back Cust. CE AS 1 AS 2 PE ASBR PE ASBR Cust. CE mbehring LSP IP Data LSP Control plane: No signalling, no labels Data plane: IPv4 only, no labels accepted Security: as in RFC 2547 (single-as) SPs are completely separated 32
Security of Inter-AS case A Static mapping Only IP interfaces 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 (like in ATM/FR) Customer can flood routing table on PE (this is the same issue as in RFC 2547 (single-as); solution: prefix limits) 33
Inter-AS: Case B ASBR exchange labelled VPNv4 routes Cust. CE AS 1 AS 2 PE ASBR MP-eBGP+Labels ASBR PE Cust. CE mbehring LSP VPN label IP Data LSP Control plane: MP-eBGP, labels Data plane: Packets with one label 34
Security of Inter-AS Case B: Summary Control Plane can be secured well Data Plane has some security issues: Label is not checked today (since i/f in global table) Labelled packets on any MPLS i/f will be forwarded if LFIB entry exists Potential Issues: Insertion of traffic into non-shared VPNs (uni-directional only) (requires compromised/faulty ASBR, remote exploit not possible) All global i/f on an ASBR share the same LFIB, thus might affect third parties Good: No visibility of other AS (except ASBR i/f) 35
Inter-AS Case C: ASBRs Exchange PE loopbacks Cust. CE AS 1 AS 2 VPNv4/v6 Routes + Labels PE ASBR PE Loopb+Labels PE ASBR Cust. CE mbehring LSP PE label VPN IP Data Control plane: ASBR: just PE loopback + labels; PE/RR: VPNv4/v6 routes + labels Data plane: PE label + VPN label AS1 can insert traffic into VPNs in AS2 Only requirement: Must have LSP to correct egress PE Customer must trust both SPs 36
Security of Inter-AS Case C ASBR-ASBR signalling (BGP) RR-RR signalling (MP-BGP) Much more open than Case A and B More interfaces, more visible parts (PE, RR) Potential Issues: SP1 can intrude into any VPN on PEs which have a Inter-AS VPN configured Cannot check what s underneath the PE label Very open architecture Acceptable for ASes controlled by the same SP 37
Inter-AS Summary and Recommendation Three different models for Inter-AS Different security properties Most secure: Static VRF connections (case A), but least scalable Basically the SPs have to trust each other Hard/impossible to secure against other SP in this model But: Can monitor with MPLS aware NetFlow (!!) Okay if all ASes in control of one SP Current Recommendation: Use case A 38
Carrier s Carrier Cust. CE1 Carrier Carrier s Carrier Carrier Cust. CE2 PE1 PE2 CsC CE1 CsC PE1 CsC PE2 CsC CE2 IP data IP data label IP data label IP data label label IP data Same principles as in normal MPLS Customer trusts carrier who trusts carrier 39
Carrier s Carrier: The Interface Carrier s Carrier Carrier CsC-CE CsC-PE Control Plane: CsC-PE assigns label to CsC-CE Data Plane: CsC-PE only accepts packets with this label on this interface CsC-PE controls data plane, no spoofing possible 40
Layer 2 VPN Security Presentation_ID 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 41
Virtual Private LAN Service (VPLS) Overview Network behaves as a switch Spanning Tree MAC address learning ARP, etc. Examine threats to a switch to understand VPLS security 42
VPLS Security Threats VLAN Hopping MAC Attacks DHCP Attacks ARP Attack NDP Spoofing (IPv6) Spoofing Attacks Other Attacks 43
Best Practices for L2 Security (VPLS) 1. Always use a dedicated VLAN ID for Trunk Ports 2. Disable unused ports and put them in an unused VLAN 3. Use Secure Transmission when managing Switches (SSH, OOB, Permit Lists) 4. Deploy Port Security 5. Set all host ports to Non Trunking 6. ALWAYS use a dedicated VLAN for Trunk Ports 7. Avoid using VLAN 1 8. Have a plan for ARP Security issues and implement it!!! 9. Use SNMP V3 to secure SNMP transmission 10. Use STP Attack mitigation 11. Use MD5 Authentication for VTP 12. Plan for and implement DHCP Attack mitigation 13. Use Private VLAN s to better secure guest VLAN s 14. Use and implement 802.1x to protect entry into your network 15. Consider using VACL s to limit access to key network resources 44
Multicast VPN Security Presentation_ID 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 45
mbehring Address Planes: True Separation for unicast and multicast! CE CE VPN1 address space 0.0.0.0 255.255.255.255 including mc addresses VPN2 address space 0.0.0.0 255.255.255.255 CE CE several data planes control plane PE including mc addresses P core address space 0.0.0.0 255.255.255.255 PE including mc addresses PE-CE interfaces belong to VPN. Only attack point!! 46
MVPN Security Best Practices Avoid RP on PE Router Reason: higher exposure to DoS against PE Avoid src/rec directly connected to PE Careful with MDT group addressing Make MDT unreachable from Internet Filtering, private addressing 47
Multicast VPN Summary Each VPN can use multicast independently Source and group may overlap with other VPN Different PIM modes can be used VPNs remain fully separated No reachability between VPNs, unicast or multicast Cannot spoof other VPN, unicast or multicast MPLS core remains secure Not attackable from VPNs, unicast or multicast However: DoS of PE might affect other VPNs on that PE, this must be secured specifically Core cannot be spoofed 48
IPsec and MPLS Presentation_ID 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 49
Where to Apply IPSec CE PE PE CE IPSec CE-CE IPSec CE-PE IPSec PE-PE Application: Remote Access into VPN Application: VPN Security Application: Special Cases 50
How to Establish IPSec: Options Option 1: Static IPSec Pre-configure static IPSec tunnels Works, but does not scale well Option 2: Dynamic Cryptomap/ Tunnel Endpoint Discovery Scaling improvements over 1). Option 3: DMVPN Dynamic tunnel establishment Easy to configure and maintain Some scaling issues Option 4: GET VPN Easy to configure and maintain Scales well Dynamic Multipoint VPN Group Encrypted Transport But: GETVPN doesn t support IPv6 yet 51
GET VPN: IPsec Made Easy! Traditional IPsec: - n 2 Problem (scalability) IKE/IPsec Key Server GET VPN: - 2 Security Associations - to the key server (~IKE) - to the group (IPsec) IPsec 52
Summary Presentation_ID 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 53
MPLS VPN Security Agenda Analysis of the Architecture Secure MPLS VPN Design General Best Practices Internet Access Inter-AS and CsC Layer 2 VPN Security Multicast VPN Security IPsec and MPLS Summary 54
MPLS doesn t provide: Protection against mis-configurations in the core Protection against attacks from within the core Confidentiality, authentication, integrity, anti-replay Use IPsec if required Customer network security 55
Summary MPLS VPNs can be well secured Security depends on correct operation and implementation MPLS backbones can be more secure than normal IP backbones Core not accessible from outside Separate control and data plane Key: PE security 56
For More Information: MPLS VPN Security Authors: Michael Behringer Monique Morrow Cisco Press, ISBN: 1587051834 First published: June, 2005; still up to date; 57
Additional Information MPLS Security White Paper: http://www.cisco.com/warp/public/cc/pd/iosw/prodlit/mxinf_ds.htm Analysis of the security of the MPLS architecture RFC on MPLS VPN Security: http://www.ietf.org/rfc/rfc4381.txt Miercom MPLS test report: http://www.mier.com/reports/cisco/mpls-vpns.pdf Practical tests show that MPLS is secure Garnter research note M-17-1953: "MPLS Networks: Drivers Beat Inhibitors in 2003"; 10 Feb 2003 58
Q&A Presentation_ID 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 59
60