Network Working Group                                       M. Behringer
Request for Comments: 4381                             Cisco Systems Inc
Category: Informational                                    February 2006
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)

BGP/MPLS IP虚拟专用网(VPN)的安全性分析

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).




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.

IETF曾考虑过本RFC的内容,因此它可能类似于当前正在进行的IETF工作或已发布的IETF工作。本RFC不适用于任何级别的互联网标准。IETF不承认本RFC适用于任何目的的任何知识,特别注意到,发布决定并非基于IETF对安全、拥塞控制或与已部署协议的不当交互等事项的审查。RFC编辑已自行决定发布本文件。本RFC的读者应谨慎评估其实施和部署价值。有关更多信息,请参阅RFC 3932。



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.

本文档分析RFC 4364中描述的BGP/MPLS IP虚拟专用网(VPN)体系结构的安全性,以利于服务提供商和VPN用户。

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.

分析表明,BGP/MPLS IP VPN网络可以与使用异步传输模式(ATM)或帧中继的传统第二层VPN服务一样安全。

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
   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
1. Scope and Introduction
1. 范围和导言

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.

随着多协议标签交换(MPLS)成为提供IP虚拟专用网(VPN)服务的更广泛技术,BGP/MPLS IP VPN体系结构的安全性越来越受到服务提供商和VPN客户的关注。本文档概述了RFC 4364[1]中描述的BGP/MPLS IP VPN体系结构的安全性,并将其与传统的第2层服务(如ATM或帧中继)的安全性进行了比较。

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.

术语“MPLS核心”在本文档中定义为提供BGP/MPLS IP VPN服务的一组提供商边缘(PE)和提供商(P)路由器,通常由单个服务提供商(SP)控制。本文档假设MPLS核心网络是可信和安全的。因此,它没有解决基本的安全问题,例如保护网络元件免受未经授权的访问、核心配置错误或核心内部攻击。不希望信任服务提供商网络的客户必须在MPLS基础设施上使用额外的安全机制,如IPsec。

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.

本文档仅分析BGP/MPLS IP VPN的安全特性,而不是一般路由协议的安全性。除强调MPLS VPN与IPsec的结合外,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.

系统的整体安全性包括三个方面:系统的体系结构、实现和操作。这些方面中的任何一个都可能存在安全问题。本文档仅分析BGP/MPLS IP VPN的体系结构安全性,而非实施或操作安全问题。

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].

