Internet Engineering Task Force (IETF) V. Manral
Request for Comments: 7018 HP
Category: Informational S. Hanna
ISSN: 2070-1721 Juniper
September 2013
Internet Engineering Task Force (IETF) V. Manral
Request for Comments: 7018 HP
Category: Informational S. Hanna
ISSN: 2070-1721 Juniper
September 2013
Auto-Discovery VPN Problem Statement and Requirements
自动发现VPN问题陈述和要求
Abstract
摘要
This document describes the problem of enabling a large number of systems to communicate directly using IPsec to protect the traffic between them. It then expands on the requirements for such a solution.
本文档描述了使大量系统能够使用IPsec直接通信以保护它们之间的通信量的问题。然后，它扩展了这种解决方案的需求。
Manual configuration of all possible tunnels is too cumbersome in many such cases. In other cases, the IP addresses of endpoints change, or the endpoints may be behind NAT gateways, making static configuration impossible. The Auto-Discovery VPN solution will address these requirements.
在许多此类情况下，手动配置所有可能的隧道过于繁琐。在其他情况下，端点的IP地址会发生变化，或者端点可能位于NAT网关后面，从而无法进行静态配置。自动发现VPN解决方案将满足这些要求。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7018.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7018.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Terminology ................................................3
1.2. Conventions Used in This Document ..........................4
2. Use Cases .......................................................4
2.1. Use Case 1: Endpoint-to-Endpoint VPN .......................4
2.2. Use Case 2: Gateway-to-Gateway VPN .........................5
2.3. Use Case 3: Endpoint-to-Gateway VPN ........................6
3. Inadequacy of Existing Solutions ................................6
3.1. Exhaustive Configuration ...................................6
3.2. Star Topology ..............................................6
3.3. Proprietary Approaches .....................................7
4. Requirements ....................................................7
4.1. Gateway and Endpoint Requirements ..........................7
5. Security Considerations ........................................11
6. Acknowledgements ...............................................11
7. Normative References ...........................................12
1. Introduction ....................................................2
1.1. Terminology ................................................3
1.2. Conventions Used in This Document ..........................4
2. Use Cases .......................................................4
2.1. Use Case 1: Endpoint-to-Endpoint VPN .......................4
2.2. Use Case 2: Gateway-to-Gateway VPN .........................5
2.3. Use Case 3: Endpoint-to-Gateway VPN ........................6
3. Inadequacy of Existing Solutions ................................6
3.1. Exhaustive Configuration ...................................6
3.2. Star Topology ..............................................6
3.3. Proprietary Approaches .....................................7
4. Requirements ....................................................7
4.1. Gateway and Endpoint Requirements ..........................7
5. Security Considerations ........................................11
6. Acknowledgements ...............................................11
7. Normative References ...........................................12
IPsec [RFC4301] is used in several different cases, including tunnel-mode site-to-site VPNs and remote access VPNs. Both tunneling modes for IPsec gateways and host-to-host transport mode are supported in this document.
IPsec[RFC4301]用于几种不同的情况，包括隧道模式的站点到站点VPN和远程访问VPN。本文档支持IPsec网关的隧道模式和主机到主机传输模式。
The subject of this document is the problem presented by large-scale deployments of IPsec and the requirements on a solution to address the problem. These may be a large collection of VPN gateways connecting various sites, a large number of remote endpoints connecting to a number of gateways or to each other, or a mix of the two. The gateways and endpoints may belong to a single administrative domain or several domains with a trust relationship.
本文档的主题是IPsec的大规模部署所带来的问题以及解决该问题的解决方案的要求。这些可能是连接不同站点的大量VPN网关，连接到多个网关或彼此的大量远程端点，或者两者的混合。网关和端点可能属于单个管理域或具有信任关系的多个域。
Section 4.4 of RFC 4301 describes the major IPsec databases needed for IPsec processing. It requires extensive configuration for each tunnel, so manually configuring a system of many gateways and endpoints becomes infeasible and inflexible.
RFC 4301的第4.4节描述了IPsec处理所需的主要IPsec数据库。它需要对每个隧道进行广泛的配置，因此手动配置包含多个网关和端点的系统变得不可行且不灵活。
The difficulty is that a lot of configuration mentioned in RFC 4301 is required to set up a Security Association. The Internet Key Exchange Protocol (IKE) implementations need to know the identity and credentials of all possible peer systems, as well as the addresses of hosts and/or networks behind them. A simplified mechanism for dynamically establishing point-to-point tunnels is needed. Section 2 contains several use cases that motivate this effort.
困难在于，建立安全关联需要RFC 4301中提到的许多配置。Internet密钥交换协议（IKE）实现需要知道所有可能的对等系统的身份和凭证，以及它们背后的主机和/或网络的地址。需要一种动态建立点到点隧道的简化机制。第2节包含几个激发这一努力的用例。
Auto-Discovery Virtual Private Network (ADVPN) - A VPN solution that enables a large number of systems to communicate directly, with minimal configuration and operator intervention, using IPsec to protect communication between them.
自动发现虚拟专用网络（ADVPN）-一种VPN解决方案，它使大量系统能够直接通信，只需最少的配置和操作员干预，并使用IPsec保护它们之间的通信。
Endpoint - A device that implements IPsec for its own traffic but does not act as a gateway.
端点-为其自身流量实现IPsec但不充当网关的设备。
Gateway - A network device that implements IPsec to protect traffic flowing through the device.
网关-实现IPsec以保护流经设备的流量的网络设备。
Point-to-Point - Communication between two parties without active participation (e.g., encryption or decryption) by any other parties.
点对点-双方之间的通信，无需任何其他方的积极参与（例如加密或解密）。
Hub - The central point in a star topology/dynamic full-mesh topology, or one of the central points in the full-mesh style VPN, i.e., a gateway to which multiple other hubs or spokes connect. The hubs usually forward traffic coming from encrypted links to other encrypted links, i.e., there are no devices connected to them in the clear.
集线器-星形拓扑/动态全网状拓扑中的中心点，或全网状样式VPN中的中心点之一，即多个其他集线器或辐条连接的网关。集线器通常将来自加密链路的流量转发到其他加密链路，即，没有设备以明文形式连接到集线器。
Spoke - The endpoint in a star topology/dynamic full-mesh topology or gateway that forwards traffic from multiple cleartext devices to other hubs or spokes, and some of those other devices are connected to it in the clear (i.e., it encrypts data coming from cleartext devices and forwards it to the ADVPN).
辐条-星形拓扑/动态全网状拓扑或网关中的端点，将流量从多个明文设备转发到其他集线器或辐条，其中一些其他设备以明文方式连接到它（即，它加密来自明文设备的数据并将其转发到ADVPN）。
ADVPN Peer - Any member of an ADVPN, including gateways, endpoints, hubs, or spokes.
ADVPN对等-ADVPN的任何成员，包括网关、端点、集线器或辐条。
Star Topology - Topology in which there is direct connectivity only between the hub and spoke, and where communication between the 2 spokes happens through the hub.
星形拓扑-仅在轮毂和轮辐之间存在直接连接的拓扑，并且两条轮辐之间的通信通过轮毂进行。
Allied and Federated Environments - Environments where we have multiple different organizations that have close associations and need to connect to each other.
联合和联合环境—我们拥有多个不同组织的环境，这些组织具有密切的关联，需要相互连接。
Full-Mesh Topology - Topology in which there is direct connectivity between every spoke to every other spoke, without the traffic between the spokes having to be redirected through an intermediate hub device.
全网状拓扑-拓扑结构中，每个辐条与其他辐条之间存在直接连接，辐条之间的通信不必通过中间集线器设备重定向。
Dynamic Full-Mesh Topology - Topology in which direct connections exist in a hub-and-spoke manner but dynamic connections are created/removed between the spokes on an as-needed basis.
动态全网格拓扑-以中心辐射方式存在直接连接，但根据需要在辐条之间创建/删除动态连接的拓扑。
Security Association (SA) - Defined in [RFC4301].
安全关联（SA）-在[RFC4301]中定义。
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]中所述进行解释。
This section presents the key use cases for large-scale point-to-point VPNs.
本节介绍大规模点到点VPN的关键用例。
In all of these use cases, the participants (endpoints and gateways) may be from a single organization (administrative domain) or from multiple organizations with an established trust relationship. When multiple organizations are involved, products from multiple vendors are employed, so open standards are needed to provide interoperability. Establishing communications between participants with no established trust relationship is out of scope for this effort.
在所有这些用例中，参与者（端点和网关）可能来自单个组织（管理域），也可能来自具有已建立信任关系的多个组织。当涉及多个组织时，将使用来自多个供应商的产品，因此需要开放标准来提供互操作性。在没有建立信任关系的参与者之间建立沟通超出了这项工作的范围。
Two endpoints wish to communicate securely via a point-to-point SA.
两个端点希望通过点对点SA进行安全通信。
The need for secure endpoint-to-endpoint communications is often driven by a need to employ high-bandwidth, low-latency local connectivity instead of using slow, expensive links to remote gateways. For example, two users in close proximity may wish to place a direct, secure video or voice call without needing to send
对安全端点到端点通信的需求通常是由于需要使用高带宽、低延迟的本地连接，而不是使用到远程网关的缓慢、昂贵的链路。例如，两个近在咫尺的用户可能希望在无需发送的情况下拨打直接、安全的视频或语音电话
the call through remote gateways, as the remote gateways would add latency to the call, consume precious remote bandwidth, and increase overall costs. Such a use case also enables connectivity when both users are behind NAT gateways. Such a use case ought to allow for seamless connectivity even as endpoints roam and even if they are moving out from behind a NAT gateway, from behind one NAT gateway to behind another, or from a standalone position to behind a NAT gateway.
通过远程网关的呼叫，因为远程网关会增加呼叫延迟，消耗宝贵的远程带宽，并增加总体成本。当两个用户都在NAT网关后面时，这样的用例还支持连接。这样的用例应该允许无缝连接，即使端点漫游，即使它们从NAT网关后面移动，从一个NAT网关后面移动到另一个NAT网关后面，或者从独立位置移动到NAT网关后面。
In a star topology, when two endpoints communicate, they need a mechanism for authentication such that they do not expose themselves to impersonation by the other spoke endpoint.
在星型拓扑中，当两个端点通信时，它们需要一种身份验证机制，这样它们就不会暴露给另一个端点的模拟。
A typical Enterprise traffic model follows a star topology, with the gateways connecting to each other using IPsec tunnels.
典型的企业流量模型遵循星形拓扑，网关使用IPsec隧道相互连接。
However, for voice and other rich media traffic that require a lot of bandwidth or is performance sensitive, the traffic tromboning (taking a suboptimal path) to the hub can create traffic bottlenecks on the hub and can lead to an increase in cost. A fully meshed solution would make best use of the available network capacity and performance, but the deployment of a fully meshed solution involves considerable configuration, especially when a large number of nodes are involved. It is for this purpose that spoke-to-spoke tunnels are dynamically created and torn down. For the reasons of cost and manual error reduction, it is desired that there be minimal configuration on each gateway.
但是，对于需要大量带宽或对性能敏感的语音和其他富媒体流量，到集线器的流量长号（采用次优路径）可能会在集线器上造成流量瓶颈，并可能导致成本增加。完全网格化解决方案将充分利用可用的网络容量和性能，但部署完全网格化解决方案需要大量配置，特别是当涉及大量节点时。正是出于这一目的，动态创建并拆除了辐射对辐射隧道。出于成本和手动错误减少的原因，希望每个网关上的配置最少。
The solution ought to work in cases where the endpoints are in different administrative domains that have an existing trust relationship (for example, two organizations that are collaborating on a project may wish to join their networks while retaining independent control over configuration). It is highly desirable that the solution works for the star, full-mesh, and dynamic full-mesh topologies.
解决方案应该适用于端点位于具有现有信任关系的不同管理域中的情况（例如，在项目上协作的两个组织可能希望加入其网络，同时保留对配置的独立控制）。非常希望该解决方案适用于星形、全网格和动态全网格拓扑。
The solution ought to also address the case where gateways use dynamic IP addresses.
解决方案还应该解决网关使用动态IP地址的情况。
Additionally, the routing implications of gateway-to-gateway communication need to be addressed. In the simple case, selectors provide sufficient information for a gateway to forward traffic appropriately. In other cases, additional tunneling (e.g., Generic Routing Encapsulation (GRE)) and routing (e.g., Open Shortest Path First (OSPF)) protocols are run over IPsec tunnels, and the configuration impact on those protocols needs to be considered.
此外，需要解决网关到网关通信的路由问题。在简单的情况下，选择器为网关提供足够的信息以适当地转发流量。在其他情况下，额外的隧道（例如，通用路由封装（GRE））和路由（例如，开放最短路径优先（OSPF））协议在IPsec隧道上运行，并且需要考虑对这些协议的配置影响。
There is also the case where Layer 3 Virtual Private Networks (L3VPNs) operate over IPsec tunnels.
还有第3层虚拟专用网络（L3VPN）通过IPsec隧道运行的情况。
When two gateways communicate, they need to use a mechanism for authentication such that they do not expose themselves to the risk of impersonation by the other entities.
当两个网关进行通信时，它们需要使用一种身份验证机制，这样它们就不会面临被其他实体冒充的风险。
A mobile endpoint ought to be able to use the most efficient gateway as it roams in the Internet.
移动终端在互联网上漫游时应该能够使用最高效的网关。
A mobile user roaming on the Internet may connect to a gateway that, because of roaming, is no longer the most efficient gateway to use (reasons could be cost, efficiency, latency, or some other factor). The mobile user ought to be able to discover and then connect to the current, most efficient gateway in a seamless way without having to bring down the connection.
在Internet上漫游的移动用户可能会连接到网关，该网关由于漫游而不再是最有效的网关（原因可能是成本、效率、延迟或其他一些因素）。移动用户应该能够发现并以无缝方式连接到当前最高效的网关，而无需中断连接。
Several solutions exist for the problems described above. However, none of these solutions is adequate, as described here.
对于上述问题，存在几种解决方案。然而，如本文所述，这些解决方案都不充分。
One simple solution is to configure all gateways and endpoints in advance with all the information needed to determine which gateway or endpoint is optimal and to establish an SA with that gateway or endpoint. However, this solution does not scale in a large network with hundreds of thousands of gateways and endpoints, especially when multiple administrative domains are involved and things are rapidly changing (e.g., mobile endpoints). Such a solution is also limited by the smallest endpoint/gateway, as the same exhaustive configuration is to be applied on all endpoints/gateways. A more dynamic, secure, and scalable system for establishing SAs between gateways is needed.
一个简单的解决方案是预先配置所有网关和端点，并提供确定哪个网关或端点是最佳的以及使用该网关或端点建立SA所需的所有信息。但是，此解决方案无法在具有数十万个网关和端点的大型网络中扩展，特别是当涉及多个管理域且情况正在快速变化时（例如，移动端点）。这种解决方案还受到最小端点/网关的限制，因为相同的详尽配置将应用于所有端点/网关。需要一个更加动态、安全和可扩展的系统来在网关之间建立SAs。
The most common way to address a part of this problem today is to use what has been termed a "star topology". In this case, one or a few gateways are defined as "hub gateways", while the rest of the systems (whether endpoints or gateways) are defined as "spokes". The spokes never connect to other spokes. They only open tunnels with the hub gateways. Also, for a large number of gateways in one administrative domain, one gateway may be defined as the hub, and the rest of the gateways and remote access clients connect only to that gateway.
今天，解决这个问题的一部分最常见的方法是使用所谓的“星形拓扑”。在这种情况下，一个或几个网关被定义为“集线器网关”，而其余系统（无论是端点还是网关）被定义为“辐条”。辐条从未连接到其他辐条。他们只开放带有枢纽网关的隧道。此外，对于一个管理域中的大量网关，可以将一个网关定义为集线器，其余网关和远程访问客户端仅连接到该网关。
This solution, however, is complicated by the case where the spokes use dynamic IP addresses and DNS with dynamic updates needs to be used. It is also desired that there is minimal to no configuration on the hub as the number of spokes increases and new spokes are added and deleted randomly.
然而，由于辐条使用动态IP地址，并且需要使用具有动态更新的DNS，因此该解决方案比较复杂。随着辐条数量的增加以及随机添加和删除新辐条，还希望轮毂上的配置最少甚至没有配置。
Another problem with the star topology is that it creates a high load on the hub gateways, as well as on the connection between the spokes and the hub. This load impacts both processing power and network bandwidth. A single packet in the hub-and-spoke scenario can be encrypted and decrypted multiple times. It would be much preferable if these gateways and clients could initiate tunnels between them, bypassing the hub gateways. Additionally, the path bandwidth to these hub gateways may be lower than that of the path between the spokes. For example, two remote access users may be in the same building with high-speed WiFi (for example, at an IETF meeting). Channeling their conversation through the hub gateways of their respective employers seems extremely wasteful, given that a more optimal direct path exists.
星形拓扑的另一个问题是，它会在集线器网关以及辐条和集线器之间的连接上产生高负载。此负载会影响处理能力和网络带宽。中心辐射方案中的单个数据包可以多次加密和解密。如果这些网关和客户端能够绕过集线器网关在它们之间启动隧道，这将是更好的选择。此外，到这些集线器网关的路径带宽可能低于辐条之间的路径带宽。例如，两个远程访问用户可能在同一栋大楼中，使用高速WiFi（例如，在IETF会议上）。考虑到存在一条更为理想的直接路径，通过各自雇主的中心网关引导他们的对话似乎是极其浪费的。
The challenge is to build large-scale IPsec-protected networks that can dynamically change with minimal administrative overhead.
面临的挑战是构建大规模的受IPsec保护的网络，该网络可以以最小的管理开销动态更改。
Several vendors offer proprietary solutions to these problems. However, these solutions offer no interoperability between equipment from one vendor and another. This means that they are generally restricted to use within one organization, and it is harder to move away from such solutions, as the features are not standardized. Besides, multiple organizations cannot be expected to all choose the same equipment vendor.
一些供应商为这些问题提供专有解决方案。但是，这些解决方案不提供来自一个供应商和另一个供应商的设备之间的互操作性。这意味着它们通常仅限于在一个组织内使用，并且很难脱离此类解决方案，因为这些特性没有标准化。此外，不能期望多个组织都选择同一个设备供应商。
This section defines the requirements on which the solution will be based.
本节定义了解决方案所基于的要求。
1. For any network topology (star, full mesh, and dynamic full mesh), when a new gateway or endpoint is added, removed, or changed, configuration changes are minimized as follows. Adding or removing a spoke in the topology MUST NOT require configuration changes to hubs other than where the spoke was connected and SHOULD NOT require configuration changes to the hub to which the spoke was connected. The changes also MUST NOT require configuration changes in other spokes.
1. 对于任何网络拓扑（星形、全网格和动态全网格），当添加、删除或更改新网关或端点时，配置更改将最小化，如下所示。在拓扑中添加或删除分支时，不得要求对连接分支的集线器以外的集线器进行配置更改，也不得要求对连接分支的集线器进行配置更改。更改也不得要求更改其他辐条的配置。
Specifically, when evaluating potential proposals, we will compare them by looking at how many endpoints or gateways must be reconfigured when a new gateway or endpoint is added, removed, or changed and how substantial this reconfiguration is, in addition to the amount of static configuration required.
具体而言，在评估潜在方案时，我们将通过查看添加、删除或更改新网关或端点时必须重新配置的端点或网关数量，以及除了所需的静态配置数量外，这种重新配置的实质性程度来对其进行比较。
This requirement is driven by use cases 1 and 2 and by the scaling limitations pointed out in Section 3.1.
该需求由用例1和用例2以及第3.1节中指出的缩放限制驱动。
2. ADVPN Peers MUST allow IPsec tunnels to be set up with other members of the ADVPN without any configuration changes, even when peer addresses get updated every time the device comes up. This implies that Security Policy Database (SPD) entries or other configuration based on a peer IP address will need to be automatically updated, avoided, or handled in some manner to avoid a need to manually update policy whenever an address changes.
2. ADVPN对等方必须允许与ADVPN的其他成员建立IPsec隧道，而无需任何配置更改，即使每次设备出现时对等方地址都会更新。这意味着安全策略数据库（SPD）条目或基于对等IP地址的其他配置将需要以某种方式自动更新、避免或处理，以避免在地址更改时需要手动更新策略。
3. In many cases, additional tunneling protocols (e.g., GRE) or routing protocols (e.g., OSPF) are run over the IPsec tunnels. Gateways MUST allow for the operation of tunneling and routing protocols operating over spoke-to-spoke IPsec tunnels with minimal or no configuration impact. The ADVPN solution SHOULD NOT increase the amount of information required to configure protocols running over IPsec tunnels.
3. 在许多情况下，附加的隧道协议（例如GRE）或路由协议（例如OSPF）在IPsec隧道上运行。网关必须允许隧道和路由协议在分支到分支IPsec隧道上运行，且对配置的影响最小或没有影响。ADVPN解决方案不应增加配置在IPsec隧道上运行的协议所需的信息量。
4. In the full-mesh and dynamic full-mesh topologies, spokes MUST allow for direct communication with other spoke gateways and endpoints. In the star topology mode, direct communication between spokes MUST be disallowed.
4. 在全网格和动态全网格拓扑中，辐条必须允许与其他辐条网关和端点直接通信。在星形拓扑模式下，必须禁止辐条之间的直接通信。
This requirement is driven by use cases 1 and 2 and by the limitations of a star topology as pointed out in Section 3.2.
该要求由用例1和用例2以及第3.2节中指出的星形拓扑的限制驱动。
5. ADVPN Peers MUST NOT have a way to get the long-term authentication credentials for any other ADVPN Peers. The compromise of an endpoint MUST NOT affect the security of communications between other ADVPN Peers. The compromise of a gateway SHOULD NOT affect the security of the communications between ADVPN Peers not associated with that gateway.
5. ADVPN对等方不得有办法获取任何其他ADVPN对等方的长期身份验证凭据。端点的泄露不得影响其他ADVPN对等方之间通信的安全性。网关的危害不应影响与该网关无关的ADVPN对等方之间通信的安全性。
This requirement is driven by use case 1. ADVPN Peers (especially spokes) become compromised fairly often. The compromise of one ADVPN Peer SHOULD NOT affect the security of other unrelated ADVPN Peers.
这个需求由用例1驱动。ADVPN对等点（尤其是辐条）经常受到损害。一个ADVPN对等点的泄露不应影响其他不相关的ADVPN对等点的安全。
6. Gateways SHOULD allow for seamless handoff of sessions in cases where endpoints are roaming, even if they cross policy boundaries. This would mean the data traffic is minimally affected even as the handoff happens. External factors like firewalls and NAT boxes that will be part of the overall solution when ADVPN is deployed will not be considered part of this solution.
6. 网关应允许在端点漫游的情况下无缝切换会话，即使它们跨越策略边界。这意味着即使在切换发生时，数据流量也会受到最小的影响。当部署ADVPN时，作为整体解决方案一部分的防火墙和NAT盒等外部因素将不被视为此解决方案的一部分。
Such endpoint roaming may affect not only the endpoint-to-endpoint SA but also the relationship between the endpoints and gateways (such as when an endpoint roams to a new network that is handled by a different gateway).
这种端点漫游可能不仅影响端点到端点SA，还影响端点和网关之间的关系（例如，当端点漫游到由不同网关处理的新网络时）。
This requirement is driven by use case 1. Today's endpoints are mobile and transition often between different networks (from 4G to WiFi and among various WiFi networks).
这个需求由用例1驱动。今天的端点是移动的，并且经常在不同的网络之间转换（从4G到WiFi以及在各种WiFi网络之间）。
7. Gateways SHOULD allow for easy handoff of a session to another gateway, to optimize latency, bandwidth, load balancing, availability, or other factors, based on policy.
7. 网关应允许将会话轻松切换到另一个网关，以根据策略优化延迟、带宽、负载平衡、可用性或其他因素。
This ability to migrate traffic from one gateway to another applies regardless of whether the gateways in question are hubs or spokes. It even applies in the case where a gateway (hub or spoke) moves in the network, as may happen with a vehicle-based network.
这种将流量从一个网关迁移到另一个网关的能力适用于任何有问题的网关是集线器还是辐条。它甚至适用于网关（集线器或轮辐）在网络中移动的情况，如基于车辆的网络。
This requirement is driven by use case 3.
此需求由用例3驱动。
8. Gateways and endpoints MUST have the capability to participate in an ADVPN even when they are located behind NAT boxes. However, in some cases they may be deployed in such a way that they will not be fully reachable behind a NAT box. It is especially difficult to handle cases where the hub is behind a NAT box. When the two endpoints are both behind separate NATs, communication between these spokes SHOULD be supported using workarounds such as port forwarding by the NAT or detecting when two spokes are behind uncooperative NATs, and using a hub in that case.
8. 网关和端点必须能够参与ADVPN，即使它们位于NAT盒后面。但是，在某些情况下，它们的部署方式可能会使它们在NAT箱后面无法完全访问。特别难以处理集线器位于NAT箱后面的情况。当两个端点都位于单独的NAT后面时，应使用变通方法支持这些辐条之间的通信，例如NAT的端口转发或检测两个辐条何时位于不合作的NAT后面，以及在这种情况下使用集线器。
This requirement is driven by use cases 1 and 2. Endpoints are often behind NATs, and gateways sometimes are. IPsec SHOULD continue to work seamlessly regardless, using ADVPN techniques whenever possible and providing graceful fallback to hub-and-spoke techniques as needed.
这个需求由用例1和用例2驱动。端点通常位于NAT之后，而网关有时位于NAT之后。不管怎样，IPsec都应该继续无缝工作，尽可能使用ADVPN技术，并根据需要提供优雅的中心辐射技术回退。
9. Changes such as establishing a new IPsec SA SHOULD be reportable and manageable. However, creating a MIB or other management technique is not within scope for this effort.
9. 诸如建立新的IPsec SA之类的更改应该是可报告和可管理的。但是，创建MIB或其他管理技术不在这项工作的范围之内。
This requirement is driven by manageability concerns for all the use cases, especially use case 2. As IPsec networks become more dynamic, management tools become more essential.
这个需求是由所有用例的可管理性问题驱动的，特别是用例2。随着IPsec网络变得更加动态，管理工具变得更加重要。
10. To support allied and federated environments, endpoints and gateways from different organizations SHOULD be able to connect to each other.
10. 为了支持联盟和联邦环境，来自不同组织的端点和网关应该能够相互连接。
This requirement is driven by demand for all the use cases in federated and allied environments.
这个需求是由联邦和联盟环境中所有用例的需求驱动的。
11. The administrator of the ADVPN SHOULD allow for the configuration of a star, full-mesh, or partial full-mesh topology, based on which tunnels are allowed to be set up.
11. ADVPN的管理员应允许配置星形、全网格或部分全网格拓扑，允许基于这些拓扑设置隧道。
This requirement is driven by demand for all the use cases in federated and allied environments.
这个需求是由联邦和联盟环境中所有用例的需求驱动的。
12. The ADVPN solution SHOULD be able to scale for multicast traffic.
12. ADVPN解决方案应该能够扩展多播流量。
This requirement is driven by use case 2, where the amount of rich media multicast traffic is increasing.
这个需求是由用例2驱动的，其中富媒体多播通信量正在增加。
13. The ADVPN solution SHOULD allow for easy monitoring, logging, and reporting of the dynamic changes to help with troubleshooting such environments.
13. ADVPN解决方案应允许轻松监视、记录和报告动态更改，以帮助对此类环境进行故障排除。
This requirement is driven by demand for all the use cases in federated and allied environments.
这个需求是由联邦和联盟环境中所有用例的需求驱动的。
14. There is also the case where L3VPNs operate over IPsec tunnels, for example, Provider-Edge-based VPNs. An ADVPN MUST support L3VPNs as applications protected by the IPsec tunnels.
14. 还有L3VPN通过IPsec隧道运行的情况，例如，基于提供商边缘的VPN。ADVPN必须支持L3VPN作为受IPsec隧道保护的应用程序。
This requirement is driven by demand for all the use cases in federated and allied environments.
这个需求是由联邦和联盟环境中所有用例的需求驱动的。
15. The ADVPN solution SHOULD allow the enforcement of per-peer QoS in both the star and full-mesh topologies.
15. ADVPN解决方案应允许在星形和全网状拓扑中实施每对等QoS。
This requirement is driven by demand for all the use cases in federated and allied environments.
这个需求是由联邦和联盟环境中所有用例的需求驱动的。
16. The ADVPN solution SHOULD take care of not letting the hub be a single point of failure.
16. ADVPN解决方案应注意不要让集线器成为单点故障。
This requirement is driven by demand for all the use cases in federated and allied environments.
这个需求是由联邦和联盟环境中所有用例的需求驱动的。
This is a problem statement and requirements document for the ADVPN solution and in itself does not introduce any new security concerns. The solution to the problems presented in this document may involve dynamic updates to databases defined by RFC 4301, such as the Security Policy Database (SPD) or the Peer Authorization Database (PAD).
这是ADVPN解决方案的问题声明和要求文档，其本身不会引入任何新的安全问题。本文档中提出的问题的解决方案可能涉及对RFC 4301定义的数据库的动态更新，例如安全策略数据库（SPD）或对等授权数据库（PAD）。
RFC 4301 is silent about the way these databases are populated, and it is implied that these databases are static and preconfigured by a human. Allowing dynamic updates to these databases must be thought out carefully because it allows the protocol to alter the security policy that the IPsec endpoints implement.
RFC 4301对这些数据库的填充方式保持沉默，这意味着这些数据库是静态的，并且是由人工预配置的。必须仔细考虑允许对这些数据库进行动态更新，因为它允许协议更改IPsec端点实现的安全策略。
One obvious attack to watch out for is stealing traffic to a particular site. The IP address for www.example.com is 192.0.2.10. If we add an entry to an IPsec endpoint's SPD that says that traffic to 192.0.2.10 is protected through peer Gw-Mallory, then this allows Gw-Mallory to either pretend to be www.example.com or proxy and read all traffic to that site. Updates to this database require a clear trust model.
要警惕的一个明显的攻击是窃取特定站点的流量。www.example.com的IP地址是192.0.2.10。如果我们在IPsec端点的SPD中添加一个条目，说明到192.0.2.10的流量是通过对等Gw Mallory保护的，那么这就允许Gw Mallory假装为www.example.com或代理，并读取到该站点的所有流量。对此数据库的更新需要明确的信任模型。
Hubs can be a single point of failure that can cause loss of connectivity of the entire system; this can be a big security issue. Any ADVPN solution design should take care of these concerns.
集线器可能是单个故障点，可能导致整个系统失去连接；这可能是一个很大的安全问题。任何ADVPN解决方案设计都应考虑这些问题。
Many people have contributed to the development of this problem statement. While we cannot thank all contributors, some have played an especially prominent role. Yoav Nir, Yaron Sheffer, Jorge Coronel Mendoza, Chris Ulliott, and John Veizades wrote the document upon which this specification was based. Geoffrey Huang, Toby Mao, Suresh Melam, Praveen Sathyanarayan, Andreas Steffen, Brian Weis, Lou Berger, and Tero Kivinen provided essential input.
许多人对这个问题陈述的发展做出了贡献。虽然我们不能感谢所有的贡献者，但有些贡献者发挥了特别突出的作用。Yoav Nir、Yaron Sheffer、Jorge Coronel Mendoza、Chris Ulliott和John Veizades编写了本规范所依据的文档。Geoffrey Huang、Toby Mao、Suresh Melam、Praveen Sathyanarayan、Andreas Steffen、Brian Weis、Lou Berger和Tero Kivinen提供了必要的投入。
[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月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
Authors' Addresses
作者地址
Vishwas Manral Hewlett-Packard Co. 3000 Hanover St. Palo Alto, CA 94304 USA
美国加利福尼亚州汉诺威圣帕洛阿尔托市维斯瓦斯曼拉尔惠普公司，邮编：94304
EMail: vishwas.manral@hp.com
EMail: vishwas.manral@hp.com
Steve Hanna Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, CA 94089 USA
Steve Hanna Juniper Networks，Inc.美国加利福尼亚州桑尼维尔市马蒂尔达大道北1194号，邮编94089
EMail: shanna@juniper.net
EMail: shanna@juniper.net