Internet Engineering Task Force (IETF) L. Fang, Ed.
Request for Comments: 5920 Cisco Systems, Inc.
Category: Informational July 2010
ISSN: 2070-1721
Internet Engineering Task Force (IETF) L. Fang, Ed.
Request for Comments: 5920 Cisco Systems, Inc.
Category: Informational July 2010
ISSN: 2070-1721
Security Framework for MPLS and GMPLS Networks
MPLS和GMPLS网络的安全框架
Abstract
摘要
This document provides a security framework for Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) Networks. This document addresses the security aspects that are relevant in the context of MPLS and GMPLS. It describes the security threats, the related defensive techniques, and the mechanisms for detection and reporting. This document emphasizes RSVP-TE and LDP security considerations, as well as inter-AS and inter-provider security considerations for building and maintaining MPLS and GMPLS networks across different domains or different Service Providers.
本文档为多协议标签交换（MPLS）和通用多协议标签交换（GMPLS）网络提供了一个安全框架。本文件阐述了与MPLS和GMPLS相关的安全方面。它描述了安全威胁、相关防御技术以及检测和报告机制。本文件强调RSVP-TE和LDP安全注意事项，以及跨不同域或不同服务提供商构建和维护MPLS和GMPLS网络时的as间和提供商间安全注意事项。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5920.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5920.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................4
2. Terminology .....................................................5
2.1. Acronyms and Abbreviations .................................5
2.2. MPLS and GMPLS Terminology .................................6
3. Security Reference Models .......................................8
4. Security Threats ...............................................10
4.1. Attacks on the Control Plane ..............................12
4.2. Attacks on the Data Plane .................................15
4.3. Attacks on Operation and Management Plane .................17
4.4. Insider Attacks Considerations ............................19
5. Defensive Techniques for MPLS/GMPLS Networks ...................19
5.1. Authentication ............................................20
5.2. Cryptographic Techniques ..................................22
5.3. Access Control Techniques .................................33
5.4. Use of Isolated Infrastructure ............................38
5.5. Use of Aggregated Infrastructure ..........................38
5.6. Service Provider Quality Control Processes ................39
5.7. Deployment of Testable MPLS/GMPLS Service .................39
5.8. Verification of Connectivity ..............................40
6. Monitoring, Detection, and Reporting of Security Attacks .......40
7. Service Provider General Security Requirements .................42
7.1. Protection within the Core Network ........................42
7.2. Protection on the User Access Link ........................46
7.3. General User Requirements for MPLS/GMPLS Providers ........48
8. Inter-Provider Security Requirements ...........................48
8.1. Control-Plane Protection ..................................49
8.2. Data-Plane Protection .....................................53
9. Summary of MPLS and GMPLS Security .............................54
9.1. MPLS and GMPLS Specific Security Threats ..................55
9.2. Defense Techniques ........................................56
9.3. Service Provider MPLS and GMPLS Best-Practice Outlines ....57
10. Security Considerations .......................................59
11. References ....................................................59
11.1. Normative References .....................................59
11.2. Informative References ...................................62
12. Acknowledgements ..............................................64
13. Contributors' Contact Information .............................65
1. Introduction ....................................................4
2. Terminology .....................................................5
2.1. Acronyms and Abbreviations .................................5
2.2. MPLS and GMPLS Terminology .................................6
3. Security Reference Models .......................................8
4. Security Threats ...............................................10
4.1. Attacks on the Control Plane ..............................12
4.2. Attacks on the Data Plane .................................15
4.3. Attacks on Operation and Management Plane .................17
4.4. Insider Attacks Considerations ............................19
5. Defensive Techniques for MPLS/GMPLS Networks ...................19
5.1. Authentication ............................................20
5.2. Cryptographic Techniques ..................................22
5.3. Access Control Techniques .................................33
5.4. Use of Isolated Infrastructure ............................38
5.5. Use of Aggregated Infrastructure ..........................38
5.6. Service Provider Quality Control Processes ................39
5.7. Deployment of Testable MPLS/GMPLS Service .................39
5.8. Verification of Connectivity ..............................40
6. Monitoring, Detection, and Reporting of Security Attacks .......40
7. Service Provider General Security Requirements .................42
7.1. Protection within the Core Network ........................42
7.2. Protection on the User Access Link ........................46
7.3. General User Requirements for MPLS/GMPLS Providers ........48
8. Inter-Provider Security Requirements ...........................48
8.1. Control-Plane Protection ..................................49
8.2. Data-Plane Protection .....................................53
9. Summary of MPLS and GMPLS Security .............................54
9.1. MPLS and GMPLS Specific Security Threats ..................55
9.2. Defense Techniques ........................................56
9.3. Service Provider MPLS and GMPLS Best-Practice Outlines ....57
10. Security Considerations .......................................59
11. References ....................................................59
11.1. Normative References .....................................59
11.2. Informative References ...................................62
12. Acknowledgements ..............................................64
13. Contributors' Contact Information .............................65
Security is an important aspect of all networks, MPLS and GMPLS networks being no exception.
安全性是所有网络的一个重要方面，MPLS和GMPLS网络也不例外。
MPLS and GMPLS are described in [RFC3031] and [RFC3945]. Various security considerations have been addressed in each of the many RFCs on MPLS and GMPLS technologies, but no single document covers general security considerations. The motivation for creating this document is to provide a comprehensive and consistent security framework for MPLS and GMPLS networks. Each individual document may point to this document for general security considerations in addition to providing security considerations specific to the particular technologies the document is describing.
[RFC3031]和[RFC3945]中描述了MPLS和GMPLS。关于MPLS和GMPLS技术的许多RFC中的每一个都讨论了各种安全注意事项，但没有一个文档涵盖一般的安全注意事项。创建本文档的目的是为MPLS和GMPLS网络提供全面一致的安全框架。除了提供文档所描述的特定技术的特定安全注意事项外，每个单独的文档还可以针对一般安全注意事项指向本文档。
In this document, we first describe the security threats relevant in the context of MPLS and GMPLS and the defensive techniques to combat those threats. We consider security issues resulting both from malicious or incorrect behavior of users and other parties and from negligent or incorrect behavior of providers. An important part of security defense is the detection and reporting of a security attack, which is also addressed in this document.
在本文档中，我们首先描述与MPLS和GMPLS相关的安全威胁，以及应对这些威胁的防御技术。我们认为安全问题，无论是从恶意或不正确的行为，用户和其他各方和疏忽或不正确的行为的提供者。安全防御的一个重要部分是安全攻击的检测和报告，本文档中也对其进行了介绍。
We then discuss possible service provider security requirements in an MPLS or GMPLS environment. Users have expectations for the security characteristics of MPLS or GMPLS networks. These include security requirements for equipment supporting MPLS and GMPLS and operational security requirements for providers. Service providers must protect their network infrastructure and make it secure to the level required to provide services over their MPLS or GMPLS networks.
然后，我们讨论MPLS或GMPLS环境中可能的服务提供商安全需求。用户对MPLS或GMPLS网络的安全特性有期望。其中包括支持MPLS和GMPLS的设备的安全要求以及供应商的操作安全要求。服务提供商必须保护其网络基础设施，并使其安全到通过其MPLS或GMPLS网络提供服务所需的级别。
Inter-AS and inter-provider security are discussed with special emphasis, because the security risk factors are higher with inter-provider connections. Note that inter-carrier MPLS security is also considered in [MFA-MPLS-ICI].
特别强调了AS间和提供商间的安全性，因为提供商间连接的安全风险更高。注意，[MFA-MPLS-ICI]中也考虑了载波间MPLS安全性。
Depending on different MPLS or GMPLS techniques used, the degree of risk and the mitigation methodologies vary. This document discusses the security aspects and requirements for certain basic MPLS and GMPLS techniques and interconnection models. This document does not attempt to cover all current and future MPLS and GMPLS technologies, as it is not within the scope of this document to analyze the security properties of specific technologies.
根据使用的不同MPLS或GMPLS技术，风险程度和缓解方法各不相同。本文件讨论了某些基本MPLS和GMPLS技术以及互连模型的安全方面和要求。本文件不试图涵盖所有当前和未来的MPLS和GMPLS技术，因为分析特定技术的安全属性不在本文件的范围内。
It is important to clarify that, in this document, we limit ourselves to describing the providers' security requirements that pertain to MPLS and GMPLS networks, not including the connected user sites. Readers may refer to the "Security Best Practices Efforts and
必须澄清的是，在本文件中，我们仅描述与MPLS和GMPLS网络相关的供应商安全要求，不包括连接的用户站点。读者可以参考“安全最佳实践和努力”
Documents" [OPSEC-EFFORTS] and "Security Mechanisms for the Internet" [RFC3631] for general network operation security considerations. It is not our intention, however, to formulate precise "requirements" for each specific technology in terms of defining the mechanisms and techniques that must be implemented to satisfy such security requirements.
文件“[OPSEC-EFFECTIONS]和“互联网安全机制”[RFC3631]用于一般网络操作安全考虑。然而，我们无意为每项特定技术制定精确的“要求”，以定义为满足此类安全要求必须实施的机制和技术。
AS Autonomous System ASBR Autonomous System Border Router ATM Asynchronous Transfer Mode BGP Border Gateway Protocol BFD Bidirectional Forwarding Detection CE Customer-Edge device CoS Class of Service CPU Central Processing Unit DNS Domain Name System DoS Denial of Service ESP Encapsulating Security Payload FEC Forwarding Equivalence Class GMPLS Generalized Multi-Protocol Label Switching GCM Galois Counter Mode GRE Generic Routing Encapsulation ICI InterCarrier Interconnect ICMP Internet Control Message Protocol ICMPv6 ICMP in IP Version 6 IGP Interior Gateway Protocol IKE Internet Key Exchange IP Internet Protocol IPsec IP Security IPVPN IP-based VPN LDP Label Distribution Protocol L2TP Layer 2 Tunneling Protocol LMP Link Management Protocol LSP Label Switched Path LSR Label Switching Router MD5 Message Digest Algorithm MPLS Multiprotocol Label Switching MP-BGP Multiprotocol BGP NTP Network Time Protocol OAM Operations, Administration, and Maintenance PCE Path Computation Element PE Provider-Edge device PPVPN Provider-Provisioned Virtual Private Network PSN Packet-Switched Network
AS自治系统ASBR自治系统边界路由器ATM异步传输模式BGP边界网关协议BFD双向转发检测CE客户边缘设备CoS服务等级CPU中央处理器DNS域名系统DoS拒绝服务ESP封装安全有效负载FEC转发等价等级GMPLS通用多协议标签交换GCM Galois计数器模式GRE通用路由封装ICI载波间互连ICMP Internet控制消息协议ICMPv6 IP中的ICMP版本6 IGP内部网关协议IKE Internet密钥交换IP Internet协议IPsec IP安全IPVPN基于IP的VPN LDP标签分发协议L2TP第二层隧道协议LMP链路管理协议LSP标签交换路径LSR标签交换路由器MD5消息摘要算法MPLS多协议标签交换MP-BGP多协议BGP NTP网络时间协议OAM操作、管理、，和维护PCE路径计算元素PE提供者边缘设备PPVPN提供者提供的虚拟专用网PSN分组交换网
PW Pseudowire QoS Quality of Service RR Route Reflector RSVP Resource Reservation Protocol RSVP-TE Resource Reservation Protocol with Traffic Engineering Extensions SLA Service Level Agreement SNMP Simple Network Management Protocol SP Service Provider SSH Secure Shell SSL Secure Sockets Layer SYN Synchronize packet in TCP TCP Transmission Control Protocol TDM Time Division Multiplexing TE Traffic Engineering TLS Transport Layer Security ToS Type of Service TTL Time-To-Live UDP User Datagram Protocol VC Virtual Circuit VPN Virtual Private Network WG Working Group of IETF WSS Web Services Security
PW伪线QoS服务质量RR路由反射器RSVP资源预留协议RSVP-TE资源预留协议带流量工程扩展SLA服务级别协议SNMP简单网络管理协议SP服务提供商SSH安全外壳SSL安全套接字层SYN同步TCP传输控制中的数据包协议TDM时分多路复用TE流量工程TLS传输层安全ToS服务类型TTL实时UDP用户数据报协议VC虚拟电路VPN虚拟专用网WG IETF WSS Web服务安全工作组
This document uses MPLS- and GMPLS-specific terminology. Definitions and details about MPLS and GMPLS terminology can be found in [RFC3031] and [RFC3945]. The most important definitions are repeated in this section; for other definitions, the reader is referred to [RFC3031] and [RFC3945].
本文件使用MPLS和GMPLS专用术语。有关MPLS和GMPLS术语的定义和详细信息，请参见[RFC3031]和[RFC3945]。本节重复了最重要的定义；对于其他定义，读者参考[RFC3031]和[RFC3945]。
Core network: An MPLS/GMPLS core network is defined as the central network infrastructure that consists of P and PE routers. An MPLS/GMPLS core network may consist of one or more networks belonging to a single SP.
核心网络：MPLS/GMPLS核心网络定义为由P和PE路由器组成的中心网络基础设施。MPLS/GMPLS核心网络可以由属于单个SP的一个或多个网络组成。
Customer Edge (CE) device: A Customer Edge device is a router or a switch in the customer's network interfacing with the Service Provider's network.
客户边缘（CE）设备：客户边缘设备是客户网络中与服务提供商网络接口的路由器或交换机。
Forwarding Equivalence Class (FEC): A group of IP packets that are forwarded in the same manner (e.g., over the same path, with the same forwarding treatment).
转发等价类（FEC）：以相同方式（例如，通过相同路径，采用相同的转发处理）转发的一组IP数据包。
Label: A short, fixed length, physically contiguous identifier, usually of local significance.
标签：一种短的、固定长度的、物理上连续的标识符，通常具有局部意义。
Label merging: the replacement of multiple incoming labels for a particular FEC with a single outgoing label.
标签合并：将特定FEC的多个传入标签替换为单个传出标签。
Label Switched Hop: A hop between two MPLS nodes, on which forwarding is done using labels.
标签交换跃点：两个MPLS节点之间的跃点，在其上使用标签进行转发。
Label Switched Path (LSP): The path through one or more LSRs at one level of the hierarchy followed by packets in a particular FEC.
标签交换路径（LSP）：在层次结构的一个级别上通过一个或多个LSR的路径，后跟特定FEC中的数据包。
Label Switching Routers (LSRs): An MPLS/GMPLS node assumed to have a forwarding plane that is capable of (a) recognizing either packet or cell boundaries, and (b) being able to process either packet headers or cell headers.
标签交换路由器（LSR）：假定MPLS/GMPLS节点具有转发平面，该转发平面能够（a）识别分组或小区边界，以及（b）能够处理分组报头或小区报头。
Loop Detection: A method of dealing with loops in which loops are allowed to be set up, and data may be transmitted over the loop, but the loop is later detected.
循环检测：一种处理循环的方法，允许建立循环，数据可以通过循环传输，但随后会检测到循环。
Loop Prevention: A method of dealing with loops in which data is never transmitted over a loop.
循环预防：一种处理循环的方法，其中数据从未通过循环传输。
Label Stack: An ordered set of labels.
标签堆栈：一组有序的标签。
Merge Point: A node at which label merging is done.
合并点：完成标签合并的节点。
MPLS Domain: A contiguous set of nodes that perform MPLS routing and forwarding and are also in one Routing or Administrative Domain.
MPLS域：执行MPLS路由和转发的一组连续节点，也位于一个路由或管理域中。
MPLS Edge Node: An MPLS node that connects an MPLS domain with a node outside of the domain, either because it does not run MPLS, or because it is in a different domain. Note that if an LSR has a neighboring host not running MPLS, then that LSR is an MPLS edge node.
MPLS边缘节点：连接MPLS域与域外节点的MPLS节点，原因可能是它不运行MPLS，也可能是因为它位于不同的域中。请注意，如果LSR的相邻主机未运行MPLS，则该LSR是MPLS边缘节点。
MPLS Egress Node: An MPLS edge node in its role in handling traffic as it leaves an MPLS domain.
MPLS出口节点：MPLS边缘节点在离开MPLS域时处理流量。
MPLS Ingress Node: A MPLS edge node in its role in handling traffic as it enters a MPLS domain.
MPLS入口节点：一个MPLS边缘节点，在其进入MPLS域时处理流量。
MPLS Label: A label carried in a packet header, which represents the packet's FEC.
MPLS标签：数据包头中的标签，表示数据包的FEC。
MPLS Node: A node running MPLS. An MPLS node is aware of MPLS control protocols, runs one or more routing protocols, and is capable of forwarding packets based on labels. An MPLS node may optionally be also capable of forwarding native IP packets.
MPLS节点：运行MPLS的节点。MPLS节点知道MPLS控制协议，运行一个或多个路由协议，并且能够基于标签转发数据包。MPLS节点还可以可选地能够转发本机IP分组。
Multiprotocol Label Switching (MPLS): MPLS is an architecture for efficient data packet switching and routing. MPLS assigns data packets with labels. Instead of performing the longest match for each packet's destination as in conventional IP forwarding, MPLS makes the packet-forwarding decisions solely on the contents of the label without examining the packet itself. This allows the creation of end-to-end circuits across any type of transport medium, using any protocols.
多协议标签交换（MPLS）：MPLS是一种高效数据包交换和路由的体系结构。MPLS为数据包分配标签。MPLS没有像传统的IP转发那样对每个数据包的目的地执行最长匹配，而是只根据标签的内容做出数据包转发决策，而不检查数据包本身。这允许使用任何协议跨任何类型的传输介质创建端到端电路。
P: Provider Router. A Provider Router is a router in the Service Provider's core network that does not have interfaces directly towards the customer. A P router is used to interconnect the PE routers and/or other P routers within the core network.
提供商路由器。提供商路由器是服务提供商核心网络中的路由器，没有直接面向客户的接口。P路由器用于互连核心网络内的PE路由器和/或其他P路由器。
PE: Provider Edge device. A Provider Edge device is the equipment in the Service Provider's network that interfaces with the equipment in the customer's network.
PE：提供程序边缘设备。提供商边缘设备是服务提供商网络中与客户网络中的设备接口的设备。
PPVPN: Provider-Provisioned Virtual Private Network, including Layer 2 VPNs and Layer 3 VPNs.
PPVPN：提供商提供的虚拟专用网络，包括第2层VPN和第3层VPN。
VPN: Virtual Private Network, which restricts communication between a set of sites, making use of an IP backbone shared by traffic not going to or not coming from those sites [RFC4110].
VPN：虚拟专用网络，它限制一组站点之间的通信，利用不进入或不来自这些站点的流量共享的IP主干网[RFC4110]。
This section defines a reference model for security in MPLS/GMPLS networks.
本节定义了MPLS/GMPLS网络安全的参考模型。
This document defines each MPLS/GMPLS core in a single domain to be a trusted zone. A primary concern is about security aspects that relate to breaches of security from the "outside" of a trusted zone to the "inside" of this zone. Figure 1 depicts the concept of trusted zones within the MPLS/GMPLS framework.
本文档将单个域中的每个MPLS/GMPLS核心定义为可信区域。主要关注的是与从受信任区域的“外部”到该区域的“内部”的安全破坏相关的安全方面。图1描述了MPLS/GMPLS框架中受信任区域的概念。
/-------------\
+------------+ / \ +------------+
| MPLS/GMPLS +---/ \--------+ MPLS/GMPLS |
| user | MPLS/GMPLS Core | user |
| site +---\ /XXX-----+ site |
+------------+ \ / XXX +------------+
\-------------/ | |
| |
| +------\
+--------/ "Internet"
/-------------\
+------------+ / \ +------------+
| MPLS/GMPLS +---/ \--------+ MPLS/GMPLS |
| user | MPLS/GMPLS Core | user |
| site +---\ /XXX-----+ site |
+------------+ \ / XXX +------------+
\-------------/ | |
| |
| +------\
+--------/ "Internet"
|<- Trusted zone ->|
|<- Trusted zone ->|
MPLS/GMPLS Core with user connections and Internet connection
具有用户连接和互联网连接的MPLS/GMPLS核心
Figure 1: The MPLS/GMPLS Trusted Zone Model
图1:MPLS/GMPLS可信区域模型
The trusted zone is the MPLS/GMPLS core in a single AS within a single Service Provider.
可信区域是单个服务提供商内单个AS中的MPLS/GMPLS核心。
A trusted zone contains elements and users with similar security properties, such as exposure and risk level. In the MPLS context, an organization is typically considered as one trusted zone.
可信区域包含具有类似安全属性（如暴露和风险级别）的元素和用户。在MPLS上下文中，组织通常被视为一个受信任区域。
The boundaries of a trust domain should be carefully defined when analyzing the security properties of each individual network, e.g., the boundaries can be at the link termination, remote peers, areas, or quite commonly, ASes.
在分析每个单独网络的安全属性时，应仔细定义信任域的边界，例如，边界可以位于链路终端、远程对等点、区域或非常常见的ASE。
In principle, the trusted zones should be separate; however, typically MPLS core networks also offer Internet access, in which case a transit point (marked with "XXX" in Figure 1) is defined. In the case of MPLS/GMPLS inter-provider connections or InterCarrier Interconnect (ICI), the trusted zone of each provider ends at the respective ASBRs (ASBR1 and ASBR2 for Provider A and ASBR3 and ASBR4 for Provider B in Figure 2).
原则上，受信任区域应该是分开的；然而，通常MPLS核心网络也提供互联网接入，在这种情况下，定义了一个中转点（图1中标记为“XXX”）。在MPLS/GMPLS提供商间连接或载波间互连（ICI）的情况下，每个提供商的受信任区域终止于各自的ASBR（图2中，提供商A的ASBR1和ASBR2以及提供商B的ASBR3和ASBR4）。
A key requirement of MPLS and GMPLS networks is that the security of the trusted zone not be compromised by interconnecting the MPLS/GMPLS core infrastructure with another provider's core (MPLS/GMPLS or non-MPLS/GMPLS), the Internet, or end users.
MPLS和GMPLS网络的一个关键要求是，通过将MPLS/GMPLS核心基础设施与另一提供商的核心（MPLS/GMPLS或非MPLS/GMPLS）、互联网或最终用户互连，不损害受信任区域的安全性。
In addition, neighbors may be trusted or untrusted. Neighbors may be authorized or unauthorized. An authorized neighbor is the neighbor one establishes a peering relationship with. Even though a neighbor may be authorized for communication, it may not be trusted. For example, when connecting with another provider's ASBRs to set up
此外，邻居可能受信任或不受信任。邻居可能被授权或未经授权。授权邻居是与之建立对等关系的邻居。即使邻居被授权进行通信，它也可能不受信任。例如，连接其他提供商的ASBR以设置
inter-AS LSPs, the other provider is considered an untrusted but authorized neighbor.
作为LSP，另一个提供者被视为不受信任但经过授权的邻居。
+---------------+ +----------------+
| | | |
| MPLS/GMPLS ASBR1----ASBR3 MPLS/GMPLS |
CE1--PE1 Network | | Network PE2--CE2
| Provider A ASBR2----ASBR4 Provider B |
| | | |
+---------------+ +----------------+
InterCarrier
Interconnect (ICI)
For Provider A:
Trusted Zone: Provider A MPLS/GMPLS network
Authorized but untrusted neighbor: provider B
Unauthorized neighbors: CE1, CE2
+---------------+ +----------------+
| | | |
| MPLS/GMPLS ASBR1----ASBR3 MPLS/GMPLS |
CE1--PE1 Network | | Network PE2--CE2
| Provider A ASBR2----ASBR4 Provider B |
| | | |
+---------------+ +----------------+
InterCarrier
Interconnect (ICI)
For Provider A:
Trusted Zone: Provider A MPLS/GMPLS network
Authorized but untrusted neighbor: provider B
Unauthorized neighbors: CE1, CE2
Figure 2: MPLS/GMPLS Trusted Zone and Authorized Neighbor
图2:MPLS/GMPLS可信区域和授权邻居
All aspects of network security independent of whether a network is an MPLS/GMPLS network, are out of scope. For example, attacks from the Internet to a user's web-server connected through the MPLS/GMPLS network are not considered here, unless the way the MPLS/GMPLS network is provisioned could make a difference to the security of this user's server.
与网络是否为MPLS/GMPLS网络无关的网络安全的所有方面都超出了范围。例如，这里不考虑从互联网对通过MPLS/GMPLS网络连接的用户web服务器的攻击，除非MPLS/GMPLS网络的配置方式可能会对该用户服务器的安全性产生影响。
This section discusses the various network security threats that may endanger MPLS/GMPLS networks. RFC 4778 [RFC4778] provided the best current operational security practices in Internet Service Provider environments.
本节讨论可能危及MPLS/GMPLS网络的各种网络安全威胁。RFC 4778[RFC4778]提供了Internet服务提供商环境中当前最佳的操作安全实践。
A successful attack on a particular MPLS/GMPLS network or on an SP's MPLS/GMPLS infrastructure may cause one or more of the following ill effects:
对特定MPLS/GMPLS网络或SP的MPLS/GMPLS基础设施的成功攻击可能会导致以下一种或多种不良影响：
- Observation, modification, or deletion of a provider's or user's data.
- 观察、修改或删除提供者或用户的数据。
- Replay of a provider's or user's data.
- 重播提供者或用户的数据。
- Injection of inauthentic data into a provider's or user's traffic stream.
- 将不真实的数据注入提供商或用户的流量流。
- Traffic pattern analysis on a provider's or user's traffic.
- 对提供商或用户的流量进行流量模式分析。
- Disruption of a provider's or user's connectivity.
- 中断提供商或用户的连接。
- Degradation of a provider's service quality.
- 供应商服务质量的下降。
- Probing a provider's network to determine its configuration, capacity, or usage.
- 探测提供商的网络以确定其配置、容量或使用情况。
It is useful to consider that threats, whether malicious or accidental, may come from different categories of sources. For example, they may come from:
考虑到威胁，无论是恶意的还是偶然的，都可能来自不同类别的来源。例如，他们可能来自：
- Other users whose services are provided by the same MPLS/GMPLS core.
- 由同一MPLS/GMPLS核心提供服务的其他用户。
- The MPLS/GMPLS SP or persons working for it.
- MPLS/GMPLS SP或其工作人员。
- Other persons who obtain physical access to an MPLS/GMPLS SP's site.
- 物理访问MPLS/GMPLS SP站点的其他人员。
- Other persons who use social engineering methods to influence the behavior of an SP's personnel.
- 使用社会工程方法影响SP人员行为的其他人员。
- Users of the MPLS/GMPLS network itself, e.g., intra-VPN threats. (Such threats are beyond the scope of this document.)
- MPLS/GMPLS网络本身的用户，例如VPN内部威胁。（此类威胁超出了本文件的范围。）
- Others, e.g., attackers from the Internet at large.
- 其他，例如，来自互联网的攻击者。
- Other SPs in the case of MPLS/GMPLS inter-provider connection. The core of the other provider may or may not be using MPLS/GMPLS.
- MPLS/GMPLS供应商间连接情况下的其他SP。另一个提供商的核心可能使用MPLS/GMPLS，也可能不使用。
- Those who create, deliver, install, and maintain software for network equipment.
- 为网络设备创建、交付、安装和维护软件的人员。
Given that security is generally a tradeoff between expense and risk, it is also useful to consider the likelihood of different attacks occurring. There is at least a perceived difference in the likelihood of most types of attacks being successfully mounted in different environments, such as:
考虑到安全性通常是费用和风险之间的权衡，考虑不同攻击发生的可能性也是有用的。大多数类型的攻击在不同环境中成功实施的可能性至少存在感知差异，例如：
- An MPLS/GMPLS core interconnecting with another provider's core.
- 与另一提供商的核心互连的MPLS/GMPLS核心。
- An MPLS/GMPLS configuration transiting the public Internet.
- 通过公共互联网传输的MPLS/GMPLS配置。
Most types of attacks become easier to mount and hence more likely as the shared infrastructure via which service is provided expands from a single SP to multiple cooperating SPs to the global Internet. Attacks that may not be of sufficient likeliness to warrant concern in a closely controlled environment often merit defensive measures in broader, more open environments. In closed communities, it is often
随着提供服务的共享基础设施从单个SP扩展到多个协作SP，再扩展到全球互联网，大多数类型的攻击都变得更容易装载，因此更有可能发生。在严密控制的环境中，攻击的可能性可能不足以引起关注，但在更广泛、更开放的环境中，往往需要采取防御措施。在封闭的社区中，这种情况经常发生
practical to deal with misbehavior after the fact: an employee can be disciplined, for example.
事后处理不当行为的实用方法：例如，员工可以受到纪律处分。
The following sections discuss specific types of exploits that threaten MPLS/GMPLS networks.
以下各节讨论威胁MPLS/GMPLS网络的特定类型的利用漏洞攻击。
This category encompasses attacks on the control structures operated by the SP with MPLS/GMPLS cores.
此类攻击包括对具有MPLS/GMPLS核心的SP操作的控制结构的攻击。
It should be noted that while connectivity in the MPLS control plane uses the same links and network resources as are used by the data plane, the GMPLS control plane may be provided by separate resources from those used in the data plane. That is, the GMPLS control plane may be physically separate from the data plane.
应当注意，尽管MPLS控制平面中的连接使用与数据平面中使用的相同的链路和网络资源，但是GMPLS控制平面可以由与数据平面中使用的资源不同的资源提供。也就是说，GMPLS控制平面可以在物理上与数据平面分离。
The different cases of physically congruent and physically separate control/data planes lead to slightly different possibilities of attack, although most of the cases are the same. Note that, for example, the data plane cannot be directly congested by an attack on a physically separate control plane as it could be if the control and data planes shared network resources. Note also that if the control plane uses diverse resources from the data plane, no assumptions should be made about the security of the control plane based on the security of the data plane resources.
物理上一致和物理上分离的控制/数据平面的不同情况导致攻击的可能性略有不同，尽管大多数情况是相同的。请注意，例如，如果控制平面和数据平面共享网络资源，则数据平面不会因对物理上独立的控制平面的攻击而直接拥塞。还请注意，如果控制平面使用来自数据平面的各种资源，则不应基于数据平面资源的安全性对控制平面的安全性进行任何假设。
This section is focused the outsider attack. The insider attack is discussed in Section 4.4.
这一部分主要关注局外人的攻击。第4.4节讨论了内部攻击。
The unauthorized element can be a local CE or a router in another domain. An unauthorized element can generate MPLS signaling messages. At the least, this can result in extra control plane and forwarding state, and if successful, network bandwidth could be reserved unnecessarily. This may also result in theft of service or even compromise the entire network.
未经授权的元素可以是本地CE或另一个域中的路由器。未经授权的元素可以生成MPLS信令消息。至少，这会导致额外的控制平面和转发状态，如果成功，可能会不必要地保留网络带宽。这也可能导致服务被盗，甚至危及整个网络。
This threat might be accomplished by monitoring network traffic, for example, after a physical intrusion. Without physical intrusion, it could be accomplished with an unauthorized software modification. Also, many technologies such as terrestrial microwave, satellite, or free-space optical could be intercepted without physical intrusion. If successful, it could provide information leading to label spoofing attacks. It also raises confidentiality issues.
这种威胁可能通过监视网络流量来实现，例如，在物理入侵之后。在没有物理入侵的情况下，可以通过未经授权的软件修改来实现。此外，许多技术，如地面微波、卫星或自由空间光学技术，都可以在没有物理入侵的情况下被拦截。如果成功，它可以提供导致标签欺骗攻击的信息。它还提出了保密问题。
RSVP-TE, described in [RFC3209], is the control protocol used to set up GMPLS and traffic engineered MPLS tunnels.
[RFC3209]中描述的RSVP-TE是用于建立GMPLS和流量工程MPLS隧道的控制协议。
There are two major types of denial-of-service (DoS) attacks against an MPLS domain based on RSVP-TE. The attacker may set up numerous unauthorized LSPs or may send a storm of RSVP messages. It has been demonstrated that unprotected routers running RSVP can be effectively disabled by both types of DoS attacks.
针对基于RSVP-TE的MPLS域的拒绝服务（DoS）攻击主要有两种类型。攻击者可能会设置大量未经授权的LSP，或发送大量RSVP消息。已经证明，运行RSVP的无保护路由器可以被这两种类型的DoS攻击有效地禁用。
These attacks may even be combined, by using the unauthorized LSPs to transport additional RSVP (or other) messages across routers where they might otherwise be filtered out. RSVP attacks can be launched against adjacent routers at the border with the attacker, or against non-adjacent routers within the MPLS domain, if there is no effective mechanism to filter them out.
通过使用未经授权的LSP在路由器上传输额外的RSVP（或其他）消息，这些攻击甚至可以组合在一起，否则这些消息可能会被过滤掉。RSVP攻击可以针对与攻击者接壤的相邻路由器发起，或者针对MPLS域内的非相邻路由器发起，前提是没有有效的机制将其过滤掉。
LDP, described in [RFC5036], is the control protocol used to set up MPLS tunnels without TE.
[RFC5036]中描述的LDP是用于建立不带TE的MPLS隧道的控制协议。
There are two significant types of attack against LDP. An unauthorized network element can establish an LDP session by sending LDP Hello and LDP Init messages, leading to the potential setup of an LSP, as well as accompanying LDP state table consumption. Even without successfully establishing LSPs, an attacker can launch a DoS attack in the form of a storm of LDP Hello messages or LDP TCP SYN messages, leading to high CPU utilization or table space exhaustion on the target router.
针对自民党的攻击主要有两种。未经授权的网元可以通过发送LDP Hello和LDP Init消息来建立LDP会话，从而导致潜在的LSP设置以及伴随的LDP状态表消耗。即使没有成功建立LSP，攻击者也可以以LDP Hello消息或LDP TCP SYN消息风暴的形式发起DoS攻击，从而导致目标路由器上CPU利用率高或表空间耗尽。
DoS attacks could be accomplished through an MPLS signaling storm, resulting in high CPU utilization and possibly leading to control-plane resource starvation.
DoS攻击可通过MPLS信令风暴完成，导致CPU利用率高，并可能导致控制平面资源不足。
Control-plane DoS attacks can be mounted specifically against the mechanisms the SP uses to provide various services, or against the general infrastructure of the service provider, e.g., P routers or shared aspects of PE routers. (An attack against the general infrastructure is within the scope of this document only if the attack can occur in relation with the MPLS/GMPLS infrastructure; otherwise, it is not an MPLS/GMPLS-specific issue.)
控制平面DoS攻击可专门针对SP用于提供各种服务的机制，或针对服务提供商的一般基础设施（例如P路由器或PE路由器的共享方面）进行。（只有当攻击可能发生在与MPLS/GMPLS基础设施相关的情况下，针对通用基础设施的攻击才在本文档的范围内；否则，这不是MPLS/GMPLS的特定问题。）
The attacks described in the following sections may each have denial of service as one of their effects. Other DoS attacks are also possible.
以下各节中描述的攻击可能会产生拒绝服务的后果。其他拒绝服务攻击也是可能的。
4.1.6. Attacks on the SP's MPLS/GMPLS Equipment via Management Interfaces
4.1.6. 通过管理接口攻击SP的MPLS/GMPLS设备
This includes unauthorized access to an SP's infrastructure equipment, for example, to reconfigure the equipment or to extract information (statistics, topology, etc.) pertaining to the network.
这包括未经授权访问SP的基础设施设备，例如，重新配置设备或提取与网络有关的信息（统计信息、拓扑等）。
This refers to the event in which expected isolation between separate users (who may be VPN users) is breached. This includes cases such as:
这是指违反独立用户（可能是VPN用户）之间预期隔离的事件。这包括以下情况：
- A site being connected into the "wrong" VPN.
- 连接到“错误”VPN的站点。
- Traffic being replicated and sent to an unauthorized user.
- 正在复制流量并将其发送给未经授权的用户。
- Two or more VPNs being improperly merged together.
- 两个或多个VPN不正确地合并在一起。
- A point-to-point VPN connecting the wrong two points.
- 连接错误两点的点对点VPN。
- Any packet or frame being improperly delivered outside the VPN to which it belongs
- 任何数据包或帧在其所属的VPN之外被不正确地传送
Misconnection or cross-connection of VPNs may be caused by service provider or equipment vendor error, or by the malicious action of an attacker. The breach may be physical (e.g., PE-CE links misconnected) or logical (e.g., improper device configuration).
VPN的错误连接或交叉连接可能由服务提供商或设备供应商的错误或攻击者的恶意行为造成。该漏洞可能是物理性的（例如，PE-CE链路连接错误）或逻辑性的（例如，设备配置不当）。
Anecdotal evidence suggests that the cross-connection threat is one of the largest security concerns of users (or would-be users).
传闻证据表明，交叉连接威胁是用户（或潜在用户）最大的安全问题之一。
This encompasses attacks against underlying routing protocols that are run by the SP and that directly support the MPLS/GMPLS core. (Attacks against the use of routing protocols for the distribution of backbone routes are beyond the scope of this document.) Specific attacks against popular routing protocols have been widely studied and are described in [RFC4593].
这包括对SP运行的、直接支持MPLS/GMPLS核心的底层路由协议的攻击。（针对使用路由协议分发主干路由的攻击超出了本文档的范围。）针对流行路由协议的特定攻击已得到广泛研究，并在[RFC4593]中进行了描述。
Besides routing and management protocols (covered separately in the previous sections), a number of other control protocols may be directly involved in delivering services by the MPLS/GMPLS core. These include but may not be limited to:
除了路由和管理协议（在前面的章节中单独介绍）之外，MPLS/GMPLS核心在提供服务时还可能直接涉及许多其他控制协议。这些包括但不限于：
- MPLS signaling (LDP, RSVP-TE) discussed above in subsections 4.1.4 and 4.1.3
- 上文第4.1.4和4.1.3小节讨论的MPLS信令（LDP、RSVP-TE）
- PCE signaling
- PCE信号
- IPsec signaling (IKE and IKEv2)
- IPsec信令（IKE和IKEv2）
- ICMP and ICMPv6
- ICMP和ICMPv6
- L2TP
- L2TP
- BGP-based membership discovery
- 基于BGP的成员身份发现
- Database-based membership discovery (e.g., RADIUS)
- 基于数据库的成员资格发现（例如RADIUS）
- Other protocols that may be important to the control infrastructure, e.g., DNS, LMP, NTP, SNMP, and GRE.
- 对控制基础设施可能很重要的其他协议，例如DNS、LMP、NTP、SNMP和GRE。
Attacks might subvert or disrupt the activities of these protocols, for example via impersonation or DoS.
攻击可能会破坏或破坏这些协议的活动，例如通过模拟或拒绝服务。
Note that all of the data-plane attacks can also be carried out against the packets of the control and management planes: insertion, spoofing, replay, deletion, pattern analysis, and other attacks mentioned above.
注意，还可以对控制和管理平面的数据包执行所有数据平面攻击：插入、欺骗、重播、删除、模式分析和上述其他攻击。
This category encompasses attacks on the provider's or end-user's data. Note that from the MPLS/GMPLS network end user's point of view, some of this might be control-plane traffic, e.g., routing protocols running from user site A to user site B via IP or non-IP connections, which may be some type of VPN.
此类攻击包括对提供商或最终用户数据的攻击。注意，从MPLS/GMPLS网络最终用户的角度来看，其中一些可能是控制平面流量，例如，通过IP或非IP连接从用户站点A运行到用户站点B的路由协议，可能是某种类型的VPN。
This refers to "sniffing" provider or end user packets and examining their contents. This can result in exposure of confidential information. It can also be a first step in other attacks (described below) in which the recorded data is modified and re-inserted, or simply replayed later.
这是指“嗅探”提供者或最终用户数据包并检查其内容。这可能导致机密信息的泄露。它也可以是其他攻击（如下所述）的第一步，在这些攻击中，记录的数据被修改和重新插入，或者只是在以后重放。
This refers to modifying the contents of packets as they traverse the MPLS/GMPLS core.
这是指在数据包通过MPLS/GMPLS核心时修改数据包的内容。
Spoofing refers to sending a user packets or inserting packets into a data stream that do not belong, with the objective of having them accepted by the recipient as legitimate. Also included in this category is the insertion of copies of once-legitimate packets that have been recorded and replayed.
欺骗是指发送用户数据包或将数据包插入不属于的数据流中，目的是让接收者接受这些数据包为合法数据。这一类别还包括插入已记录和重放的一度合法数据包的副本。
This refers to causing packets to be discarded as they traverse the MPLS/GMPLS networks. This is a specific type of denial-of-service attack.
这是指在数据包通过MPLS/GMPLS网络时导致数据包被丢弃。这是一种特定类型的拒绝服务攻击。
This refers to "sniffing" provider or user packets and examining aspects or meta-aspects of them that may be visible even when the packets themselves are encrypted. An attacker might gain useful information based on the amount and timing of traffic, packet sizes, source and destination addresses, etc. For most users, this type of attack is generally considered to be significantly less of a concern than the other types discussed in this section.
这是指“嗅探”提供者或用户数据包，并检查它们的方面或元方面，这些方面甚至在数据包本身被加密时也可能可见。攻击者可能会根据流量的数量和时间、数据包大小、源地址和目标地址等获得有用的信息。对于大多数用户来说，与本节中讨论的其他类型相比，这种类型的攻击通常被认为不太值得关注。
Denial-of-service (DoS) attacks are those in which an attacker attempts to disrupt or prevent the use of a service by its legitimate users. Taking network devices out of service, modifying their configuration, or overwhelming them with requests for service are several of the possible avenues for DoS attack.
拒绝服务（DoS）攻击是指攻击者试图中断或阻止合法用户使用服务的攻击。使网络设备停止服务、修改其配置或以服务请求压倒网络设备是DoS攻击的几种可能途径。
Overwhelming the network with requests for service, otherwise known as a "resource exhaustion" DoS attack, may target any resource in the network, e.g., link bandwidth, packet forwarding capacity, session capacity for various protocols, CPU power, table size, storage overflows, and so on.
以服务请求压倒网络，也称为“资源耗尽”DoS攻击，可能以网络中的任何资源为目标，例如链路带宽、数据包转发容量、各种协议的会话容量、CPU功率、表大小、存储溢出等。
DoS attacks of the resource exhaustion type can be mounted against the data plane of a particular provider or end user by attempting to insert (spoofing) an overwhelming quantity of inauthentic data into the provider or end-user's network from outside of the trusted zone. Potential results might be to exhaust the bandwidth available to that
通过尝试将大量不真实数据从受信任区域之外插入（欺骗）提供商或最终用户的网络，可以针对特定提供商或最终用户的数据平面发起资源耗尽类型的DoS攻击。潜在的结果可能是耗尽可用的带宽
provider or end user, or to overwhelm the cryptographic authentication mechanisms of the provider or end user.
提供程序或最终用户，或覆盖提供程序或最终用户的加密身份验证机制。
Data-plane resource exhaustion attacks can also be mounted by overwhelming the service provider's general (MPLS/GMPLS-independent) infrastructure with traffic. These attacks on the general infrastructure are not usually an MPLS/GMPLS-specific issue, unless the attack is mounted by another MPLS/GMPLS network user from a privileged position. (For example, an MPLS/GMPLS network user might be able to monopolize network data-plane resources and thus disrupt other users.)
数据平面资源耗尽攻击也可以通过使用流量压倒服务提供商的通用（MPLS/GMPLS独立）基础设施来发起。对一般基础设施的这些攻击通常不是MPLS/GMPLS特定的问题，除非攻击是由另一个MPLS/GMPLS网络用户从特权位置发起的。（例如，MPLS/GMPLS网络用户可能会垄断网络数据平面资源，从而干扰其他用户。）
Many DoS attacks use amplification, whereby the attacker co-opts otherwise innocent parties to increase the effect of the attack. The attacker may, for example, send packets to a broadcast or multicast address with the spoofed source address of the victim, and all of the recipients may then respond to the victim.
许多DoS攻击使用放大技术，攻击者通过这种方式选择其他无辜方来增加攻击效果。例如，攻击者可以向广播或多播地址发送带有受害者伪造源地址的数据包，然后所有收件人都可以响应受害者。
Misconnection may arise through deliberate attack, or through misconfiguration or misconnection of the network resources. The result is likely to be delivery of data to the wrong destination or black-holing of the data.
错误连接可能是由于故意攻击、网络资源的错误配置或错误连接造成的。其结果很可能是将数据传递到错误的目的地，或是数据的黑洞。
In GMPLS with physically diverse control and data planes, it may be possible for data-plane misconnection to go undetected by the control plane.
在具有物理多样性控制和数据平面的GMPLS中，控制平面可能未检测到数据平面错误连接。
In optical networks under GMPLS control, misconnection may give rise to physical safety risks as unprotected lasers may be activated without warning.
在GMPLS控制下的光网络中，错误连接可能会导致物理安全风险，因为未受保护的激光器可能会在没有警告的情况下被激活。
Attacks on the Operation and Management plane have been discussed extensively as general network security issues over the last 20 years. RFC 4778 [RFC4778] may serve as the best current operational security practices in Internet Service Provider environments. RFC 4377 [RFC4377] provided Operations and Management Requirements for MPLS networks. See also the Security Considerations of RFC 4377 and Section 7 of RFC 4378 [RFC4378].
在过去20年中，对运营和管理层的攻击作为一般网络安全问题被广泛讨论。RFC 4778[RFC4778]可以作为Internet服务提供商环境中当前最佳的操作安全实践。RFC 4377[RFC4377]提供了MPLS网络的操作和管理要求。另见RFC 4377的安全注意事项和RFC 4378[RFC4378]第7节。
Operation and Management across the MPLS-ICI could also be the source of security threats on the provider infrastructure as well as the service offered over the MPLS-ICI. A large volume of Operation and Management messages could overwhelm the processing capabilities of an ASBR if the ASBR is not properly protected. Maliciously generated
跨MPLS-ICI的操作和管理也可能是提供商基础设施以及通过MPLS-ICI提供的服务的安全威胁源。如果ASBR未得到适当保护，大量的操作和管理消息可能会使ASBR的处理能力无法承受。恶意生成
Operation and Management messages could also be used to bring down an otherwise healthy service (e.g., MPLS Pseudowire), and therefore affect service security. LSP ping does not support authentication today, and that support should be a subject for future considerations. Bidirectional Forwarding Detection (BFD), however, does have support for carrying an authentication object. It also supports Time-To-Live (TTL) processing as an anti-replay measure. Implementations conformant with this MPLS-ICI should support BFD authentication and must support the procedures for TTL processing.
操作和管理消息也可用于关闭其他正常服务（例如，MPLS伪线），从而影响服务安全。LSP ping目前不支持身份验证，这种支持应该成为未来考虑的主题。然而，双向转发检测（BFD）确实支持携带身份验证对象。它还支持生存时间（TTL）处理作为一种反重放措施。符合此MPLS-ICI的实现应支持BFD身份验证，并且必须支持TTL处理过程。
Regarding GMPLS Operation and Management considerations in optical interworking, there is a good discussion on security for management interfaces to Network Elements [OIF-Sec-Mag].
关于光互通中的GMPLS操作和管理注意事项，对网元管理接口的安全性[OIF Sec Mag]进行了很好的讨论。
Network elements typically have one or more (in some cases many) Operation and Management interfaces used for network management, billing and accounting, configuration, maintenance, and other administrative activities.
网元通常具有一个或多个（在某些情况下是许多）操作和管理接口，用于网络管理、计费和记帐、配置、维护和其他管理活动。
Remote access to a network element through these Operation and Management interfaces is frequently a requirement. Securing the control protocols while leaving these Operation and Management interfaces unprotected opens up a huge security vulnerability. Network elements are an attractive target for intruders who want to disrupt or gain free access to telecommunications facilities. Much has been written about this subject since the 1980s. In the 1990s, telecommunications facilities were identified in the U.S. and other countries as part of the "critical infrastructure", and increased emphasis was placed on thwarting such attacks from a wider range of potentially well-funded and determined adversaries.
通常需要通过这些操作和管理接口远程访问网元。保护控制协议，同时不保护这些操作和管理接口，会打开一个巨大的安全漏洞。网络元件对于想要干扰或免费访问电信设施的入侵者来说是一个有吸引力的目标。自20世纪80年代以来，关于这一主题的文章很多。在20世纪90年代，美国和其他国家的电信设施被确定为“关键基础设施”的一部分，并且越来越强调挫败来自更广泛的潜在资金充足和决心坚定的对手的此类攻击。
At one time, careful access controls and password management were a sufficient defense, but are no longer. Networks using the TCP/IP protocol suite are vulnerable to forged source addresses, recording and later replay, packet sniffers picking up passwords, re-routing of traffic to facilitate eavesdropping or tampering, active hijacking attacks of TCP connections, and a variety of denial-of-service attacks. The ease of forging TCP/IP packets is the main reason network management protocols lacking strong security have not been used to configure network elements (e.g., with the SNMP SET command).
曾经，谨慎的访问控制和密码管理是一种足够的防御措施，但现在已经不再是了。使用TCP/IP协议套件的网络容易受到伪造源地址、录制和稍后重播、数据包嗅探器获取密码、重新路由流量以便于窃听或篡改、TCP连接的主动劫持攻击以及各种拒绝服务攻击的攻击。伪造TCP/IP数据包的简易性是没有使用缺乏强安全性的网络管理协议来配置网络元素（例如，使用SNMP SET命令）的主要原因。
Readily available hacking tools exist that let an eavesdropper on a LAN take over one end of any TCP connection, so that the legitimate party is cut off. In addition, enterprises and Service Providers in some jurisdictions need to safeguard data about their users and network configurations from prying. An attacker could eavesdrop and
现有的黑客工具可以让局域网上的窃听者接管任何TCP连接的一端，从而切断合法的一方。此外，某些管辖区的企业和服务提供商需要保护有关其用户和网络配置的数据免受窥探。攻击者可以窃听并
observe traffic to analyze usage patterns and map a network configuration; an attacker could also gain access to systems and manipulate configuration data or send malicious commands.
观察流量以分析使用模式并绘制网络配置图；攻击者还可以访问系统、操纵配置数据或发送恶意命令。
Therefore, in addition to authenticating the human user, more sophisticated protocol security is needed for Operation and Management interfaces, especially when they are configured over TCP/IP stacks. Finally, relying on a perimeter defense, such as firewalls, is insufficient protection against "insider attacks" or against penetrations that compromise a system inside the firewall as a launching pad to attack network elements. The insider attack is discussed in the following session.
因此，除了对人类用户进行身份验证外，操作和管理界面还需要更复杂的协议安全性，特别是在TCP/IP堆栈上配置时。最后，依靠防火墙等周界防御不足以抵御“内部攻击”或入侵，这些入侵会危及防火墙内的系统作为攻击网络元素的发射台。内幕攻击将在下一节课中讨论。
The chain of trust model means that MPLS and GMPLS networks are particularly vulnerable to insider attacks. These can be launched by any malign person with access to any LSR in the trust domain. Insider attacks could also be launched by compromised software within the trust domain. Such attacks could, for example, advertise non-existent resources, modify advertisements from other routers, request unwanted LSPs that use network resources, or deny or modify legitimate LSP requests.
信任链模型意味着MPLS和GMPLS网络特别容易受到内部攻击。任何有权访问信任域中任何LSR的恶意用户都可以启动这些服务。内部攻击也可能由信任域内的受损软件发起。例如，此类攻击可能会播发不存在的资源，修改来自其他路由器的播发，请求使用网络资源的不需要的LSP，或者拒绝或修改合法的LSP请求。
Protection against insider attacks is largely for future study in MPLS and GMPLS networks. Some protection can be obtained by providing strict security for software upgrades and tight OAM access control procedures. Further protection can be achieved by strict control of user (i.e., operator) access to LSRs. Software change management and change tracking (e.g., CVS diffs from text-based configuration files) helps in spotting irregularities and human errors. In some cases, configuration change approval processes may also be warranted. Software tools could be used to check configurations for consistency and compliance. Software tools may also be used to monitor and report network behavior and activity in order to quickly spot any irregularities that may be the result of an insider attack.
在MPLS和GMPLS网络中，防范内部攻击主要是为了将来的研究。通过为软件升级提供严格的安全性和严格的OAM访问控制过程，可以获得一些保护。通过严格控制用户（即操作员）对LSR的访问，可以实现进一步的保护。软件变更管理和变更跟踪（例如，基于文本的配置文件中的CVS差异）有助于发现异常情况和人为错误。在某些情况下，配置变更批准流程也可能得到保证。软件工具可用于检查配置的一致性和合规性。软件工具还可用于监控和报告网络行为和活动，以便快速发现可能由内部攻击导致的任何违规行为。
The defensive techniques discussed in this document are intended to describe methods by which some security threats can be addressed. They are not intended as requirements for all MPLS/GMPLS implementations. The MPLS/GMPLS provider should determine the applicability of these techniques to the provider's specific service offerings, and the end user may wish to assess the value of these techniques to the user's service requirements. The operational environment determines the security requirements. Therefore,
本文档中讨论的防御技术旨在描述解决某些安全威胁的方法。它们不是所有MPLS/GMPLS实施的要求。MPLS/GMPLS提供商应确定这些技术对提供商的特定服务产品的适用性，最终用户可能希望评估这些技术对用户服务需求的价值。操作环境决定了安全要求。因此
protocol designers need to provide a full set of security services, which can be used where appropriate.
协议设计者需要提供一整套安全服务，这些服务可以在适当的地方使用。
The techniques discussed here include encryption, authentication, filtering, firewalls, access control, isolation, aggregation, and others.
这里讨论的技术包括加密、身份验证、过滤、防火墙、访问控制、隔离、聚合等。
Often, security is achieved by careful protocol design, rather than by adding a security method. For example, one method of mitigating DoS attacks is to make sure that innocent parties cannot be used to amplify the attack. Security works better when it is "designed in" rather than "added on".
通常，安全性是通过仔细的协议设计实现的，而不是通过添加安全方法。例如，减轻DoS攻击的一种方法是确保无辜方不能被用来放大攻击。安全性在“设计于”而不是“添加于”时工作得更好。
Nothing is ever 100% secure. Defense therefore involves protecting against those attacks that are most likely to occur or that have the most direct consequences if successful. For those attacks that are protected against, absolute protection is seldom achievable; more often it is sufficient just to make the cost of a successful attack greater than what the adversary will be willing or able to expend.
没有什么是百分之百安全的。因此，防御包括防范最有可能发生的攻击或成功后产生最直接后果的攻击。对于那些受到保护的攻击，绝对保护很少能够实现；通常情况下，只要使成功攻击的成本高于对手愿意或能够付出的成本就足够了。
Successfully defending against an attack does not necessarily mean the attack must be prevented from happening or from reaching its target. In many cases, the network can instead be designed to withstand the attack. For example, the introduction of inauthentic packets could be defended against by preventing their introduction in the first place, or by making it possible to identify and eliminate them before delivery to the MPLS/GMPLS user's system. The latter is frequently a much easier task.
成功防御攻击并不一定意味着必须阻止攻击发生或到达目标。在许多情况下，网络可以设计为抵御攻击。例如，可以通过首先防止引入不真实的数据包，或者通过在将其交付到MPLS/GMPLS用户系统之前识别并消除它们来防止引入不真实的数据包。后者通常是一项容易得多的任务。
To prevent security issues arising from some DoS attacks or from malicious or accidental misconfiguration, it is critical that devices in the MPLS/GMPLS should only accept connections or control messages from valid sources. Authentication refers to methods to ensure that message sources are properly identified by the MPLS/GMPLS devices with which they communicate. This section focuses on identifying the scenarios in which sender authentication is required and recommends authentication mechanisms for these scenarios.
为了防止由于某些DoS攻击或恶意或意外错误配置而引起的安全问题，MPLS/GMPLS中的设备应仅接受来自有效来源的连接或控制消息，这一点至关重要。认证指的是确保消息源由与其通信的MPLS/GMPLS设备正确识别的方法。本节重点介绍需要发送方身份验证的场景，并为这些场景推荐身份验证机制。
Cryptographic techniques (authentication, integrity, and encryption) do not protect against some types of denial-of-service attacks, specifically resource exhaustion attacks based on CPU or bandwidth exhaustion. In fact, the software-based cryptographic processing required to decrypt or check authentication may in some cases increase the effect of these resource exhaustion attacks. With a hardware cryptographic accelerator, attack packets can be dropped at line speed without a cost to software cycles. Cryptographic
加密技术（身份验证、完整性和加密）无法抵御某些类型的拒绝服务攻击，特别是基于CPU或带宽耗尽的资源耗尽攻击。事实上，解密或检查身份验证所需的基于软件的加密处理在某些情况下可能会增加这些资源耗尽攻击的效果。使用硬件加密加速器，攻击数据包可以以线路速度丢弃，而不会对软件周期造成损失。加密
techniques may, however, be useful against resource exhaustion attacks based on the exhaustion of state information (e.g., TCP SYN attacks).
然而，这些技术可能对基于状态信息耗尽的资源耗尽攻击（例如，TCP SYN攻击）有用。
The MPLS data plane, as presently defined, is not amenable to source authentication, as there are no source identifiers in the MPLS packet to authenticate. The MPLS label is only locally meaningful. It may be assigned by a downstream node or upstream node for multicast support.
目前定义的MPLS数据平面不适于源认证，因为MPLS分组中没有要认证的源标识符。MPLS标签仅在本地有意义。它可以由下游节点或上游节点分配用于多播支持。
When the MPLS payload carries identifiers that may be authenticated (e.g., IP packets), authentication may be carried out at the client level, but this does not help the MPLS SP, as these client identifiers belong to an external, untrusted network.
当MPLS有效载荷携带可被认证的标识符（例如，IP分组）时，可在客户端级别执行认证，但这无助于MPLS SP，因为这些客户端标识符属于外部的、不受信任的网络。
Management system authentication includes the authentication of a PE to a centrally managed network management or directory server when directory-based "auto-discovery" is used. It also includes authentication of a CE to the configuration server, when a configuration server system is used.
管理系统身份验证包括在使用基于目录的“自动发现”时，PE对集中管理的网络管理或目录服务器的身份验证。当使用配置服务器系统时，它还包括CE到配置服务器的身份验证。
Authentication should be bidirectional, including PE or CE to configuration server authentication for the PE or CE to be certain it is communicating with the right server.
身份验证应该是双向的，包括PE或CE到配置服务器的身份验证，以确保PE或CE与正确的服务器通信。
Peer-to-peer authentication includes peer authentication for network control protocols (e.g., LDP, BGP, etc.) and other peer authentication (i.e., authentication of one IPsec security gateway by another).
对等认证包括针对网络控制协议的对等认证（例如，LDP、BGP等）和其他对等认证（例如，一个IPsec安全网关对另一个IPsec安全网关的认证）。
Authentication should be bidirectional, including PE or CE to configuration server authentication for the PE or CE to be certain it is communicating with the right server.
身份验证应该是双向的，包括PE或CE到配置服务器的身份验证，以确保PE或CE与正确的服务器通信。
As indicated in Section 5.1.1, authentication should be bidirectional.
如第5.1.1节所述，认证应是双向的。
Cryptographic techniques offer several mechanisms for authenticating the identity of devices or individuals. These include the use of shared secret keys, one-time keys generated by accessory devices or software, user-ID and password pairs, and a range of public-private
密码技术提供了几种验证设备或个人身份的机制。其中包括使用共享密钥、由附属设备或软件生成的一次性密钥、用户ID和密码对，以及一系列公私密钥
key systems. Another approach is to use a hierarchical Certification Authority system to provide digital certificates.
关键系统。另一种方法是使用分级证书颁发机构系统来提供数字证书。
This section describes or provides references to the specific cryptographic approaches for authenticating identity. These approaches provide secure mechanisms for most of the authentication scenarios required in securing an MPLS/GMPLS network.
本节描述或提供对身份验证的特定加密方法的参考。这些方法为保护MPLS/GMPLS网络所需的大多数身份验证方案提供了安全机制。
MPLS/GMPLS defenses against a wide variety of attacks can be enhanced by the proper application of cryptographic techniques. These same cryptographic techniques are applicable to general network communications and can provide confidentiality (encryption) of communication between devices, authenticate the identities of the devices, and detect whether the data being communicated has been changed during transit or replayed from previous messages.
正确应用密码技术可以增强MPLS/GMPLS对各种攻击的防御能力。这些相同的加密技术适用于一般网络通信，并且可以提供设备之间通信的机密性（加密），验证设备的身份，并检测正在通信的数据是否在传输过程中发生了更改或从以前的消息中重播。
Several aspects of authentication are addressed in some detail in a separate "Authentication" section (Section 5.1).
认证的几个方面在单独的“认证”部分（第5.1节）中有详细说明。
Cryptographic methods add complexity to a service and thus, for a few reasons, may not be the most practical solution in every case. Cryptography adds an additional computational burden to devices, which may reduce the number of user connections that can be handled on a device or otherwise reduce the capacity of the device, potentially driving up the provider's costs. Typically, configuring encryption services on devices adds to the complexity of their configuration and adds labor cost. Some key management system is usually needed. Packet sizes are typically increased when the packets are encrypted or have integrity checks or replay counters added, increasing the network traffic load and adding to the likelihood of packet fragmentation with its increased overhead. (This packet length increase can often be mitigated to some extent by data compression techniques, but at the expense of additional computational burden.) Finally, some providers may employ enough other defensive techniques, such as physical isolation or filtering and firewall techniques, that they may not perceive additional benefit from encryption techniques.
加密方法增加了服务的复杂性，因此，出于一些原因，可能不是所有情况下最实用的解决方案。加密技术给设备增加了额外的计算负担，这可能会减少设备上可以处理的用户连接数量，或者以其他方式降低设备的容量，可能会推高提供商的成本。通常，在设备上配置加密服务会增加其配置的复杂性并增加人工成本。通常需要一些密钥管理系统。当数据包被加密或添加完整性检查或重播计数器时，数据包大小通常会增加，从而增加网络流量负载，并增加数据包碎片的可能性，同时增加开销。（这种数据包长度的增加通常可以通过数据压缩技术在一定程度上得到缓解，但代价是额外的计算负担。）最后，一些提供商可能会采用足够多的其他防御技术，如物理隔离或过滤以及防火墙技术，他们可能没有意识到加密技术带来的额外好处。
Users may wish to provide confidentiality end to end. Generally, encrypting for confidentiality must be accompanied with cryptographic integrity checks to prevent certain active attacks against the encrypted communications. On today's processors, encryption and integrity checks run extremely quickly, but key management may be more demanding in terms of both computational and administrative overhead.
用户可能希望提供端到端的保密性。通常，保密加密必须伴随着加密完整性检查，以防止针对加密通信的某些主动攻击。在今天的处理器上，加密和完整性检查运行得非常快，但密钥管理在计算和管理开销方面可能要求更高。
The trust model among the MPLS/GMPLS user, the MPLS/GMPLS provider, and other parts of the network is a major element in determining the applicability of cryptographic protection for any specific MPLS/GMPLS implementation. In particular, it determines where cryptographic protection should be applied:
MPLS/GMPLS用户、MPLS/GMPLS提供商和网络其他部分之间的信任模型是确定任何特定MPLS/GMPLS实现的加密保护适用性的主要因素。特别是，它确定了应在何处应用加密保护：
- If the data path between the user's site and the provider's PE is not trusted, then it may be used on the PE-CE link.
- 如果用户站点和提供商PE之间的数据路径不受信任，则可在PE-CE链路上使用。
- If some part of the backbone network is not trusted, particularly in implementations where traffic may travel across the Internet or multiple providers' networks, then the PE-PE traffic may be cryptographically protected. One also should consider cases where L1 technology may be vulnerable to eavesdropping.
- 如果骨干网络的某个部分不可信，特别是在流量可能通过互联网或多个提供商的网络传输的实现中，则PE-PE流量可能受到加密保护。还应该考虑L1技术可能容易被窃听的情况。
- If the user does not trust any zone outside of its premises, it may require end-to-end or CE-CE cryptographic protection. This fits within the scope of this MPLS/GMPLS security framework when the CE is provisioned by the MPLS/GMPLS provider.
- 如果用户不信任其场所外的任何区域，则可能需要端到端或CE-CE加密保护。当CE由MPLS/GMPLS提供商提供时，这符合此MPLS/GMPLS安全框架的范围。
- If the user requires remote access to its site from a system at a location that is not a customer location (for example, access by a traveler), there may be a requirement for cryptographically protecting the traffic between that system and an access point or a customer's site. If the MPLS/GMPLS provider supplies the access point, then the customer must cooperate with the provider to handle the access control services for the remote users. These access control services are usually protected cryptographically, as well.
- 如果用户需要从非客户位置的系统远程访问其站点（例如，由旅行者访问），则可能需要加密保护该系统与接入点或客户站点之间的通信量。如果MPLS/GMPLS提供商提供接入点，则客户必须与提供商合作，为远程用户处理访问控制服务。这些访问控制服务通常也受到加密保护。
Access control usually starts with authentication of the entity. If cryptographic services are part of the scenario, then it is important to bind the authentication to the key management. Otherwise, the protocol is vulnerable to being hijacked between the authentication and key management.
访问控制通常从实体的身份验证开始。如果加密服务是场景的一部分，那么将身份验证绑定到密钥管理非常重要。否则，该协议很容易在身份验证和密钥管理之间被劫持。
Although CE-CE cryptographic protection can provide integrity and confidentiality against third parties, if the MPLS/GMPLS provider has complete management control over the CE (encryption) devices, then it may be possible for the provider to gain access to the user's traffic or internal network. Encryption devices could potentially be reconfigured to use null encryption, bypass cryptographic processing altogether, reveal internal configuration, or provide some means of sniffing or diverting unencrypted traffic. Thus an implementation using CE-CE encryption needs to consider the trust relationship between the MPLS/GMPLS user and provider. MPLS/GMPLS users and providers may wish to negotiate a service level agreement (SLA) for CE-CE encryption that provides an acceptable demarcation of
尽管CE-CE加密保护可针对第三方提供完整性和保密性，但如果MPLS/GMPLS提供商对CE（加密）设备具有完全的管理控制，则提供商可能获得对用户流量或内部网络的访问权。加密设备可能被重新配置为使用空加密、完全绕过加密处理、显示内部配置或提供一些嗅探或转移未加密流量的方法。因此，使用CE-CE加密的实现需要考虑MPLS/GMPLS用户和提供者之间的信任关系。MPLS/GMPLS用户和提供商可能希望协商CE-CE加密的服务级别协议（SLA），该协议提供了一个可接受的界限
responsibilities for management of cryptographic protection on the CE devices. The demarcation may also be affected by the capabilities of the CE devices. For example, the CE might support some partitioning of management, a configuration lock-down ability, or shared capability to verify the configuration. In general, the MPLS/GMPLS user needs to have a fairly high level of trust that the MPLS/GMPLS provider will properly provision and manage the CE devices, if the managed CE-CE model is used.
负责管理CE设备上的加密保护。标定也可能受到CE设备能力的影响。例如，CE可能支持一些管理分区、配置锁定功能或验证配置的共享功能。通常，如果使用托管CE-CE模型，MPLS/GMPLS用户需要对MPLS/GMPLS提供商将正确提供和管理CE设备有相当高的信任度。
IPsec [RFC4301] [RFC4302] [RFC4835] [RFC4306] [RFC4309] [RFC2411] [IPSECME-ROADMAP] is the security protocol of choice for protection at the IP layer. IPsec provides robust security for IP traffic between pairs of devices. Non-IP traffic, such as IS-IS routing, must be converted to IP (e.g., by encapsulation) in order to use IPsec. When the MPLS is encapsulating IP traffic, then IPsec covers the encryption of the IP client layer; for non-IP client traffic, see Section 5.2.4 (MPLS PWs).
IPsec[RFC4301][RFC4302][RFC4835][RFC4306][RFC4309][RFC2411][IPSECME-ROADMAP]是IP层保护的首选安全协议。IPsec为成对设备之间的IP通信提供了强大的安全性。非IP流量（如IS-IS路由）必须转换为IP（例如通过封装）才能使用IPsec。当MPLS封装IP流量时，IPsec覆盖IP客户端层的加密；有关非IP客户端流量，请参阅第5.2.4节（MPLS PWs）。
In the MPLS/GMPLS model, IPsec can be employed to protect IP traffic between PEs, between a PE and a CE, or from CE to CE. CE-to-CE IPsec may be employed in either a provider-provisioned or a user-provisioned model. Likewise, IPsec protection of data performed within the user's site is outside the scope of this document, because it is simply handled as user data by the MPLS/GMPLS core. However, if the SP performs compression, pre-encryption will have a major effect on that operation.
在MPLS/GMPLS模型中，IPsec可用于保护PE之间、PE与CE之间或CE与CE之间的IP流量。CE到CE IPsec可以在提供者提供的模型或用户提供的模型中使用。同样，在用户站点内执行的数据IPsec保护不在本文档的范围内，因为MPLS/GMPLS核心仅将其作为用户数据处理。但是，如果SP执行压缩，预加密将对该操作产生重大影响。
IPsec does not itself specify cryptographic algorithms. It can use a variety of integrity or confidentiality algorithms (or even combined integrity and confidentiality algorithms) with various key lengths, such as AES encryption or AES message integrity checks. There are trade-offs between key length, computational burden, and the level of security of the encryption. A full discussion of these trade-offs is beyond the scope of this document. In practice, any currently recommended IPsec protection offers enough security to reduce the likelihood of its being directly targeted by an attacker substantially; other weaker links in the chain of security are likely to be attacked first. MPLS/GMPLS users may wish to use a Service Level Agreement (SLA) specifying the SP's responsibility for ensuring data integrity and confidentiality, rather than analyzing the specific encryption techniques used in the MPLS/GMPLS service.
IPsec本身并不指定加密算法。它可以使用各种完整性或机密性算法（甚至组合完整性和机密性算法）和各种密钥长度，例如AES加密或AES消息完整性检查。密钥长度、计算负担和加密的安全级别之间存在权衡。对这些权衡的全面讨论超出了本文件的范围。实际上，任何当前推荐的IPsec保护都提供了足够的安全性，大大降低了被攻击者直接攻击的可能性；安全链中其他较弱的环节可能首先受到攻击。MPLS/GMPLS用户可能希望使用服务级别协议（SLA），指定SP确保数据完整性和机密性的责任，而不是分析MPLS/GMPLS服务中使用的特定加密技术。
Encryption algorithms generally come with two parameters: mode such as Cipher Block Chaining and key length such as AES-192. (This should not be confused with two other senses in which the word "mode" is used: IPsec itself can be used in Tunnel Mode or Transport Mode,
加密算法通常有两个参数：模式（如密码块链接）和密钥长度（如AES-192）。（这不应与使用“模式”一词的其他两种含义混淆：IPsec本身可用于隧道模式或传输模式，
and IKE [version 1] uses Main Mode, Aggressive Mode, or Quick Mode). It should be stressed that IPsec encryption without an integrity check is a state of sin.
IKE[version 1]使用主模式、攻击模式或快速模式）。应该强调的是，没有完整性检查的IPsec加密是一种罪恶的状态。
For many of the MPLS/GMPLS provider's network control messages and some user requirements, cryptographic authentication of messages without encryption of the contents of the message may provide appropriate security. Using IPsec, authentication of messages is provided by the Authentication Header (AH) or through the use of the Encapsulating Security Protocol (ESP) with NULL encryption. Where control messages require integrity but do not use IPsec, other cryptographic authentication methods are often available. Message authentication methods currently considered to be secure are based on hashed message authentication codes (HMAC) [RFC2104] implemented with a secure hash algorithm such as Secure Hash Algorithm 1 (SHA-1) [RFC3174]. No attacks against HMAC SHA-1 are likely to play out in the near future, but it is possible that people will soon find SHA-1 collisions. Thus, it is important that mechanisms be designed to be flexible about the choice of hash functions and message integrity checks. Also, many of these mechanisms do not include a convenient way to manage and update keys.
对于许多MPLS/GMPLS提供商的网络控制消息和一些用户需求，在不加密消息内容的情况下对消息进行加密身份验证可以提供适当的安全性。使用IPsec，消息的身份验证由身份验证头（AH）或通过使用带有空加密的封装安全协议（ESP）提供。当控制消息需要完整性但不使用IPsec时，通常可以使用其他加密身份验证方法。当前被认为是安全的消息认证方法基于使用安全哈希算法（如安全哈希算法1（SHA-1）[RFC3174]实现的哈希消息认证码（HMAC）[RFC2104]。在不久的将来，不太可能发生针对HMAC SHA-1的攻击，但人们可能很快就会发现SHA-1的碰撞。因此，重要的是，机制应设计为灵活选择哈希函数和消息完整性检查。此外，这些机制中的许多并不包括管理和更新密钥的方便方法。
A mechanism to provide a combination of confidentiality, data-origin authentication, and connectionless integrity is the use of AES in GCM (Counter with CBC-MAC) mode (RFC 4106) [RFC4106].
提供保密性、数据源身份验证和无连接完整性组合的机制是在GCM（带CBC-MAC的计数器）模式（RFC 4106）[RFC4106]中使用AES。
MPLS and GMPLS, which provide differentiated services based on traffic type, may encounter some conflicts with IPsec encryption of traffic. Because encryption hides the content of the packets, it may not be possible to differentiate the encrypted traffic in the same manner as unencrypted traffic. Although Diffserv markings are copied to the IPsec header and can provide some differentiation, not all traffic types can be accommodated by this mechanism. Using IPsec without IKE or IKEv2 (the better choice) is not advisable. IKEv2 provides IPsec Security Association creation and management, entity authentication, key agreement, and key update. It works with a variety of authentication methods including pre-shared keys, public key certificates, and EAP. If DoS attacks against IKEv2 are considered an important threat to mitigate, the cookie-based anti-spoofing feature of IKEv2 should be used. IKEv2 has its own set of cryptographic methods, but any of the default suites specified in [RFC4308] or [RFC4869] provides more than adequate security.
MPLS和GMPLS提供基于流量类型的区分服务，可能会与IPsec流量加密发生冲突。由于加密隐藏了数据包的内容，因此可能无法以与未加密流量相同的方式区分加密流量。尽管Diffserv标记被复制到IPsec报头并可以提供一些区别，但并不是所有的流量类型都可以通过这种机制来适应。不建议在没有IKE或IKEv2（更好的选择）的情况下使用IPsec。IKEv2提供IPsec安全关联的创建和管理、实体身份验证、密钥协议和密钥更新。它与多种身份验证方法一起工作，包括预共享密钥、公钥证书和EAP。如果针对IKEv2的DoS攻击被视为需要缓解的重要威胁，则应使用IKEv2基于cookie的反欺骗功能。IKEv2有自己的加密方法集，但[RFC4308]或[RFC4869]中指定的任何默认套件都提供了足够的安全性。
For configuration and management of MPLS/GMPLS devices, encryption and authentication of the management connection at a level comparable to that provided by IPsec is desirable.
对于MPLS/GMPLS设备的配置和管理，需要在与IPsec提供的级别相当的级别上对管理连接进行加密和认证。
Several methods of transporting MPLS/GMPLS device management traffic offer authentication, integrity, and confidentiality.
传输MPLS/GMPLS设备管理流量的几种方法提供身份验证、完整性和机密性。
- Secure Shell (SSH) offers protection for TELNET [STD8] or terminal-like connections to allow device configuration.
- Secure Shell（SSH）为TELNET[STD8]或类似终端的连接提供保护，以允许设备配置。
- SNMPv3 [STD62] provides encrypted and authenticated protection for SNMP-managed devices.
- SNMPv3[STD62]为SNMP管理的设备提供加密和身份验证保护。
- Transport Layer Security (TLS) [RFC5246] and the closely-related Secure Sockets Layer (SSL) are widely used for securing HTTP-based communication, and thus can provide support for most XML- and SOAP-based device management approaches.
- 传输层安全性（TLS）[RFC5246]和密切相关的安全套接字层（SSL）广泛用于保护基于HTTP的通信，因此可以支持大多数基于XML和SOAP的设备管理方法。
- Since 2004, there has been extensive work proceeding in several organizations (OASIS, W3C, WS-I, and others) on securing device management traffic within a "Web Services" framework, using a wide variety of security models, and providing support for multiple security token formats, multiple trust domains, multiple signature formats, and multiple encryption technologies.
- 自2004年以来，多个组织（OASIS、W3C、WS-I和其他组织）在“Web服务”框架内保护设备管理流量方面开展了大量工作，使用了多种安全模型，并支持多种安全令牌格式、多个信任域、多个签名格式，以及多种加密技术。
- IPsec provides security services including integrity and confidentiality at the network layer. With regards to device management, its current use is primarily focused on in-band management of user-managed IPsec gateway devices.
- IPsec在网络层提供安全服务，包括完整性和机密性。关于设备管理，其当前用途主要集中于用户管理的IPsec网关设备的带内管理。
- There is recent work in the ISMS WG (Integrated Security Model for SNMP Working Group) to define how to use SSH to secure SNMP, due to the limited deployment of SNMPv3, and the possibility of using Kerberos, particularly for interfaces like TELNET, where client code exists.
- 由于SNMPv3的部署有限，以及使用Kerberos的可能性，特别是对于存在客户端代码的TELNET等接口，ISMS WG（SNMP集成安全模型工作组）最近的工作定义了如何使用SSH保护SNMP。
In addition to IP traffic, MPLS networks may be used to transport other services such as Ethernet, ATM, Frame Relay, and TDM. This is done by setting up pseudowires (PWs) that tunnel the native service through the MPLS core by encapsulating at the edges. The PWE architecture is defined in [RFC3985].
除了IP通信，MPLS网络还可用于传输其他服务，如以太网、ATM、帧中继和TDM。这是通过设置伪线（PWs）来完成的，伪线通过边缘封装将本机服务通过MPLS核心进行隧道传输。PWE体系结构在[RFC3985]中定义。
PW tunnels may be set up using the PWE control protocol based on LDP [RFC4447], and thus security considerations for LDP will most likely be applicable to the PWE3 control protocol as well.
PW隧道可以使用基于LDP[RFC4447]的PWE控制协议建立，因此LDP的安全考虑也很可能适用于PWE3控制协议。
PW user packets contain at least one MPLS label (the PW label) and may contain one or more MPLS tunnel labels. After the label stack, there is a four-byte control word (which is optional for some PW types), followed by the native service payload. It must be stressed that encapsulation of MPLS PW packets in IP for the purpose of enabling use of IPsec mechanisms is not a valid option.
PW用户分组包含至少一个MPLS标签（PW标签），并且可以包含一个或多个MPLS隧道标签。在标签堆栈之后，有一个四字节的控制字（对于某些PW类型是可选的），后跟本机服务负载。必须强调的是，在IP中封装MPLS PW数据包以启用IPsec机制不是一个有效的选项。
The following is a non-exhaustive list of PW-specific threats:
以下是PW特定威胁的非详尽列表：
- Unauthorized setup of a PW (e.g., to gain access to a customer network)
- 未经授权设置PW（例如，访问客户网络）
- Unauthorized teardown of a PW (thus causing denial of service)
- 未经授权拆卸PW（从而导致拒绝服务）
- Malicious reroute of a PW
- PW的恶意重新路由
- Unauthorized observation of PW packets
- 未经授权观察PW数据包
- Traffic analysis of PW connectivity
- PW连通性的流量分析
- Unauthorized insertion of PW packets
- 未经授权插入PW数据包
- Unauthorized modification of PW packets
- 未经授权修改PW数据包
- Unauthorized deletion of PW packets replay of PW packets
- 未经授权删除PW数据包PW数据包的重播
- Denial of service or significant impact on PW service quality
- 拒绝服务或对PW服务质量产生重大影响
These threats are not mutually exclusive, for example, rerouting can be used for snooping or insertion/deletion/replay, etc. Multisegment PWs introduce additional weaknesses at their stitching points.
这些威胁不是相互排斥的，例如，重新路由可用于窥探或插入/删除/重放等。多段PW在其缝合点引入了额外的弱点。
The PW user plane suffers from the following inherent security weaknesses:
PW用户平面存在以下固有的安全弱点：
- Since the PW label is the only identifier in the packet, there is no authenticatable source address.
- 由于PW标签是数据包中唯一的标识符，因此没有可验证的源地址。
- Since guessing a valid PW label is not difficult, it is relatively easy to introduce seemingly valid foreign packets.
- 由于猜测有效的PW标签并不困难，因此引入看似有效的外部数据包相对容易。
- Since the PW packet is not self-describing, minor modification of control-plane packets renders the data-plane traffic useless.
- 由于PW数据包不是自描述的，因此对控制平面数据包的微小修改使得数据平面通信量无用。
- The control-word sequence number processing algorithm is susceptible to a DoS attack.
- 控制字序列号处理算法容易受到DoS攻击。
The PWE control protocol introduces its own weaknesses:
PWE控制协议引入了其自身的弱点：
- No (secure) peer autodiscovery technique has been standardized .
- 尚未标准化（安全）对等自动发现技术。
- PE authentication is not mandated, so an intruder can potentially impersonate a PE; after impersonating a PE, unauthorized PWs may be set up, consuming resources and perhaps allowing access to user networks.
- PE身份验证不是强制性的，因此入侵者可能会模拟PE；在模拟PE后，可能会设置未经授权的PW，从而消耗资源，并可能允许访问用户网络。
- Alternately, desired PWs may be torn down, giving rise to denial of service.
- 或者，所需的PWs可能会被拆除，从而导致拒绝服务。
The following characteristics of PWs can be considered security strengths:
PWs的以下特征可视为安全优势：
- The most obvious attacks require compromising edge or core routers (although not necessarily those along the PW path).
- 最明显的攻击需要破坏边缘或核心路由器（尽管不一定是沿着PW路径的路由器）。
- Adequate protection of the control-plane messaging is sufficient to rule out many types of attacks.
- 对控制平面消息的充分保护足以排除多种类型的攻击。
- PEs are usually configured to reject MPLS packets from outside the service provider network, thus ruling out insertion of PW packets from the outside (since IP packets cannot masquerade as PW packets).
- PEs通常配置为拒绝来自服务提供商网络外部的MPLS数据包，从而排除了从外部插入PW数据包的可能性（因为IP数据包不能伪装成PW数据包）。
In MPLS/GMPLS, cryptographic protection could potentially be applied to the MPLS/GMPLS traffic at several different places. This section discusses some of the tradeoffs in implementing encryption in several different connection topologies among different devices within an MPLS/GMPLS network.
在MPLS/GMPLS中，加密保护可能应用于多个不同位置的MPLS/GMPLS流量。本节讨论在MPLS/GMPLS网络中不同设备之间的几种不同连接拓扑中实现加密的一些权衡。
Cryptographic protection typically involves a pair of devices that protect the traffic passing between them. The devices may be directly connected (over a single "hop"), or intervening devices may transport the protected traffic between the pair of devices. The extreme cases involve using protection between every adjacent pair of devices along a given path (hop-by-hop), or using protection only between the end devices along a given path (end-to-end). To keep this discussion within the scope of this document, the latter ("end-to-end") case considered here is CE-to-CE rather than fully end-to-end.
加密保护通常涉及一对设备，用于保护它们之间的通信量。这些设备可以直接连接（通过单个“跃点”），或者中间设备可以在这对设备之间传输受保护的通信量。极端情况涉及沿给定路径（逐跳）在每对相邻设备之间使用保护，或仅沿给定路径（端到端）在端设备之间使用保护。为了将本讨论保持在本文件的范围内，此处考虑的后一种（“端到端”）情况是CE到CE，而不是完全端到端。
Figure 3 depicts a simplified topology showing the Customer Edge (CE) devices, the Provider Edge (PE) devices, and a variable number (three are shown) of Provider core (P) devices, which might be present along the path between two sites in a single VPN operated by a single service provider (SP).
图3描述了一个简化的拓扑结构，其中显示了客户边缘（CE）设备、提供商边缘（PE）设备和数量可变（显示了三个）的提供商核心（P）设备，这些设备可能位于由单个服务提供商（SP）操作的单个VPN中两个站点之间的路径上。
Site_1---CE---PE---P---P---P---PE---CE---Site_2
Site_1---CE---PE---P---P---P---PE---CE---Site_2
Figure 3: Simplified Topology Traversing through MPLS/GMPLS Core
图3：通过MPLS/GMPLS核心的简化拓扑遍历
Within this simplified topology, and assuming that the P devices are not involved with cryptographic protection, four basic, feasible configurations exist for protecting connections among the devices:
在该简化拓扑中，并且假设P设备不涉及密码保护，存在四种基本的、可行的配置来保护设备之间的连接：
1) Site-to-site (CE-to-CE) - Apply confidentiality or integrity services between the two CE devices, so that traffic will be protected throughout the SP's network.
1) 站点到站点（CE到CE）-在两个CE设备之间应用机密性或完整性服务，以便在整个SP网络中保护流量。
2) Provider edge-to-edge (PE-to-PE) - Apply confidentiality or integrity services between the two PE devices. Unprotected traffic is received at one PE from the customer's CE, then it is protected for transmission through the SP's network to the other PE, and finally it is decrypted or checked for integrity and sent to the other CE.
2) 提供商边缘到边缘（PE到PE）-在两个PE设备之间应用机密性或完整性服务。一个PE从客户的CE接收未受保护的流量，然后对其进行保护，以便通过SP的网络传输到另一个PE，最后对其进行解密或完整性检查，并发送到另一个CE。
3) Access link (CE-to-PE) - Apply confidentiality or integrity services between the CE and PE on each side or on only one side.
3) 接入链路（CE到PE）-在CE和PE之间的每一侧或仅在一侧应用保密性或完整性服务。
4) Configurations 2 and 3 above can also be combined, with confidentiality or integrity running from CE to PE, then PE to PE, and then PE to CE.
4) 上述配置2和3也可以组合使用，保密性或完整性从CE到PE，然后从PE到PE，再从PE到CE。
Among the four feasible configurations, key tradeoffs in considering encryption include:
在四种可行的配置中，考虑加密时的密钥权衡包括：
- Vulnerability to link eavesdropping or tampering - assuming an attacker can observe or modify data in transit on the links, would it be protected by encryption?
- 链接窃听或篡改漏洞-假设攻击者可以观察或修改链接上传输的数据，它会受到加密保护吗？
- Vulnerability to device compromise - assuming an attacker can get access to a device (or freely alter its configuration), would the data be protected?
- 设备漏洞-假设攻击者可以访问设备（或自由更改其配置），数据是否会受到保护？
- Complexity of device configuration and management - given the number of sites per VPN customer as Nce and the number of PEs participating in a given VPN as Npe, how many device configurations need to be created or maintained, and how do those configurations scale?
- 设备配置和管理的复杂性-考虑到每个VPN客户作为Nce的站点数量和作为Npe参与给定VPN的PE数量，需要创建或维护多少设备配置，以及这些配置如何扩展？
- Processing load on devices - how many cryptographic operations must be performed given N packets? - This raises considerations of device capacity and perhaps end-to-end delay.
- 设备上的处理负载-给定N个数据包必须执行多少加密操作？-这引起了对设备容量和端到端延迟的考虑。
- Ability of the SP to provide enhanced services (QoS, firewall, intrusion detection, etc.) - Can the SP inspect the data to provide these services?
- SP提供增强服务（QoS、防火墙、入侵检测等）的能力—SP能否检查数据以提供这些服务？
These tradeoffs are discussed for each configuration, below:
下面讨论了每种配置的这些权衡：
1) Site-to-site (CE-to-CE)
1) 现场到现场（CE到CE）
Link eavesdropping or tampering - protected on all links. Device compromise - vulnerable to CE compromise.
链接窃听或篡改-在所有链接上受保护。设备损坏-易受CE损坏。
Complexity - single administration, responsible for one device per site (Nce devices), but overall configuration per VPN scales as Nce**2.
复杂性-单一管理，负责每个站点一个设备（Nce设备），但每个VPN的总体配置可扩展为Nce**2。
Though the complexity may be reduced: 1) In practice, as Nce grows, the number of VPNs falls off from being a full clique; 2) If the CEs run an automated key management protocol, then they should be able to set up and tear down secured VPNs without any intervention.
虽然复杂性可能会降低：1）在实践中，随着Nce的增长，虚拟专用网络的数量从一个完整的集团中下降；2） 如果CEs运行自动密钥管理协议，那么他们应该能够在没有任何干预的情况下设置和拆除安全的VPN。
Processing load - on each of the two CEs, each packet is cryptographically processed (2P), though the protection may be "integrity check only" or "integrity check plus encryption."
处理负载-在两个CE中的每个CE上，每个数据包都经过加密处理（2P），尽管保护可能是“仅完整性检查”或“完整性检查加加密”
Enhanced services - severely limited; typically only Diffserv markings are visible to the SP, allowing some QoS services. The CEs could also use the IPv6 Flow Label to identify traffic classes.
强化服务——严重受限；通常，SP只能看到Diffserv标记，从而允许某些QoS服务。CEs还可以使用IPv6流标签来识别流量类别。
2) Provider Edge-to-Edge (PE-to-PE)
2) 提供商边缘到边缘（PE到PE）
Link eavesdropping or tampering - vulnerable on CE-PE links; protected on SP's network links.
链接窃听或篡改-易受CE-PE链接攻击；在SP的网络链接上受保护。
Device compromise - vulnerable to CE or PE compromise.
设备损坏-易受CE或PE损坏。
Complexity - single administration, Npe devices to configure. (Multiple sites may share a PE device so Npe is typically much smaller than Nce.) Scalability of the overall configuration depends on the PPVPN type: if the cryptographic protection is separate per VPN context, it scales as Npe**2 per customer VPN. If it is per-PE, it scales as Npe**2 for all customer VPNs combined.
复杂性-单一管理，需要配置Npe设备。（多个站点可能共享一个PE设备，因此Npe通常比Nce小得多。）总体配置的可扩展性取决于PPVPN类型：如果加密保护在每个VPN上下文中是独立的，则其扩展为每个客户VPN的Npe**2。如果是每个PE，则对于所有客户VPN组合，其扩展为Npe**2。
Processing load - on each of the two PEs, each packet is cryptographically processed (2P).
处理负载-在两个PE中的每个PE上，每个数据包都经过加密处理（2P）。
Enhanced services - full; SP can apply any enhancements based on detailed view of traffic.
强化服务-全面服务；SP可以根据流量的详细视图应用任何增强功能。
3) Access Link (CE-to-PE)
3) 接入链路（CE到PE）
Link eavesdropping or tampering - protected on CE-PE link; vulnerable on SP's network links.
链路窃听或篡改-受CE-PE链路保护；SP的网络链接上存在漏洞。
Device compromise - vulnerable to CE or PE compromise.
设备损坏-易受CE或PE损坏。
Complexity - two administrations (customer and SP) with device configuration on each side (Nce + Npe devices to configure), but because there is no mesh, the overall configuration scales as Nce.
复杂性-两个管理（客户和SP），每侧都有设备配置（要配置的是Nce+Npe设备），但由于没有网格，因此总体配置按Nce扩展。
Processing load - on each of the two CEs, each packet is cryptographically processed, plus on each of the two PEs, each packet is cryptographically processed (4P).
处理负载-在两个CE中的每个CE上，每个数据包都经过加密处理，另外在两个PE中的每个PE上，每个数据包都经过加密处理（4P）。
Enhanced services - full; SP can apply any enhancements based on a detailed view of traffic.
强化服务-全面服务；SP可以根据流量的详细视图应用任何增强功能。
4) Combined Access link and PE-to-PE (essentially hop-by-hop).
4) 组合接入链路和PE到PE（基本上是逐跳）。
Link eavesdropping or tampering - protected on all links.
链接窃听或篡改-在所有链接上受保护。
Device compromise - vulnerable to CE or PE compromise.
设备损坏-易受CE或PE损坏。
Complexity - two administrations (customer and SP) with device configuration on each side (Nce + Npe devices to configure). Scalability of the overall configuration depends on the PPVPN type: If the cryptographic processing is separate per VPN context, it scales as Npe**2 per customer VPN. If it is per-PE, it scales as Npe**2 for all customer VPNs combined.
复杂性-两个管理（客户和SP），每侧都有设备配置（需要配置Nce+Npe设备）。整体配置的可伸缩性取决于PPVPN类型：如果加密处理是每个VPN上下文单独进行的，则其可伸缩性为每个客户VPN的Npe**2。如果是每个PE，则对于所有客户VPN组合，其扩展为Npe**2。
Processing load - on each of the two CEs, each packet is cryptographically processed, plus on each of the two PEs, each packet is cryptographically processed twice (6P).
处理负载-在两个CE中的每个CE上，每个数据包都经过加密处理，另外在两个PE中的每个PE上，每个数据包经过两次加密处理（6P）。
Enhanced services - full; SP can apply any enhancements based on a detailed view of traffic.
强化服务-全面服务；SP可以根据流量的详细视图应用任何增强功能。
Given the tradeoffs discussed above, a few conclusions can be drawn:
鉴于以上讨论的权衡，可以得出以下结论：
- Configurations 2 and 3 are subsets of 4 that may be appropriate alternatives to 4 under certain threat models; the remainder of these conclusions compare 1 (CE-to-CE) versus 4 (combined access links and PE-to-PE).
- 配置2和3是4的子集，在某些威胁模型下可能是4的合适替代方案；这些结论的其余部分将1（CE对CE）与4（组合接入链路和PE对PE）进行比较。
- If protection from link eavesdropping or tampering is all that is important, then configurations 1 and 4 are equivalent.
- 如果防止链路窃听或篡改是最重要的，那么配置1和4是等效的。
- If protection from device compromise is most important and the threat is to the CE devices, both cases are equivalent; if the threat is to the PE devices, configuration 1 is better.
- 如果保护设备免受危害是最重要的，并且威胁是对CE设备的，则这两种情况是等效的；如果威胁是PE设备，则配置1更好。
- If reducing complexity is most important, and the size of the network is small, configuration 1 is better. Otherwise, configuration 4 is better because rather than a mesh of CE devices, it requires a smaller mesh of PE devices. Also, under some PPVPN approaches, the scaling of 4 is further improved by sharing the same PE-PE mesh across all VPN contexts. The scaling advantage of 4 may be increased or decreased in any given situation if the CE devices are simpler to configure than the PE devices, or vice-versa.
- 如果降低复杂性是最重要的，并且网络规模较小，则配置1更好。否则，配置4更好，因为它需要更小的PE设备网格，而不是CE设备网格。此外，在某些PPVPN方法下，通过在所有VPN上下文中共享相同的PE-PE网格，4的可扩展性得到进一步改进。如果CE设备比PE设备更易于配置，则在任何给定情况下4的缩放优势可以增加或减少，反之亦然。
- If the overall processing load is a key factor, then 1 is better, unless the PEs come with a hardware encryption accelerator and the CEs do not.
- 如果整体处理负载是一个关键因素，那么1更好，除非PEs配备了硬件加密加速器，而CEs没有。
- If the availability of enhanced services support from the SP is most important, then 4 is best.
- 如果SP提供的增强服务支持是最重要的，那么4是最好的。
- If users are concerned with having their VPNs misconnected with other users' VPNs, then encryption with 1 can provide protection.
- 如果用户担心他们的VPN与其他用户的VPN错误连接，则使用1加密可以提供保护。
As a quick overall conclusion, CE-to-CE protection is better against device compromise, but this comes at the cost of enhanced services and at the cost of operational complexity due to the Order(n**2) scaling of a larger mesh.
作为一个快速的总体结论，CE-to-CE保护更好地防止设备损坏，但这是以增强服务为代价的，并且由于更大网格的顺序（n**2）缩放，以操作复杂性为代价的。
This analysis of site-to-site vs. hop-by-hop tradeoffs does not explicitly include cases of multiple providers cooperating to provide a PPVPN service, public Internet VPN connectivity, or remote access VPN service, but many of the tradeoffs are similar.
对站点到站点与逐跳权衡的分析并未明确包括多个提供商合作提供PPVPN服务、公共互联网VPN连接或远程访问VPN服务的情况，但许多权衡是相似的。
In addition to the simplified models, the following should also be considered:
除简化模型外，还应考虑以下因素：
- There are reasons, perhaps, to protect a specific P-to-P or PE-to-P.
- 也许有理由保护特定的P-to-P或PE-to-P。
- There may be reasons to do multiple encryptions over certain segments. One may be using an encrypted wireless link under our IPsec VPN to access an SSL-secured web site to download encrypted email attachments: four layers.)
- 可能有理由对某些段进行多次加密。您可能正在使用IPSecVPN下的加密无线链接访问SSL安全的网站，以下载加密的电子邮件附件：四层。）
- It may be appropriate that, for example, cryptographic integrity checks are applied end to end, and confidentiality is applied over a shorter span.
- 例如，端到端应用加密完整性检查，并且在较短的范围内应用机密性，这可能是合适的。
- Different cryptographic protection may be required for control protocols and data traffic.
- 控制协议和数据通信可能需要不同的加密保护。
- Attention needs to be given to how auxiliary traffic is protected, e.g., the ICMPv6 packets that flow back during PMTU discovery, among other examples.
- 需要注意如何保护辅助流量，例如，在PMTU发现期间回流的ICMPv6数据包，以及其他示例。
Access control techniques include packet-by-packet or packet-flow-by-packet-flow access control by means of filters and firewalls on IPv4/IPv6 packets, as well as by means of admitting a "session" for a control, signaling, or management protocol. Enforcement of access control by isolated infrastructure addresses is discussed in Section 5.4 of this document.
访问控制技术包括通过IPv4/IPv6数据包上的过滤器和防火墙，以及通过允许控制、信令或管理协议的“会话”，逐数据包或逐数据包流访问控制。本文件第5.4节讨论了通过隔离基础设施地址实施访问控制。
In this document, we distinguish between filtering and firewalls based primarily on the direction of traffic flow. We define filtering as being applicable to unidirectional traffic, while a firewall can analyze and control both sides of a conversation.
在本文中，我们主要根据流量的方向来区分过滤和防火墙。我们将过滤定义为适用于单向流量，而防火墙可以分析和控制会话双方。
The definition has two significant corollaries:
该定义有两个重要的推论：
- Routing or traffic flow symmetry: A firewall typically requires routing symmetry, which is usually enforced by locating a firewall where the network topology assures that both sides of a conversation will pass through the firewall. A filter can operate upon traffic flowing in one direction, without considering traffic in the reverse direction. Beware that this concept could result in a single point of failure.
- 路由或流量对称性：防火墙通常需要路由对称性，这通常通过定位防火墙来实现，其中网络拓扑确保会话双方都将通过防火墙。过滤器可以对单向流动的交通流进行操作，而不考虑反向的交通流。请注意，此概念可能导致单点故障。
- Statefulness: Because it receives both sides of a conversation, a firewall may be able to interpret a significant amount of information concerning the state of that conversation and use this information to control access. A filter can maintain some limited state information on a unidirectional flow of packets, but cannot determine the state of the bidirectional conversation as precisely as a firewall.
- 状态性：因为它接收会话双方，防火墙可能能够解释与会话状态有关的大量信息，并使用这些信息来控制访问。过滤器可以在单向数据包流上维护一些有限的状态信息，但不能像防火墙那样精确地确定双向对话的状态。
For a general description on filtering and rate limiting for IP networks, please also see [OPSEC-FILTER].
有关IP网络过滤和速率限制的一般说明，请参阅[OPSEC-FILTER]。
It is relatively common for routers to filter packets. That is, routers can look for particular values in certain fields of the IP or higher-level (e.g., TCP or UDP) headers. Packets matching the criteria associated with a particular filter may either be discarded or given special treatment. Today, not only routers, but most end hosts have filters, and every instance of IPsec is also a filter [RFC4301].
路由器过滤数据包是比较常见的。也就是说，路由器可以在IP或更高级别（例如TCP或UDP）头的某些字段中查找特定值。与特定过滤器相关联的标准匹配的包可以被丢弃或给予特殊处理。今天，不仅路由器，而且大多数终端主机都有过滤器，IPsec的每个实例也是一个过滤器[RFC4301]。
In discussing filters, it is useful to separate the filter characteristics that may be used to determine whether a packet matches a filter from the packet actions applied to those packets matching a particular filter.
在讨论过滤器时，将可用于确定包是否与过滤器匹配的过滤器特性与应用于与特定过滤器匹配的那些包的包动作分开是有用的。
o Filter Characteristics
o 滤波器特性
Filter characteristics or rules are used to determine whether a particular packet or set of packets matches a particular filter.
筛选器特征或规则用于确定特定数据包或数据包集是否与特定筛选器匹配。
In many cases, filter characteristics may be stateless. A stateless filter determines whether a particular packet matches a filter based solely on the filter definition, normal forwarding information (such as the next hop for a packet), the interface on which a packet arrived, and the contents of that individual packet. Typically, stateless filters may consider the incoming and outgoing logical or physical interface, information in the IP header, and information in higher-layer headers such as the TCP or UDP header. Information in the IP header to be considered may for example include source and destination IP addresses; Protocol field, Fragment Offset, and TOS field in IPv4; or Next Header, Extension Headers, Flow label, etc. in IPv6. Filters also may consider fields in the TCP or UDP header such as the Port numbers, the SYN field in the TCP header, as well as ICMP and ICMPv6 type.
在许多情况下，过滤器特征可能是无状态的。无状态筛选器仅基于筛选器定义、正常转发信息（例如，数据包的下一跳）、数据包到达的接口以及单个数据包的内容来确定特定数据包是否与筛选器匹配。通常，无状态过滤器可以考虑传入和传出的逻辑或物理接口、IP报头中的信息、以及诸如TCP或UDP报头之类的更高层报头中的信息。要考虑的IP报头中的信息可以例如包括源IP地址和目的IP地址；IPv4中的协议字段、片段偏移量和TOS字段；或者IPv6中的下一个标头、扩展标头、流标签等。过滤器还可以考虑TCP或UDP报头中的字段，例如端口号、TCP报头中的SYN字段、ICMP和ICMPv6类型。
Stateful filtering maintains packet-specific state information to aid in determining whether a filter rule has been met. For example, a device might apply stateless filtering to the first fragment of a fragmented IPv4 packet. If the filter matches, then the data unit ID may be remembered and other fragments of the same packet may then be considered to match the same filter. Stateful filtering is more commonly done in firewalls, although firewall technology may be added to routers. The data unit ID can also be a Fragment Extension Header Identification field in IPv6.
有状态筛选维护特定于数据包的状态信息，以帮助确定是否满足筛选规则。例如，设备可能会对碎片化IPv4数据包的第一个片段应用无状态筛选。如果过滤器匹配，则可以记住数据单元ID，并且可以认为相同分组的其他片段与相同过滤器匹配。状态过滤通常在防火墙中完成，尽管防火墙技术可能会添加到路由器中。数据单元ID也可以是IPv6中的片段扩展标头标识字段。
o Actions based on Filter Results
o 基于筛选结果的操作
If a packet, or a series of packets, matches a specific filter, then a variety of actions may be taken based on that match. Examples of such actions include:
如果一个数据包或一系列数据包与特定的过滤器匹配，则可以基于该匹配采取各种操作。这些行动的例子包括：
- Discard
- 丢弃
In many cases, filters are set to catch certain undesirable packets. Examples may include packets with forged or invalid source addresses, packets that are part of a DoS or Distributed DoS (DDoS) attack, or packets trying to access unallowed resources (such as network management packets from an unauthorized source). Where such filters are activated, it is common to discard the packet or set of packets matching the filter silently. The discarded packets may of course also be counted or logged.
在许多情况下，设置过滤器以捕获某些不需要的数据包。示例可能包括具有伪造或无效源地址的数据包、属于DoS或分布式DoS（DDoS）攻击的数据包，或试图访问不允许的资源的数据包（例如来自未授权源的网络管理数据包）。在激活此类过滤器的情况下，通常会以静默方式丢弃与过滤器匹配的数据包或数据包集。丢弃的包当然也可以被计数或记录。
- Set CoS
- 设置CoS
A filter may be used to set the class of service associated with the packet.
过滤器可用于设置与分组相关联的服务类别。
- Count packets or bytes
- 计算数据包或字节数
- Rate Limit
- 利率限制
In some cases, the set of packets matching a particular filter may be limited to a specified bandwidth. In this case, packets or bytes would be counted, and would be forwarded normally up to the specified limit. Excess packets may be discarded or may be marked (for example, by setting a "discard eligible" bit in the IPv4 ToS field, or changing the EXP value to identify traffic as being out of contract).
在某些情况下，与特定滤波器匹配的分组集可能被限制在指定的带宽内。在这种情况下，将对数据包或字节进行计数，并将正常转发到指定的限制。多余的数据包可能会被丢弃或被标记（例如，通过在IPv4 ToS字段中设置“discard-qualified”位，或更改EXP值以将流量标识为不符合约定）。
- Forward and Copy
- 转发和复制
It is useful in some cases to forward some set of packets normally, but also to send a copy to a specified other address or interface. For example, this may be used to implement a lawful intercept capability or to feed selected packets to an Intrusion Detection System.
在某些情况下，通常转发某些数据包集是有用的，但也可以将副本发送到指定的其他地址或接口。例如，这可用于实现合法拦截能力或将所选分组馈送到入侵检测系统。
o Other Packet Filters Issues
o 其他数据包过滤器问题
Filtering performance may vary widely according to implementation and the types and number of rules. Without acceptable performance, filtering is not useful.
根据实现以及规则的类型和数量，过滤性能可能会有很大差异。如果没有可接受的性能，过滤就没有用处。
The precise definition of "acceptable" may vary from SP to SP, and may depend upon the intended use of the filters. For example, for some uses, a filter may be turned on all the time to set CoS, to prevent an attack, or to mitigate the effect of a possible future attack. In this case, it is likely that the SP will want the filter to have minimal or no impact on performance. In other cases, a filter may be turned on only in response to a major attack (such as a major DDoS attack). In this case, a greater performance impact may be acceptable to some service providers.
“可接受”的准确定义可能因SP而异，并可能取决于过滤器的预期用途。例如，对于某些用途，可始终打开过滤器以设置CoS、防止攻击或减轻未来可能攻击的影响。在这种情况下，SP可能希望过滤器对性能的影响最小或没有影响。在其他情况下，可能仅在响应重大攻击（如重大DDoS攻击）时才打开过滤器。在这种情况下，一些服务提供商可以接受更大的性能影响。
A key consideration with the use of packet filters is that they can provide few options for filtering packets carrying encrypted data. Because the data itself is not accessible, only packet header information or other unencrypted fields can be used for filtering.
使用包过滤器的一个关键考虑因素是，它们可以为过滤携带加密数据的包提供很少的选项。因为数据本身是不可访问的，所以只能使用数据包头信息或其他未加密字段进行过滤。
Firewalls provide a mechanism for controlling traffic passing between different trusted zones in the MPLS/GMPLS model or between a trusted zone and an untrusted zone. Firewalls typically provide much more functionality than filters, because they may be able to apply detailed analysis and logical functions to flows, and not just to individual packets. They may offer a variety of complex services, such as threshold-driven DoS attack protection, virus scanning, acting as a TCP connection proxy, etc.
防火墙提供了一种机制，用于控制MPLS/GMPLS模型中不同受信任区域之间或受信任区域与不受信任区域之间的流量传递。防火墙通常比过滤器提供更多的功能，因为它们可以将详细的分析和逻辑功能应用于流，而不仅仅是单个数据包。它们可能提供各种复杂的服务，如阈值驱动的DoS攻击保护、病毒扫描、充当TCP连接代理等。
As with other access control techniques, the value of firewalls depends on a clear understanding of the topologies of the MPLS/GMPLS core network, the user networks, and the threat model. Their effectiveness depends on a topology with a clearly defined inside (secure) and outside (not secure).
与其他访问控制技术一样，防火墙的价值取决于对MPLS/GMPLS核心网络、用户网络和威胁模型的拓扑结构的清晰理解。它们的有效性取决于具有明确定义的内部（安全）和外部（不安全）的拓扑。
Firewalls may be applied to help protect MPLS/GMPLS core network functions from attacks originating from the Internet or from
防火墙可用于帮助保护MPLS/GMPLS核心网络功能免受来自互联网或网络的攻击
MPLS/GMPLS user sites, but typically other defensive techniques will be used for this purpose.
MPLS/GMPLS用户站点，但通常会为此目的使用其他防御技术。
Where firewalls are employed as a service to protect user VPN sites from the Internet, different VPN users, and even different sites of a single VPN user, may have varying firewall requirements. The overall PPVPN logical and physical topology, along with the capabilities of the devices implementing the firewall services, has a significant effect on the feasibility and manageability of such varied firewall service offerings.
当防火墙用作保护用户VPN站点不受Internet影响的服务时，不同的VPN用户，甚至单个VPN用户的不同站点，可能具有不同的防火墙要求。总体PPVPN逻辑和物理拓扑以及实现防火墙服务的设备的能力，对此类不同防火墙服务产品的可行性和可管理性具有重大影响。
Another consideration with the use of firewalls is that they can provide few options for handling packets carrying encrypted data. Because the data itself is not accessible, only packet header information, other unencrypted fields, or analysis of the flow of encrypted packets can be used for making decisions on accepting or rejecting encrypted traffic.
使用防火墙的另一个考虑因素是，它们可以提供很少的选项来处理携带加密数据的数据包。因为数据本身是不可访问的，所以只有包头信息、其他未加密字段或加密包流的分析可用于做出接受或拒绝加密流量的决策。
Two approaches of using firewalls are to move the firewall outside of the encrypted part of the path or to register and pre-approve the encrypted session with the firewall.
使用防火墙的两种方法是将防火墙移出路径的加密部分，或者注册并预先批准与防火墙的加密会话。
Handling DoS attacks has become increasingly important. Useful guidelines include the following:
处理拒绝服务攻击变得越来越重要。有用的指导原则包括：
1. Perform ingress filtering everywhere.
1. 到处执行入口过滤。
2. Be able to filter DoS attack packets at line speed.
2. 能够以线路速度过滤DoS攻击数据包。
3. Do not allow oneself to amplify attacks.
3. 不要让自己放大攻击。
4. Continue processing legitimate traffic. Over provide for heavy loads. Use diverse locations, technologies, etc.
4. 继续处理合法流量。超载。使用不同的地点、技术等。
Most of the security issues related to management interfaces can be addressed through the use of authentication techniques as described in the section on authentication (Section 5.1). However, additional security may be provided by controlling access to management interfaces in other ways.
与管理接口相关的大多数安全问题都可以通过使用认证技术来解决，如认证部分（第5.1节）所述。然而，可以通过以其他方式控制对管理接口的访问来提供额外的安全性。
The Optical Internetworking Forum has done relevant work on protecting such interfaces with TLS, SSH, Kerberos, IPsec, WSS, etc. See "Security for Management Interfaces to Network Elements" [OIF-SMI-01.0] and "Addendum to the Security for Management Interfaces to Network Elements" [OIF-SMI-02.1]. See also the work in the ISMS WG (http://datatracker.ietf.org/wg/isms/charter/).
光纤网络互连论坛已经完成了使用TLS、SSH、Kerberos、IPsec、WSS等保护此类接口的相关工作。请参阅“网元管理接口安全”[OIF-SMI-01.0]和“网元管理接口安全附录”[OIF-SMI-02.1]。另请参见ISMS工作组中的工作(http://datatracker.ietf.org/wg/isms/charter/).
Management interfaces, especially console ports on MPLS/GMPLS devices, may be configured so they are only accessible out-of-band, through a system that is physically or logically separated from the rest of the MPLS/GMPLS infrastructure.
可以配置管理接口，特别是MPLS/GMPLS设备上的控制台端口，以便通过物理或逻辑上与MPLS/GMPLS基础设施的其余部分分离的系统，只能在带外访问这些接口。
Where management interfaces are accessible in-band within the MPLS/GMPLS domain, filtering or firewalling techniques can be used to restrict unauthorized in-band traffic from having access to management interfaces. Depending on device capabilities, these filtering or firewalling techniques can be configured either on other devices through which the traffic might pass, or on the individual MPLS/GMPLS devices themselves.
如果可以在MPLS/GMPLS域内的带内访问管理接口，则可以使用过滤或防火墙技术来限制未经授权的带内流量访问管理接口。根据设备功能的不同，这些过滤或防火墙技术可以配置在流量可能通过的其他设备上，也可以配置在单个MPLS/GMPLS设备本身上。
One way to protect the infrastructure used for support of MPLS/GMPLS is to separate the resources for support of MPLS/GMPLS services from the resources used for other purposes (such as support of Internet services). In some cases, this may involve using physically separate equipment for VPN services, or even a physically separate network.
保护用于支持MPLS/GMPLS的基础设施的一种方法是将用于支持MPLS/GMPLS服务的资源与用于其他目的（如支持互联网服务）的资源分开。在某些情况下，这可能涉及为VPN服务使用物理上独立的设备，甚至是物理上独立的网络。
For example, PE-based IPVPNs may be run on a separate backbone not connected to the Internet, or may use separate edge routers from those supporting Internet service. Private IPv4 addresses (local to the provider and non-routable over the Internet) are sometimes used to provide additional separation. For a discussion of comparable techniques for IPv6, see "Local Network Protection for IPv6," RFC 4864 [RFC4864].
For example, PE-based IPVPNs may be run on a separate backbone not connected to the Internet, or may use separate edge routers from those supporting Internet service. Private IPv4 addresses (local to the provider and non-routable over the Internet) are sometimes used to provide additional separation. For a discussion of comparable techniques for IPv6, see "Local Network Protection for IPv6," RFC 4864 [RFC4864].translate error, please retry
In a GMPLS network, it is possible to operate the control plane using physically separate resources from those used for the data plane. This means that the data-plane resources can be physically protected and isolated from other equipment to protect users' data while the control and management traffic uses network resources that can be accessed by operators to configure the network. Conversely, the separation of control and data traffic may lead the operator to consider that the network is secure because the data-plane resources are physically secure. However, this is not the case if the control plane can be attacked through a shared or open network, and control-plane protection techniques must still be applied.
在GMPLS网络中，可以使用与用于数据平面的资源物理上分离的资源来操作控制平面。这意味着数据平面资源可以受到物理保护，并与其他设备隔离，以保护用户的数据，而控制和管理流量则使用运营商可以访问的网络资源来配置网络。相反，控制和数据业务的分离可能导致操作员认为网络是安全的，因为数据平面资源是物理安全的。但是，如果控制平面可以通过共享或开放网络受到攻击，则情况并非如此，并且控制平面保护技术仍必须应用。
In general, it is not feasible to use a completely separate set of resources for support of each service. In fact, one of the main reasons for MPLS/GMPLS enabled services is to allow sharing of resources between multiple services and multiple users. Thus, even if certain services use a separate network from Internet services,
一般来说，使用一组完全独立的资源来支持每项服务是不可行的。事实上，支持MPLS/GMPLS的服务的主要原因之一是允许在多个服务和多个用户之间共享资源。因此，即使某些服务使用独立于互联网服务的网络，
nonetheless there will still be multiple MPLS/GMPLS users sharing the same network resources. In some cases, MPLS/GMPLS services will share network resources with Internet services or other services.
尽管如此，仍将有多个MPLS/GMPLS用户共享相同的网络资源。在某些情况下，MPLS/GMPLS服务将与Internet服务或其他服务共享网络资源。
It is therefore important for MPLS/GMPLS services to provide protection between resources used by different parties. Thus, a well-behaved MPLS/GMPLS user should be protected from possible misbehavior by other users. This requires several security measurements to be implemented. Resource limits can be placed on a per service and per user basis. Possibilities include, for example, using a virtual router or logical router to define hardware or software resource limits per service or per individual user; using rate limiting per Virtual Routing and Forwarding (VRF) or per Internet connection to provide bandwidth protection; or using resource reservation for control-plane traffic. In addition to bandwidth protection, separate resource allocation can be used to limit security attacks only to directly impacted service(s) or customer(s). Strict, separate, and clearly defined engineering rules and provisioning procedures can reduce the risks of network-wide impact of a control-plane attack, DoS attack, or misconfiguration.
因此，MPLS/GMPLS服务在不同方使用的资源之间提供保护非常重要。因此，应保护行为良好的MPLS/GMPLS用户免受其他用户可能的不当行为。这需要实施若干安全措施。可以根据每个服务和每个用户设置资源限制。可能包括，例如，使用虚拟路由器或逻辑路由器来定义每个服务或每个单独用户的硬件或软件资源限制；使用每个虚拟路由和转发（VRF）或每个Internet连接的速率限制来提供带宽保护；或者使用资源预留来控制飞机流量。除了带宽保护外，还可以使用单独的资源分配将安全攻击限制在直接受影响的服务或客户。严格、独立且定义明确的工程规则和供应程序可以降低控制平面攻击、DoS攻击或错误配置对整个网络造成影响的风险。
In general, the use of aggregated infrastructure allows the service provider to benefit from stochastic multiplexing of multiple bursty flows, and also may in some cases thwart traffic pattern analysis by combining the data from multiple users. However, service providers must minimize security risks introduced from any individual service or individual users.
通常，聚合基础设施的使用允许服务提供商从多个突发流的随机多路复用中获益，并且在某些情况下，还可能通过组合来自多个用户的数据来阻碍流量模式分析。但是，服务提供商必须最大限度地减少来自任何单个服务或单个用户的安全风险。
Deployment of provider-provisioned VPN services in general requires a relatively large amount of configuration by the SP. For example, the SP needs to configure which VPN each site belongs to, as well as QoS and SLA guarantees. This large amount of required configuration leads to the possibility of misconfiguration.
部署提供商提供的VPN服务通常需要SP进行相对大量的配置。例如，SP需要配置每个站点所属的VPN，以及QoS和SLA保证。所需的大量配置可能导致配置错误。
It is important for the SP to have operational processes in place to reduce the potential impact of misconfiguration. CE-to-CE authentication may also be used to detect misconfiguration when it occurs. CE-to-CE encryption may also limit the damage when misconfiguration occurs.
SP必须制定操作流程，以减少错误配置的潜在影响。CE-to-CE认证也可用于在错误配置发生时检测错误配置。CE-to-CE加密还可以在发生错误配置时限制损坏。
This refers to solutions that can be readily tested to make sure they are configured correctly. For example, for a point-to-point connection, checking that the intended connectivity is working pretty
这是指可以随时测试以确保正确配置的解决方案。例如，对于点对点连接，检查预期的连接是否正常工作
much ensures that there is no unintended connectivity to some other site.
这可以确保没有意外连接到其他站点。
In order to protect against deliberate or accidental misconnection, mechanisms can be put in place to verify both end-to-end connectivity and hop-by-hop resources. These mechanisms can trace the routes of LSPs in both the control plane and the data plane.
为了防止故意或意外的错误连接，可以建立机制来验证端到端连接和逐跳资源。这些机制可以在控制平面和数据平面上跟踪LSP的路由。
It should be noted that if there is an attack on the control plane, data-plane connectivity test mechanisms that rely on the control plane can also be attacked. This may hide faults through false positives or disrupt functioning services through false negatives.
需要注意的是，如果控制平面受到攻击，依赖于控制平面的数据平面连接测试机制也会受到攻击。这可能会通过误报隐藏故障，或通过误报中断正常运行的服务。
MPLS/GMPLS network and service may be subject to attacks from a variety of security threats. Many threats are described in Section 4 of this document. Many of the defensive techniques described in this document and elsewhere provide significant levels of protection from a variety of threats. However, in addition to employing defensive techniques silently to protect against attacks, MPLS/GMPLS services can also add value for both providers and customers by implementing security monitoring systems to detect and report on any security attacks, regardless of whether the attacks are effective.
MPLS/GMPLS网络和服务可能受到各种安全威胁的攻击。本文件第4节描述了许多威胁。本文档和其他地方描述的许多防御技术提供了针对各种威胁的重要防护级别。然而，除了无声地使用防御技术来防范攻击外，MPLS/GMPLS服务还可以通过实施安全监控系统来检测和报告任何安全攻击，从而为提供商和客户增加价值，而不管攻击是否有效。
Attackers often begin by probing and analyzing defenses, so systems that can detect and properly report these early stages of attacks can provide significant benefits.
攻击者通常从探测和分析防御开始，因此能够检测并正确报告这些早期攻击的系统可以提供显著的好处。
Information concerning attack incidents, especially if available quickly, can be useful in defending against further attacks. It can be used to help identify attackers or their specific targets at an early stage. This knowledge about attackers and targets can be used to strengthen defenses against specific attacks or attackers, or to improve the defenses for specific targets on an as-needed basis. Information collected on attacks may also be useful in identifying and developing defenses against novel attack types.
关于攻击事件的信息，特别是如果可以很快获得的话，可以有助于防范进一步的攻击。它可用于帮助在早期阶段识别攻击者或其特定目标。有关攻击者和目标的知识可用于加强针对特定攻击或攻击者的防御，或根据需要改进特定目标的防御。收集的攻击信息也有助于识别和开发针对新攻击类型的防御措施。
Monitoring systems used to detect security attacks in MPLS/GMPLS typically operate by collecting information from the Provider Edge (PE), Customer Edge (CE), and/or Provider backbone (P) devices. Security monitoring systems should have the ability to actively retrieve information from devices (e.g., SNMP get) or to passively receive reports from devices (e.g., SNMP notifications). The systems may actively retrieve information from devices (e.g., SNMP get) or passively receive reports from devices (e.g., SNMP notifications).
用于检测MPLS/GMPLS中安全攻击的监控系统通常通过从提供商边缘（PE）、客户边缘（CE）和/或提供商主干（P）设备收集信息来运行。安全监控系统应能够主动从设备检索信息（如SNMP get）或被动从设备接收报告（如SNMP通知）。系统可以主动地从设备检索信息（例如，SNMP get）或被动地从设备接收报告（例如，SNMP通知）。
The specific information exchanged depends on the capabilities of the devices and on the type of VPN technology. Particular care should be given to securing the communications channel between the monitoring systems and the MPLS/GMPLS devices.
交换的特定信息取决于设备的功能和VPN技术的类型。应特别注意保护监控系统和MPLS/GMPLS设备之间的通信通道。
The CE, PE, and P devices should employ efficient methods to acquire and communicate the information needed by the security monitoring systems. It is important that the communication method between MPLS/GMPLS devices and security monitoring systems be designed so that it will not disrupt network operations. As an example, multiple attack events may be reported through a single message, rather than allowing each attack event to trigger a separate message, which might result in a flood of messages, essentially becoming a DoS attack against the monitoring system or the network.
CE、PE和P设备应采用有效的方法获取和传输安全监控系统所需的信息。设计MPLS/GMPLS设备和安全监控系统之间的通信方法，使其不会中断网络操作，这一点很重要。例如，可以通过单个消息报告多个攻击事件，而不是允许每个攻击事件触发单独的消息，这可能导致大量消息，基本上成为针对监控系统或网络的DoS攻击。
The mechanisms for reporting security attacks should be flexible enough to meet the needs of MPLS/GMPLS service providers, MPLS/GMPLS customers, and regulatory agencies, if applicable. The specific reports should depend on the capabilities of the devices, the security monitoring system, the type of VPN, and the service level agreements between the provider and customer.
报告安全攻击的机制应足够灵活，以满足MPLS/GMPLS服务提供商、MPLS/GMPLS客户和监管机构（如适用）的需要。具体报告应取决于设备的功能、安全监控系统、VPN的类型以及提供商和客户之间的服务级别协议。
While SNMP/syslog type monitoring and detection mechanisms can detect some attacks (usually resulting from flapping protocol adjacencies, CPU overload scenarios, etc.), other techniques, such as netflow-based traffic fingerprinting, are needed for more detailed detection and reporting.
虽然SNMP/syslog类型的监视和检测机制可以检测到一些攻击（通常由协议邻接、CPU过载场景等引起），但需要其他技术，如基于netflow的流量指纹，以进行更详细的检测和报告。
With netflow-based traffic fingerprinting, each packet that is forwarded within a device is examined for a set of IP packet attributes. These attributes are the IP packet identity or fingerprint of the packet and determine if the packet is unique or similar to other packets.
使用基于netflow的流量指纹，将检查设备内转发的每个数据包是否具有一组IP数据包属性。这些属性是数据包的IP数据包标识或指纹，并确定数据包是否唯一或与其他数据包相似。
The flow information is extremely useful for understanding network behavior, and detecting and reporting security attacks:
流信息对于了解网络行为、检测和报告安全攻击非常有用：
- Source address allows the understanding of who is originating the traffic.
- 源地址允许了解谁是流量的始发者。
- Destination address tells who is receiving the traffic.
- 目的地地址告诉谁正在接收流量。
- Ports characterize the application utilizing the traffic.
- 端口是利用流量的应用程序的特征。
- Class of service examines the priority of the traffic.
- 服务类别检查流量的优先级。
- The device interface tells how traffic is being utilized by the network device.
- 设备接口告知网络设备如何利用流量。
- Tallied packets and bytes show the amount of traffic.
- 计数的数据包和字节显示通信量。
- Flow timestamps allow the understanding of the life of a flow; timestamps are useful for calculating packets and bytes per second.
- 流时间戳允许理解流的生命周期；时间戳对于计算每秒的数据包和字节非常有用。
- Next-hop IP addresses including BGP routing Autonomous Systems (ASes).
- 下一跳IP地址，包括BGP路由自治系统（ASes）。
- Subnet mask for the source and destination addresses are for calculating prefixes.
- 源地址和目标地址的子网掩码用于计算前缀。
- TCP flags are useful for examining TCP handshakes.
- TCP标志对于检查TCP握手非常有用。
This section covers security requirements the provider may have for securing its MPLS/GMPLS network infrastructure including LDP and RSVP-TE-specific requirements.
本节涵盖了供应商为保护其MPLS/GMPLS网络基础设施而可能具有的安全要求，包括LDP和RSVP TE特定要求。
The MPLS/GMPLS service provider's requirements defined here are for the MPLS/GMPLS core in the reference model. The core network can be implemented with different types of network technologies, and each core network may use different technologies to provide the various services to users with different levels of offered security. Therefore, an MPLS/GMPLS service provider may fulfill any number of the security requirements listed in this section. This document does not state that an MPLS/GMPLS network must fulfill all of these requirements to be secure.
此处定义的MPLS/GMPLS服务提供商的要求适用于参考模型中的MPLS/GMPLS核心。核心网络可以使用不同类型的网络技术来实现，每个核心网络可以使用不同的技术向具有不同安全级别的用户提供各种服务。因此，MPLS/GMPLS服务提供商可以满足本节中列出的任何数量的安全要求。本文件并未说明MPLS/GMPLS网络必须满足所有这些安全要求。
These requirements are focused on: 1) how to protect the MPLS/GMPLS core from various attacks originating outside the core including those from network users, both accidentally and maliciously, and 2) how to protect the end users.
这些要求的重点是：1）如何保护MPLS/GMPLS核心免受来自核心外部的各种攻击，包括来自网络用户的攻击，包括意外攻击和恶意攻击，以及2）如何保护最终用户。
- Filtering spoofed infrastructure IP addresses at edges
- 在边缘过滤伪造的基础结构IP地址
Many attacks on protocols running in a core involve spoofing a source IP address of a node in the core (e.g., TCP-RST attacks). It makes sense to apply anti-spoofing filtering at edges, e.g., using strict unicast reverse path forwarding (uRPF) [RFC3704] and/or by preventing
对核心中运行的协议的许多攻击都涉及欺骗核心中节点的源IP地址（例如TCP-RST攻击）。在边缘应用反欺骗过滤是有意义的，例如，使用严格的单播反向路径转发（uRPF）[RFC3704]和/或通过防止
the use of infrastructure addresses as source. If this is done comprehensively, the need to cryptographically secure these protocols is smaller. See [BACKBONE-ATTKS] for more elaborate description.
使用基础结构地址作为源。如果这是全面完成的，那么对这些协议进行加密保护的需求就会减少。请参阅[BACKBONE-ATTKS]以了解更详细的说明。
- Protocol authentication within the core
- 核心内的协议认证
The network infrastructure must support mechanisms for authentication of the control-plane messages. If an MPLS/GMPLS core is used, LDP sessions may be authenticated with TCP MD5. In addition, IGP and BGP authentication should be considered. For a core providing various IP, VPN, or transport services, PE-to-PE authentication may also be performed via IPsec. See the above discussion of protocol security services: authentication, integrity (with replay detection), and confidentiality. Protocols need to provide a complete set of security services from which the SP can choose. Also, the important but often more difficult part is key management. Considerations, guidelines, and strategies regarding key management are discussed in [RFC3562], [RFC4107], [RFC4808].
网络基础设施必须支持对控制平面消息进行身份验证的机制。如果使用MPLS/GMPLS核心，LDP会话可以通过TCP MD5进行身份验证。此外，还应考虑IGP和BGP认证。对于提供各种IP、VPN或传输服务的核心，也可以通过IPsec执行PE到PE认证。请参阅上面关于协议安全服务的讨论：身份验证、完整性（带有重播检测）和机密性。协议需要提供一整套安全服务，SP可以从中进行选择。此外，重要但往往更困难的部分是关键管理。[RFC3562]、[RFC4107]、[RFC4808]中讨论了有关密钥管理的注意事项、指南和策略。
With today's processors, applying cryptographic authentication to the control plane may not increase the cost of deployment for providers significantly, and will help to improve the security of the core. If the core is dedicated to MPLS/GMPLS enabled services without any interconnects to third parties, then this may reduce the requirement for authentication of the core control plane.
对于今天的处理器，将加密身份验证应用于控制平面可能不会显著增加提供商的部署成本，并将有助于提高核心的安全性。如果核心专用于支持MPLS/GMPLS的服务，而没有任何与第三方的互连，那么这可能会降低对核心控制平面的认证要求。
- Infrastructure Hiding
- 基础设施隐藏
Here we discuss means to hide the provider's infrastructure nodes. An MPLS/GMPLS provider may make its infrastructure routers (P and PE) unreachable from outside users and unauthorized internal users. For example, separate address space may be used for the infrastructure loopbacks.
这里我们讨论隐藏提供者的基础结构节点的方法。MPLS/GMPLS提供商可能使外部用户和未经授权的内部用户无法访问其基础设施路由器（P和PE）。例如，单独的地址空间可用于基础设施环回。
Normal TTL propagation may be altered to make the backbone look like one hop from the outside, but caution needs to be taken for loop prevention. This prevents the backbone addresses from being exposed through trace route; however, this must also be assessed against operational requirements for end-to-end fault tracing.
正常的TTL传播可能会被改变，使主干看起来像是从外部跳转，但需要注意环路预防。这可以防止主干地址通过跟踪路由暴露；然而，这也必须根据端到端故障跟踪的操作要求进行评估。
An Internet backbone core may be re-engineered to make Internet routing an edge function, for example, by using MPLS label switching for all traffic within the core and possibly making the Internet a VPN within the PPVPN core itself. This helps to detach Internet access from PPVPN services.
因特网骨干核心可被重新设计以使因特网路由成为边缘功能，例如，通过对核心内的所有通信使用MPLS标签交换，并可能使因特网成为PPVPN核心本身内的VPN。这有助于将Internet访问与PPVPN服务分离。
Separating control-plane, data-plane, and management-plane functionality in hardware and software may be implemented on the PE
可以在PE上实现硬件和软件中分离控制平面、数据平面和管理平面功能
devices to improve security. This may help to limit the problems when attacked in one particular area, and may allow each plane to implement additional security measures separately.
提高安全性的设备。这可能有助于限制在某一特定区域受到攻击时的问题，并允许每架飞机单独实施额外的安全措施。
PEs are often more vulnerable to attack than P routers, because PEs cannot be made unreachable from outside users by their very nature. Access to core trunk resources can be controlled on a per-user basis by using of inbound rate limiting or traffic shaping; this can be further enhanced on a per-class-of-service basis (see Section 8.2.3)
PEs通常比P路由器更容易受到攻击，因为PEs的本质不能让外部用户无法访问。通过使用入站速率限制或流量整形，可以在每个用户的基础上控制对核心中继资源的访问；这可以在每类服务的基础上进一步增强（见第8.2.3节）
In the PE, using separate routing processes for different services, for example, Internet and PPVPN service, may help to improve the PPVPN security and better protect VPN customers. Furthermore, if resources, such as CPU and memory, can be further separated based on applications, or even individual VPNs, it may help to provide improved security and reliability to individual VPN customers.
在PE中，对不同的服务（例如Internet和PPVPN服务）使用单独的路由过程，可能有助于提高PPVPN安全性并更好地保护VPN客户。此外，如果资源（如CPU和内存）可以根据应用程序甚至单个VPN进一步分离，则可能有助于为单个VPN客户提供改进的安全性和可靠性。
- General RSVP Security Tools
- 通用RSVP安全工具
Isolation of the trusted domain is an important security mechanism for RSVP, to ensure that an untrusted element cannot access a router of the trusted domain. However, ASBR-ASBR communication for inter-AS LSPs needs to be secured specifically. Isolation mechanisms might also be bypassed by an IPv4 Router Alert or IPv6 using Next Header 0 packets. A solution could consist of disabling the processing of IP options. This drops or ignores all IP packets with IPv4 options, including the router alert option used by RSVP; however, this may have an impact on other protocols using IPv4 options. An alternative is to configure access-lists on all incoming interfaces dropping IPv4 protocol or IPv6 next header 46 (RSVP).
隔离受信任域是RSVP的重要安全机制，以确保不受信任的元素无法访问受信任域的路由器。但是，需要特别保护AS间LSP的ASBR-ASBR通信。IPv4路由器警报或使用下一个报头0数据包的IPv6也可能绕过隔离机制。解决方案可以包括禁用IP选项的处理。这会删除或忽略所有具有IPv4选项的IP数据包，包括RSVP使用的路由器警报选项；但是，这可能会对使用IPv4选项的其他协议产生影响。另一种方法是在所有传入接口上配置访问列表，删除IPv4协议或IPv6下一报头46（RSVP）。
RSVP security can be strengthened by deactivating RSVP on interfaces with neighbors who are not authorized to use RSVP, to protect against adjacent CE-PE attacks. However, this does not really protect against DoS attacks or attacks on non-adjacent routers. It has been demonstrated that substantial CPU resources are consumed simply by processing received RSVP packets, even if the RSVP process is deactivated for the specific interface on which the RSVP packets are received.
RSVP安全性可以通过禁用与未被授权使用RSVP的邻居接口上的RSVP来加强，以防止相邻CE-PE攻击。然而，这并不能真正防止DoS攻击或对非相邻路由器的攻击。已经证明，只要处理接收到的RSVP数据包，就可以消耗大量的CPU资源，即使对于接收到RSVP数据包的特定接口，RSVP进程被停用。
RSVP neighbor filtering at the protocol level, to restrict the set of neighbors that can send RSVP messages to a given router, protects against non-adjacent attacks. However, this does not protect against DoS attacks and does not effectively protect against spoofing of the source address of RSVP packets, if the filter relies on the neighbor's address within the RSVP message.
在协议级别进行RSVP邻居过滤，以限制可以向给定路由器发送RSVP消息的邻居集，从而防止非相邻攻击。但是，如果过滤器依赖于RSVP消息中的邻居地址，则这不能防止DoS攻击，也不能有效防止RSVP数据包的源地址被欺骗。
RSVP neighbor filtering at the data-plane level, with an access list to accept IP packets with port 46 only for specific neighbors, requires Router Alert mode to be deactivated and does not protect against spoofing.
数据平面级别的RSVP邻居过滤，具有访问列表以仅针对特定邻居接受端口为46的IP数据包，需要停用路由器警报模式，并且不防止欺骗。
Another valuable tool is RSVP message pacing, to limit the number of RSVP messages sent to a given neighbor during a given period. This allows blocking DoS attack propagation.
另一个有价值的工具是RSVP消息调整，用于限制在给定时间段内发送给给定邻居的RSVP消息的数量。这允许阻止DoS攻击传播。
- Another approach is to limit the impact of an attack on control-plane resources.
- 另一种方法是限制攻击对控制飞机资源的影响。
To ensure continued effective operation of the MPLS router even in the case of an attack that bypasses packet filtering mechanisms such as Access Control Lists in the data plane, it is important that routers have some mechanisms to limit the impact of the attack. There should be a mechanism to rate limit the amount of control-plane traffic addressed to the router, per interface. This should be configurable on a per-protocol basis, (and, ideally, on a per-sender basis) to avoid letting an attacked protocol or a given sender block all communications. This requires the ability to filter and limit the rate of incoming messages of particular protocols, such as RSVP (filtering at the IP protocol level), and particular senders. In addition, there should be a mechanism to limit CPU and memory capacity allocated to RSVP, so as to protect other control-plane elements. To limit memory allocation, it will probably be necessary to limit the number of LSPs that can be set up.
为了确保MPLS路由器即使在绕过数据平面中的访问控制列表等包过滤机制的攻击情况下也能继续有效运行，路由器必须具有一些机制来限制攻击的影响。应该有一种机制来对每个接口发送到路由器的控制平面流量进行速率限制。这应该在每个协议的基础上进行配置（理想情况下，在每个发送方的基础上），以避免让受攻击的协议或给定的发送方阻止所有通信。这需要能够过滤和限制特定协议（如RSVP（在IP协议级别过滤）和特定发送方的传入消息的速率。此外，应该有一种机制来限制分配给RSVP的CPU和内存容量，以保护其他控制平面元件。为了限制内存分配，可能需要限制可以设置的LSP的数量。
- Authentication for RSVP messages
- RSVP消息的身份验证
RSVP message authentication is described in RFC 2747 [RFC2747] and RFC 3097 [RFC3097]. It is one of the most powerful tools for protection against RSVP-based attacks. It applies cryptographic authentication to RSVP messages based on a secure message hash using a key shared by RSVP neighbors. This protects against LSP creation attacks, at the expense of consuming significant CPU resources for digest computation. In addition, if the neighboring RSVP speaker is compromised, it could be used to launch attacks using authenticated RSVP messages. These methods, and certain other aspects of RSVP security, are explained in detail in RFC 4230 [RFC4230]. Key management must be implemented. Logging and auditing as well as multiple layers of cryptographic protection can help here. IPsec can also be used in some cases (see [RFC4230]).
RFC 2747[RFC2747]和RFC 3097[RFC3097]中描述了RSVP消息身份验证。它是防止基于RSVP的攻击的最强大的工具之一。它基于使用RSVP邻居共享的密钥的安全消息散列，对RSVP消息应用加密身份验证。这可以防止LSP创建攻击，代价是消耗大量CPU资源进行摘要计算。此外，如果相邻的RSVP扬声器受损，则可能会使用经过身份验证的RSVP消息发起攻击。RFC 4230[RFC4230]详细解释了这些方法以及RSVP安全性的某些其他方面。必须实施密钥管理。日志记录和审核以及多层加密保护在这方面可以有所帮助。在某些情况下也可以使用IPsec（请参见[RFC4230]）。
One challenge using RSVP message authentication arises in many cases where non-RSVP nodes are present in the network. In such cases, the RSVP neighbor may not be known up front, thus neighbor-based keying approaches fail, unless the same key is used everywhere, which is not
在网络中存在非RSVP节点的许多情况下，使用RSVP消息身份验证会出现一个挑战。在这种情况下，RSVP邻居可能事先不知道，因此基于邻居的键控方法失败，除非到处使用相同的密钥，而这是不可能的
recommended for security reasons. Group keying may help in such cases. The security properties of various keying approaches are discussed in detail in [RSVP-key].
出于安全原因，建议使用。在这种情况下，组键控可能会有所帮助。[RSVP key]中详细讨论了各种键控方法的安全特性。
The approaches to protect MPLS routers against LDP-based attacks are similar to those for RSVP, including isolation, protocol deactivation on specific interfaces, filtering of LDP neighbors at the protocol level, filtering of LDP neighbors at the data-plane level (with an access list that filters the TCP and UDP LDP ports), authentication with a message digest, rate limiting of LDP messages per protocol per sender, and limiting all resources allocated to LDP-related tasks. LDP protection could be considered easier in a certain sense. UDP port matching may be sufficient for LDP protection. Router alter options and beyond might be involved in RSVP protection.
保护MPLS路由器免受基于LDP的攻击的方法与RSVP类似，包括隔离、特定接口上的协议停用、在协议级别过滤LDP邻居、在数据平面级别过滤LDP邻居（使用过滤TCP和UDP LDP端口的访问列表），使用消息摘要进行身份验证，对每个发送方的每个协议的LDP消息进行速率限制，并限制分配给LDP相关任务的所有资源。从某种意义上说，自民党的保护可能更容易。UDP端口匹配可能足以实现LDP保护。路由器alter选项和其他选项可能涉及RSVP保护。
IPsec can provide authentication, integrity, confidentiality, and replay detection for provider or user data. It also has an associated key management protocol.
IPsec可以为提供者或用户数据提供身份验证、完整性、机密性和重播检测。它还有一个相关的密钥管理协议。
In today's MPLS/GMPLS, ATM, or Frame Relay networks, encryption is not provided as a basic feature. Mechanisms described in Section 5 can be used to secure the MPLS data-plane traffic carried over an MPLS core. Both the Frame Relay Forum and the ATM Forum standardized cryptographic security services in the late 1990s, but these standards are not widely implemented.
在今天的MPLS/GMPLS、ATM或帧中继网络中，加密并不是一项基本功能。第5节中描述的机制可用于保护通过MPLS核心承载的MPLS数据平面流量。帧中继论坛和ATM论坛都在20世纪90年代末实现了密码安全服务的标准化，但这些标准并未得到广泛实施。
Peer or neighbor protocol authentication may be used to enhance security. For example, BGP MD5 authentication may be used to enhance security on PE-CE links using eBGP. In the case of inter-provider connections, cryptographic protection mechanisms, such as IPsec, may be used between ASes.
对等或邻居协议认证可用于增强安全性。例如，BGP MD5认证可用于使用eBGP增强PE-CE链路上的安全性。在提供者间连接的情况下，可以在ASE之间使用加密保护机制，例如IPsec。
If multiple services are provided on the same PE platform, different WAN address spaces may be used for different services (e.g., VPN and non-VPN) to enhance isolation.
如果在同一PE平台上提供多个服务，则不同的WAN地址空间可用于不同的服务（例如VPN和非VPN），以增强隔离。
Firewall and Filtering: access control mechanisms can be used to filter any packets destined for the service provider's infrastructure prefix or eliminate routes identified as illegitimate. Filtering should also be applied to prevent sourcing packets with infrastructure IP addresses from outside.
防火墙和过滤：访问控制机制可用于过滤发送至服务提供商基础设施前缀的任何数据包，或消除被识别为非法的路由。还应应用过滤，以防止从外部获取具有基础设施IP地址的数据包。
Rate limiting may be applied to the user interface/logical interfaces as a defense against DDoS bandwidth attack. This is helpful when the PE device is supporting both multiple services, especially VPN and Internet Services, on the same physical interfaces through different logical interfaces.
速率限制可应用于用户界面/逻辑界面，以防御DDoS带宽攻击。当PE设备通过不同的逻辑接口在相同的物理接口上同时支持多个服务（特别是VPN和Internet服务）时，这将非常有用。
Authentication can be used to validate site access to the network via fixed or logical connections, e.g., L2TP or IPsec, respectively. If the user wishes to hold the authentication credentials for access, then provider solutions require the flexibility for either direct authentication by the PE itself or interaction with a customer authentication server. Mechanisms are required in the latter case to ensure that the interaction between the PE and the customer authentication server is appropriately secured.
身份验证可用于分别通过固定或逻辑连接（例如L2TP或IPsec）验证站点对网络的访问。如果用户希望持有用于访问的身份验证凭据，则提供商解决方案需要PE本身直接身份验证或与客户身份验证服务器交互的灵活性。在后一种情况下，需要机制来确保PE和客户身份验证服务器之间的交互得到适当的保护。
Choice of routing protocols, e.g., RIP, OSPF, or BGP, may be used to provide control access between a CE and a PE. Per-neighbor and per-VPN routing policies may be established to enhance security and reduce the impact of a malicious or non-malicious attack on the PE; the following mechanisms, in particular, should be considered:
路由协议的选择，例如RIP、OSPF或BGP，可用于提供CE和PE之间的控制访问。可以建立每邻居和每VPN路由策略，以增强安全性并减少恶意或非恶意攻击对PE的影响；应特别考虑以下机制：
- Limiting the number of prefixes that may be advertised on a per-access basis into the PE. Appropriate action may be taken should a limit be exceeded, e.g., the PE shutting down the peer session to the CE
- 限制可在每次访问的基础上向PE播发的前缀数量。如果超过限制，可以采取适当的措施，例如，PE关闭与CE的对等会话
- Applying route dampening at the PE on received routing updates
- 在收到路由更新时在PE处应用路由阻尼
- Definition of a per-VPN prefix limit after which additional prefixes will not be added to the VPN routing table.
- 每个VPN前缀限制的定义，在此限制之后，将不会向VPN路由表添加其他前缀。
In the case of inter-provider connection, access protection, link authentication, and routing policies as described above may be applied. Both inbound and outbound firewall or filtering mechanisms between ASes may be applied. Proper security procedures must be implemented in inter-provider interconnection to protect the providers' network infrastructure and their customers. This may be custom designed for each inter-provider peering connection, and must be agreed upon by both providers.
在提供商间连接的情况下，可以应用如上所述的访问保护、链路认证和路由策略。可以应用ASE之间的入站和出站防火墙或过滤机制。供应商之间的互连必须实施适当的安全程序，以保护供应商的网络基础设施及其客户。这可能是为每个提供商间对等连接定制的，并且必须得到两个提供商的同意。
MPLS/GMPLS providers offering QoS-enabled services require mechanisms to ensure that individual accesses are validated against their subscribed QoS profile and as such gain access to core resources that match their service profile. Mechanisms such as per-class-of-service rate limiting or traffic shaping on ingress to the MPLS/GMPLS core are two options for providing this level of control. Such mechanisms may require the per-class-of-service profile to be enforced either by marking, remarking, or discarding of traffic outside of the profile.
提供支持QoS的服务的MPLS/GMPLS提供商需要各种机制，以确保根据其订阅的QoS配置文件验证各个访问，从而获得对与其服务配置文件匹配的核心资源的访问。在进入MPLS/GMPLS核心时，诸如每类服务速率限制或流量整形等机制是提供这种控制级别的两种选择。此类机制可能要求通过标记、注释或丢弃配置文件之外的流量来强制执行每类服务配置文件。
End users needing specific statistics on the core, e.g., routing table, interface status, or QoS statistics, place requirements on mechanisms at the PE both to validate the incoming user and limit the views available to that particular user. Mechanisms should also be considered to ensure that such access cannot be used as means to construct a DoS attack (either maliciously or accidentally) on the PE itself. This could be accomplished either through separation of these resources within the PE itself or via the capability to rate limiting, which is performed on the basis of each physical interface or each logical connection.
最终用户需要核心上的特定统计信息，例如路由表、接口状态或QoS统计信息，对PE上的机制提出要求，以验证传入用户并限制该特定用户可用的视图。还应考虑各种机制，以确保此类访问不能用作在PE本身上构造DoS攻击（恶意或意外）的手段。这可以通过在PE本身内分离这些资源或通过速率限制的能力来实现，速率限制是基于每个物理接口或每个逻辑连接执行的。
MPLS/GMPLS providers must support end users' security requirements. Depending on the technologies used, these requirements may include:
MPLS/GMPLS提供商必须支持最终用户的安全要求。根据使用的技术，这些要求可能包括：
- User control plane separation through routing isolation when applicable, for example, in the case of MPLS VPNs.
- 适用时，例如在MPLS VPN的情况下，通过路由隔离实现用户控制平面分离。
- Protection against intrusion, DoS attacks, and spoofing
- 防止入侵、DoS攻击和欺骗
- Access Authentication
- 访问认证
- Techniques highlighted throughout this document that identify methodologies for the protection of resources and the MPLS/GMPLS infrastructure.
- 本文件中强调的技术确定了保护资源和MPLS/GMPLS基础设施的方法。
Hardware or software errors in equipment leading to breaches in security are not within the scope of this document.
导致安全漏洞的设备硬件或软件错误不在本文件范围内。
This section discusses security capabilities that are important at the MPLS/GMPLS inter-provider connections and at devices (including ASBR routers) supporting these connections. The security
本节讨论在MPLS/GMPLS供应商间连接和支持这些连接的设备（包括ASBR路由器）上非常重要的安全功能。保安
capabilities stated in this section should be considered as complementary to security considerations addressed in individual protocol specifications or security frameworks.
本节中所述的功能应视为对各个协议规范或安全框架中所述安全考虑的补充。
Security vulnerabilities and exposures may be propagated across multiple networks because of security vulnerabilities arising in one peer's network. Threats to security originate from accidental, administrative, and intentional sources. Intentional threats include events such as spoofing and denial-of-service (DoS) attacks.
由于一个对等网络中出现的安全漏洞，安全漏洞和暴露可能会在多个网络中传播。对安全的威胁源于意外、行政和故意的来源。故意威胁包括欺骗和拒绝服务（DoS）攻击等事件。
The level and nature of threats, as well as security and availability requirements, may vary over time and from network to network. This section, therefore, discusses capabilities that need to be available in equipment deployed for support of the MPLS InterCarrier Interconnect (MPLS-ICI). Whether any particular capability is used in any one specific instance of the ICI is up to the service providers managing the PE equipment offering or using the ICI services.
威胁的级别和性质，以及安全性和可用性要求，可能会随着时间的推移和网络的不同而有所不同。因此，本节讨论了为支持MPLS载波间互连（MPLS-ICI）而部署的设备中需要具备的功能。是否在ICI的任何一个特定实例中使用任何特定功能取决于管理提供的PE设备或使用ICI服务的服务提供商。
This section discusses capabilities for control-plane protection, including protection of routing, signaling, and OAM capabilities.
本节讨论控制平面保护功能，包括路由、信令和OAM功能的保护。
Authentication may be needed for signaling sessions (i.e., BGP, LDP, and RSVP-TE) and routing sessions (e.g., BGP), as well as OAM sessions across domain boundaries. Equipment must be able to support the exchange of all protocol messages over IPsec ESP, with NULL encryption and authentication, between the peering ASBRs. Support for message authentication for LDP, BGP, and RSVP-TE authentication must also be provided. Manual keying of IPsec should not be used. IKEv2 with pre-shared secrets or public key methods should be used. Replay detection should be used.
信令会话（即BGP、LDP和RSVP-TE）和路由会话（例如BGP）以及跨域边界的OAM会话可能需要身份验证。设备必须能够支持通过IPsec ESP在对等ASBR之间交换所有协议消息，并使用空加密和身份验证。还必须支持LDP、BGP和RSVP-TE认证的消息认证。不应使用IPsec的手动键控。应使用具有预共享秘密或公钥方法的IKEv2。应使用回放检测。
Mechanisms to authenticate and validate a dynamic setup request must be available. For instance, if dynamic signaling of a TE-LSP or PW is crossing a domain boundary, there must be a way to detect whether the LSP source is who it claims to be and that it is allowed to connect to the destination.
验证和验证动态设置请求的机制必须可用。例如，如果TE-LSP或PW的动态信令正在跨越域边界，则必须有一种方法来检测LSP源是否是它所声称的那个人，以及是否允许它连接到目的地。
Message authentication support for all TCP-based protocols within the scope of the MPLS-ICI (i.e., LDP signaling and BGP routing) and Message authentication with the RSVP-TE Integrity Object must be provided to interoperate with current practices. Equipment should be able to support the exchange of all signaling and routing (LDP, RSVP-TE, and BGP) protocol messages over a single IPsec association pair
必须为MPLS-ICI范围内的所有基于TCP的协议（即LDP信令和BGP路由）提供消息认证支持，并使用RSVP-TE完整性对象进行消息认证，以便与当前实践进行互操作。设备应能够通过单个IPsec关联对支持所有信令和路由（LDP、RSVP-TE和BGP）协议消息的交换
in tunnel or transport mode with authentication but with NULL encryption, between the peering ASBRs. IPsec, if supported, must be supported with HMAC-SHA-1 and alternatively with HMAC-SHA-2 and optionally SHA-1. It is expected that authentication algorithms will evolve over time and support can be updated as needed.
在对等ASBR之间，在具有身份验证但具有空加密的隧道或传输模式中。IPsec（如果支持）必须由HMAC-SHA-1支持，或者由HMAC-SHA-2和可选的SHA-1支持。预计认证算法将随着时间的推移而发展，并可根据需要更新支持。
OAM operations across the MPLS-ICI could also be the source of security threats on the provider infrastructure as well as the service offered over the MPLS-ICI. A large volume of OAM messages could overwhelm the processing capabilities of an ASBR if the ASBR is not properly protected. Maliciously generated OAM messages could also be used to bring down an otherwise healthy service (e.g., MPLS Pseudowire), and therefore affect service security. LSP ping does not support authentication today, and that support should be a subject for future consideration. Bidirectional Forwarding Detection (BFD), however, does have support for carrying an authentication object. It also supports Time-To-Live (TTL) processing as an anti-replay measure. Implementations conformant with this MPLS-ICI should support BFD authentication and must support the procedures for TTL processing.
跨MPLS-ICI的OAM操作也可能是提供商基础设施以及通过MPLS-ICI提供的服务的安全威胁源。如果ASBR未得到适当保护，大量OAM消息可能会使ASBR的处理能力无法承受。恶意生成的OAM消息也可用于关闭其他正常服务（例如MPLS伪线），从而影响服务安全。LSP ping目前不支持身份验证，这种支持应该作为未来考虑的主题。然而，双向转发检测（BFD）确实支持携带身份验证对象。它还支持生存时间（TTL）处理作为一种反重放措施。符合此MPLS-ICI的实现应支持BFD身份验证，并且必须支持TTL处理过程。
Implementations must have the ability to prevent signaling and routing DoS attacks on the control plane per interface and provider. Such prevention may be provided by rate limiting signaling and routing messages that can be sent by a peer provider according to a traffic profile and by guarding against malformed packets.
实现必须能够在每个接口和提供程序的控制平面上防止信令和路由DoS攻击。可通过速率限制信令和路由消息（可由对等提供商根据业务简档发送）和通过防止格式错误的分组来提供这种预防。
Equipment must provide the ability to filter signaling, routing, and OAM packets destined for the device, and must provide the ability to rate limit such packets. Packet filters should be capable of being separately applied per interface, and should have minimal or no performance impact. For example, this allows an operator to filter or rate limit signaling, routing, and OAM messages that can be sent by a peer provider and limit such traffic to a given profile.
设备必须提供过滤发往设备的信令、路由和OAM数据包的能力，并且必须提供对此类数据包进行速率限制的能力。数据包过滤器应该能够分别应用于每个接口，并且应该对性能影响最小或没有影响。例如，这允许运营商过滤或限制对等提供商可以发送的信令、路由和OAM消息，并将此类流量限制到给定的配置文件。
During a control-plane DoS attack against an ASBR, the router should guarantee sufficient resources to allow network operators to execute network management commands to take corrective action, such as turning on additional filters or disconnecting an interface under attack. DoS attacks on the control plane should not adversely affect data-plane performance.
在针对ASBR的控制平面DoS攻击期间，路由器应保证有足够的资源允许网络运营商执行网络管理命令以采取纠正措施，例如打开其他过滤器或断开受到攻击的接口。控制平面上的DoS攻击不应对数据平面性能产生不利影响。
Equipment running BGP must support the ability to limit the number of BGP routes received from any particular peer. Furthermore, in the case of IPVPN, a router must be able to limit the number of routes
运行BGP的设备必须支持限制从任何特定对等方接收的BGP路由数量的能力。此外，在IPVPN的情况下，路由器必须能够限制路由的数量
learned from a BGP peer per IPVPN. In the case that a device has multiple BGP peers, it should be possible for the limit to vary between peers.
根据IPVPN从BGP对等方学习。在一个设备有多个BGP对等点的情况下，对等点之间的限制可能会有所不同。
Equipment should be robust in the presence of malformed protocol packets. For example, malformed routing, signaling, and OAM packets should be treated in accordance with the relevant protocol specification.
在存在格式错误的协议数据包时，设备应坚固耐用。例如，应根据相关协议规范处理格式错误的路由、信令和OAM数据包。
Equipment must have the ability to drop any signaling or routing protocol messages when these messages are to be processed by the ASBR but the corresponding protocol is not enabled on that interface.
当ASBR处理任何信令或路由协议消息，但该接口上未启用相应协议时，设备必须能够丢弃这些消息。
Equipment must allow an administrator to enable or disable a protocol (by default, the protocol is disabled unless administratively enabled) on an interface basis.
设备必须允许管理员在接口的基础上启用或禁用协议（默认情况下，除非以管理方式启用，否则该协议将被禁用）。
Equipment must be able to drop any signaling or routing protocol messages when these messages are to be processed by the ASBR but the corresponding protocol is not enabled on that interface. This dropping should not adversely affect data-plane or control-plane performance.
当ASBR处理任何信令或路由协议消息，但该接口上未启用相应协议时，设备必须能够丢弃这些消息。这种删除不应对数据平面或控制平面的性能产生不利影响。
The capability to detect and locate faults in an LSP cross-connect must be provided. Such faults may cause security violations as they result in directing traffic to the wrong destinations. This capability may rely on OAM functions. Equipment must support MPLS LSP ping [RFC4379]. This may be used to verify end-to-end connectivity for the LSP (e.g., PW, TE Tunnel, VPN LSP, etc.), and to verify PE-to-PE connectivity for IPVPN services.
必须提供在LSP交叉连接中检测和定位故障的能力。此类故障可能会导致违反安全规定，因为它们会将流量导向错误的目的地。此功能可能依赖于OAM功能。设备必须支持MPLS LSP ping[RFC4379]。这可用于验证LSP的端到端连接（例如，PW、TE隧道、VPN LSP等），以及验证IPVPN服务的PE到PE连接。
When routing information is advertised from one domain to the other, operators must be able to guard against situations that result in traffic hijacking, black-holing, resource stealing (e.g., number of routes), etc. For instance, in the IPVPN case, an operator must be able to block routes based on associated route target attributes. In addition, mechanisms to defend against routing protocol attack must exist to verify whether a route advertised by a peer for a given VPN is actually a valid route and whether the VPN has a site attached to or reachable through that domain.
当路由信息从一个域发布到另一个域时，运营商必须能够防范导致流量劫持、黑洞、资源窃取（例如，路由数量）等的情况。例如，在IPVPN情况下，运营商必须能够根据相关的路由目标属性阻止路由。此外，必须存在防御路由协议攻击的机制，以验证对等方为给定VPN播发的路由是否实际是有效路由，以及VPN是否具有连接到该域或可通过该域访问的站点。
Equipment (ASBRs and Route Reflectors (RRs)) supporting operation of BGP must be able to restrict which route target attributes are sent to and accepted from a BGP peer across an ICI. Equipment (ASBRs, RRs) should also be able to inform the peer regarding which route target attributes it will accept from a peer, because sending an incorrect route target can result in an incorrect cross-connection of VPNs. Also, sending inappropriate route targets to a peer may disclose confidential information. This is another example of defense against routing protocol attacks.
支持BGP操作的设备（ASBR和路由反射器（RRs））必须能够限制通过ICI向BGP对等方发送和接受哪些路由目标属性。设备（ASBR、RRs）还应能够通知对等方它将从对等方接受哪些路由目标属性，因为发送错误的路由目标可能导致VPN的错误交叉连接。此外，向对等方发送不适当的路由目标可能会泄露机密信息。这是防御路由协议攻击的另一个示例。
Equipment must support route filtering of routes received via a BGP peer session by applying policies that include one or more of the following: AS path, BGP next hop, standard community, or extended community.
设备必须通过应用包括以下一项或多项的策略来支持对通过BGP对等会话接收的路由进行路由过滤：AS path、BGP下一跳、标准社区或扩展社区。
The ability to identify and block messages with confidential information from leaving the trusted domain that can reveal confidential information about network operation (e.g., performance OAM messages or LSP ping messages) is required. SPs must have the flexibility to handle these messages at the ASBR.
需要能够识别和阻止带有机密信息的消息离开可泄露有关网络操作机密信息的受信任域（例如，性能OAM消息或LSP ping消息）。SP必须具有在ASBR上处理这些消息的灵活性。
Equipment should be able to identify and restrict where it sends messages that can reveal confidential information about network operation (e.g., performance OAM messages, LSP Traceroute messages). Service Providers must have the flexibility to handle these messages at the ASBR. For example, equipment supporting LSP Traceroute may limit to which addresses replies can be sent. Note that this capability should be used with care. For example, if an SP chooses to prohibit the exchange of LSP ping messages at the ICI, it may make it more difficult to debug incorrect cross-connection of LSPs or other problems.
设备应能够识别并限制其发送可能泄露网络运行机密信息的消息的位置（例如，性能OAM消息、LSP跟踪路由消息）。服务提供商必须具有在ASBR处理这些消息的灵活性。例如，支持LSP跟踪路由的设备可能会限制可以向哪些地址发送回复。请注意，应小心使用此功能。例如，如果SP选择禁止在ICI上交换LSP ping消息，则可能使调试LSP的错误交叉连接或其他问题变得更加困难。
An SP may decide to progress these messages if they arrive from a trusted provider and are targeted to specific, agreed-on addresses. Another provider may decide to traffic police, reject, or apply other policies to these messages. Solutions must enable providers to control the information that is relayed to another provider about the path that an LSP takes. For example, when using the RSVP-TE record route object or LSP ping / trace, a provider must be able to control the information contained in corresponding messages when sent to another provider.
如果这些消息来自受信任的提供商，并且目标是特定的、商定的地址，SP可能会决定对其进行处理。另一个提供商可能决定对这些消息实施交通管制、拒绝或应用其他策略。解决方案必须使提供程序能够控制转发给另一个提供程序的有关LSP路径的信息。例如，当使用RSVP-TE记录路由对象或LSP ping/trace时，提供程序必须能够在发送给另一个提供程序时控制相应消息中包含的信息。
8.1.8. Protection against Over-provisioned Number of RSVP-TE LSPs and Bandwidth Reservation
8.1.8. 防止RSVP-TE LSP数量过多和带宽预留
In addition to the control-plane protection mechanisms listed in the previous section on control-plane protection with RSVP-TE, the ASBR must be able both to limit the number of LSPs that can be set up by other domains and to limit the amount of bandwidth that can be reserved. A provider's ASBR may deny an LSP setup request or a bandwidth reservation request sent by another provider's whose limits have been reached.
除了前面关于RSVP-TE控制平面保护的章节中列出的控制平面保护机制外，ASBR必须能够限制其他域可以设置的LSP数量，并限制可以保留的带宽量。提供商的ASBR可以拒绝LSP设置请求或已达到限制的另一提供商的ASBR发送的带宽保留请求。
This is described in Section 5 of this document.
本文件第5节对此进行了描述。
Equipment must be able to verify that a label received across an interconnect was actually assigned to an LSP arriving across that interconnect. If a label not assigned to an LSP arrives at this router from the correct neighboring provider, the packet must be dropped. This verification can be applied to the top label only. The top label is the received top label and every label that is exposed by label popping is to be used for forwarding decisions.
设备必须能够验证通过互连接收的标签是否实际分配给通过该互连到达的LSP。如果未分配给LSP的标签从正确的相邻提供商到达该路由器，则必须丢弃该数据包。此验证只能应用于顶部标签。顶部标签是接收到的顶部标签，通过标签弹出显示的每个标签都将用于转发决策。
Equipment must provide the capability to drop MPLS-labeled packets if all labels in the stack are not processed. This lets SPs guarantee that every label that enters its domain from another carrier is actually assigned to that carrier.
如果未处理堆栈中的所有标签，设备必须提供丢弃MPLS标记的数据包的能力。这使SPs能够保证从另一个运营商进入其域的每个标签都实际分配给该运营商。
The following requirements are not directly reflected in this document but must be used as guidance for addressing further work.
以下要求未直接反映在本文件中，但必须用作解决进一步工作的指南。
Solutions must NOT force operators to reveal reachability information to routers within their domains. Note that it is believed that this requirement is met via other requirements specified in this section plus the normal operation of IP routing, which does not reveal individual hosts.
解决方案不得强迫运营商向其域内的路由器透露可达性信息。请注意，本节中规定的其他要求加上IP路由的正常操作，可以满足此要求，但这不会揭示单个主机。
Mechanisms to authenticate and validate a dynamic setup request must be available. For instance, if dynamic signaling of a TE-LSP or PW is crossing a domain boundary, there must be a way to detect whether the LSP source is who it claims to be and that it is allowed to connect to the destination.
验证和验证动态设置请求的机制必须可用。例如，如果TE-LSP或PW的动态信令正在跨越域边界，则必须有一种方法来检测LSP源是否是它所声称的那个人，以及是否允许它连接到目的地。
The following simple diagram illustrates a potential security issue on the data plane across an MPLS interconnect:
下图显示了MPLS互连中数据平面上的潜在安全问题：
SP2 - ASBR2 - labeled path - ASBR1 - P1 - SP1's PSN - P2 - PE1
| | | |
|< AS2 >|<MPLS interconnect>|< AS1 >|
SP2 - ASBR2 - labeled path - ASBR1 - P1 - SP1's PSN - P2 - PE1
| | | |
|< AS2 >|<MPLS interconnect>|< AS1 >|
Traffic flow direction is from SP2 to SP1
交通流方向为SP2至SP1
In the case of downstream label assignment, the transit label used by ASBR2 is allocated by ASBR1, which in turn advertises it to ASBR2 (downstream unsolicited or on-demand); this label is used for a service context (VPN label, PW VC label, etc.), and this LSP is normally terminated at a forwarding table belonging to the service instance on PE (PE1) in SP1.
在下游标签分配的情况下，ASBR2使用的运输标签由ASBR1分配，ASBR1反过来向ASBR2（下游未经请求或按需）播发；此标签用于服务上下文（VPN标签、PW VC标签等），此LSP通常在属于SP1中PE（PE1）上服务实例的转发表处终止。
In the example above, ASBR1 would not know whether the label of an incoming packet from ASBR2 over the interconnect is a VPN label or PSN label for AS1. So it is possible (though unlikely) that ASBR2 can be accidentally or intentionally configured such that the incoming label could match a PSN label (e.g., LDP) in AS1. Then, this LSP would end up on the global plane of an infrastructure router (P or PE1), and this could invite a unidirectional attack on that P or PE1 where the LSP terminates.
在上面的示例中，ASBR1不知道通过互连从ASBR2传入的数据包的标签是AS1的VPN标签还是PSN标签。因此，ASBR2可能（尽管不太可能）被意外地或有意地配置，以便传入标签可以与AS1中的PSN标签（例如LDP）匹配。然后，该LSP将在基础设施路由器（P或PE1）的全局平面上结束，这可能会在LSP终止的位置对该P或PE1发起单向攻击。
To mitigate this threat, implementations should be able to do a forwarding path look-up for the label on an incoming packet from an interconnect in a Label Forwarding Information Base (LFIB) space that is only intended for its own service context or provide a mechanism on the data plane that would ensure the incoming labels are what ASBR1 has allocated and advertised.
为了减轻这种威胁，实现应该能够在标签转发信息库（LFIB）中的互连中对传入数据包上的标签执行转发路径查找仅用于其自身服务上下文的空间，或在数据平面上提供一种机制，以确保传入的标签是ASBR1分配和公布的。
A similar concept has been proposed in "Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)" [RFC5254].
“多段伪线仿真边到边（PWE3）的要求”[RFC5254]中也提出了类似的概念。
When using upstream label assignment, the upstream source must be identified and authenticated so the labels can be accepted as from a trusted source.
当使用上游标签分配时，必须识别和验证上游源，以便可以接受来自可信源的标签。
The following summary provides a quick checklist of MPLS and GMPLS security threats, defense techniques, and the best-practice outlines for MPLS and GMPLS deployment.
以下摘要提供了MPLS和GMPLS安全威胁、防御技术的快速清单，以及MPLS和GMPLS部署的最佳实践概述。
Types of attacks on the control plane:
对控制平面的攻击类型：
- Unauthorized LSP creation
- 未经授权的LSP创建
- LSP message interception
- LSP消息截获
Attacks against RSVP-TE: DoS attacks that set up unauthorized LSP and/or LSP messages.
针对RSVP-TE的攻击：设置未经授权的LSP和/或LSP消息的DoS攻击。
Attacks against LDP: DoS attack with storms of LDP Hello messages or LDP TCP SYN messages.
针对LDP的攻击：LDP Hello消息或LDP TCP SYN消息风暴的DoS攻击。
Attacks may be launched from external or internal sources, or through an SP's management systems.
攻击可以从外部或内部来源发起，也可以通过SP的管理系统发起。
Attacks may be targeted at the SP's routing protocols or infrastructure elements.
攻击的目标可能是SP的路由协议或基础架构元素。
In general, control protocols may be attacked by:
通常，控制协议可能受到以下攻击：
- MPLS signaling (LDP, RSVP-TE)
- MPLS信令（LDP、RSVP-TE）
- PCE signaling
- PCE信号
- IPsec signaling (IKE and IKEv2)
- IPsec信令（IKE和IKEv2）
- ICMP and ICMPv6
- ICMP和ICMPv6
- L2TP
- L2TP
- BGP-based membership discovery
- 基于BGP的成员身份发现
- Database-based membership discovery (e.g., RADIUS)
- 基于数据库的成员资格发现（例如RADIUS）
- OAM and diagnostic protocols such as LSP ping and LMP
- OAM和诊断协议，如LSP ping和LMP
- Other protocols that may be important to the control infrastructure, e.g., DNS, LMP, NTP, SNMP, and GRE
- 对控制基础设施可能很重要的其他协议，例如DNS、LMP、NTP、SNMP和GRE
- Unauthorized observation of data traffic
- 未经授权观察数据流量
- Data-traffic modification
- 数据流量修改
- Spoofing and replay
- 欺骗和重播
- Unauthorized deletion
- 未经授权的删除
- Unauthorized traffic-pattern analysis
- 非授权交通模式分析
- Denial of Service
- 拒绝服务
1) Authentication:
1) 身份验证：
- Bidirectional authentication
- 双向认证
- Key management
- 密钥管理
- Management system authentication
- 管理系统认证
- Peer-to-peer authentication
- 对等认证
2) Cryptographic techniques
2) 密码技术
3) Use of IPsec in MPLS/GMPLS networks
3) IPsec在MPLS/GMPLS网络中的应用
4) Encryption for device configuration and management
4) 用于设备配置和管理的加密
5) Cryptographic techniques for MPLS pseudowires
5) MPLS伪线的密码技术
6) End-to-End versus Hop-by-Hop protection (CE-CE, PE-PE, PE-CE)
6) 端到端与逐跳保护（CE-CE、PE-PE、PE-CE）
7) Access control techniques
7) 访问控制技术
- Filtering
- 过滤
- Firewalls
- 防火墙
- Access Control to management interfaces
- 对管理接口的访问控制
8) Infrastructure isolation
8) 基础设施隔离
9) Use of aggregated infrastructure
9) 使用聚合基础设施
10) Quality control processes
10） 质量控制过程
11) Testable MPLS/GMPLS service
11） 可测试MPLS/GMPLS服务
12) End-to-end connectivity verification
12） 端到端连接验证
13) Hop-by-hop resource configuration verification and discovery
13） 逐跳资源配置验证和发现
1) General control-plane protection
1) 一般控制面保护
- Filtering out infrastructure source addresses at edges
- 在边缘过滤出基础结构源地址
- Protocol authentication within the core
- 核心内的协议认证
- Infrastructure hiding (e.g., disable TTL propagation)
- 基础结构隐藏（例如，禁用TTL传播）
2) RSVP control-plane protection
2) 控制面保护
- RSVP security tools
- RSVP安全工具
- Isolation of the trusted domain
- 受信任域的隔离
- Deactivating RSVP on interfaces with neighbors who are not authorized to use RSVP
- 在与未被授权使用RSVP的邻居的接口上停用RSVP
- RSVP neighbor filtering at the protocol level and data-plane level
- 协议级和数据平面级的RSVP邻居过滤
- Authentication for RSVP messages
- RSVP消息的身份验证
- RSVP message pacing
- RSVP消息调整
3) LDP control-plane protection (similar techniques as for RSVP)
3) LDP控制面保护（与RSVP类似的技术）
4) Data-plane protection
4) 数据平面保护
- User access link protection
- 用户访问链路保护
- Link authentication
- 链路认证
- Access routing control (e.g., prefix limits, route dampening, routing table limits (such as VRF limits)
- 访问路由控制（例如，前缀限制、路由阻尼、路由表限制（例如VRF限制）
- Access QoS control
- 访问QoS控制
- Customer service monitoring tools
- 客户服务监控工具
- Use of LSP ping (with its own control-plane security) to verify end-to-end connectivity of MPLS LSPs
- 使用LSP ping（具有自己的控制平面安全性）验证MPLS LSP的端到端连接
- LMP (with its own security) to verify hop-by-hop connectivity.
- LMP（具有自身的安全性）验证逐跳连接。
Inter-provider connections are high security risk areas. Similar techniques and procedures as described for SP's general core protection are listed below for inter-provider connections.
提供商间连接是高安全风险区域。下面列出了SP一般核心保护的类似技术和程序，用于提供商间连接。
1) Control-plane protection at inter-provider connections
1) 提供程序间连接的控制平面保护
- Authentication of signaling sessions
- 信令会话的身份验证
- Protection against DoS attacks in the control plane
- 在控制平面中防止DoS攻击
- Protection against malformed packets
- 防止格式错误的数据包
- Ability to enable/disable specific protocols
- 启用/禁用特定协议的能力
- Protection against incorrect cross connection
- 防止不正确的交叉连接
- Protection against spoofed updates and route advertisements
- 防止伪造更新和路由广告
- Protection of confidential information
- 保护机密信息
- Protection against an over-provisioned number of RSVP-TE LSPs and bandwidth reservation
- 防止RSVP-TE LSP和带宽预留数量过多
2) Data-plane protection at the inter-provider connections
2) 提供程序间连接处的数据平面保护
- Protection against DoS in the data plane
- 数据平面中的DoS防护
- Protection against label spoofing
- 防止标签欺骗
For MPLS VPN interconnections [RFC4364], in practice, inter-AS option a), VRF-to-VRF connections at the AS (Autonomous System) border, is commonly used for inter-provider connections. Option c), Multi-hop EBGP redistribution of labeled VPN-IPv4 routes between source and destination ASes with EBGP redistribution of labeled IPv4 routes from AS to a neighboring AS, on the other hand, is not normally used for inter-provider connections due to higher security risks. For more details, please see [RFC4111].
对于MPLS VPN互连[RFC4364]，在实践中，AS（自治系统）边界处的VRF到VRF连接通常用于提供商间连接。选项c），源和目标ASE之间标记的VPN-IPv4路由的多跳EBGP重新分配，以及从AS到相邻AS的标记的IPv4路由的EBGP重新分配，另一方面，由于更高的安全风险，通常不用于提供商间连接。有关更多详细信息，请参阅[RFC4111]。
Security considerations constitute the sole subject of this memo and hence are discussed throughout. Here we recap what has been presented and explain at a high level the role of each type of consideration in an overall secure MPLS/GMPLS system.
安全考虑是本备忘录的唯一主题，因此将在本备忘录中进行讨论。在这里，我们回顾已经介绍的内容，并从较高的层次上解释每种考虑因素在整个安全MPLS/GMPLS系统中的作用。
The document describes a number of potential security threats. Some of these threats have already been observed occurring in running networks; others are largely hypothetical at this time.
该文件描述了一些潜在的安全威胁。已经观察到其中一些威胁发生在运行的网络中；其他的在此时基本上是假设性的。
DoS attacks and intrusion attacks from the Internet against an SPs' infrastructure have been seen. DoS "attacks" (typically not malicious) have also been seen in which CE equipment overwhelms PE equipment with high quantities or rates of packet traffic or routing information. Operational or provisioning errors are cited by SPs as one of their prime concerns.
已发现来自互联网的针对SPs基础设施的DoS攻击和入侵攻击。DoS“攻击”（通常不是恶意的）也被发现，其中CE设备以高数量或速率的数据包流量或路由信息压倒PE设备。SPs将操作或资源调配错误作为其主要关注点之一。
The document describes a variety of defensive techniques that may be used to counter the suspected threats. All of the techniques presented involve mature and widely implemented technologies that are practical to implement.
该文件描述了可用于对抗可疑威胁的各种防御技术。所介绍的所有技术都涉及成熟且广泛实施的技术，这些技术都很实用。
The document describes the importance of detecting, monitoring, and reporting attacks, both successful and unsuccessful. These activities are essential for "understanding one's enemy", mobilizing new defenses, and obtaining metrics about how secure the MPLS/GMPLS network is. As such, they are vital components of any complete PPVPN security system.
该文档描述了检测、监视和报告攻击（成功和失败）的重要性。这些活动对于“了解敌人”、动员新的防御以及获取有关MPLS/GMPLS网络安全性的指标至关重要。因此，它们是任何完整PPVPN安全系统的重要组成部分。
The document evaluates MPLS/GMPLS security requirements from a customer's perspective as well as from a service provider's perspective. These sections re-evaluate the identified threats from the perspectives of the various stakeholders and are meant to assist equipment vendors and service providers, who must ultimately decide what threats to protect against in any given configuration or service offering.
本文件从客户和服务提供商的角度评估MPLS/GMPLS安全要求。这些章节从不同利益相关者的角度重新评估已识别的威胁，旨在帮助设备供应商和服务提供商，他们必须最终决定在任何给定配置或服务提供中要防范哪些威胁。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747]Baker，F.，Lindell，B.和M.Talwar，“RSVP加密认证”，RFC 2747，2000年1月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication -- Updated Message Type Value", RFC 3097, April 2001.
[RFC3097]Braden，R.和L.Zhang，“RSVP加密身份验证——更新的消息类型值”，RFC 3097，2001年4月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945]Mannie，E.，Ed.“通用多协议标签交换（GMPLS）体系结构”，RFC 39452004年10月。
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, June 2005.
[RFC4106]Viega，J.和D.McGrew，“在IPsec封装安全有效负载（ESP）中使用Galois/计数器模式（GCM）”，RFC 4106，2005年6月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]Kent，S.，“IP认证头”，RFC43022005年12月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]考夫曼，C.，编辑，“互联网密钥交换（IKEv2）协议”，RFC4306，2005年12月。
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)", RFC 4309, December 2005.
[RFC4309]Housley，R.，“使用高级加密标准（AES）CCM模式和IPsec封装安全有效载荷（ESP）”，RFC 4309，2005年12月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]Rosen，E.和Y.Rekhter，“BGP/MPLS IP虚拟专用网络（VPN）”，RFC 4364，2006年2月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379]Kompella，K.和G.Swallow，“检测多协议标签交换（MPLS）数据平面故障”，RFC 4379，2006年2月。
[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4447]Martini，L.，Ed.，Rosen，E.，El Aawar，N.，Smith，T.，和G.Heron，“使用标签分发协议（LDP）的伪线设置和维护”，RFC 4447，2006年4月。
[RFC4835] Manral, V., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4835, April 2007.
[RFC4835]Manral，V.“封装安全有效载荷（ESP）和身份验证头（AH）的密码算法实现要求”，RFC 4835，2007年4月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[RFC5036]Andersson，L.，Ed.，Minei，I.，Ed.，和B.Thomas，Ed.，“LDP规范”，RFC 5036，2007年10月。
[STD62] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[STD62]Harrington，D.，Presuhn，R.，和B.Wijnen，“描述简单网络管理协议（SNMP）管理框架的体系结构”，STD 62，RFC 3411，2002年12月。
Case, J., Harrington, D., Presuhn, R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3412, December 2002.
Case，J.，Harrington，D.，Presohn，R.，和B.Wijnen，“简单网络管理协议（SNMP）的消息处理和调度”，STD 62，RFC 3412，2002年12月。
Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002.
Levi，D.，Meyer，P.，和B.Stewart，“简单网络管理协议（SNMP）应用”，STD 62，RFC 3413，2002年12月。
Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
Blumenthal，U.和B.Wijnen，“简单网络管理协议（SNMPv3）第3版的基于用户的安全模型（USM）”，STD 62，RFC 3414，2002年12月。
Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002.
Wijnen，B.，Presuhn，R.，和K.McCloghrie，“用于简单网络管理协议（SNMP）的基于视图的访问控制模型（VACM）”，STD 62，RFC 3415，2002年12月。
Presuhn, R., Ed., "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002.
Presohn，R.，Ed.“简单网络管理协议（SNMP）的协议操作第2版”，STD 62，RFC 3416，2002年12月。
Presuhn, R., Ed., "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002.
Presohn，R.，Ed.“简单网络管理协议（SNMP）的传输映射”，STD 62，RFC 34172002年12月。
Presuhn, R., Ed., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002.
Presohn，R.，Ed.，“简单网络管理协议（SNMP）的管理信息库（MIB）”，STD 62，RFC 3418，2002年12月。
[STD8] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[STD8]Postel，J.和J.Reynolds，“Telnet协议规范”，STD 8，RFC 854，1983年5月。
Postel, J. and J. Reynolds, "Telnet Option Specifications", STD 8, RFC 855, May 1983.
Postel，J.和J.Reynolds，“Telnet选项规范”，标准8，RFC 855，1983年5月。
[OIF-SMI-01.0] Renee Esposito, "Security for Management Interfaces to Network Elements", Optical Internetworking Forum, Sept. 2003.
[OIF-SMI-01.0]Renee Esposito，“网元管理接口的安全性”，光纤互联论坛，2003年9月。
[OIF-SMI-02.1] Renee Esposito, "Addendum to the Security for Management Interfaces to Network Elements", Optical Internetworking Forum, March 2006.
[OIF-SMI-02.1]Renee Esposito，“网元管理接口安全性附录”，光纤互联论坛，2006年3月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[RFC2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[RFC2411]Thayer，R.，Doraswamy，N.，和R.Glenn，“IP安全文档路线图”，RFC 24111998年11月。
[RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.
[RFC3174]Eastlake 3rd，D.和P.Jones，“美国安全哈希算法1（SHA1）”，RFC 3174，2001年9月。
[RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 Signature Option", RFC 3562, July 2003.
[RFC3562]Leech，M.，“TCP MD5签名选项的密钥管理注意事项”，RFC 3562，2003年7月。
[RFC3631] Bellovin, S., Ed., Schiller, J., Ed., and C. Kaufman, Ed., "Security Mechanisms for the Internet", RFC 3631, December 2003.
[RFC3631]Bellovin，S.，Ed.，Schiller，J.，Ed.，和C.Kaufman，Ed.，“互联网的安全机制”，RFC 36312003年12月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]Baker，F.和P.Savola，“多宿网络的入口过滤”，BCP 84，RFC 37042004年3月。
[RFC3985] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985]Bryant，S.，Ed.，和P.Pate，Ed.，“伪线仿真边到边（PWE3）架构”，RFC 39852005年3月。
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
[RFC4107]Bellovin，S.和R.Housley，“加密密钥管理指南”，BCP 107，RFC 4107，2005年6月。
[RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4110, July 2005.
[RFC4110]Callon，R.和M.Suzuki，“第3层提供商提供的虚拟专用网络（PPVPN）框架”，RFC 4110，2005年7月。
[RFC4111] Fang, L., Ed., "Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4111, July 2005.
[RFC4111]Fang，L.，Ed.“提供商提供的虚拟专用网络（PPVPN）的安全框架”，RFC 4111，2005年7月。
[RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security Properties", RFC 4230, December 2005.
[RFC4230]Tschofenig，H.和R.Graveman，“RSVP安全属性”，RFC 4230，2005年12月。
[RFC4308] Hoffman, P., "Cryptographic Suites for IPsec", RFC 4308, December 2005.
[RFC4308]Hoffman，P.，“IPsec加密套件”，RFC 4308，2005年12月。
[RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. Matsushima, "Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks", RFC 4377, February 2006.
[RFC4377]Nadeau，T.，Morrow，M.，Swallow，G.，Allan，D.，和S.Matsushima，“多协议标签交换（MPLS）网络的运营和管理（OAM）要求”，RFC 4377，2006年2月。
[RFC4378] Allan, D., Ed., and T. Nadeau, Ed., "A Framework for Multi-Protocol Label Switching (MPLS) Operations and Management (OAM)", RFC 4378, February 2006.
[RFC4378]Allan，D.，Ed.，和T.Nadeau，Ed.，“多协议标签交换（MPLS）操作和管理（OAM）框架”，RFC 4378，2006年2月。
[RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, October 2006.
[RFC4593]Barbir，A.，Murphy，S.，和Y.Yang，“路由协议的一般威胁”，RFC 4593，2006年10月。
[RFC4778] Kaeo, M., "Operational Security Current Practices in Internet Service Provider Environments", RFC 4778, January 2007.
[RFC4778]Kaeo，M.，“互联网服务提供商环境中的运营安全当前实践”，RFC 4778，2007年1月。
[RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5", RFC 4808, March 2007.
[RFC4808]Bellovin，S.，“TCP-MD5的关键变化策略”，RFC 4808，2007年3月。
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, "Local Network Protection for IPv6", RFC 4864, May 2007.
[RFC4864]Van de Velde，G.，Hain，T.，Droms，R.，Carpenter，B.，和E.Klein，“IPv6的本地网络保护”，RFC 4864，2007年5月。
[RFC4869] Law, L. and J. Solinas, "Suite B Cryptographic Suites for IPsec", RFC 4869, May 2007.
[RFC4869]Law，L.和J.Solinas，“用于IPsec的套件B加密套件”，RFC 4869，2007年5月。
[RFC5254] Bitar, N., Ed., Bocci, M., Ed., and L. Martini, Ed., "Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)", RFC 5254, October 2008.
[RFC5254]Bitar，N.，Ed.，Bocci，M.，Ed.，和L.Martini，Ed.，“多段伪线仿真边到边（PWE3）的要求”，RFC 5254，2008年10月。
[MFA-MPLS-ICI] N. Bitar, "MPLS InterCarrier Interconnect Technical Specification," IP/MPLS Forum 19.0.0, April 2008.
[MFA-MPLS-ICI]N.Bitar，“MPLS载波间互连技术规范”，IP/MPLS论坛19.0.0，2008年4月。
[OIF-Sec-Mag] R. Esposito, R. Graveman, and B. Hazzard, "Security for Management Interfaces to Network Elements," OIF-SMI-01.0, September 2003.
[OIF Sec Mag]R.Esposito、R.Graveman和B.Hazzard，“网元管理接口的安全”，OIF-SMI-01.012003年9月。
[BACKBONE-ATTKS] Savola, P., "Backbone Infrastructure Attacks and Protections", Work in Progress, January 2007.
[BACKBONE-ATTKS]Savola，P.，“主干基础设施攻击和保护”，正在进行的工作，2007年1月。
[OPSEC-FILTER] Morrow, C., Jones, G., and V. Manral, "Filtering and Rate Limiting Capabilities for IP Network Infrastructure", Work in Progress, July 2007.
[OPSEC-FILTER]Morrow，C.，Jones，G.，和V.Manral，“IP网络基础设施的过滤和速率限制能力”，正在进行的工作，2007年7月。
[IPSECME-ROADMAP] Frankel, S. and S. Krishnan, "IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap", Work in Progress, May 2010.
[IPSECME-ROADMAP]Frankel，S.和S.Krishnan，“IP安全（IPsec）和互联网密钥交换（IKE）文档路线图”，正在进行的工作，2010年5月。
[OPSEC-EFFORTS] Lonvick, C. and D. Spak, "Security Best Practices Efforts and Documents", Work in Progress, May 2010.
[OPSEC-努力]Lonvick，C.和D.Spak，“安全最佳实践努力和文件”，正在进行的工作，2010年5月。
[RSVP-key] Behringer, M. and F. Le Faucheur, "Applicability of Keying Methods for RSVP Security", Work in Progress, June 2009.
[RSVP密钥]Behringer，M.和F.Le Faucheur，“RSVP安全密钥方法的适用性”，正在进行的工作，2009年6月。
The authors and contributors would also like to acknowledge the helpful comments and suggestions from Sam Hartman, Dimitri Papadimitriou, Kannan Varadhan, Stephen Farrell, Mircea Pisica, Scott Brim in particular for his comments and discussion through GEN-ART review,as well as Suresh Krishnan for his GEN-ART review and comments. The authors would like to thank Sandra Murphy and Tim Polk for their comments and help through Security AD review, thank Pekka Savola for his comments through ops-dir review, and Amanda Baber for her IANA review.
作者和撰稿人还想感谢Sam Hartman、Dimitri Papadimitriou、Kannan Varadhan、Stephen Farrell、Mircea Pisica、Scott Brim的有益评论和建议，特别是他通过GEN-ART review发表的评论和讨论，以及Suresh Krishnan发表的GEN-ART评论和意见。作者要感谢Sandra Murphy和Tim Polk通过安全广告评论发表的评论和帮助，感谢Pekka Savola通过ops dir评论发表的评论，以及Amanda Baber通过IANA评论发表的评论。
This document has used relevant content from RFC 4111 "Security Framework of Provider Provisioned VPN for Provider-Provisioned Virtual Private Networks (PPVPNs)" [RFC4111]. We acknowledge the authors of RFC 4111 for the valuable information and text.
本文件使用了RFC 4111“提供商提供的虚拟专用网络（PPVPN）提供商提供的VPN安全框架”[RFC4111]中的相关内容。我们感谢RFC4111的作者提供了宝贵的信息和文本。
Authors:
作者：
Luyuan Fang, Ed., Cisco Systems, Inc. Michael Behringer, Cisco Systems, Inc. Ross Callon, Juniper Networks Richard Graveman, RFG Security, LLC J. L. Le Roux, France Telecom Raymond Zhang, British Telecom Paul Knight, Individual Contributor
方陆元主编，思科系统有限公司迈克尔·贝林格，思科系统有限公司罗斯·卡隆，Juniper Networks Richard Graveman，RFG Security，LLC J.L.Le Roux，法国电信公司张雷蒙德，英国电信公司保罗·奈特，个人撰稿人
Yaakov Stein, RAD Data Communications Nabil Bitar, Verizon Monique Morrow, Cisco Systems, Inc. Adrian Farrel, Old Dog Consulting
Yaakov Stein，RAD数据通信公司Nabil Bitar，Verizon Monique Morrow，思科系统公司Adrian Farrel，老狗咨询公司
As a design team member for the MPLS Security Framework, Jerry Ash also made significant contributions to this document.
作为MPLS安全框架的设计团队成员，Jerry Ash也对本文档做出了重大贡献。
Michael Behringer Cisco Systems, Inc. Village d'Entreprises Green Side 400, Avenue Roumanille, Batiment T 3 06410 Biot, Sophia Antipolis FRANCE EMail: mbehring@cisco.com
Michael Behringer Cisco Systems，Inc.法国索菲亚安提波利斯市比奥特市巴蒂门特T 306410路鲁曼尼尔大道400号企业绿边村电子邮件：mbehring@cisco.com
Ross Callon Juniper Networks 10 Technology Park Drive Westford, MA 01886 USA EMail: rcallon@juniper.net
Ross Callon Juniper Networks 10 Technology Park Drive Westford，马萨诸塞州01886美国电子邮件：rcallon@juniper.net
Richard Graveman RFG Security 15 Park Avenue Morristown, NJ 07960 EMail: rfg@acm.org
新泽西州莫里斯镇公园大道15号Richard Graveman RFG Security 07960电子邮件：rfg@acm.org
Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex FRANCE EMail: jeanlouis.leroux@francetelecom.com
Jean-Louis Le Roux法国电信2号，Pierre Marzin大街22307 Lannion Cedex France电子邮件：jeanlouis。leroux@francetelecom.com
Raymond Zhang British Telecom BT Center 81 Newgate Street London, EC1A 7AJ United Kingdom EMail: raymond.zhang@bt.com
Raymond Zhang英国电信BT中心81 Newgate Street London，EC1A 7AJ英国电子邮件：Raymond。zhang@bt.com
Paul Knight 39 N. Hancock St. Lexington, MA 02420 EMail: paul.the.knight@gmail.com
保罗·奈特39 N.汉考克圣列克星敦，马萨诸塞州02420电子邮件：Paul.the。knight@gmail.com
Yaakov (Jonathan) Stein RAD Data Communications 24 Raoul Wallenberg St., Bldg C Tel Aviv 69719 ISRAEL EMail: yaakov_s@rad.com
雅科夫（Jonathan）Stein RAD数据通信公司以色列特拉维夫C栋Raoul Wallenberg街24号邮编：69719电子邮件：雅科夫_s@rad.com
Nabil Bitar Verizon 40 Sylvan Road Waltham, MA 02145 EMail: nabil.bitar@verizon.com
Nabil Bitar Verizon马萨诸塞州沃尔瑟姆Sylvan路40号02145电子邮件：Nabil。bitar@verizon.com
Monique Morrow Glatt-com CH-8301 Glattzentrum Switzerland EMail: mmorrow@cisco.com
Monique Morrow Glatt com CH-8301 Glattzentrum Switzerland电子邮件：mmorrow@cisco.com
Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk
Adrian Farrel老狗咨询电子邮件：adrian@olddog.co.uk
Editor's Address
编辑地址
Luyuan Fang (editor) Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 USA EMail: lufang@cisco.com
方陆元（编辑）思科系统有限公司，地址：美国马萨诸塞州伯斯堡市比弗布鲁克路300号邮编：01719电子邮件：lufang@cisco.com