MPLS VPN Security. Intelligent Information Network. Klaudia Bakšová Systems Engineer, Cisco Systems

Transcription

1 Intelligent Information Network MLS VN Security Klaudia Bakšová Systems Engineer, Cisco Systems

2 Agenda Analysis of MLS/VN Security Inter-AS VNs rovider Edge DoS possibility Secure MLS VN Design Internet Access Security Recommendations Summary 2

3 The rinciple: A Virtual Router Virtual Routing and Forwarding Instance! ip vrf Customer_A rd 100:110 route-target export 100:1000 route-target import 100:1000! interface Serial0/1 ip vrf forwarding Customer_A! Assign Interface to Virtual Router Route Distinguisher: Makes VN routes unique Export this VRF with community 100:1000 Import routes from other VRFs with community 100:1000 3

4 General VN Security Requirements Address Space and Routing Separation Hiding of the MLS Core Structure Resistance to Attacks Impossibility of VN Spoofing Working assumption: The core (+) is secure 4

5 mbehring Address lanes: True Separation! VN1 Address Space ? VN2 Address Space ? Several Data lanes: VNv4 Addr. Control lane: Iv4 Addr.? Core Address Space ? - Interfaces Belong to VN; Only Attack oint!! 5

6 Hiding of the MLS Core Structure Visible Address Space of VN1 MLS core I(; l0) 1 I(1) I(; fa0) VRF 1 2 I(2) I(; fa1) VRF 2 interface to the only point where a VN can see the core and send packets to the core device; seen and accessible from VN1 space only, VN1 cannot see any other interface on the Only peer addresses of VN1 exposed (-> )! -> ACL for interfaces for receive traffic I unnumbered for interfaces complete hiding of the core from that VN! routers not reachable from VN 6

7 rotection Against Spoofing VN Customer VN Customer Transit ACL Customer Internet Service rovider Internet Internet * Exceptions: Inter-AS, CsC Customer VN Customer Internet Customer LS Label Spoofing - Interface between and pure I without labels labeled packet received from, automatically drops it Cannot spoof labels from outside! I spoofing possible, remains within the originating VN RFC2827 7

8 Inter-AS: What are we trying to achieve? An S should have: 100% (full) reachability to all Inter-AS VNs shared between them (control plane and data plane) 0% (no) reachability to VNs that are not shared (control plane and data plane) S networks should be independent: Must be secured against each other Not attackable from outside (other S, customer, Internet) 8

9 Inter-AS: What Are We NOT Trying to Achieve? Any Form of Separation Between Inter-AS VNs (Control or Data lane) - Interconnection of VNs is 100% No firewalling, no limitations, no sanity checks within an Inter-AS VN If an S Holds VN Sites in an Inter-AS Set-Up, He Has Full Access to All VN Sites, Also on Other ASes 9

10 Inter-AS: Case A VRF-VRF Back-to-Back Cust. AS 1 AS 2 ASBR ASBR Cust. mbehring LS I Data LS Control plane: No signalling, no labels interfaces external to AS are pure I, each ASBR holds its own VRF for the shared VN ASBR - as if a single router connecting a router (the other ASBR) Data plane: Iv4 only, no labels accepted Not very scalable 10

11 Inter-AS: Case A otential Security Issues Accidental misconnection at the ASBR Ss have to make sure they are clear about which interface/subinterface connects which VN Routing issues VRFs on both ASBRs will exchange routing for a given Inter-AS VN Routing security refix number limited to avoid memory overflow Security: as in RFC2547; most secure interconnection model no labels accepted due to - analogy, neighbouring AS cannot see the AS core Ss are completely separated, VRF-to-VRF connection, no global routing table connection Neighboring ASBR - just an I interface to MLS core no label spoofing 11

12 Inter-AS: Case B ASBR exchange labelled VNv4 routes Cust. AS 1 AS 2 ASBR M-eBG+Labels ASBR Cust. mbehring LS VN label I Data LS Control plane: M-eBG between ASBRs, no IG or TD/LD Inter-AS VNv4 routes held in BG table, not in VRFs Data plane: one connection between ASBRs data plane traffic for different VNs must be kept separate labelling packets before sending them to the other ASBR (label stack swapped for ASBR VN label) inherent behaviour to M-eBG Better scalability, BG table size might be an issue 12

13 Inter-AS: Case B otential Security Issues No AS VN label is checked on ASBRs when forwarding, => possible label spoofing => data plane not possible to secure completely External interfaces accept labelled packets instead of just I packets No way for ASBR to check on the VN membership of the packet, as there is no VRF on ASBR Control plane: ingress ASBR interfaces ACL to filter any I accept BG Ss are completely separate Visibility only the neighbouring ASBR, via ebg 13

