Network Working Group L. Fang, Ed.
Request for Comments: 4111 AT&T Labs.
Category: Informational July 2005
Network Working Group L. Fang, Ed.
Request for Comments: 4111 AT&T Labs.
Category: Informational July 2005
Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)
提供商提供的虚拟专用网络（PPVPN）的安全框架
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document addresses security aspects pertaining to Provider-Provisioned Virtual Private Networks (PPVPNs). First, it describes the security threats in the context of PPVPNs and defensive techniques to combat those threats. It considers security issues deriving both from malicious behavior of anyone and from negligent or incorrect behavior of the providers. It also describes how these security attacks should be detected and reported. It then discusses possible user requirements for security of a PPVPN service. These user requirements translate into corresponding provider requirements. In addition, the provider may have additional requirements to make its network infrastructure secure to a level that can meet the PPVPN customer's expectations. Finally, this document defines a template that may be used to describe and analyze the security characteristics of a specific PPVPN technology.
本文档介绍与提供商提供的虚拟专用网络（PPVPN）相关的安全方面。首先，它描述了PPVPN环境中的安全威胁以及应对这些威胁的防御技术。它考虑由任何人的恶意行为和提供者的疏忽或不正确行为引起的安全问题。它还描述了如何检测和报告这些安全攻击。然后讨论用户对PPVPN服务安全性的可能要求。这些用户需求转化为相应的提供商需求。此外，提供商可能有其他要求，以使其网络基础设施安全到能够满足PPVPN客户期望的水平。最后，本文档定义了一个模板，可用于描述和分析特定PPVPN技术的安全特性。
Table of Contents
目录
1. Introduction ................................................. 2
2. Terminology .................................................. 4
3. Security Reference Model ..................................... 4
4. Security Threats ............................................. 6
4.1. Attacks on the Data Plane .............................. 7
4.2. Attacks on the Control Plane ........................... 9
5. Defensive Techniques for PPVPN Service Providers ............. 11
5.1. Cryptographic Techniques ............................... 12
5.2. Authentication ......................................... 20
5.3. Access Control Techniques .............................. 22
5.4. Use of Isolated Infrastructure ......................... 27
1. Introduction ................................................. 2
2. Terminology .................................................. 4
3. Security Reference Model ..................................... 4
4. Security Threats ............................................. 6
4.1. Attacks on the Data Plane .............................. 7
4.2. Attacks on the Control Plane ........................... 9
5. Defensive Techniques for PPVPN Service Providers ............. 11
5.1. Cryptographic Techniques ............................... 12
5.2. Authentication ......................................... 20
5.3. Access Control Techniques .............................. 22
5.4. Use of Isolated Infrastructure ......................... 27
5.5. Use of Aggregated Infrastructure ....................... 27
5.6. Service Provider Quality Control Processes ............. 28
5.7. Deployment of Testable PPVPN Service ................... 28
6. Monitoring, Detection, and Reporting of Security Attacks ..... 28
7. User Security Requirements ................................... 29
7.1. Isolation .............................................. 30
7.2. Protection ............................................. 30
7.3. Confidentiality ........................................ 31
7.4. CE Authentication ...................................... 31
7.5. Integrity .............................................. 31
7.6. Anti-replay ............................................ 32
8. Provider Security Requirements ............................... 32
8.1. Protection within the Core Network ..................... 32
8.2. Protection on the User Access Link ..................... 34
8.3. General Requirements for PPVPN Providers ............... 36
9. Security Evaluation of PPVPN Technologies .................... 37
9.1. Evaluating the Template ................................ 37
9.2. Template ............................................... 37
10. Security Considerations ...................................... 40
11. Contributors ................................................. 41
12. Acknowledgement .............................................. 42
13. Normative References ......................................... 42
14. Informative References ....................................... 43
5.5. Use of Aggregated Infrastructure ....................... 27
5.6. Service Provider Quality Control Processes ............. 28
5.7. Deployment of Testable PPVPN Service ................... 28
6. Monitoring, Detection, and Reporting of Security Attacks ..... 28
7. User Security Requirements ................................... 29
7.1. Isolation .............................................. 30
7.2. Protection ............................................. 30
7.3. Confidentiality ........................................ 31
7.4. CE Authentication ...................................... 31
7.5. Integrity .............................................. 31
7.6. Anti-replay ............................................ 32
8. Provider Security Requirements ............................... 32
8.1. Protection within the Core Network ..................... 32
8.2. Protection on the User Access Link ..................... 34
8.3. General Requirements for PPVPN Providers ............... 36
9. Security Evaluation of PPVPN Technologies .................... 37
9.1. Evaluating the Template ................................ 37
9.2. Template ............................................... 37
10. Security Considerations ...................................... 40
11. Contributors ................................................. 41
12. Acknowledgement .............................................. 42
13. Normative References ......................................... 42
14. Informative References ....................................... 43
Security is an integral aspect of Provider-Provisioned Virtual Private Network (PPVPN) services. The motivation and rationale for both Provider-Provisioned Layer-2 VPN and Provider-Provisioned Layer-3 VPN services are provided by [RFC4110] and [RFC4031]. These documents acknowledge that security is an important and integral aspect of PPVPN services, for both VPN customers and VPN service providers. Both will benefit from a PPVPN Security Framework document that lists the customer and provider security requirements related to PPVPN services, and that can be used to assess how much a particular technology protects against security threats and fulfills the security requirements.
安全性是提供商提供的虚拟专用网络（PPVPN）服务的一个重要方面。提供商提供的第2层VPN和提供商提供的第3层VPN服务的动机和原理由[RFC4110]和[RFC4031]提供。这些文件承认，对于VPN客户和VPN服务提供商而言，安全性是PPVPN服务的一个重要组成部分。两者都将受益于PPVPN安全框架文档，该文档列出了与PPVPN服务相关的客户和提供商安全要求，并可用于评估特定技术对安全威胁的防护程度和满足安全要求的程度。
First, we describe the security threats that are relevant in the context of PPVPNs, and the defensive techniques that can be used to combat those threats. We consider security issues deriving both from malicious or incorrect behavior of users and other parties and from negligent or incorrect behavior of the providers. An important part of security defense is the detection and report of a security attack,
首先，我们描述与PPVPN相关的安全威胁，以及可用于打击这些威胁的防御技术。我们考虑来自用户和其他方的恶意或不正确行为以及提供者的疏忽或错误行为的安全问题。安全防御的一个重要部分是检测和报告安全攻击，
which is also addressed in this document. Special considerations engendered by IP mobility within PPVPNs are not in the scope of this document.
本文件中也讨论了这一点。由PPVPN内的IP移动性引起的特殊注意事项不在本文档的范围内。
Then, we discuss the possible user and provider security requirements for a PPVPN service. Users expectations must be met for the security characteristics of a VPN service. These user requirements translate into corresponding requirements for the providers offering the service. Furthermore, providers have security requirements to protect their network infrastructure, securing it to the level required to provide the PPVPN services in addition to other services.
然后，我们讨论PPVPN服务可能的用户和提供商安全要求。VPN服务的安全特性必须满足用户的期望。这些用户需求转化为提供服务的提供商的相应需求。此外，提供商有安全要求来保护其网络基础设施，将其保护到除其他服务外提供PPVPN服务所需的级别。
Finally, we define a template that may be used to describe the security characteristics of a specific PPVPN technology in a manner consistent with the security framework described in this document. It is not within the scope of this document to analyze the security properties of specific technologies. Instead, our intention is to provide a common tool, in the form of a checklist, that may be used in other documents dedicated to an in-depth security analysis of individual PPVPN technologies to describe their security characteristics in a comprehensive and coherent way, thereby providing a common ground for comparison between different technologies.
最后，我们定义了一个模板，该模板可用于以与本文档中描述的安全框架一致的方式描述特定PPVPN技术的安全特性。分析特定技术的安全属性不在本文档的范围内。相反，我们的目的是以清单的形式提供一个通用工具，该工具可用于其他文件中，专门用于对单个PPVPN技术进行深入的安全分析，以全面、一致的方式描述其安全特性，从而为不同技术之间的比较提供了一个共同的基础。
It is important to clarify that this document is limited to describing users' and providers' security requirements that pertain to PPVPN services. It is not the intention to formulate precise "requirements" on each specific technology by defining the mechanisms and techniques that must be implemented to satisfy such users' and providers' requirements.
必须澄清的是，本文件仅限于描述与PPVPN服务相关的用户和提供商的安全要求。通过定义必须实现的机制和技术来满足这些用户和提供商的需求，并不是要对每项特定技术制定精确的“需求”。
This document is organized as follows. Section 2 defines the terminology used in the document. Section 3 defines the security reference model for security in PPVPN networks. Section 4 describes the security threats that are specific of PPVPNs. Section 5 reviews defense techniques that may be used against those threats. Section 6 describes how attacks may be detected and reported. Section 7 discusses the user security requirements that apply to PPVPN services. Section 8 describes additional security requirements on the provider to guarantee the security of the network infrastructure providing PPVPN services. In Section 9, we provide a template that may be used to describe the security characteristics of specific PPVPN technologies. Finally, Section 10 discusses security considerations.
本文件的组织结构如下。第2节定义了文件中使用的术语。第3节定义了PPVPN网络安全的安全参考模型。第4节描述了PPVPN特有的安全威胁。第5节回顾了针对这些威胁可能使用的防御技术。第6节描述了如何检测和报告攻击。第7节讨论了适用于PPVPN服务的用户安全要求。第8节描述了对提供商的附加安全要求，以保证提供PPVPN服务的网络基础设施的安全。在第9节中，我们提供了一个模板，可用于描述特定PPVPN技术的安全特性。最后，第10节讨论了安全注意事项。
This document uses PPVPN-specific terminology. Definitions and details specific to PPVPN terminology can be found in [RFC4026] and [RFC4110]. The most important definitions are repeated in this section; for other definitions, the reader is referred to [RFC4026] and [RFC4110].
本文档使用PPVPN专用术语。有关PPVPN术语的定义和详细信息，请参见[RFC4026]和[RFC4110]。本节重复了最重要的定义；对于其他定义，读者参考[RFC4026]和[RFC4110]。
CE: Customer Edge device, a router or a switch in the customer network interfacing with the service provider's network.
CE：客户边缘设备，客户网络中与服务提供商网络接口的路由器或交换机。
P: Provider Router. The Provider Router is a router in the service provider's core network that does not have interfaces directly toward the customer. A P router is used to interconnect the PE routers. A P router does not have to maintain VPN state and is thus VPN unaware.
提供商路由器。提供商路由器是服务提供商核心网络中的路由器，没有直接面向客户的接口。P路由器用于互连PE路由器。P路由器不必维护VPN状态，因此不知道VPN。
PE: Provider Edge device, 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, a VPN that is configured and managed by the service provider (and thus not by the customer itself).
PPVPN：提供商提供的虚拟专用网络，由服务提供商（而不是客户本身）配置和管理的VPN。
SP: Service Provider.
SP：服务提供商。
VPN: Virtual Private Network, which restricts communication between a set of sites using an IP backbone shared by traffic that is not going to or coming from those sites.
VPN：虚拟专用网络，它限制一组站点之间的通信，这些站点使用一个IP主干网，该主干网由不进出这些站点的流量共享。
This section defines a reference model for security in PPVPN networks.
本节定义了PPVPN网络安全的参考模型。
A PPVPN core network is the central network infrastructure (P and PE routers) over which PPVPN services are delivered. A PPVPN core network consists of one or more SP networks. All network elements in the core are under the operational control of one or more PPVPN service providers. Even if the PPVPN core is provided by several service providers, it appears to the PPVPN users as a single zone of trust. However, several service providers providing a common PPVPN core still have to secure themselves against the other providers. PPVPN services can also be delivered over the Internet, in which case the Internet forms a logical part of the PPVPN core.
PPVPN核心网络是提供PPVPN服务的中央网络基础设施（P和PE路由器）。PPVPN核心网络由一个或多个SP网络组成。核心中的所有网络元素都在一个或多个PPVPN服务提供商的运营控制之下。即使PPVPN核心由多个服务提供商提供，PPVPN用户也会认为它是一个单一的信任区域。但是，几个提供公共PPVPN核心的服务提供商仍然必须针对其他提供商进行保护。PPVPN服务也可以通过互联网交付，在这种情况下，互联网构成PPVPN核心的逻辑部分。
A PPVPN user is a company, institution or residential client of the PPVPN service provider.
PPVPN用户是PPVPN服务提供商的公司、机构或住宅客户。
A PPVPN service is a private network service made available by a service provider to a PPVPN user. The service is implemented using virtual constructs built on a shared PPVPN core network. A PPVPN service interconnects sites of a PPVPN user.
PPVPN服务是由服务提供商向PPVPN用户提供的专用网络服务。该服务使用构建在共享PPVPN核心网络上的虚拟结构实现。PPVPN服务连接PPVPN用户的站点。
Extranets are VPNs in which multiple sites are controlled by different (legal) entities. Extranets are another example of PPVPN deployment scenarios wherein restricted and controlled communication is allowed between trusted zones, often via well-defined transit points.
外部网是VPN，其中多个站点由不同的（法律）实体控制。外部网是PPVPN部署场景的另一个示例，其中受信任区域之间允许受限和受控的通信，通常通过定义良好的传输点。
This document defines each PPVPN as a trusted zone and the PPVPN core as another trusted zone. A primary concern is 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 PPVPN framework.
本文档将每个PPVPN定义为一个受信任区域，将PPVPN核心定义为另一个受信任区域。主要关注的是安全方面，这些方面与从受信任区域的“外部”到该区域的“内部”的安全性破坏有关。图1描述了PPVPN框架中受信任区域的概念。
+------------+ +------------+
| PPVPN +-----------------------------+ PPVPN |
| user PPVPN user |
| site +---------------------XXX-----+ site |
+------------+ +------------------XXX--+ +------------+
| PPVPN core | | |
+------------------| |--+
| |
| +------\
+--------/ Internet
+------------+ +------------+
| PPVPN +-----------------------------+ PPVPN |
| user PPVPN user |
| site +---------------------XXX-----+ site |
+------------+ +------------------XXX--+ +------------+
| PPVPN core | | |
+------------------| |--+
| |
| +------\
+--------/ Internet
Figure 1: The PPVPN trusted zone model
图1:PPVPN可信区域模型
In principle, the trusted zones should be separate. However, PPVPN core networks often offer Internet access, in which case a transit point (marked "XXX" in the figure) is defined.
原则上，受信任区域应该是分开的。然而，PPVPN核心网络通常提供互联网接入，在这种情况下，定义了一个中转点（图中标记为“XXX”）。
The key requirement of a "virtual private" network (VPN) is that the security of the trusted zone of the VPN is not compromised by sharing the core infrastructure with other VPNs.
“虚拟专用”网络（VPN）的关键要求是，与其他VPN共享核心基础设施不会损害VPN受信任区域的安全性。
Security against threats that originate within the same trusted zone as their targets (for example, attacks from a user in a PPVPN to other users within the same PPVPN, or attacks entirely within the core network) is outside the scope of this document.
针对源于与其目标相同的受信任区域内的威胁的安全性（例如，PPVPN中的用户对同一PPVPN中的其他用户的攻击，或完全在核心网络内的攻击）不在本文档的范围内。
Also outside the scope are all aspects of network security that are independent of whether a network is a PPVPN network or a private
网络安全的所有方面也不在范围之内，这些方面与网络是PPVPN网络还是专用网络无关
network. For example, attacks from the Internet to a web server inside a given PPVPN will not be considered here, unless the provisioning of the PPVPN network could make a difference to the security of this server.
网络例如，此处不考虑从Internet对给定PPVPN内web服务器的攻击，除非PPVPN网络的配置可能会对该服务器的安全性产生影响。
This section discusses the various network security threats that may endanger PPVPNs. The discussion is limited to threats that are unique to PPVPNs, or that affect PPVPNs in unique ways. A successful attack on a particular PPVPN or on a service provider's PPVPN infrastructure may cause one or more of the following ill effects:
本节讨论可能危及PPVPN的各种网络安全威胁。讨论仅限于PPVPN特有的威胁，或以独特方式影响PPVPN的威胁。成功攻击特定PPVPN或服务提供商的PPVPN基础设施可能会造成以下一种或多种不良影响：
- observation, modification, or deletion of PPVPN user data,
- 观察、修改或删除PPVPN用户数据，
- replay of PPVPN user data,
- PPVPN用户数据的回放，
- injection of non-authentic data into a PPVPN,
- 将非真实数据注入PPVPN，
- traffic pattern analysis on PPVPN traffic,
- PPVPN流量的流量模式分析，
- disruption of PPVPN connectivity, or
- PPVPN连接中断，或
- degradation of PPVPN service quality.
- PPVPN服务质量下降。
It is useful to consider that threats to a PPVPN, whether malicious or accidental, may come from different categories of sources. For example they may come from:
考虑PPVPN的威胁，无论是恶意的还是偶然的，都可能来自不同类别的源。例如，他们可能来自：
- users of other PPVPNs provided by the same PPVPN service provider,
- 同一PPVPN服务提供商提供的其他PPVPN的用户，
- the PPVPN service provider or persons working for it,
- PPVPN服务提供商或其工作人员，
- other persons who obtain physical access to a service provider site,
- 能够实际访问服务提供商站点的其他人员，
- other persons who use social engineering methods to influence behavior of service provider personnel,
- 使用社会工程方法影响服务提供商人员行为的其他人员，
- users of the PPVPN itself, i.e., intra-VPN threats (such threats are beyond the scope of this document), or
- PPVPN本身的用户，即VPN内部威胁（此类威胁超出本文档的范围），或
- others, i.e., attackers from the Internet at large.
- 其他，即来自互联网的攻击者。
In the case of PPVPNs, some parties may be in more advantageous positions that enable them to launch types of attacks not available to others. For example, users of different PPVPNs provided by the
在PPVPN的情况下，一些当事方可能处于更有利的位置，使它们能够发起其他方不可用的攻击类型。例如，由
same service provider may be able to launch attacks that those who are completely outside the network cannot.
同一个服务提供商可能能够发起完全脱离网络的人无法发起的攻击。
Given that security is generally a compromise between expense and risk, it is also useful to consider the likelihood of different attacks. There is at least a perceived difference in the likelihood of most types of attacks being successfully mounted in different environments, such as
考虑到安全通常是费用和风险之间的折衷，考虑不同攻击的可能性也是有用的。在不同环境中成功实施大多数类型攻击的可能性至少存在感知差异，例如
- in a PPVPN contained within one service provider's network, or
- 在一个服务提供商网络中包含的PPVPN中，或
- in a PPVPN transiting the public Internet.
- 在公共互联网上传输的PPVPN中。
Most types of attacks become easier to mount, and hence more likely, as the shared infrastructure that provides VPN service expands from a single service provider to multiple cooperating providers, and then to the global Internet. Attacks that may not be sufficiently likely to warrant concern in a closely controlled environment often merit defensive measures in broader, more open environments.
随着提供VPN服务的共享基础设施从单个服务提供商扩展到多个合作提供商，然后扩展到全球互联网，大多数类型的攻击变得更容易装载，因此更有可能。在严密控制的环境中，可能不太可能引起关注的攻击通常需要在更广泛、更开放的环境中采取防御措施。
The following sections discuss specific types of exploits that threaten PPVPNs.
以下各节讨论威胁PPVPN的特定类型的利用漏洞攻击。
This category encompasses attacks on the PPVPN user's data, as viewed by the service provider. Note that from the PPVPN user's point of view, some of this might be control plane traffic, e.g., routing protocols running from PPVPN user site to PPVPN user site via an L2 PPVPN.
此类攻击包括服务提供商查看的对PPVPN用户数据的攻击。请注意，从PPVPN用户的角度来看，其中一些可能是控制平面流量，例如，通过L2 PPVPN从PPVPN用户站点运行到PPVPN用户站点的路由协议。
This refers to "sniffing" VPN 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 re-inserted unchanged.
这是指“嗅探”VPN数据包并检查其内容。这可能导致机密信息的泄露。它也可以是其他攻击（如下所述）的第一步，在这些攻击中，记录的数据被修改并重新插入，或者未经修改而重新插入。
This refers to modifying the contents of packets as they traverse the VPN.
这是指在数据包通过VPN时修改其内容。
This refers to the insertion into the VPN (or "spoofing") of packets that do not belong there, with the objective of having them accepted as legitimate by the recipient. Also included in this category is
这是指在VPN中插入（或“欺骗”）不属于VPN的数据包，目的是让接收者接受这些数据包为合法数据包。这一类别还包括：
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 VPN. This is a specific type of Denial-of-Service attack.
这是指在数据包通过VPN时导致数据包被丢弃。这是一种特定类型的拒绝服务攻击。
This refers to "sniffing" VPN 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 PPVPN users, this type of attack is generally considered significantly less of a concern than are the other types discussed in this section.
这是指“嗅探”VPN数据包，并检查这些数据包的方面或元方面，即使数据包本身已加密，这些方面也可能可见。攻击者可能会根据流量的数量和时间、数据包大小、源地址和目标地址等获得有用的信息。对于大多数PPVPN用户来说，与本节中讨论的其他类型相比，这种类型的攻击通常被认为不太值得关注。
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, and CPU power.
以服务请求压倒网络，也称为“资源耗尽”DoS攻击，可能以网络中的任何资源为目标，例如链路带宽、数据包转发容量、各种协议的会话容量和CPU功率。
DoS attacks of the resource exhaustion type can be mounted against the data plane of a particular PPVPN by attempting to insert (spoof) an overwhelming quantity of non-authentic data into the VPN from outside of that VPN. Potential results might be to exhaust the bandwidth available to that VPN or to overwhelm the cryptographic authentication mechanisms of the VPN.
通过尝试从特定PPVPN外部向VPN插入（欺骗）大量非真实数据，可以针对该PPVPN的数据平面发起资源耗尽类型的DoS攻击。潜在的结果可能是耗尽该VPN的可用带宽，或者淹没VPN的加密身份验证机制。
Data plane resource exhaustion attacks can also be mounted by overwhelming the service provider's general (VPN-independent) infrastructure with traffic. These attacks on the general infrastructure are not usually a PPVPN-specific issue, unless the attack is mounted by another PPVPN user from a privileged position. For example, a PPVPN user might be able to monopolize network data plane resources and thus to disrupt other PPVPNs.)
数据平面资源耗尽攻击也可以通过使用流量压倒服务提供商的通用（独立于VPN）基础设施来发起。对一般基础设施的这些攻击通常不是特定于PPVPN的问题，除非该攻击是由另一个PPVPN用户从特权位置发起的。例如，PPVPN用户可能会垄断网络数据平面资源，从而中断其他PPVPN。）
This category encompasses attacks on the control structures operated by the PPVPN service provider.
此类攻击包括对PPVPN服务提供商操作的控制结构的攻击。
Control plane DoS attacks can be mounted specifically against the mechanisms that the service provider uses to provide PPVPNs (e.g., IPsec, MPLS) or against the general infrastructure of the service provider (e.g., P routers or shared aspects of PE routers.) Attacks against the general infrastructure are within the scope of this document only if the attack happens in relation to the VPN service; otherwise, they are not a PPVPN-specific issue.
控制平面DoS攻击可以专门针对服务提供商用于提供PPVPN的机制（例如IPsec、MPLS）或针对服务提供商的一般基础设施（例如P路由器或PE路由器的共享方面）进行仅当针对VPN服务的攻击发生时，针对通用基础设施的攻击才在本文档的范围内；否则，它们不是特定于PPVPN的问题。
Of special concern for PPVPNs is denial of service to one PPVPN user caused by the activities of another. This can occur, for example, if one PPVPN user's activities are allowed to consume excessive network resources of any sort that are also needed to serve other PPVPN users.
PPVPN特别关注的是由另一个PPVPN用户的活动导致的对一个PPVPN用户的拒绝服务。例如，如果允许一个PPVPN用户的活动消耗服务其他PPVPN用户所需的任何种类的过量网络资源，则可能发生这种情况。
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.2.2. Attacks on Service Provider Equipment via Management Interfaces
4.2.2. 通过管理接口攻击服务提供商设备
This includes unauthorized access to service provider infrastructure equipment, in order, for example, to reconfigure the equipment or to extract information (statistics, topology, etc.) about one or more PPVPNs.
这包括未经授权访问服务提供商基础设施设备，以便重新配置设备或提取有关一个或多个PPVPN的信息（统计信息、拓扑等）。
This can be accomplished through malicious entrance of the systems, or as an inadvertent consequence of inadequate inter-VPN isolation in a PPVPN user self-management interface. (The former is not necessarily a PPVPN-specific issue.)
这可以通过恶意进入系统来实现，或者由于PPVPN用户自我管理界面中的VPN间隔离不足而导致的意外后果。（前者不一定是特定于PPVPN的问题。）
4.2.3. Social Engineering Attacks on Service Provider Infrastructure
4.2.3. 对服务提供商基础设施的社会工程攻击
Attacks in which the service provider network is reconfigured or damaged, or in which confidential information is improperly disclosed, may be mounted through manipulation of service provider personnel. These types of attacks are PPVPN-specific if they affect PPVPN-serving mechanisms. It may be observed that the organizational split (customer, service provider) that is inherent in PPVPNs may make it easier to mount such attacks against provider-provisioned
服务提供商网络被重新配置或损坏，或机密信息被不当披露的攻击可能通过操纵服务提供商人员进行。如果这些类型的攻击影响PPVPN服务机制，则它们是特定于PPVPN的。可以观察到，PPVPN中固有的组织分裂（客户、服务提供商）可能更容易对提供的提供商发起此类攻击
VPNs than against VPNs that are self-provisioned by the customer at the IP layer.
与客户在IP层自行配置的VPN相比，VPN更具优势。
This refers to events where expected isolation between separate PPVPNs is breached. This includes cases such as:
这是指违反单独PPVPN之间预期隔离的事件。这包括以下情况：
- a site being connected into the "wrong" VPN,
- 连接到“错误”VPN的站点，
- two or more VPNs being improperly merged,
- 两个或多个VPN未正确合并，
- a point-to-point VPN connecting the wrong two points, or
- 连接错误两点的点对点VPN，或
- any packet or frame being improperly delivered outside the VPN it is sent in.
- 任何数据包或帧被不正确地传送到它所发送的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 (improper device configuration).
VPN的错误连接或交叉连接可能由服务提供商或设备供应商的错误或攻击者的恶意行为造成。该漏洞可能是物理（例如，PE-CE链路连接错误）或逻辑（设备配置不当）。
Anecdotal evidence suggests that the cross-connection threat is one of the largest security concerns of PPVPN users (or would-be users).
传闻证据表明，交叉连接威胁是PPVPN用户（或潜在用户）最大的安全问题之一。
This encompasses attacks against routing protocols that are run by the service provider and that directly support the PPVPN service. In layer 3 VPNs this, typically relates to membership discovery or to the distribution of per-VPN routes. In layer 2 VPNs, this typically relates to membership and endpoint discovery. Attacks against the use of routing protocols for the distribution of backbone (non-VPN) routes are beyond the scope of this document. Specific attacks against popular routing protocols have been widely studied and are described in [RFC3889].
这包括针对由服务提供商运行并直接支持PPVPN服务的路由协议的攻击。在第3层VPN中，这通常与成员身份发现或每个VPN路由的分布有关。在第2层VPN中，这通常与成员资格和端点发现有关。针对使用路由协议分发主干（非VPN）路由的攻击超出了本文档的范围。针对流行路由协议的特定攻击已被广泛研究，并在[RFC3889]中进行了描述。
"Route separation" refers here to keeping the per-VPN topology and reachability information for each PPVPN separate from, and unavailable to, any other PPVPN (except as specifically intended by the service provider). This concept is only a distinct security concern for layer-3 VPN types for which the service provider is involved with the routing within the VPN (i.e., VR, BGP-MPLS, routed version of IPsec). A breach in the route separation can reveal topology and addressing information about a PPVPN. It can also cause
“路由分离”是指将每个PPVPN的每VPN拓扑和可达性信息与任何其他PPVPN分开，并且不可用于任何其他PPVPN（服务提供商特别指定的情况除外）。对于服务提供商参与VPN内路由的第3层VPN类型（即VR、BGP-MPLS、IPsec路由版本），此概念只是一个明显的安全问题。路由分离中的漏洞可以揭示PPVPN的拓扑和寻址信息。它还可能导致
black hole routing or unauthorized data plane cross-connection between PPVPNs.
PPVPN之间的黑洞路由或未经授权的数据平面交叉连接。
In layer-3 VPNs, the IP address spaces of different VPNs have to be kept separate. In layer-2 VPNs, the MAC address and VLAN spaces of different VPNs have to be kept separate. A control plane breach in this addressing separation may result in unauthorized data plane cross-connection between VPNs.
在第三层VPN中，不同VPN的IP地址空间必须保持分离。在第二层VPN中，不同VPN的MAC地址和VLAN空间必须分开。此寻址分离中的控制平面违规可能导致VPN之间未经授权的数据平面交叉连接。
Besides routing and management protocols (covered separately in the previous sections), a number of other control protocols may be directly involved in delivering the PPVPN service (e.g., for membership discovery and tunnel establishment in various PPVPN approaches). These include but may not be limited to:
除了路由和管理协议（在前面的章节中单独介绍）之外，许多其他控制协议可能直接参与PPVPN服务的交付（例如，用于各种PPVPN方法中的成员发现和隧道建立）。这些包括但不限于：
- MPLS signaling (LDP, RSVP-TE), - IPsec signaling (IKE) , - L2TP, - BGP-based membership discovery, and - Database-based membership discovery (e.g., RADIUS-based).
- MPLS信令（LDP、RSVP-TE）、IPsec信令（IKE）、L2TP、基于BGP的成员身份发现和基于数据库的成员身份发现（例如，基于RADIUS的）。
Attacks might subvert or disrupt the activities of these protocols, for example, via impersonation or DoS attacks.
攻击可能会破坏或破坏这些协议的活动，例如，通过模拟或DoS攻击。
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 PPVPN implementations. The PPVPN provider should determine the applicability of these techniques to the provider's specific service offerings, and the PPVPN user may wish to assess the value of these techniques in regard to the user's VPN requirements.
本文档中讨论的防御技术旨在描述解决某些安全威胁的方法。它们不是所有PPVPN实现的要求。PPVPN提供商应确定这些技术对提供商特定服务产品的适用性，PPVPN用户可能希望评估这些技术在用户VPN需求方面的价值。
The techniques discussed here include encryption, authentication, filtering, firewalls, access control, isolation, aggregation, and other techniques.
这里讨论的技术包括加密、身份验证、过滤、防火墙、访问控制、隔离、聚合和其他技术。
Nothing is ever 100% secure. Defense therefore protects against those attacks that are most likely to occur or that could have the most dire consequences. Absolute protection against these attacks is seldom achievable; more often it is sufficient to make the cost of a successful attack greater than what the adversary would be willing to expend.
没有什么是百分之百安全的。因此，防御可以防止最有可能发生或可能产生最可怕后果的攻击。对这些攻击的绝对保护很少能够实现；更常见的情况是，使成功攻击的成本高于对手愿意花费的成本就足够了。
Successful defense against an attack does not necessarily mean that 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 non-authentic 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 PPVPN user's system. The latter is frequently a much easier task.
成功防御攻击并不一定意味着必须阻止攻击发生或到达目标。在许多情况下，网络可以设计为抵御攻击。例如，可以通过首先阻止引入非真实数据包，或者通过在将其交付到PPVPN用户系统之前识别并消除它们来防止引入非真实数据包。后者通常是一项容易得多的任务。
PPVPN defenses against a wide variety of attacks can be enhanced by the proper application of cryptographic techniques. These are the same cryptographic techniques that are applicable to general network communications. In general, these techniques can provide confidentiality (encryption) of communication between devices, authentication of the identities of the devices, and detection of a change of the protected data during transit.
通过正确应用密码技术，可以增强PPVPN对各种攻击的防御能力。这些加密技术与适用于一般网络通信的加密技术相同。通常，这些技术可以提供设备之间通信的机密性（加密）、设备身份的认证以及在传输期间检测受保护数据的变化。
Privacy is a key part (the middle name!) of any Virtual Private Network. In a PPVPN, privacy can be provided by two mechanisms: traffic separation and encryption. This section focuses on encryption; traffic separation is addressed separately.
隐私是任何虚拟专用网络的关键部分（中间名！）。在PPVPN中，隐私可以通过两种机制提供：流量分离和加密。本节重点介绍加密；交通隔离是分开处理的。
Several aspects of authentication are addressed in some detail in a separate "Authentication" section.
身份验证的几个方面在单独的“身份验证”部分中进行了详细说明。
Encryption adds complexity, and thus it may not be a standard offering within every PPVPN service. There are a few reasons for this. Encryption adds an additional computational burden to the devices performing encryption and decryption. This may reduce the number of user VPN 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 the device configuration and adds incremental labor cost. Encrypting packets typically increases packet lengths, thereby increasing the network traffic load and the likelihood of packet fragmentation, with its increased overhead. (Packet length increase can often be mitigated to some extent by data compression techniques, but with additional computational burden.) Finally, some PPVPN providers may employ enough other defensive techniques, such as physical isolation or filtering/firewall techniques, that they may not perceive additional benefit from encryption techniques.
加密增加了复杂性，因此它可能不是每个PPVPN服务中的标准产品。这有几个原因。加密为执行加密和解密的设备增加了额外的计算负担。这可能会减少可在设备上处理的用户VPN连接的数量，或者以其他方式减少设备的容量，从而可能会推高提供商的成本。通常，在设备上配置加密服务会增加设备配置的复杂性，并增加劳动力成本。加密数据包通常会增加数据包长度，从而增加网络流量负载和数据包碎片的可能性，同时增加开销。（数据压缩技术通常可以在一定程度上缓解数据包长度的增加，但会带来额外的计算负担。）最后，一些PPVPN提供商可能会采用足够多的其他防御技术，如物理隔离或过滤/防火墙技术，以使他们不会从加密技术中获得额外的好处。
The trust model among the PPVPN user, the PPVPN provider, and other parts of the network is a key element in determining the applicability of encryption for any specific PPVPN implementation.
PPVPN用户、PPVPN提供商和网络其他部分之间的信任模型是确定加密是否适用于任何特定PPVPN实现的关键因素。
In particular, it determines where encryption should be applied, as follows.
特别是，它决定了加密应该应用于何处，如下所示。
- If the data path between the user's site and the provider's PE is not trusted, then encryption 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 provider networks, then the PE-PE traffic may be encrypted.
- 如果骨干网络的某个部分不可信，特别是在流量可能通过互联网或多个提供商网络传输的实现中，则PE-PE流量可能被加密。
- If the PPVPN user does not trust any zone outside of its premises, it may require end-to-end or CE-CE encryption service. This service fits within the scope of this PPVPN security framework when the CE is provisioned by the PPVPN provider.
- 如果PPVPN用户不信任其场所外的任何区域，则可能需要端到端或CE-CE加密服务。当PPVPN提供商提供CE时，此服务符合此PPVPN安全框架的范围。
- If the PPVPN user requires remote access to a PPVPN from a system that is not at a PPVPN customer location (for example, access by a traveler), there may be a requirement for encrypting the traffic between that system and an access point on the PPVPN or at a customer site. If the PPVPN provider provides 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 implemented by using encryption, as well.
- 如果PPVPN用户需要从不在PPVPN客户位置的系统远程访问PPVPN（例如，由旅行者访问），则可能需要加密该系统与PPVPN或客户站点上的接入点之间的通信量。如果PPVPN提供商提供接入点，则客户必须与提供商合作，为远程用户处理访问控制服务。这些访问控制服务通常也通过使用加密来实现。
Although CE-CE encryption provides confidentiality against third-party interception, if the PPVPN 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 VPN traffic or internal network. Encryption devices can potentially be configured to use null encryption, to bypass encryption processing altogether, or to provide some means of sniffing or diverting unencrypted traffic. Thus, a PPVPN implementation using CE-CE encryption has to consider the trust relationship between the PPVPN user and provider. PPVPN users and providers may wish to negotiate a service level agreement (SLA) for CE-CE encryption that will provide an acceptable demarcation of responsibilities for management of encryption on the CE devices.
尽管CE-CE加密提供了针对第三方拦截的保密性，但如果PPVPN提供商对CE（加密）设备具有完全的管理控制，则提供商可能获得对用户VPN流量或内部网络的访问权。加密设备可能被配置为使用空加密，完全绕过加密处理，或者提供一些嗅探或转移未加密流量的方法。因此，使用CE-CE加密的PPVPN实现必须考虑PPVPN用户和提供商之间的信任关系。PPVPN用户和提供商可能希望协商CE-CE加密的服务级别协议（SLA），该协议将为CE设备上的加密管理提供可接受的责任划分。
The demarcation may also be affected by the capabilities of the CE devices. For example, the CE might support some partitioning of management or a configuration lock-down ability, or it might allow both parties to verify the configuration. In general, if the managed CE-CE model is used, the PPVPN user has to have a fairly high level of trust that the PPVPN provider will properly provision and manage the CE devices.
标定也可能受到CE设备能力的影响。例如，CE可能支持一些管理分区或配置锁定功能，或者它可能允许双方验证配置。通常，如果使用托管CE-CE模型，PPVPN用户必须对PPVPN提供商将正确提供和管理CE设备具有相当高的信任度。
IPsec [RFC2401] [RFC2402] [RFC2406] [RFC2407] [RFC2411] is the security protocol of choice for encryption at the IP layer (Layer 3), as discussed in [RFC3631]. IPsec provides robust security for IP traffic between pairs of devices. Non-IP traffic must be converted to IP packets, or it cannot be transported over IPsec. Encapsulation is a common conversion method.
IPsec[RFC2401][RFC2402][RFC2406][RFC2407][RFC2411]是IP层（第3层）加密的首选安全协议，如[RFC3631]所述。IPsec为成对设备之间的IP通信提供了强大的安全性。非IP通信必须转换为IP数据包，否则无法通过IPsec传输。封装是一种常见的转换方法。
In the PPVPN 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. The user-provisioned CE-CE IPsec model is outside the scope of this document and outside the scope of the PPVPN Working Group. Likewise, data encryption that is performed within the user's site is outside the scope of this document, as it is simply handled as user data by the PPVPN. IPsec can also be used to protect IP traffic between a remote user and the PPVPN.
在PPVPN模型中，IPsec可用于保护PE之间、PE和CE之间或从CE到CE之间的IP流量。CE到CE IPsec可以在提供者提供的模型或用户提供的模型中使用。用户提供的CE-CE IPsec模型不在本文档的范围内，也不在PPVPN工作组的范围内。同样，在用户站点内执行的数据加密不在本文档的范围内，因为PPVPN仅将其作为用户数据处理。IPsec还可用于保护远程用户和PPVPN之间的IP通信。
IPsec does not itself specify an encryption algorithm. It can use a variety of encryption algorithms with various key lengths, such as AES encryption. 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 order to assess the level of security offered by a particular IPsec-based PPVPN service, some PPVPN users may wish to know the specific encryption algorithm and effective key length used by the PPVPN provider. However, in practice, any currently recommended IPsec encryption offers enough security to substantially reduce the likelihood of being directly targeted by an attacker. Other, weaker, links in the chain of security are likely to be attacked first. PPVPN users may wish to use a Service Level Agreement (SLA) specifying the service provider's responsibility for ensuring data confidentiality rather than to analyze the specific encryption techniques used in the PPVPN service.
IPsec本身不指定加密算法。它可以使用各种密钥长度的加密算法，如AES加密。密钥长度、计算负担和加密的安全级别之间存在权衡。对这些权衡的全面讨论超出了本文件的范围。为了评估特定基于IPsec的PPVPN服务提供的安全级别，一些PPVPN用户可能希望了解PPVPN提供商使用的特定加密算法和有效密钥长度。然而，在实践中，任何当前推荐的IPsec加密都提供了足够的安全性，从而大大降低了被攻击者直接攻击的可能性。安全链中其他较弱的环节可能首先受到攻击。PPVPN用户可能希望使用服务级别协议（SLA），指定服务提供商确保数据机密性的责任，而不是分析PPVPN服务中使用的特定加密技术。
For many of the PPVPN provider's network control messages and some PPVPN user requirements, cryptographic authentication of messages without encryption of the contents of the message may provide acceptable security. With IPsec, authentication of messages is provided by the Authentication Header (AH) or by the Encapsulating Security Protocol (ESP) with authentication only. Where control messages require authentication but do not use IPsec, other cryptographic authentication methods are 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].
对于许多PPVPN提供商的网络控制消息和一些PPVPN用户需求，在不加密消息内容的情况下对消息进行加密身份验证可以提供可接受的安全性。使用IPsec，消息的身份验证由身份验证头（AH）或仅通过身份验证的封装安全协议（ESP）提供。如果控制消息需要身份验证但不使用IPsec，则可以使用其他加密身份验证方法。当前被认为是安全的消息认证方法基于使用安全哈希算法（如安全哈希算法1（SHA-1）[RFC3174]实现的哈希消息认证码（HMAC）[RFC2104]。
One recommended mechanism for providing a combination confidentiality, data origin authentication, and connectionless integrity is the use of AES in Cipher Block Chaining (CBC) Mode, with an explicit Initialization Vector (IV) [RFC3602], as the IPsec ESP.
提供组合机密性、数据源身份验证和无连接完整性的一种推荐机制是在密码块链接（CBC）模式下使用AES，并带有一个明确的初始化向量（IV）[RFC3602]，如IPsec ESP。
PPVPNs that provide differentiated services based on traffic type may encounter some conflicts with IPsec encryption of traffic. As 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.
基于流量类型提供区分服务的PPVPN可能会与IPsec流量加密发生冲突。由于加密隐藏了数据包的内容，因此可能无法以与未加密流量相同的方式区分加密流量。尽管DiffServ标记被复制到IPsec报头并可以提供一些区别，但并不是所有的流量类型都可以通过这种机制来适应。
For configuration and management of PPVPN devices, encryption and authentication of the management connection at a level comparable to that provided by IPsec is desirable.
对于PPVPN设备的配置和管理，需要在与IPsec提供的级别相当的级别上对管理连接进行加密和身份验证。
Several methods of transporting PPVPN device management traffic offer security and confidentiality.
传输PPVPN设备管理流量的几种方法提供了安全性和保密性。
- Secure Shell (SSH) offers protection for TELNET [STD8] or terminal-like connections to allow device configuration.
- Secure Shell（SSH）为TELNET[STD8]或类似终端的连接提供保护，以允许设备配置。
- SNMP v3 [STD62] provides encrypted and authenticated protection for SNMP-managed devices.
- SNMP v3[STD62]为SNMP管理的设备提供加密和身份验证保护。
- Transport Layer Security (TLS) [RFC2246] 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）[RFC2246]和密切相关的安全套接字层（SSL）广泛用于保护基于HTTP的通信，因此可以支持大多数基于XML和SOAP的设备管理方法。
- As of 2004, extensive work is proceeding in several organizations (OASIS, W3C, WS-I, and others) on securing device management traffic within a "Web Services" framework. This work uses a wide variety of security models and supports multiple security token formats, multiple trust domains, multiple signature formats, and multiple encryption technologies.
- 截至2004年，多个组织（OASIS、W3C、WS-I和其他组织）正在进行大量工作，以在“Web服务”框架内保护设备管理流量。这项工作使用了多种安全模型，并支持多种安全令牌格式、多种信任域、多种签名格式和多种加密技术。
- IPsec provides the services with security and confidentiality at the network layer. With regard to device management, its current use is primarily focused on in-band management of user-managed IPsec gateway devices.
- IPsec在网络层为服务提供安全性和机密性。关于设备管理，其当前用途主要集中于用户管理的IPsec网关设备的带内管理。
Layer-2 PPVPNs will generally not be able to use IPsec to provide encryption throughout the entire network. They may be able to use IPsec for PE-PE traffic where it is encapsulated in IP packets, but IPsec will generally not be applicable for CE-PE traffic in Layer-2 PPVPNs.
第2层PPVPN通常无法使用IPsec在整个网络中提供加密。他们可能能够将IPsec用于封装在IP数据包中的PE-PE通信，但IPsec通常不适用于第2层PPVPN中的CE-PE通信。
Encryption techniques for Layer-2 links are widely available but are not within the scope of this document or IETF documents in general. Layer-2 encryption could be applied to the links from CE to PE, or it could be applied from CE to CE, as long as the encrypted Layer-2 packets can be handled properly by the intervening PE devices. In addition, the upper-layer traffic transported by the Layer-2 VPN can be encrypted by the user. In this case, confidentiality will be maintained; however, this is transparent to the PPVPN provider and is outside the scope of this document.
第2层链路的加密技术广泛可用，但一般不在本文件或IETF文件的范围内。第2层加密可以应用于从CE到PE的链路，也可以应用于从CE到CE的链路，只要加密的第2层数据包可以由介入的PE设备正确处理。此外，用户还可以对第二层VPN传输的上层流量进行加密。在这种情况下，将保持机密性；但是，这对PPVPN提供商是透明的，不在本文档的范围之内。
In PPVPNs, encryption could potentially be applied to the VPN traffic at several different places. This section discusses some of the tradeoffs in implementing encryption in several different connection topologies among different devices within a PPVPN.
在PPVPN中，加密可能应用于多个不同位置的VPN流量。本节讨论在PPVPN内的不同设备之间以几种不同连接拓扑实现加密时的一些折衷。
Encryption typically involves a pair of devices that encrypt the traffic passing between them. The devices may be directly connected (over a single "hop"), or there may be intervening devices that transport the encrypted traffic between the pair of devices. The extreme cases involve hop-by-hop encryption between every adjacent pair of devices along a given path or "end-to-end" encryption only between the end devices along a given path. To keep this discussion within the scope of PPVPNs, we consider the "end to end" case to be CE to CE rather than fully end to end.
加密通常涉及一对设备，对它们之间传递的流量进行加密。这些设备可以直接连接（通过单个“跃点”），或者可能存在在这对设备之间传输加密流量的中间设备。极端情况涉及沿给定路径的每对相邻设备之间的逐跳加密或仅沿给定路径的端设备之间的“端到端”加密。为了保持这种讨论在PPVPNS的范围内，我们认为“端到端”的情况是CE到CE，而不是完全结束。
Figure 2 depicts a simplified PPVPN topology, showing the Customer Edge (CE) devices, the Provider Edge (PE) devices, and a variable number (three are shown) of Provider core (P) devices that might be present along the path between two sites in a single VPN, operated by a single service provider (SP).
图2描述了一个简化的PPVPN拓扑，显示了客户边缘（CE）设备、提供商边缘（PE）设备和可变数量（显示了三个）的提供商核心（P）设备，这些设备可能位于单个VPN中两个站点之间的路径上，由单个服务提供商（SP）操作。
Site_1---CE---PE---P---P---P---PE---CE---Site_2
Site_1---CE---PE---P---P---P---PE---CE---Site_2
Figure 2: Simplified PPVPN topology
图2：简化的PPVPN拓扑
Within this simplified topology and assuming that P devices are not to be involved with encryption, there are four basic feasible configurations for implementing encryption on connections among the devices:
在这个简化的拓扑结构中，假设P设备不涉及加密，则有四种基本的可行配置用于在设备之间的连接上实现加密：
1) Site-to-site (CE-to-CE): Encryption can be configured between the two CE devices, so that traffic will be encrypted throughout the SP's network.
1) 站点到站点（CE到CE）：可以在两个CE设备之间配置加密，以便在整个SP网络中对流量进行加密。
2) Provider edge-to-edge (PE-to-PE): Encryption can be configured between the two PE devices. Unencrypted traffic is received at one PE from the customer's CE; then it is encrypted for transmission through the SP's network to the other PE, where it is decrypted and sent to the other CE.
2) 提供商边缘到边缘（PE到PE）：可以在两个PE设备之间配置加密。在一个PE接收来自客户CE的未加密流量；然后对其进行加密，以便通过SP的网络传输到另一个PE，在那里对其进行解密并发送到另一个CE。
3) Access link (CE-to-PE): Encryption can be configured between the CE and PE, on each side (or on only one side).
3) 接入链路（CE到PE）：可以在CE和PE之间的每一侧（或仅在一侧）配置加密。
4) Configurations 2) and 3) can be combined, with encryption running from CE to PE, then from PE to PE, and then from PE to CE.
4) 配置2）和3）可以结合使用，加密从CE运行到PE，然后从PE运行到PE，然后从PE运行到CE。
Among the four feasible configurations, key tradeoffs in considering encryption include the following:
在四种可行的配置中，考虑加密时的密钥权衡包括：
- Vulnerability to link eavesdropping: Assuming that an attacker can observe the 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 Nce, the number of sites per VPN customer, and Npe, the number of PEs participating in a given VPN, how many device configurations have to be created or maintained and how do those configurations scale?
- 设备配置和管理的复杂性：给定Nce、每个VPN客户的站点数量和Npe、参与给定VPN的PE数量、必须创建或维护多少设备配置以及这些配置如何扩展？
- Processing load on devices: How many encryption or decryption operations must be done, given P packets? This influences considerations of device capacity and perhaps end-to-end delay.
- 设备上的处理负载：给定P数据包，必须执行多少加密或解密操作？这会影响对设备容量和端到端延迟的考虑。
- Ability of SP to provide enhanced services (QoS, firewall, intrusion detection, etc.): Can the SP inspect the data in order to provide these services?
- SP提供增强服务（QoS、防火墙、入侵检测等）的能力：SP能否检查数据以提供这些服务？
These tradeoffs are discussed below for each configuration.
下面将讨论每种配置的这些权衡。
1) Site-to-site (CE-to-CE) Configurations
1) 站点到站点（CE到CE）配置
o Link eavesdropping: Protected on all links.
o 链接窃听：在所有链接上受保护。
o Device compromise: Vulnerable to CE compromise.
o 设备损坏：易受CE损坏。
o Complexity: Single administration, responsible for one device per site (Nce devices), but overall configuration per VPN scales as Nce**2.
o 复杂性：单一管理，每个站点负责一个设备（Nce设备），但每个VPN的总体配置可扩展为Nce**2。
o Processing load: on each of two CEs, each packet is either encrypted or decrypted (2P).
o 处理负载：在两个CE中的每一个上，每个数据包要么被加密，要么被解密（2P）。
o Enhanced services: Severely limited; typically only DiffServ markings are visible to SP, allowing some QoS services.
o 强化服务：严重受限；通常，SP只能看到DiffServ标记，从而允许某些QoS服务。
2) Provider edge-to-edge (PE-to-PE) Configurations
2) 提供程序边缘到边缘（PE到PE）配置
o Link eavesdropping: Vulnerable on CE-PE links; protected on SP's network links.
o 链路窃听：CE-PE链路易受攻击；在SP的网络链接上受保护。
o Device compromise: Vulnerable to CE or PE compromise.
o 设备危害：易受CE或PE危害。
o Complexity: Single administration; Npe devices to configure. (Multiple sites may share a PE device, so Npe is typically much less than Nce.) Scalability of the overall configuration depends on the PPVPN type: If the encryption is separate per VPN context, it scales as Npe**2 per customer VPN. If the encryption is per PE, it scales as Npe**2 for all customer VPNs combined.
o 复杂性：单一管理；要配置的Npe设备。（多个站点可能共享一个PE设备，因此Npe通常比Nce小得多。）总体配置的可扩展性取决于PPVPN类型：如果加密在每个VPN上下文中是独立的，则其扩展为每个客户VPN的Npe**2。如果加密为每PE，则对于所有客户VPN组合，其扩展为Npe**2。
o Processing load: On each of two PEs, each packet is either encrypted or decrypted (2P).
o 处理负载：在两个PE中的每一个上，每个数据包要么被加密，要么被解密（2P）。
o Enhanced services: Full; SP can apply any enhancements based on detailed view of traffic.
o 加强服务：全面服务；SP可以根据流量的详细视图应用任何增强功能。
3) Access link (CE-to-PE) Configuration
3) 接入链路（CE到PE）配置
o Link eavesdropping: Protected on CE-PE link; vulnerable on SP's network links.
o 链路窃听：受CE-PE链路保护；SP的网络链接上存在漏洞。
o Device compromise: Vulnerable to CE or PE compromise.
o 设备危害：易受CE或PE危害。
o Complexity: Two administrations (customer and SP) with device configuration on each side (Nce + Npe devices to configure), but as there is no mesh, the overall configuration scales as Nce.
o 复杂性：两个管理（客户和SP），每侧都有设备配置（要配置的是Nce+Npe设备），但由于没有网格，因此总体配置按Nce扩展。
o Processing load: On each of two CEs, each packet is either encrypted or decrypted. On each of two PEs, each packet is either encrypted or decrypted (4P).
o 处理负载：在两个CE中的每一个上，每个数据包要么被加密，要么被解密。在两个PEs中的每一个上，每个数据包要么被加密，要么被解密（4P）。
o Enhanced services: Full; SP can apply any enhancements based on detailed view of traffic.
o 加强服务：全面服务；SP可以根据流量的详细视图应用任何增强功能。
4) Combined Access link and PE-to-PE (essentially hop-by-hop).
4) 组合接入链路和PE到PE（基本上是逐跳）。
o Link eavesdropping: Protected on all links.
o 链接窃听：在所有链接上受保护。
o Device compromise: Vulnerable to CE or PE compromise.
o 设备危害：易受CE或PE危害。
o 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 encryption is separate per VPN context, it scales as Npe**2 per customer VPN. If the encryption is per-PE, it scales as Npe**2 for all customer VPNs combined.
o 复杂性：两个管理（客户和SP），每侧都有设备配置（需要配置Nce+Npe设备）。总体配置的可伸缩性取决于PPVPN类型。如果加密在每个VPN上下文中是独立的，那么它将按每个客户VPN扩展为Npe**2。如果加密为每PE，则对于所有客户VPN组合，其扩展为Npe**2。
o Processing load: On each of two CEs, each packet is either encrypted or decrypted. On each of two PEs, each packet is both encrypted and decrypted (6P).
o 处理负载：在两个CE中的每一个上，每个数据包要么被加密，要么被解密。在两个PE中的每一个上，每个数据包都被加密和解密（6P）。
o Enhanced services: Full; SP can apply any enhancements based on detailed view of traffic.
o 加强服务：全面服务；SP可以根据流量的详细视图应用任何增强功能。
Given the tradeoffs discussed above, a few conclusions can be reached.
鉴于以上讨论的权衡，可以得出一些结论。
- Configurations 2 and 3, which are subsets of 4, may be appropriate alternatives to 4 under certain threat models. The remainder of these conclusions compare 1 (CE-to-CE) with 4 (combined access links and PE-to-PE).
- 配置2和3是4的子集，在某些威胁模型下可能是4的合适替代方案。这些结论的其余部分将1（CE对CE）与4（组合接入链路和PE对PE）进行比较。
- If protection from link eavesdropping is most 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 best.
- 如果保护设备免受危害是最重要的，并且威胁是对CE设备的，则这两种情况是等效的；如果威胁是针对PE设备，则配置1是最佳配置。
- If reducing complexity is most important and the size of the network is very small, configuration 1 is the best. Otherwise, the comparison between options 1 and 4 is relatively complex , based on a number of issues such as, how close the CE to CE communication is to a full mesh, and what tools are used for key management. Option 1 requires configuring keys for each CE-CE
- 如果降低复杂性是最重要的，并且网络的大小非常小，那么配置1是最好的。否则，选项1和选项4之间的比较相对复杂，这取决于一系列问题，如CE-to-CE通信距离完整网格有多近，以及密钥管理使用了哪些工具。选项1要求为每个CE-CE配置密钥
pair that is communicating directly. Option 4 requires configuring keys on both CE and PE devices but may offer benefit from the fact that the number of PEs is generally much smaller than the number of CEs.
直接通信的一对。选项4要求在CE和PE设备上配置密钥，但由于PE的数量通常比CE的数量小得多，因此可能会带来好处。
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 characteristics 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. Furthermore, with option 4, the impact of operational error may be significantly increased.
此外，在某些PPVPN方法下，通过在所有VPN上下文中共享相同的PE-PE网格，4的可扩展性得到进一步改进。如果CE设备比PE设备更易于配置，则在任何给定情况下，4的缩放特性可以增加或减少，反之亦然。此外，使用选项4，操作错误的影响可能会显著增加。
- If the overall processing load is a key factor, then 1 is best.
- 如果总体处理负载是一个关键因素，那么1是最好的。
- If the availability of enhanced services support from the SP is most important, then 4 is best.
- 如果SP提供的增强服务支持是最重要的，那么4是最好的。
As a quick overall conclusion, CE-to-CE encryption provides greater protection against device compromise, but it comes at the cost of enhanced services and with additional operational complexity due to the Order(n**2) scaling of the mesh.
作为一个快速的总体结论，CE-to-CE加密提供了更大的保护，以防止设备受损，但它以增强服务为代价，并且由于网格的顺序（n**2）缩放而增加了操作复杂性。
This analysis of site-to-site vs. hop-by-hop encryption tradeoffs does not explicitly include cases where multiple providers cooperate to provide a PPVPN service, public Internet VPN connectivity, or remote access VPN service, but many of the tradeoffs will be similar.
对站点到站点与逐跳加密权衡的分析并未明确包括多个提供商合作提供PPVPN服务、公共互联网VPN连接或远程访问VPN服务的情况，但许多权衡将是类似的。
In order to prevent security issues from some denial-of-service attacks or from malicious misconfiguration, it is critical that devices in the PPVPN should only accept connections or control messages from valid sources. Authentication refers to methods for ensuring that message sources are properly identified by the PPVPN devices with which they communicate. This section focuses on identifying the scenarios in which sender authentication is required, and it recommends authentication mechanisms for these scenarios.
为了防止安全问题受到某些拒绝服务攻击或恶意错误配置的影响，PPVPN中的设备应仅接受来自有效来源的连接或控制消息，这一点至关重要。认证指的是确保消息源由与其通信的PPVPN设备正确标识的方法。本节重点介绍需要发送方身份验证的场景，并为这些场景推荐身份验证机制。
Cryptographic techniques (authentication 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 processing required to decrypt or check authentication may in some cases increase the effect of these resource exhaustion attacks. Cryptographic techniques may, however, be useful against resource exhaustion attacks based on exhaustion of state information (e.g., TCP SYN attacks).
加密技术（身份验证和加密）无法抵御某些类型的拒绝服务攻击，特别是基于CPU或带宽耗尽的资源耗尽攻击。事实上，解密或检查身份验证所需的处理在某些情况下可能会增加这些资源耗尽攻击的效果。然而，密码技术可能对基于状态信息耗尽的资源耗尽攻击（例如，TCP SYN攻击）有用。
This category includes techniques for the CEs to verify that they are connected to the expected VPN. It includes techniques for CE-PE authentication, to verify that each specific CE and PE is actually communicating with its expected peer.
此类别包括CEs验证其是否连接到预期VPN的技术。它包括CE-PE身份验证技术，以验证每个特定CE和PE是否实际与其预期对等方通信。
Management system authentication includes the authentication of a PE to a centrally-managed directory server when directory-based "auto-discovery" is used. It also includes authentication of a CE to its PPVPN configuration server when a configuration server system is used.
管理系统身份验证包括在使用基于目录的“自动发现”时，PE对集中管理的目录服务器的身份验证。当使用配置服务器系统时，它还包括CE对其PPVPN配置服务器的身份验证。
Peer-to-peer authentication includes peer authentication for network control protocols (e.g., LDP, BGP), and other peer authentication (i.e., authentication of one IPsec security gateway by another).
对等身份验证包括网络控制协议的对等身份验证（例如，LDP、BGP）和其他对等身份验证（例如，一个IPsec安全网关对另一个IPsec安全网关的身份验证）。
This section describes methods for authentication of remote access users connecting to a VPN.
本节介绍连接到VPN的远程访问用户的身份验证方法。
Effective authentication of individual connections is a key requirement for enabling remote access to a PPVPN from an arbitrary Internet address (for instance, by a traveler).
个人连接的有效身份验证是从任意互联网地址（例如，由旅行者）远程访问PPVPN的关键要求。
There are several widely used standards-based protocols to support remote access authentication. These include RADIUS [RFC2865] and DIAMETER [RFC3588]. Digital certificate systems also provide authentication. In addition, there has been extensive development and deployment of mechanisms for securely transporting individual remote access connections within tunneling protocols, including L2TP [RFC2661] and IPsec.
有几种广泛使用的基于标准的协议支持远程访问身份验证。其中包括半径[RFC2865]和直径[RFC3588]。数字证书系统还提供身份验证。此外，还广泛开发和部署了用于在隧道协议（包括L2TP[RFC2661]和IPsec）内安全传输单个远程访问连接的机制。
Remote access involves connection to a gateway device, which provides access to the PPVPN. The gateway device may be managed by the user at a user site, or by the PPVPN provider at any of several possible locations in the network. The user-managed case is of limited interest within the PPVPN security framework, and it is not considered at this time.
远程访问涉及到与网关设备的连接，网关设备提供对PPVPN的访问。网关设备可以由用户站点上的用户管理，或者由网络中多个可能位置中的任何一个的PPVPN提供商管理。用户管理案例在PPVPN安全框架内的利益有限，目前不予以考虑。
When a PPVPN provider manages authentication at the remote access gateway, this implies that authentication databases, which are usually extremely confidential user-managed systems, will have to be
当PPVPN提供商在远程访问网关上管理身份验证时，这意味着身份验证数据库（通常是高度机密的用户管理系统）将必须
referenced in a secure manner by the PPVPN provider. This can be accomplished through proxy authentication services, which accept an encrypted authentication credential from the remote access user, pass it to the PPVPN user's authentication system, and receive a yes/no response as to whether the user has been authenticated. Thus, the PPVPN provider does not have access to the actual authentication database, but it can use it on behalf of the PPVPN user to provide remote access authentication.
PPVPN提供商以安全的方式引用。这可以通过代理身份验证服务实现，代理身份验证服务接受来自远程访问用户的加密身份验证凭据，将其传递给PPVPN用户的身份验证系统，并接收关于用户是否已通过身份验证的是/否响应。因此，PPVPN提供商无法访问实际的身份验证数据库，但可以代表PPVPN用户使用该数据库来提供远程访问身份验证。
Specific cryptographic techniques for handling authentication are described in the following sections.
处理身份验证的特定加密技术将在以下部分中描述。
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 key systems. Another approach is to use a hierarchical Certificate Authority system to provide digital certificates.
密码技术提供了几种验证设备或个人身份的机制。其中包括使用共享密钥、由附属设备或软件生成的一次性密钥、用户ID和密码对，以及一系列公私密钥系统。另一种方法是使用分层证书颁发机构系统来提供数字证书。
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 operating a PPVPN.
本节描述或提供对身份验证的特定加密方法的参考。这些方法为操作PPVPN所需的大多数身份验证方案提供了安全机制。
Access control techniques include packet-by-packet or packet flow - by - packet flow access control by means of filters and firewalls, as well as by means of admitting a "session" for a control/signaling/management protocol that is being used to implement PPVPNs. Enforcement of access control by isolated infrastructure addresses is discussed elsewhere in this document.
访问控制技术包括通过过滤器和防火墙，以及通过允许用于实现PPVPN的控制/信令/管理协议的“会话”来进行逐包或逐包流访问控制。本文档其他部分讨论了通过隔离的基础结构地址实施访问控制。
We distinguish between filtering and firewalls primarily by the direction of traffic flow. We define filtering as being applicable to unidirectional traffic, whereas a firewall can analyze and control both sides of a conversation.
我们主要根据流量的方向来区分过滤和防火墙。我们将过滤定义为适用于单向流量，而防火墙可以分析和控制会话双方。
There are two significant corollaries of this definition:
这一定义有两个重要的推论：
- 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 then operate upon traffic flowing in one direction without considering traffic in the reverse direction.
- 路由或流量对称性：防火墙通常需要路由对称性，这通常通过定位防火墙来实现，其中网络拓扑确保会话双方都将通过防火墙。然后，过滤器可以对一个方向上的流量进行操作，而不考虑反向的流量。
- Statefulness: Because it receives both sides of a conversation, a firewall may be able to obtain a significant amount of information concerning that conversation and to use this information to control access. A filter can maintain some limited state information on a unidirectional flow of packets, but it cannot determine the state of the bi-directional conversation as precisely as a firewall can.
- 状态性：因为它接收会话的双方，防火墙可能能够获取有关该会话的大量信息，并使用这些信息来控制访问。过滤器可以在单向数据包流上维护一些有限的状态信息，但它不能像防火墙那样精确地确定双向对话的状态。
It is relatively common for routers to filter data 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 that match the criteria associated with a particular filter may be either discarded or given special treatment.
路由器过滤数据包是比较常见的。也就是说，路由器可以在IP或更高级别（例如TCP或UDP）头的某些字段中查找特定值。与特定过滤器相关联的标准相匹配的包可以被丢弃或给予特殊处理。
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 that are applied to packets that match a particular filter.
在讨论过滤器时，将可用于确定数据包是否与过滤器匹配的过滤器特征与应用于与特定过滤器匹配的数据包的数据包动作分开是有用的。
o Filter Characteristics
o 滤波器特性
Filter characteristics 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, on normal forwarding information (such as the next hop for a packet), and on the characteristics 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 address, Protocol field, Fragment Offset, and TOS field. Filters may also consider fields in the TCP or UDP header such as the Port fields and the SYN field in the TCP header.
在许多情况下，过滤器特征可能是无状态的。无状态筛选器仅基于筛选器定义、正常转发信息（例如，数据包的下一跳）以及单个数据包的特征来确定特定数据包是否与筛选器匹配。通常，无状态过滤器可以考虑传入和传出的逻辑或物理接口、IP报头中的信息、以及诸如TCP或UDP报头之类的更高层报头中的信息。例如，要考虑的IP报头中的信息可以包括源和目的IP地址、协议字段、片段偏移量和TOS字段。过滤器还可以考虑TCP或UDP报头中的字段，例如端口字段和TCP报头中的SYN字段。
Stateful filtering maintains packet-specific state information to aid in determining whether a filter has been met. For example, a device might apply stateless filters to the first fragment of a fragmented IP 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.
有状态筛选维护特定于数据包的状态信息，以帮助确定是否满足筛选条件。例如，设备可能会对碎片化IP数据包的第一个片段应用无状态筛选器。如果过滤器匹配，则可以记住数据单元ID，并且可以认为相同分组的其他片段与相同过滤器匹配。状态过滤通常在防火墙中完成，尽管防火墙技术可能会添加到路由器中。
o Actions Based on Filter Results
o 基于筛选结果的操作
If a packet, or a series of packets, match a specific filter, then there are a variety of actions that may be taken based on that filter match. Examples of such actions include:
如果一个数据包或一系列数据包与特定筛选器匹配，则可以根据该筛选器匹配采取多种操作。这些行动的例子包括：
- Discard
- 丢弃
In many cases, filters may be set to catch certain undesirable packets. Examples may include packets with forged or invalid source addresses, packets that are part of a DoS or DDoS attack, or packets that are trying to access forbidden resources (such as network management packets from an unauthorized source). Where such filters are activated, it is common to silently discard the packet or set of packets matching the filter. The discarded packets may also be counted and/or logged, of course.
在许多情况下，可以设置过滤器来捕获某些不需要的数据包。示例可能包括具有伪造或无效源地址的数据包、作为DoS或DDoS攻击一部分的数据包，或试图访问禁止资源的数据包（例如来自未经授权源的网络管理数据包）。在激活此类过滤器的情况下，通常会无声地丢弃与过滤器匹配的数据包或数据包集。当然，也可以对丢弃的分组进行计数和/或记录。
- Set CoS
- 设置CoS
A filter may be used to set the Class of Service associated with the packet.
过滤器可用于设置与分组相关联的服务类别。
- Count Packets and/or Bytes
- 对数据包和/或字节进行计数
- Rate Limit
- 利率限制
In some cases, the set of packets that match a particular filter may be limited to a specified bandwidth. Packets and/or bytes would be counted and forwarded normally up to the specified limit. Excess packets may be discarded or marked (for example, by setting a "discard eligible" bit in the IP ToS field or the MPLS EXP field).
在某些情况下，与特定过滤器匹配的分组集可能被限制在指定的带宽内。数据包和/或字节的计数和转发通常会达到指定的限制。可以丢弃或标记多余的数据包（例如，通过在IP ToS字段或MPLS EXP字段中设置“丢弃合格”位）。
- Forward and Copy
- 转发和复制
It is useful in some cases not only 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 Issues Related to Packet Filters
o 与包过滤器相关的其他问题
There may be a very wide variation in the performance impact of filtering. This may occur both due to differences between implementations, and due to differences between types or numbers
过滤的性能影响可能有很大的差异。这既可能是由于实现之间的差异，也可能是由于类型或数字之间的差异
of filters deployed. For filtering to be useful, the performance of the equipment has to be acceptable in the presence of filters.
部署的过滤器的数量。为了使过滤变得有用，在有过滤器的情况下，设备的性能必须是可接受的。
The precise definition of "acceptable" may vary from service provider to service provider and may depend on the intended use of the filters. For example, for some uses a filter may be turned on all the time in order 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 service provider 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.
“可接受”的准确定义可能因服务提供商而异，并可能取决于过滤器的预期用途。例如，对于某些用途，可始终打开过滤器，以设置CoS、防止攻击或减轻未来可能攻击的影响。在这种情况下，服务提供商可能希望过滤器对性能的影响最小或没有影响。在其他情况下，可能仅在响应重大攻击（如重大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 control over traffic passing between different trusted zones in the PPVPN model, or between a trusted zone and an untrusted zone. Firewalls typically provide much more functionality than filters, as 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 denial-of-service attack protection, virus scanning, or acting as a TCP connection proxy. As with other access control techniques, the value of firewalls depends on a clear understanding of the topologies of the PPVPN 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).
防火墙提供了一种机制，用于控制PPVPN模型中不同受信任区域之间或受信任区域和不受信任区域之间的通信量。防火墙通常比过滤器提供更多的功能，因为它们可以对流而不仅仅是单个数据包应用详细的分析和逻辑功能。它们可能提供多种复杂服务，如阈值驱动的拒绝服务攻击保护、病毒扫描或充当TCP连接代理。与其他访问控制技术一样，防火墙的价值取决于对PPVPN核心网络、用户网络和威胁模型的拓扑结构的清晰理解。它们的有效性取决于具有明确定义的内部（安全）和外部（不安全）的拓扑。
Within the PPVPN framework, traffic typically is not allowed to pass between the various user VPNs. This inter-VPN isolation is usually not performed by a firewall, but it is a part of the basic VPN mechanism. An exception to the total isolation of VPNs is the case of "extranets", which allow specific external access to a user's VPN, potentially from another VPN. Firewalls can be used to provide the services required for secure extranet implementation.
在PPVPN框架内，流量通常不允许在各种用户VPN之间传递。这种VPN间隔离通常不是由防火墙执行的，但它是基本VPN机制的一部分。VPN完全隔离的一个例外是“外部网”，它允许特定的外部访问用户的VPN，可能是从另一个VPN。防火墙可用于提供安全外联网实现所需的服务。
In a PPVPN, firewalls can be applied between the public Internet and user VPNs, in cases where Internet access services are offered by the provider to the VPN user sites. In addition, firewalls may be applied between VPN user sites and any shared network-based services offered by the PPVPN provider.
在PPVPN中，如果提供商向VPN用户站点提供Internet访问服务，则可以在公共Internet和用户VPN之间应用防火墙。此外，可以在VPN用户站点和PPVPN提供商提供的任何共享网络服务之间应用防火墙。
Firewalls may be applied to help protect PPVPN core network functions from attacks originating from the Internet or from PPVPN user sites, but typically other defensive techniques will be used for this purpose.
防火墙可用于帮助保护PPVPN核心网络功能免受来自互联网或PPVPN用户站点的攻击，但通常会为此目的使用其他防御技术。
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, will have 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. As 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.
使用防火墙的另一个考虑因素是，它们可以提供很少的选项来处理携带加密数据的数据包。由于数据本身不可访问，因此只有数据包头信息、其他未加密字段或加密数据包流的分析可用于做出接受或拒绝加密流量的决策。
Most of the security issues related to management interfaces can be addressed through the use of authentication techniques described in the section on authentication. However, additional security may be provided by controlling access to management interfaces in other ways.
与管理接口相关的大多数安全问题都可以通过使用身份验证部分中描述的身份验证技术来解决。然而，可以通过以其他方式控制对管理接口的访问来提供额外的安全性。
Management interfaces, especially console ports on PPVPN devices, may be configured so that they are only accessible out of band, through a system that is physically or logically separated from the rest of the PPVPN infrastructure.
管理接口，特别是PPVPN设备上的控制台端口，可以进行配置，以便它们只能通过物理或逻辑上与PPVPN基础设施的其余部分分离的系统在带外访问。
Where management interfaces are accessible in-band within the PPVPN 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 PPVPN devices themselves.
如果可以在PPVPN域内的带内访问管理接口，则可以使用过滤或防火墙技术来限制未经授权的带内流量访问管理接口。根据设备功能，这些过滤或防火墙技术可以在流量可能通过的其他设备上配置，也可以在单个PPVPN设备上配置。
One way to protect the infrastructure used for support of VPNs is to separate the VPN support resources from the resources used for other purposes (such as support of Internet services). In some cases, this may require the use of physically separate equipment for VPN services, or even a physically separate network.
保护用于支持VPN的基础设施的一种方法是将VPN支持资源与用于其他目的（如支持Internet服务）的资源分开。在某些情况下，这可能需要为VPN服务使用物理上独立的设备，甚至需要物理上独立的网络。
For example, PE-based L3 VPNs may be run on a separate backbone not connected to the Internet, or they may use separate edge routers from those used to support Internet service. Private IP addresses (local to the provider and non-routable over the Internet) are sometimes used to provide additional separation.
例如，基于PE的L3 VPN可以在未连接到Internet的单独主干上运行，或者它们可以使用与用于支持Internet服务的路由器不同的边缘路由器。专用IP地址（提供商本地地址，不可通过Internet路由）有时用于提供额外的隔离。
It is common for CE-based L3VPNs to make use of CE devices that are dedicated to one specific VPN. In many or most cases, CE-based VPNs may make use of normal Internet services to interconnect CE devices.
基于CE的L3VPN通常使用专用于一个特定VPN的CE设备。在许多或大多数情况下，基于CE的VPN可以使用正常的Internet服务来互连CE设备。
In general it is not feasible to use a completely separate set of resources for support of each VPN. One of the main reasons for VPN services is to allow sharing of resources between multiple users, including multiple VPNs. Thus, even if VPN services make use of a separate network from Internet services, there will still be multiple VPN users sharing the same network resources. In some cases, VPN services will share the use of network resources with Internet services or other services.
一般来说，使用一组完全独立的资源来支持每个VPN是不可行的。VPN服务的主要原因之一是允许多个用户（包括多个VPN）之间共享资源。因此，即使VPN服务使用独立于Internet服务的网络，仍然会有多个VPN用户共享相同的网络资源。在某些情况下，VPN服务将与Internet服务或其他服务共享网络资源的使用。
It is therefore important for VPN services to provide protection between resource use by different VPNs. Thus, a well-behaved VPN user should be protected from possible misbehavior by other VPNs. This requires that limits be placed on the amount of resources that can be used by any one VPN. For example, both control traffic and user data traffic may be rate limited. In some cases or in some parts of the network where a sufficiently large number of queues are available, each VPN (and, optionally, each VPN and CoS within the VPN) may make use of a separate queue. Control-plane resources such as link bandwidth and CPU and memory resources may be reserved on a per-VPN basis.
因此，VPN服务必须在不同VPN使用的资源之间提供保护。因此，应保护行为良好的VPN用户免受其他VPN可能的不当行为。这要求限制任何一个VPN可以使用的资源量。例如，控制通信量和用户数据通信量都可以是速率受限的。在某些情况下或在网络的某些部分中，如果有足够多的队列可用，则每个VPN（以及可选地，VPN中的每个VPN和CoS）可以使用单独的队列。控制平面资源，如链路带宽、CPU和内存资源，可以在每个VPN的基础上保留。
The techniques that are used to provision resource protection between multiple VPNs served by the same infrastructure can also be used to protect VPN services from Internet services.
用于在由相同基础设施提供服务的多个VPN之间提供资源保护的技术也可用于保护VPN服务不受Internet服务的影响。
The use of aggregated infrastructure allows the service provider to benefit from stochastic multiplexing of multiple bursty flows and may
聚合基础设施的使用使服务提供商能够从多个突发流的随机多路复用中获益，并且可能
also, in some cases, thwart traffic pattern analysis by combining the data from multiple VPNs.
此外，在某些情况下，通过组合来自多个VPN的数据来阻止流量模式分析。
Deployment of provider-provisioned VPN services requires a relatively large amount of configuration by the service provider. For example, the service provider has 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服务需要服务提供商进行相对大量的配置。例如，服务提供商必须配置每个站点所属的VPN，以及QoS和SLA保证。所需的大量配置可能导致配置错误。
It is important for the service provider 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认证也可用于在错误配置发生时检测错误配置。
This refers to solutions that can readily be tested for correct configuration. For example, for a point-point VPN, checking that the intended connectivity is working largely ensures that there is not connectivity to some unintended site.
这是指可以随时测试正确配置的解决方案。例如，对于点VPN，检查预期连接是否正常工作在很大程度上确保没有连接到某个非预期站点。
A PPVPN service may be subject to attacks from a variety of security threats. Many threats are described in another part 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 silently employing defensive techniques to protect against attacks, PPVPN services can add value for both providers and customers by implementing security-monitoring systems that detect and report on any security attacks that occur, regardless of whether the attacks are effective.
PPVPN服务可能会受到各种安全威胁的攻击。本文档的另一部分描述了许多威胁。本文档和其他地方描述的许多防御技术提供了针对各种威胁的重要防护级别。然而，除了静默地使用防御技术来防范攻击外，PPVPN服务还可以通过实施安全监控系统来为提供商和客户增加价值，该系统可以检测并报告发生的任何安全攻击，而不管攻击是否有效。
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 and their specific targets at an early stage. This knowledge about attackers and targets can be used to further strengthen defenses against specific attacks or attackers, or to improve the defensive services 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 PPVPNs will typically operate by collecting information from 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 specific information exchanged will depend 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 PPVPN devices.
用于检测PPVPN中安全攻击的监控系统通常通过从提供商边缘（PE）、客户边缘（CE）和/或提供商主干（P）设备收集信息来运行。安全监控系统应能够主动从设备检索信息（如SNMP get）或被动从设备接收报告（如SNMP通知）。交换的具体信息将取决于设备的功能和VPN技术的类型。应特别注意保护监控系统和PPVPN设备之间的通信通道。
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 PPVPN 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 allow each attack event to trigger a separate message, which might result in a flood of messages, essentially becoming a denial-of-service attack against the monitoring system or the network.
CE、PE和P设备应采用有效的方法获取和传输安全监控系统所需的信息。重要的是，PPVPN设备和安全监控系统之间的通信方法的设计应确保不会中断网络操作。例如，可以通过单个消息报告多个攻击事件，而不是允许每个攻击事件触发单独的消息，这可能导致大量消息，基本上成为针对监控系统或网络的拒绝服务攻击。
The mechanisms for reporting security attacks should be flexible enough to meet the needs of VPN service providers, VPN customers, and regulatory agencies. The specific reports will 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.
报告安全攻击的机制应足够灵活，以满足VPN服务提供商、VPN客户和监管机构的需求。具体报告将取决于设备的功能、安全监控系统、VPN的类型以及提供商和客户之间的服务级别协议。
This section defines a list of security-related requirements that the users of PPVPN services may have for their PPVPN service. Typically, these translate into requirements for the provider in offering the service.
本节定义了PPVPN服务用户可能对其PPVPN服务具有的安全相关要求的列表。通常，这些转化为对提供服务的提供者的需求。
The following sections detail various requirements that ensure the security of a given trusted zone. Since in real life there are various levels of security, a PPVPN may fulfill any or all of these security requirements. This document does not state that a PPVPN must fulfill all of these requirements to be secure. As mentioned in the Introduction, it is not within the scope of this document to define the specific requirements that each VPN technology must fulfill in order to be secure.
以下各节详细介绍了确保给定受信任区域安全的各种要求。由于现实生活中存在各种级别的安全性，PPVPN可以满足任何或所有这些安全性要求。本文件并未说明PPVPN必须满足所有这些安全要求。如引言中所述，定义每种VPN技术必须满足的特定要求以确保安全不在本文档的范围内。
A virtual private network usually defines "private" as isolation from other PPVPNs and the Internet. More specifically, isolation has several components, which are discussed in the following sections.
虚拟专用网络通常将“专用”定义为与其他PPVPN和Internet隔离。更具体地说，隔离有几个组件，将在以下部分中讨论。
A given PPVPN can use the full Internet address range, including private address ranges [RFC1918], without interfering with other PPVPNs that use PPVPN services from the same service provider(s). When Internet access is provided (e.g., by the same service provider that is offering PPVPN service), NAT functionality may be needed.
给定的PPVPN可以使用完整的Internet地址范围，包括专用地址范围[RFC1918]，而不会干扰使用来自同一服务提供商的PPVPN服务的其他PPVPN。当提供互联网接入时（例如，由提供PPVPN服务的同一服务提供商提供），可能需要NAT功能。
In layer-2 VPNs, the same requirement exists for the layer 2 addressing schemes, such as MAC addresses.
在第二层VPN中，对第二层寻址方案（如MAC地址）也有相同的要求。
A PPVPN core must maintain routing separation between the trusted zones. This means that routing information must not leak from any trusted zone to any other, unless the zones are specifically engineered this way (e.g., for Internet access.)
PPVPN核心必须在受信任区域之间保持路由隔离。这意味着路由信息不得从任何受信任的区域泄漏到任何其他区域，除非这些区域是以这种方式专门设计的（例如，用于互联网访问）
In layer-2 VPNs, the switching information must be kept separate between the trusted zones, so that switching information of one PPVPN does not influence other PPVPNs or the PPVPN core.
在第二层VPN中，交换信息必须在受信任区域之间保持分离，以便一个PPVPN的交换信息不会影响其他PPVPN或PPVPN核心。
Traffic from a given trusted zone must never leave this zone, and traffic from another zone must never enter this zone. Exceptions are made where zones are is specifically engineered that way (e.g., for extranet purposes or Internet access.)
来自给定受信任区域的流量不得离开此区域，来自其他区域的流量不得进入此区域。特殊设计的区域除外（例如，用于外联网或互联网访问）
The common perception is that a completely separated "private" network has defined entry points and is only subject to attack or intrusion over those entry points. By sharing a common core, a PPVPN appears to lose some of these clear interfaces to networks outside the trusted zone. Thus, one of the key security requirements of PPVPN services is that they offer the same level of protection as private networks.
通常的看法是，完全分离的“专用”网络定义了入口点，并且仅在这些入口点上受到攻击或入侵。通过共享一个公共核心，PPVPN似乎失去了一些到受信任区域外网络的清晰接口。因此，PPVPN服务的关键安全要求之一是，它们提供与专用网络相同级别的保护。
An intrusion is defined here as the penetration of a trusted zone from outside. This could be from the Internet, another PPVPN, or the core network itself.
这里的入侵定义为从外部渗透受信任区域。这可能来自互联网、另一个PPVPN或核心网络本身。
The fact that a network is "virtual" must not expose it to additional threats over private networks. Specifically, it must not add new interfaces to other parts outside the trusted zone. Intrusions from known interfaces such as Internet gateways are outside the scope of this document.
网络是“虚拟的”，这一事实决不能使其在专用网络上受到额外的威胁。特别是，它不能向受信任区域之外的其他部分添加新接口。来自Internet网关等已知接口的入侵不在本文档范围内。
A denial-of-service (DoS) attack aims at making services or devices unavailable to legitimate users. In the framework of this document, only those DoS attacks are considered that are a consequence of providing network service through a VPN. DoS attacks over the standard interfaces into a trusted zone are not considered here.
拒绝服务（DoS）攻击旨在使合法用户无法使用服务或设备。在本文档的框架中，仅考虑通过VPN提供网络服务而导致的DoS攻击。此处不考虑通过标准接口进入受信任区域的DoS攻击。
The requirement is that a PPVPN is not more vulnerable against DoS attacks than it would be if the same network were private.
要求是PPVPN不比同一网络为私有网络时更容易受到DoS攻击。
It must not be possible to violate the integrity of a PPVPN by changing the sender identification (source address, source label, etc) of traffic in transit. For example, if two CEs are connected to the same PE, it must not be possible for one CE to send crafted packets that make the PE believe those packets are coming from the other CE, thus inserting them into the wrong PPVPN.
不得通过更改传输中流量的发送方标识（源地址、源标签等）来破坏PPVPN的完整性。例如，如果两个CE连接到同一个PE，则一个CE不可能发送精心编制的数据包，使PE相信这些数据包来自另一个CE，从而将它们插入错误的PPVPN。
This requirement means that data must be cryptographically secured in transit over the PPVPN core network to avoid eavesdropping.
这一要求意味着数据在PPVPN核心网络上传输时必须以加密方式进行保护，以避免窃听。
Where CE authentication is provided, it is not possible for an outsider to install a CE and pretend to belong to a specific PPVPN to which this CE does not belong in reality.
在提供CE认证的情况下，外部人员不可能安装CE并假装属于该CE实际上不属于的特定PPVPN。
Data in transit must be secured in such a manner that it cannot be altered or that any alteration may be detected at the receiver.
传输中的数据必须以不可更改的方式进行保护，或者在接收器处可以检测到任何更改。
Anti-replay means that data in transit cannot be recorded and replayed later. To protect against anti-replay attacks, the data must be cryptographically secured.
反重放意味着传输中的数据不能在以后记录和重放。为了防止反重放攻击，必须对数据进行加密保护。
Note: Even private networks do not necessarily meet the requirements of confidentiality, integrity, and anti-reply. Thus, when private and "virtually private" PPVPN services are compared, these requirements are only applicable if the comparable private service also included these services. However, the fact that VPNs operate over a shared infrastructure may make some of these requirements more important in a VPN environment than in a private network environment.
注意：即使是专用网络也不一定满足机密性、完整性和反回复的要求。因此，当比较私有和“虚拟私有”PPVPN服务时，这些要求仅适用于可比较的私有服务也包括这些服务的情况。然而，VPN在共享基础设施上运行的事实可能会使其中一些要求在VPN环境中比在专用网络环境中更为重要。
In this section, we discuss additional security requirements that the provider may have in order to secure its network infrastructure as it provides PPVPN services.
在本节中，我们将讨论提供商在提供PPVPN服务时为保护其网络基础设施而可能具有的其他安全要求。
The PPVPN service provider requirements defined here are the requirements for the PPVPN 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 PPVPN services to users with different levels of offered security. Therefore, a PPVPN service provider may fulfill any number of the security requirements listed in this section. This document does not state that a PPVPN must fulfill all of these requirements to be secure.
此处定义的PPVPN服务提供商要求是参考模型中PPVPN核心的要求。核心网络可以使用不同类型的网络技术实现，每个核心网络可以使用不同的技术向具有不同安全级别的用户提供PPVPN服务。因此，PPVPN服务提供商可以满足本节中列出的任何数量的安全要求。本文件并未说明PPVPN必须满足所有这些安全要求。
These requirements are focused on 1) how to protect the PPVPN core from various attacks outside the core, including PPVPN users and non-PPVPN alike, both accidentally and maliciously, and 2) how to protect the PPVPN user VPNs and sites themselves. Note that a PPVPN core is not more vulnerable against attacks than a core that does not provide PPVPNs. However, providing PPVPN services over such a core may lead to additional security requirements, if only because most users are expecting higher security standards in a core delivering PPVPN services.
这些要求的重点是1）如何保护PPVPN核心免受核心之外的各种攻击，包括PPVPN用户和非PPVPN用户（意外和恶意），以及2）如何保护PPVPN用户VPN和站点本身。请注意，PPVPN核心不比不提供PPVPN的核心更容易受到攻击。然而，在这样的核心上提供PPVPN服务可能会导致额外的安全要求，如果这仅仅是因为大多数用户期望在提供PPVPN服务的核心中有更高的安全标准。
- Protocol Authentication within the Core:
- 核心内的协议身份验证：
PPVPN technologies and infrastructure must support mechanisms for authentication of the control plane. For an IP core, IGP and BGP
PPVPN技术和基础设施必须支持控制平面认证机制。对于IP核、IGP和BGP
sessions may be authenticated by using TCP MD5 or IPsec. If an MPLS core is used, LDP sessions may be authenticated by using TCP MD5. In addition, IGP and BGP authentication should also be considered. For a core providing layer-2 services, PE to PE authentication may also be used via IPsec.
会话可以使用TCP MD5或IPsec进行身份验证。如果使用MPLS核心，则可以使用TCP MD5对LDP会话进行身份验证。此外，还应考虑IGP和BGP认证。对于提供第2层服务的核心，也可以通过IPsec使用PE-to-PE身份验证。
With the cost of authentication coming down rapidly, the application of control plane authentication may not increase the cost of implementation for providers significantly, and it will improve the security of the core. If the core is dedicated to VPN services and there are no interconnects to third parties, then it may reduce the requirement for authentication of the core control plane.
随着认证成本的快速下降，控制平面认证的应用可能不会显著增加提供商的实现成本，并且会提高核心的安全性。如果核心专用于VPN服务，并且没有与第三方的互连，那么它可能会降低对核心控制平面的认证要求。
- Elements protection
- 元素保护
Here we discuss means to hide the provider's infrastructure nodes.
这里我们讨论隐藏提供者的基础结构节点的方法。
A PPVPN provider may make the infrastructure routers (P and PE routers) unreachable by outside users and unauthorized internal users. For example, separate address space may be used for the infrastructure loopbacks.
PPVPN提供商可能会使外部用户和未经授权的内部用户无法访问基础设施路由器（P和PE路由器）。例如，单独的地址空间可用于基础设施环回。
Normal TTL propagation may be altered to make the backbone look like one hop from the outside, but caution should be taken for loop prevention. This prevents the backbone addresses from being exposed through trace route; however, it 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 by making the Internet a VPN within the PPVPN core itself. This helps detach Internet access from PPVPN services.
因特网骨干核心可被重新设计以使因特网路由成为边缘功能，例如，通过对核心内的所有通信使用MPLS标签交换，并且可能通过使因特网成为PPVPN核心本身内的VPN。这有助于将Internet访问与PPVPN服务分离。
PE devices may implement separate control plane, data plane, and management plane functionality in terms of hardware and software, to improve security. This may help limit the problems when one particular area is attacked, and it may allow each plane to implement additional security measurement separately.
PE设备可以在硬件和软件方面实现单独的控制平面、数据平面和管理平面功能，以提高安全性。这可能有助于限制一个特定区域受到攻击时的问题，并允许每架飞机单独实施额外的安全措施。
PEs are often more vulnerable to attack than P routers, since, by their very nature, PEs cannot be made unreachable to outside users. Access to core trunk resources can be controlled on a per-user basis by the application of inbound rate-limiting/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 Internet and PPVPN service may help improve the PPVPN security and better protect VPN customers. Furthermore, if the resources, such as CPU and memory, may be further separated based on applications, or even on individual VPNs, it may help provide improved security and reliability to individual VPN customers.
在PE中，对Internet和PPVPN服务使用单独的路由过程可能有助于提高PPVPN安全性并更好地保护VPN客户。此外，如果资源（如CPU和内存）可以根据应用程序，甚至在单个VPN上进一步分离，则可能有助于为单个VPN客户提供改进的安全性和可靠性。
Many of these were not particular issues when an IP core was designed to support Internet services only. Providing PPVPN services introduces new security requirements for VPN services. Similar consideration apply to L2 VPN services.
当IP核心设计为仅支持Internet服务时，其中许多问题都不是特别的问题。提供PPVPN服务为VPN服务引入了新的安全要求。类似的考虑也适用于L2 VPN服务。
PPVPN using IPsec technologies provides VPN users with encryption of secure user data.
使用IPsec技术的PPVPN为VPN用户提供安全用户数据的加密。
In today's MPLS, ATM, and Frame Relay networks, encryption is not provided as a basic feature. Mechanisms can be used to secure the MPLS data plane and to secure the data carried over the MPLS core. Additionally, if the core is dedicated to VPN services and there are no external interconnects to third party networks, then there is no obvious need for encryption of the user data plane.
在今天的MPLS、ATM和帧中继网络中，加密并不是一项基本功能。机制可用于保护MPLS数据平面和MPLS核心上携带的数据。此外，如果核心专用于VPN服务，并且没有与第三方网络的外部互连，那么显然不需要对用户数据平面进行加密。
Inter-working IPsec/L3 PPVPN technologies or IPsec/L2 PPVPN technologies may be used to provide PPVPN users with end-to-end PPVPN services.
可使用互操作IPsec/L3 PPVPN技术或IPsec/L2 PPVPN技术为PPVPN用户提供端到端PPVPN服务。
Peer/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 an inter-provider connection, authentication/encryption mechanisms between ASes, such as IPsec, may be used.
对等/邻居协议认证可用于增强安全性。例如，BGP MD5认证可用于使用eBGP增强PE-CE链路上的安全性。在提供商间连接的情况下，可以使用ASE之间的身份验证/加密机制，例如IPsec。
WAN link address space separation for VPN and non-VPN users may be implemented to improve security in order to protect VPN customers if multiple services are provided on the same PE platform.
如果在同一个PE平台上提供多个服务，则可以为VPN和非VPN用户实施WAN链路地址空间分离，以提高安全性，从而保护VPN客户。
Firewall/Filtering: Access control mechanisms can be used to filter out any packets destined for the service provider's infrastructure prefix or to eliminate routes identified as illegitimate.
防火墙/过滤：访问控制机制可用于过滤掉任何发送到服务提供商基础设施前缀的数据包，或消除被识别为非法的路由。
Rate limiting may be applied to the user interface/logical interfaces against DDoS bandwidth attack. This is very helpful when the PE device is supporting both VPN services and Internet services, especially when it supports VPN and Internet services on the same physical interfaces through different logical interfaces.
速率限制可应用于针对DDoS带宽攻击的用户接口/逻辑接口。当PE设备同时支持VPN服务和Internet服务时，这非常有用，特别是当它通过不同的逻辑接口在相同的物理接口上支持VPN和Internet服务时。
Authentication mechanisms can be employed to validate site access to the PPVPN network via fixed or logical (e.g., L2TP, IPsec) connections. When the user wishes to hold the 'secret' associated to acceptance of the access and site into the VPN, then PPVPN based solutions require the flexibility for either direct authentication by the PE itself or interaction with a customer PPVPN authentication server. Mechanisms are required in the latter case to ensure that the interaction between the PE and the customer authentication server is controlled, for example, by limiting it simply to an exchange in relation to the authentication phase and with other attributes (e.g., optional filtering of RADIUS).
身份验证机制可用于通过固定或逻辑（例如L2TP、IPsec）连接验证对PPVPN网络的站点访问。当用户希望持有与接受VPN访问和站点相关的“秘密”时，基于PPVPN的解决方案需要PE本身直接认证或与客户PPVPN认证服务器交互的灵活性。在后一种情况下，需要机制来确保PE和客户身份验证服务器之间的交互受到控制，例如，通过将其仅限于与身份验证阶段相关的交换和其他属性（例如，RADIUS的可选过滤）。
Mechanisms may be used to provide control at a routing protocol level (e.g., RIP, OSPF, BGP) between the CE and 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, in particular, the following mechanisms should be considered:
机制可用于在CE和PE之间提供路由协议级别（例如，RIP、OSPF、BGP）的控制。可以建立每邻居和每VPN路由策略，以增强安全性并减少恶意或非恶意攻击对PE的影响，特别是应考虑以下机制：
- Limiting the number of prefixes that may be advertised into the PE on a per-access basis . Appropriate action may be taken should a limit be exceeded; for example, the PE might shut 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/filtering mechanism may be applied between ASes. Proper security procedures must be implemented in inter-provider VPN interconnection to protect the providers' network infrastructure and their customer VPNs. This may be custom designed for each inter-Provider VPN peering connection, and both providers must agree on it.
在提供商间连接的情况下，可以应用如上所述的访问保护、链路认证和路由策略。ASE之间可以应用入站和出站防火墙/过滤机制。必须在供应商间VPN互连中实施适当的安全程序，以保护供应商的网络基础设施及其客户VPN。这可能是为每个供应商间VPN对等连接定制的，两个供应商必须对此达成一致。
PPVPN providers offering QoS-enabled services require mechanisms to ensure that individual accesses are validated against their subscribed QOS profile and are granted access to core resources that match their service profile. Mechanisms such as per-Class of Service rate limiting/traffic shaping on ingress to the PPVPN core are one option in providing this level of control. Such mechanisms may require the per-Class of Service profile to be enforced by marking, remarking, or discarding traffic that is outside of the profile.
提供支持QoS的服务的PPVPN提供商需要机制来确保根据其订阅的QoS配置文件验证单个访问，并授予对与其服务配置文件匹配的核心资源的访问权限。诸如每类服务速率限制/进入PPVPN核心时的流量整形等机制是提供这种控制级别的一种选择。此类机制可能要求通过标记、注释或丢弃配置文件之外的流量来强制执行每类服务配置文件。
End users requiring visibility of VPN-specific statistics on the core (e.g., routing table, interface status, QoS statistics) impose requirements for mechanisms at the PE both to validate the incoming user and to limit the views available to that particular user's VPN. Mechanisms should also be considered to ensure that such access cannot be used to create a DoS attack (either malicious or accidental) on the PE itself. This could be accomplished either through separation of these resources within the PE itself or via the capability to rate-limit such traffic on a per-VPN basis.
最终用户需要查看核心上的VPN特定统计信息（例如，路由表、接口状态、QoS统计信息），这就对PE上的机制提出了要求，以验证传入用户并限制该特定用户的VPN可用的视图。还应考虑各种机制，以确保此类访问不能用于在PE本身上创建DoS攻击（恶意或意外）。这可以通过在PE内部分离这些资源或通过在每个VPN的基础上对此类流量进行速率限制的能力来实现。
The PPVPN providers must support the users' security requirements as listed in Section 7. Depending on the technologies used, these requirements may include the following.
PPVPN提供商必须支持第7节中列出的用户安全要求。根据使用的技术，这些要求可能包括以下内容。
- User control plane separation: Routing isolation.
- 用户控制平面隔离：路由隔离。
- User address space separation: Supporting overlapping addresses from different VPNs.
- 用户地址空间分离：支持来自不同VPN的重叠地址。
- User data plane separation: One VPN traffic cannot be intercepted by other VPNs or any other users.
- 用户数据平面分离：一个VPN流量不能被其他VPN或任何其他用户拦截。
- Protection against intrusion, DoS attacks and spoofing.
- 防止入侵、DoS攻击和欺骗。
- Access Authentication.
- 访问验证。
- Techniques highlighted through this document identify methodologies for the protection of PPVPN resources and infrastructure.
- 本文件强调的技术确定了保护PPVPN资源和基础设施的方法。
Hardware or software bugs in equipment that lead to security breaches are outside the scope of this document.
设备中导致安全漏洞的硬件或软件缺陷不在本文件范围内。
This section presents a brief template that may be used to evaluate and summarize how a given PPVPN approach (solution) measures up against the PPVPN Security Framework. An evaluation using this template should appear in the applicability statement for each PPVPN approach.
本节介绍一个简短的模板，可用于评估和总结给定PPVPN方法（解决方案）如何与PPVPN安全框架相匹配。使用此模板的评估应出现在每个PPVPN方法的适用性声明中。
The first part of the template is in the form of a list of security assertions. For each assertion the approach is assessed and one or more of the following ratings is assigned:
模板的第一部分是安全断言列表的形式。对于每个断言，评估方法，并指定以下一个或多个评级：
- The requirement is not applicable to the VPN approach because ... (fill in reason).
- 该要求不适用于VPN方法，因为。。。（填写原因）。
- The base VPN approach completely addresses the requirement by ... (fill in technique).
- 基本VPN方法完全满足以下要求。。。（填写技巧）。
- The base VPN approach partially addresses the requirement by ... (fill in technique and extent to which it addresses the requirement).
- 基本VPN方法通过以下方式部分满足了需求。。。（填写满足要求的技术和程度）。
- An optional extension to the VPN approach completely addresses the requirement by ... (fill in technique).
- VPN方法的可选扩展完全满足以下要求。。。（填写技巧）。
- An optional extension to the VPN approach partially addresses the requirement by ... (fill in technique and extent to which it addresses the requirement).
- VPN方法的可选扩展部分解决了以下要求。。。（填写满足要求的技术和程度）。
- The requirement is addressed in a way that is beyond the scope of the VPN approach. (Explain.) (One example of this would be a VPN approach in which some aspect, such as membership discovery, is done via configuration. The protection afforded to the configuration would be beyond the scope of the VPN approach.).
- 该需求的解决方式超出了VPN方法的范围。（解释。）（这方面的一个例子是VPN方法，其中某些方面（如成员身份发现）是通过配置完成的。为配置提供的保护将超出VPN方法的范围。）。
- The VPN approach does not meet the requirement.
- VPN方法不符合要求。
The following assertions solicit responses of the types listed in the previous section.
以下断言请求上一节中列出的类型的响应。
1. The approach provides complete IP address space separation for each L3 VPN.
1. 该方法为每个L3 VPN提供完整的IP地址空间分离。
2. The approach provides complete L2 address space separation for each L2 VPN.
2. 该方法为每个L2 VPN提供完整的L2地址空间分离。
3. The approach provides complete VLAN ID space separation for each L2 VPN.
3. 该方法为每个L2 VPN提供完整的VLAN ID空间分离。
4. The approach provides complete IP route separation for each L3 VPN.
4. 该方法为每个L3 VPN提供完整的IP路由分离。
5. The approach provides complete L2 forwarding separation for each L2 VPN.
5. 该方法为每个L2 VPN提供完全的L2转发分离。
6. The approach provides a means to prevent improper cross-connection of sites in separate VPNs.
6. 该方法提供了一种防止不同VPN中站点之间不正确交叉连接的方法。
7. The approach provides a means to detect improper cross-connection of sites in separate VPNs.
7. 该方法提供了一种检测单独VPN中站点的不正确交叉连接的方法。
8. The approach protects against the introduction of unauthorized packets into each VPN a. in the CE-PE link, b. in a single- or multi-provider PPVPN backbone, or c. in the Internet used as PPVPN backbone.
8. 该方法可防止未经授权的数据包引入每个VPN a。在CE-PE链接中，b。在单提供商或多提供商PPVPN主干网中，或c。在Internet上用作PPVPN主干网。
9. The approach provides confidentiality (secrecy) protection for PPVPN user data a. in the CE-PE link, b. in a single- or multi-provider PPVPN backbone, or c. in the Internet used as PPVPN backbone.
9. 该方法为PPVPN用户数据a提供机密（保密）保护。在CE-PE链接中，b。在单提供商或多提供商PPVPN主干网中，或c。在Internet上用作PPVPN主干网。
10. The approach provides sender authentication for PPVPN user data. a. in the CE-PE link, b. in a single- or multi-provider PPVPN backbone, or c. in the Internet used as PPVPN backbone.
10. 该方法为PPVPN用户数据提供发送方身份验证。A.在CE-PE链接中，b。在单提供商或多提供商PPVPN主干网中，或c。在Internet上用作PPVPN主干网。
11. The approach provides integrity protection for PPVPN user data a. in the CE-PE link, b. in a single- or multi- provider PPVPN backbone, or c. in the Internet used as PPVPN backbone.
11. 该方法为PPVPN用户数据a提供完整性保护。在CE-PE链接中，b。在单提供商或多提供商PPVPN主干网中，或c。在Internet上用作PPVPN主干网。
12. The approach provides protection against replay attacks for PPVPN user data a. in the CE-PE link, b. in a single- or multi-provider PPVPN backbone, or c. in the Internet used as PPVPN backbone.
12. 该方法为PPVPN用户数据a提供了防止重播攻击的保护。在CE-PE链接中，b。在单提供商或多提供商PPVPN主干网中，或c。在Internet上用作PPVPN主干网。
13. The approach provides protection against unauthorized traffic pattern analysis for PPVPN user data a. in the CE-PE link, b. in a single- or multi-provider PPVPN backbone, or c. in the Internet used as PPVPN backbone.
13. 该方法针对PPVPN用户数据a的未授权流量模式分析提供保护。在CE-PE链接中，b。在单提供商或多提供商PPVPN主干网中，或c。在Internet上用作PPVPN主干网。
14. The control protocol(s) used for each of the following functions provides message integrity and peer authentication
14. 用于以下每个功能的控制协议提供消息完整性和对等身份验证
a. VPN membership discovery. b. Tunnel establishment. c. VPN topology and reachability advertisement: i. PE-PE. ii. PE-CE. d. VPN provisioning and management. e. VPN monitoring, attack detection, and reporting. f. Other VPN-specific control protocols, if any (list).
a. VPN成员身份发现。B隧道设施。CVPN拓扑和可达性广告：i。PE-PE。二、PE-CE。DVPN配置和管理。EVPN监控、攻击检测和报告。F其他特定于VPN的控制协议（如有）（列表）。
The following questions solicit free-form answers.
以下问题征求自由形式的答案。
15. Describe the protection, if any, the approach provides against PPVPN-specific DoS attacks (i.e., inter-trusted-zone DoS attacks):
15. 描述该方法针对特定于PPVPN的DoS攻击（即相互信任区域DoS攻击）提供的保护（如有）：
a. Protection of the service provider infrastructure against Data Plane or Control Plane DoS attacks originated in a private (PPVPN user) network and aimed at PPVPN mechanisms.
a. 保护服务提供商基础设施免受源自专用（PPVPN用户）网络并针对PPVPN机制的数据平面或控制平面DoS攻击。
b. Protection of the service provider infrastructure against Data Plane or Control Plane DoS attacks originated in the Internet and aimed at PPVPN mechanisms.
b. 保护服务提供商基础设施免受源于Internet并针对PPVPN机制的数据平面或控制平面DoS攻击。
c. Protection of PPVPN users against Data Plane or Control Plane DoS attacks originated from the Internet or from other PPVPN users and aimed at PPVPN mechanisms.
c. 保护PPVPN用户免受来自Internet或其他PPVPN用户并针对PPVPN机制的数据平面或控制平面DoS攻击。
16. Describe the protection, if any, the approach provides against unstable or malicious operation of a PPVPN user network
16. 描述该方法针对PPVPN用户网络的不稳定或恶意操作提供的保护（如有）
a. Protection against high levels of, or malicious design of, routing traffic from PPVPN user networks to the service provider network.
a. 针对从PPVPN用户网络到服务提供商网络的路由流量的高级别或恶意设计提供保护。
b. Protection against high levels of, or malicious design of, network management traffic from PPVPN user networks to the service provider network.
b. 针对从PPVPN用户网络到服务提供商网络的高级别或恶意设计的网络管理流量提供保护。
c. Protection against worms and probes originated in the PPVPN user networks, sent toward the service provider network.
c. 针对源自PPVPN用户网络、发送至服务提供商网络的蠕虫和探测的保护。
17. Is the approach subject to any approach-specific vulnerabilities not specifically addressed by this template? If so, describe the defense or mitigation, if any, that the approach provides for each.
17. 该方法是否受到本模板未明确解决的任何方法特定漏洞的影响？如果是，请描述该方法为每种方法提供的防御或缓解措施（如有）。
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 very high level the role of each type of consideration in an overall secure PPVPN system. The document describes a number of potential security threats. Some of these threats have already been observed occurring in running networks; others are largely theoretical at this time.
安全考虑是本备忘录的唯一主题，因此将在本备忘录中进行讨论。在这里，我们重述已经介绍的内容，并在一个非常高的层次上解释每种考虑因素在整个安全PPVPN系统中的作用。该文件描述了一些潜在的安全威胁。已经观察到其中一些威胁发生在运行的网络中；其他的在这个时候主要是理论性的。
DoS attacks and intrusion attacks from the Internet against service provider 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/provisioning errors are cited by service providers as one of their prime concerns.
已经看到来自互联网的针对服务提供商基础设施的DoS攻击和入侵攻击。DoS“攻击”（通常不是恶意的）也被发现，其中CE设备以高数量或速率的数据包流量或路由信息压倒PE设备。服务提供商将操作/资源调配错误列为他们最关心的问题之一。
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 both successful and unsuccessful attacks. These activities are essential for "understanding one's enemy", mobilizing new defenses, and obtaining metrics about how secure the PPVPN service is. As such, they are vital components of any complete PPVPN security system.
该文档描述了检测、监视和报告成功和失败攻击的重要性。这些活动对于“了解敌人”、动员新的防御以及获取PPVPN服务安全性指标至关重要。因此，它们是任何完整PPVPN安全系统的重要组成部分。
The document evaluates PPVPN security requirements from a customer perspective and from a service provider 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 equipment or service offering.
本文档从客户和服务提供商的角度评估PPVPN安全要求。这些章节从不同利益相关者的角度重新评估已识别的威胁，旨在帮助设备供应商和服务提供商，他们必须最终决定在任何给定设备或服务中要防范哪些威胁。
Finally, the document includes a template for use by authors of PPVPN technical solutions for evaluating how those solutions measure up against the security considerations presented in this memo.
最后，该文档包括一个模板，供PPVPN技术解决方案的作者使用，用于评估这些解决方案如何符合本备忘录中提出的安全考虑。
The following people made major contributions to writing this document: Michael Behringer, Ross Callon, Fabio Chiussi, Jeremy De Clerque, Paul Hitchen, and Paul Knignt.
以下人士为撰写本文件做出了重大贡献：迈克尔·贝林格、罗斯·卡隆、法比奥·丘西、杰里米·德·克莱克、保罗·希钦和保罗·奈特。
Michael Behringer Cisco Village d'Entreprises Green Side, Phone: +33.49723-2652 400, Avenue Roumanille, Bat. T 3 EMail: mbehring@cisco.com 06410 Biot, Sophia Antipolis France
迈克尔·贝林格·思科格林赛德创业村，电话：+33.49723-2652400，巴特州鲁马尼尔大道。T 3电子邮件：mbehring@cisco.com06410比奥，索菲亚安提波利斯法国
Ross Callon Juniper Networks 10 Technology Park Drive Phone: 978-692-6724 Westford, MA 01886 EMail: rcallon@juniper.net
Ross Callon Juniper Networks 10 Technology Park Drive电话：978-692-6724马萨诸塞州韦斯特福德01886电子邮件：rcallon@juniper.net
Fabio Chiussi Phone: 1 978 367-8965 Airvana EMail: fabio@airvananet.com 19 Alpha Road Chelmsford, Massachusetts 01824
Fabio Chiussi电话：1 978 367-8965 Airvana电子邮件：fabio@airvananet.com马萨诸塞州切姆斯福德阿尔法路19号01824
Jeremy De Clercq Alcatel Fr. Wellesplein 1, 2018 Antwerpen EMail: jeremy.de_clercq@alcatel.be Belgium
Jeremy De Clercq Alcatel Fr.Welleslein 2018年1月1日安特卫普电子邮件：Jeremy.De_clercq@alcatel.be比利时
Mark Duffy Sonus Networks 250 Apollo Drive Phone: 1 978-614-8748 Chelmsford, MA 01824 EMail: mduffy@sonusnet.com
Mark Duffy Sonus Networks 250阿波罗大道电话：1 978-614-8748马萨诸塞州切姆斯福德01824电子邮件：mduffy@sonusnet.com
Paul Hitchen BT BT Adastral Park Martlesham Heath Phone: 44-1473-606-344 Ipswich IP53RE EMail: paul.hitchen@bt.com UK
Paul Hitchen英国电信公司Adastral Park Martlesham Heath电话：44-1473-606-344 Ipswich IP53RE电子邮件：Paul。hitchen@bt.com英国
Paul Knight Nortel 600 Technology Park Drive Phone: 978-288-6414 Billerica, MA 01821 EMail: paul.knight@nortel.com
Paul Knight Nortel 600 Technology Park Drive电话：978-288-6414马萨诸塞州Billerica 01821电子邮件：Paul。knight@nortel.com
The author and contributors would also like to acknowledge the helpful comments and suggestions from Paul Hoffman, Eric Gray, Ron Bonica, Chris Chase, Jerry Ash, and Stewart Bryant.
作者和撰稿人还想感谢保罗·霍夫曼、埃里克·格雷、罗恩·博尼卡、克里斯·蔡斯、杰里·阿什和斯图尔特·布莱恩特的有益评论和建议。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，B.，Karrenberg，D.，de Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246]Dierks，T.和C.Allen，“TLS协议版本1.0”，RFC2246，1999年1月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[RFC2402]Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2407]Piper，D.，“ISAKMP解释的互联网IP安全域”，RFC 2407，1998年11月。
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
[RFC2661]汤斯利，W.，瓦伦西亚，A.，鲁本斯，A.，帕尔，G.，佐恩，G.，和B.帕尔特，“第二层隧道协议“L2TP”，RFC 26611999年8月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865]Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588]Calhoun，P.，Loughney，J.，Guttman，E.，Zorn，G.，和J.Arkko，“直径基础协议”，RFC 3588，2003年9月。
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003.
[RFC3602]Frankel，S.，Glenn，R.，和S.Kelly，“AES-CBC密码算法及其在IPsec中的使用”，RFC 3602，2003年9月。
[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., "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002.
Presohn，R.，“简单网络管理协议（SNMP）的协议操作第2版”，STD 62，RFC 3416，2002年12月。
Presuhn, R., "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002.
Presohn，R.，“简单网络管理协议（SNMP）的传输映射”，STD 62，RFC 34172002年12月。
Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002.
Presohn，R.，“简单网络管理协议（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月。
[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月。
[RFC3631] Bellovin, S., Schiller, J., and C. Kaufman, "Security Mechanisms for the Internet", RFC 3631, December 2003.
[RFC3631]Bellovin，S.，Schiller，J.，和C.Kaufman，“互联网的安全机制”，RFC 36312003年12月。
[RFC3889] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 3889, October 2004.
[RFC3889]Barbir，A.，Murphy，S.，和Y.Yang，“路由协议的一般威胁”，RFC 3889，2004年10月。
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, March 2005.
[RFC4026]Andersson，L.和T.Madsen，“提供商提供的虚拟专用网络（VPN）术语”，RFC 4026，2005年3月。
[RFC4031] Carugi, M. and D. McDysan, Eds., "Service Requirements for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs)", RFC 4031, April 2005.
[RFC4031]Carugi，M.和D.McDysan，编辑，“第3层提供商提供的虚拟专用网络（PPVPN）的服务要求”，RFC 4031，2005年4月。
[RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3 Provider Provisioned Virtual Private Networks", RFC 4110, July 2005.
[RFC4110]Callon，R.和M.Suzuki，“第3层提供商提供的虚拟专用网络框架”，RFC 4110，2005年7月。
Author's Address
作者地址
Luyuan Fang AT&T Labs. 200 Laurel Avenue, Room C2-3B35 Middletown, NJ 07748
卢元芳AT&T实验室。新泽西州米德尔顿市劳雷尔大道200号C2-3B35室，邮编07748
Phone: 732-420-1921 EMail: luyuanfang@att.com
电话：732-420-1921电子邮件：luyuanfang@att.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。