MPLS Virtual Private Network (VPN) Security

Transcription

1 MPLS Virtual Private Network () Security An MFA Forum Sponsored Tutorial Monique Morrow MFA Forum Ambassador CTO Consulting Engineer Cisco Systems Slide 1 MPLS Security - Agenda Analysis of the Architecture Secure MPLS Design General Best Practices Internet Access Inter-AS and Carriers Carrier Layer 2 Security Attacking an MPLS Network IPsec and MPLS Ongoing standardization work Summary Slide 2 1

2 MPLS Security Tutorial Contributors Developed by: Michael Behringer Cisco Systems Monique Morrow Cisco Systems Contributors: Victoria Fineberg DISA Ross Callon Juniper David Christophe Lucent Slide 3 About this Presentation Advanced level Expected: Basic understanding of MPLS protocols and how MPLS s operate. Target Audience: Service providers Network operators and designers Network security engineers Technical focus Slide 4 2

3 Why Is MPLS Security Important? Customer buys Internet Service : Packets from SP are not trusted Perception: Need for firewalls, etc. Customer buys a Service : Packets from SP are trusted Perception: Few or no further security measures required SP Must Ensure Secure MPLS Operations Slide 5 Objectives Understand how secure MPLS s* are And what IPsec offers in addition Best practices on how to secure General MPLS Inter-provider Specific cases (Internet connectivity, etc) Examples are for IPv4 s Also applicable to IPv6 * Here: MPLS = RFC 4364 (old 2547bis ) Slide 6 3

4 Analysis of the MPLS Architecture (RFC 4364) Slide 7 MPLS Security Framework Trusted Zone External Network MPLS Network External Network External Network Interface External Network Interface Control Plane MPLS core signaling LDP, RSVP, and BGP MPLS edge signaling BGP, LDP, RIP, OSPF Forwarding Plane MPLS packet forwarding IP or MPLS packet forwarding Slide 8 4

5 MPLS Security Service Provider View Trusted Zone Customer Network MPLS Network Peer SP Network External Service Interface External Network Connect Interface MPLS Edge Security Security for service interface Focus on control plane access and resources on router MPLS Core Security Security for end-to-end (-) MPLS traffic integrity Focus on MPLS packet forwarding MPLS Inter-AS Security Security for network interconnect interface Focus on data/control plane access on ASBR Slide 9 MPLS Security Enterprise View Trusted Zone Extranet Customer Network MPLS Network SP MPLS Network Extranet Service Interface External WAN Interface Extranet Edge Security Security of extranet interface Focus on data/control plane access across interface with partner MPLS Core Security Security for end-to-end (-) MPLS traffic integrity Focus on MPLS traffic segmentation WAN Edge Security Security of WAN interface with SP Focus on data/control plane access across -CE link with SP Slide 10 5

6 Comparison with ATM/FR Address Space Separation Routing Separation Resistance to Attacks Resistance to Label Spoofing Direct CE-CE Authentication (Layer 3) ATM/FR Yes Yes Yes Yes Yes MPLS Yes Yes Yes Yes With IPsec Slide 11 Basic MPLS Security: Today s Arguments Can be mis-configured (operation) Routers can have bugs (implementation) s can be accessed from Internet, thus intrinsically insecure Floods over Internet can impact traffic True, but same on ATM/FR s can be secured, as Internet routers Engineering/QoS Slide 12 6

7 mbehring Security Relies on Three Pillars Security Architecture/ Algorithm Implementation Operation Break One, and All Security Is Gone! Slide 13 Address Planes: True Separation! CE 1 Address Space CE CE 2 Address Space CE Several Data Planes: v4 Addr. Control Plane: IPv4 Addr. P Core Address Space CE Interfaces Belong to ; Only Attack Point!! Slide 14 7

8 Secure MPLS Design General Security Best Practices Slide 15 Secure MPLS/ Core Design Don t let packets into the core (for MPLS: routers) No way to attack core, except through routing, thus: Secure the routing protocol Neighbor authentication, maximum routes, dampening, Design for transit traffic QoS to give priority over Internet Choose correct router for bandwidth Separate s where necessary Operate Securely Still Open : Routing Protocol Only Attack Vector: Transit Traffic Now Only Insider Attacks Possible Avoid Insider Attacks Slide 16 8