14 Inter-AS Case C: ASBRs Exchange loopbacks Cust. AS 1 AS 2 VNv4 Routes + Labels ASBR Loopb+Labels ASBR Cust. mbehring LS label VN I Data Control plane: visibility of both Ss through Multihop M-BG ASBR exchange just loopback vie ebg + labels; s exchange VNv4 routes + labels end to end without involving ASBRs => no need to hold VN specific information, only loopbacks and their labels => very scalable Data plane: label + VN label, ASBRs only as routers, LS built from in AS1 to in AS2 14

15 Inter-AS: Case C otential Security Issues Security: S must be able to reach all s of neighbouring AS which hold connections of shared VNs, issue: ASBR cannot check VN label, sees only egress label, possible VN label spoofing => probability of misinsertion Control plane: ingress ASBR interfaces ACL to filter any I accept BG ASBR no VRF, no VN routing information => VN label below egress label cannot be checked (e.g. intrusion no VN label appended, H pops egress label at router, receives a pure I packet gets routed into S core) All these label spoofing attacks carried out by S, not by customer VN, as data can be injected at ASBR only! 15

16 The Key Issue: Designing a DoS Resistant rovider Edge Customer VN MLS core VN Customer VRF 1 Internet Customer DoS Attack Internet VRF rimary prerequisite I address visibility has shared CU / memory / bandwidth resources for different VRFs: Traffic can affect VN customer(s) via performance degradation up to complete loss of connectivity DoS attacks usually perceived as coming from Internet, however also coming from customer VNs A way to compromise MLS core thorough security of s crucial to avoid the threat 16

17 Today s Best ractice: DoS Through a Shared Solved by Using a different design To Internet 1 1 Separate VN and Internet traffic on physically different routers customer network 2 To VN 2 VRF Internet VRF VN routers should contain only VRFs of the same security level. Example: Level 0: Internet Level 1: VN customers Internet VN subject to DoS attack in no different way than other network technologies, i.e. this is not an MLS-specific issue DO NOT expose addresses to Internet at all, or with dynamic routing use limit to routing reachability only Infrastructure ACL! 17

18 Separate VN and Internet Access Customer LAN MLS core To Internet Firewall / NAT 1 1 VRF Internet IDS 2 2 VRF VN To VN Separation DoS resistance 18

19 Agenda Analysis of MLS/VN Security Inter-AS VNs rovider Edge DoS possibility Secure MLS VN Design Internet Access Security Recommendations Summary 19

20 Internet rovisioning on an MLS Core Most common VN user requirement S to provide Internet access in addition to VN connectivity Two basic possibilities: 1. Internet in global table, either: 1a) Internet-free MLS core (using LSs between s) 1b) Internet routing held by the entire MLS core ( and ) 2. Internet in VRF Internet carried as a VN on the core Issue how to design an MLS core for Internet access such that VNs remain secure 20

21 MLS Core Without Internet Connectivity MLS Core no connection to the Internet; only VNs connect to the core, not reachable, also (except in case seen below) ure MLS VN service considered most secure well secured against intrusions and DoS attacks from the outside (core invisible from the outside) VN Spoofing impossible, VNs not reachable from the outside But what about: B VRF B VRF B B A VRF A mbehring VRF Ambehring A Internet Service rovider Internet has become part of the VN, above statements still hold DoS attack within such VN no immense threat as access capacity of VN A can be limited by configuration 21

22 Internet in a VRF Internet Service rovider Internet Internet VN Customer Customer Customer VN Customer VN Customer Internet Routing Table (Global Routing Table) VN Routing Table (VRF) Internet in a VRF Internet Customer 22

23 Internet in a VRF Security Features Internet is handled just the same as a VN, Customer VNs not reachable from Internet VN The core is secure against attacks from the outside as the Internet has no access to the core not reachable Spoofing is impossible between VNs and Internet in a VN Internet VN possibility of DoS of higher magnitude can be reachable from Internet if not secured properly Customer VNs must not be affected -> provide sufficient capacity in the core OR use QoS to prioritize VN traffic over Internet traffic Scalability Issue a prefix held in a VRF requires about three times as much memory as a prefix held in the global table => additional memory required 23

24 Internet in the Global Routing Table Using LSs Between s Internet Routing Table (Global Routing Table) VN Routing Table (VRF) Internet Service rovider Internet VN Customer Customer Internet Customer VN Customer VN Customer Internet Customer LS Ingress - ibg next hop - Egress loopback Next hop to egress usually has label, LS is used to reach egress routers do not need to know Internet routes (nor run BG, only IG and LD) 24

