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).
版权所有（C）互联网协会（2006年）。
IESG Note
IESG注释
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。
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.
本文档分析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
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节总结了本文件的调查结果。
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的这些要求。
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:
假定同一VPN服务的非交叉第3层VPN具有独立的地址空间。例如，两个不相交的VPN可能各自使用相同的10/8网络地址而不发生冲突。此外，来自一个VPN的流量决不能进入另一个VPN。这意味着路由协议信息的分离，因此每个VPN的路由表也必须是分离的。明确地：
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.
从安全角度来看，基本要求是防止发送到给定VPN内主机a.b.c.d的数据包到达另一个VPN或核心中具有相同地址的主机，并防止将数据包路由到另一个VPN，即使它不包含该目标地址。
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.
L3VPN安全框架[11]中定义的保密性要求超出了VPN的简单隔离，并提供了防止任何传输介质上窃听的保护。加密是用于提供机密性的机制。本文档将保密性视为可选的VPN要求，因为许多现有VPN部署不加密传输流量。
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.
安全不应完全依赖于隐蔽性，即信息的隐藏。如果已知实现，则服务应该同样安全。然而，市场强烈认为隐藏细节是有利的。这一点解决了市场感知问题。
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.
对于入侵，有两种基本的方法来保护网络：第一，强化可能被滥用的协议（例如，Telnet进入路由器），第二，使网络尽可能不可访问。如上所述，这是通过组合数据包过滤/防火墙和地址隐藏来实现的。
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.
DoS攻击更容易执行，因为一个已知的IP地址可能足以攻击机器。这可以通过使用正常的“允许”流量来实现，但使用高于正常的数据包速率，这样其他用户就无法访问目标机器。抵御这种攻击的唯一方法是确保无法访问机器，同样是通过数据包过滤和地址隐藏。
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.
本文档集中于保护核心网络免受来自“外部”的攻击，即互联网和连接的VPN。此处不讨论针对“内部”攻击的保护，即对核心网络具有逻辑或物理访问权限的攻击者。
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.
假设上面讨论的地址和流量分离，攻击者可能会尝试通过插入带有他不“拥有”标签的数据包来访问其他VPN。这可以从外部完成，即，另一个客户边缘（CE）路由器，或从互联网，或从MPLS核心内部完成。后一种情况（从核心内部）将不讨论，因为我们假设核心网络是安全提供的。如果需要针对不安全的核心进行保护，则有必要跨MPLS基础设施（至少从CE到CE）使用IPsec等安全协议，因为PEs属于核心。
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.
要求VPN不能滥用MPLS标签机制或协议来获得对其他VPN或核心的未经授权访问。
In this section, the BGP/MPLS IP VPN architecture is analysed with respect to the security requirements listed above.
在本节中，将根据上述安全要求分析BGP/MPLS IP VPN体系结构。
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
每个PE路由器为每个连接的VPN维护一个单独的虚拟路由和转发实例（VRF）。VRF包括该VPN的地址以及CE路由器与之对等的PE路由器的地址。VRF的所有地址，包括这些PE地址，在逻辑上属于VPN，并且可以从VPN访问。如果在PE和CE路由器之间使用静态路由，则VPN可以访问PE地址这一事实不是问题，因为可以部署包过滤器来阻止对PE路由器上VRF的所有地址的访问。如果使用动态路由协议，CE路由器需要配置核心中对等PE路由器的地址。在服务提供商管理
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.
CE路由器作为CPE，这对客户来说是不可见的。CE-PE链路上的地址空间（包括对等PE地址）被视为VPN地址空间的一部分。由于地址空间可以在VPN之间重叠，CE-PE链路地址可以在VPN之间重叠。出于实际管理考虑，SP通常从全局池处理CE-PE链路，从而保持整个核心的唯一性。
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.
也可以实现VPN之间的路由分离。每个VRF由一个VPN通过静态配置的路由或通过PE和CE路由器之间运行的路由协议填充路由。由于每个VPN都与单独的VRF相关联，因此PE路由器上的VPN之间没有干扰。
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.
在数据平面上，业务分离是通过入口PE预挂VPN特定标签来实现的。带有VPN标签的分组通过核心发送到出口PE，其中VPN标签用于选择出口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节。
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
服务提供商和最终客户通常不希望他们的网络拓扑向外界透露。这使得攻击更难执行：如果攻击者不知道受害者的地址，他只能猜测要攻击的IP地址。由于大多数DoS攻击不向攻击者提供直接反馈，因此很难攻击网络。必须特别提到这一点
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.
使用已知的IP地址，潜在的攻击者可以更容易地对该设备发起DoS攻击。因此，理想的做法是不向外界透露任何有关内部网络的信息。这适用于客户网络和核心。还必须采取一些额外的安全措施：最重要的是，广泛的数据包过滤。
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.
出于安全原因，建议任何核心网络过滤从“外部”（互联网或连接的VPN）发送到核心基础设施的数据包。这使得攻击核心变得非常困难，尽管一些功能（如ping核心路由器）将丢失。跨核心的Traceroute仍然可以工作，因为它在核心之外寻址一个目的地。
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
在具有共享互联网接入的VPN服务中，服务提供商通常会向其上游或对等提供商宣布希望使用互联网的客户的路由。如果VPN客户使用公共地址空间，则可以直接执行此操作，或者通过网络地址转换（NAT）来隐藏客户网络的寻址信息。在这两种情况下，客户透露的信息都不会比一般互联网服务透露的信息多。核心信息不会被披露，除非
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.
与Internet进行对等的PE路由器的对等地址。这些地址必须像在传统的IP主干网中一样受到保护。
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地址，从而向外部世界透露。
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.
对于指向接口的静态路由，CE路由器不需要知道核心网络甚至PE路由器的任何IP地址。这样做的缺点是需要更广泛的（静态）配置，但却是最安全的选择。在这种情况下，还可以在PE接口上配置数据包过滤器，以拒绝向PE接口发送任何数据包。这可以保护路由器和整个核心免受攻击。
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.
在所有其他情况下，每个CE路由器至少需要知道核心中PE路由器的路由器ID（RID，即对等IP地址），因此具有攻击的潜在目的地。人们可以想象对路由器上运行的各种服务的各种攻击。实际上，通过使用访问控制列表（ACL），可以将通过CE-PE接口对PE路由器的访问限制为所需的路由协议。这将攻击点限制为一个路由协议，例如BGP。潜在的攻击可能是发送大量路由，或用路由更新淹没PE路由器。但是，这两种情况都可能导致拒绝服务，而不是未经授权的访问。
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:
为了降低这种风险，有必要在PE路由器上配置路由协议以尽可能安全地运行。这可以通过多种方式实现：
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.
总之，不可能从一个VPN入侵其他VPN或核心。然而，从理论上讲，攻击路由协议端口以对PE路由器执行DoS攻击是可能的。这反过来可能会对该PE路由器上的其他VPN产生负面影响。因此，PE路由器必须非常安全，尤其是在其与CE路由器的接口上。ACL必须配置为仅限制对路由协议端口的访问，并且只能从CE路由器进行访问。其他路由协议的安全机制，如MD5身份验证、最大前缀限制和生存时间（TTL）安全机制，应在所有PE-CE对等上使用。有了所有这些安全措施，唯一可能的攻击就是针对路由协议本身的DoS攻击。BGP在协议中内置了许多对策，如前缀过滤和阻尼，以帮助提高稳定性。追踪此类潜在DoS攻击的来源也很容易。如果没有CEs和PEs之间的动态路由，安全性相当于ATM或帧中继网络的安全性。
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.
与IP欺骗攻击类似，攻击者伪造数据包的源IP地址，理论上也可能伪造MPLS数据包的标签。在第一部分中，假设核心网络是可信的。如果无法做出此假设，则必须在MPLS云上运行IPsec。因此，在本节中，重点在于是否可能从外部（即从VPN（CE路由器）或从互联网）将带有伪造标签的数据包插入MPLS网络。
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.
CE路由器与其对等PE路由器之间的接口为IP接口，即无标签。CE路由器不知道MPLS核心，认为它正在向另一个路由器发送IP数据包。“智能”在PE设备中完成，根据配置，选择标签并将其挂起到数据包上。这是所有PE路由器、CE路由器以及上游服务提供商的情况。所有进入MPLS云的接口只需要IP数据包，不需要标签。
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.
仍然存在欺骗发送到MPLS核心的数据包的IP地址的可能性。由于PE路由器内部存在严格的地址分离，并且每个VPN都有自己的VRF，这只会损害来自伪造数据包的VPN；也就是说，VPN客户只能攻击自己。MPLS不会在这里增加任何安全风险。
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.
由于在提供商之间的接口上，通常交换带有标签的数据包，因此内部AS和运营商的运营商情况是特殊情况。有关这些体系结构的分析，请参见第4节。
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的安全性取决于网络的安全配置，错误也可能导致安全问题。
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]随后定义了一个更复杂的体系结构，具有更开放的接口。这些接口允许在服务提供商控制之外的设备之间交换标签信息和标签数据包。本节讨论此高级体系结构的安全含义。
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.
在运营商的运营商（CsC）架构中，CE链接到PE上的VRF。CE可以向PE发送带标签的分组。该标签先前已由PE分配给CE，并表示通过运营商网络从该CE到远程CE的标签交换路径（LSP）。
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.
在PE上使用标签映射将完全由PE控制标签信息，因此这不会影响解决方案的安全性。
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.
在CsC体系结构中，客户运营商需要信任运营商的运营商进行正确的配置和操作。因此，承运人的客户隐含地需要同时信任其承运人和承运人的承运人。
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]网络相同的安全级别。
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.
此解决方案存在潜在的可扩展性问题，因为ASBR需要为每个VPN维护一个VRF，并且所有VRF都需要保留特定VPN的所有路由。因此，如果单个VRF包含太多路由，ASBR可能会遇到影响所有VPN的内存问题。因此，服务提供商需要确保ASBR的尺寸适当，并采取适当的安全措施，例如限制每个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.
以这种方式连接其VPN的两个服务提供商必须相互信任。由于VPN在不同（子）接口上分开，ASBR之间的所有信令都保持在给定的VPN内。这意味着动态跨VPN安全漏洞是不可能的。可以想象，服务提供商将特定VPN连接到错误的接口，从而将不应连接的两个VPN互连。这必须在操作上加以控制。
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.
其他提供程序的ASBR已传递。这允许一个提供程序将数据包插入到另一个提供程序的任何VPN中，并为其添加标签。
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.
该解决方案还需要考虑互连2层上的安全性。RFC规定，此类互连应仅在专用互连点上实施。详见第6节。
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.
在这个解决方案中，ASE之间有两个有效的控制连接。路由反射器（RRs）通过多跳eBGP交换VPN-IPv4路由。ASBR仅交换持有在这些ASE之间共享的VPN路由的PE路由器的标记地址。这保持了ASBR的可伸缩性，因为它们不需要知道VPN-IPv4路由。
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.
在此解决方案中，顶部标签指定出口PE路由器的LSP，第二个标签指定连接到此出口PE的VPN。ASBR连接的安全性具有与解决方案b中相同的约束条件）：ASBR应仅接受其已分配给其他路由器的具有顶部标签的数据包，从而验证该数据包是否寻址到有效的PE路由器。将接受分配给其他ASBR的任何标签。ASBR无法区分不同的出口PE或这些PE上的不同VPN。一个AS的恶意服务提供商可能将数据包引入另一个AS的PE上的任何VPN；它只需要其ASBR和PE上的有效LSP到另一个AS上的相应PE。VPN标签可以从理论标签空间进行统计猜测，这允许单向流量进入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).
这意味着此类ASBR-ASBR连接只能通过专用接口与受信任方建立，如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.
信息无法验证，如前一种情况。因此，服务提供商可以为任何共享VPN引入虚假路由。ASE需要相互信任才能正确配置各自的网络。此设计中涉及的所有ASE形成一个可信区域。客户需要信任所有相关的服务提供商。
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.
案例b）和案例c）之间的区别在于，在b）中，ASBR充当其as的iBGP下一跳；因此，每个SP只需要知道另一个SP的核心ASBR的地址。在情况c）中，SP交换其PE路由器的环回地址；因此，每个SP都会向另一个SP透露有关其PE路由器的信息，并且这些路由器必须可以从另一个SP访问。如上所述，无障碍并不一定意味着不安全，网络永远不应该依赖“通过模糊实现安全”。如果PE路由器得到了适当的保护，那么这不应该是一个问题。然而，越来越多的人认为网络设备通常不应该是可访问的。
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.
此外，案例c）还考虑了可伸缩性。必须为整个网络（包括以这种方式链接的所有ASE）进行大量BGP对等。双方的SP需要共同定义一个可扩展的体系结构，可能包括路由反射器。
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.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.
这里讨论的安全机制假设核心网络（PE和P路由器）的网络元素配置正确。故意或无意的错误配置可能导致严重的安全漏洞。
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
注意，本段特别提及核心网络，即PE和P元件。上述安全机制涵盖了任何客户端元素（如CE路由器）的错误配置。这意味着潜在的攻击者必须能够访问PE或P路由器，才能从错误配置中获益。如果攻击者可以访问核心元素，或者
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:
如果能够插入核心附加设备，他将能够攻击核心网络和连接的VPN。因此，以下几点很重要：
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路由验证的类似方案。这两种方案都旨在检测和防止内核中的错误配置。
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可以提供这些缺失的服务。
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]。
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.
在大多数情况下，AS间或运营商的运营商解决方案将通过点对点专用连接将网络互连到其他网络。第三方不能干扰此连接。重要的是要了解，将任何共享介质层2技术用于此类互连（如以太网交换机）可能会带来额外的安全风险。
There are two types of risks with layer 2 infrastructure:
第2层基础设施存在两种类型的风险：
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.
第2层环境中的风险包括多种不同形式的地址解析协议（ARP）攻击、VLAN中继攻击或内容寻址内存（CAM）溢出攻击。例如，ARP欺骗允许攻击者通过其设备重定向两个路由器之间的流量，从而访问这两个路由器之间的所有数据包。
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.
这些攻击可以通过适当的安全措施加以预防，但这些安全问题往往被忽视。最重要的是，如果在上述场景中使用共享介质（如交换机），则使用所有可用的第2层安全机制来防止基于第2层的攻击。
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.
如果许多路由器共享一个共同的第二层网络（例如，在互联网交换点），第三方就有可能将数据包引入网络。过去，当一些服务提供商在传统交换点上默认使用另一个提供商时，这在传统交换点上被滥用。实际上，他们正在将所有流量发送到另一个SP的网络，即使控制平面（路由）可能不允许这样做。
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.
因此，交换点（或其他共享第2层连接）上的路由器只应将未标记的IP数据包接收到全局路由表中。必须丢弃任何带标签的数据包。这维护了连接网络的安全性。
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.
因此，当前的建议是丢弃通用共享介质层2网络（如Internet交换点（IXP））上的标记数据包。如果需要交换带标签的数据包，强烈建议使用专用连接。
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网络仍然会受到许多攻击。
The entire document is discussing security considerations of the RFC 4364 [1] architecture.
整个文档都在讨论RFC 4364[1]体系结构的安全注意事项。
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）的长期反馈。
[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月。
[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
EMail: mbehring@cisco.com
URI: http://www.cisco.com
EMail: mbehring@cisco.com
URI: http://www.cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（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.
本文件受BCP 78和www.rfc-editor.org/copyright.html中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
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 http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。