9 -CE Routing Security In order of security preference (for both CE and ): 1. Static: If no dynamic routing required; also static default route (no security implications) 2. BGP: For redundancy and dynamic updates (many security features) 3. IGP: If BGP not supported (limited security features) Slide 17 Securing the MPLS Core CE CE P MPLS Core BGP Route Reflector P P Internet CE BGP Peering With MD5 Authentic. LDP With MD5 CE CE Slide 18 CE ACL, and Secure Routing 9

10 Securing the Core: Infrastructure ACLs CE On : deny ip any <VRF address space on the > Exception: routing protocol from host to host Idea: no traffic to /P you can t attack Prevents intrusions 100% DoS: very hard, but traffic over router theoretically enables DoS Easy with MPLS! In MPLS: VRF Belongs to Customer! Slide 19 Securing the Core: Infrastructure ACLs CE / /30.2 CE CE / /30.2 CE Example: This Is Address deny ip any Space, Not Core! permit ip any any Caution: This also blocks packets to the CE s! Alternatives: List all i/f in ACL, or use secondary i/f on CE Slide 20 10

11 Neighbor Authentication Router knows his neighbors Verification through MD5 based authentication Verifies updates it receives from neighbor Supported: BGP, ISIS, OSPF, RIPv2, LDP Key chains for key rollover Use them where available Config easy Slide 21 Maximum Prefix Control Injection of too many routes: Potential memory overflow Potential DoS attack Two security mechanisms: Specify maximum number of routes For a VRF For a BGP peer Slide 22 11

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 Accept Max 45 Prefixes ip vrf red maximum routes and Log a Warning at 80% (of 45) Slide 23 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 maximum-prefix restart 2 Log a Warning at 80% (of 45) and Restart the BGP Session After 2 min. Slide 24 12

13 Control of Routes from a BGP Peer: Logging 6d22h: %BGP-4-MAXPFX: No. of prefix received from (afi 2) reaches 37, max 45 6d22h: %BGP-3-MAXPFXEXCEED: No. of prefix received from (afi 2): 46 exceed limit 456d22h: %BGP- 5-ADJCHANGE: neighbor vpn vrf _20499 Down BGP Notification sent 6d22h: %BGP-3-NOTIFICATION: sent to neighbor /1 (update malformed) 0 bytes FFFF FFFF FF Slide 25 Best Practice Security Overview Secure devices (, P): They are trusted! See next slide for risks s: Secure with ACLs on all interfaces Static -CE routing where possible If dynamic routing: Use authentication (MD5) Maximum number of routes per peer (only BGP) Separation of CE- links where possible (Internet/) LDP authentication (MD5) VRF: Define maximum number of routes Note: Overall security depends on weakest link! Slide 26 13

14 Key: Security What happens if a single in the core gets compromised? Intruder has access to all s; GRE tunnel to his CE in the Internet, bring that CE into any That might not even notice Worst Case!!!! Therefore: Security is Paramount!!!!!!! Therefore: No on customer premises!!!!!!! (Think about console access, password recovery ) Slide 27 Solution: Operational Security Security depends on SP! Employee can make mistake, or malicious misconfiguration Potential Security hole: If compromised, s might be insecure Cannot *prevent* all misconfigs Need to operationally control this Slide 28 14

15 Operational Security Logging config changes Dual Control: Network operators must have no access to logging facility AAA for access Use command authorization where possible Keep logs in a secure place (Malicious employee might change logs too) Tight control Disable password recovery where possible Secure Operations Is Hard!!! Slide 29 MPLS s are Quite Secure Perfect Separation of s No intrusions possible Perfect Separation of the Core from s Again, no intrusions possible But there is one remaining issue Slide 30 15

16 Issue: DoS Through a Shared Might Affect Customer Has Shared CPU/Memory/Bandwidth: Traffic COULD affect customer (however, risk probably acceptable) Customer Customer MPLS core P P VRF CE1 P Internet Customer global table P P DoS Attack Slide 31 Today s Best Practice: Routers Should Contain Only VRFs of the Same Security Level; Example: Customer Network To Internet CE1 CE2 To 1 2 VRF Internet VRF Level 0: Internet Level 1: customers (Level 2: Mission critical infrastructure) Note: This is negotiable: Shared Internet/ may be acceptable if price and conditions are right Slide 32 16