本文件针对服务提供商和企业的技术人员。理解本文件需要具备RFC 4364[1]中所述的基本BGP/MPLS IP VPN体系结构的知识。有关特定的第3层VPN术语和参考模型,请参阅[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.

本文件第2节规定了VPN用户可能具有的典型VPN要求,第3节分析了RFC 4364[1]如何满足这些要求。第4节讨论了多AS(自治系统)MPLS体系结构的具体安全问题,第5节列出了该体系结构未涵盖的安全特性,因此需要单独解决。第6节重点介绍第2层上可能影响BGP/MPLS IP VPN服务整体安全性的潜在安全问题。第7节总结了本文件的调查结果。

2. Security Requirements of VPN Networks
2. VPN网络的安全要求

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.

提供任何类型VPN服务的服务提供商和使用VPN服务的客户都有特定的安全需求。大多数情况下,他们将基于MPLS的解决方案与传统的基于第2层的VPN解决方案(如帧中继和ATM)进行比较,因为它们已被广泛部署和接受。本节概述了VPN网络的典型安全要求。以下部分讨论BGP/MPLS IP VPN是否以及如何满足MPLS核心和连接的VPN的这些要求。

2.1. Address Space, Routing, and Traffic Separation
2.1. 地址空间、路由和流量分离

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.

o 任何VPN必须能够使用与任何其他VPN相同的地址空间。o任何VPN必须能够使用与MPLS核心相同的地址空间。o来自一个VPN的流量(包括路由流量)不得流向另一个VPN。o一个VPN实例的路由信息以及该信息的分发和处理必须独立于任何其他VPN实例。o对于一个VPN实例,路由信息以及该信息的分发和处理必须独立于核心。

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.


2.2. Hiding the Core Infrastructure
2.2. 隐藏核心基础设施

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.

核心网络的内部结构(MPLS PE和P元素)不应在外部可见。虽然违反这一要求本身并不是一个安全问题,但许多服务提供商认为,如果内部地址和网络结构对外部世界隐藏,这是有利的。一个论点是,如果攻击者知道路由器地址,那么针对核心路由器的拒绝服务(DoS)攻击更容易实施。地址总是可以猜测的,但如果地址未知,攻击就更加困难。核心对于外部世界来说应该是不可见的,就像可比较的第2层基础设施(例如,帧中继、ATM)一样。核心网络元素也不能从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
2.3. 抵抗攻击

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.

有两种基本类型的攻击:DoS攻击,授权用户无法使用资源;入侵,未授权用户可以使用资源。BGP/MPLS IP VPN网络必须提供至少与当前第2层网络相同的保护级别,以抵御两种形式的攻击。

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.


2.4. Impossibility of Label Spoofing
2.4. 标签欺骗的不可能性

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.

根据CE路由器连接到PE路由器的方式,可能会使用第2层攻击机制(如802.1Q标签欺骗或ATM VPI/VCI欺骗)入侵连接到同一PE的VPN。第6节将讨论第2层安全问题。

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
3. BGP/mplsipvpn安全性分析

In this section, the BGP/MPLS IP VPN architecture is analysed with respect to the security requirements listed above.

在本节中,将根据上述安全要求分析BGP/MPLS IP VPN体系结构。

3.1. Address Space, Routing, and Traffic Separation
3.1. 地址空间、路由和流量分离

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.

BGP/MPLS允许不同的IP VPN使用相同的地址空间,也可以是专用地址空间(RFC 1918[2])。这是通过向每个IPv4路由添加64位路由识别器(RD)来实现的,使VPN唯一地址在MPLS核心中也是唯一的。此“扩展”地址也称为“VPN-IPv4地址”。因此,BGP/MPLS IP VPN服务的客户不需要更改其当前的寻址计划。

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


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.

在多协议BGP(路由识别器(RDs))中,通过独特的VPN标识符保持从核心到其他PE路由器的分离。VPN路由(包括RD)通过多协议BGP(MP-BGP,RFC 2858[8])在PE路由器之间通过核心进行独家交换。这些BGP路由更新不会重新分发到核心中,而是仅分发到其他PE路由器,在这些路由器中,信息再次保存在特定于VPN的VRF中。因此,通过BGP/MPLS网络的路由是每个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.

考虑到BGP/MPLS IP VPN核心网络中的寻址、路由和流量分离,可以假设该体系结构在这方面提供了与第2层VPN相同的安全性。除非已明确配置,否则不可能从VPN或核心入侵到另一个VPN。

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.

如果需要保密,可以通过在网络上覆盖加密服务在BGP/MPLS IP VPN中实现。但是,加密不是BGP/MPLS IP VPN上的标准服务。另见第5.2节。

3.2. Hiding of the BGP/MPLS IP VPN Core Infrastructure
3.2. 隐藏BGP/MPLS IP VPN核心基础设施

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


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.

MPLS不会将不必要的信息泄露给外部,甚至不会泄露给客户VPN。内核的寻址可以通过专用地址(RFC 1918[2])或公共地址完成。由于VPN和Internet的接口均为BGP,因此无需透露任何内部信息。对于PE和CE之间的路由协议,唯一需要的信息是PE路由器的地址。如果不需要动态路由,可以在PE和CE之间配置无编号接口上的静态路由。通过这种措施,BGP/MPLS IP VPN核心可以完全隐藏。

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.

客户VPN必须公布其到BGP/MPLS IP VPN核心的路由(动态或静态),以确保其VPN的可达性。在某些情况下,VPN用户希望服务提供商不了解VPN的寻址计划。必须注意以下几点:首先,核心已知的信息不是关于特定主机的,而是关于网络(路由);这提供了一定程度的抽象。其次,在仅VPN的BGP/MPLS IP VPN网络(无互联网接入)中,这相当于现有的第2层模型,其中客户必须信任服务提供商。此外,在帧中继或ATM网络中,可以在核心网络上看到有关VPN的路由和寻址信息。

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


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.

总之,在纯MPLS-VPN服务中,不提供Internet访问,信息隐藏与在可比的FR或ATM网络上一样好。不向第三方或互联网透露地址信息。如果客户选择通过BGP/MPLS IP VPN核心访问互联网,他将不得不透露正常互联网服务所需的相同信息。NAT可用于进一步的模糊性。可以从Internet访问会自动使客户网络面临其他安全威胁。必须部署适当的安全机制,如防火墙和入侵检测系统。这适用于任何通过MPLS或直接进行的Internet访问。

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.

不与Internet互连的BGP/MPLS IP VPN网络具有与FR或ATM VPN网络相同的安全性。通过从MPLS云进行互联网访问,服务提供商必须向下一个提供商透露(对等PE路由器的)至少一个IP地址,从而向外部世界透露。

3.3. Resistance to Attacks
3.3. 抵抗攻击

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:

第3.1节显示不可能直接入侵其他VPN。另一种可能是攻击MPLS核心并尝试从那里攻击其他VPN。如上所示,直接寻址P路由器是不可能的。唯一可以从VPN或Internet访问的地址是PE路由器的对等地址。因此,有两种基本方式可以攻击BGP/MPLS IP VPN核心:

1. By attacking the PE routers directly. 2. By attacking the signaling mechanisms of MPLS (mostly routing).

1. 通过直接攻击PE路由器。2.通过攻击MPLS的信令机制(主要是路由)。

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).

