diff options
Diffstat (limited to 'doc/rfc/rfc4381.txt')
| -rw-r--r-- | doc/rfc/rfc4381.txt | 1235 |
1 files changed, 1235 insertions, 0 deletions
diff --git a/doc/rfc/rfc4381.txt b/doc/rfc/rfc4381.txt new file mode 100644 index 0000000..be318ee --- /dev/null +++ b/doc/rfc/rfc4381.txt @@ -0,0 +1,1235 @@ + + + + + + +Network Working Group M. Behringer +Request for Comments: 4381 Cisco Systems Inc +Category: Informational February 2006 + + + Analysis of the Security of BGP/MPLS IP + Virtual Private Networks (VPNs) + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +IESG Note + + The content of this RFC was at one time considered by the IETF, and + therefore it may resemble a current IETF work in progress or a + published IETF work. This RFC is not a candidate for any level of + Internet Standard. The IETF disclaims any knowledge of the fitness + of this RFC for any purpose, and in particular notes that the + decision to publish is not based on IETF review for such things as + security, congestion control or inappropriate interaction with + deployed protocols. The RFC Editor has chosen to publish this + document at its discretion. Readers of this RFC should exercise + caution in evaluating its value for implementation and deployment. + See RFC 3932 for more information. + +Abstract + + This document analyses the security of the BGP/MPLS IP virtual + private network (VPN) architecture that is described in RFC 4364, for + the benefit of service providers and VPN users. + + The analysis shows that BGP/MPLS IP VPN networks can be as secure as + traditional layer-2 VPN services using Asynchronous Transfer Mode + (ATM) or Frame Relay. + + + + + + + + + + +Behringer Informational [Page 1] + +RFC 4381 Security of BGP/MPLS IP VPNs February 2006 + + +Table of Contents + + 1. Scope and Introduction ..........................................3 + 2. Security Requirements of VPN Networks ...........................4 + 2.1. Address Space, Routing, and Traffic Separation .............4 + 2.2. Hiding the Core Infrastructure .............................5 + 2.3. Resistance to Attacks ......................................5 + 2.4. Impossibility of Label Spoofing ............................6 + 3. Analysis of BGP/MPLS IP VPN Security ............................6 + 3.1. Address Space, Routing, and Traffic Separation .............6 + 3.2. Hiding of the BGP/MPLS IP VPN Core Infrastructure ..........7 + 3.3. Resistance to Attacks ......................................9 + 3.4. Label Spoofing ............................................11 + 3.5. Comparison with ATM/FR VPNs ...............................12 + 4. Security of Advanced BGP/MPLS IP VPN Architectures .............12 + 4.1. Carriers' Carrier .........................................13 + 4.2. Inter-Provider Backbones ..................................14 + 5. What BGP/MPLS IP VPNs Do Not Provide ...........................16 + 5.1. Protection against Misconfigurations of the Core + and Attacks 'within' the Core .............................16 + 5.2. Data Encryption, Integrity, and Origin Authentication .....17 + 5.3. Customer Network Security .................................17 + 6. Layer 2 Security Considerations ................................18 + 7. Summary and Conclusions ........................................19 + 8. Security Considerations ........................................20 + 9. Acknowledgements ...............................................20 + 10. Normative References ..........................................20 + 11. Informative References ........................................20 + + + + + + + + + + + + + + + + + + + + + + + +Behringer Informational [Page 2] + +RFC 4381 Security of BGP/MPLS IP VPNs February 2006 + + +1. Scope and Introduction + + As Multiprotocol Label Switching (MPLS) is becoming a more widespread + technology for providing IP virtual private network (VPN) services, + the security of the BGP/MPLS IP VPN architecture is of increasing + concern to service providers and VPN customers. This document gives + an overview of the security of the BGP/MPLS IP VPN architecture that + is described in RFC 4364 [1], and compares it with the security of + traditional layer-2 services such as ATM or Frame Relay. + + The term "MPLS core" is defined for this document as the set of + Provider Edge (PE) and provider (P) routers that provide a BGP/MPLS + IP VPN service, typically under the control of a single service + provider (SP). This document assumes that the MPLS core network is + trusted and secure. Thus, it does not address basic security + concerns such as securing the network elements against unauthorised + access, misconfigurations of the core, or attacks internal to the + core. A customer that does not wish to trust the service provider + network must use additional security mechanisms such as IPsec over + the MPLS infrastructure. + + This document analyses only the security features of BGP/MPLS IP + VPNs, not the security of routing protocols in general. IPsec + technology is also not covered, except to highlight the combination + of MPLS VPNs with IPsec. + + The overall security of a system has three aspects: the architecture, + the implementation, and the operation of the system. Security issues + can exist in any of these aspects. This document analyses only the + architectural security of BGP/MPLS IP VPNs, not implementation or + operational security issues. + + This document is targeted at technical staff of service providers and + enterprises. Knowledge of the basic BGP/MPLS IP VPN architecture as + described in RFC 4364 [1] is required to understand this document. + For specific Layer 3 VPN terminology and reference models refer to + [11]. + + Section 2 of this document specifies the typical VPN requirements a + VPN user might have, and section 3 analyses how RFC 4364 [1] + addresses these requirements. Section 4 discusses specific security + issues of multi-AS (Autonomous System) MPLS architectures, and + section 5 lists security features that are not covered by this + architecture and therefore need to be addressed separately. Section + 6 highlights potential security issues on layer 2 that might impact + the overall security of a BGP/MPLS IP VPN service. The findings of + this document are summarized in section 7. + + + + +Behringer Informational [Page 3] + +RFC 4381 Security of BGP/MPLS IP VPNs February 2006 + + +2. Security Requirements of VPN Networks + + Both service providers offering any type of VPN services and + customers using them have specific demands for security. Mostly, + they compare MPLS-based solutions with traditional layer 2-based VPN + solutions such as Frame Relay and ATM, since these are widely + deployed and accepted. This section outlines the typical security + requirements for VPN networks. The following section discusses if + and how BGP/MPLS IP VPNs address these requirements, for both the + MPLS core and the connected VPNs. + +2.1. Address Space, Routing, and Traffic Separation + + Non-intersecting layer 3 VPNs of the same VPN service are assumed to + have independent address spaces. For example, two non-intersecting + VPNs may each use the same 10/8 network addresses without conflict. + In addition, traffic from one VPN must never enter another VPN. This + implies separation of routing protocol information, so that routing + tables must also be separate per VPN. Specifically: + + o Any VPN must be able to use the same address space as any other + VPN. + o Any VPN must be able to use the same address space as the MPLS + core. + o Traffic, including routing traffic, from one VPN must never flow + to another VPN. + o Routing information, as well as distribution and processing of + that information, for one VPN instance must be independent from + any other VPN instance. + o Routing information, as well as distribution and processing of + that information, for one VPN instance must be independent from + the core. + + From a security point of view, the basic requirement is to prevent + packets destined to a host a.b.c.d within a given VPN reaching a host + with the same address in another VPN or in the core, and to prevent + routing packets to another VPN even if it does not contain that + destination address. + + Confidentiality, as defined in the L3VPN Security Framework [11], is + a requirement that goes beyond simple isolation of VPNs and provides + protection against eavesdropping on any transmission medium. + Encryption is the mechanism used to provide confidentiality. This + document considers confidentiality an optional VPN requirement, since + many existing VPN deployments do not encrypt transit traffic. + + + + + + +Behringer Informational [Page 4] + +RFC 4381 Security of BGP/MPLS IP VPNs February 2006 + + +2.2. Hiding the Core Infrastructure + + The internal structure of the core network (MPLS PE and P elements) + should not be externally visible. Whilst breaking this requirement + is not a security problem in itself, many service providers believe + it is advantageous if the internal addresses and network structure + are hidden from the outside world. An argument is that denial-of- + service (DoS) attacks against a core router are much easier to carry + out if an attacker knows the router addresses. Addresses can always + be guessed, but attacks are more difficult if addresses are not + known. The core should be as invisible to the outside world as a + comparable layer 2 infrastructure (e.g., Frame Relay, ATM). Core + network elements should also not be accessible from within a VPN. + + Security should never rely entirely on obscurity, i.e., the hiding of + information. Services should be equally secure if the implementation + is known. However, there is a strong market perception that hiding + of details is advantageous. This point addresses that market + perception. + +2.3. Resistance to Attacks + + There are two basic types of attacks: DoS attacks, where resources + become unavailable to authorised users, and intrusions, where + resources become available to unauthorised users. BGP/MPLS IP VPN + networks must provide at least the same level of protection against + both forms of attack as current layer 2 networks. + + For intrusions, there are two fundamental ways to protect the + network: first, to harden protocols that could be abused (e.g., + Telnet into a router), and second, to make the network as + inaccessible as possible. This is achieved by a combination of + packet filtering / firewalling and address hiding, as discussed + above. + + DoS attacks are easier to execute, since a single known IP address + might be enough information to attack a machine. This can be done + using normal "permitted" traffic, but using higher than normal packet + rates, so that other users cannot access the targeted machine. The + only way to be invulnerable to this kind of attack is to make sure + that machines are not reachable, again by packet filtering and + optionally by address hiding. + + This document concentrates on protecting the core network against + attacks from the "outside", i.e., the Internet and connected VPNs. + Protection against attacks from the "inside", i.e., an attacker who + has logical or physical access to the core network, is not discussed + here. + + + +Behringer Informational [Page 5] + +RFC 4381 Security of BGP/MPLS IP VPNs February 2006 + + +2.4. Impossibility of Label Spoofing + + Assuming the address and traffic separation discussed above, an + attacker might try to access other VPNs by inserting packets with a + label that he does not "own". This could be done from the outside, + i.e., another Customer Edge (CE) router or from the Internet, or from + within the MPLS core. The latter case (from within the core) will + not be discussed, since we assume that the core network is provided + securely. Should protection against an insecure core be required, it + is necessary to use security protocols such as IPsec across the MPLS + infrastructure, at least from CE to CE, since the PEs belong to the + core. + + Depending on the way that CE routers are connected to PE routers, it + might be possible to intrude into a VPN that is connected to the same + PE, using layer 2 attack mechanisms such as 802.1Q-label spoofing or + ATM VPI/VCI spoofing. Layer 2 security issues will be discussed in + section 6. + + It is required that VPNs cannot abuse the MPLS label mechanisms or + protocols to gain unauthorised access to other VPNs or the core. + +3. Analysis of BGP/MPLS IP VPN Security + + In this section, the BGP/MPLS IP VPN architecture is analysed with + respect to the security requirements listed above. + +3.1. Address Space, Routing, and Traffic Separation + + BGP/MPLS allows distinct IP VPNs to use the same address space, which + can also be private address space (RFC 1918 [2]). This is achieved + by adding a 64-bit Route Distinguisher (RD) to each IPv4 route, + making VPN-unique addresses also unique in the MPLS core. This + "extended" address is also called a "VPN-IPv4 address". Thus, + customers of a BGP/MPLS IP VPN service do not need to change their + current addressing plan. + + Each PE router maintains a separate Virtual Routing and Forwarding + instance (VRF) for each connected VPN. A VRF includes the addresses + of that VPN as well as the addresses of the PE routers with which the + CE routers are peering. All addresses of a VRF, including these PE + addresses, belong logically to the VPN and are accessible from the + VPN. The fact that PE addresses are accessible to the VPN is not an + issue if static routing is used between the PE and CE routers, since + packet filters can be deployed to block access to all addresses of + the VRF on the PE router. If dynamic routing protocols are used, the + CE routers need to have the address of the peer PE router in the core + configured. In an environment where the service provider manages the + + + +Behringer Informational [Page 6] + +RFC 4381 Security of BGP/MPLS IP VPNs February 2006 + + + CE routers as CPE, this can be invisible to the customer. The + address space on the CE-PE link (including the peering PE address) is + considered part of the VPN address space. Since address space can + overlap between VPNs, the CE-PE link addresses can overlap between + VPNs. For practical management considerations, SPs typically address + CE-PE links from a global pool, maintaining uniqueness across the + core. + + Routing separation between VPNs can also be achieved. Each VRF is + populated with routes from one VPN through statically configured + routes or through routing protocols that run between the PE and CE + router. Since each VPN is associated with a separate VRF there is no + interference between VPNs on the PE router. + + Across the core to the other PE routers separation is maintained with + unique VPN identifiers in multiprotocol BGP, the Route Distinguishers + (RDs). VPN routes including the RD are exclusively exchanged between + PE routers by Multi-Protocol BGP (MP-BGP, RFC 2858 [8]) across the + core. These BGP routing updates are not re-distributed into the + core, but only to the other PE routers, where the information is kept + again in VPN-specific VRFs. Thus, routing across a BGP/MPLS network + is separate per VPN. + + On the data plane, traffic separation is achieved by the ingress PE + pre-pending a VPN-specific label to the packets. The packets with + the VPN labels are sent through the core to the egress PE, where the + VPN label is used to select the egress VRF. + + Given the addressing, routing, and traffic separation across an BGP/ + MPLS IP VPN core network, it can be assumed that this architecture + offers in this respect the same security as a layer-2 VPN. It is not + possible to intrude from a VPN or the core into another VPN unless + this has been explicitly configured. + + If and when confidentiality is required, it can be achieved in BGP/ + MPLS IP VPNs by overlaying encryption services over the network. + However, encryption is not a standard service on BGP/MPLS IP VPNs. + See also section 5.2. + +3.2. Hiding of the BGP/MPLS IP VPN Core Infrastructure + + Service providers and end-customers do not normally want their + network topology revealed to the outside. This makes attacks more + difficult to execute: If an attacker doesn't know the address of a + victim, he can only guess the IP addresses to attack. Since most DoS + attacks don't provide direct feedback to the attacker it would be + difficult to attack the network. It has to be mentioned specifically + + + + +Behringer Informational [Page 7] + +RFC 4381 Security of BGP/MPLS IP VPNs February 2006 + + + that information hiding as such does not provide security. However, + in the market this is a perceived requirement. + + With a known IP address, a potential attacker can launch a DoS attack + more easily against that device. Therefore, the ideal is to not + reveal any information about the internal network to the outside + world. This applies to the customer network and the core. A number + of additional security measures also have to be taken: most of all, + extensive packet filtering. + + For security reasons, it is recommended for any core network to + filter packets from the "outside" (Internet or connected VPNs) + destined to the core infrastructure. This makes it very hard to + attack the core, although some functionality such as pinging core + routers will be lost. Traceroute across the core will still work, + since it addresses a destination outside the core. + + MPLS does not reveal unnecessary information to the outside, not even + to customer VPNs. The addressing of the core can be done with + private addresses (RFC 1918 [2]) or public addresses. Since the + interface to the VPNs as well as the Internet is BGP, there is no + need to reveal any internal information. The only information + required in the case of a routing protocol between PE and CE is the + address of the PE router. If no dynamic routing is required, static + routing on unnumbered interfaces can be configured between the PE and + CE. With this measure, the BGP/MPLS IP VPN core can be kept + completely hidden. + + Customer VPNs must advertise their routes to the BGP/MPLS IP VPN core + (dynamically or statically), to ensure reachability across their VPN. + In some cases, VPN users prefer that the service provider have no + visibility of the addressing plan of the VPN. The following has to + be noted: First, the information known to the core is not about + specific hosts, but networks (routes); this offers a degree of + abstraction. Second, in a VPN-only BGP/MPLS IP VPN network (no + Internet access) this is equal to existing layer-2 models, where the + customer has to trust the service provider. Also, in a Frame Relay + or ATM network, routing and addressing information about the VPNs can + be seen on the core network. + + In a VPN service with shared Internet access, the service provider + will typically announce the routes of customers who wish to use the + Internet to his upstream or peer providers. This can be done + directly if the VPN customer uses public address space, or via + Network Address Translation (NAT) to obscure the addressing + information of the customers' networks. In either case, the customer + does not reveal more information than would be revealed by a general + Internet service. Core information will not be revealed, except for + + + +Behringer Informational [Page 8] + +RFC 4381 Security of BGP/MPLS IP VPNs February 2006 + + + the peering address(es) of the PE router(s) that hold(s) the peering + with the Internet. These addresses must be secured as in a + traditional IP backbone. + + In summary, in a pure MPLS-VPN service, where no Internet access is + provided, information hiding is as good as on a comparable FR or ATM + network. No addressing information is revealed to third parties or + the Internet. If a customer chooses to access the Internet via the + BGP/MPLS IP VPN core, he will have to reveal the same information as + required for a normal Internet service. NAT can be used for further + obscurity. Being reachable from the Internet automatically exposes a + customer network to additional security threats. Appropriate + security mechanisms have to be deployed such as firewalls and + intrusion detection systems. This is true for any Internet access, + over MPLS or direct. + + A BGP/MPLS IP VPN network with no interconnections to the Internet + has security equal to that of FR or ATM VPN networks. With an + Internet access from the MPLS cloud, the service provider has to + reveal at least one IP address (of the peering PE router) to the next + provider, and thus to the outside world. + +3.3. Resistance to Attacks + + Section 3.1 shows that it is impossible to directly intrude into + other VPNs. Another possibility is to attack the MPLS core and try + to attack other VPNs from there. As shown above, it is impossible to + address a P router directly. The only addresses reachable from a VPN + or the Internet are the peering addresses of the PE routers. Thus, + there are two basic ways that the BGP/MPLS IP VPN core can be + attacked: + + 1. By attacking the PE routers directly. + 2. By attacking the signaling mechanisms of MPLS (mostly routing). + + To attack an element of a BGP/MPLS IP VPN network, it is first + necessary to know the address of the element. As discussed in + section 3.2, the addressing structure of the BGP/MPLS IP VPN core is + hidden from the outside world. Thus, an attacker cannot know the IP + address of any router in the core to attack. The attacker could + guess addresses and send packets to these addresses. However, due to + the address separation of MPLS each incoming packet will be treated + as belonging to the address space of the customer. Thus, it is + impossible to reach an internal router, even by guessing IP + addresses. There is only one exception to this rule, which is the + peer interface of the PE router. This address of the PE is the only + attack point from the outside (a VPN or Internet). + + + + +Behringer Informational [Page 9] + +RFC 4381 Security of BGP/MPLS IP VPNs February 2006 + + + The routing between a VPN and the BGP/MPLS IP VPN core can be + configured two ways: + + 1. Static: In this case, the PE routers are configured with static + routes to the networks behind each CE, and the CEs are configured + to statically point to the PE router for any network in other + parts of the VPN (mostly a default route). There are two sub- + cases: The static route can point to the IP address of the PE + router or to an interface of the CE router (e.g., serial0). + 2. Dynamic: A routing protocol (e.g., Routing Information Protocol + (RIP), OSPF, BGP) is used to exchange routing information between + the CE and PE at each peering point. + + In the case of a static route that points to an interface, the CE + router doesn't need to know any IP addresses of the core network or + even of the PE router. This has the disadvantage of needing a more + extensive (static) configuration, but is the most secure option. In + this case, it is also possible to configure packet filters on the PE + interface to deny any packet to the PE interface. This protects the + router and the whole core from attack. + + In all other cases, each CE router needs to know at least the router + ID (RID, i.e., peer IP address) of the PE router in the core, and + thus has a potential destination for an attack. One could imagine + various attacks on various services running on a router. In + practice, access to the PE router over the CE-PE interface can be + limited to the required routing protocol by using access control + lists (ACLs). This limits the point of attack to one routing + protocol, for example, BGP. A potential attack could be to send an + extensive number of routes, or to flood the PE router with routing + updates. Both could lead to a DoS, however, not to unauthorised + access. + + To reduce this risk, it is necessary to configure the routing + protocol on the PE router to operate as securely as possible. This + can be done in various ways: + + o By accepting only routing protocol packets, and only from the CE + router. The inbound ACL on each CE interface of the PE router + should allow only routing protocol packets from the CE to the PE. + o By configuring MD5 authentication for routing protocols. This is + available for BGP (RFC 2385 [6]), OSPF (RFC 2154 [4]), and RIP2 + (RFC 2082 [3]), for example. This avoids packets being spoofed + from other parts of the customer network than the CE router. It + requires the service provider and customer to agree on a shared + secret between all CE and PE routers. It is necessary to do this + for all VPN customers. It is not sufficient to do this only for + the customer with the highest security requirements. + + + +Behringer Informational [Page 10] + +RFC 4381 Security of BGP/MPLS IP VPNs February 2006 + + + o By configuring parameters of the routing protocol to further + secure this communication. For example, the rate of routing + updates should be restricted where possible (in BGP through + damping); a maximum number of routes accepted per VRF and per + routing neighbor should be configured where possible; and the + Generalized TTL Security Mechanism (GTSM; RFC 3682 [10]) should be + used for all supported protocols. + + In summary, it is not possible to intrude from one VPN into other + VPNs, or the core. However, it is theoretically possible to attack + the routing protocol port to execute a DoS attack against the PE + router. This in turn might have a negative impact on other VPNs on + this PE router. For this reason, PE routers must be extremely well + secured, especially on their interfaces to CE routers. ACLs must be + configured to limit access only to the port(s) of the routing + protocol, and only from the CE router. Further routing protocols' + security mechanisms such as MD5 authentication, maximum prefix + limits, and Time to Live (TTL) security mechanisms should be used on + all PE-CE peerings. With all these security measures, the only + possible attack is a DoS attack against the routing protocol itself. + BGP has a number of countermeasures such as prefix filtering and + damping built into the protocol, to assist with stability. It is + also easy to track the source of such a potential DoS attack. + Without dynamic routing between CEs and PEs, the security is + equivalent to the security of ATM or Frame Relay networks. + +3.4. Label Spoofing + + Similar to IP spoofing attacks, where an attacker fakes the source IP + address of a packet, it is also theoretically possible to spoof the + label of an MPLS packet. In the first section, the assumption was + made that the core network is trusted. If this assumption cannot be + made, IPsec must be run over the MPLS cloud. Thus in this section + the emphasis is on whether it is possible to insert packets with + spoofed labels into the MPLS network from the outside, i.e., from a + VPN (CE router) or from the Internet. + + The interface between a CE router and its peering PE router is an IP + interface, i.e., without labels. The CE router is unaware of the + MPLS core, and thinks it is sending IP packets to another router. + The "intelligence" is done in the PE device, where, based on the + configuration, the label is chosen and pre-pended to the packet. + This is the case for all PE routers, towards CE routers as well as + the upstream service provider. All interfaces into the MPLS cloud + only require IP packets, without labels. + + + + + + +Behringer Informational [Page 11] + +RFC 4381 Security of BGP/MPLS IP VPNs February 2006 + + + For security reasons, a PE router should never accept a packet with a + label from a CE router. RFC 3031 [9] specifies: "Therefore, when a + labeled packet is received with an invalid incoming label, it MUST be + discarded, UNLESS it is determined by some means (not within the + scope of the current document) that forwarding it unlabeled cannot + cause any harm." Since accepting labels on the CE interface would + potentially allow passing packets to other VPNs it is not permitted + by the RFC. + + Thus, it is impossible for an outside attacker to send labeled + packets into the BGP/MPLS IP VPN core. + + There remains the possibility to spoof the IP address of a packet + being sent to the MPLS core. Since there is strict address + separation within the PE router, and each VPN has its own VRF, this + can only harm the VPN the spoofed packet originated from; that is, a + VPN customer can attack only himself. MPLS doesn't add any security + risk here. + + The Inter-AS and Carrier's Carrier cases are special cases, since on + the interfaces between providers typically packets with labels are + exchanged. See section 4 for an analysis of these architectures. + +3.5. Comparison with ATM/FR VPNs + + ATM and FR VPN services enjoy a very high reputation in terms of + security. Although ATM and FR VPNs can be provided in a secure + manner, it has been reported that these technologies also can have + security vulnerabilities [14]. In ATM/FR as in any other networking + technology, the security depends on the configuration of the network + being secure, and errors can also lead to security problems. + +4. Security of Advanced BGP/MPLS IP VPN Architectures + + The BGP/MPLS IP VPN architecture described in RFC 2547 [7] defines + the PE-CE interface as the only external interface seen from the + service provider network. In this case, the PE treats the CE as + untrusted and only accepts IP packets from the CE. The IP address + range is treated as belonging to the VPN of the CE, so the PE + maintains full control over VPN separation. + + RFC 4364 [1] has subsequently defined a more complex architecture, + with more open interfaces. These interfaces allow the exchange of + label information and labeled packets to and from devices outside the + control of the service provider. This section discusses the security + implications of this advanced architecture. + + + + + +Behringer Informational [Page 12] + +RFC 4381 Security of BGP/MPLS IP VPNs February 2006 + + +4.1. Carriers' Carrier + + In the Carriers' Carrier (CsC) architecture, the CE is linked to a + VRF on the PE. The CE may send labeled packets to the PE. The label + has been previously assigned by the PE to the CE, and represents the + label switched path (LSP) from this CE to the remote CE via the + carrier's network. + + RFC 4364 [1] specifies for this case: "When the PE receives a labeled + packet from a CE, it must verify that the top label is one that was + distributed to that CE." This ensures that the CE can only use + labels that the PE correctly associates with the corresponding VPN. + Packets with incorrect labels will be discarded, and thus label + spoofing is impossible. + + The use of label maps on the PE leaves the control of the label + information entirely with the PE, so that this has no impact on the + security of the solution. + + The packet underneath the top label will -- as in standard RFC 2547 + [7] networks -- remain local to the customer carrier's VPN and not be + inspected in the carriers' carrier core. Potential spoofing of + subsequent labels or IP addresses remains local to the carrier's VPN; + it has no implication on the carriers' carrier core nor on other VPNs + in that core. This is specifically stated in section 6 of RFC 4364 + [1]. + + Note that if the PE and CE are interconnected using a shared layer 2 + infrastructure such as a switch, attacks are possible on layer 2, + which might enable a third party on the shared layer 2 network to + intrude into a VPN on that PE router. RFC 4364 [1] specifies + therefore that either all devices on a shared layer 2 network have to + be part of the same VPN, or the layer 2 network must be split + logically to avoid this issue. This will be discussed in more detail + in section 6. + + In the CsC architecture, the customer carrier needs to trust the + carriers' carrier for correct configuration and operation. The + customer of the carrier thus implicitly needs to trust both his + carrier and the carriers' carrier. + + In summary, a correctly configured carriers' carrier network provides + the same level of security as comparable layer 2 networks or + traditional RFC 2547 [7] networks. + + + + + + + +Behringer Informational [Page 13] + +RFC 4381 Security of BGP/MPLS IP VPNs February 2006 + + +4.2. Inter-Provider Backbones + + RFC 4364 [1] specifies three sub-cases for the inter-provider + backbone (Inter-AS) case. + + a) VRF-to-VRF connections at the autonomous system border routers + (ASBRs). + + In this case, each PE sees and treats the other PE as a CE; each will + not accept labeled packets, and there is no signaling between the PEs + other than inside the VRFs on both sides. Thus, the separation of + the VPNs on both sides and the security of those are the same as on a + single AS RFC 2547 [7] network. This has already been shown to have + the same security properties as traditional layer 2 VPNs. + + This solution has potential scalability issues in that the ASBRs need + to maintain a VRF per VPN, and all of the VRFs need to hold all + routes of the specific VPNs. Thus, an ASBR can run into memory + problems affecting all VPNs if one single VRF contains too many + routes. Thus, the service providers needs to ensure that the ASBRs + are properly dimensioned and apply appropriate security measures such + as limiting the number of prefixes per VRF. + + The two service providers connecting their VPNs in this way must + trust each other. Since the VPNs are separated on different + (sub-)interfaces, all signaling between ASBRs remains within a given + VPN. This means that dynamic cross-VPN security breaches are + impossible. It is conceivable that a service provider connects a + specific VPN to the wrong interface, thus interconnecting two VPNs + that should not be connected. This must be controlled operationally. + + b) EBGP redistribution of labeled VPN-IPv4 routes from AS to + neighboring AS. + + In this case, ASBRs on both sides hold full routing information for + all shared VPNs on both sides. This is not held in separate VRFs, + but in the BGP database. (This is typically limited to the Inter-AS + VPNs through filtering.) The separation inside the PE is maintained + through the use of VPN-IPv4 addresses. The control plane between the + ASBRs uses Multi-Protocol BGP (MP-BGP, RFC 2858 [8]). It exchanges + VPN routes as VPN-IPv4 addresses, the ASBR addresses as BGP next-hop + IPv4 addresses, and labels to be used in the data plane. + + The data plane is separated through the use of a single label, + representing a VRF or a subset thereof. RFC 4364 [1] states that an + ASBR should only accept packets with a label that it has assigned to + this router. This prevents the insertion of packets with unknown + labels, but it is possible for a service provider to use any label + + + +Behringer Informational [Page 14] + +RFC 4381 Security of BGP/MPLS IP VPNs February 2006 + + + that the ASBR of the other provider has passed on. This allows one + provider to insert packets into any VPN of the other provider for + which it has a label. + + This solution also needs to consider the security on layer 2 at the + interconnection. The RFC states that this type of interconnection + should only be implemented on private interconnection points. See + section 6 for more details. + + RFC 4364 [1] states that a trust relationship between the two + connecting ASes must exist for this model to work securely. + Effectively, all ASes interconnected in this way form a single zone + of trust. The VPN customer needs to trust all the service providers + involved in the provisioning of his VPN on this architecture. + + c) PEs exchange labeled VPN-IPv4 routes, ASBRs only exchange + loopbacks of PEs with labels. + + In this solution, there are effectively two control connections + between ASes. The route reflectors (RRs) exchange the VPN-IPv4 + routes via multihop eBGP. The ASBRs only exchange the labeled + addresses of those PE routers that hold VPN routes that are shared + between those ASes. This maintains scalability for the ASBRs, since + they do not need to know the VPN-IPv4 routes. + + In this solution, the top label specifies an LSP to an egress PE + router, and the second label specifies a VPN connected to this egress + PE. The security of the ASBR connection has the same constraints as + in solution b): An ASBR should only accept packets with top labels + that it has assigned to the other router, thus verifying that the + packet is addressed to a valid PE router. Any label, which was + assigned to the other ASBR, will be accepted. It is impossible for + an ASBR to distinguish between different egress PEs or between + different VPNs on those PEs. A malicious service provider of one AS + could introduce packets into any VPN on a PE of the other AS; it only + needs a valid LSP on its ASBR and PEs to the corresponding PE on the + other AS. The VPN label can be statistically guessed from the + theoretical label space, which allows unidirectional traffic into a + VPN. + + This means that such an ASBR-ASBR connection can only be made with a + trusted party over a private interface, as described in b). + + In addition, this solution exchanges labeled VPN-IPv4 addresses + between route reflectors (RRs) via MP-eBGP. The control plane itself + can be protected via routing authentication (RFC 2385 [6]), which + ensures that the routing information has been originated by the + expected RR and has not been modified in transit. The received VPN + + + +Behringer Informational [Page 15] + +RFC 4381 Security of BGP/MPLS IP VPNs February 2006 + + + information cannot be verified, as in the previous case. Thus, a + service provider can introduce bogus routes for any shared VPN. The + ASes need to trust each other to configure their respective networks + correctly. All ASes involved in this design form one trusted zone. + The customer needs to trust all service providers involved. + + The difference between case b) and case c) is that in b) the ASBRs + act as iBGP next-hops for their AS; thus, each SP needs to know of + the other SP's core only the addresses of the ASBRs. In case c), the + SPs exchange the loopback addresses of their PE routers; thus, each + SP reveals information to the other about its PE routers, and these + routers must be accessible from the other AS. As stated above, + accessibility does not necessarily mean insecurity, and networks + should never rely on "security through obscurity". This should not + be an issue if the PE routers are appropriately secured. However, + there is an increasing perception that network devices should + generally not be accessible. + + In addition, there are scalability considerations for case c). A + number of BGP peerings have to be made for the overall network + including all ASes linked this way. SPs on both sides need to work + together in defining a scalable architecture, probably with route + reflectors. + + In summary, all of these Inter-AS solutions logically merge several + provider networks. For all cases of Inter-AS configuration, all ASes + form a single zone of trust and service providers need to trust each + other. For the VPN customer, the security of the overall solution is + equal to the security of traditional RFC 2547 [7] networks, but the + customer needs to trust all service providers involved in the + provisioning of this Inter-AS solution. + +5. What BGP/MPLS IP VPNs Do Not Provide + +5.1. Protection against Misconfigurations of the Core and Attacks + 'within' the Core + + The security mechanisms discussed here assume correct configuration + of the network elements of the core network (PE and P routers). + Deliberate or inadvertent misconfiguration may result in severe + security leaks. + + Note that this paragraph specifically refers to the core network, + i.e., the PE and P elements. Misconfigurations of any of the + customer side elements such as the CE router are covered by the + security mechanisms above. This means that a potential attacker must + have access to either PE or P routers to gain advantage from + misconfigurations. If an attacker has access to core elements, or is + + + +Behringer Informational [Page 16] + +RFC 4381 Security of BGP/MPLS IP VPNs February 2006 + + + able to insert into the core additional equipment, he will be able to + attack both the core network and the connected VPNs. Thus, the + following is important: + + o To avoid the risk of misconfigurations, it is important that the + equipment is easy to configure and that SP staff have the + appropriate training and experience when configuring the network. + Proper tools are required to configure the core network. + o To minimise the risk of "internal" attacks, the core network must + be properly secured. This includes network element security, + management security, physical security of the service provider + infrastructure, access control to service provider installations, + and other standard SP security mechanisms. + + BGP/MPLS IP VPNs can only provide a secure service if the core + network is provided in a secure fashion. This document assumes this + to be the case. + + There are various approaches to control the security of a core if the + VPN customer cannot or does not want to trust the service provider. + IPsec from customer-controlled devices is one of them. The document + "CE-to-CE Member Verification for Layer 3 VPNs" [13] proposes a + CE-based authentication scheme using tokens, aimed at detecting + misconfigurations in the MPLS core. The document "MPLS VPN + Import/Export Verification" [12] proposes a similar scheme based on + using the MD5 routing authentication. Both schemes aim to detect and + prevent misconfigurations in the core. + +5.2. Data Encryption, Integrity, and Origin Authentication + + BGP/MPLS IP VPNs themselves do not provide encryption, integrity, or + authentication service. If these are required, IPsec should be used + over the MPLS infrastructure. The same applies to ATM and Frame + Relay: IPsec can provide these missing services. + +5.3. Customer Network Security + + BGP/MPLS IP VPNs can be secured so that they are comparable with + other VPN services. However, the security of the core network is + only one factor for the overall security of a customer's network. + Threats in today's networks do not come only from an "outside" + connection, but also from the "inside" and from other entry points + (modems, for example). To reach a good security level for a customer + network in a BGP/MPLS infrastructure, MPLS security is necessary but + not sufficient. The same applies to other VPN technologies like ATM + or Frame Relay. See also RFC 2196 [5] for more information on how to + secure a network. + + + + +Behringer Informational [Page 17] + +RFC 4381 Security of BGP/MPLS IP VPNs February 2006 + + +6. Layer 2 Security Considerations + + In most cases of Inter-AS or Carrier's Carrier solutions, a network + will be interconnected to other networks via a point-to-point private + connection. This connection cannot be interfered with by third + parties. It is important to understand that the use of any + shared-medium layer 2 technology for such interconnections, such as + Ethernet switches, may carry additional security risks. + + There are two types of risks with layer 2 infrastructure: + + a) Attacks against layer 2 protocols or mechanisms + + Risks in a layer 2 environment include many different forms of + Address Resolution Protocol (ARP) attacks, VLAN trunking attacks, or + Content Addressable Memory (CAM) overflow attacks. For example, ARP + spoofing allows an attacker to redirect traffic between two routers + through his device, gaining access to all packets between those two + routers. + + These attacks can be prevented by appropriate security measures, but + often these security concerns are overlooked. It is of the utmost + importance that if a shared medium (such as a switch) is used in the + above scenarios, that all available layer 2 security mechanisms are + used to prevent layer 2 based attacks. + + b) Traffic insertion attacks + + Where many routers share a common layer 2 network (for example, at an + Internet exchange point), it is possible for a third party to + introduce packets into a network. This has been abused in the past + on traditional exchange points when some service providers have + defaulted to another provider on this exchange point. In effect, + they are sending all their traffic into the other SP's network even + though the control plane (routing) might not allow that. + + For this reason, routers on exchange points (or other shared layer 2 + connections) should only accept non-labeled IP packets into the + global routing table. Any labeled packet must be discarded. This + maintains the security of connected networks. + + Some of the above designs require the exchange of labeled packets. + This would make it possible for a third party to introduce labeled + packets, which if correctly crafted might be associated with certain + VPNs on an BGP/MPLS IP VPN network, effectively introducing false + packets into a VPN. + + + + + +Behringer Informational [Page 18] + +RFC 4381 Security of BGP/MPLS IP VPNs February 2006 + + + The current recommendation is therefore to discard labeled packets on + generic shared-medium layer 2 networks such as Internet exchange + points (IXPs). Where labeled packets need to be exchanged, it is + strongly recommended to use private connections. + +7. Summary and Conclusions + + BGP/MPLS IP VPNs provide full address and traffic separation as in + traditional layer-2 VPN services. It hides addressing structures of + the core and other VPNs, and it is not possible to intrude into other + VPNs abusing the BGP/MPLS mechanisms. It is also impossible to + intrude into the MPLS core if this is properly secured. However, + there is a significant difference between BGP/MPLS-based IP VPNs and, + for example, FR- or ATM-based VPNs: The control structure of the core + is layer 3 in the case of MPLS. This caused significant skepticism + in the industry towards MPLS, since this might open the architecture + to DoS attacks from other VPNs or the Internet (if connected). + + As shown in this document, it is possible to secure a BGP/MPLS IP VPN + infrastructure to the same level of security as a comparable ATM or + FR service. It is also possible to offer Internet connectivity to + MPLS VPNs in a secure manner, and to interconnect different VPNs via + firewalls. Although ATM and FR services have a strong reputation + with regard to security, it has been shown that also in these + networks security problems can exist [14]. + + As far as attacks from within the MPLS core are concerned, all VPN + classes (BGP/MPLS, FR, ATM) have the same problem: If an attacker can + install a sniffer, he can read information in all VPNs, and if the + attacker has access to the core devices, he can execute a large + number of attacks, from packet spoofing to introducing new peer + routers. There are a number of precautionary measures outlined above + that a service provider can use to tighten security of the core, but + the security of the BGP/MPLS IP VPN architecture depends on the + security of the service provider. If the service provider is not + trusted, the only way to fully secure a VPN against attacks from the + "inside" of the VPN service is to run IPsec on top, from the CE + devices or beyond. + + This document discussed many aspects of BGP/MPLS IP VPN security. It + has to be noted that the overall security of this architecture + depends on all components and is determined by the security of the + weakest part of the solution. For example, a perfectly secured + static BGP/MPLS IP VPN network with secured Internet access and + secure management is still open to many attacks if there is a weak + remote access solution in place. + + + + + +Behringer Informational [Page 19] + +RFC 4381 Security of BGP/MPLS IP VPNs February 2006 + + +8. Security Considerations + + The entire document is discussing security considerations of the RFC + 4364 [1] architecture. + +9. Acknowledgements + + The author would like to thank everybody who has provided input to + this document. Specific thanks go to Yakov Rekhter, for his + continued strong support, and Eric Rosen, Loa Andersson, Alexander + Renner, Jim Guichard, Monique Morrow, Eric Vyncke, and Steve Simlo, + for their extended feedback and support. + +10. Normative References + + [1] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks + (VPNs)", RFC 4364, February 2006. + +11. Informative References + + [2] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. + Lear, "Address Allocation for Private Internets", BCP 5, + RFC 1918, February 1996. + + [3] Baker, F., Atkinson, R., and G. Malkin, "RIP-2 MD5 + Authentication", RFC 2082, January 1997. + + [4] Murphy, S., Badger, M., and B. Wellington, "OSPF with Digital + Signatures", RFC 2154, June 1997. + + [5] Fraser, B., "Site Security Handbook", RFC 2196, September 1997. + + [6] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 + Signature Option", RFC 2385, August 1998. + + [7] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, + March 1999. + + [8] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, + "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. + + [9] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label + Switching Architecture", RFC 3031, January 2001. + + [10] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL + Security Mechanism (GTSM)", RFC 3682, February 2004. + + + + + +Behringer Informational [Page 20] + +RFC 4381 Security of BGP/MPLS IP VPNs February 2006 + + + [11] Fang, L., "Security Framework for Provider-Provisioned Virtual + Private Networks (PPVPNs)", RFC 4111, July 2005. + + [12] Behringer, M., Guichard, J., and P. Marques, "MPLS VPN + Import/Export Verification", Work in Progress, June 2004. + + [13] Bonica, R. and Y. Rekhter, "CE-to-CE Member Verification for + Layer 3 VPNs", Work in Progress, September 2003. + + [14] DataComm, "Data Communications Report, Vol 15, No 4: Frame + Relay and ATM: Are they really secure?", February 2000. + +Author's Address + + Michael H. Behringer + Cisco Systems Inc + Village d'Entreprises Green Side + 400, Avenue Roumanille, Batiment T 3 + Biot - Sophia Antipolis 06410 + France + + EMail: mbehring@cisco.com + URI: http://www.cisco.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Behringer Informational [Page 21] + +RFC 4381 Security of BGP/MPLS IP VPNs February 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78 and at www.rfc-editor.org/copyright.html, and + except as set forth therein, the authors retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Behringer Informational [Page 22] + |