17 Separate and Internet Access Customer LAN MPLS core To Internet Firewall/NAT CE1 1 P VRF Internet IDS CE2 2 VRF To Separation: +++ DoS resistance: +++ Cost: $$$ (two lines and two s: expensive!) Slide 33 Shared Access Line, CE with VRF Lite Customer LAN MPLS core Firewall/NAT Internet CE 1 P IDS VRF Internet VRF Internet VRF Separation: CE +++ Logical Links (e.g. FR) DoS resistance: + (DoS might affect on, attachment circuit, CE) Cost: $ Slide 34 17

18 mbehring Hub-and-Spoke with Internet Access Hub Site MPLS core Internet Firewall NAT Internet CE 1 To Internet VRF Internet IDS CE 2 To VRF s CEs Spoke 1 Spoke 2 Spoke 3 Slide 35 Extranet and Firewalling Extranet / Internet A Customer VRF A VRF B Customer B VRF A VRF B Extranet means: Connecting s Route Targets define where traffic is going Usually firewalling required to restrict connectivity and maintain separation Slide 36 18

19 Alternative Topologies Full mesh, one Internet access Internet access at several sites Several firewalls needed More complex Internet access from all sites Complex, one firewall per site Slide 37 Secure MPLS Design Internet Access Slide 38 19

20 Internet Provisioning on an MPLS Core Two basic possibilities: 1. Internet in global table, either: 1a) Internet-free core (using LSPs between s) 1b) hop-by-hop routing 2. Internet in VRF Internet carried as a on the core Slide 39 Internet in Global Routing Table Using LSPs Between s Internet Service Provider Internet CE Customer Customer P Internet P Customer Customer Customer Internet Routing Table (Global Routing Table) in a VRF LSP Internet Customer Slide 40 20

21 Internet in Global Routing Table Using LSPs Between s Default behavior, if Internet in global table!! On ingress : BGP next hop: Egress loopback Next hop to egress usually has label! LSP is used to reach egress P routers do not need to know Internet routes (nor run BGP) Security consequence: 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! Slide 41 Internet in Global Routing Table Using LSPs Between s Recommendations: Fully secure each router! Do not advertise IGP routes outside (General recommendation for all cores!) P routers not reachable (unless someone defaults to you) routers not reachable (possible exception: Peering ) Infrastructure ACLs to block core space: Additional security mechanism Even if someone defaults to you, he cannot reach the core Slide 42 21

22 Internet in Global Routing Table Hop-by-Hop Routing Internet Service Provider Internet CE Customer Customer P Internet P Customer Customer Customer Internet Routing Table (Global Routing Table) in a VRF Internet Customer Slide 43 Internet in 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 routers by default fully reachable from Internet Recommendations: (like before) Fully secure each router! Do not advertise IGP routes outside Infrastructure ACLs Slide 44 22

23 Internet in a VRF Internet Service Provider Internet CE Customer Customer P Internet P Customer Customer Customer Internet Routing Table (Global Routing Table) in a VRF Internet in a VRF Slide 45 Internet Customer Internet in a VRF Internet is a on the core Full separation to other s, and the core, by default! Connection Internet (for service) must be specifically configured Security consequence: P routers not reachable from anywhere! routers only reachable on outbound facing interfaces Very limited access to core Much easier to secure But!!! Routes in a VRF take more memory!! Check feasibility of putting Internet into the VRF!! Plus other restrictions, convergence, etc. Slide 46 23

24 mbehring mbehring Internet in a VRF Recommendations: Fully secure each router (you never know ) Secure external facing interfaces! Use Infrastructure ACLs for this (see earlier) (Internal i/f and P cannot be reached from outside) Slide 47 Alternatively: No Internet on the Core Pure MPLS service considered most secure But what about: CE B VRF B VRF B CE B CE A VRF A VRF A CE A Internet Service Provider however, bandwidth usually limited and some firewall / control applied Slide 48 24

25 mbehring mbehring s Private Internet Connection CE B VRF B VRF B CE B CE A VRF A VRF A CE A Internet Service Provider customer has private Internet connection Announces his address space to ISP If that includes CE- links, s are accessible from Internet If not, only transit traffic attacks very hard (limited in b/w by CE- link) Slide 49 Secure MPLS Design Inter-AS and CsC Slide 50 25

