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「ハブとスポーク」と「メッシュ」ソリューションのセキュリティガイドラインについて説明します。一緒にsoftwire展開シナリオの議論と、セキュリティ攻撃に対する脆弱性は、このようなsoftwire制御とデータパケットに認証、完全性、機密性などのセキュリティ保護メカニズムを提供するために分析されます。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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ネットワークを介したIPv6ネットワーク間でのIPv4ネットワークを接続するためのカプセル化方法の標準化を指定します。 softwireは、再利用したり、既存の技術を拡張することにより、両方のアドレスファミリのグローバルな到達可能性を可能にするための接続を提供します。 Softwireワーキンググループは、異なるアドレスファミリから構成されるネットワークの横断を議論する際に現れた2つのシナリオに焦点を当てています。この文書では、2つのそのようなsoftwireソリューションスペースのセキュリティガイドラインを提供します：「ハブとスポーク」とのシナリオを「メッシュ」。 「ハブとスポーク」と問題点は、それぞれ、[RFC4925]セクション2及び3に記載されている「メッシュ」。 softwire接続用に選択されたプロトコルは、各ソリューションのためのより具体的な展開シナリオのセキュリティの考慮が必要です。この文書の範囲は、展開シナリオのためのセキュリティの脆弱性の分析を提供して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などの適切なセキュリティプロトコルによって保護されなければなりません。それはIKEv1のより信頼性の高いプロトコルであり、単一のプラットフォームに必要なプロトコルを統合しているため、新たな実装では、IPsecの鍵管理プロトコルとして、IKEv2の（インターネット鍵交換プロトコルバージョン2）を使用してください。この文書では、実装のガイダンスを提供し、「ハブとスポーク」シナリオではセキュリティ上の脆弱性を考慮して、セキュリティ保護メカニズムとしての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.
softwire「メッシュ」ソリューションは、異なるアドレスファミリー[RFC4925]で動作する中継コアを横切って一つのアドレスファミリーとアクセスネットワークからsoftwireトンネル上で送信されるデータパケットを保護するためのセキュリティメカニズムの様々なレベルをサポートしなければなりません。コントロールプレーンのセキュリティ機構はまた、「メッシュ」溶液で等制御データ変更、スプーフィング攻撃から保護する必要がある、BGPはトランジットコアにルーティング情報をsoftwireを配布するために使用されます。一方、BGPのためのセキュリティ問題は、他のワーキンググループで議論されています。この文書では、softwireメッシュ展開シナリオのためのセキュリティメカニズムの適切な使用方法を提供します。
The terminology is based on the "Softwire Problem Statement" [RFC4925].
用語は「Softwire問題文」[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.
同じまたは異なるアドレスファミリを使用する2つのネットワークを相互接続するデュアルスタックルーター - ファミリー境界ルータ（AFBR）に対処。他のAFBRs、隣接するコアルータ、および添付のカスタマエッジ（CE）ルータとの関係をピアリングAFBRフォーム; softwire発見及びシグナリングを実行します。クライアントのASF（I）到達可能性情報を広告します。および/はsoftwire転送ヘッダに顧客のパケットをデカプセル化カプセル化します。
Customer Edge (CE) - A router located inside an AF access island that peers with other CE routers within the access island network and with one or more upstream AFBRs.
顧客エッジ（CE） - アクセスアイランドネットワーク内および1つまたは複数の上流AFBRs有する他のCEルータとピアAFアクセス島の内側に位置するルータ。
Customer Premise Equipment (CPE) - An equipment, host or router, located at a subscriber's premises and connected with a carrier's access network.
顧客宅内機器（CPE） - 機器、ホストやルータ、加入者の構内に位置しており、通信事業者のアクセス網に接続されています。
Provider Edge (PE) - A router located at the edge of a transit core network that interfaces with the CE in an access island.
プロバイダエッジ（PE） - アクセス島におけるCEとインターフェーストランジットコアネットワークのエッジに位置するルータ。
Softwire Concentrator (SC) - The node terminating the softwire in the service provider network.
Softwireコンセントレータ（SC） - サービスプロバイダネットワーク内softwire終端ノード。
Softwire Initiator (SI) - The node initiating the softwire within the customer network.
Softwireイニシエータ（SI） - 顧客のネットワーク内softwireを開始ノード。
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） - softwireカプセル化セットは、トンネルヘッダパラメータ、トンネルヘッダの種類の優先順位、およびsoftwire内部に運ば期待ペイロードタイプ（例えば、IPv4の）を含みます。
Softwire Next_Hop (SW-NHOP) - This attribute accompanies client AF reachability advertisements and is used to reference a softwire on the ingress AFBR leading to the specific prefixes. It contains a softwire identifier value and a softwire next_hop IP address denoted as <SW ID:SW-NHOP address>. Its existence in the presence of client
Softwire NEXT_HOP（SW-NHOP） - この属性は、クライアントAF到達可能性広告を伴う、特定のプレフィックスに至る入口AFBRにsoftwireを参照するために使用されます。それはsoftwire識別子の値と、<：SW-NHOPアドレスSW ID>と表記softwire NEXT_HOP IPアドレスが含まれています。クライアントの存在下でその存在
AF prefixes (in advertisements or entries in a routing table) infers the use of softwire to reach that prefix.
（ルーティングテーブル内の広告またはエントリ内）AFプレフィックスは、プレフィックスに到達するsoftwireの使用を推測します。
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"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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が存在するノードが等PC、器具、センサー、等のCPEアクセスデバイス、元のCPEアクセスデバイスの背後にある別の専用のCPEルータ、またはホストデバイスの任意の種類とすることができます
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は、このようなsoftwireがサポートするなどこれは遊牧民のケースでのWi-Fiホットスポット、訪問したオフィスネットワーク、などの様々なアクセスネットワークにアクセスすることができます。
As the softwire deployment model, the following three cases as shown in Figure 1 should be considered. Cases 2 and 3 are typical for a nomadic node, but are also applicable to a stationary node. In order to securely connect a legitimate SI and SC to each other, the authentication process between SI and SC is normally performed using Authentication, Authorization, and Accounting (AAA) servers.
softwire展開モデルとして、図1に示すように、次の3つの場合が考慮されるべきです。ケース2及び3は、ノマディックノードの典型的なものであるだけでなく、固定ノードに適用可能です。しっかり相互に正当SIとSCを接続するために、SIとSCとの間の認証処理が正常に認証、許可、アカウンティング（AAA）サーバを使用して行われます。
visited network visited network
access provider service provider
+---------------------------------+
| |
+......v......+ +.....................|......+
. . . v .
+------+ . (case 3) . . +------+ +--------+ .
| |=====================.==| | | | .
| SI |__.________ . . | SC |<---->| AAAv | .
| |---------- \ . . | | | | .
+------+ . \\ . . +------+ +--------+ .
. \\ . . ^ .
^ +..........\\.+ +.....................|......+
| \\ |
| (case 2) \\ |
| \\ |
| \\ |
| +............+ \\ +.....................|......+
. . \\. v .
+------+ . . \\__+------+ +--------+ .
| | . (case 1) . ---| | | | .
| SI |=====================.==| SC |<---->| AAAh | .
| | . . . | | | | .
+------+ . . . +------+ +--------+ .
. . . .
+............+ +............................+
home network home network
access provider service provider
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サーバ（AAAv）などの訪問先ネットワークサービスプロバイダ内のホームAAAサーバ（AAAhを）およびそれになど、ホームネットワークサービスプロバイダでのAAAサーバを指します。
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問題文」[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.
softwireが保護されていないネットワークで使用される場合、より強力な認証処理が必要である（例えば、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は、モバイルである場合、それは例えば、のWi-Fiホットスポットネットワークが異なるISPが提供する、訪問先のアクセスネットワークへのホームアクセスネットワークを提供するホームISPからローミングがあります。 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とホームAAAサーバは、それらの間の信頼関係と通信が確保されなければならない持たなければなりません。 SCは、SIを認証すると、SCはホーム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.
SIがモバイルのときケース2では、訪問アクセスネットワークプロバイダを介してホームネットワークサービスプロバイダへのアクセスが許可されます。ホームネットワーク内の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.
SIは、異なるネットワーク・サービス・プロバイダの管理ドメインにローミング場合ケース3では、訪問したAAAサーバは、SI認証のための情報を取得するためにホームAAAサーバと通信します。訪問したAAAサーバは、ホームAAAサーバとそれらの間の通信との信頼関係が正しく指定された条件の下で合意されているローミングサービスを実行するために確保されなければならない持たなければなりません。
Note that the path for the communications between the home AAA server and the visited AAA server may consist of several AAA proxies. In this case, the AAA proxy threat model SHOULD be considered [RFC2607]. A malicious AAA proxy may launch passive or active security attacks. The trustworthiness of proxies in AAA proxy chains will weaken when the hop counts of the proxy chain is longer. For example, the accounting information exchanged among AAA proxies is attractive for an adversary. The communication between a home AAA server and a visited AAA server MUST be protected.
ホームAAAサーバと訪問したAAAサーバ間の通信のためのパスは、いくつかのAAAプロキシから構成されてもよいことに注意してください。この場合には、AAAプロキシ脅威モデルは[RFC2607]と考えるべきです。悪質なAAAプロキシは、パッシブまたはアクティブなセキュリティ攻撃を仕掛けることがあります。プロキシチェーンのホップ数が長くなるときAAAプロキシチェーンにおけるプロキシの信頼性が弱まります。例えば、AAAプロキシ間で交換会計情報は、敵にとって魅力的です。ホームAAAサーバと訪問したAAAサーバの間の通信を保護しなければなりません。
Softwire can be used to connect IPv6 networks across public IPv4 networks and IPv4 networks across public IPv6 networks. The control and data packets used during the softwire session are vulnerable to the security attacks.
Softwireは公衆IPv6ネットワーク間でのパブリックIPv4ネットワークとIPv4ネットワークを介してIPv6ネットワークを接続するために使用することができます。 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).
softwireの完全な脅威分析はsoftwireセットアップ、ペイロードを輸送するために使用されるカプセル化方法、および構成するために使用される他のプロトコル（例えば、ルータ広告、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]）のサブセットを使用します。 softwire「ハブとスポーク」モデルでは、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]、およびルーティングプロトコル[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）パケットを送信します。制御接続確立時 - L2TPv2は、（チャレンジハンドシェイク認証プロトコルCHAPと同様である）任意のトンネル認証システムを提供します。これは、SIとSC間の共有秘密を必要とし、どのキー管理は、このL2TPv2のために提供されていません。
When the L2TPv2 control connection is established, the SI and SC optionally enter the authentication phase after completing PPP Link Control Protocol (LCP) negotiation. PPP authentication supports one-way or two-way CHAP authentication, and can leverage existing AAA infrastructure. PPP authentication does not provide per-packet authentication.
L2TPv2コントロール接続が確立されると、SIおよびSCは、必要に応じてPPPリンク制御プロトコル（LCP）のネゴシエーションを完了した後に、認証段階に入ります。 PPP認証は、一方向または双方向のCHAP認証をサポートし、既存のAAAインフラストラクチャを活用することができます。 PPP認証は、パケットごとの認証を提供しません。
PPP encryption is defined but PPP Encryption Control Protocol (ECP) negotiation does not provide for a protected cipher suite negotiation. PPP encryption provides a weak security solution [RFC3193]. PPP ECP implementation cannot be expected. PPP authentication also does not provide scalable key management.
PPPの暗号化が定義されていますが、PPP暗号化制御プロトコル（ECP）ネゴシエーションが保護された暗号スイートのネゴシエーションのために用意されていません。 PPPの暗号化は弱いセキュリティソリューション[RFC3193]を提供します。 PPP ECPの実装は期待できません。 PPPの認証もスケーラブルな鍵管理を提供していません。
Once the L2TPv2 tunnel and PPP configuration are successfully established, the SI is connected and can start using the connection.
L2TPv2トンネルおよびPPP設定が正常に確立されると、SIが接続され、接続を使用して開始することができます。
These steps are vulnerable to man-in-the-middle (MITM), denial-of-service (DoS), and service-theft attacks, which are caused by the following adversary actions.
これらの手順は、内、中間マン（MITM）、サービス拒否（DoS）、および以下の敵の行動によって引き起こされるサービス盗難攻撃に対して脆弱です。
Adversary attacks on softwire include:
softwire上の敵の攻撃は、次のとおりです。
1. An adversary may try to discover identities and other confidential information by snooping data packets.
1.敵は、データパケットをスヌーピングによってアイデンティティおよびその他の機密情報を発見しようとします。
2. An adversary may try to modify both control and data packets. This type of attack involves integrity violations.
2.敵は両方の制御とデータパケットを変更しようとするかもしれません。この種の攻撃は、整合性違反を伴います。
3. An adversary may try to eavesdrop and collect control messages. By replaying these messages, an adversary may successfully hijack the L2TP tunnel or the PPP connection inside the tunnel. An adversary might mount MITM, DoS, and theft-of-service attacks.
3.敵は盗聴や制御メッセージを収集しようとするかもしれません。これらのメッセージを再生することによって、敵対者は正常L2TPトンネルまたはトンネル内のPPP接続をハイジャックすることができます。敵はMITM、DoS攻撃、およびサービスの窃盗攻撃をマウントすることがあります。
4. An adversary can flood the softwire node with bogus signaling messages to cause DoS attacks by terminating L2TP tunnels or PPP connections.
4.敵はL2TPトンネルやPPP接続を終了させることによってDoS攻撃を引き起こすために偽のシグナリングメッセージでsoftwireノードをあふれさせることができます。
5. An adversary may attempt to disrupt the softwire negotiation in order to weaken or remove confidentiality protection.
5.敵は機密保護を弱めるまたは除去するためにsoftwire交渉を中断するために試みることができます。
6. An adversary may wish to disrupt the PPP LCP authentication negotiation.
6.敵はPPP LCP認証交渉を破壊することもできます。
When AAA servers are involved in softwire tunnel establishment, the security attacks can be mounted on the communication associated with AAA servers. Specifically, for Case 3 stated in Section 3.2, an adversary may eavesdrop on the packets between AAA servers in the home and visited network and compromise the authentication data. An adversary may also disrupt the communication between the AAA servers, causing a service denial. Security of AAA server communications is out of scope of this document.
AAAサーバがsoftwireトンネル確立に関与している場合、セキュリティ攻撃は、AAAサーバに関連付けられた通信に取り付けることができます。具体的には、ケース3のために、3.2節で述べた、敵は、家庭内の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のふりをすることができます。この場合、敵対者はトラフィック（例えば、「不正」softwireコンセントレータ）を傍受するためにSCを偽装することができます。
The rogue SC can introduce a denial-of-service attack by blackholing packets from the SI. The rogue SC can also eavesdrop on all packets sent from or to the SI. Security threats of a rogue SC are similar to a compromised router.
不正SCは、SIからのパケットをブラックホール化によって、サービス拒否攻撃を導入することができます。不正SCはまた、SIからかに送信されたすべてのパケットを盗聴することができます。不正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]を制御することができます。攻撃者はそのようなDoS攻撃などの攻撃に対して脆弱なシステムを残して、偽のパケットを注入するためのSCにおけるカプセル開放装置の特定のイングレスフィルタリングをチェックすることなく、それが可能です。イングレスフィルタリングを使用して、不正な内部アドレスを拒否することができます。内部アドレスの入力フィルタリングせずに、攻撃の別の種類が発生する可能性があります。別の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.
イングレスフィルタリングは、アドレス詐称が起こった場合には完全な保護を提供していません。アドレススプーフィングに対するより良い保護を提供するためには、正当なアドレスと認証されたID間の結合による認証を実装する必要があります。これは、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.
SIとSCの間に1 Softwire制御メッセージは、盗聴やなりすまし攻撃から保護されなければなりません。
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.
softwire制御パケット、認証、整合性、および再生保護のためにサポートしなければならない、と機密性がサポートされるべきです。
For softwire data packets, authentication, integrity, and replay protection SHOULD be supported, and confidentiality MAY be supported.
softwireデータパケット、認証、整合性、および再生保護のためにサポートする必要があり、機密性をサポートすることができます。
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問題文」[RFC4925]は、セキュリティ保護メカニズムを定義する際に考慮されている「ハブとスポーク」ソリューションのためのいくつかの要件を提供します。
1. The control and/or data plane MUST be able to provide full payload security when desired.
1.制御及び/又はデータプレーンは、所望の場合、完全なペイロードセキュリティを提供できなければなりません。
This additional security protection must be separable from the softwire tunneling mechanism.
この追加のセキュリティ保護がsoftwireトンネリングメカニズムから分離可能でなければなりません。
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.
たとえば、パスワード認証プロトコル（PAP）平文パスワードを使用して、SCへのアクセスを使用してSI /ユーザーを検討します。多くの状況では、これは大きなセキュリティリスクを表します。敵は盗まれたパスワードを使用して、正当なユーザーとして偽装することがあります。チャレンジハンドシェイク認証プロトコル（CHAP）[RFC1994]はSCから送られた「チャレンジ」でパスワードを暗号化します。パスワードの盗難を軽減することができます。 CHAPのみ一方向の認証をサポートしていますしかし、のman-in-the-middleまたは不正なSCのリスクを回避することはできません。拡張認証プロトコル - トランスポート層セキュリティ（EAP-TLS）[RFC5216]は、相互認証を義務付けし、不正なSCを回避することができます。
When the SI established a connection to the SC through a public network, the SI may want proof of the SC identity. Softwire MUST support mutual authentication to allow for such a scenario.
SIは、公衆ネットワークを介して、SCへの接続を確立すると、SIは、SCの身元の証明をすることもできます。 Softwireは、このようなシナリオを可能にするための相互認証をサポートしなければなりません。
In some circumstances, however, the service provider may decide to allow non-authenticated connection [RFC5571]. For example, when the customer is already authenticated by some other means, such as closed networks, cellular networks at Layer 2, etc., the service provider may decide to turn authentication off. If no authentication is conducted on any layer, the SC acts as a gateway for anonymous connections. Running such a service MUST be configurable by the SC administrator and the SC SHOULD take some security measures, such as ingress filtering and adequate logging of activity. It should be noted that anonymous connection service cannot provide the security functionalities described in this document (e.g., integrity, replay protection, and confidentiality).
いくつかの状況においては、しかしながら、サービスプロバイダは、非認証接続[RFC5571]を許可することを決定することができます。顧客がすでになど閉域網、レイヤ2での携帯電話ネットワーク、などいくつかの他の手段によって認証されたときに、例えば、サービスプロバイダは、認証をオフにすることもできます。認証がどの層で行われていない場合、SCは、匿名接続のためのゲートウェイとして機能します。そのようなサービスを実行すると、SCの管理者によって構成可能でなければなりませんし、SCは、イングレスフィルタリングや活動の十分なロギングなど、いくつかのセキュリティ対策を、取る必要があります。匿名接続サービスは、この文書（例えば、整合性、再生保護、および機密性）で説明したセキュリティ機能を提供することができないことに留意すべきです。
L2TPv2 selected as the softwire phase 1 protocol supports PPP authentication and L2TPv2 authentication. PPP authentication and L2TPv2 have various security threats, as stated in Section 3.3. They will be used in the limited condition as described in the next subsections.
softwire相1のプロトコルとして選択されたL2TPv2は、PPP認証とL2TPv2認証をサポートします。 3.3節で述べたようにPPP認証およびL2TPv2は、さまざまなセキュリティ上の脅威を持っています。次のサブセクションで説明するように彼らは、限られた条件の中で使用されます。
PPP can provide mutual authentication between the SI and SC using CHAP [RFC1994] during the connection-establishment phase (via the Link Control Protocol, LCP). PPP CHAP authentication can be used when the SI and SC are on a trusted, non-public IP network.
PPPは、（リンク制御プロトコル、LCPを介して）接続確立段階中CHAP [RFC1994]を使用してSIとSCとの間の相互認証を提供することができます。 SIおよびSCは信頼できる、非パブリックIPネットワーク上にあるとき、PPP CHAP認証を使用することができます。
Since CHAP does not provide per-packet authentication, integrity, or replay protection, PPP CHAP authentication MUST NOT be used unprotected on a public IP network. If other appropriate protected mechanisms have been already applied, PPP CHAP authentication MAY be used.
CHAPは、パケットごとの認証、完全性、または再生保護を提供していないので、PPP CHAP認証では、パブリックIPネットワーク上で保護されていない使用してはいけません。他の適切な保護メカニズムがすでに適用されている場合は、PPP CHAP認証を使用することができます。
Optionally, other authentication methods such as PAP, MS-CHAP, and EAP MAY be supported.
必要に応じて、そのようなPAP、MS-CHAP、およびEAPなどの他の認証方法をサポートすることができます。
L2TPv2 provides an optional CHAP-like tunnel authentication during the control connection establishment [RFC2661], Section 5.1.1. L2TPv2 authentication MUST NOT be used unprotected on a public IP network, similar to the same restriction applied to PPP CHAP authentication.
L2TPv2は、制御コネクション確立[RFC2661]、セクション5.1.1中に任意CHAP状トンネル認証を提供します。 L2TPv2認証は、PPP CHAP認証に適用される同じ制限と同様に、パブリックIPネットワーク上で保護されていない使用してはいけません。
To meet the above requirements, all softwire-security-compliant implementations MUST implement the following security protocols.
上記の要件を満たすために、すべてのsoftwireセキュリティ準拠の実装は、次のセキュリティプロトコルを実装しなければなりません。
IPsec ESP [RFC4303] in transport mode is used for securing softwire control and data packets. The Internet Key Exchange (IKE) protocol [RFC4306] MUST be supported for authentication, security association negotiation, and key management for IPsec. The applicability of different versions of IKE is discussed in Section 3.5.
トランスポート・モードのIPsec ESP [RFC4303]はsoftwire制御およびデータパケットを保護するために使用されます。 IKE（Internet Key Exchange）プロトコル[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トラバーサルをサポートしなければなりません。 IPsecは使用されたときにIPsec ESPパケット[RFC3948]とIKE [RFC3947]でNATトラバーサルの交渉のUDPカプセル化をサポートしなければなりません。
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によって実装softwire「ハブとスポーク」溶液が信頼できないネットワークで使用される場合、softwireは、IPsecなどの適切なセキュリティプロトコルによって保護されなければなりません。このセクションでは、L2TPv2ベースのsoftwireのIPsecの利用のためのガイドラインを提供します。
[RFC3193] discusses how L2TP can use IKE [RFC2409] and IPsec [RFC2401] to provide tunnel authentication, privacy protection,
[RFC3193]はL2TPトンネル認証、プライバシー保護を提供するために、IKE [RFC2409]とIPsec [RFC2401]を使用する方法について説明し、
integrity checking, and replay protection. Since the publication of [RFC3193], the revisions to IPsec protocols have been published (IKEv2 [RFC4306], ESP [RFC4303], NAT-traversal for IKE [RFC3947], and ESP [RFC3948]).
整合性チェック、および再生保護。 [RFC3193]の出版ので、IPsecプロトコルの改定が発表されている（のIKEv2 [RFC4306]、ESP [RFC4303] IKE [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]はサポートしなければなりません。しかし、新しい実装があるため、それはIKE [RFC2409]の上に持っている多くの利点のIPsecのためのIKEv2 [RFC4306]を使用すべきです。新しい展開では、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]はsoftwire「ハブとスポーク」は、溶液中で適用することができるが、そのようなNATトラバーサルとしてsoftwire要件は、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.
事前共有鍵または証明書の選択がsoftwireは、セクション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]はusername-とパスワードベースの認証がすでに展開されている環境でも有用である可能性がある従来の認証方式をサポートしています。
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上のIKEv2を使用すべきであるという点でIKE [RFC2409]よりも信頼性の高いプロトコルです。
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.
次のセクションでは、softwire「ハブとスポーク」モデルに適用されるL2TPv2を保護するためにIPsecを使って説明します。特に明記しない限り、IKEv2のと新しいのIPsecアーキテクチャ[RFC4301]は想定されます。
IPsec implementation using IKE only supports machine authentication. There is no way to verify a user identity and to segregate the tunnel traffic among users in the multi-user machine environment. IKEv2 can support user authentication with EAP payload by leveraging the existing authentication infrastructure and credential database. This enables traffic segregation among users when user authentication is used by combining the legacy authentication. The user identity asserted within IKEv2 will be verified on a per-packet basis.
IKEを使用してIPsec実装は、マシン認証をサポートしています。ユーザーの身元を確認するために、マルチユーザマシン環境でのユーザー間でトンネルトラフィックを分離する方法はありません。 IKEv2のは、既存の認証インフラや資格情報データベースを活用することにより、EAPペイロードを持つユーザ認証をサポートすることができます。これは、ユーザー認証が従来の認証を組み合わせることにより、使用されているユーザーの間でトラフィックの分離を可能にします。 IKEv2の中にアサートされたユーザー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交換が安全にAAAサーバからSCに転送されたセッションキーを作成するために、SIとAAAサーバの間で実行します。関与するエンティティ間の信頼関係は、このドキュメントのセクション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.
アイデンティティがIKEにアサートIPsecは、認証されると、結果として得られたキーは、パケットごとの認証、整合性、および再生保護を提供するために使用されています。結果として、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).
事前共有キーが使用される場合、グループ事前共有キーがあるためman-in-the-middle攻撃に対する脆弱性（[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の相互運用性、第3節では、考慮しなければなりません。
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仕様は、応答者（softwireでSC）が新しいIPアドレスを使用するか、ポート番号を変更することができますが、スタートコントロール接続要求 - 応答（SCCRP）を送信する際に、softwireコンセントレータの実装はこれをすべきではありません（[ 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.
しかし、いくつかの理由から、例えば、「ロードバランシング」SC間のために、IPアドレスの変更が必要となります。 IPアドレスの変更を通知するために、SCは、L2TPv2メッセージに結果とエラーコードAVPを使用してSIにStopCCNメッセージを送信します。新しい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ペイロード）を有していないためsoftwire実装は、「チェックサムの増分更新」（[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はsoftwireモデルに適用することができます。その場合には、イニシエータは、常にクライアント（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]はより多くの柔軟性（エントリごとに複数のセレクタ、アドレス範囲のリスト、ピア認証データベース（PAD）、「パケットから移入」（PFP）フラグなど）を提供するために、SPDエントリを再定義します。インターネット鍵交換（IKE）ものIKEv2 [RFC4306]に改訂し、簡素化されています。次のセクションでは、改訂されたIPsecアーキテクチャとのIKEv2を使用するsoftwire用SPDの例を提供します。
If IKEv2 is used as the key management protocol, [RFC4301] provides the guidance of the SPD entries. In IKEv2, we can use the PFP flag to specify the SA, and the port number can be selected with the TSr (Traffic Selector - Responder) payload during CREATE_CHILD_SA. The following describes PAD entries on the SI and SC, respectively. The PAD entries are only example configurations. The PAD entry on the SC matches user identities to the L2TP SPD entry. This is done using a symbolic name type specified in [RFC4301].
IKEv2の鍵管理プロトコルとして使用されている場合は、[RFC4301]はSPDエントリのガイダンスを提供します。 IKEv2のでは、我々は、SAを指定するPFPフラグを使用することができ、およびポート番号がTSrを（トラフィックセレクタ - レスポンダ）で選択することができるCREATE_CHILD_SA中ペイロード。以下は、それぞれ、SIおよびSC上のパッドのエントリについて説明します。 PADのエントリは、あくまでも一例の構成です。 SC上のパッドエントリはL2TP SPDエントリにユーザーIDと一致しました。これは、[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を認可IF
SC PAD: - IF remote_identity = user_1 Then authenticate (shared secret/certificate/EAP) and authorize CHILD_SAs for symbolic name "l2tp_spd_entry"
SCのパッド： - IF remote_identity = USER_1次に認証（共有秘密/証明書/ EAP）とシンボリック名 "l2tp_spd_entry" のためのCHILD_SAsを承認
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].
IPv4パケットフォーマットESPを保護し、L2TPv2は、IPv6パケットが[RFC4891]表1と同様であり、表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：ESPは、IPv6パケットを運ぶと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イニシエータSPD-S - IF local_address =のIPv4-SI REMOTE_ADDRESS =のIPv4-SC次の層プロトコル= UDP LOCAL_PORT = 1701 REMOTE_PORT = ANY（PFP = 1）は、次にSA ESPトランスポートモードを使用したIPv4-SCに対処するためにIDiと= USER_1を使用して開始
SPD for Softwire Concentrator:
Softwireコンセントレータの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コンセントレータSPD-S - 名= "l2tp_spd_entry" local_address IF =のIPv4-SCのREMOTE_ADDRESS = ANY（PFP = 1）次の層プロトコル= UDP LOCAL_PORT = 1701 REMOTE_PORT = ANY（PFP = 1）は、次にSA ESPトランスポートモードを使用します
The PAD entries for SI and SC are shown as examples. These example configurations are similar to those in Section 3.5.4.1 of this document.
SIおよびSC用のパッドエントリは例として示されています。これらの構成例は、このドキュメントのセクション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を認可IF
SC PAD: - IF remote_identity = user_2 Then authenticate (shared secret/certificate/EAP) and authorize CHILD_SAs for symbolic name "l2tp_spd_entry"
SCのパッド： - IF remote_identity = USER_2次に認証（共有秘密/証明書/ EAP）とシンボリック名 "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].
IPv6パケットフォーマットESPを保護し、L2TPv2は、IPv4パケットは[RFC4891]表1と同様であり、表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：ESPがIPv4パケットを運ぶと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イニシエータSPD-S - IF local_address =のIPv6-SI REMOTE_ADDRESS =のIPv6-SC次の層プロトコル= UDP LOCAL_PORT = 1701 REMOTE_PORT = ANY（PFP = 1）は、次にSA ESPトランスポートモードを使用したIPv6-SCに対処するためにIDiと= USER_2を使用して開始
SPD for Softwire Concentrator:
Softwireコンセントレータの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コンセントレータSPD-S - 名= "l2tp_spd_entry" local_address IF =のIPv6-SCのREMOTE_ADDRESS = ANY（PFP = 1）次の層プロトコル= UDP LOCAL_PORT = 1701 REMOTE_PORT = ANY（PFP = 1）は、次にSA ESPトランスポートモードを使用します
In the softwire "Mesh" solution ([RFC4925], [RFC5565]), it is required to establish connectivity to access network islands of one address family type across a transit core of a differing address family type. To provide reachability across the transit core, AFBRs are installed between the access network island and transit core network. These AFBRs can perform as Provider Edge routers (PE) within an autonomous system or perform peering across autonomous systems. The AFBRs establish and encapsulate softwires in a mesh to the other islands across the transit core network. The transit core network consists of one or more service providers.
softwire「メッシュ」溶液（[RFC4925]、[RFC5565]）には、異なるアドレスファミリータイプの通過コアを横切って一つのアドレスファミリータイプのネットワーク・アイランドにアクセスするための接続を確立する必要があります。トランジットコア間で到達可能性を提供するために、AFBRsは、アクセスネットワークの島とトランジットコアネットワークの間に設置されています。これらAFBRsは、自律システム内のプロバイダーエッジルータ（PE）として実行するか、または自律システム間でピアリングを行うことができます。 AFBRsはトランジットコアネットワークを介して他の島にメッシュ内のsoftwiresを確立し、カプセル化します。トランジットコアネットワークは、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「メッシュ」は、溶液中で、PEルータ（AFBRs）のペアは、ルーティング情報を交換するためにBGPを使用します。トランジットネットワーク内AFBRノードは、内部BGPスピーカであり、交換SW-ENCAPセットに直接またはルートリフレクタを介して相互にピアsoftwireシグナリングを実行し、AFアクセス島到達可能性情報及びSW-NHOP情報をアドバタイズします。そのような情報は、自律システム内でアドバタイズされた場合、他のAFBRsからそれらを受信AFBRノードが他のAFBRノードに転送しません。 AFBRsの間で情報を交換するには、フルメッシュ接続が確立されます。
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.
AFBRsプロバイダのコアネットワークのエッジに位置するPEルータである場合、このアーキテクチャは、L3VPNは、[RFC4364]に記載と同様です。トランジットネットワークにおけるアクセスアイランドネットワーク内のCEルータとPEルータ間の接続は、静的に確立されます。アクセス・アイランドは、プロバイダの中継網でPEルータを介して収容企業ネットワークです。この場合、アクセス島ネットワークは、プロバイダの自律システムによって管理されています。
The AFBRs may have multiple connections to the core network, and also may have connections to multiple client access networks. The client access networks may connect to each other through private networks or through the Internet. When the client access networks have their own AS number, a CE router located inside access islands forms a private BGP peering with an AFBR. Further, an AFBR may need to exchange full Internet routing information with each network to which it connects.
AFBRsは、コアネットワークへの複数の接続を有していてもよく、また、複数のクライアントアクセスネットワークへの接続を有することができます。クライアント・アクセス・ネットワークは、プライベートネットワークを介して、またはインターネットを介して相互に接続することができます。クライアント・アクセス・ネットワークは、自分のAS番号を持っている場合は、アクセスの島々の内側にあるCEルータは、プライベートBGPはAFBRとピアリング形成しています。さらに、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.
トランジットコアのすべてのAFBRノードは、信頼関係やsoftwiresを確立するために、お互いに契約が必要です。トランジットコアは、単一の管理ドメインで構成されている場合、全てのノードが（例えば、AFBR、PE、またはルートリフレクタは、該当する場合）相互に信頼されているものとします。
If the transit core consists of multiple administrative domains, intermediate routers between AFBRs may not be trusted.
トランジットコアが複数の管理ドメインで構成されている場合、AFBRs間の中間ルータは、信頼されなくてもよいです。
There MUST be a trust relationship between the PE in the transit core and the CE in the corresponding island, although the link(s) between the PE and the CE may not be protected.
PEとCEの間のリンク（複数可）は保護されないかもしれないが、トランジットコアにおけるPEおよび対応するアイランドにCEとの間の信頼関係が存在していなければなりません。
As the architecture of the softwire mesh solution is very similar to that of the provider-provisioned VPN (PPVPN). The security threat considerations on the PPVPN operation are applicable to those in the softwire mesh solution [RFC4111].
softwireメッシュソリューションのアーキテクチャとしてプロバイダプロビジョニングVPN（PPVPN）のものと非常に類似しています。 PPVPN操作上のセキュリティ上の脅威に関する注意事項はsoftwireメッシュソリューション[RFC4111]のものに適用されます。
Examples of attacks to data packets being transmitted on a softwire tunnel include:
softwireトンネル上で送信されるデータ・パケットへの攻撃の例としては：
1. An adversary may try to discover confidential information by sniffing softwire packets.
1.敵はsoftwireパケットを盗聴することにより、機密情報を発見しようとします。
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.敵は、許可ドメインに属していないと記録され、再生されたかつての正当なパケットのコピーを挿入するためにsoftwireパケットを偽装しようとするかもしれません。
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攻撃はsoftwireトンネルの外部からsoftwireに非認証大量のデータを偽装することによってデータプレーンに対して取り付けることができます。
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.敵はsoftwireパケットを盗聴すると、パケット自体が暗号化されている場合でも、目に見えるかもしれそれらの側面またはメタ側面を検討しようとするかもしれません。攻撃者は、量やトラフィック、パケットサイズ、送信元と送信先のアドレス、などのタイミングに基づいて有用な情報を得るかもしれません
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メッシュソリューションでは、softwireのカプセル化は、BGPを使用して設定されます。 [RFC4272]に記載されているように、BGPは、機密性違反のような様々なセキュリティ上の脅威に対して脆弱です。リプレイ攻撃。挿入、削除、およびBGPメッセージの修正。 man-in-the-middle攻撃。およびサービス拒否攻撃。
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節で説明したアクセスネットワークにおけるユーザ間の信頼関係、トランジットコアプロバイダ、およびネットワークの他の部分は、特定のsoftwireメッシュ展開のためのセキュリティ保護メカニズムの適用性を決定する重要な要素です。
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問題文」[RFC4925]はsoftwireカプセル化を宣伝するsoftwireメッシュセットアップメカニズムが認証をサポートしなければならないと述べているが、トランジットコア・プロバイダは、いくつかの状況でそれをオフにすることもできます。
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）は、いくつかの状況では不十分であり、また、セキュリティの立派なレベルを維持するために、オペレータとの対話を必要とします。 [RFC3562]に記載されているようにTCP-MD5の展示の現在の配備鍵管理に関していくつかの欠点。
Key management can be especially cumbersome for operators. The number of keys required and the maintenance of keys (issue/revoke/ renew) has had an additive effect as a barrier to deployment. Thus, automated means of managing keys, to reduce operational burdens, is available in the BGP security system ([BGP-SEC], [RFC4107]).
鍵の管理は、事業者にとって特に面倒なことができます。必要なキーの数とキーのメンテナンスは、（問題/更新/取り消し）導入への障壁としての添加効果がありました。このように、運用負担を軽減するために、鍵を管理する手段を自動化し、BGPのセキュリティシステムで利用可能である（[BGP-SEC]、[RFC4107]）。
Use of IPsec counters the message insertion, deletion, and modification attacks, as well as man-in-the-middle attacks by outsiders. If routing data confidentiality is desired, the use of IPsec ESP could provide that service. If eavesdropping attacks are identified as a threat, ESP can be used to provide confidentiality (encryption), integrity, and authentication for the BGP session.
IPsecのを使用すると、メッセージの挿入、削除、および変更攻撃だけでなく、部外者によるman-in-the-middle攻撃に対抗します。ルーティングデータの機密性が必要な場合は、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.
L2TPv3の、IPインIP、MPLS（LDPベースおよびベースのRSVP-TE）、およびGRE：トランジットコアを介してデータパケットを転送するために、メッシュ溶液は、複数のカプセル化を定義します。確実にそのようなデータ・パケットを転送するために、softwireは、IPsecトンネルをサポートしなければなりません。
IPsec can provide authentication and integrity. The implementation MUST support ESP with null encryption [RFC4303] or else AH (IP Authentication Header) [RFC4302]. If some part of the transit core network is not trusted, ESP with encryption MAY be applied.
IPsecは、認証と完全性を提供することができます。実装は他のヌル暗号化[RFC4303]またはAH（IP認証ヘッダー）[RFC4302]でESPサポートしなければなりません。トランジットコアネットワークの一部が信頼されていない場合は、ESP暗号化を適用することができます。
Since the softwires are created dynamically by BGP, the automated key distribution MUST be performed by IKEv2 [RFC4306] with either pre-shared key or public key management. For dynamic softwire IPsec tunnel creation, the pre-shared key will be the same in all routers. Namely, pre-shared key indicates here "group key" instead of "pairwise-shared" key.
softwiresがBGPによって動的に作成されているので、自動鍵配布は、事前共有鍵または公開鍵管理のいずれかでのIKEv2 [RFC4306]によって実行されなければなりません。動的softwire 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.
一緒に暗号化セキュリティで保護され、アクセス制御技術は、サービスプロバイダーネットワーク（トランジットネットワーク）外部からの攻撃への露出を減らします。アクセス制御技術は、フィルタによって、ならびに実装するために使用されている制御/シグナリング/管理プロトコルのためのセッションを導入により、パケット・バイ・パケットまたはパケットフローごとのパケットフローアクセス制御を含みますsoftwireメッシュ。
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セキュリティプロトコルの実装は、「L2TP IPsecを使用しての保護」「Softwire問題文」[RFC4925]、[RFC3193]、「PPVPNsのためのセキュリティフレームワーク」[RFC4111]、および「の使用を指定するためのガイドラインを参照して提供されていますIPsecの」[RFC5406]。セキュリティプロトコルの雇用のためのガイドラインはまた、特定の展開状況を考慮与えられています。
Note that this document discusses softwire tunnel security protection and does not address end-to-end protection.
この文書はsoftwireトンネルのセキュリティ保護について説明し、エンド・ツー・エンドの保護に対応しないことに注意してください。
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に感謝したいと思います。彼らのフィードバックのためのジョルディPaletマルティネス、宮川晋、康弘白崎、そしてブルーノ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ハブの作者に感謝することも好き＆セキュリティに関するテキストを提供するための展開フレームワークドキュメント[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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、バレンシア、A.、ルーベンス、A.、ポール、G.、ツォルン、G.、およびB. Palter、 "レイヤ2トンネリングプロトコル "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]パテル、B.、Aboba、B.、ディクソン、W.、ゾルン、G.、およびS.ブース、 "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.ボルペ、 "IKEにおけるNATトラバーサルのネゴシエーション"、RFC 3947、2005年1月。
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005.
[RFC3948] Huttunen、A.、Swander、B.、ボルペ、V.、DiBurro、L.、及びM.ステンバーグ、 "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]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]カウフマン、C.、 "インターネットキーエクスチェンジ（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]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.カレル、 "インターネットキー交換（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]リーチ、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]パルタサラティ、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]牙、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.ギリガン、 "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.、オーラ、T.、モンテネグロ、G.、およびE. Nordmarkと、 "モバイルIPバージョン6経路最適化セキュリティデザインの背景"、RFC 4225、2005年12月。
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, January 2006.
[RFC4272]マーフィー、S.、 "BGPセキュリティの脆弱性分析"、RFC 4272、2006年1月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]ローゼン、E.およびY. Rekhter、 "BGP / MPLS IP仮想プライベートネットワーク（VPN）"、RFC 4364、2006年2月。
[RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, October 2006.
[RFC4593] Barbir、A.、マーフィー、S.、およびY.ヤン、 "ルーティングプロトコルへの一般的な脅威"、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.、パルタサラティ、M.、Savola、P.、およびH. Tschofenig、RFC 4891、2007年5月の "IPv6インIPv4トンネルを保護するためにIPsecを使用します"。
[RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire Problem Statement", RFC 4925, July 2007.
[RFC4925]のLi、X.、ドーキンス、S.、ウォード、D.、およびA.デュラン、 "Softwire問題文"、RFC 4925、2007年7月。
[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication Protocol", RFC 5216, March 2008.
[RFC5216]サイモン、D.、Aboba、B.、およびR.ハースト、 "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]呉、J.、キュイ、Y.、メス、C.、およびE.ローゼン、 "Softwireメッシュフレームワーク"、RFC 5565、2009年6月。
[RFC5566] Berger, L., White, R., and E. Rosen, "BGP IPsec Tunnel Encapsulation Attribute", RFC 5566, June 2009.
[RFC5566]バーガー、L.、ホワイト、R.、およびE.ローゼン、 "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.、ドス・サントス、M.、Stevant、B.、Toutain、L.、及びJ.トレンブレイ、「Softwireハブおよびレイヤ2トンネリングプロトコルバージョン2で展開フレームワークのスポーク（L2TPv2 ）」、RFC 5571、2009年6月。
Appendix A. Examples
付録A.例
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です。
A.1. IPv6-over-IPv4 Softwire with L2TPv2 Example for IKE
A.1。 IKEのためのL2TPv2例でのIPv6オーバーIPv4のSoftwire
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開始剤およびコンセントレータのIPv4アドレスは、それぞれのIPv4-SIとIPv4-SCによって示されています。 NATトラバーサルは、IKEで使用される場合、UDP送信元および宛先ポートは、このSPDエントリに4500であり、IKEは、500 *はワイルドカードを表し、任意のポートまたはアドレスを示しているUDPポートを指します。
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イニシエータ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コンセントレータSPD
A.2. IPv4-over-IPv6 Softwire with Example for IKE
A.2。 IKEのための例でのIPv4-IPv6のオーバーSoftwire
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開始剤およびコンセントレータのIPv6アドレスは、それぞれのIPv6-SIおよびIPv6-SCによって示されています。 NATトラバーサルは、IKEで使用される場合、UDP送信元および宛先ポートは、このSPDエントリに4500であり、IKEは、500 *はワイルドカードを表し、任意のポートまたはアドレスを示しているUDPポートを指します。
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イニシエータ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コンセントレータSPD
Authors' Addresses
著者のアドレス
Shu Yamamoto NICT/KDDI R&D Labs 1-13-16 Hakusan, Bunkyo-ku Tokyo 113-0001 Japan
しゅ やまもと にＣＴ／Ｋっぢ Ｒ＆Ｄ ぁｂｓ １ー１３ー１６ はくさん、 ぶんきょーく ときょ １１３ー０００１ じゃぱん
Phone: +81-3-3868-6913 EMail: shu@nict.go.jp
電話：+ 81-3-3868-6913 Eメール：shu@nict.go.jp
Carl Williams KDDI R&D Labs Palo Alto, CA 94301 USA
パロアルト、CA 94301 USAでのカール・ウィリアムズKDDI R＆D研究所
Phone: +1-650-279-5903 EMail: carlw@mcsr-labs.org
電話：+ 1-650-279-5903 Eメール：carlw@mcsr-labs.org
Hidetoshi Yokota KDDI R&D Labs 2-1-15 Ohara Fujimino, Saitama 356-8502 Japan
ひでとし よこた Ｋっぢ Ｒ＆Ｄ ぁｂｓ ２ー１ー１５ おはら ふじみの、 さいたま ３５６ー８５０２ じゃぱん
Phone: +81-49-278-7894 EMail: yokota@kddilabs.jp
電話：+ 81-49-278-7894 Eメール：yokota@kddilabs.jp
Florent Parent Beon Solutions Quebec, QC Canada
フロラン親BEONソリューションケベック、QCカナダ
EMail: Florent.Parent@beon.ca
メールアドレス：Florent.Parent@beon.ca