idnits 2.17.1 draft-behringer-mpls-security-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 979. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 956. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 963. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 969. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([10]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 503: '... an invalid incoming label, it MUST be...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 21, 2004) is 7127 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 2082 (ref. '2') (Obsoleted by RFC 4822) -- Obsolete informational reference (is this intentional?): RFC 2385 (ref. '5') (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 2547 (ref. '6') (Obsoleted by RFC 4364) -- Obsolete informational reference (is this intentional?): RFC 2858 (ref. '7') (Obsoleted by RFC 4760) -- Obsolete informational reference (is this intentional?): RFC 3682 (ref. '9') (Obsoleted by RFC 5082) == Outdated reference: A later version (-03) exists of draft-ietf-l3vpn-security-framework-02 Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Behringer 2 Internet-Draft Cisco Systems Inc 3 Expires: April 21, 2005 October 21, 2004 5 Analysis of the Security of BGP/MPLS IP VPNs 6 draft-behringer-mpls-security-10.txt 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions 11 of section 3 of RFC 3667. By submitting this Internet-Draft, each 12 author represents that any applicable patent or other IPR claims of 13 which he or she is aware have been or will be disclosed, and any of 14 which he or she become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 21, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). 39 Abstract 41 This document analyses the security of the BGP/MPLS IP VPN 42 architecture that is described in RFC 2547bis [10], for the benefit 43 of service providers and VPN users. 45 The analysis shows that BGP/MPLS IP VPN networks can be as secure as 46 traditional layer-2 VPN services using ATM or Frame Relay. 48 Table of Contents 50 1. Scope and Introduction . . . . . . . . . . . . . . . . . . . . 3 51 2. Security Requirements of VPN Networks . . . . . . . . . . . . 4 52 2.1 Address Space, Routing, and Traffic Separation . . . . . . 4 53 2.2 Hiding the Core Infrastructure . . . . . . . . . . . . . . 4 54 2.3 Resistance to Attacks . . . . . . . . . . . . . . . . . . 5 55 2.4 Impossibility of Label Spoofing . . . . . . . . . . . . . 5 56 3. Analysis of BGP/MPLS IP VPN Security . . . . . . . . . . . . . 7 57 3.1 Address Space, Routing, and Traffic Separation . . . . . . 7 58 3.2 Hiding of the BGP/MPLS IP VPN Core Infrastructure . . . . 8 59 3.3 Resistance to Attacks . . . . . . . . . . . . . . . . . . 10 60 3.4 Label Spoofing . . . . . . . . . . . . . . . . . . . . . . 12 61 3.5 Comparison with ATM/FR VPNs . . . . . . . . . . . . . . . 12 62 4. Security of advanced BGP/MPLS IP VPN architectures . . . . . . 14 63 4.1 Carriers' Carrier (CsC) . . . . . . . . . . . . . . . . . 14 64 4.2 Inter-provider backbones . . . . . . . . . . . . . . . . . 15 65 5. What BGP/MPLS IP VPNs Do Not Provide . . . . . . . . . . . . . 18 66 5.1 Protection against Misconfigurations of the Core and 67 Attacks 'within' the Core . . . . . . . . . . . . . . . . 18 68 5.2 Data Encryption, Integrity and Origin Authentication . . . 18 69 5.3 Customer Network Security . . . . . . . . . . . . . . . . 19 70 6. Layer 2 security considerations . . . . . . . . . . . . . . . 20 71 7. Summary and Conclusions . . . . . . . . . . . . . . . . . . . 22 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 73 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 74 10. Informative References . . . . . . . . . . . . . . . . . . . 24 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 25 76 Intellectual Property and Copyright Statements . . . . . . . . 26 78 1. Scope and Introduction 80 As MPLS (Multi Protocol Label Switching) is becoming a more 81 wide-spread technology for providing IP VPN (virtual private network) 82 services, the security of the BGP/MPLS IP VPN architecture is of 83 increasing concern to service providers and VPN customers. This 84 document gives an overview of the security of the BGP/MPLS IP VPN 85 architecture that is described in RFC 2547bis [10], and compares it 86 with the security of traditional layer-2 services such as ATM or 87 Frame Relay. 89 The term "MPLS core" is defined for this document as the set of 90 provider edge (PE) and provider (P) routers that provide a BGP/MPLS 91 IP VPN service, typically under the control of a single service 92 provider. This document assumes that the MPLS core network is 93 trusted and secure. Thus, it does not address basic security 94 concerns such as securing the network elements against unauthorised 95 access, misconfigurations of the core, or attacks internal to the 96 core. A customer that does not wish to trust the service provider 97 network must use additional security mechanisms such as IPsec over 98 the MPLS infrastructure. 100 This document analyses only the security features of BGP/MPLS IP 101 VPNs, not the security of routing protocols in general. IPsec 102 technology is also not covered, except to highlight the combination 103 of MPLS VPNs with IPsec. 105 The overall security of a system has three aspects: the architecture, 106 the implementation, and the operation of the system. Security issues 107 can exist in any of these aspects. This document analyses only the 108 architectural security of BGP/MPLS IP VPNs, not implementation or 109 operational security issues. 111 This document is targeted at technical staff of service providers and 112 enterprises. Knowledge of the basic BGP/MPLS IP VPN architecture as 113 described in RFC 2547bis [10] is required to understand this 114 document. For specific Layer 3 VPN terminology and reference models 115 refer to document draft-ietf-l3vpn-security-framework [11]. 117 Section 2 of this document specifies the typical VPN requirements a 118 VPN user might have, and section 3 analyses how RFC 2547bis [10] 119 addresses these requirements. Section 4 discusses specific security 120 issues of multi-AS MPLS architectures, and section 5 lists security 121 features that are not covered by this architecture and therefore need 122 to be addressed separately. Section 6 highlights potential security 123 issues on layer 2 which might impact the overall security of a 124 BGP/MPLS IP VPN service. The findings of this document are 125 summarized in section 7. 127 2. Security Requirements of VPN Networks 129 Both service providers offering any type of VPN services and 130 customers using them have specific demands for security. Mostly they 131 compare MPLS-based solutions with traditional layer 2-based VPN 132 solutions such as Frame Relay and ATM, since these are widely 133 deployed and accepted. This section outlines the typcial security 134 requirements for VPN networks. The following section discusses if 135 and how BGP/MPLS IP VPNs address these requirements, for both the 136 MPLS core and the connected VPNs. 138 2.1 Address Space, Routing, and Traffic Separation 140 Non-intersecting layer 3 VPNs of the same VPN service are assumed to 141 have independent address spaces. For example, two non-intersecting 142 VPNs may each use the same 10/8 network addresses without conflict. 143 In addition, traffic from one VPN must never enter another VPN. This 144 implies separation of routing protocol information, so that routing 145 tables must also be separate per VPN. Specifically: 146 o Any VPN must be able to use the same address space as any other 147 VPN. 148 o Any VPN must be able to use the same address space as the MPLS 149 core. 150 o Traffic, including routing traffic, from one VPN must never flow 151 to another VPN. 152 o Routing information, as well as distribution and processing of 153 that information, for one VPN instance must be independent from 154 any other VPN instance. 155 o Routing information, as well as distribution and processing of 156 that information, for one VPN instance must be independent from 157 the core. 159 From a security point of view, the basic requirement is to prevent 160 packets destined to a host a.b.c.d within a given VPN reaching a host 161 with the same address in another VPN or in the core, and to prevent 162 routing packets to another VPN even if it does not contain that 163 destination address. 165 Confidentiality, as defined in the L3VPN Security Framework [11], is 166 a requirement that goes beyond simple isolation of VPNs and provides 167 protection against eavesdropping on any transmission medium. 168 Encryption is the mechanism used to provide confidentiality. This 169 document considers confidentiality an optional VPN requirement, since 170 many existing VPN deployments do not encrypt transit traffic. 172 2.2 Hiding the Core Infrastructure 174 The internal structure of the core network (MPLS PE and P elements) 175 should not be externally visible. Whilst breaking this requirement 176 is not a security problem in itself, many service providers believe 177 it is advantageous if the internal addresses and network structure 178 are hidden from the outside world. An argument is that DoS attacks 179 against a core router are much easier to carry out if an attacker 180 knows the router addresses. Addresses can always be guessed, but 181 attacks are more difficult if addresses are not known. The core 182 should be as invisible to the outside world as a comparable layer 2 183 infrastructure (e.g., frame relay, ATM). Core network elements 184 should also not be accessible from within a VPN. 186 Security should never rely entirely on obscurity, i.e., the hiding of 187 information. Services should be equally secure if the implementation 188 is known. However, there is a strong market perception that hiding 189 of details is advantageous. This point addresses that market 190 perception. 192 2.3 Resistance to Attacks 194 There are two basic types of attacks: Denial-of-Service (DoS) 195 attacks, where resources become unavailable to authorised users, and 196 intrusions, where resources become available to un-authorised users. 197 BGP/MPLS IP VPN networks must provide at least the same level of 198 protection against both forms of attack as current layer 2 networks. 200 For intrusions there are two fundamental ways to protect the network: 201 firstly, to harden protocols that could be abused (e.g., Telnet into 202 a router), secondly to make the network as inaccessible as possible. 203 This is achieved by a combination of packet filtering / firewalling 204 and address hiding, as discussed above. 206 DoS attacks are easier to execute, since a single known IP address 207 might be enough information to attack a machine. This can be done 208 using normal "permitted" traffic, but using higher than normal packet 209 rates, so that other users cannot access the targeted machine. The 210 only way to be invulnerable to this kind of attack is to make sure 211 that machines are not reachable, again by packet filtering and 212 optionally by address hiding. 214 This document concentrates on protecting the core network against 215 attacks from the "outside", i.e., the Internet and connected VPNs. 216 Protection against attacks from the "inside", i.e., an attacker who 217 has logical or physical access to the core network, is not discussed 218 here. 220 2.4 Impossibility of Label Spoofing 222 Assuming the address and traffic separation discussed above, an 223 attacker might try to access other VPNs by inserting packets with a 224 label that he does not "own". This could be done from the outside, 225 i.e., another customer edge (CE) router or from the Internet, or from 226 within the MPLS core. The latter case (from within the core) will 227 not be discussed, since we assume that the core network is provided 228 securely. Should protection against an insecure core be required, it 229 is necessary to use security protocols such as IPsec across the MPLS 230 infrastructure, at least from CE to CE, since the PEs belong to the 231 core. 233 Depending on the way that CE routers are connected to PE routers, it 234 might be possible to intrude into a VPN which is connected to the 235 same PE, using layer 2 attack mechanisms such as 802.1Q - label 236 spoofing, or ATM VPI/VCI spoofing. Layer 2 security issues will be 237 discussed in section 6. 239 It is required that VPNs cannot abuse the MPLS label mechanisms or 240 protocols to gain un-authorised access to other VPNs or the core. 242 3. Analysis of BGP/MPLS IP VPN Security 244 In this section the BGP/MPLS IP VPN architecture is analysed with 245 respect to the security requirements listed above. 247 3.1 Address Space, Routing, and Traffic Separation 249 BGP/MPLS allows distinct IP VPNs to use the same address space, which 250 can also be private address space (RFC 1918 [1]). This is achieved 251 by adding a 64 bit route distinguisher (RD) to each IPv4 route, 252 making VPN-unique addresses also unique in the MPLS core. This 253 "extended" address is also called a "VPN-IPv4 address". Thus 254 customers of a BGP/MPLS IP VPN service do not need to change their 255 current addressing plan. 257 Each PE router maintains a separate Virtual Routing and Forwarding 258 instance (VRF) for each connected VPN. A VRF includes the addresses 259 of that VPN as well as the addresses of the PE routers with which the 260 CE routers are peering. All addresses of a VRF, including these PE 261 addresses, belong logically to the VPN and are accessible from the 262 VPN. The fact that PE addresses are accessible to the VPN is not an 263 issue if static routing is used between the PE and CE routers, since 264 packet filters can be deployed to block access to all addresses of 265 the VRF on the PE router. If dynamic routing protocols are used, the 266 CE routers need to have the address of the peer PE router in the core 267 configured. In an environment where the service provider manages the 268 CE routers as CPE, this can be invisible to the customer. The 269 address space on the CE-PE link (including the peering PE address) is 270 considered part of the VPN address space. Since address space can 271 overlap between VPNs, the CE-PE link addresses can overlap between 272 VPNs. For practical management considerations SPs typically address 273 CE-PE links from a global pool, maintaining uniqueness across the 274 core. 276 Routing separation between VPNs can also be achieved. Each VRF is 277 populated with routes from one VPN through statically configured 278 routes or through routing protocols that run between the PE and CE 279 router. Since each VPN is associated with a separate VRF there is no 280 interference between VPNs on the PE router. 282 Across the core to the other PE routers separation is maintained with 283 unique VPN identifiers in multi-protocol BGP, the Route 284 Distinguishers (RD). VPN routes including the RD are exclusively 285 exchanged between PE routers by Multi-Protocol BGP (MP-BGP, (RFC 2858 286 [7]) across the core. These BGP routing updates are not 287 re-distributed into the core, but only to the other PE routers, where 288 the information is kept again in VPN specific VRFs. Thus routing 289 across an BGP/MPLS network is separate per VPN. 291 On the data plane traffic separation is achieved by the ingress PE 292 pre-pending a VPN-specific label to the packets. The packets with 293 the VPN labels are sent through the core to the egress PE, where the 294 VPN label is used to select the egress VRF. 296 Given the addressing, routing and traffic separation across an 297 BGP/MPLS IP VPN core network, it can be assumed that this 298 architecture offers in this respect the same security as a layer-2 299 VPN. It is not possible to intrude from a VPN or the core into 300 another VPN unless this has been explicitly configured. 302 If and when confidentiality is required, it can be achieved in 303 BGP/MPLS IP VPNs by overlaying encryption services over the network. 304 However, encryption is not a standard service on BGP/MPLS IP VPNs. 305 See also section 5.2. 307 3.2 Hiding of the BGP/MPLS IP VPN Core Infrastructure 309 Service Providers and end-customers do not normally want their 310 network topology revealed to the outside. This makes attacks more 311 difficult to execute: If an attacker doesn't know the address of a 312 victim he can only guess the IP addresses to attack. Since most DoS 313 attacks don't provide direct feedback to the attacker it would be 314 difficult to attack the network. It has to be mentioned specifically 315 that information hiding as such does not provide security. However, 316 in the market this is a perceived requirement. 318 With a known IP address a potential attacker can launch a DoS attack 319 more easily against that device. Therefore the ideal is to not 320 reveal any information about the internal network to the outside 321 world. This applies to the customer network and the core. A number 322 of additional security measures have to be also taken, most of all 323 extensive packet filtering. 325 For security reasons it is recommended for any core network to filter 326 packets from the "outside" (Internet or connected VPNs) destined to 327 the core infrastructure. This makes it very hard to attack the core, 328 although some functionality such as pinging core routers will be 329 lost. Traceroute across the core will still work, since it addresses 330 a destination outside the core. 332 MPLS does not reveal unnecessary information to the outside, not even 333 to customer VPNs. The addressing of the core can be done with 334 private addresses (RFC 1918 [1]) or public addresses. Since the 335 interface to the VPNs as well as the Internet is BGP, there is no 336 need to reveal any internal information. The only information 337 required in the case of a routing protocol between PE and CE is the 338 address of the PE router. If no dynamic routing is required, static 339 routing on unnumbered interfaces can be configured between the PE and 340 CE. With this measure the BGP/MPLS IP VPN core can be kept 341 completely hidden. 343 Customer VPNs must advertise their routes to the BGP/MPLS IP VPN core 344 (dynamically or statically), to ensure reachability across their VPN. 345 In some cases VPN users prefer that the service provider have no 346 visibility of the addressing plan of the VPN. The following has to 347 be noted: Firstly, the information known to the core is not about 348 specific hosts, but networks (routes); this offers a degree of 349 abstraction. Secondly, in a VPN-only BGP/MPLS IP VPN network (no 350 Internet access) this is equal to existing layer-2 models, where the 351 customer has to trust the service provider. Also in a FR or ATM 352 network routing and addressing information about the VPNs can be seen 353 on the core network. 355 In a VPN service with shared Internet access, the service provider 356 will typically announce the routes of customers who wish to use the 357 Internet to his upstream or peer providers. This can be done 358 directly if the VPN customer uses public address space, or via NAT 359 (Network Address Translation) to obscure the addressing information 360 of the customers' networks. In either case the customer does not 361 reveal more information would be revealed by a general Internet 362 service. Core information will not be revealed, except for the 363 peering address(es) of the PE router(s) that hold(s) the peering with 364 the Internet. These addresses must be secured as in a traditional IP 365 backbone. 367 In summary, in a pure MPLS-VPN service, where no Internet access is 368 provided, information hiding is as good as on a comparable FR or ATM 369 network. No addressing information is revealed to third parties or 370 the Internet. If a customer chooses to access the Internet via the 371 BGP/MPLS IP VPN core he will have to reveal the same information as 372 required for a normal Internet service. NAT can be used for further 373 obscurity. Being reachable from the Internet automatically exposes a 374 customer network to additional security threats. Appropriate 375 security mechanisms have to be deployed such as firewalls and 376 intrusion detection systems. This is true for any Internet access, 377 over MPLS or direct. 379 A BGP/MPLS IP VPN network with no interconnections to the Internet 380 has security equal to that of FR or ATM VPN networks. With an 381 Internet access from the MPLS cloud the service provider has to 382 reveal at least one IP address (of the peering PE router) to the next 383 provider, and thus to the outside world. 385 3.3 Resistance to Attacks 387 Section 3.1 shows that it is impossible to directly intrude into 388 other VPNs. Another possibility is to attack the MPLS core and try 389 to attack other VPNs from there. As shown above it is impossible to 390 address a P router directly. The only addresses reachable from a VPN 391 or the Internet are the peering addresses of the PE routers. Thus 392 there are two basic ways the BGP/MPLS IP VPN core can be attacked: 393 1. By attacking the PE routers directly. 394 2. By attacking the signaling mechanisms of MPLS (mostly routing) 396 To attack an element of an BGP/MPLS IP VPN network it is first 397 necessary to know the address of the element. As discussed in 398 section 3.2 the addressing structure of the BGP/MPLS IP VPN core is 399 hidden from the outside world. Thus an attacker cannot know the IP 400 address of any router in the core to attack. The attacker could 401 guess addresses and send packets to these addresses. However, due to 402 the address separation of MPLS each incoming packet will be treated 403 as belonging to the address space of the customer. Thus it is 404 impossible to reach an internal router, even by guessing IP 405 addresses. There is only one exception to this rule, which is the 406 peer interface of the PE router. This address of the PE is the only 407 attack point from the outside (a VPN or Internet). 409 The routing between a VPN and the BGP/MPLS IP VPN core can be 410 configured two ways: 411 1. Static; in this case the PE routers are configured with static 412 routes to the networks behind each CE, and the CEs are configured 413 to statically point to the PE router for any network in other 414 parts of the VPN (mostly a default route). There are two 415 sub-cases: The static route can point to the IP address of the PE 416 router, or to an interface of the CE router (e.g., serial0). 417 2. Dynamic; a routing protocol (e.g., RIP, OSPF, BGP) is used to 418 exchange routing information between the CE and PE at each 419 peering point. 421 In the case of a static route, which points to an interface, the CE 422 router doesn't need to know any IP addresses of the core network or 423 even of the PE router. This has the disadvantage of needing a more 424 extensive (static) configuration, but is the most secure option. In 425 this case it is also possible to configure packet filters on the PE 426 interface to deny any packet to the PE interface. This protects the 427 router and the whole core from attack. 429 In all other cases, each CE router needs to know at least the router 430 ID (RID, i.e., peer IP address) of the PE router in the core, and 431 thus has a potential destination for an attack. One could imagine 432 various attacks on various services running on a router. In 433 practice, access to the PE router over the CE-PE interface can be 434 limited to the required routing protocol by using ACLs (access 435 control lists). This limits the point of attack to one routing 436 protocol, for example BGP. A potential attack could be to send an 437 extensive number of routes, or to flood the PE router with routing 438 updates. Both could lead to a denial-of-service, however, not to 439 unauthorised access. 441 To reduce this risk it is necessary to configure the routing protocol 442 on the PE router to operate as securely as possible. This can be 443 done in various ways: 444 o By accepting only routing protocol packets, and only from the CE 445 router. The inbound ACL on each CE interface of the PE router 446 should allow only routing protocol packets from the CE to the PE. 447 o By configuring MD-5 authentication for routing protocols. This is 448 available for BGP (RFC 2385 [5]), OSPF (RFC 2154 [3]) and RIP2 449 (RFC 2082 [2]) for example. This avoids packets being spoofed 450 from other parts of the customer network than the CE router. It 451 requires the service provider and customer to agree on a shared 452 secret between all CE and PE routers. It is necessary to do this 453 for all VPN customers. It is not sufficient to do this only for 454 the customer with the highest security requirements. 455 o By configuring parameters of the routing protocol to further 456 secure this communication. For example, the rate of routing 457 updates should be restricted where possible (in BGP through 458 damping); a maximum number of routes accepted per VRF and per 459 routing neighbor should be configured where possible; and the 460 Generalized TTL Security Mechanism (GTSM; RFC 3682 [9]) should be 461 used for all supported protocols. 463 In summary, it is not possible to intrude from one VPN into other 464 VPNs, or the core. However, it is theoretically possible to attack 465 the routing protocol port to execute a DoS attack against the PE 466 router. This in turn might have negative impact on other VPNs on 467 this PE router. For this reason PE routers must be extremely well 468 secured, especially on their interfaces to CE routers. ACLs must be 469 configured to limit access only to the port(s) of the routing 470 protocol, and only from the CE router. Further routing protocols 471 security mechanisms such as MD5 authentication, maximum prefix limits 472 and TTL security mechanisms should be used on all PE-CE peerings. 473 With all these security measures the only possible attack is a DoS 474 attack against the routing protocol itself. BGP has a number of 475 counter-measures such as prefix filtering and damping built into the 476 protocol, to assist with stability. It is also easy to track the 477 source of such a potential DoS attack. Without dynamic routing 478 between CEs and PEs the security is equivalent to the security of ATM 479 or Frame Relay networks. 481 3.4 Label Spoofing 483 Similar to IP spoofing attacks, where an attacker fakes the source IP 484 address of a packet, it is also theoretically possible to spoof the 485 label of an MPLS packet. In the first section the assumption was 486 made that the core network is trusted. If this assumption cannot be 487 made IPsec must be run over the MPLS cloud. Thus in this section the 488 emphasis is on whether it is possible to insert packets with spoofed 489 labels into the MPLS network from the outside, i.e., from a VPN (CE 490 router) or from the Internet. 492 The interface between a CE router and its peering PE router is an IP 493 interface, i.e. without labels. The CE router is unaware of the 494 MPLS core, and thinks it is sending IP packets to another router. 495 The "intelligence" is done in the PE device, where based on the 496 configuration, the label is chosen and pre-pended to the packet. 497 This is the case for all PE routers, towards CE routers as well as 498 the upstream service provider. All interfaces into the MPLS cloud 499 only require IP packets, without labels. 501 For security reasons a PE router should never accept a packet with a 502 label from a CE router. RFC 3031 [8] specifies: "Therefore, when a 503 labeled packet is received with an invalid incoming label, it MUST be 504 discarded, UNLESS it is determined by some means (not within the 505 scope of the current document) that forwarding it unlabeled cannot 506 cause any harm." Since accepting labels on the CE interface would 507 potentially allow passing packets to other VPNs it is not permitted 508 by the RFC. 510 Thus it is impossible for an outside attacker to send labeled packets 511 into the BGP/MPLS IP VPN core. 513 There remains the possibility to spoof the IP address of a packet 514 being sent to the MPLS core. Since there is strict address 515 separation within the PE router, and each VPN has its own VRF, this 516 can only harm the VPN the spoofed packet originated from, that is, A 517 VPN customer can attack only himself. MPLS doesn't add any security 518 risk here. 520 The Inter-AS and Carrier's Carrier (CsC) cases are special cases, 521 since on the interfaces between providers typically packets with 522 labels are exchanged. See section 4 for an analysis of these 523 architectures. 525 3.5 Comparison with ATM/FR VPNs 527 ATM and FR VPN services enjoy a very high reputation in terms of 528 security. Although ATM and FR VPNs can also be provided in a secure 529 manner, it has been reported that also these technologies can have 530 security vulnerabilities [14]. In ATM/FR as in any other networking 531 technology the security depends on the configuration of the network 532 being secure, and errors can also lead to security problems. 534 4. Security of advanced BGP/MPLS IP VPN architectures 536 The BGP/MPLS IP VPN architecture described in RFC 2547 [6] defines 537 the PE-CE interface as the only external interface seen from the 538 service provider network. In this case, the PE treats the CE as 539 untrusted and only accepts IP packets from the CE. The IP address 540 range is treated as belonging to the VPN of the CE, so the PE 541 maintains full control over VPN separation. 543 RFC 2547bis [10] has subsequently defined a more complex 544 architecture, with more open interfaces. These interfaces allow the 545 exchange of label information and labeled packets to and from devices 546 outside the control of the service provider. This section discusses 547 the security implications of this advanced architecture. 549 4.1 Carriers' Carrier (CsC) 551 In the CsC architecture the CE is linked to a VRF on the PE. The CE 552 may send labeled packets to the PE. The label has been previously 553 assigned by the PE to the CE, and represents the label switch path 554 (LSP) from this CE to the remote CE via the carrier's network. 556 RFC 2547bis [10] specifies for this case: "When the PE receives a 557 labeled packet from a CE, it must verify that the top label is one 558 that was distributed to that CE." This ensures that the CE can only 559 use labels that the PE correctly associates with the corresponding 560 VPN. Packets with incorrect labels will be discarded, and thus label 561 spoofing is impossible. 563 The use of label maps on the PE leaves the control of the label 564 information entirely with the PE, so that this has no impact on the 565 security of the solution. 567 The packet underneath the top label will -- as in standard RFC 2547 568 [6] networks -- remain local to the customer carrier's VPN and not be 569 inspected in the carriers' carrier core. Potential spoofing of 570 subsequent labels or IP addresses remains local to the carrier's VPN; 571 it has no implication on the carriers' carrier core nor on other VPNs 572 in that core. This is specifically stated in section 6 of RFC 573 2547bis [10]. 575 Note that if the PE and CE are interconnected using a shared layer 2 576 infrastructure such as a switch, attacks are possible on layer 2, 577 which might enable a third party on the shared layer 2 network to 578 intrude into a VPN on that PE router. RFC 2547bis [10] specifies 579 therefore that either all devices on a shared layer 2 network have to 580 be part of the same VPN, or the layer 2 network must be split 581 logically to avoid this issue. This will be discussed in more detail 582 in section 6. 584 In the CsC architecture the customer carrier needs to trust the 585 carriers' carrier for correct configuration and operation. The 586 customer of the carrier thus implicitly needs to trust both his 587 carrier and the carriers' carrier. 589 In summary, a correctly configured carriers' carrier network provides 590 the same level of security as comparable layer 2 networks, or 591 traditional RFC 2547 [6] networks. 593 4.2 Inter-provider backbones 595 RFC 2547bis [10] specifies three sub-cases for the inter-provider 596 backbone (Inter-AS) case. 598 a) VRF-to-VRF connections at the autonomous system border routers 599 (ASBR) 601 In this case each PE sees and treats the other PE as a CE; each will 602 not accept labeled packets, and there is no signaling between the PEs 603 other than inside the VRFs on both sides. Thus the separation of the 604 VPNs on both sides and the security of those are the same as on a 605 single AS RFC 2547 [6] network. This has already been shown to have 606 the same security properties as traditional layer 2 VPNs. 608 This solution has potential scalability issues in that the ASBRs need 609 to maintain a VRF per VPN, and all of the VRFs need to hold all 610 routes of the specific VPNs. Thus an ASBR can run into memory 611 problems affecting all VPNs if one single VRF contains too many 612 routes. Thus the service providers needs to ensure that the ASBRs 613 are properly dimensioned and apply appropriate security measures such 614 as limiting the number of prefixes per VRF. 616 The two service providers connecting their VPNs in this way must 617 trust each other. Since the VPNs are separated on different 618 (sub-)interfaces, all signaling between ASBRs remains within a given 619 VPN. This means that dynamic cross-VPN security breaches are 620 impossible. It is conceivable that a service provider connects a 621 specific VPN to the wrong interface, thus interconnecting two VPNs 622 that should not be connected. This must be controlled operationally. 624 b) EBGP redistribution of labeled VPN-IPv4 routes from AS to 625 neighboring AS 627 In this case ASBRs on both sides hold full routing information for 628 all shared VPNs on both sides. This is not held in separate VRFs, 629 but in the BGP database. (This is typically limited to the Inter-AS 630 VPNs through filtering.) The separation inside the PE is maintained 631 through the use of VPN-IPv4 addresses. The control plane between the 632 ASBRs uses Multi-Protocol BGP (MP-BGP, RFC 2858 [7]). It exchanges 633 VPN routes as VPN-IPv4 addresses, the ASBR addresses as BGP next hop 634 IPv4 addresses, and labels to be used in the data plane. 636 The data plane is separated through the use of a single label, 637 representing a VRF or a subset thereof. RFC 2547bis [10] states that 638 an ASBR should only accept packets with a label that it has assigned 639 to this router. This prevents the insertion of packets with unknown 640 labels, but it is possible for a service provider to use any label 641 that the ASBR of the other provider has passed on. This allows one 642 provider to insert packets into any VPN of the other provider for 643 which it has a label. 645 This solution also needs to consider the security on layer 2 at the 646 interconnection. The RFC states that this type of interconnection 647 should only be implemented on private interconnection points. See 648 section 6 for more details. 650 RFC 2547bis [10] states that a trust relationship between the two 651 connecting ASes must exist for this model to work securely. 652 Effectively all ASes interconnected in this way form a single zone of 653 trust. The VPN customer needs to trust all the service providers 654 involved in the provisioning of his VPN on this architecture. 656 c) PEs exchange labeled VPN-IPv4 routes, ASBRs only exchange 657 loopbacks of PEs with labels. 659 In this solution there are effectively two control connections 660 between ASes. The route reflectors (RRs) exchange the VPN-IPv4 661 routes via multihop eBGP. The ASBRs only exchange the labeled 662 addresses of those PE routers that hold VPN routes that are shared 663 between those ASes. This maintains scalability for the ASBR routers, 664 since they do not need to know the VPN-IPv4 routes. 666 In this solution the top label specifies an LSP to an egress PE 667 router, and the second label specifies a VPN connected to this egress 668 PE. The security of the ASBR connection has the same constraints as 669 in solution b): An ASBR should only accept packets with top labels 670 that it has assigned to the other router, thus verifying that the 671 packet is addressed to a valid PE router. Any label, which was 672 assigned to the other ASBR, router will be accepted. It is 673 impossible for an ASBR to distinguish between different egress PEs, 674 nor between different VPNs on those PEs. A malicious service 675 provider of one AS could introduce packets into any VPN on a PE of 676 the other AS; it only needs a valid LSP on its ASBR and PEs to the 677 corresponding PE on the other AS. The VPN label can be statistically 678 guessed from the theoretical label space, which allows unidirectional 679 traffic into a VPN. 681 This means that such an ASBR-ASBR connection can only be made with a 682 trusted party over a private interface, as described in b). 684 In addition, this solution exchanges labeled VPN-IPv4 addresses 685 between route reflectors (RR) via MP-eBGP. The control plane itself 686 can be protected via routing authentication (RFC 2385 [5]), which 687 ensures that the routing information has been originated by the 688 expected RR and has not been modified in transit. The received VPN 689 information cannot be verified, as in the previous case. Thus a 690 service provider can introduce bogus routes for any shared VPN. The 691 ASes need to trust each other to configure their respective networks 692 correctly. All ASes involved in this design form one trusted zone. 693 The customer needs to trust all service providers involved. 695 The difference between case b) and case c) is that in b) the ASBRs 696 act as iBGP next-hops for their AS; thus each SP needs to know of the 697 other SP's core only the addresses of the ASBRs. In case c) the SPs 698 exchange the loopback addresses of their PE routers; thus each SP 699 reveals information to the other about their PE routers, and these 700 routers must be accessible from the other AS. As stated above, 701 accessibility does not necessarily mean insecurity, and networks 702 should never rely on "security through obscurity". This should not 703 be an issue if the PE routers are appropriately secured. However, 704 there is an increasing perception that network devices should 705 generally not be accessible. 707 In addition there are scalability considerations for case c). A 708 number of BGP peerings have to be made for the overall network 709 including all ASes linked this way. SPs on both sides need to work 710 together in defining a scalable architecture, probably with route 711 reflectors. 713 In summary, all of these Inter-AS solutions logically merge several 714 provider networks. For all cases of Inter-AS configuration, all ASes 715 form a single zone of trust and service providers need to trust each 716 other. For the VPN customer, the security of the overall solution is 717 equal to the security of traditional RFC 2547 [6] networks, but the 718 customer needs to trust all service providers involved in the 719 provisioning of this Inter-AS solution. 721 5. What BGP/MPLS IP VPNs Do Not Provide 723 5.1 Protection against Misconfigurations of the Core and Attacks 724 'within' the Core 726 The security mechanisms discussed here assume correct configuration 727 of the network elements of the core network (PE and P routers). 728 Deliberate or inadvertent misconfiguration may result in severe 729 security leaks. 731 Note that this paragraph specifically refers to the core network, 732 i.e., the PE and P elements. Misconfigurations of any of the 733 customer side elements such as the CE router are covered by the 734 security mechanisms above. This means that a potential attacker must 735 have access to either PE or P routers to gain advantage from 736 misconfigurations. If an attacker has access to core elements, or is 737 able to insert into the core additional equipment, he will be able to 738 attack both the core network as well as the connected VPNs. Thus the 739 following is important: 740 o To avoid the risk of misconfigurations it is important that the 741 equipment is easy to configure, and that SP staff have the 742 appropriate training and experience when configuring the network. 743 Proper tools are required to configure the core network. 744 o To minimise the risk of "internal" attacks the core network must 745 be properly secured. This includes network element security, 746 management security, physical security of the service provider 747 infrastructure, access control to service provider installations 748 and other standard SP security mechanisms. 750 BGP/MPLS IP VPNs can only provide a secure service if the core 751 network is provided in a secure fashion. This document assumes this 752 to be the case. 754 There are various approaches to control the security of a core if the 755 VPN customer cannot or does not want to trust the service provider. 756 IPsec from customer controlled devices is one of them. Document 757 draft- ietf-l3vpn-auth [13] proposes a CE-based authentication scheme 758 using tokens, aimed at detecting misconfigurations in the MPLS core. 759 Document draft-behringer-mpls-vpn-auth [12] proposes a similar scheme 760 based on using the MD5 routing authentication. Both schemes aim to 761 detect and prevent misconfigurations in the core. 763 5.2 Data Encryption, Integrity and Origin Authentication 765 BGP/MPLS IP VPNs themselves does not provide encryption, integrity, 766 or authentication service. If these are required, IPsec should be 767 used over the MPLS infrastructure. The same applies to ATM and Frame 768 Relay: IPsec can provide these missing services. 770 5.3 Customer Network Security 772 BGP/MPLS IP VPNs can be secured so that they are comparable with 773 other VPN services. However, the security of the core network is 774 only one factor for the overall security of a customer's network. 775 Threats in today's networks do not come only from an "outside" 776 connection, but also from the "inside" and from other entry points 777 (modems, for example). To reach a good security level for a customer 778 network in an BGP/MPLS infrastructure, MPLS security is necessary but 779 not sufficient. The same applies to other VPN technologies like ATM 780 or frame relay. See also RFC 2196 [4] for more information on how to 781 secure a network. 783 6. Layer 2 security considerations 785 In most cases of Inter-AS or Carrier's Carrier solutions, a network 786 will be interconnected to other networks via a point-to-point private 787 connection. This connection cannot be interfered by third parties. 788 It is important to understand that the use of any shared medium layer 789 2 technology for such interconnections, such as Ethernet switches, 790 may carry additional security risks. 792 There are two types of risks with layer 2 infrastructure: 794 a) Attacks against layer 2 protocols or mechanisms 796 Risks in a layer 2 environment include many different forms of ARP 797 attacks, VLAN trunking attacks, or CAM overflow attacks. For 798 example, ARP spoofing allows an attacker to re-direct traffic between 799 two routers through his device, gaining access to all packets between 800 those two routers. 802 These attacks can be prevented by appropriate security measures, but 803 often these security concerns are overlooked. It is of the utmost 804 importance that if a shared medium (such as a switch) is used in the 805 above scenarios, that all available layer 2 security mechanisms are 806 used to prevent layer 2 based attacks. 808 b) Traffic insertion attacks 810 Where many routers share a common layer 2 network, (for example at an 811 Internet exchange point), it is possible for a third party to 812 introduce packets into a network. This has been abused in the past 813 on traditional exchange points when some service providers have 814 defaulted to another provider on this exchange point. In effect, 815 they are sending all their traffic into the other SPs network even 816 though the control plane (routing) might not allow that. 818 For this reason routers on exchange points (or other shared layer 2 819 connections) should only accept non-labeled IP packets into the 820 global routing table. Any labeled packet must be discarded. This 821 maintains the security of connected networks. 823 Some of the above designs require the exchange of labeled packets. 824 This would make it possible for a third party to introduce labeled 825 packets, which if correctly crafted might be associated with certain 826 VPNs on an BGP/MPLS IP VPN network, effectively introducing false 827 packets into a VPN. 829 The current recommendation is therefore to discard labeled packets on 830 generic shared medium layer 2 networks such as Internet exchange 831 points (IXPs). Where labeled packets need to be exchanged it is 832 strongly recommended to use private connections. 834 7. Summary and Conclusions 836 BGP/MPLS IP VPNs provide full address and traffic separation as in 837 traditional layer-2 VPN services. It hides addressing structures of 838 the core and other VPNs, and it is not possible to intrude into other 839 VPNs abusing the BGP/MPLS mechanisms. It is also impossible to 840 intrude into the MPLS core if this is properly secured. However, 841 there is a significant difference between BGP/MPLS based IP VPNs and 842 for example FR or ATM based VPNs: The control structure of the core 843 is layer 3 in the case of MPLS. This caused significant skepticism 844 in the industry towards MPLS, since this might open the architecture 845 to DoS attacks from other VPNs or the Internet (if connected). 847 As shown in this document, it is possible to secure a BGP/MPLS IP VPN 848 infrastructure to the same level of security as a comparable ATM or 849 FR service. It is also possible to offer Internet connectivity to 850 MPLS VPNs in a secure manner, and to interconnect different VPNs via 851 firewalls. Although ATM and FR services have a strong reputation 852 with regard to security, it has been shown that also in these 853 networks security problems can also exist [14]. 855 As far as attacks from within the MPLS core are concerned, all VPN 856 classes (BGP/MPLS, FR, ATM) have the same problem: If an attacker can 857 install a sniffer, he can read information in all VPNs, and if he has 858 access to the core devices, he can execute a large number of attacks, 859 from packet spoofing to introducing new peer routers. There are a 860 number of precautionary measures outlined above that a service 861 provider can use to tighten security of the core, but the security of 862 the BGP/MPLS IP VPN architecture depends on the security of the 863 service provider. If the service provider is not trusted, the only 864 way to fully secure a VPN against attacks from the "inside" of the 865 VPN service is to run IPsec on top, from the CE devices or beyond. 867 This document discussed many aspects of BGP/MPLS IP VPN security. It 868 has to be noted that the overall security of this architecture 869 depends on all components, and is determined by the security of the 870 weakest part of the solution. For example a perfectly secured static 871 BGP/MPLS IP VPN network with secured Internet access and secure 872 management is still open to many attacks if there is a weak remote 873 access solution in place. 875 8. Security Considerations 877 The entire document is discussing security considerations of the RFC 878 2547bis [10] architecture. 880 9. Acknowledgements 882 The author would like to thank everybody who has provided input to 883 this document. Specific thanks go to Yakov Rekhter for his continued 884 strong support, and Eric Rosen, Loa Andersson, Alexander Manhenke, 885 Jim Guichard, Monique Morrow, Eric Vyncke and Steve Simlo for their 886 extended feedback and support. 888 10 Informative References 890 [1] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and E. 891 Lear, "Address Allocation for Private Internets", BCP 5, RFC 892 1918, February 1996. 894 [2] Baker, F., Atkinson, R. and G. Malkin, "RIP-2 MD5 895 Authentication", RFC 2082, January 1997. 897 [3] Murphy, S., Badger, M. and B. Wellington, "OSPF with Digital 898 Signatures", RFC 2154, June 1997. 900 [4] Fraser, B., "Site Security Handbook", RFC 2196, September 1997. 902 [5] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 903 Signature Option", RFC 2385, August 1998. 905 [6] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March 906 1999. 908 [7] Bates, T., Rekhter, Y., Chandra, R. and D. Katz, "Multiprotocol 909 Extensions for BGP-4", RFC 2858, June 2000. 911 [8] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label 912 Switching Architecture", RFC 3031, January 2001. 914 [9] Gill, V., Heasley, J. and D. Meyer, "The Generalized TTL 915 Security Mechanism (GTSM)", RFC 3682, February 2004. 917 [10] Rosen, E., "BGP/MPLS IP VPNs", draft-ietf-l3vpn-rfc2547bis-03 918 (work in progress), October 2004. 920 [11] Fang, L., "Security Framework for Provider Provisioned Virtual 921 Private Networks", draft-ietf-l3vpn-security-framework-02 (work 922 in progress), July 2004. 924 [12] Behringer, M., Guichard, J. and P. Marques, "MPLS VPN 925 Import/Export Verification", draft-behringer-mpls-vpn-auth-04 926 (work in progress), June 2004. 928 [13] Bonica, R. and Y. Rekhter, "CE-to-CE Member Verification for 929 Layer 3 VPNs", draft-ietf-l3vpn-auth-00 (work in progress), 930 September 2003. 932 [14] DataComm, "Data Communications Report, Vol 15, No 4: Frame 933 Relay and ATM: Are they really secure?", February 2000. 935 Author's Address 937 Michael H. Behringer 938 Cisco Systems Inc 939 Village d'Entreprises Green Side 940 400, Avenue Roumanille, Batiment T 3 941 Biot - Sophia Antipolis 06410 942 France 944 EMail: mbehring@cisco.com 945 URI: http://www.cisco.com 947 Intellectual Property Statement 949 The IETF takes no position regarding the validity or scope of any 950 Intellectual Property Rights or other rights that might be claimed to 951 pertain to the implementation or use of the technology described in 952 this document or the extent to which any license under such rights 953 might or might not be available; nor does it represent that it has 954 made any independent effort to identify any such rights. Information 955 on the procedures with respect to rights in RFC documents can be 956 found in BCP 78 and BCP 79. 958 Copies of IPR disclosures made to the IETF Secretariat and any 959 assurances of licenses to be made available, or the result of an 960 attempt made to obtain a general license or permission for the use of 961 such proprietary rights by implementers or users of this 962 specification can be obtained from the IETF on-line IPR repository at 963 http://www.ietf.org/ipr. 965 The IETF invites any interested party to bring to its attention any 966 copyrights, patents or patent applications, or other proprietary 967 rights that may cover technology that may be required to implement 968 this standard. Please address the information to the IETF at 969 ietf-ipr@ietf.org. 971 Disclaimer of Validity 973 This document and the information contained herein are provided on an 974 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 975 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 976 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 977 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 978 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 979 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 981 Copyright Statement 983 Copyright (C) The Internet Society (2004). This document is subject 984 to the rights, licenses and restrictions contained in BCP 78, and 985 except as set forth therein, the authors retain all their rights. 987 Acknowledgment 989 Funding for the RFC Editor function is currently provided by the 990 Internet Society.