26 Standard-based L3 IP Interconnect Inter-AS/Interprovider specification in RFC4364 IETF, RFC4364, Paragraph 10 : 10A: Simple IP interconnect: The other network looks like a CE for each cross-sp 10B: Trusted MPLS interconnect: One logical connection for all s but routes still have to be maintained on provider border routers 10C: Trusted and even more scalable MPLS interconnect: Provider border routers don t have to maintain routes Current deployments 10A: Simple, low volume Interconnects between untrusted parties 10B and 10C: Mostly deployed for higher volume or when there is a shareholder relation between SPs Slide 51 Inter-AS: What are we trying to achieve? An SP should have: 100% (full) reachability to all Inter-AS s (control plane and data plane) 0% (no) reachability to s that are not shared (control plane and data plane) SP networks should be independent: Not attackable from outside (other SP, customer, Internet) Limited reachability from outside Slide 52 26

27 Inter-AS: What Are We NOT Trying to Achieve? Any Form of Separation Between Inter-AS s (Control or Data Plane) Interconnection of s is 100% No firewalling, no limitations, no sanity checks within an Inter-AS If an SP Holds Sites in an Inter-AS Set-Up, He Has Full Access to All Sites, Also on Other ASes Slide 53 From RFC 4364 Data Plane Protection 1. 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!!) Slide 54 27

28 mbehring Inter-AS: Case A VRF-VRF Back-to-Back Cust. CE1 AS 1 AS 2 1 ASBR1 2 ASBR2 Cust. CE2 LSP IP Data LSP Control plane: No signalling, no labels Data plane: IPv4 only, no labels accepted Security: as in single AS (very good) SPs are completely separated Slide 55 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 s Quite secure Potential issues: SP 1 can incorrectly connect s (like in ATM/FR) Customer can flood routing table on (this is the same issue as in single-as; solution: prefix limits) Slide 56 28

29 mbehring Inter-AS: Case B: ASBR exchange labelled v4 routes Cust. CE1 AS 1 AS 2 1 ASBR1MP-eBGP+Labels ASBR2 2 Cust. CE2 LSP label IP Data LSP Control plane: MP-eBGP, labels Data plane: Packets with one label Slide 57 Security of Inter-AS Case B: Summary Control Plane can be secured well Data Plane can also be secured Permit packets with labels that were assigned on the control plane Deny others Good: No visibility of other AS (except ASBR i/f) Slide 58 29

30 mbehring Inter-AS Case C: ASBRs Exchange loopbacks Cust. CE1 AS 1 AS 2 v4 Routes + Labels 1 ASBR1 Loopb+Labels 2 ASBR2 Cust. CE2 LSP label label IP Data Control plane: ASBR: just loopback + labels; /RR: v4 routes + labels Data plane: label + label AS1 can insert traffic into s in AS2 Only requirement: Must have LSP to correct egress Customer must trust both SPs Slide 59 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 (, RR) Potential Issues: SP1 can intrude into any on s which have a Inter-AS configured Cannot check what s underneath the label Very open architecture Acceptable for ASes controlled by the same SP Slide 60 30

31 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 flow monitoring Case B and C are okay if all ASes are in control of one SP Otherwise: Current Recommendation: Use case A Slide 61 From RFC4364: Data Plane Protection 1. 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 In CsC packets are switched through the core based on the top label The packet is not further inspected on the core Slide 62 31

32 Carrier s Carrier Cust. CE1 1 Carrier CsC CE1 Carrier s Carrier CsC 1 CsC 2 CsC CE2 Carrier 2 Cust. 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 Slide 63 Carrier s Carrier: The Interface Carrier s Carrier Carrier CsC-CE CsC- Control Plane: CsC- assigns label to CsC-CE Data Plane: CsC- only accepts packets with this label on this interface CsC- controls data plane, no spoofing possible Slide 64 32

33 Carrier s Carrier: Security Carrier is a on core Carrier s network Cannot spoof other /carrier: CsC- verifies top incoming label in data path Top label determines egress (+interface, +prefix) Can mess up his own! Basically like in a single AS Slide 65 Carrier s Carrier: Summary Can be secured well Carrier has on Carrier s Carrier MPLS cloud Carrier cannot intrude into other s. End customer must trust both SPs. Slide 66 33

34 L2 Security Slide 67 Watch out for Layer 2 Security!! ASBR IXP ASBR 3rd party in same VLAN (e.g. IXP) can: insert spoofed packets into s (cannot be prevented today technically!!) Do layer 2 attacks to do man-in-the-middle (could be mostly prevented, but is often not done) Recommendation: Inter-AS and CsC connections only on private peerings!! Slide 68 34