要攻击BGP/MPLS IP VPN网络的一个元素,首先需要知道该元素的地址。如第3.2节所述,BGP/MPLS IP VPN核心的寻址结构对外隐藏。因此,攻击者无法知道要攻击的核心中任何路由器的IP地址。攻击者可以猜测地址并向这些地址发送数据包。然而,由于MPLS的地址分离,每个传入数据包将被视为属于客户的地址空间。因此,即使猜测IP地址,也不可能到达内部路由器。此规则只有一个例外,即PE路由器的对等接口。PE的此地址是来自外部(VPN或Internet)的唯一攻击点。

The routing between a VPN and the BGP/MPLS IP VPN core can be configured two ways:

VPN和BGP/MPLS IP VPN核心之间的路由可以通过两种方式配置:

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.

1. 静态:在这种情况下,PE路由器配置为到每个CE后面的网络的静态路由,CE配置为静态指向VPN其他部分中任何网络的PE路由器(主要是默认路由)。有两个子情况:静态路由可以指向PE路由器的IP地址或CE路由器的接口(例如serial0)。2.动态:路由协议(例如路由信息协议(RIP)、OSPF、BGP)用于在每个对等点的CE和PE之间交换路由信息。

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.

o 只接受路由协议数据包,并且只接受来自CE路由器的数据包。PE路由器的每个CE接口上的入站ACL应只允许将协议数据包从CE路由到PE。o通过为路由协议配置MD5身份验证。例如,这适用于BGP(RFC 2385[6])、OSPF(RFC 2154[4])和RIP2(RFC 2082[3])。这避免了来自除CE路由器之外的客户网络其他部分的数据包被欺骗。它要求服务提供商和客户就所有CE和PE路由器之间的共享秘密达成一致。有必要为所有VPN客户执行此操作。仅为具有最高安全要求的客户这样做是不够的。

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.

o 通过配置路由协议的参数来进一步保护此通信。例如,应尽可能限制路由更新的速率(在BGP中通过阻尼);应尽可能配置每个VRF和每个路由邻居接受的最大路由数;所有受支持的协议都应使用广义TTL安全机制(GTSM;RFC 3682[10])。

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
3.4. 标签欺骗

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.


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.

出于安全原因,PE路由器不应接受来自CE路由器的带有标签的数据包。RFC 3031[9]规定:“因此,当接收到带有无效传入标签的标记数据包时,必须将其丢弃,除非通过某种方式(不在当前文档的范围内)确定未标记的转发不会造成任何伤害。”由于在CE接口上接受标签可能会允许将数据包传递到其他VPN,因此RFC不允许这样做。

Thus, it is impossible for an outside attacker to send labeled packets into the BGP/MPLS IP VPN core.

因此,外部攻击者不可能将带标签的数据包发送到BGP/MPLS IP VPN核心。

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
3.5. 与ATM/FR VPN的比较

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.

ATM和FR VPN服务在安全方面享有很高的声誉。尽管ATM和FR VPN可以以安全的方式提供,但据报道,这些技术也可能存在安全漏洞[14]。与任何其他网络技术一样,ATM/FR的安全性取决于网络的安全配置,错误也可能导致安全问题。

4. Security of Advanced BGP/MPLS IP VPN Architectures
4. 高级BGP/MPLS IP VPN体系结构的安全性

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 2547[7]中描述的BGP/MPLS IP VPN体系结构将PE-CE接口定义为从服务提供商网络中看到的唯一外部接口。在这种情况下,PE将CE视为不受信任的,并且只接受来自CE的IP数据包。IP地址范围被视为属于CE的VPN,因此PE保持对VPN分离的完全控制。

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.