25 Internet in the Global Routing Table Using LSs Between s - Recommendations In this model routers have to carry routes for routers in their IG Traffic coming from the outside into a router's global routing table will have normally a route to the routers ( reachable unidirectionally) LD and ibg threatened via attacks against TC usage of MD5 authentication as a solution use Infrastructure ACLs to prevent packets from outside reach the inside of the core use Receive ACLs and Control lane olicing to protect the control plane of a single platform Consider using NSA addresses in core IS-IS 25

26 Agenda Analysis of MLS/VN Security Inter-AS VNs rovider Edge DoS possibility Secure MLS VN Design Internet Access Security Recommendations Summary 26

27 Securing the Core: Infrastructure ACLs VN In MLS: address belongs to VRF! Intended to filter data destined for network infrastructure equipment, i.e. what protocols and addresses can access critical infrastructure equipment On all reachable VRF interfaces: deny ip any < address space> permit ip any any exception: routing protocol from only and all transit traffic Idea: rotecting the Core DoS: traffic over router theoretically enables DoS, primary threat traffic destined for R iacls also to deny source private address space, reserved addresses, Ss own address space - antispoofing 27

28 Securing the Core: Infrastructure ACLs /30.1 VN VN / /30.1 VN VN /30.2 Example: deny ip any permit ip any any This Is VN Address Space, Not Core! Caution: This also blocks packets to the s! Alternatives: List all i/f in ACL, or use secondary i/f on 28

29 Securing the Core: - routing protocol security In order of security preference: 1. Static: If no dynamic routing required (no security implications no fabricated routing updates, less CU impact, possible sniffing not revealing routes due to no updates) 2. BG: For redundancy and dynamic updates (many security features prefix filtering, route dampening, one BG process, multiple address-families (per customer/vrf), redistribution at not necessary into ibg) 3. IGs: If BG not supported (limited security features peering address known, no neighbor definition, use iacls) 29

30 Routing Security: Neighbor Authentication and BG TTL Use static routing between and where possible no errant routes announced, no routing data crossing the wire, no CU impact Routers authenticate each time a routing update is exchange between them reliable information received from a trusted source Verification through MD5 hash Supported: BG, ISIS, OSF, EIGR, RIv2, LD MD5 for LD label spoofing protection, enable also on M-iBG 30

31 Control of Routes from a BG eer Injection of too many routes possible attack at routing table stability, CU and memory: otential DoS attack, leading e.g. to F disabling or reload Control with maximum prefix command After exceeding the number BG peering disabled, neighbor down From This Neighbor Accept Max 45 refixes, Then Reset Session router bgp 13 neighbor maximum-prefix restart 2 Log a Warning at 80% (of 45), and Restart the BG Session After Two Min. 31

32 Control of Routes from a BG eer: Logging 6d22h: %BG-4-MAXFX: No. of prefix received from (afi 2) reaches 37, max 45 6d22h: %BG-3-MAXFXEXED: No. of prefix received from (afi 2): 46 exceed limit 45 6d22h: %BG-5-ADJCHANGE: neighbor vpn vrf VN_20499 Down BG Notification sent 6d22h: %BG-3-NOTIFICATION: sent to neighbor /1 (update malformed) 0 bytes FFFF FFFF FF 32

33 VRF Maximum refix Number Injection of too many routes: otential memory overflow otential DoS attack For a VRF: Specify the maximum number of routes allowed In This VRF ip vrf red maximum routes Accept Max 45 refixes, and Log a Warning at 80% (of 45), 33

34 -Specific Router Security Control lane hardening Receive traffic L3 routing environment (authentication, max number of prefixes ) Infrastructure ACLs rotection ACLs (anti-spoofing, etc.) Data lane Hardening Use urf Strict mode on each interface of the routers facing interfaces and on the routers -facing interfaces 34

35 Attacking a from MLS (other VN) Is the reachable from the MLS side? -> only if this is an Internet, otherwise not! (- addressing is part of VN!) For Internet s: Same security rules apply as for any other access router. MLS hides VN-s: Secure! Internet s: Same as in other networks 35

36 Agenda Analysis of MLS/VN Security Inter-AS VNs rovider Edge DoS possibility Secure MLS VN Design Internet Access Security Recommendations Summary 36

37 Securing the MLS Core: Wrap-Up VN MLS core BG Route Reflector VN Internet VN VN VN BG peering with MD5 authentic. LD with MD5 ACL and secure routing 37

38 MLS Security Overview 1. Don t let packets into (!) the core No way to attack core, except through routing, thus: 2. Secure the routing protocol Neighbor authentication, maximum routes, dampening, 3. Design for transit traffic QoS to give VN priority over Internet Choose correct router for bandwidth Separate s where necessary 4. Operate Securely Still open : routing protocol Only attack vector: Transit traffic Now only insider attacks possible Avoid insider attacks 38