35 What the Standards Say RFC 3985 (PWE3 Architecture) PWE3 provides no means of protecting the integrity, confidentiality, or delivery of the native data units. The use of PWE3 can therefore expose a particular environment to additional security threats. Assumptions that might be appropriate when all communicating systems are interconnected via a point-to-point or circuit-switched network may no longer hold when they are interconnected with an emulated wire carried over some types of PSN. Note: This talks only about customer security! Slide 69 Virtual Private Wire Service (VPWS) Overview Attachment circuit Private Wire Attachment circuit PSN Tunnel CE VPWS P P P VPWS CE Directed LDP In VPWS: Packets coming in on one side, are blindly forwarded to the other. Low security exposure Slide 70 35

36 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 Slide 71 VPLS Security Threats VLAN Hopping MAC Attacks DHCP Attacks ARP Attack Spoofing Attacks Other Attacks Slide 72 36

37 Best Practices for L2 Security Always use use a dedicated VLAN VLAN ID ID for for Trunk Trunk Ports Ports Disable unused ports ports and and put put them them in in an an unused VLAN VLAN Use Use Secure Transmission when when managing Switches (SSH, (SSH, OOB, OOB, Permit Permit Lists) Lists) Deploy Port Port Security Set Set all all host host ports ports to to Non Non Trunking ALWAYS use use a dedicated VLAN VLAN for for Trunk Trunk Ports Ports Avoid Avoid using using VLAN VLAN Have Have a plan plan for for ARP ARP Security issues issues and and implement it!!! it!!! Use Use SNMP SNMP V3 V3 to to secure secure SNMP SNMP transmission Use Use STP STP Attack Attack mitigation Use Use MD5 MD5 Authentication for for VTP VTP Plan Plan for for and and implement DHCP DHCP Attack Attack mitigation Use Use Private VLAN s to to better better secure secure guest guest VLAN s Use Use and and implement 802.1x 802.1x to to protect entry entry into into your your network Consider using using VACL s to to limit limit access to to key key network resources Slide 73 Exposure to Customer Must trust provider Protocols carried over PW might not be designed for high-grade security Easy to break security (integrity, confidentiality, availability) Example: VRRP / HSRP Depends on what you do with PW Make sure you understand what you run on top of PW No general answer possible Slide 74 37

38 Exposure to SP s do not analyse L2 frames s just encapsulate and forward L2 frames Also applies to L2 signalling Therefore: s cannot be attacked on control plane (there is none to the outside) s may be overwhelmed on data plane (too much traffic to forward DoS) This threat is identical to any other network Correct provisioning solves this issue Slide 75 Attacking an MPLS Network Slide 76 38

39 Threat Model Security Threats Malicious user behavior Unintended human error, misconfiguration, protocol side effects Security Vulnerability Denial of Service (DoS) attacks Intrusion attacks Undesired MPLS protocol side effects MPLS device misconfiguration Description MPLS network resources become unavailable to authorized users MPLS network resources become available to unauthorized users MPLS network resources become available to unauthorized users as a result of unintended device misconfiguration or unexpected protocol side effects Slide 77 Security Threats CE P ASBR ASBR P CE Malicious user behavior Unintended human error, misconfiguration, protocol side effects MPLS Service Edge ( Router) Control plane DoS attacks (ie:bgp) Unauthorized control plane access (ie: SNMP,) MPLS Core (P routers) Control plane DoS attacks (ie: LDP) Unintended P router access due to Unintended Route incorrect/missing access leakage due to VRF misconfiguration and/or IGP route control configuration router access due to distribution incorrect/missing access traffic misforwarding due to configuration unexpected (rare) Slide 78 protocol side effects MPLS Inter-AS Edge (ASBR) Unauthorized /IGP access via label spoofing Control plane DoS attack Unintended Route leakage due to VRF misconfiguration or incorrect route distribution ASBR router access due to incorrect/missing access configuration 39

40 Ways to Attack Intrusion : Get un-authorized access Theory: Not possible (as shown before) Practice: Depends on: - Vendor implementation - Correct configuration and management Denial-of-Service : Deny access of others Much more interesting No Trust? Use IPSec Between CEs! Slide 79 DoS Against MPLS DoS is about Resource Starvation, one of: Bandwidth CPU Memory (buffers, routing tables ) In MPLS, we have to examine: CE Rest is the same as in other networks Slide 80 40