RFC 4364[1]随后定义了一个更复杂的体系结构,具有更开放的接口。这些接口允许在服务提供商控制之外的设备之间交换标签信息和标签数据包。本节讨论此高级体系结构的安全含义。

4.1. Carriers' Carrier
4.1. 承运人的承运人

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.

RFC 4364[1]针对这种情况规定:“当PE从CE接收到带标签的数据包时,它必须验证顶部标签是否是分发给该CE的标签。”这确保了CE只能使用PE与相应VPN正确关联的标签。标签不正确的数据包将被丢弃,因此标签欺骗是不可能的。

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].

与标准RFC 2547[7]网络一样,顶部标签下的数据包将保持在客户运营商VPN的本地,并且不会在运营商的运营商核心中进行检查。对后续标签或IP地址的潜在欺骗仍然存在于运营商的VPN本地;它不影响运营商的运营商核心,也不影响该核心中的其他VPN。RFC 4364[1]第6节中明确规定了这一点。

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.

请注意,如果PE和CE使用共享第2层基础设施(如交换机)互连,则第2层上可能存在攻击,这可能使共享第2层网络上的第三方入侵该PE路由器上的VPN。因此,RFC 4364[1]规定,共享第2层网络上的所有设备必须是同一VPN的一部分,或者必须对第2层网络进行逻辑拆分以避免此问题。第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.

总之,正确配置的运营商运营商网络提供了与可比的第2层网络或传统RFC 2547[7]网络相同的安全级别。

4.2. Inter-Provider Backbones
4.2. 提供程序间主干网

RFC 4364 [1] specifies three sub-cases for the inter-provider backbone (Inter-AS) case.

RFC 4364[1]为跨提供商主干网(inter-AS)案例指定了三个子案例。

a) VRF-to-VRF connections at the autonomous system border routers (ASBRs).

a) 自主系统边界路由器(ASBR)上的VRF到VRF连接。

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.

在这种情况下,每个PE将另一个PE视为CE;每一个都不接受标记的数据包,并且除了双方的VRFs内部之外,PEs之间没有信令。因此,双方VPN的分离及其安全性与单个as RFC 2547[7]网络上的相同。这已经被证明具有与传统的第2层VPN相同的安全属性。

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.

b) EBGP重新分配从AS到相邻AS的标记VPN-IPv4路由。

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.

在这种情况下,双方的ASBR都持有双方所有共享VPN的完整路由信息。这不是保存在单独的VRF中,而是保存在BGP数据库中。(这通常通过过滤限制为内部AS VPN。)通过使用VPN-IPv4地址保持PE内部的分离。ASBR之间的控制平面使用多协议BGP(MP-BGP,RFC 2858[8])。它将VPN路由交换为VPN-IPv4地址,将ASBR地址交换为BGP下一跳IPv4地址,并在数据平面中使用标签。

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

通过使用表示VRF或其子集的单个标签来分隔数据平面。RFC 4364[1]指出ASBR应仅接受其已分配给该路由器的标签的数据包。这可以防止插入带有未知标签的数据包,但服务提供商可以使用任何标签

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.

RFC 4364[1]指出,两个连接ASE之间必须存在信任关系,此模型才能安全工作。实际上,所有以这种方式互连的ASE都形成了一个单一的信任区。VPN客户需要信任在此体系结构上提供其VPN所涉及的所有服务提供商。

c) PEs exchange labeled VPN-IPv4 routes, ASBRs only exchange loopbacks of PEs with labels.

c) PEs交换标记为VPN-IPv4路由,ASBR仅交换带有标签的PEs环回。

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

此外,此解决方案通过MP eBGP在路由反射器(RRs)之间交换标记为VPN-IPv4的地址。可以通过路由认证(RFC 2385[6])保护控制平面本身,该认证确保路由信息是由预期RR发起的,并且在传输过程中未被修改。接收到的VPN

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.

总之,所有这些AS间解决方案在逻辑上合并了多个提供商网络。对于所有AS间配置的情况,所有AS都形成一个信任区域,服务提供商需要相互信任。对于VPN客户,整体解决方案的安全性与传统RFC 2547[7]网络的安全性相同,但客户需要信任提供此AS间解决方案所涉及的所有服务提供商。

