Network Working Group S. Yamamoto
Request for Comments: 5619 NICT/KDDI R&D Labs
Category: Standards Track C. Williams
H. Yokota
KDDI R&D Labs
F. Parent
Beon Solutions
August 2009
Network Working Group S. Yamamoto
Request for Comments: 5619 NICT/KDDI R&D Labs
Category: Standards Track C. Williams
H. Yokota
KDDI R&D Labs
F. Parent
Beon Solutions
August 2009
Softwire Security Analysis and Requirements
软线安全分析与需求
Abstract
摘要
This document describes security guidelines for the softwire "Hubs and Spokes" and "Mesh" solutions. Together with discussion of the softwire deployment scenarios, the vulnerability to security attacks is analyzed to provide security protection mechanisms such as authentication, integrity, and confidentiality to the softwire control and data packets.
本文档描述了软线“集线器和辐条”和“网格”解决方案的安全指南。结合对软线部署场景的讨论，分析了易受安全攻击的漏洞，为软线控制和数据包提供身份验证、完整性和机密性等安全保护机制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Requirements Language . . . . . . . . . . . . . . . . . . 5
3. Hubs and Spokes Security Guidelines . . . . . . . . . . . . . 5
3.1. Deployment Scenarios . . . . . . . . . . . . . . . . . . . 5
3.2. Trust Relationship . . . . . . . . . . . . . . . . . . . . 7
3.3. Softwire Security Threat Scenarios . . . . . . . . . . . . 8
3.4. Softwire Security Guidelines . . . . . . . . . . . . . . . 11
3.4.1. Authentication . . . . . . . . . . . . . . . . . . . . 12
3.4.2. Softwire Security Protocol . . . . . . . . . . . . . . 13
3.5. Guidelines for Usage of IPsec in Softwire . . . . . . . . 13
3.5.1. Authentication Issues . . . . . . . . . . . . . . . . 14
3.5.2. IPsec Pre-Shared Keys for Authentication . . . . . . . 15
3.5.3. Inter-Operability Guidelines . . . . . . . . . . . . . 15
3.5.4. IPsec Filtering Details . . . . . . . . . . . . . . . 16
4. Mesh Security Guidelines . . . . . . . . . . . . . . . . . . . 19
4.1. Deployment Scenario . . . . . . . . . . . . . . . . . . . 19
4.2. Trust Relationship . . . . . . . . . . . . . . . . . . . . 20
4.3. Softwire Security Threat Scenarios . . . . . . . . . . . . 20
4.4. Applicability of Security Protection Mechanism . . . . . . 21
4.4.1. Security Protection Mechanism for Control Plane . . . 21
4.4.2. Security Protection Mechanism for Data Plane . . . . . 22
5. Security Considerations . . . . . . . . . . . . . . . . . . . 23
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.1. Normative References . . . . . . . . . . . . . . . . . . . 23
7.2. Informative References . . . . . . . . . . . . . . . . . . 24
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 26
A.1. IPv6-over-IPv4 Softwire with L2TPv2 Example for IKE . . . 26
A.2. IPv4-over-IPv6 Softwire with Example for IKE . . . . . . . 26
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Requirements Language . . . . . . . . . . . . . . . . . . 5
3. Hubs and Spokes Security Guidelines . . . . . . . . . . . . . 5
3.1. Deployment Scenarios . . . . . . . . . . . . . . . . . . . 5
3.2. Trust Relationship . . . . . . . . . . . . . . . . . . . . 7
3.3. Softwire Security Threat Scenarios . . . . . . . . . . . . 8
3.4. Softwire Security Guidelines . . . . . . . . . . . . . . . 11
3.4.1. Authentication . . . . . . . . . . . . . . . . . . . . 12
3.4.2. Softwire Security Protocol . . . . . . . . . . . . . . 13
3.5. Guidelines for Usage of IPsec in Softwire . . . . . . . . 13
3.5.1. Authentication Issues . . . . . . . . . . . . . . . . 14
3.5.2. IPsec Pre-Shared Keys for Authentication . . . . . . . 15
3.5.3. Inter-Operability Guidelines . . . . . . . . . . . . . 15
3.5.4. IPsec Filtering Details . . . . . . . . . . . . . . . 16
4. Mesh Security Guidelines . . . . . . . . . . . . . . . . . . . 19
4.1. Deployment Scenario . . . . . . . . . . . . . . . . . . . 19
4.2. Trust Relationship . . . . . . . . . . . . . . . . . . . . 20
4.3. Softwire Security Threat Scenarios . . . . . . . . . . . . 20
4.4. Applicability of Security Protection Mechanism . . . . . . 21
4.4.1. Security Protection Mechanism for Control Plane . . . 21
4.4.2. Security Protection Mechanism for Data Plane . . . . . 22
5. Security Considerations . . . . . . . . . . . . . . . . . . . 23
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.1. Normative References . . . . . . . . . . . . . . . . . . . 23
7.2. Informative References . . . . . . . . . . . . . . . . . . 24
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 26
A.1. IPv6-over-IPv4 Softwire with L2TPv2 Example for IKE . . . 26
A.2. IPv4-over-IPv6 Softwire with Example for IKE . . . . . . . 26
The Softwire Working Group specifies the standardization of discovery, control, and encapsulation methods for connecting IPv4 networks across IPv6 networks and IPv6 networks across IPv4 networks. The softwire provides connectivity to enable the global reachability of both address families by reusing or extending existing technology. The Softwire Working Group is focusing on the two scenarios that emerged when discussing the traversal of networks composed of differing address families. This document provides the security guidelines for two such softwire solution spaces: the "Hubs and Spokes" and "Mesh" scenarios. The "Hubs and Spokes" and "Mesh" problems are described in [RFC4925] Sections 2 and 3, respectively. The protocols selected for softwire connectivity require security considerations on more specific deployment scenarios for each solution. The scope of this document provides analysis on the security vulnerabilities for the deployment scenarios and specifies the proper usage of the security mechanisms that are applied to the softwire deployment.
Softwire工作组规定了跨IPv6网络连接IPv4网络和跨IPv4网络连接IPv6网络的发现、控制和封装方法的标准化。软线提供连接，通过重用或扩展现有技术实现两个地址系列的全局可达性。Softwire工作组的重点是讨论由不同地址族组成的网络的遍历时出现的两种情况。本文档提供了两种软线解决方案空间的安全指南：“集线器和辐条”和“网格”方案。[RFC4925]第2节和第3节分别描述了“轮毂和辐条”和“网格”问题。为软线连接选择的协议需要针对每个解决方案的更具体部署场景考虑安全问题。本文档的范围提供了对部署场景的安全漏洞的分析，并指定了适用于软线部署的安全机制的正确用法。
The Layer Two Tunneling Protocol (L2TPv2) is selected as the phase 1 protocol to be deployed in the "Hubs and Spokes" solution space. If L2TPv2 is used in the unprotected network, it will be vulnerable to various security attacks and MUST be protected by an appropriate security protocol, such as IPsec as described in [RFC3193]. The new implementation SHOULD use IKEv2 (Internet Key Exchange Protocol version 2) as the key management protocol for IPsec because it is a more reliable protocol than IKEv1 and integrates the required protocols into a single platform. This document provides implementation guidance and specifies the proper usage of IPsec as the security protection mechanism by considering the security vulnerabilities in the "Hubs and Spokes" scenario. The document also addresses cases where the security protocol is not necessarily mandated.
选择第二层隧道协议（L2TPv2）作为第一阶段协议，部署在“集线器和辐条”解决方案空间中。如果L2TPv2在未受保护的网络中使用，它将容易受到各种安全攻击，并且必须受到适当的安全协议的保护，如[RFC3193]中所述的IPsec。新的实现应该使用IKEv2（Internet密钥交换协议版本2）作为IPsec的密钥管理协议，因为它是比IKEv1更可靠的协议，并且将所需的协议集成到单个平台中。本文档提供了实施指南，并通过考虑“集线器和辐条”场景中的安全漏洞，指定了IPsec作为安全保护机制的正确用法。该文件还涉及不一定强制执行安全协议的情况。
The softwire "Mesh" solution MUST support various levels of security mechanisms to protect the data packets being transmitted on a softwire tunnel from the access networks with one address family across the transit core operating with a different address family [RFC4925]. The security mechanism for the control plane is also required to be protected from control-data modification, spoofing attacks, etc. In the "Mesh" solution, BGP is used for distributing softwire routing information in the transit core; meanwhile, security issues for BGP are being discussed in other working groups. This document provides the proper usage of security mechanisms for softwire mesh deployment scenarios.
软线“网状”解决方案必须支持各种级别的安全机制，以保护在软线隧道上从接入网络传输的数据包，该接入网络在传输核心上具有一个地址系列，使用不同的地址系列运行[RFC4925]。还需要保护控制平面的安全机制免受控制数据修改、欺骗攻击等。在“Mesh”解决方案中，BGP用于在传输核心中分发软线路由信息；与此同时，BGP的安全问题正在其他工作组中讨论。本文档为softwire mesh部署场景提供了安全机制的正确用法。
The terminology is based on the "Softwire Problem Statement" [RFC4925].
该术语基于“软线问题声明”[RFC4925]。
AF(i) - Address Family. IPv4 or IPv6. Notation used to indicate that prefixes, a node, or network only deal with a single IP AF.
AF（i）-地址家庭。IPv4或IPv6。表示前缀、节点或网络只处理单个IP AF的符号。
AF(i,j) - Notation used to indicate that a node is dual-stack or that a network is composed of dual-stack nodes.
AF（i，j）-用于指示节点为双堆栈或网络由双堆栈节点组成的符号。
Address Family Border Router (AFBR) - A dual-stack router that interconnects two networks that use either the same or different address families. An AFBR forms peering relationships with other AFBRs, adjacent core routers, and attached Customer Edge (CE) routers; performs softwire discovery and signaling; advertises client ASF(i) reachability information; and encapsulates/decapsulates customer packets in softwire transport headers.
地址族边界路由器（AFBR）-一种双堆栈路由器，用于互连使用相同或不同地址族的两个网络。AFBR与其他AFBR、相邻的核心路由器和连接的客户边缘（CE）路由器形成对等关系；执行软线发现和信令；公布客户ASF（i）可达性信息；并在软线传输报头中封装/解除封装客户数据包。
Customer Edge (CE) - A router located inside an AF access island that peers with other CE routers within the access island network and with one or more upstream AFBRs.
客户边缘（CE）-位于AF接入岛内的路由器，与接入岛网络内的其他CE路由器以及一个或多个上游AFBR对等。
Customer Premise Equipment (CPE) - An equipment, host or router, located at a subscriber's premises and connected with a carrier's access network.
客户场所设备（CPE）-位于用户场所并与运营商接入网络连接的设备、主机或路由器。
Provider Edge (PE) - A router located at the edge of a transit core network that interfaces with the CE in an access island.
提供商边缘（PE）-位于传输核心网络边缘的路由器，与接入岛中的CE接口。
Softwire Concentrator (SC) - The node terminating the softwire in the service provider network.
软线集中器（SC）-在服务提供商网络中终止软线的节点。
Softwire Initiator (SI) - The node initiating the softwire within the customer network.
软线启动器（SI）-在客户网络内启动软线的节点。
Softwire Encapsulation Set (SW-Encap) - A softwire encapsulation set contains tunnel header parameters, order of preference of the tunnel header types, and the expected payload types (e.g., IPv4) carried inside the softwire.
软线封装集（SW Encap）-软线封装集包含隧道标头参数、隧道标头类型的优先顺序以及软线内部承载的预期有效负载类型（例如IPv4）。
Softwire Next_Hop (SW-NHOP) - This attribute accompanies client AF reachability advertisements and is used to reference a softwire on the ingress AFBR leading to the specific prefixes. It contains a softwire identifier value and a softwire next_hop IP address denoted as <SW ID:SW-NHOP address>. Its existence in the presence of client
Softwire Next_-Hop（SW-NHOP）-此属性伴随客户端AF可达性广告，用于引用入口AFBR上的软线，从而产生特定前缀。它包含一个软线标识符值和一个表示为<SW ID:SW-NHOP address>的软线下一跳IP地址。它在客户面前的存在
AF prefixes (in advertisements or entries in a routing table) infers the use of softwire to reach that prefix.
AF前缀（在播发或路由表中的条目中）推断使用软线来达到该前缀。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
To provide the security guidelines, discussion of the possible deployment scenario and the trust relationship in the network is important.
为了提供安全指南，讨论可能的部署场景和网络中的信任关系非常重要。
The softwire initiator (SI) always resides in the customer network. The node in which the SI resides can be the CPE access device, another dedicated CPE router behind the original CPE access device, or any kind of host device, such as a PC, appliance, sensor, etc.
软线启动器（SI）始终驻留在客户网络中。SI驻留的节点可以是CPE接入设备、原始CPE接入设备后面的另一专用CPE路由器，或者任何类型的主机设备，例如PC、设备、传感器等。
However, the host device may not always have direct access to its home carrier network, to which the user has subscribed. For example, the SI in the laptop PC can access various access networks such as Wi-Fi hot-spots, visited office networks, etc. This is the nomadic case, which the softwire SHOULD support.
然而，主机设备可能并不总是能够直接访问其用户已订阅的家庭载波网络。例如，笔记本电脑中的SI可以访问各种接入网络，如Wi-Fi热点、访问的办公网络等。这是游牧情况，软线应该支持这种情况。
As the softwire deployment model, the following three cases as shown in Figure 1 should be considered. Cases 2 and 3 are typical for a nomadic node, but are also applicable to a stationary node. In order to securely connect a legitimate SI and SC to each other, the authentication process between SI and SC is normally performed using Authentication, Authorization, and Accounting (AAA) servers.
作为软线部署模型，应考虑以下三种情况，如图1所示。情况2和3是游牧节点的典型情况，但也适用于固定节点。为了安全地将合法的SI和SC相互连接，SI和SC之间的身份验证过程通常使用身份验证、授权和记帐（AAA）服务器执行。
visited network visited network
access provider service provider
+---------------------------------+
| |
+......v......+ +.....................|......+
. . . v .
+------+ . (case 3) . . +------+ +--------+ .
| |=====================.==| | | | .
| SI |__.________ . . | SC |<---->| AAAv | .
| |---------- \ . . | | | | .
+------+ . \\ . . +------+ +--------+ .
. \\ . . ^ .
^ +..........\\.+ +.....................|......+
| \\ |
| (case 2) \\ |
| \\ |
| \\ |
| +............+ \\ +.....................|......+
. . \\. v .
+------+ . . \\__+------+ +--------+ .
| | . (case 1) . ---| | | | .
| SI |=====================.==| SC |<---->| AAAh | .
| | . . . | | | | .
+------+ . . . +------+ +--------+ .
. . . .
+............+ +............................+
home network home network
access provider service provider
visited network visited network
access provider service provider
+---------------------------------+
| |
+......v......+ +.....................|......+
. . . v .
+------+ . (case 3) . . +------+ +--------+ .
| |=====================.==| | | | .
| SI |__.________ . . | SC |<---->| AAAv | .
| |---------- \ . . | | | | .
+------+ . \\ . . +------+ +--------+ .
. \\ . . ^ .
^ +..........\\.+ +.....................|......+
| \\ |
| (case 2) \\ |
| \\ |
| \\ |
| +............+ \\ +.....................|......+
. . \\. v .
+------+ . . \\__+------+ +--------+ .
| | . (case 1) . ---| | | | .
| SI |=====================.==| SC |<---->| AAAh | .
| | . . . | | | | .
+------+ . . . +------+ +--------+ .
. . . .
+............+ +............................+
home network home network
access provider service provider
Figure 1: Authentication Model for Hubs and Spokes
图1：集线器和辐条的身份验证模型
The AAA server shown in Figure 1 interacts with the SC, which acts as a AAA client. The AAA may consists of multiple AAA servers, and the proxy AAA may be intermediate between the SC and the AAA servers. This document refers to the AAA server in the home network service provider as the home AAA server (AAAh) and to that in the visited network service provider as the visited AAA server (AAAv).
图1所示的AAA服务器与SC交互，SC充当AAA客户端。AAA可以由多个AAA服务器组成，并且代理AAA可以是SC和AAA服务器之间的中间层。本文档将家庭网络服务提供商中的AAA服务器称为家庭AAA服务器（AAAh），将访问的网络服务提供商中的AAA服务器称为访问的AAA服务器（AAAv）。
The "Softwire Problem Statement" [RFC4925] states that the softwire solution must be able to be integrated with commonly deployed AAA solutions. L2TPv2 used in softwire supports PPP and L2TP authentications that can be integrated with common AAA servers.
“软线问题声明”[RFC4925]指出，软线解决方案必须能够与通常部署的AAA解决方案集成。softwire中使用的L2TPv2支持PPP和L2TP认证，可与普通AAA服务器集成。
When the softwire is used in an unprotected network, a stronger authentication process is required (e.g., IKEv2). The proper selection of the authentication processes is discussed in Section 3.4 with respect to the various security threats.
在未受保护的网络中使用软线时，需要更强的身份验证过程（例如IKEv2）。第3.4节针对各种安全威胁讨论了认证过程的正确选择。
Case 1: The SI connects to the SC that belongs to the home network service provider via the home access provider network that operates a different address family. It is assumed that the home access provider network and the home network service provider for the SC are under the same administrative system.
情况1：SI通过运营不同地址系列的家庭接入提供商网络连接到属于家庭网络服务提供商的SC。假定SC的家庭接入提供商网络和家庭网络服务提供商处于相同的管理系统下。
Note that the IP address of the host device, in which the SI resides, is static or dynamic depending on the subscribed service. The discovery of the SC may be automatic. But in this document, the information on the SC, e.g., the DNS name or IP address, is assumed to be configured by the user or the provider of the SI in advance.
请注意，SI所在的主机设备的IP地址是静态的或动态的，具体取决于订阅的服务。SC的发现可能是自动的。但是在本文档中，关于SC的信息，例如DNS名称或IP地址，被假定由SI的用户或提供商预先配置。
Case 2: The SI connects to the SC that belongs to the home network service provider via the visited access network. For the nomadic case, the SI/user does not subscribe to the visited access provider. For network access through the public network, such as Wi-Fi hot-spots, the home network service provider does not have a trust relationship with the access network.
情况2：SI通过访问的接入网络连接到属于家庭网络服务提供商的SC。对于游牧情况，SI/用户不订阅访问的访问提供商。对于通过公共网络（如Wi-Fi热点）进行的网络访问，家庭网络服务提供商与访问网络没有信任关系。
Note that the IP address of the host device, in which the SI resides, may be changed periodically due to the home network service provider's policy.
请注意，SI所在的主机设备的IP地址可能会由于家庭网络服务提供商的策略而定期更改。
Case 3: The SI connects to the SC that belongs to the visited network service provider via the visited access network. This is typical of the nomadic access case. When the SI is mobile, it may roam from the home ISP providing the home access network to the visited access network, e.g., Wi-Fi hot-spot network provided by the different ISP. The SI does not connect to the SC in the home network, for example, due to geographical reasons. The SI/user does not subscribe to the visited network service provider, but the visited network service provider has some roaming agreement with the home network service provider.
情况3：SI通过访问的接入网络连接到属于访问的网络服务提供商的SC。这是典型的游牧访问案例。当SI是移动的时，它可以从提供家庭接入网络的家庭ISP漫游到访问的接入网络，例如，不同ISP提供的Wi-Fi热点网络。例如，由于地理原因，SI未连接到家庭网络中的SC。SI/用户不订阅到访网络服务提供商，但到访网络服务提供商与家庭网络服务提供商有一些漫游协议。
Note that the IP address of the host, in which the SI resides, is provided with the visited network service provider's policy.
请注意，SI所在主机的IP地址随访问网络服务提供商的策略一起提供。
The establishment of a trust relationship between the SI and SC is different for three cases. The security considerations must be taken into account for each case.
在三种情况下，SI和SC之间建立信任关系的方式不同。每种情况都必须考虑安全因素。
In Case 1, the SC and the home AAA server in the same network service provider MUST have a trust relationship and communications between them MUST be secured. When the SC authenticates the SI, the SC transmits the authentication request message to the home AAA server and obtains the accept message together with the Attribute Value Pair
在情况1中，同一网络服务提供商中的SC和家庭AAA服务器必须具有信任关系，并且它们之间的通信必须安全。当SC认证SI时，SC将认证请求消息发送到家庭AAA服务器，并与属性值对一起获得接受消息
for the SI authentication. Since the SI is in the service provider network, the provider can take measures to protect the entities (e.g., SC, AAA servers) against a number of security threats, including the communication between them.
对于SI身份验证。由于SI位于服务提供商网络中，提供商可以采取措施保护实体（例如，SC、AAA服务器）免受多种安全威胁，包括它们之间的通信。
In Case 2, when the SI is mobile, access to the home network service provider through the visited access network provider is allowed. The trust relationship between the SI and the SC in the home network MUST be established. When the visited access network is a public network, various security attacks must be considered. Especially for SI to connect to the legitimate SC, the authentication from SI to SC MUST be performed together with that from SC to SI.
在情况2中，当SI是移动的时，允许通过访问的接入网络提供商访问家庭网络服务提供商。必须在家庭网络中的SI和SC之间建立信任关系。当访问的接入网是公共网络时，必须考虑各种安全攻击。特别是对于要连接到合法SC的SI，从SI到SC的认证必须与从SC到SI的认证一起执行。
In Case 3, if the SI roams into a different network service provider's administrative domain, the visited AAA server communicates with the home AAA server to obtain the information for SI authentication. The visited AAA server MUST have a trust relationship with the home AAA server and the communication between them MUST be secured in order to properly perform the roaming services that have been agreed upon under specified conditions.
在情况3中，如果SI漫游到不同的网络服务提供商的管理域，则访问的AAA服务器与家庭AAA服务器通信以获得用于SI认证的信息。访问的AAA服务器必须与家庭AAA服务器具有信任关系，并且必须保护它们之间的通信，以便正确执行在指定条件下商定的漫游服务。
Note that the path for the communications between the home AAA server and the visited AAA server may consist of several AAA proxies. In this case, the AAA proxy threat model SHOULD be considered [RFC2607]. A malicious AAA proxy may launch passive or active security attacks. The trustworthiness of proxies in AAA proxy chains will weaken when the hop counts of the proxy chain is longer. For example, the accounting information exchanged among AAA proxies is attractive for an adversary. The communication between a home AAA server and a visited AAA server MUST be protected.
注意，家庭AAA服务器和访问的AAA服务器之间的通信路径可以由几个AAA代理组成。在这种情况下，应考虑AAA代理威胁模型[RFC2607]。恶意AAA代理可能发起被动或主动安全攻击。当代理链的跳数较长时，AAA代理链中代理的可信性会减弱。例如，AAA代理之间交换的会计信息对对手具有吸引力。家庭AAA服务器和访问过的AAA服务器之间的通信必须受到保护。
Softwire can be used to connect IPv6 networks across public IPv4 networks and IPv4 networks across public IPv6 networks. The control and data packets used during the softwire session are vulnerable to the security attacks.
Softwire可用于跨公共IPv4网络连接IPv6网络，以及跨公共IPv6网络连接IPv4网络。软线会话期间使用的控制和数据包容易受到安全攻击。
A complete threat analysis of softwire requires examination of the protocols used for the softwire setup, the encapsulation method used to transport the payload, and other protocols used for configuration (e.g., router advertisements, DHCP).
软线的完整威胁分析需要检查软线设置所使用的协议、用于传输有效负载的封装方法以及用于配置的其他协议（例如，路由器广告、DHCP）。
The softwire solution uses a subset of the Layer Two Tunneling Protocol (L2TPv2) functionality ([RFC2661], [RFC5571]). In the softwire "Hubs and Spokes" model, L2TPv2 is used in a voluntary tunnel model only. The SI acts as an L2TP Access Concentrator (LAC) and PPP endpoint. The L2TPv2 tunnel is always initiated from the SI.
软线解决方案使用第二层隧道协议（L2TPv2）功能的子集（[RFC2661]，[RFC5571]）。在软线“轮毂和辐条”模型中，L2TPv2仅用于自愿隧道模型。SI充当L2TP访问集中器（LAC）和PPP端点。L2TPv2隧道始终从SI启动。
The generic threat analysis done for L2TP using IPsec [RFC3193] is applicable to softwire "Hubs and Spokes" deployment. The threat analysis for other protocols such as MIPv6 (Mobile IPv6) [RFC4225], PANA (Protocol for Carrying Authentication for Network Access) [RFC4016], NSIS (Next Steps in Signaling) [RFC4081], and Routing Protocols [RFC4593] are applicable here as well and should be used as references.
使用IPsec[RFC3193]对L2TP进行的通用威胁分析适用于软线“集线器和辐条”部署。其他协议的威胁分析，如MIPv6（移动IPv6）[RFC4225]、PANA（承载网络访问身份验证的协议）[RFC4016]、NSIS（信令的下一步）[RFC4081]和路由协议[RFC4593]也适用于此，应作为参考。
First, the SI that resides in the customer network sends a Start-Control-Connection-Request (SCCRQ) packet to the SC for the initiation of the softwire. L2TPv2 offers an optional tunnel authentication system (which is similar to CHAP -- the Challenge Handshake Authentication Protocol) during control connection establishment. This requires a shared secret between the SI and SC and no key management is offered for this L2TPv2.
首先，驻留在客户网络中的SI向SC发送启动控制连接请求（SCCRQ）分组，以启动软线。L2TPv2在控制连接建立期间提供可选的隧道身份验证系统（类似于CHAP——质询握手身份验证协议）。这需要SI和SC之间共享机密，并且没有为该L2TPv2提供密钥管理。
When the L2TPv2 control connection is established, the SI and SC optionally enter the authentication phase after completing PPP Link Control Protocol (LCP) negotiation. PPP authentication supports one-way or two-way CHAP authentication, and can leverage existing AAA infrastructure. PPP authentication does not provide per-packet authentication.
当L2TPv2控制连接建立时，SI和SC可以选择在完成PPP链路控制协议（LCP）协商后进入身份验证阶段。PPP身份验证支持单向或双向CHAP身份验证，并且可以利用现有的AAA基础架构。PPP身份验证不提供每包身份验证。
PPP encryption is defined but PPP Encryption Control Protocol (ECP) negotiation does not provide for a protected cipher suite negotiation. PPP encryption provides a weak security solution [RFC3193]. PPP ECP implementation cannot be expected. PPP authentication also does not provide scalable key management.
定义了PPP加密，但PPP加密控制协议（ECP）协商未提供受保护的密码套件协商。PPP加密提供了弱安全性解决方案[RFC3193]。无法预期PPP ECP的实施。PPP身份验证也不提供可扩展密钥管理。
Once the L2TPv2 tunnel and PPP configuration are successfully established, the SI is connected and can start using the connection.
成功建立L2TPv2隧道和PPP配置后，SI将连接并可以开始使用连接。
These steps are vulnerable to man-in-the-middle (MITM), denial-of-service (DoS), and service-theft attacks, which are caused by the following adversary actions.
这些步骤容易受到中间人（MITM）、拒绝服务（DoS）和服务盗窃攻击的攻击，这些攻击是由以下敌对行动引起的。
Adversary attacks on softwire include:
对手对softwire的攻击包括：
1. An adversary may try to discover identities and other confidential information by snooping data packets.
1. 敌方可能试图通过窥探数据包来发现身份和其他机密信息。
2. An adversary may try to modify both control and data packets. This type of attack involves integrity violations.
2. 对手可能试图修改控制和数据包。这种类型的攻击涉及完整性冲突。
3. An adversary may try to eavesdrop and collect control messages. By replaying these messages, an adversary may successfully hijack the L2TP tunnel or the PPP connection inside the tunnel. An adversary might mount MITM, DoS, and theft-of-service attacks.
3. 对手可能试图窃听和收集控制信息。通过重放这些消息，对手可以成功劫持L2TP隧道或隧道内的PPP连接。对手可能发起MITM、DoS和窃取服务攻击。
4. An adversary can flood the softwire node with bogus signaling messages to cause DoS attacks by terminating L2TP tunnels or PPP connections.
4. 敌方可以通过终止L2TP隧道或PPP连接，向软线节点发送虚假的信令消息，从而导致DoS攻击。
5. An adversary may attempt to disrupt the softwire negotiation in order to weaken or remove confidentiality protection.
5. 对手可能会试图中断软线谈判，以削弱或消除保密保护。
6. An adversary may wish to disrupt the PPP LCP authentication negotiation.
6. 对手可能希望中断PPP LCP身份验证协商。
When AAA servers are involved in softwire tunnel establishment, the security attacks can be mounted on the communication associated with AAA servers. Specifically, for Case 3 stated in Section 3.2, an adversary may eavesdrop on the packets between AAA servers in the home and visited network and compromise the authentication data. An adversary may also disrupt the communication between the AAA servers, causing a service denial. Security of AAA server communications is out of scope of this document.
当AAA服务器参与softwire隧道建立时，安全攻击可能会发生在与AAA服务器相关的通信上。具体而言，对于第3.2节中所述的情况3，敌方可窃听家庭和访问网络中AAA服务器之间的数据包，并破坏认证数据。对手还可能中断AAA服务器之间的通信，导致拒绝服务。AAA服务器通信的安全性超出了本文档的范围。
In environments where the link is shared without cryptographic protection and weak authentication or one-way authentication is used, these security attacks can be mounted on softwire control and data packets.
在链路共享而没有加密保护且使用弱身份验证或单向身份验证的环境中，这些安全攻击可以安装在软线控制和数据包上。
When there is no prior trust relationship between the SI and SC, any node can pretend to be a SC. In this case, an adversary may impersonate the SC to intercept traffic (e.g., "rogue" softwire concentrator).
当SI和SC之间没有先前的信任关系时，任何节点都可以假装是SC。在这种情况下，对手可以模拟SC来拦截流量（例如，“恶意”软线集中器）。
The rogue SC can introduce a denial-of-service attack by blackholing packets from the SI. The rogue SC can also eavesdrop on all packets sent from or to the SI. Security threats of a rogue SC are similar to a compromised router.
流氓SC可以通过对来自SI的数据包进行黑洞攻击来引入拒绝服务攻击。流氓SC还可以窃听从SI发送或发送到SI的所有数据包。流氓SC的安全威胁类似于受损路由器。
The deployment of ingress filtering is able to control malicious users' access [RFC4213]. Without specific ingress filtering checks in the decapsulator at the SC, it would be possible for an attacker to inject a false packet, leaving the system vulnerable to attacks such as DoS. Using ingress filtering, invalid inner addresses can be rejected. Without ingress filtering of inner addresses, another kind of attack can happen. The malicious users from another ISP could start using its tunneling infrastructure to get free inner-address connectivity, effectively transforming the ISP into an inner-address transit provider.
入口过滤的部署能够控制恶意用户的访问[RFC4213]。如果在SC的decapsulator中没有特定的入口过滤检查，攻击者可能会注入虚假数据包，使系统容易受到DoS等攻击。使用入口过滤，可以拒绝无效的内部地址。如果不过滤内部地址，可能会发生另一种攻击。来自另一个ISP的恶意用户可以开始使用其隧道基础设施获得免费的内部地址连接，从而有效地将ISP转变为内部地址传输提供商。
Ingress filtering does not provide complete protection in the case that address spoofing has happened. In order to provide better protection against address spoofing, authentication with binding
在发生地址欺骗的情况下，入口过滤不能提供完全的保护。为了更好地防止地址欺骗，使用绑定进行身份验证
between the legitimate address and the authenticated identity MUST be implemented. This can be implemented between the SC and the SI using IPsec.
必须实现合法地址和经过身份验证的标识之间的连接。这可以使用IPsec在SC和SI之间实现。
Based on the security threat analysis in Section 3.3 of this document, the softwire security protocol MUST support the following protections.
根据本文件第3.3节中的安全威胁分析，软线安全协议必须支持以下保护。
1. Softwire control messages between the SI and SC MUST be protected against eavesdropping and spoofing attacks.
1. SI和SC之间的软线控制消息必须防止窃听和欺骗攻击。
2. The softwire security protocol MUST be able to protect itself against replay attacks.
2. 软线安全协议必须能够保护自身免受重播攻击。
3. The softwire security protocol MUST be able to protect the device identifier against the impersonation when it is exchanged between the SI and the SC.
3. 当在SI和SC之间交换设备标识符时，软线安全协议必须能够保护设备标识符不受模拟的影响。
4. The softwire security protocol MUST be able to securely bind the authenticated session to the device identifier of the client, to prevent service theft.
4. softwire安全协议必须能够将经过身份验证的会话安全地绑定到客户端的设备标识符，以防止服务被盗。
5. The softwire security protocol MUST be able to protect disconnect and revocation messages.
5. 软线安全协议必须能够保护断开连接和撤销消息。
The softwire security protocol requirement is comparable to [RFC3193].
软线安全协议要求与[RFC3193]相当。
For softwire control packets, authentication, integrity, and replay protection MUST be supported, and confidentiality SHOULD be supported.
对于软线控制数据包，必须支持身份验证、完整性和重播保护，并且应支持机密性。
For softwire data packets, authentication, integrity, and replay protection SHOULD be supported, and confidentiality MAY be supported.
对于软线数据包，应支持身份验证、完整性和重播保护，并且可能支持保密性。
The "Softwire Problem Statement" [RFC4925] provides some requirements for the "Hubs and Spoke" solution that are taken into account in defining the security protection mechanisms.
“软线问题声明”[RFC4925]为“集线器和分支”解决方案提供了一些要求，这些要求在定义安全保护机制时被考虑在内。
1. The control and/or data plane MUST be able to provide full payload security when desired.
1. 控制和/或数据平面必须能够在需要时提供完整的有效载荷安全性。
2. The deployed technology MUST be very strongly considered.
2. 必须非常认真地考虑部署的技术。
This additional security protection must be separable from the softwire tunneling mechanism.
这种额外的安全保护必须与软线隧道机制分开。
Note that the scope of this security is on the L2TP tunnel between the SI and SC. If end-to-end security is required, a security protocol SHOULD be used in the payload packets. But this is out of scope of this document.
请注意，此安全性的范围在SI和SC之间的L2TP隧道上。如果需要端到端安全性，则应在有效负载数据包中使用安全协议。但这超出了本文件的范围。
The softwire security protocol MUST support user authentication in the control plane in order to authorize access to the service and provide adequate logging of activity. Although several authentication protocols are available, security threats must be considered to choose the protocol.
softwire安全协议必须支持控制平面中的用户身份验证，以便授权访问服务并提供足够的活动日志记录。虽然有几种认证协议可用，但在选择协议时必须考虑安全威胁。
For example, consider the SI/user using Password Authentication Protocol (PAP) access to the SC with a cleartext password. In many circumstances, this represents a large security risk. The adversary may spoof as a legitimate user by using the stolen password. The Challenge Handshake Authentication Protocol (CHAP) [RFC1994] encrypts a password with a "challenge" sent from the SC. The theft of password can be mitigated. However, as CHAP only supports unidirectional authentication, the risk of a man-in-the-middle or rogue SC cannot be avoided. Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) [RFC5216] mandates mutual authentication and avoids the rogue SC.
例如，考虑SI /用户使用密码验证协议（PAP）访问带有明文密码的SC。在许多情况下，这意味着巨大的安全风险。对手可以通过使用被盗密码欺骗合法用户。质询握手认证协议（CHAP）[RFC1994]使用SC发送的“质询”对密码进行加密。密码被盗可以减轻。然而，由于CHAP只支持单向身份验证，中间人或流氓SC的风险无法避免。可扩展身份验证协议传输层安全性（EAP-TLS）[RFC5216]要求相互身份验证并避免恶意SC。
When the SI established a connection to the SC through a public network, the SI may want proof of the SC identity. Softwire MUST support mutual authentication to allow for such a scenario.
当SI通过公共网络与SC建立连接时，SI可能需要SC身份证明。Softwire必须支持相互认证，以允许出现这种情况。
In some circumstances, however, the service provider may decide to allow non-authenticated connection [RFC5571]. For example, when the customer is already authenticated by some other means, such as closed networks, cellular networks at Layer 2, etc., the service provider may decide to turn authentication off. If no authentication is conducted on any layer, the SC acts as a gateway for anonymous connections. Running such a service MUST be configurable by the SC administrator and the SC SHOULD take some security measures, such as ingress filtering and adequate logging of activity. It should be noted that anonymous connection service cannot provide the security functionalities described in this document (e.g., integrity, replay protection, and confidentiality).
然而，在某些情况下，服务提供商可能决定允许非认证连接[RFC5571]。例如，当客户已经通过一些其他手段（例如封闭网络、第2层的蜂窝网络等）进行认证时，服务提供商可以决定关闭认证。如果在任何层上都没有进行身份验证，则SC将充当匿名连接的网关。运行这样的服务必须由SC管理员配置，并且SC应该采取一些安全措施，例如入口过滤和充分记录活动。应该注意的是，匿名连接服务不能提供本文档中描述的安全功能（例如，完整性、重播保护和机密性）。
L2TPv2 selected as the softwire phase 1 protocol supports PPP authentication and L2TPv2 authentication. PPP authentication and L2TPv2 have various security threats, as stated in Section 3.3. They will be used in the limited condition as described in the next subsections.
选择L2TPv2作为软线第1阶段协议支持PPP身份验证和L2TPv2身份验证。PPP认证和L2TPv2具有各种安全威胁，如第3.3节所述。它们将在下一小节所述的有限条件下使用。
PPP can provide mutual authentication between the SI and SC using CHAP [RFC1994] during the connection-establishment phase (via the Link Control Protocol, LCP). PPP CHAP authentication can be used when the SI and SC are on a trusted, non-public IP network.
PPP可以在连接建立阶段（通过链路控制协议LCP）使用CHAP[RFC1994]在SI和SC之间提供相互认证。当SI和SC位于受信任的非公共IP网络上时，可以使用PPP CHAP身份验证。
Since CHAP does not provide per-packet authentication, integrity, or replay protection, PPP CHAP authentication MUST NOT be used unprotected on a public IP network. If other appropriate protected mechanisms have been already applied, PPP CHAP authentication MAY be used.
由于CHAP不提供每包身份验证、完整性或重播保护，因此PPP CHAP身份验证不得在公共IP网络上无保护地使用。如果已经应用了其他适当的受保护机制，则可以使用PPP CHAP身份验证。
Optionally, other authentication methods such as PAP, MS-CHAP, and EAP MAY be supported.
可选地，可以支持其他认证方法，例如PAP、MS-CHAP和EAP。
L2TPv2 provides an optional CHAP-like tunnel authentication during the control connection establishment [RFC2661], Section 5.1.1. L2TPv2 authentication MUST NOT be used unprotected on a public IP network, similar to the same restriction applied to PPP CHAP authentication.
L2TPv2在控制连接建立[RFC2661]第5.1.1节期间提供可选的CHAP类隧道身份验证。L2TPv2身份验证不得在公共IP网络上不受保护地使用，类似于应用于PPP CHAP身份验证的相同限制。
To meet the above requirements, all softwire-security-compliant implementations MUST implement the following security protocols.
为满足上述要求，所有符合softwire安全性的实施必须实施以下安全协议。
IPsec ESP [RFC4303] in transport mode is used for securing softwire control and data packets. The Internet Key Exchange (IKE) protocol [RFC4306] MUST be supported for authentication, security association negotiation, and key management for IPsec. The applicability of different versions of IKE is discussed in Section 3.5.
传输模式下的IPsec ESP[RFC4303]用于保护软线控制和数据包。IPsec的身份验证、安全关联协商和密钥管理必须支持Internet密钥交换（IKE）协议[RFC4306]。第3.5节讨论了不同版本IKE的适用性。
The softwire security protocol MUST support NAT traversal. UDP encapsulation of IPsec ESP packets[RFC3948] and negotiation of NAT-traversal in IKE [RFC3947] MUST be supported when IPsec is used.
软线安全协议必须支持NAT穿越。使用IPsec时，必须支持IPsec ESP数据包[RFC3948]的UDP封装和IKE[RFC3947]中NAT遍历的协商。
When the softwire "Hubs and Spokes" solution implemented by L2TPv2 is used in an untrustworthy network, softwire MUST be protected by appropriate security protocols, such as IPsec. This section provides guidelines for the usage of IPsec in L2TPv2-based softwire.
当L2TPv2实现的软线“集线器和辐条”解决方案用于不可信网络时，软线必须受到适当的安全协议（如IPsec）的保护。本节提供了在基于L2TPv2的软线中使用IPsec的指南。
[RFC3193] discusses how L2TP can use IKE [RFC2409] and IPsec [RFC2401] to provide tunnel authentication, privacy protection,
[RFC3193]讨论L2TP如何使用IKE[RFC2409]和IPsec[RFC2401]提供隧道身份验证、隐私保护、，
integrity checking, and replay protection. Since the publication of [RFC3193], the revisions to IPsec protocols have been published (IKEv2 [RFC4306], ESP [RFC4303], NAT-traversal for IKE [RFC3947], and ESP [RFC3948]).
完整性检查和重播保护。自[RFC3193]发布以来，IPsec协议的修订版已经发布（IKEv2[RFC4306]、ESP[RFC4303]、IKE的NAT遍历[RFC3947]和ESP[RFC3948]）。
Given that deployed technology must be very strongly considered [RFC4925] for the 'time-to-market' solution, [RFC3193] MUST be supported. However, the new implementation SHOULD use IKEv2 [RFC4306] for IPsec because of the numerous advantages it has over IKE [RFC2409]. In new deployments, IKEv2 SHOULD be used as well.
鉴于“上市时间”解决方案必须充分考虑部署的技术[RFC4925]，必须支持[RFC3193]。然而，新的实现应该将IKEv2[RFC4306]用于IPsec，因为它比IKE[RFC2409]具有许多优势。在新的部署中，也应该使用IKEv2。
Although [RFC3193] can be applied in the softwire "Hubs and Spokes" solution, softwire requirements such as NAT-traversal, NAT-traversal for IKE [RFC3947], and ESP [RFC3948] MUST be supported.
尽管[RFC3193]可应用于软线“集线器和辐条”解决方案，但必须支持诸如NAT遍历、IKE的NAT遍历[RFC3947]和ESP[RFC3948]等软线要求。
Meanwhile, IKEv2 [RFC4306] integrates NAT-traversal. IKEv2 also supports EAP authentication, with the authentication using shared secrets (pre-shared key) or a public key signature (certificate).
同时，IKEv2[RFC4306]集成了NAT遍历。IKEv2还支持EAP身份验证，使用共享秘密（预共享密钥）或公钥签名（证书）进行身份验证。
The selection of pre-shared key or certificate depends on the scale of the network for which softwire is to be deployed, as described in Section 3.5.2. However, pre-shared keys and certificates only support the machine authentication. When both machine and user authentications are required as, for example, in the nomadic case, EAP SHOULD be used.
如第3.5.2节所述，预共享密钥或证书的选择取决于要部署软线的网络规模。但是，预共享密钥和证书仅支持机器身份验证。当需要机器和用户身份验证时，例如在游牧情况下，应使用EAP。
Together with EAP, IKEv2 [RFC4306] supports legacy authentication methods that may be useful in environments where username- and password-based authentication is already deployed.
IKEv2[RFC4306]与EAP一起支持传统的身份验证方法，这些方法在已经部署了基于用户名和密码的身份验证的环境中可能很有用。
IKEv2 is a more reliable protocol than IKE [RFC2409] in terms of replay-protection capability, DoS-protection-enabled mechanism, etc. Therefore, new implementations SHOULD use IKEv2 over IKE.
就重播保护能力、DoS保护启用机制等而言，IKEv2是比IKE[RFC2409]更可靠的协议。因此，新的实现应该在IKE上使用IKEv2。
The following sections will discuss using IPsec to protect L2TPv2 as applied in the softwire "Hubs and Spokes" model. Unless otherwise stated, IKEv2 and the new IPsec architecture [RFC4301] is assumed.
以下各节将讨论使用IPsec保护L2TPv2，如软线“集线器和辐条”模型中所应用的那样。除非另有说明，否则假定IKEv2和新的IPsec体系结构[RFC4301]。
IPsec implementation using IKE only supports machine authentication. There is no way to verify a user identity and to segregate the tunnel traffic among users in the multi-user machine environment. IKEv2 can support user authentication with EAP payload by leveraging the existing authentication infrastructure and credential database. This enables traffic segregation among users when user authentication is used by combining the legacy authentication. The user identity asserted within IKEv2 will be verified on a per-packet basis.
使用IKE的IPsec实现仅支持机器身份验证。在多用户机器环境中，无法验证用户身份并在用户之间隔离隧道通信。IKEv2可以利用现有的身份验证基础设施和凭证数据库，支持使用EAP负载的用户身份验证。当通过组合传统身份验证使用用户身份验证时，这将启用用户之间的流量隔离。IKEv2中声明的用户身份将在每个数据包的基础上进行验证。
If the AAA server is involved in security association establishment between the SI and SC, a session key can be derived from the authentication between the SI and the AAA server. Successful EAP exchanges within IKEv2 run between the SI and the AAA server to create a session key, which is securely transferred to the SC from the AAA server. The trust relationship between the involved entities follows Section 3.2 of this document.
如果AAA服务器参与SI和SC之间的安全关联建立，则可以从SI和AAA服务器之间的身份验证中导出会话密钥。IKEv2中成功的EAP交换在SI和AAA服务器之间运行，以创建会话密钥，该密钥从AAA服务器安全地传输到SC。相关实体之间的信任关系遵循本文件第3.2节。
With IPsec, when the identity asserted in IKE is authenticated, the resulting derived keys are used to provide per-packet authentication, integrity, and replay protection. As a result, the identity verified in the IKE is subsequently verified on reception of each packet.
对于IPsec，当IKE中声明的身份经过身份验证时，生成的派生密钥用于提供每个数据包的身份验证、完整性和重播保护。结果，随后在接收到每个分组时验证在IKE中验证的身份。
Authentication using pre-shared keys can be used when the number of SI and SC is small. As the number of SI and SC grows, pre-shared keys become increasingly difficult to manage. A softwire security protocol MUST provide a scalable approach to key management. Whenever possible, authentication with certificates is preferred.
当SI和SC的数量较少时，可以使用使用预共享密钥的身份验证。随着SI和SC数量的增加，预共享密钥变得越来越难以管理。软线安全协议必须提供可扩展的密钥管理方法。只要可能，最好使用证书进行身份验证。
When pre-shared keys are used, group pre-shared keys MUST NOT be used because of its vulnerability to man-in-the-middle attacks ([RFC3193], Section 5.1.4).
使用预共享密钥时，不得使用组预共享密钥，因为其易受中间人攻击（[RFC3193]，第5.1.4节）。
The L2TPv2/IPsec inter-operability concerning tunnel teardown, fragmentation, and per-packet security checks given in [RFC3193], Section 3 must be taken into account.
必须考虑[RFC3193]第3节中给出的L2TPv2/IPsec关于隧道拆卸、碎片和每包安全检查的互操作性。
Although the L2TP specification allows the responder (SC in softwire) to use a new IP address or to change the port number when sending the Start-Control-Connection-Request-Reply (SCCRP), a softwire concentrator implementation SHOULD NOT do this ([RFC3193], Section 4).
尽管L2TP规范允许应答器（软线中的SC）在发送启动控制连接请求应答（SCCRP）时使用新的IP地址或更改端口号，但软线集中器实现不应这样做（[RFC3193]，第4节）。
However, for some reasons, for example, "load-balancing" between SCs, the IP address change is required. To signal an IP address change, the SC sends a StopCCN message to the SI using the Result and Error Code AVP in an L2TPv2 message. A new IKE_SA and CHILD_SA MUST be established to the new IP address.
但是，由于某些原因，例如SCs之间的“负载平衡”，需要更改IP地址。为了发出IP地址更改的信号，SC使用L2TPv2消息中的结果和错误代码AVP向SI发送StopCCN消息。必须为新的IP地址建立新的IKE_SA和CHILD_SA。
Since ESP transport mode is used, the UDP header carrying the L2TP packet will have an incorrect checksum due to the change of parts of the IP header during transit. Section 3.1.2 of [RFC3948] defines 3 procedures that can be used to fix the checksum. A softwire implementation MUST NOT use the "incremental update of checksum"
由于使用了ESP传输模式，由于传输过程中IP报头的部分更改，因此承载L2TP数据包的UDP报头的校验和将不正确。[RFC3948]第3.1.2节定义了3个可用于固定校验和的程序。软线实现不得使用“校验和增量更新”
(option 1 described in [RFC3948]) because IKEv2 does not have the information required (NAT-OA payload) to compute that checksum. Since ESP is already providing validation on the L2TP packet, a simple approach is to use the "do not check" approach (option 3 in [RFC3948]).
（选项1在[RFC3948]中描述），因为IKEv2没有计算该校验和所需的信息（NAT-OA有效载荷）。由于ESP已经在L2TP数据包上提供验证，一种简单的方法是使用“不检查”方法（RFC3948中的选项3）。
If the old IPsec architecture [RFC2401] and IKE [RFC2409] are used, the security policy database (SPD) examples in [RFC3193], Appendix A can be applied to softwire model. In that case, the initiator is always the client (SI), and the responder is the SC. IPsec SPD examples for IKE [RFC2409] are also given in Appendix A of this document.
如果使用旧的IPsec体系结构[RFC2401]和IKE[RFC2409]，则附录A[RFC3193]中的安全策略数据库（SPD）示例可应用于软线模型。在这种情况下，发起方始终是客户机（SI），响应方是SC。IKE[RFC2409]的IPsec SPD示例也在本文档附录A中给出。
The revised IPsec architecture [RFC4301] redefined the SPD entries to provide more flexibility (multiple selectors per entry, list of address range, peer authentication database (PAD), "populate from packet" (PFP) flag, etc.). The Internet Key Exchange (IKE) has also been revised and simplified in IKEv2 [RFC4306]. The following sections provide the SPD examples for softwire to use the revised IPsec architecture and IKEv2.
修订后的IPsec体系结构[RFC4301]重新定义了SPD条目，以提供更大的灵活性（每个条目有多个选择器、地址范围列表、对等身份验证数据库（PAD）、“从数据包填充”（PFP）标志等）。互联网密钥交换（IKE）也在IKEv2[RFC4306]中进行了修订和简化。以下各节提供了softwire使用经修订的IPsec体系结构和IKEv2的SPD示例。
If IKEv2 is used as the key management protocol, [RFC4301] provides the guidance of the SPD entries. In IKEv2, we can use the PFP flag to specify the SA, and the port number can be selected with the TSr (Traffic Selector - Responder) payload during CREATE_CHILD_SA. The following describes PAD entries on the SI and SC, respectively. The PAD entries are only example configurations. The PAD entry on the SC matches user identities to the L2TP SPD entry. This is done using a symbolic name type specified in [RFC4301].
如果将IKEv2用作密钥管理协议，[RFC4301]提供SPD条目指南。在IKEv2中，我们可以使用PFP标志指定SA，并且可以在创建子SA期间使用TSr（流量选择器-响应器）负载选择端口号。下面分别介绍SI和SC上的PAD条目。焊盘条目仅为示例配置。SC上的PAD条目将用户身份与L2TP SPD条目相匹配。这是使用[RFC4301]中指定的符号名称类型完成的。
SI PAD: - IF remote_identity = SI_identity Then authenticate (shared secret/certificate/) and authorize CHILD_SA for remote address SC_address
SI PAD:-如果remote_identity=SI_identity，则对远程地址SC_地址进行身份验证（共享机密/证书/）并授权子_SA
SC PAD: - IF remote_identity = user_1 Then authenticate (shared secret/certificate/EAP) and authorize CHILD_SAs for symbolic name "l2tp_spd_entry"
SC PAD:-如果远程\u标识=用户\u 1，则对符号名“l2tp\u spd\u条目”进行身份验证（共享机密/证书/EAP）并授权子级\u SA
The following describes the SPD entries for the SI and SC, respectively. Note that IKEv2 and ESP traffic MUST be allowed (bypass). These include IP protocol 50 and UDP port 500 and 4500.
以下分别描述了SI和SC的SPD条目。注意，必须允许IKEv2和ESP流量（旁路）。其中包括IP协议50、UDP端口500和4500。
The IPv4 packet format when ESP protects and L2TPv2 carries an IPv6 packet is shown in Table 1, which is similar to Table 1 in [RFC4891].
ESP保护且L2TPv2承载IPv6数据包时的IPv4数据包格式如表1所示，类似于[RFC4891]中的表1。
+----------------------------+------------------------------------+
| Components (first to last) | Contains |
+----------------------------+------------------------------------+
| IPv4 header | (src = IPv4-SI, dst = IPv4-SC) |
| ESP header | |
| UDP header | (src port=1701, dst port=1701) |
| L2TPv2 header | |
| PPP header | |
| IPv6 header | |
| (payload) | |
| ESP ICV | |
+----------------------------+------------------------------------+
+----------------------------+------------------------------------+
| Components (first to last) | Contains |
+----------------------------+------------------------------------+
| IPv4 header | (src = IPv4-SI, dst = IPv4-SC) |
| ESP header | |
| UDP header | (src port=1701, dst port=1701) |
| L2TPv2 header | |
| PPP header | |
| IPv6 header | |
| (payload) | |
| ESP ICV | |
+----------------------------+------------------------------------+
Table 1: Packet Format for L2TPv2 with ESP Carrying IPv6 Packet
表1：ESP携带IPv6数据包的L2TPv2数据包格式
SPD for Softwire Initiator:
软线启动器的SPD：
Softwire Initiator SPD-S - IF local_address=IPv4-SI remote_address=IPv4-SC Next Layer Protocol=UDP local_port=1701 remote_port=ANY (PFP=1) Then use SA ESP transport mode Initiate using IDi = user_1 to address IPv4-SC
软线启动器SPD-S-如果本地_地址=IPv4 SI远程_地址=IPv4 SC下一层协议=UDP本地_端口=1701远程_端口=任意（PFP=1），则使用SA ESP传输模式Initiate使用IDi=用户_1来寻址IPv4 SC
SPD for Softwire Concentrator:
软线集中器的SPD：
Softwire Concentrator SPD-S - IF name="l2tp_spd_entry" local_address=IPv4-SC remote_address=ANY (PFP=1) Next Layer Protocol=UDP local_port=1701 remote_port=ANY (PFP=1) Then use SA ESP transport mode
软线集中器SPD-S-如果name=“l2tp\U SPD\U条目”本地\U地址=IPv4 SC远程\U地址=任意（PFP=1）下一层协议=UDP本地\U端口=1701远程\U端口=任意（PFP=1），则使用SA ESP传输模式
The PAD entries for SI and SC are shown as examples. These example configurations are similar to those in Section 3.5.4.1 of this document.
SI和SC的PAD条目如示例所示。这些示例配置与本文件第3.5.4.1节中的配置类似。
SI PAD: - IF remote_identity = SI_identity Then authenticate (shared secret/certificate/) and authorize CHILD_SA for remote address SC_address
SI PAD:-如果remote_identity=SI_identity，则对远程地址SC_地址进行身份验证（共享机密/证书/）并授权子_SA
SC PAD: - IF remote_identity = user_2 Then authenticate (shared secret/certificate/EAP) and authorize CHILD_SAs for symbolic name "l2tp_spd_entry"
SC PAD:-如果远程\u标识=用户\u 2，则对符号名“l2tp\u spd\u条目”进行身份验证（共享机密/证书/EAP）并授权子级\u SA
The following describes the SPD entries for the SI and SC, respectively. In this example, the SI and SC are denoted with IPv6 addresses IPv6-SI and IPv6-SC, respectively. Note that IKEv2 and ESP traffic MUST be allowed (bypass). These include IP protocol 50 and UDP port 500 and 4500.
以下分别描述了SI和SC的SPD条目。在此示例中，SI和SC分别用IPv6地址IPv6 SI和IPv6 SC表示。注意，必须允许IKEv2和ESP流量（旁路）。其中包括IP协议50、UDP端口500和4500。
The IPv6 packet format when ESP protects and L2TPv2 carries an IPv4 packet is shown in Table 2, which is similar to Table 1 in [RFC4891].
ESP保护且L2TPv2承载IPv4数据包时的IPv6数据包格式如表2所示，类似于[RFC4891]中的表1。
+----------------------------+------------------------------------+
| Components (first to last) | Contains |
+----------------------------+------------------------------------+
| IPv6 header | (src = IPv6-SI, dst = IPv6-SC) |
| ESP header | |
| UDP header | (src port=1701, dst port=1701) |
| L2TPv2 header | |
| PPP header | |
| IPv4 header | |
| (payload) | |
| ESP ICV | |
+----------------------------+------------------------------------+
+----------------------------+------------------------------------+
| Components (first to last) | Contains |
+----------------------------+------------------------------------+
| IPv6 header | (src = IPv6-SI, dst = IPv6-SC) |
| ESP header | |
| UDP header | (src port=1701, dst port=1701) |
| L2TPv2 header | |
| PPP header | |
| IPv4 header | |
| (payload) | |
| ESP ICV | |
+----------------------------+------------------------------------+
Table 2: Packet Format for L2TPv2 with ESP Carrying IPv4 Packet
表2：ESP携带IPv4数据包的L2TPv2的数据包格式
SPD for Softwire Initiator:
软线启动器的SPD：
Softwire Initiator SPD-S - IF local_address=IPv6-SI remote_address=IPv6-SC Next Layer Protocol=UDP local_port=1701 remote_port=ANY (PFP=1) Then use SA ESP transport mode Initiate using IDi = user_2 to address IPv6-SC
软线启动器SPD-S-如果本地_地址=IPv6 SI远程_地址=IPv6 SC下一层协议=UDP本地_端口=1701远程_端口=任意（PFP=1），则使用SA ESP传输模式Initiate使用IDi=用户_2来寻址IPv6 SC
SPD for Softwire Concentrator:
软线集中器的SPD：
Softwire Concentrator SPD-S - IF name="l2tp_spd_entry" local_address=IPv6-SC remote_address=ANY (PFP=1) Next Layer Protocol=UDP local_port=1701 remote_port=ANY (PFP=1) Then use SA ESP transport mode
软线集中器SPD-S-如果name=“l2tp\U SPD\U条目”本地\U地址=IPv6 SC远程\U地址=任意（PFP=1）下一层协议=UDP本地\U端口=1701远程\U端口=任意（PFP=1），则使用SA ESP传输模式
In the softwire "Mesh" solution ([RFC4925], [RFC5565]), it is required to establish connectivity to access network islands of one address family type across a transit core of a differing address family type. To provide reachability across the transit core, AFBRs are installed between the access network island and transit core network. These AFBRs can perform as Provider Edge routers (PE) within an autonomous system or perform peering across autonomous systems. The AFBRs establish and encapsulate softwires in a mesh to the other islands across the transit core network. The transit core network consists of one or more service providers.
在软线“网状”解决方案（[RFC4925]、[RFC5565]）中，需要建立连接，以跨不同地址族类型的传输核心访问一个地址族类型的网络孤岛。为了提供整个公交核心网的可达性，在接入网岛和公交核心网之间安装了AFBR。这些AFBR可以作为自治系统内的提供商边缘路由器（PE）执行，也可以跨自治系统执行对等。AFBR在网状结构中建立并封装软线，通过传输核心网络连接到其他岛屿。公交核心网络由一个或多个服务提供商组成。
In the softwire "Mesh" solution, a pair of PE routers (AFBRs) use BGP to exchange routing information. AFBR nodes in the transit network are Internal BGP speakers and will peer with each other directly or via a route reflector to exchange SW-encap sets, perform softwire signaling, and advertise AF access island reachability information and SW-NHOP information. If such information is advertised within an autonomous system, the AFBR node receiving them from other AFBRs does not forward them to other AFBR nodes. To exchange the information among AFBRs, the full mesh connectivity will be established.
在软线“网状”解决方案中，一对PE路由器（AFBR）使用BGP交换路由信息。公交网络中的AFBR节点是内部BGP扬声器，将直接或通过路由反射器彼此对等，以交换SW encap集、执行软线信令，并公布AF接入岛可达性信息和SW-NHOP信息。如果此类信息在自治系统内发布，则从其他AFBR接收这些信息的AFBR节点不会将其转发给其他AFBR节点。为了在AFBR之间交换信息，将建立完整的网状连接。
The connectivity between CE and PE routers includes dedicated physical circuits, logical circuits (such as Frame Relay and ATM), and shared medium access (such as Ethernet-based access).
CE和PE路由器之间的连接包括专用物理电路、逻辑电路（如帧中继和ATM）和共享介质访问（如基于以太网的访问）。
When AFBRs are PE routers located at the edge of the provider core networks, this architecture is similar to the L3VPN described in [RFC4364]. The connectivity between a CE router in an access island network and a PE router in a transit network is established statically. The access islands are enterprise networks accommodated through PE routers in the provider's transit network. In this case, the access island networks are administrated by the provider's autonomous system.
当AFBR是位于提供商核心网络边缘的PE路由器时，该架构类似于[RFC4364]中描述的L3VPN。接入岛网络中的CE路由器和传输网络中的PE路由器之间的连接是静态建立的。接入岛是通过提供商传输网络中的PE路由器容纳的企业网络。在这种情况下，接入岛网络由提供商的自治系统管理。
The AFBRs may have multiple connections to the core network, and also may have connections to multiple client access networks. The client access networks may connect to each other through private networks or through the Internet. When the client access networks have their own AS number, a CE router located inside access islands forms a private BGP peering with an AFBR. Further, an AFBR may need to exchange full Internet routing information with each network to which it connects.
AFBR可以具有到核心网络的多个连接，并且还可以具有到多个客户端接入网络的连接。客户端接入网络可以通过专用网络或通过因特网相互连接。当客户端接入网络有自己的AS号时，位于接入岛内的CE路由器与AFBR形成专用BGP对等。此外，AFBR可能需要与所连接的每个网络交换完整的Internet路由信息。
All AFBR nodes in the transit core MUST have a trust relationship or an agreement with each other to establish softwires. When the transit core consists of a single administrative domain, it is assumed that all nodes (e.g., AFBR, PE, or Route Reflector, if applicable) are trusted by each other.
transit core中的所有AFBR节点必须彼此具有信任关系或协议才能建立软线。当传输核心由单个管理域组成时，假定所有节点（例如，AFBR、PE或路由反射器，如果适用）彼此信任。
If the transit core consists of multiple administrative domains, intermediate routers between AFBRs may not be trusted.
如果传输核心由多个管理域组成，AFBR之间的中间路由器可能不受信任。
There MUST be a trust relationship between the PE in the transit core and the CE in the corresponding island, although the link(s) between the PE and the CE may not be protected.
传输核心中的PE和相应岛中的CE之间必须存在信任关系，尽管PE和CE之间的链路可能不受保护。
As the architecture of the softwire mesh solution is very similar to that of the provider-provisioned VPN (PPVPN). The security threat considerations on the PPVPN operation are applicable to those in the softwire mesh solution [RFC4111].
因为softwire mesh解决方案的体系结构与提供商提供的VPN（PPVPN）非常相似。PPVPN操作的安全威胁考虑因素适用于softwire mesh解决方案[RFC4111]中的安全威胁考虑因素。
Examples of attacks to data packets being transmitted on a softwire tunnel include:
对正在软线隧道上传输的数据分组的攻击的示例包括：
1. An adversary may try to discover confidential information by sniffing softwire packets.
1. 对手可以通过嗅探软线数据包来发现机密信息。
2. An adversary may try to modify the contents of softwire packets.
2. 对手可能试图修改软线数据包的内容。
3. An adversary may try to spoof the softwire packets that do not belong to the authorized domains and to insert copies of once-legitimate packets that have been recorded and replayed.
3. 对手可能试图欺骗不属于授权域的软线数据包，并插入已记录和重播的合法数据包的副本。
4. An adversary can launch denial-of-service (DoS) attacks by deleting softwire data traffic. DoS attacks of the resource exhaustion type can be mounted against the data plane by spoofing a large amount of non-authenticated data into the softwire from the outside of the softwire tunnel.
4. 对手可以通过删除软线数据通信发起拒绝服务（DoS）攻击。通过从软线隧道外部将大量未经验证的数据欺骗到软线，可以针对数据平面发起资源耗尽类型的DoS攻击。
5. An adversary may try to sniff softwire packets and to examine 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.
5. 对手可能会尝试嗅探软线数据包，并检查其方面或元方面，即使数据包本身已加密，也可能可见。攻击者可能会根据通信量和时间、数据包大小、源地址和目标地址等获取有用信息。
The security attacks can be mounted on the control plane as well. In the softwire mesh solution, softwire encapsulation will be set up by using BGP. As described in [RFC4272], BGP is vulnerable to various security threats such as confidentiality violation; replay attacks; insertion, deletion, and modification of BGP messages; man-in-the-middle attacks; and denial-of-service attacks.
安全攻击也可以安装在控制平面上。在软线网格解决方案中，将使用BGP设置软线封装。如[RFC4272]所述，BGP容易受到各种安全威胁，如违反保密性；重放攻击；插入、删除和修改BGP消息；中间人攻击；以及拒绝服务攻击。
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 deployment.
考虑到安全通常是费用和风险之间的折衷，考虑不同攻击的可能性也是有用的。在不同部署中成功实施大多数类型攻击的可能性至少存在感知差异。
The trust relationship among users in access networks, transit core providers, and other parts of networks described in Section 4.2 is a key element in determining the applicability of the security protection mechanism for the specific softwire mesh deployment.
第4.2节中描述的接入网络、传输核心提供商和网络其他部分中的用户之间的信任关系是确定安全保护机制是否适用于特定软线网部署的关键因素。
The "Softwire Problem Statement" [RFC4925] states that the softwire mesh setup mechanism to advertise the softwire encapsulation MUST support authentication, but the transit core provider may decide to turn it off in some circumstances.
“软线问题声明”[RFC4925]指出，用于公布软线封装的软线网格设置机制必须支持身份验证，但在某些情况下，传输核心提供商可能会决定将其关闭。
The BGP authentication mechanism is specified in [RFC2385]. The mechanism defined in [RFC2385] is based on a one-way hash function (MD5) and use of a secret key. The key is shared between a pair of peer routers and is used to generate 16-byte message authentication code values that are not readily computed by an attacker who does not have access to the key.
[RFC2385]中规定了BGP身份验证机制。[RFC2385]中定义的机制基于单向散列函数（MD5）和密钥的使用。密钥在一对对等路由器之间共享，用于生成16字节的消息身份验证码值，该值不容易由无权访问密钥的攻击者计算。
However, the security mechanism for BGP transport (e.g., TCP-MD5) is inadequate in some circumstances and also requires operator interaction to maintain a respectable level of security. The current deployments of TCP-MD5 exhibit some shortcomings with respect to key management as described in [RFC3562].
然而，BGP传输的安全机制（例如TCP-MD5）在某些情况下是不充分的，并且还需要操作员交互以维持适当的安全级别。如[RFC3562]所述，当前TCP-MD5的部署在密钥管理方面存在一些缺陷。
Key management can be especially cumbersome for operators. The number of keys required and the maintenance of keys (issue/revoke/
密钥管理对于操作员来说尤其麻烦。所需钥匙数量和钥匙维护（发放/撤销）/
renew) has had an additive effect as a barrier to deployment. Thus, automated means of managing keys, to reduce operational burdens, is available in the BGP security system ([BGP-SEC], [RFC4107]).
更新）具有附加效应，成为部署的障碍。因此，BGP安全系统（[BGP-SEC]，[RFC4107]）中提供了管理密钥的自动化方法，以减少操作负担。
Use of IPsec counters the message insertion, deletion, and modification attacks, as well as man-in-the-middle attacks by outsiders. If routing data confidentiality is desired, the use of IPsec ESP could provide that service. If eavesdropping attacks are identified as a threat, ESP can be used to provide confidentiality (encryption), integrity, and authentication for the BGP session.
使用IPsec可以抵抗消息插入、删除和修改攻击，以及外部人员的中间人攻击。如果需要路由数据保密性，则使用IPsec ESP可以提供该服务。如果窃听攻击被确定为威胁，则ESP可用于为BGP会话提供机密性（加密）、完整性和身份验证。
To transport data packets across the transit core, the mesh solution defines multiple encapsulations: L2TPv3, IP-in-IP, MPLS (LDP-based and RSVP-TE based), and GRE. To securely transport such data packets, the softwire MUST support IPsec tunnel.
为了在传输核心上传输数据包，mesh解决方案定义了多种封装：L2TPv3、IP-in-IP、MPLS（基于LDP和基于RSVP-TE）和GRE。为了安全地传输此类数据包，软线必须支持IPsec隧道。
IPsec can provide authentication and integrity. The implementation MUST support ESP with null encryption [RFC4303] or else AH (IP Authentication Header) [RFC4302]. If some part of the transit core network is not trusted, ESP with encryption MAY be applied.
IPsec可以提供身份验证和完整性。实现必须支持带有空加密[RFC4303]或AH（IP身份验证头）[RFC4302]的ESP。如果公交核心网的某些部分不受信任，则可采用加密ESP。
Since the softwires are created dynamically by BGP, the automated key distribution MUST be performed by IKEv2 [RFC4306] with either pre-shared key or public key management. For dynamic softwire IPsec tunnel creation, the pre-shared key will be the same in all routers. Namely, pre-shared key indicates here "group key" instead of "pairwise-shared" key.
由于软线是由BGP动态创建的，因此自动密钥分发必须由IKEv2[RFC4306]使用预共享密钥或公钥管理来执行。对于动态软线IPsec隧道创建，所有路由器中的预共享密钥将相同。即，预共享密钥在这里表示“组密钥”，而不是“成对共享”密钥。
If security policy requires a stronger key management, the public key SHOULD be used. If a public key infrastructure is not available, the IPsec Tunnel Authentication sub-TLV specified in [RFC5566] MUST be used before SA is established.
如果安全策略需要更强的密钥管理，则应使用公钥。如果公钥基础设施不可用，则在建立SA之前必须使用[RFC5566]中指定的IPsec隧道身份验证子TLV。
If the link(s) between the user's site and the provider's PE is not trusted, then encryption MAY be used on the PE-CE link(s).
如果用户站点和提供商PE之间的链接不受信任，则可以在PE-CE链接上使用加密。
Together with the cryptographic security protection, the access-control technique reduces exposure to attacks from outside the service provider networks (transit networks). The access-control technique includes packet-by-packet or packet-flow-by-packet-flow access control by means of filters as well as by means of admitting a session for a control/signaling/management protocol that is being used to implement softwire mesh.
与加密安全保护一起，访问控制技术减少了来自服务提供商网络（传输网络）外部的攻击。访问控制技术包括通过滤波器以及通过允许用于实现软线网的控制/信令/管理协议的会话来进行逐包或逐包流访问控制。
The access-control technique is an important protection against security attacks of DoS, etc., and a necessary adjunct to
访问控制技术是防御DoS等安全攻击的重要手段，也是对网络安全的必要补充
cryptographic strength in encapsulation. Packets that match the criteria associated with a particular filter may be either discarded or given special treatment to prevent an attack or to mitigate the effect of a possible future attack.
封装中的加密强度。匹配与特定过滤器相关联的标准的分组可以被丢弃，或者被给予特殊处理以防止攻击或减轻未来可能的攻击的影响。
This document discusses various security threats for the softwire control and data packets in the "Hubs and Spokes" and "Mesh" time-to-market solutions. With these discussions, the softwire security protocol implementations are provided by referencing "Softwire Problem Statement" [RFC4925], "Securing L2TP using IPsec" [RFC3193], "Security Framework for PPVPNs" [RFC4111], and "Guidelines for Specifying the Use of IPsec" [RFC5406]. The guidelines for the security protocol employment are also given considering the specific deployment context.
本文档讨论了“集线器和辐条”和“网格”上市时间解决方案中软线控制和数据包的各种安全威胁。通过这些讨论，通过参考“软线问题声明”[RFC4925]、“使用IPsec保护L2TP”[RFC3193]、“PPVPN安全框架”[RFC4111]和“指定IPsec使用指南”[RFC5406]提供了软线安全协议的实现。考虑到具体的部署环境，还给出了安全协议使用的指导原则。
Note that this document discusses softwire tunnel security protection and does not address end-to-end protection.
请注意，本文档讨论的是软线隧道安全保护，而不是端到端保护。
The authors would like to thank Tero Kivinen for reviewing the document and Francis Dupont for substantive suggestions. Acknowledgments to Jordi Palet Martinez, Shin Miyakawa, Yasuhiro Shirasaki, and Bruno Stevant for their feedback.
作者要感谢Tero Kivinen对该文件的审查，以及Francis Dupont提出的实质性建议。感谢Jordi Palet Martinez、Shin Miyakawa、Hisuhiro Shirasaki和Bruno Stevant的反馈。
We would like also to thank the authors of the Softwire Hub & Spoke Deployment Framework document [RFC5571] for providing the text concerning security.
我们还要感谢软线中心辐射式部署框架文档[RFC5571]的作者提供了有关安全性的文本。
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
[RFC1994]辛普森，W.，“PPP挑战握手认证协议（CHAP）”，RFC 1994，1996年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385]Heffernan，A.，“通过TCP MD5签名选项保护BGP会话”，RFC 2385，1998年8月。
[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月。
[RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth, "Securing L2TP using IPsec", RFC 3193, November 2001.
[RFC3193]Patel，B.，Aboba，B.，Dixon，W.，Zorn，G.，和S.Booth，“使用IPsec保护L2TP”，RFC 3193，2001年11月。
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005.
[RFC3947]Kivinen，T.，Swander，B.，Huttunen，A.，和V.Volpe，“IKE中NAT穿越的协商”，RFC 3947，2005年1月。
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005.
[RFC3948]Huttunen，A.，Swander，B.，Volpe，V.，DiBurro，L.，和M.Stenberg，“IPsec ESP数据包的UDP封装”，RFC 3948，2005年1月。
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
[RFC4107]Bellovin，S.和R.Housley，“加密密钥管理指南”，BCP 107，RFC 4107，2005年6月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]Kent，S.，“IP认证头”，RFC43022005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]Kaufman，C.，“互联网密钥交换（IKEv2）协议”，RFC43062005年12月。
[BGP-SEC] Christian, B. and T. Tauber, "BGP Security Requirements", Work in Progress, November 2008.
[BGP-SEC]Christian，B.和T.Tauber，“BGP安全要求”，正在进行的工作，2008年11月。
[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月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999.
[RFC2607]Aboba，B.和J.Vollbrecht，“漫游中的代理链接和策略实施”，RFC 2607，1999年6月。
[RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 Signature Option", RFC 3562, July 2003.
[RFC3562]Leech，M.，“TCP MD5签名选项的密钥管理注意事项”，RFC 3562，2003年7月。
[RFC4016] Parthasarathy, M., "Protocol for Carrying Authentication and Network Access (PANA) Threat Analysis and Security Requirements", RFC 4016, March 2005.
[RFC4016]Parthasarathy，M.“承载身份验证和网络访问协议（PANA）威胁分析和安全要求”，RFC4016，2005年3月。
[RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next Steps in Signaling (NSIS)", RFC 4081, June 2005.
[RFC4081]Tschofenig，H.和D.Kroeselberg，“信令（NSIS）下一步的安全威胁”，RFC 40812005年6月。
[RFC4111] Fang, L., "Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4111, July 2005.
[RFC4111]Fang，L.“提供商提供的虚拟专用网络（PPVPN）的安全框架”，RFC 4111，2005年7月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213]Nordmark，E.和R.Gilligan，“IPv6主机和路由器的基本转换机制”，RFC 4213，2005年10月。
[RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. Nordmark, "Mobile IP Version 6 Route Optimization Security Design Background", RFC 4225, December 2005.
[RFC4225]Nikander，P.，Arkko，J.，Aura，T.，黑山，G.，和E.Nordmark，“移动IP版本6路由优化安全设计背景”，RFC 42252005年12月。
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, January 2006.
[RFC4272]Murphy，S.，“BGP安全漏洞分析”，RFC 4272，2006年1月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]Rosen，E.和Y.Rekhter，“BGP/MPLS IP虚拟专用网络（VPN）”，RFC 4364，2006年2月。
[RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, October 2006.
[RFC4593]Barbir，A.，Murphy，S.，和Y.Yang，“路由协议的一般威胁”，RFC 4593，2006年10月。
[RFC4891] Graveman, R., Parthasarathy, M., Savola, P., and H. Tschofenig, "Using IPsec to Secure IPv6-in-IPv4 Tunnels", RFC 4891, May 2007.
[RFC4891]Graveman，R.，Parthasarathy，M.，Savola，P.，和H.Tschofenig，“使用IPsec保护IPv4隧道中的IPv6”，RFC 4891，2007年5月。
[RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire Problem Statement", RFC 4925, July 2007.
[RFC4925]Li，X.，Dawkins，S.，Ward，D.，和A.Durand，“软线问题声明”，RFC 49252007年7月。
[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication Protocol", RFC 5216, March 2008.
[RFC5216]Simon，D.，Aboba，B.和R.Hurst，“EAP-TLS认证协议”，RFC 5216，2008年3月。
[RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec Version 2", BCP 146, RFC 5406, February 2009.
[RFC5406]Bellovin，S.，“指定IPsec版本2使用的指南”，BCP 146，RFC 5406，2009年2月。
[RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh Framework", RFC 5565, June 2009.
[RFC5565]Wu，J.，Cui，Y.，Metz，C.和E.Rosen，“软线网格框架”，RFC 55652009年6月。
[RFC5566] Berger, L., White, R., and E. Rosen, "BGP IPsec Tunnel Encapsulation Attribute", RFC 5566, June 2009.
[RFC5566]Berger，L.，White，R.，和E.Rosen，“BGP IPsec隧道封装属性”，RFC 5566，2009年6月。
[RFC5571] Storer, B., Pignataro, C., Dos Santos, M., Stevant, B., Toutain, L., and J. Tremblay, "Softwire Hub and Spoke Deployment Framework with Layer Two Tunneling Protocol Version 2 (L2TPv2)", RFC 5571, June 2009.
[RFC5571]Storer，B.，Pignataro，C.，Dos Santos，M.，Stevant，B.，Toutain，L.，和J.Tremblay，“具有第二层隧道协议版本2（L2TPv2）的软线中心辐射部署框架”，RFC 55712009年6月。
If the old IPsec architecture [RFC2401] and IKE [RFC2409] are used, the SPD examples in [RFC3193] are applicable to the "Hub & Spokes" model. In this model, the initiator is always the client (SI), and the responder is the SC.
如果使用旧的IPsec体系结构[RFC2401]和IKE[RFC2409]，则[RFC3193]中的SPD示例适用于“集线器和辐条”模型。在此模型中，发起方始终是客户机（SI），响应方是SC。
IPv4 addresses of the softwire initiator and concentrator are denoted by IPv4-SI and IPv4-SC, respectively. If NAT traversal is used in IKE, UDP source and destination ports are 4500. In this SPD entry, IKE refers to UDP port 500. * denotes wildcard and indicates ANY port or address.
软线启动器和集中器的IPv4地址分别由IPv4 SI和IPv4 SC表示。如果在IKE中使用NAT遍历，则UDP源端口和目标端口为4500。在此SPD条目中，IKE指UDP端口500。*表示通配符并表示任何端口或地址。
Local Remote Protocol Action
----- ------ -------- ------
IPV4-SI IPV4-SC ESP BYPASS
IPV4-SI IPV4-SC IKE BYPASS
IPv4-SI IPV4-SC UDP, src 1701, dst 1701 PROTECT(ESP,
transport)
IPv4-SC IPv4-SI UDP, src * , dst 1701 PROTECT(ESP,
transport)
Local Remote Protocol Action
----- ------ -------- ------
IPV4-SI IPV4-SC ESP BYPASS
IPV4-SI IPV4-SC IKE BYPASS
IPv4-SI IPV4-SC UDP, src 1701, dst 1701 PROTECT(ESP,
transport)
IPv4-SC IPv4-SI UDP, src * , dst 1701 PROTECT(ESP,
transport)
Softwire Initiator SPD
软线启动器
Remote Local Protocol Action
------ ------ -------- ------
* IPV4-SC ESP BYPASS
* IPV4-SC IKE BYPASS
* IPV4-SC UDP, src * , dst 1701 PROTECT(ESP,
transport)
Remote Local Protocol Action
------ ------ -------- ------
* IPV4-SC ESP BYPASS
* IPV4-SC IKE BYPASS
* IPV4-SC UDP, src * , dst 1701 PROTECT(ESP,
transport)
Softwire Concentrator SPD
软线集中器
IPv6 addresses of the softwire initiator and concentrator are denoted by IPv6-SI and IPv6-SC, respectively. If NAT traversal is used in IKE, UDP source and destination ports are 4500. In this SPD entry, IKE refers to UDP port 500. * denotes wildcard and indicates ANY port or address.
软线启动器和集中器的IPv6地址分别由IPv6 SI和IPv6 SC表示。如果在IKE中使用NAT遍历，则UDP源端口和目标端口为4500。在此SPD条目中，IKE指UDP端口500。*表示通配符并表示任何端口或地址。
Local Remote Protocol Action
----- ------ -------- ------
IPV6-SI IPV6-SC ESP BYPASS
IPV6-SI IPV6-SC IKE BYPASS
IPv6-SI IPV6-SC UDP, src 1701, dst 1701 PROTECT(ESP,
transport)
IPv6-SC IPv6-SI UDP, src * , dst 1701 PROTECT(ESP,
transport)
Local Remote Protocol Action
----- ------ -------- ------
IPV6-SI IPV6-SC ESP BYPASS
IPV6-SI IPV6-SC IKE BYPASS
IPv6-SI IPV6-SC UDP, src 1701, dst 1701 PROTECT(ESP,
transport)
IPv6-SC IPv6-SI UDP, src * , dst 1701 PROTECT(ESP,
transport)
Softwire Initiator SPD
软线启动器
Remote Local Protocol Action
------ ------ -------- ------
* IPV6-SC ESP BYPASS
* IPV6-SC IKE BYPASS
* IPV6-SC UDP, src * , dst 1701 PROTECT(ESP,
transport)
Remote Local Protocol Action
------ ------ -------- ------
* IPV6-SC ESP BYPASS
* IPV6-SC IKE BYPASS
* IPV6-SC UDP, src * , dst 1701 PROTECT(ESP,
transport)
Softwire Concentrator SPD
软线集中器
Authors' Addresses
作者地址
Shu Yamamoto NICT/KDDI R&D Labs 1-13-16 Hakusan, Bunkyo-ku Tokyo 113-0001 Japan
日本东京本岛箱山1-13-16号山本町NICT/KDDI研发实验室113-0001
Phone: +81-3-3868-6913
EMail: shu@nict.go.jp
Phone: +81-3-3868-6913
EMail: shu@nict.go.jp
Carl Williams KDDI R&D Labs Palo Alto, CA 94301 USA
卡尔·威廉姆斯KDDI研发实验室美国加利福尼亚州帕洛阿尔托94301
Phone: +1-650-279-5903
EMail: carlw@mcsr-labs.org
Phone: +1-650-279-5903
EMail: carlw@mcsr-labs.org
Hidetoshi Yokota KDDI R&D Labs 2-1-15 Ohara Fujimino, Saitama 356-8502 Japan
横田英寿KDDI研发实验室2-1-15日本柴达木大原藤美浓356-8502
Phone: +81-49-278-7894
EMail: yokota@kddilabs.jp
Phone: +81-49-278-7894
EMail: yokota@kddilabs.jp
Florent Parent Beon Solutions Quebec, QC Canada
Florent Parent Beon Solutions加拿大魁北克省
EMail: Florent.Parent@beon.ca
EMail: Florent.Parent@beon.ca