[要約] RFC 5619は、ソフトワイヤセキュリティの分析と要件に関するものであり、IPv4とIPv6の間のトンネリング技術のセキュリティに焦点を当てています。このRFCの目的は、ソフトワイヤセキュリティの問題を特定し、適切な対策を提案することです。
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.
このドキュメントでは、ソフトワイヤーの「ハブとスポーク」および「メッシュ」ソリューションのセキュリティガイドラインについて説明します。Softwireの展開シナリオの議論とともに、セキュリティ攻撃に対する脆弱性が分析され、ソフトワイヤー制御およびデータパケットに認証、整合性、機密性などのセキュリティ保護メカニズムが提供されます。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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
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ネットワーク全体でIPv4ネットワークを接続するための発見、制御、およびカプセル化方法の標準化を指定します。Softwireは、既存のテクノロジーを再利用または拡張することにより、両方の住所ファミリのグローバルな到達可能性を可能にするための接続を提供します。Softwireワーキンググループは、異なるアドレスファミリで構成されるネットワークのトラバーサルについて議論するときに現れた2つのシナリオに焦点を当てています。このドキュメントは、このようなソフトワイヤーソリューションスペースの2つのセキュリティガイドラインを提供します。「ハブとスポーク」と「メッシュ」シナリオです。「ハブとスポーク」および「メッシュ」の問題は、それぞれ[RFC4925]セクション2と3で説明されています。ソフトワイヤー接続用に選択されたプロトコルには、各ソリューションのより具体的な展開シナリオでセキュリティ上の考慮事項が必要です。このドキュメントの範囲は、展開シナリオのセキュリティの脆弱性に関する分析を提供し、Softwireの展開に適用されるセキュリティメカニズムの適切な使用法を指定します。
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.
レイヤー2トンネルプロトコル（L2TPV2）は、「ハブとスポーク」ソリューションスペースに展開されるフェーズ1プロトコルとして選択されます。L2TPV2が保護されていないネットワークで使用されている場合、[RFC3193]に記載されているIPSECなどの適切なセキュリティプロトコルによって保護され、さまざまなセキュリティ攻撃に対して脆弱である必要があります。新しい実装では、IKEV2（Internet Key Exchangeプロトコルバージョン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.
ソフトワイヤーの「メッシュ」ソリューションは、さまざまなレベルのセキュリティメカニズムをサポートする必要があります。これは、異なるアドレスファミリで動作するトランジットコアの1つのアドレスファミリを持つアクセスネットワークからソフトワイヤートンネルに送信されるデータパケットを保護する必要があります[RFC4925]。コントロールプレーンのセキュリティメカニズムは、コントロールデータの変更、スプーフィング攻撃などから保護する必要があります。「メッシュ」ソリューションでは、BGPはトランジットコアのソフトワイヤールーティング情報の配布に使用されます。一方、BGPのセキュリティ問題は、他のワーキンググループで議論されています。このドキュメントは、Softwireメッシュ展開シナリオのセキュリティメカニズムの適切な使用を提供します。
The terminology is based on the "Softwire Problem Statement" [RFC4925].
用語は、「Softwire Problem Statement」[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） - 同じまたは異なるアドレスファミリを使用する2つのネットワークを相互接続するデュアルスタックルーター。AFBRは、他のAFBR、隣接するコアルーター、および接続された顧客エッジ（CE）ルーターとのピアリング関係を形成します。ソフトワイヤーの発見とシグナリングを実行します。クライアントASF（i）Reachability情報を宣伝します。ソフトワイヤートランスポートヘッダーの顧客パケットをカプセル化/脱カプセル化します。
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.
Customer Edge（CE） - AFアクセスアイランド内にあるルーターは、Access Islandネットワーク内の他のCEルーターと1つ以上の上流のAFBRと一緒に協力しています。
Customer Premise Equipment (CPE) - An equipment, host or router, located at a subscriber's premises and connected with a carrier's access network.
Customer Premise Equipment（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.
Softwire concencorator（SC） - サービスプロバイダーネットワークのソフトワイヤーを終了するノード。
Softwire Initiator (SI) - The node initiating the softwire within the customer network.
Softwire Initiator（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.
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 AF prefixes (in advertisements or entries in a routing table) infers the use of softwire to reach that prefix.
Softwire next_hop（sw -nhop） - この属性は、クライアントAFリーチビリティ広告に付属し、特定のプレフィックスにつながるイングレスAFBRのソフトワイヤを参照するために使用されます。ソフトワイヤー識別子値と、<SW ID：SW-NHOPアドレス>として示されるソフトワイヤーNext_HOP IPアドレスが含まれています。クライアント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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[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.
Softwireイニシエーター（SI）は常に顧客ネットワークにあります。SIが存在するノードは、CPEアクセスデバイス、元のCPEアクセスデバイスの背後にあるもう1つの専用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.
ただし、ホストデバイスは、ユーザーがサブスクライブしているホームキャリアネットワークに常に直接アクセスできるとは限りません。たとえば、ラップトップPCのSIは、Wi-Fiホットスポット、オフィスネットワークにアクセスするなど、さまざまなアクセスネットワークにアクセスできます。これは、Softwireがサポートすべき遊牧民です。
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.
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サーバーは、AAAクライアントとして機能するSCと相互作用します。AAAは複数のAAAサーバーで構成され、プロキシAAAはSCとAAAサーバーの中間である場合があります。このドキュメントでは、ホームネットワークサービスプロバイダーのAAAサーバーをホームAAAサーバー（AAAH）として、および訪問したネットワークサービスプロバイダーのAAAサーバー（AAAV）の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.
「Softwire Problem Statement」[RFC4925]は、Softwireソリューションを一般的に展開するAAAソリューションと統合できる必要があると述べています。Softwireで使用されるL2TPV2は、一般的なAAAサーバーと統合できるPPPおよびL2TP認証をサポートします。
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がモバイルである場合、Home 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の間の信頼関係の確立は、3つのケースで異なります。セキュリティ上の考慮事項は、各ケースについて考慮する必要があります。
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 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.
ケース1では、同じネットワークサービスプロバイダーのSCとHome AAAサーバーに信頼関係が必要であり、それらの間の通信を確保する必要があります。SCがSIを認証すると、SCは認証要求メッセージをHome AAAサーバーに送信し、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がモバイルの場合、訪問されたアクセスネットワークプロバイダーを介したホームネットワークサービスプロバイダーへのアクセスが許可されます。Homeネットワーク内のSIとSCの信頼関係を確立する必要があります。訪問されたアクセスネットワークがパブリックネットワークである場合、さまざまなセキュリティ攻撃を考慮する必要があります。特にSIが正当なSCに接続するには、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サーバーはHome 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.
Home 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ネットワーク全体のIPv4ネットワークとIPv4ネットワークを越えて接続できます。Softwireセッション中に使用される制御およびデータパケットは、セキュリティ攻撃に対して脆弱です。
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.
Softwireソリューションは、レイヤー2トンネリングプロトコル（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に対して行われた一般的な脅威分析は、Softwireの「ハブとスポーク」の展開に適用できます。MIPV6（モバイルIPv6）[RFC4225]、PANA（ネットワークアクセスのための認証を運ぶためのプロトコル）[RFC4016]、NSIS（RFC4081] [RFC4081]、およびルーティングプロトコル[RFC4593]などの他のプロトコルの脅威分析は、適用可能です[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は、Softwireの開始のためにSCに開始コントロール接続再会（SCCRQ）パケットをSCに送信します。L2TPV2は、制御接続の確立中にオプションのトンネル認証システム（CHAP -Challenge Handshake Authentication Protocolに似ています）を提供します。これには、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制御接続が確立されると、PPPリンク制御プロトコル（LCP）ネゴシエーションを完了した後、SiおよびSCはオプションで認証フェーズに入ります。PPP認証は、片道または双方向のチャップ認証をサポートし、既存の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サーバーがソフトワイヤートンネルの確立に関与する場合、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.
暗号化保護と弱い認証または一方向認証なしでリンクが共有される環境では、これらのセキュリティ攻撃はSoftwireコントロールとデータパケットに取り付けることができます。
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になりすましてトラフィックを傍受する場合があります（たとえば、「Rogue」ソフトワイヤーコンセントレーターなど）。
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.
Rogue SCは、SIからのブラックホールパケットによるサービス拒否攻撃を導入できます。Rogue SCは、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の脱カプセレーターの特定のイングレスフィルタリングチェックがなければ、攻撃者が誤ったパケットを注入し、システムを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のセキュリティ脅威分析に基づいて、Softwireセキュリティプロトコルは次の保護をサポートする必要があります。
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. Softwireセキュリティプロトコルは、リプレイ攻撃から身を守ることができなければなりません。
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. Softwireセキュリティプロトコルは、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. Softwireセキュリティプロトコルは、切断および取り消しメッセージを保護できる必要があります。
The softwire security protocol requirement is comparable to [RFC3193].
Softwireセキュリティプロトコル要件は[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.
「Softwire Problem Statement」[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.
たとえば、ClearTextパスワードを使用してSCへのパスワード認証プロトコル（PAP）アクセスを使用してSI/ユーザーを検討してください。多くの状況で、これは大きなセキュリティリスクを表しています。敵は、盗まれたパスワードを使用することにより、合法的なユーザーとして吹き飛ばすことができます。チャレンジハンドシェイク認証プロトコル（CHAP）[RFC1994]は、SCから送信された「チャレンジ」を使用してパスワードを暗号化します。パスワードの盗難を軽減できます。ただし、CHAPは単方向認証のみをサポートしているため、中間または不正なSCのリスクは回避できません。拡張可能な認証プロトコル輸送レイヤーセキュリティ（EAP-TLS）[RFC5216]は相互認証を義務付け、Rogue 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 IDの証明を必要とする場合があります。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.
Softwireフェーズ1プロトコルとして選択されたL2TPV2は、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の間で相互認証を提供できます。PPP Chap認証は、SiおよびSCが信頼できる非公共のIPネットワーク上にある場合に使用できます。
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認証は、PPP CHAP認証に適用された同じ制限と同様に、パブリックIPネットワークで保護されていない使用を使用してはなりません。
To meet the above requirements, all softwire-security-compliant implementations MUST implement the following security protocols.
上記の要件を満たすには、すべてのSoftwire-Security準拠の実装が次のセキュリティプロトコルを実装する必要があります。
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]は、ソフトワイヤー制御とデータパケットの保護に使用されます。Internter Key Exchange（IKE）プロトコル[RFC4306]は、IPSECの認証、セキュリティ協会の交渉、および主要な管理のためにサポートする必要があります。IKEのさまざまなバージョンの適用性については、セクション3.5で説明します。
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.
Softwireセキュリティプロトコルは、NAT Traversalをサポートする必要があります。IPSEC ESPパケット[RFC3948]のUDPカプセル化とIKESCの使用時には、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ベースのSoftwireでのIPSECの使用に関するガイドラインを提供します。
[RFC3193] discusses how L2TP can use IKE [RFC2409] and IPsec [RFC2401] to provide tunnel authentication, privacy protection, 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]は、L2TPがIKE [RFC2409]およびIPSEC [RFC2401]を使用して、トンネル認証、プライバシー保護、整合性チェック、およびリプレイ保護を提供する方法について説明します。[RFC3193]の公開以来、IPSECプロトコルの改訂が公開されています（IKEV2 [RFC4306]、ESP [RFC4303]、IKE [RFC3947]のNATトラバーサル、および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]をサポートする必要があります。ただし、新しい実装では、IKESECにIKEV2 [RFC4306]を使用する必要があります。これは、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-Traversal、IKE [RFC3947]、およびESP [RFC3948のNATトラバーサルなどのソフトワイヤー要件もサポートする必要があります。
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.
EAPとともに、IKEV2 [RFC4306]は、ユーザー名とパスワードベースの認証が既に展開されている環境で役立つレガシー認証方法をサポートしています。
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.
IKEV2は、リプレイ保護機能、DOS保護対応メカニズムなどの点で、IKE [RFC2409]よりも信頼性の高いプロトコルです。したがって、新しい実装では、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実装は、マシン認証のみをサポートします。ユーザーIDを確認し、マルチユーザーマシン環境でユーザー間のトンネルトラフィックを分離する方法はありません。IKEV2は、既存の認証インフラストラクチャと資格情報データベースを活用することにより、EAPペイロードでユーザー認証をサポートできます。これにより、レガシー認証を組み合わせることでユーザー認証を使用する場合、ユーザー間のトラフィックの分離が可能になります。IKEV2内で主張されたユーザーIDは、パケットごとに検証されます。
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で主張されたIDが認証されると、結果の派生キーがパケットごとの認証、整合性、およびリプレイ保護を提供するために使用されます。その結果、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の数が増えるにつれて、事前に共有されたキーがますます困難になります。Softwireセキュリティプロトコルは、主要な管理にスケーラブルなアプローチを提供する必要があります。可能な場合はいつでも、証明書を使用した認証が推奨されます。
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]に記載されているトンネルの分解、断片化、およびパケットごとのセキュリティチェックに関する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）が新しいIPアドレスを使用したり、Start-Connection-Request-Reply（SCCRP）を送信するときにポート番号を変更したりできますが、ソフトワイヤーのConcencoratorの実装はこれを行うべきではありません（[[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を使用してSTCCNメッセージをSIに送信します。新しいIKE_SAとCHILD_SAを新しいIPアドレスに確立する必要があります。
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" (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]).
ESP輸送モードを使用するため、L2TPパケットを運ぶUDPヘッダーは、トランジット中のIPヘッダーの部分の変更により、誤ったチェックサムを持ちます。[RFC3948]のセクション3.1.2では、チェックサムの修正に使用できる3つの手順を定義します。IKEV2にはそのチェックサムを計算するために必要な情報（NAT-OAペイロード）がないため、ソフトワイヤーの実装では「チェックサムの増分更新」（[RFC3948]に記載されているオプション1）を使用してはなりません。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]が使用されている場合、[RFC3193]のセキュリティポリシーデータベース（SPD）の例を使用すると、付録Aはソフトワイヤーモデルに適用できます。その場合、イニシエーターは常にクライアント（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）フラグなど）。Internet Key Exchange（IKE）もIKEV2 [RFC4306]で改訂および簡素化されています。次のセクションでは、ソフトワイヤーのSPD例を示して、改訂されたIPSECアーキテクチャとIKEV2を使用します。
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を指定でき、create_child_sa中にポート番号をTSR（トラフィックセレクター - レスポンダー）ペイロードで選択できます。以下は、それぞれSIとSCのパッドエントリを説明しています。パッドエントリは、構成の例のみです。SCのパッドエントリは、ユーザーのIDと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パッド：-Remote_Identity = si_Identityの場合、リモートアドレスsc_addressのchild_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パッド： - remote_identity = user_1の場合、seutionady（shared secret/certificate/eap）を認証し、child_sasをシンボリック名「l2tp_spd_entry」
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が保護する場合のIPv4パケット形式は、[RFC4891]の表1に類似したIPv6パケットを表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 | |
+----------------------------+------------------------------------+
Table 1: Packet Format for L2TPv2 with ESP Carrying IPv6 Packet
表1：IPv6パケットを運ぶESPを備えたL2TPV2のパケット形式
SPD for Softwire Initiator:
Softwireイニシエーター用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
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）を使用してからidi = user_1を使用してsa espトランスポートモードイニシエイト
SPD for Softwire Concentrator:
Sofwire concentator用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
Softwire concentorator spd-s-if name = "l2tp_spd_entry" local_address = ipv4-sc remote_address = any（pfp = 1）次のレイヤープロトコル= udp local_port = 1701 remote_port = any（pfp = 1）an sa 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のパッドエントリは、例として示されています。これらの例の構成は、このドキュメントのセクション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パッド：-Remote_Identity = si_Identityの場合、リモートアドレスsc_addressのchild_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パッド：-remote_Identity = user_2の場合、seutionady（shared secret/certificate/eap）を認証し、symbolic名 "l2tp_spd_entry"のchild_sasを承認します
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が保護する場合のIPv6パケット形式は、[RFC4891]の表1に類似したIPv4パケットを表2に示します。
+----------------------------+------------------------------------+
| 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：IPv4パケットを運ぶESPを備えたL2TPV2のパケット形式
SPD for Softwire Initiator:
Softwireイニシエーター用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
Softwire Initiator SPD-S-local_address = ipv6-si remote_address = ipv6-sc次レイヤープロトコル= udp local_port = 1701 remote_port = any（pfp = 1）を使用してからidi = user_2を使用してsa espトランスポートモードイニシエイト
SPD for Softwire Concentrator:
Sofwire concentator用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
Softwire concentorator SPD-S-if name = "l2tp_spd_entry" local_address = ipv6-sc remote_address = any（pfp = 1）次のレイヤープロトコル= udp local_port = 1701 remote_port = any（pfp = 1）an sa 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]）では、異なる住所ファミリタイプのトランジットコアにまたがる1つの住所ファミリタイプのネットワーク島にアクセスするための接続性を確立する必要があります。Transit Core全体に到達可能性を提供するために、AFBRはAccess Network IslandとTransit Core Networkの間にインストールされます。これらのAFBRは、自律システム内でプロバイダーエッジルーター（PE）として実行したり、自律システム全体でピアリングを実行したりできます。AFBRは、トランジットコアネットワーク全体の他の島へのメッシュ内のソフトウェアを確立およびカプセル化します。Transit Core Networkは、1つ以上のサービスプロバイダーで構成されています。
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.
Softwireの「Mesh」ソリューションでは、PEルーターのペア（AFBR）がBGPを使用してルーティング情報を交換します。Transit NetworkのAFBRノードは内部BGPスピーカーであり、SWエンキャップセットを交換し、Softwire Signalingを実行し、AF Access Island Reachability情報と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に似ています。Access IslandネットワークのCEルーターとトランジットネットワークのPEルーター間の接続は、静的に確立されます。アクセス島は、プロバイダーのトランジットネットワークのPEルーターを介して収容されるエンタープライズネットワークです。この場合、Access Islandネットワークはプロバイダーの自律システムによって管理されています。
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.
AFBRSは、コアネットワークへの複数の接続を持つ場合があり、複数のクライアントアクセスネットワークへの接続がある場合があります。クライアントアクセスネットワークは、プライベートネットワークまたはインターネットを介して互いに接続できます。クライアントアクセスネットワークに独自のAS番号がある場合、Access Islands内部にあるCEルーターがAFBRでプライベートBGPのピアリングを形成します。さらに、AFBRは、接続する各ネットワークと完全なインターネットルーティング情報を交換する必要がある場合があります。
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].
ソフトワイヤーメッシュソリューションのアーキテクチャは、プロバイダーがプロビジョニングした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. 敵は、Softwireデータトラフィックを削除することにより、サービス拒否（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.
セキュリティ攻撃は、コントロールプレーンにも取り付けることができます。Softwire Meshソリューションでは、BGPを使用してSoftwireのカプセル化が設定されます。[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.
「Softwire Problem Statement」[RFC4925]は、Softwireメッシュのセットアップメカニズムがソフトワイヤーのカプセル化を宣伝する必要があると認証をサポートする必要があると述べていますが、Transit Coreプロバイダーは状況によってはオフにすることを決定する場合があります。
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.
BGP認証メカニズムは[RFC2385]で指定されています。[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）は、状況によっては不十分であり、立派なレベルのセキュリティを維持するためにオペレーターの相互作用も必要です。TCP-MD5の現在の展開は、[RFC3562]に記載されているように、主要な管理に関していくつかの欠点を示しています。
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.
Transit Core全体にデータパケットを輸送するために、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は認証と整合性を提供できます。実装は、null暗号化[RFC4303]またはAH（IP認証ヘッダー）[RFC4302]でESPをサポートする必要があります。Transit Core Networkの一部が信頼されていない場合、暗号化を伴う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 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.
アクセス制御手法は、DOSなどのセキュリティ攻撃に対する重要な保護であり、カプセル化における暗号化強度に必要な補助です。特定のフィルターに関連付けられた基準に一致するパケットは、攻撃を防ぐため、または将来の攻撃の可能性の影響を軽減するために、廃棄または特別な治療を与えられる場合があります。
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.
このドキュメントでは、「ハブとスポーク」および「メッシュ」市場のソリューションのソフトワイヤー制御およびデータパケットのさまざまなセキュリティの脅威について説明します。これらの議論により、Softwireセキュリティプロトコルの実装は、「Softwire Problem Statement」[RFC4925]、「IPSEC」[RFC3193]を使用したL2TPを保護すること、「PPVPNSのセキュリティフレームワーク」[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に感謝したいと思います。ジョルディ・パレット・マルティネス、宮川清、Yasuhiro 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.
また、セキュリティに関するテキストを提供してくれたSoftwire Hub＆Skeed Deployment Framework Document [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] Townsley、W.、Valencia、A.、Rubens、A.、Pall、G.、Zorn、G。、およびB. Palter、 "Layer Two Tunneling Protocol" L2TP ""、RFC 2661、1999年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-Traversalの交渉」、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 4301、2005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302] Kent、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306] Kaufman、C。、「Internet Key Exchange（IKEV2）プロトコル」、RFC 4306、2005年12月。
[BGP-SEC] Christian, B. and T. Tauber, "BGP Security Requirements", Work in Progress, November 2008.
[BGP-SEC]クリスチャン、B。およびT.タウバー、「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、「The Internet Key Exchange（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）脅威分析とセキュリティ要件を搭載するためのプロトコル」、RFC 4016、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 4081、2005年6月。
[RFC4111] Fang, L., "Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4111, July 2005.
[RFC4111] Fang、L。、「プロバイダーが提供する仮想プライベートネットワーク（PPVPNS）のセキュリティフレームワーク」、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.、Montenegro、G。、およびE. Nordmark、「モバイルIPバージョン6ルート最適化セキュリティデザイン背景」、RFC 4225、2005年12月。
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, January 2006.
[RFC4272] Murphy、S。、「BGP Security脆弱性分析」、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仮想プライベートネットワーク（VPNS）」、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を使用してIPv6-in-IPV4トンネルを保護する」、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、「Softwire Problem Statement」、RFC 4925、2007年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、「Softwire Mesh Framework」、RFC 5565、2009年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、 "Softwire Hub and Speake Deployment Framework 2つのトンネルプロトコルバージョン2（L2TPV2（L2TPV2））」、RFC 5571、2009年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.
Softwire InitiatorとConcentatorの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)
Softwire Initiator SPD
Softwire Initiator SPD
Remote Local Protocol Action
------ ------ -------- ------
* IPV4-SC ESP BYPASS
* IPV4-SC IKE BYPASS
* IPV4-SC UDP, src * , dst 1701 PROTECT(ESP,
transport)
Softwire Concentrator SPD
Softwire concentator 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.
Softwire InitiatorとConcentatorの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)
Softwire Initiator SPD
Softwire Initiator SPD
Remote Local Protocol Action
------ ------ -------- ------
* IPV6-SC ESP BYPASS
* IPV6-SC IKE BYPASS
* IPV6-SC UDP, src * , dst 1701 PROTECT(ESP,
transport)
Softwire Concentrator SPD
Softwire concentator spd
Authors' Addresses
著者のアドレス
Shu Yamamoto NICT/KDDI R&D Labs 1-13-16 Hakusan, Bunkyo-ku Tokyo 113-0001 Japan
ヤマモト・ニクト/KDDI R＆D LABS 1-13-16 Hakusan、Bunkyo-Ku Tokyo 113-0001 Japan
Phone: +81-3-3868-6913
EMail: shu@nict.go.jp
Carl Williams KDDI R&D Labs Palo Alto, CA 94301 USA
Carl Williams Kddi R＆D Labs Palo Alto、CA 94301 USA
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
Hidetoshi Yokota Kddi R＆D Labs 2-1-15 Ohara Fujimino、Saitama 356-8502 Japan
Phone: +81-49-278-7894
EMail: yokota@kddilabs.jp
Florent Parent Beon Solutions Quebec, QC Canada
Florent Parent Beon Solutions Quebec、QC Canada
EMail: Florent.Parent@beon.ca