Transcript
Introduction
The MFA Forum is an international, industry-wide, nonprofit association of telecommunications, networking, and other companies focused on advancing the deployment of multi-vendor, multiservice packet-based networks, associated applications, and interworking solutions
Formed in July 2005 by merging the ATM Forum andthe MPLS & Frame Relay Alliance
38 member companies
Three primary committees Technical Committee
Applications and Deployment Working Group
Architecture Working Group
ATM Control Signaling Working Group
Interoperability Working Group
Interworking and Frame Relay Working Group
Marketing Awareness and Education Committee
Service Provider Council
MPLS User Group Enterprises, Carriers
Developed by:
Michael Behringer Cisco Systems
Monique Morrow Cisco Systems
Contributors:
Victoria Fineberg DISA
Ross Callon Juniper Networks
David Christophe Alcatel-Lucent
Advanced level
Expected: Basic understanding of MPLS protocols and how MPLS VPNs operate
Target Audience: Service providers Network operators and designers Network security engineers Technical focus
Customer buys “Internet Service”: Packets from SP are not trusted Perception: Need for firewalls, etc
Customer buys a “VPN Service”: Packets from SP are trusted Perception: Few or no further security measures
required
Understand how secure MPLS VPNs* are And what IPsec offers in addition
Best practices on how to secure General MPLS VPN Inter-provider VPN Specific cases (Internet connectivity, etc)
Examples are for IPv4 VPNs
Also applicable to IPv6 VPN
* Here: MPLS VPN = RFC 4364 (old “2547bis”)
Analysis of the MPLSVPN Architecture (RFC 4364)
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
Break One, and All Security Is Gone!
Secure MPLS VPN Design ― General Security Best Practices
Don’t let packets into the core(for MPLS: PE routers)
No way to attack core, exceptthrough routing, thus:
Secure the routing protocol
Neighbor authentication, maximum routes, dampening,…
Design for transit traffic
QoS to give VPN priorityover Internet Choose correct router
for bandwidth Separate PEs where necessary
Operate Securely
Still “Open”: RoutingProtocol
Only AttackVector: Transit Traffic
Now OnlyInsider Attacks Possible
Avoid Insider Attacks
In order of security preference (for both CE and PE):
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)
“deny ip any <VRF address space on the PE>” Exception: routing protocol from host to host
Idea: no traffic to PE/P you can’t attack
Prevents intrusions 100%
DoS: very hard, but traffic over router theoretically enables DoS
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
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
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
If dynamic routing: Use authentication (MD5)
Maximum number of routes per peer (only BGP)
Separation of CE-PE links where possible(Internet/VPN)
LDP authentication (MD5)
VRF: Define maximum number of routes
Note: Overall security depends on weakest link!
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…)
Security depends on SP!
Employee can make mistake, or malicious misconfiguration
Potential Security hole: If PE compromised, VPNs might be insecure
Cannot *prevent* all misconfigs Need to operationally control this
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
Perfect Separation of VPNs No intrusions possible
Perfect Separation of the Core from VPNs Again, no intrusions possible
But there is one remaining issue…
PE Routers Should Contain Only VRFs of the Same Security Level; Example:
To Internet
Level 0: Internet
Level 1: VPN
customers
(Level 2: Mission critical infrastructure)
Note: This is negotiable: Shared Internet/VPN PE may be acceptable if price and conditions are right
Separation: +++
DoS resistance: +++
Cost: $$$ (two lines and two PEs: expensive!)
(eg FR)
Separation:
DoS resistance: + (DoS might affect VPN on PE, attachment circuit, CE)
Cost:
Extranet means: Connecting VPNs Route Targets define where traffic is going
Usually firewalling required to restrict
connectivity and maintain separation
Secure MPLS VPN Design ― Internet Access
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
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!
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) 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
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
Internet is a VPN on the core Full separation to other VPNs, and the core, bydefault!
“Connection” Internet ↔ VPN (for service) must bespecifically configured
Security consequence: P routers not reachable from anywhere! PE 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 43
Recommendations:
Fully secure each router (you never know…)
Secure external facing PE interfaces! Use Infrastructure ACLs for this (see earlier) (Internal PE i/f and P cannot be reached from
outside)
Pure MPLS VPN service considered “most secure”
But what about:
Secure MPLS VPN Design
― Inter-AS and CsC
An SP should have: 100% (full) reachability to all Inter-AS VPNs (control plane and data plane)
0% (no) reachability to VPNs 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
Any Form of Separation Between Inter-AS VPNs (Control or Data Plane)
Interconnection of VPNs is 100%
No firewalling, no limitations, no sanity checks within an Inter-AS VPN
Control plane: No signalling, no labels
Data plane: IPv4 only, no labels accepted
Security: as in single AS (very good)
SPs are completely separated
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 incorrectly connect VPNs (like in ATM/FR)
Customer can flood routing table on PE (this is the
same issue as in single-AS; solution: prefix limits)
Control plane: MP-eBGP, labels
Data plane: Packets with one label
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)
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
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
Same principles as in normal MPLS
Customer trusts carrier who trusts carrier
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
Carrier is a VPN on core Carrier’s network
Cannot spoof other VPN/carrier: CsC-PE verifies top incoming label in data path Top label determines egress PE (+interface, +prefix)
Can mess up his own VPN!
Basically like in a single AS
L2VPN Security
In VPWS: Packets coming in on one side, areblindly forwarded to the other Æ Low security exposure
Network behaves as a switch Spanning Tree MAC address learning ARP, etc
Æ Examine threats to a switch to understand VPLS security
VLAN “Hopping”
MAC Attacks
DHCP Attacks
ARP Attack
Spoofing Attacks
Other Attacks
Best Practices for L2 Security
1
Always use a dedicated VLAN ID for Trunk Ports
Disable unused ports and put them in an unused VLAN
Use Secure Transmission when managing Switches (SSH, OOB, Permit
Deploy Port Security
Set all host ports to Non Trunking
ALWAYS use a dedicated VLAN for Trunk Ports
Avoid using VLAN 1
Have a plan for ARP Security issues and implement it!!!
Use SNMP V3 to secure SNMP transmission
10
10 Use STP Attack mitigation
11
11 Use MD5 Authentication for VTP
12
12 Plan for and implement DHCP Attack mitigation
13
13 Use Private VLAN’s to better secure guest VLAN’s
14
14 Use and implement 8021x to protect entry into your network
15
15 Consider using VACL’s to limit access to key network resources…
IPsec and MPLS
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!
Normal RFC 4364
Instead of LSPs between PEs, use IPsec
Packets on the core instead of this:
PE label VPN IP Data
Actually, the Labelled Packet Is First IP/GR
Look like this:
Encapsulated, Then
Put in IPsec Transport
Mode; IPsec Requires
an IP Packet!!
IPsec Header VPN IP Data
Careful: Does not encrypt CE-PE: Most vulnerable!!
Work in progress, pretty stable
Hacker wants to… …read VPN traffic …insert traffic into VPN …join a VPN …DoS a VPN/the core
IPsec CE-CE
Protects Fully
Protects Fully
Protects Fully
IPsec PE-PE
Protects Partially
Protects Partially
Ongoing Standardizations Work
IETF L3VPN WG: Working on Layer 3 VPN architectures, such as MPLS IP
VPNs, IP VPNs using virtual routers, and IPsec VPNs http://wwwietforg/htmlcharters/l3vpn-charterhtml
IETF L2VPN WG: Working on Layer 2 VPN architectures, such as VPLS and
VPWS http://wwwietforg/htmlcharters/l2vpn-charterhtml
Summary
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
MPLS VPNs can be secured as well as ATM/FR VPNs
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: PE security Advantage: Only PE-CE interfaces accessiblefrom outside
Makes security easier than in “normal”
networks
MPLS VPN Security ISBN 1587051834
RFC4381 Analysis of MPLS VPN 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 SecurityServices and Procedures
RFC2196 Site Security Handbook
Garnter research note M-17-1953: \"MPLS Networks: Drivers Beat Inhibitors in 2003\"; 10 Feb 2003
MPLS and VPN Architectures ISBN 1587050021
MPLS VPN Security ISBN 1587051834
http://wwwmfaforumorg
http://wwwietforg
http://wwwituint
http://wwwmplsrccom
For questions, utilize the MFA Forum Message Board Website: http://wwwmfaforumorg/board/
Thank you for attending the
MPLS VPN Security Tutorial