5. What BGP/MPLS IP VPNs Do Not Provide

5.1. Protection against Misconfigurations of the Core and Attacks 'within' the Core

5.1. 防止内核配置错误和内核“内部”攻击

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


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.

o 为避免错误配置的风险,重要的是设备易于配置,并且SP员工在配置网络时具有适当的培训和经验。需要适当的工具来配置核心网络。o为将“内部”攻击的风险降至最低,必须对核心网络进行适当保护。这包括网元安全、管理安全、服务提供商基础设施的物理安全、对服务提供商安装的访问控制以及其他标准SP安全机制。

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.

只有以安全的方式提供核心网络,BGP/MPLS IP VPN才能提供安全服务。本文件假设情况就是这样。

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.

如果VPN客户不能或不想信任服务提供商,则有多种方法来控制核心的安全性。来自客户控制设备的IPsec就是其中之一。文件“第3层VPN的CE-to-CE成员验证”[13]提出了一种使用令牌的基于CE的认证方案,旨在检测MPLS核心中的错误配置。文件“MPLS VPN导入/导出验证”[12]提出了基于使用MD5路由验证的类似方案。这两种方案都旨在检测和防止内核中的错误配置。

5.2. Data Encryption, Integrity, and Origin Authentication
5.2. 数据加密、完整性和源身份验证

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.

BGP/MPLS IP VPN本身不提供加密、完整性或身份验证服务。如果需要,应在MPLS基础设施上使用IPsec。这同样适用于ATM和帧中继:IPsec可以提供这些缺失的服务。

5.3. Customer Network Security
5.3. 客户网络安全

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.

BGP/MPLS IP VPN可以得到保护,以便与其他VPN服务相比较。然而,核心网络的安全性只是客户网络整体安全性的一个因素。当今网络中的威胁不仅来自“外部”连接,还来自“内部”和其他入口点(例如调制解调器)。为了在BGP/MPLS基础设施中为客户网络达到良好的安全级别,MPLS安全是必要的,但还不够。这同样适用于其他VPN技术,如ATM或帧中继。有关如何保护网络的更多信息,请参见RFC 2196[5]。

6. Layer 2 Security Considerations
6. 第2层安全注意事项

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

a) 针对第2层协议或机制的攻击

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

b) 流量插入攻击

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.

上述一些设计要求交换标记的数据包。这将使第三方有可能引入带标签的数据包,如果制作正确,这些数据包可能与BGP/MPLS IP VPN网络上的某些VPN相关联,从而有效地将虚假数据包引入VPN。

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
7. 摘要和结论

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).

BGP/MPLS IP VPN与传统的第二层VPN服务一样,提供完整的地址和流量分离。它隐藏了核心和其他VPN的寻址结构,并且不可能滥用BGP/MPLS机制入侵其他VPN。如果MPLS核心得到适当的保护,也不可能侵入。然而,基于BGP/MPLS的IP VPN与基于FR或ATM的VPN之间存在显著差异:对于MPLS,核心的控制结构是第3层。这引起了业界对MPLS的极大怀疑,因为这可能会使体系结构受到来自其他VPN或Internet(如果已连接)的DoS攻击。

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].

