[要約] 要約：RFC 7018は、自動検出VPNの問題と要件に関する情報を提供するものである。 目的：自動検出VPNの問題を明確にし、要件を定義することで、より効果的な自動検出VPNの実装を促進する。
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.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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ゲートウェイの大規模なコレクション、多数のゲートウェイまたは相互に接続する多数のリモートエンドポイント、あるいはこの2つの組み合わせである可能性があります。ゲートウェイとエンドポイントは、単一の管理ドメインまたは信頼関係のある複数のドメインに属している場合があります。
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で言及されている多くの構成が必要なことです。インターネットキー交換プロトコル（IKE）の実装では、考えられるすべてのピアシステムのIDと資格情報、およびその背後にあるホストやネットワークのアドレスを知る必要があります。ポイントツーポイントトンネルを動的に確立するための簡略化されたメカニズムが必要です。セクション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.
ポイントツーポイント-他の当事者によるアクティブな参加（暗号化や復号化など）を行わない2つの当事者間の通信。
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の中心点の1つ、つまり、他の複数のハブまたはスポークが接続するゲートウェイ。ハブは通常、暗号化されたリンクからのトラフィックを他の暗号化されたリンクに転送します。つまり、ハブは平文で接続されているデバイスはありません。
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.
スタートポロジ-ハブとスポークの間だけが直接接続され、2つのスポーク間の通信がハブを介して行われるトポロジ。
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].
Security Association（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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [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.
2つのエンドポイントは、ポイントツーポイント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.
エンドポイントからエンドポイントへの安全な通信の必要性は、リモートゲートウェイへの低速で高価なリンクを使用するのではなく、高帯域幅で低遅延のローカル接続を採用する必要性によって引き起こされることがよくあります。たとえば、リモートゲートウェイは通話に遅延を追加し、貴重なリモート帯域幅を消費し、全体的なコストを増加させるため、近くにいる2人のユーザーは、リモートゲートウェイ経由で通話を送信する必要なしに、安全な直接ビデオまたは音声通話を発信したい場合があります。 。このような使用例では、両方のユーザーが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.
スタートポロジでは、2つのエンドポイントが通信するときに、他のスポークエンドポイントによる偽装に身をさらさないように、認証のためのメカニズムが必要です。
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.
ソリューションは、既存の信頼関係があるエンドポイントが異なる管理ドメインにある場合に機能する必要があります（たとえば、プロジェクトで共同作業している2つの組織が、構成に対する独立した制御を維持しながら、ネットワークに参加する場合があります）。ソリューションがスター、フルメッシュ、およびダイナミックフルメッシュトポロジで機能することが強く望まれます。
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.
さらに、ゲートウェイ間通信のルーティングの影響にも対処する必要があります。単純なケースでは、セレクターはゲートウェイがトラフィックを適切に転送するための十分な情報を提供します。他の場合では、追加のトンネリング（例：Generic Routing Encapsulation（GRE））およびルーティング（例：Open Shortest Path First（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.
2つのゲートウェイが通信する場合、他のエンティティによる偽装のリスクにさらされないように、認証メカニズムを使用する必要があります。
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.
インターネットでローミングするモバイルユーザーは、ローミングのために使用するのに最も効率的なゲートウェイではなくなったゲートウェイに接続する場合があります（理由としては、コスト、効率、待ち時間、またはその他の要因が考えられます）。モバイルユーザーは、接続を停止することなく、シームレスで現在の最も効率的なゲートウェイを検出して接続できる必要があります。
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.
簡単な解決策の1つは、最適なゲートウェイまたはエンドポイントを特定し、そのゲートウェイまたはエンドポイントとのSAを確立するために必要なすべての情報を使用して、すべてのゲートウェイとエンドポイントを事前に構成することです。ただし、このソリューションは、特に複数の管理ドメインが関係し、状況が急速に変化している場合（モバイルエンドポイントなど）、数十万のゲートウェイとエンドポイントがある大規模ネットワークでは拡張できません。同じ徹底的な構成がすべてのエンドポイント/ゲートウェイに適用されるため、このようなソリューションは最小のエンドポイント/ゲートウェイによっても制限されます。ゲートウェイ間にSAを確立するための、より動的で安全なスケーラブルなシステムが必要です。
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.
今日この問題の一部に対処する最も一般的な方法は、「スタートポロジ」と呼ばれているものを使用することです。この場合、1つまたはいくつかのゲートウェイは「ハブゲートウェイ」として定義され、残りのシステム（エンドポイントまたはゲートウェイ）は「スポーク」として定義されます。スポークが他のスポークに接続することはありません。ハブゲートウェイでのみトンネルを開きます。また、1つの管理ドメインに多数のゲートウェイがある場合は、1つのゲートウェイをハブとして定義し、残りのゲートウェイとリモートアクセスクライアントはそのゲートウェイにのみ接続します。
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.
スタートポロジのもう1つの問題は、ハブゲートウェイ、およびスポークとハブ間の接続に高い負荷がかかることです。この負荷は、処理能力とネットワーク帯域幅の両方に影響を与えます。ハブアンドスポークシナリオの単一のパケットは、複数回暗号化および復号化できます。これらのゲートウェイとクライアントがハブゲートウェイをバイパスして、それらの間のトンネルを開始できると、非常に望ましいでしょう。さらに、これらのハブゲートウェイへのパス帯域幅は、スポーク間のパスの帯域幅よりも低い場合があります。たとえば、2人のリモートアクセスユーザーが同じ建物内に高速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.
いくつかのベンダーがこれらの問題に対する独自のソリューションを提供しています。ただし、これらのソリューションでは、ベンダー間の機器の相互運用性は提供されません。つまり、それらは一般に1つの組織内での使用に制限されており、機能が標準化されていないため、そのようなソリューションから離れることは困難です。さらに、複数の組織がすべて同じ機器ベンダーを選択することを期待することはできません。
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ピアは、デバイスが起動するたびにピアアドレスが更新される場合でも、構成を変更せずにIPsecトンネルをADVPNの他のメンバーとセットアップできるようにする必要があります。これは、ピアIPアドレスに基づくセキュリティポリシーデータベース（SPD）エントリまたはその他の構成を自動的に更新、回避、または何らかの方法で処理して、アドレスが変更されるたびにポリシーを手動で更新する必要を回避する必要があることを意味します
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トンネルを介して実行されるプロトコルを構成するために必要な情報量を増やしてはなりません（SHOULD NOT）。
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ピア間の通信のセキュリティに影響を与えるべきではありません（SHOULD NOT）。
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ピア（特にスポーク）は、かなり頻繁に危険にさらされます。 1つの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. ゲートウェイは、エンドポイントがローミングしている場合でも、ポリシーの境界を越えていても、セッションのシームレスなハンドオフを可能にする必要があります（SHOULD）。これは、ハンドオフが発生しても、データトラフィックへの影響が最小限であることを意味します。ファイアウォールやNATボックスなど、ADVPNの展開時に全体的なソリューションの一部となる外部要因は、このソリューションの一部とは見なされません。
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. ゲートウェイは、ポリシーに基づいて、レイテンシ、帯域幅、ロードバランシング、可用性、またはその他の要素を最適化するために、セッションを別のゲートウェイに簡単にハンドオフできるようにする必要があります（SHOULD）。
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. ゲートウェイとエンドポイントは、NATボックスの背後にある場合でも、ADVPNに参加できる必要があります。ただし、場合によっては、NATボックスの背後で完全に到達できないような方法で展開されることがあります。ハブがNATボックスの背後にある場合の処理は特に困難です。 2つのエンドポイントが両方とも別個のNATの背後にある場合、これらのスポーク間の通信は、NATによるポート転送や、2つのスポークが非協調型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の背後にあり、ゲートウェイは時々背後にあります。 IPsecは、可能な限りADVPN技術を使用し、必要に応じてハブアンドスポーク技術への適切なフォールバックを提供して、シームレスに機能し続ける必要があります（SHOULD）。
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の確立などの変更は、報告および管理可能である必要があります（SHOULD）。ただし、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. 連合環境および連合環境をサポートするには、さまざまな組織のエンドポイントとゲートウェイが相互に接続できる必要があります（SHOULD）。
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の管理者は、設定できるトンネルに基づいて、スター、フルメッシュ、または部分的なフルメッシュトポロジの構成を許可する必要があります（SHOULD）。
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ソリューションは、マルチキャストトラフィックに合わせて拡張できる必要があります（SHOULD）。
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ソリューションは、そのような環境のトラブルシューティングに役立つように、動的な変更の簡単な監視、ロギング、およびレポートを可能にする必要があります（SHOULD）。
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が、プロバイダーエッジベースのVPNなどのIPsecトンネルを介して動作する場合もあります。 ADVPNは、IPsecトンネルによって保護されたアプリケーションとしてL3VPNをサポートする必要があります。
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を適用できるようにする必要があります（SHOULD）。
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ソリューションの問題ステートメントと要件ドキュメントであり、それ自体は新しいセキュリティ上の懸念をもたらしません。このドキュメントで提示されている問題の解決には、セキュリティポリシーデータベース（SPD）やピア認証データベース（PAD）など、RFC 4301で定義されているデータベースの動的更新が含まれる場合があります。
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.
注意すべき明らかな攻撃の1つは、特定のサイトへのトラフィックを盗むことです。 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 4301、2005年12月。
Authors' Addresses
著者のアドレス
Vishwas Manral Hewlett-Packard Co. 3000 Hanover St. Palo Alto, CA 94304 USA
Biswas Mineral Hewlett-Packard CO。 3000ハノーバー土94304パロアルトの彼
EMail: vishwas.manral@hp.com
Steve Hanna Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, CA 94089 USA
Steve Hanna Juniper Networks、Inc. 1194 N. Mathilda Ave. Sunnyvale、CA 94089 USA
EMail: shanna@juniper.net