41 Attacking a CE from MPLS (Other ) Is the CE reachable from the MPLS side? only if this is an Internet CE, otherwise not (CE- addressing is part of!) For Internet CEs: Same security rules apply as for any other access router MPLS Hides -CEs: Secure! Internet CEs: Same as In Other Networks Slide 81 Attacking a CE- Line Also depends on reachability of CE or the behind it Only an issue for lines to Internet-CEs Same considerations as in normal networks If CE- line shared ( and Internet): DoS on Internet may influence! MPLS Hides -CEs: Secure! Internet CEs: Same as In Other Networks Slide 82 41

42 Attacking a Router CE1 IP(CE1) IP(; fa0) IP(; l0) IP(P) VRF CE1 CE2 IP(CE2) IP(; fa1) VRF CE2 Attack Points VRF Internet Only Visible: Your Interface and Interfaces of Internet CEs Slide 83 DoS Attacks to Can Come from Other, connected to same Internet, if carries Internet VRF Possible Attacks: Resource starvation on Too many routing updates, too many SNMP requests, small servers Has to Be Secured and Can Be Secured! Slide 84 42

43 IPsec and MPLS Slide 85 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! Slide 86 43

44 Where to Apply IPsec CE CE IPsec CE-CE IPsec CE- IPsec - Application: Remote Access into Application: Security Application: Special Cases Slide 87 Applications of - IPSec If core is not pure MPLS, but IP based Standard 4364 requires MPLS core, - IPSec does not Alternative: MPLS in IP/GRE/L2TPv3, but with - IPSec spoofing impossible Protect against misbehaving transit nodes Protection against sniffing on core lines Slide 88 44

45 draft-ietf-l3vpn-ipsec txt: - IPsec in MPLS s Normal RFC 4364 Instead of LSPs between s, use IPsec Packets on the core instead of this: Look like this: label IPsec Header IP Data Careful: Does not encrypt CE-: Most vulnerable!! Work in progress, pretty stable IP Data Actually, the Labelled Packet Is First IP/GRE Encapsulated, Then Put in IPsec Transport Mode; IPsec Requires an IP Packet!! Slide 89 - IPSec: How It Works BGP + Ext. Community 1. Egress Signals IPSec Policy Per Prefix IPSec 2. Ingress s Establish IPSec Tunnel for Prefix Not defined in draft: How to establish IPSec tunnel Slide 90 45

46 IPsec: - vs. CE-CE Hacker wants to read traffic insert traffic into join a DoS a /the core IPsec CE-CE Protects Fully Protects Fully Protects Fully Doesn t Protect IPsec - Protects Partially Protects Partially Doesn t Protect Doesn t Protect Slide 91 Ongoing Standardizations Work Slide 92 46

47 Relevant Standardization IETF L3 WG: Working on Layer 3 architectures, such as MPLS IP s, IP s using virtual routers, and IPsec s. IETF L2 WG: Working on Layer 2 architectures, such as VPLS and VPWS Slide 93 Summary Slide 94 47

48 MPLS doesn t provide: Protection against mis-configurations in the core Protection against attacks from within the core Confidentiality, authentication, integrity, antireplay -> Use IPsec if required Customer network security Slide 95 Summary MPLS s can be secured as well as ATM/FR s Security depends on correct architecture, operation and implementation MPLS backbones can be more secure than normal IP backbones Core not accessible from outside Separate control and data plane Key: security Advantage: Only -CE interfaces accessible from outside Makes security easier than in normal networks Slide 96 48

49 References MPLS Security ISBN RFC4381 Analysis of MPLS Security RFC2082 RIP-2 MD5 Authentication RFC2154 OSPF with Digital Signatures RFC2385 Protection of BGP Sessions via the TCP MD5 Signature Option RFC3013 Recommended Internet Service Provider Security Services and Procedures RFC2196 Site Security Handbook Garnter research note M : "MPLS Networks: Drivers Beat Inhibitors in 2003"; 10 Feb 2003 MPLS and Architectures ISBN MPLS Security ISBN Slide 97 For More Information For questions, utilize the MFA Forum Message Board Website: Slide 98 49

50 Thank you for attending the MPLS Security Tutorial Slide 99 50