如本文档所示,可以将BGP/MPLS IP VPN基础设施的安全级别与可比ATM或FR服务的安全级别相同。还可以以安全的方式向MPLS VPN提供Internet连接,并通过防火墙互连不同的VPN。尽管ATM和FR服务在安全方面享有很高的声誉,但已经证明,在这些网络中也可能存在安全问题[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.

就MPLS核心内的攻击而言,所有VPN类(BGP/MPLS、FR、ATM)都有相同的问题:如果攻击者可以安装嗅探器,他可以读取所有VPN中的信息,如果攻击者可以访问核心设备,他可以执行大量攻击,从包欺骗到引入新的对等路由器。服务提供商可以使用上面概述的一些预防措施来加强核心的安全性,但BGP/MPLS IP VPN体系结构的安全性取决于服务提供商的安全性。如果服务提供商不受信任,则针对来自VPN服务“内部”的攻击完全保护VPN的唯一方法是在顶部、CE设备或其他设备上运行IPsec。

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.

本文档讨论了BGP/MPLS IP VPN安全的许多方面。必须注意的是,此体系结构的总体安全性取决于所有组件,并由解决方案最薄弱部分的安全性决定。例如,如果存在薄弱的远程访问解决方案,则具有安全的Internet访问和安全管理的完全安全的静态BGP/MPLS IP VPN网络仍然会受到许多攻击。

8. Security Considerations
8. 安全考虑

The entire document is discussing security considerations of the RFC 4364 [1] architecture.

整个文档都在讨论RFC 4364[1]体系结构的安全注意事项。

9. Acknowledgements
9. 致谢

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.

作者要感谢为本文件提供投入的每一个人。特别感谢亚科夫·雷克特(Yakov Rekhter)的持续大力支持,以及埃里克·罗森(Eric Rosen)、洛亚·安德森(Loa Andersson)、亚历山大·雷纳(Alexander Renner)、吉姆·吉查德(Jim Guichard)、莫妮克·莫罗(Monique Morrow)、埃里克·温克(Eric Vyncke)和史蒂夫·西姆洛(Steve Simlo)的长期反馈。

10. Normative References
10. 规范性引用文件

[1] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.

[1] Rosen,E.和Y.Rekhter,“BGP/MPLS IP虚拟专用网络(VPN)”,RFC 4364,2006年2月。

11. Informative References
11. 资料性引用

[2] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.

[2] Rekhter,Y.,Moskowitz,R.,Karrenberg,D.,Groot,G.,和E.Lear,“私人互联网地址分配”,BCP 5,RFC 1918,1996年2月。

[3] Baker, F., Atkinson, R., and G. Malkin, "RIP-2 MD5 Authentication", RFC 2082, January 1997.

[3] Baker,F.,Atkinson,R.和G.Malkin,“RIP-2 MD5认证”,RFC 2082,1997年1月。

[4] Murphy, S., Badger, M., and B. Wellington, "OSPF with Digital Signatures", RFC 2154, June 1997.

[4] Murphy,S.,Badger,M.,和B.Wellington,“具有数字签名的OSPF”,RFC 2154,1997年6月。

[5] Fraser, B., "Site Security Handbook", RFC 2196, September 1997.

[5] Fraser,B.,“现场安全手册”,RFC 2196,1997年9月。

[6] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.

[6] Heffernan,A.,“通过TCP MD5签名选项保护BGP会话”,RFC 2385,1998年8月。

[7] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March 1999.

[7] Rosen,E.和Y.Rekhter,“BGP/MPLS VPN”,RFC 2547,1999年3月。

[8] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.

[8] Bates,T.,Rekhter,Y.,Chandra,R.,和D.Katz,“BGP-4的多协议扩展”,RFC 28582000年6月。

[9] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.

[9] Rosen,E.,Viswanathan,A.,和R.Callon,“多协议标签交换体系结构”,RFC 30312001年1月。

[10] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL Security Mechanism (GTSM)", RFC 3682, February 2004.

[10] Gill,V.,Heasley,J.,和D.Meyer,“广义TTL安全机制(GTSM)”,RFC 3682,2004年2月。

[11] Fang, L., "Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4111, July 2005.

[11] Fang,L.“提供商提供的虚拟专用网络(PPVPN)的安全框架”,RFC 4111,2005年7月。

[12] Behringer, M., Guichard, J., and P. Marques, "MPLS VPN Import/Export Verification", Work in Progress, June 2004.

[12] Behringer,M.,Guichard,J.,和P.Marques,“MPLS VPN导入/导出验证”,正在进行的工作,2004年6月。

[13] Bonica, R. and Y. Rekhter, "CE-to-CE Member Verification for Layer 3 VPNs", Work in Progress, September 2003.

[13] Bonica,R.和Y.Rekhter,“第3层VPN的CE对CE成员验证”,正在进行的工作,2003年9月。

[14] DataComm, "Data Communications Report, Vol 15, No 4: Frame Relay and ATM: Are they really secure?", February 2000.

[14] DataComm,“数据通信报告,第15卷,第4期:帧中继和ATM:它们真的安全吗?”,2000年2月。

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

Michael H.Behringer Cisco Systems Inc.法国索菲亚安提波利斯(Sophia Antipolis)毕奥(T 3 Biot)鲁马尼尔大道绿边400号企业村06410


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, and except as set forth therein, the authors retain all their rights.

本文件受BCP 78和中包含的权利、许可和限制的约束,除其中规定外,作者保留其所有权利。



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.

IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围,或此类权利下的任何许可可能或可能不可用的程度,不采取任何立场;它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息,请参见BCP 78和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


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




Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).