[要約] RFC 5920は、MPLSおよびGMPLSネットワークのセキュリティフレームワークに関する規格です。このRFCの目的は、これらのネットワークのセキュリティを向上させるためのガイドラインと手法を提供することです。
Internet Engineering Task Force (IETF) L. Fang, Ed.
Request for Comments: 5920 Cisco Systems, Inc.
Category: Informational July 2010
ISSN: 2070-1721
Security Framework for MPLS and GMPLS Networks
MPLSおよびGMPLSネットワークのセキュリティフレームワーク
Abstract
概要
This document provides a security framework for Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) Networks. This document addresses the security aspects that are relevant in the context of MPLS and GMPLS. It describes the security threats, the related defensive techniques, and the mechanisms for detection and reporting. This document emphasizes RSVP-TE and LDP security considerations, as well as inter-AS and inter-provider security considerations for building and maintaining MPLS and GMPLS networks across different domains or different Service Providers.
このドキュメントは、マルチプロトコルラベルスイッチング（MPLS）および一般化されたマルチプロトコルラベルスイッチング（GMPLS）ネットワークのセキュリティフレームワークを提供します。このドキュメントでは、MPLSおよびGMPLSのコンテキストで関連するセキュリティの側面に対応しています。セキュリティの脅威、関連する防御技術、および検出と報告のメカニズムについて説明します。このドキュメントでは、RSVP-TEおよびLDPのセキュリティに関する考慮事項、およびさまざまなドメインまたは異なるサービスプロバイダーにわたってMPLSおよびGMPLSネットワークを構築および維持するためのAS間およびプロバイダー間のセキュリティに関する考慮事項を強調しています。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5920.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5920で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................4
2. Terminology .....................................................5
2.1. Acronyms and Abbreviations .................................5
2.2. MPLS and GMPLS Terminology .................................6
3. Security Reference Models .......................................8
4. Security Threats ...............................................10
4.1. Attacks on the Control Plane ..............................12
4.2. Attacks on the Data Plane .................................15
4.3. Attacks on Operation and Management Plane .................17
4.4. Insider Attacks Considerations ............................19
5. Defensive Techniques for MPLS/GMPLS Networks ...................19
5.1. Authentication ............................................20
5.2. Cryptographic Techniques ..................................22
5.3. Access Control Techniques .................................33
5.4. Use of Isolated Infrastructure ............................38
5.5. Use of Aggregated Infrastructure ..........................38
5.6. Service Provider Quality Control Processes ................39
5.7. Deployment of Testable MPLS/GMPLS Service .................39
5.8. Verification of Connectivity ..............................40
6. Monitoring, Detection, and Reporting of Security Attacks .......40
7. Service Provider General Security Requirements .................42
7.1. Protection within the Core Network ........................42
7.2. Protection on the User Access Link ........................46
7.3. General User Requirements for MPLS/GMPLS Providers ........48
8. Inter-Provider Security Requirements ...........................48
8.1. Control-Plane Protection ..................................49
8.2. Data-Plane Protection .....................................53
9. Summary of MPLS and GMPLS Security .............................54
9.1. MPLS and GMPLS Specific Security Threats ..................55
9.2. Defense Techniques ........................................56
9.3. Service Provider MPLS and GMPLS Best-Practice Outlines ....57
10. Security Considerations .......................................59
11. References ....................................................59
11.1. Normative References .....................................59
11.2. Informative References ...................................62
12. Acknowledgements ..............................................64
13. Contributors' Contact Information .............................65
Security is an important aspect of all networks, MPLS and GMPLS networks being no exception.
セキュリティは、すべてのネットワークの重要な側面であり、MPLSおよびGMPLSネットワークも例外ではありません。
MPLS and GMPLS are described in [RFC3031] and [RFC3945]. Various security considerations have been addressed in each of the many RFCs on MPLS and GMPLS technologies, but no single document covers general security considerations. The motivation for creating this document is to provide a comprehensive and consistent security framework for MPLS and GMPLS networks. Each individual document may point to this document for general security considerations in addition to providing security considerations specific to the particular technologies the document is describing.
MPLSおよびGMPLは[RFC3031]および[RFC3945]で説明されています。MPLSおよびGMPLSテクノロジーに関する多くのRFCのそれぞれでさまざまなセキュリティ上の考慮事項が対処されていますが、一般的なセキュリティに関する考慮事項をカバーする文書はありません。このドキュメントを作成する動機は、MPLSおよびGMPLSネットワークに包括的で一貫したセキュリティフレームワークを提供することです。各ドキュメントは、文書が説明している特定のテクノロジーに固有のセキュリティに関する考慮事項を提供することに加えて、一般的なセキュリティに関する考慮事項について、このドキュメントを指している場合があります。
In this document, we first describe the security threats relevant in the context of MPLS and GMPLS and the defensive techniques to combat those threats. We consider security issues resulting both from malicious or incorrect behavior of users and other parties and from negligent or incorrect behavior of providers. An important part of security defense is the detection and reporting of a security attack, which is also addressed in this document.
このドキュメントでは、まず、MPLSとGMPLSのコンテキストに関連するセキュリティの脅威と、それらの脅威と戦うための防御技術について説明します。ユーザーや他の関係者の悪意のあるまたは誤った行動の両方から、プロバイダーの過失または誤った行動の両方から生じるセキュリティの問題を考慮します。セキュリティ防衛の重要な部分は、セキュリティ攻撃の検出と報告です。これは、このドキュメントでも対処されています。
We then discuss possible service provider security requirements in an MPLS or GMPLS environment. Users have expectations for the security characteristics of MPLS or GMPLS networks. These include security requirements for equipment supporting MPLS and GMPLS and operational security requirements for providers. Service providers must protect their network infrastructure and make it secure to the level required to provide services over their MPLS or GMPLS networks.
次に、MPLSまたはGMPLS環境で可能なサービスプロバイダーのセキュリティ要件について説明します。ユーザーは、MPLSまたはGMPLSネットワークのセキュリティ特性に期待されています。これらには、MPLとGMPLSをサポートする機器のセキュリティ要件、およびプロバイダーの運用セキュリティ要件が含まれます。サービスプロバイダーは、ネットワークインフラストラクチャを保護し、MPLSまたはGMPLSネットワークを介してサービスを提供するために必要なレベルまで安全にする必要があります。
Inter-AS and inter-provider security are discussed with special emphasis, because the security risk factors are higher with inter-provider connections. Note that inter-carrier MPLS security is also considered in [MFA-MPLS-ICI].
セキュリティリスク要因がプロバイダー間接続により高いため、AS間およびプロバイダー間のセキュリティについては、特に重点を置いて議論されています。キャリア間MPLSセキュリティは[MFA-MPLS-ICI]でも考慮されていることに注意してください。
Depending on different MPLS or GMPLS techniques used, the degree of risk and the mitigation methodologies vary. This document discusses the security aspects and requirements for certain basic MPLS and GMPLS techniques and interconnection models. This document does not attempt to cover all current and future MPLS and GMPLS technologies, as it is not within the scope of this document to analyze the security properties of specific technologies.
使用されるさまざまなMPLSまたはGMPLS手法に応じて、リスクの程度と緩和方法はさまざまです。このドキュメントでは、特定の基本的なMPLSおよびGMPLS技術と相互接続モデルのセキュリティの側面と要件について説明します。このドキュメントは、特定のテクノロジーのセキュリティプロパティを分析するためにこのドキュメントの範囲内ではないため、現在および将来のすべてのMPLSおよびGMPLSテクノロジーをカバーしようとはしません。
It is important to clarify that, in this document, we limit ourselves to describing the providers' security requirements that pertain to MPLS and GMPLS networks, not including the connected user sites. Readers may refer to the "Security Best Practices Efforts and Documents" [OPSEC-EFFORTS] and "Security Mechanisms for the Internet" [RFC3631] for general network operation security considerations. It is not our intention, however, to formulate precise "requirements" for each specific technology in terms of defining the mechanisms and techniques that must be implemented to satisfy such security requirements.
このドキュメントでは、接続されたユーザーサイトを含まないMPLSおよびGMPLSネットワークに関連するプロバイダーのセキュリティ要件を説明することに制限することを明確にすることが重要です。読者は、一般的なネットワーク運用セキュリティに関する考慮事項について、「セキュリティベストプラクティスの取り組みと文書」[OPSEC-Efforts]および「インターネットのセキュリティメカニズム」[RFC3631]を指す場合があります。ただし、そのようなセキュリティ要件を満たすために実装する必要があるメカニズムと技術を定義するという観点から、特定のテクノロジーごとに正確な「要件」を策定することは、私たちの意図ではありません。
AS Autonomous System ASBR Autonomous System Border Router ATM Asynchronous Transfer Mode BGP Border Gateway Protocol BFD Bidirectional Forwarding Detection CE Customer-Edge device CoS Class of Service CPU Central Processing Unit DNS Domain Name System DoS Denial of Service ESP Encapsulating Security Payload FEC Forwarding Equivalence Class GMPLS Generalized Multi-Protocol Label Switching GCM Galois Counter Mode GRE Generic Routing Encapsulation ICI InterCarrier Interconnect ICMP Internet Control Message Protocol ICMPv6 ICMP in IP Version 6 IGP Interior Gateway Protocol IKE Internet Key Exchange IP Internet Protocol IPsec IP Security IPVPN IP-based VPN LDP Label Distribution Protocol L2TP Layer 2 Tunneling Protocol LMP Link Management Protocol LSP Label Switched Path LSR Label Switching Router MD5 Message Digest Algorithm MPLS Multiprotocol Label Switching MP-BGP Multiprotocol BGP NTP Network Time Protocol OAM Operations, Administration, and Maintenance PCE Path Computation Element PE Provider-Edge device PPVPN Provider-Provisioned Virtual Private Network PSN Packet-Switched Network PW Pseudowire QoS Quality of Service RR Route Reflector RSVP Resource Reservation Protocol RSVP-TE Resource Reservation Protocol with Traffic Engineering Extensions SLA Service Level Agreement SNMP Simple Network Management Protocol SP Service Provider SSH Secure Shell SSL Secure Sockets Layer SYN Synchronize packet in TCP TCP Transmission Control Protocol TDM Time Division Multiplexing TE Traffic Engineering TLS Transport Layer Security ToS Type of Service TTL Time-To-Live UDP User Datagram Protocol VC Virtual Circuit VPN Virtual Private Network WG Working Group of IETF WSS Web Services Security
自律システムとしてASBR自律システムボーダールーターATM非同期転送モードBGPボーダーゲートウェイプロトコルBFD双方向転送検出CEカスタマーエッジデバイスCOS CPU中央処理ユニットDNSドメイン名DNSドメイン名システムDOS拒否セキュリティペイロードFEC FEC FEC FEC FEC FEC FEC FEC FEC FEC FEC FEC FEC転送クラス一般化されたマルチプロトコルラベルスイッチングGCMガロアカウンターモードGREジェネリックルーティングカプセル化ICIインターキャリアインターネットインターネットコントロールメッセージプロトコルICMP ICMP INIPバージョン6 IGPインテリアゲートウェイプロトコルIKEインターネットキーエクスチェンジIPインターネットプロトコルIPSEC IPセキュリティIPVPN LDPラベル配信プロトコルL2TPレイヤー2トンネリングプロトコルLMPリンク管理プロトコルLSPラベルスイッチングパスLSRラベルスイッチングルーターMD5メッセージダイジェストアルゴリズムMPLSマルチプロトコルラベルスイッチングMP-BGPマルチプロトコルBGP NTPネットワーク時間OAM操作、および維持PCE PATH計算要素PE P P P P PE P PE PE PERovider-EdgeデバイスPPVPNプロバイダープロビジョン仮想プライベートネットワークPSNパケットスイッチネットワークPW PSEUDOWIRE QOS QOS QOS QUALTY of SERVICE RR REATE REFRECTOR RSVPリソースリソースリソースリソースリソース予約プロトコルプロバイダーSSHセキュアシェルSSLセキュアソケットレイヤーシンシンシンクロニオンパケットパケットをTCP TCP TCPトランスミッションコントロールプロトコルTDMタイムディビジョンマルチプレックスTLSトランスポートレイヤーセキュリティTOSタイプTTLタイムツーライブUDPユーザーデータグラムプロトコルVC仮想回路VPN仮想ネットワークWGGIETF WSS Webサービスセキュリティのワーキンググループ
This document uses MPLS- and GMPLS-specific terminology. Definitions and details about MPLS and GMPLS terminology can be found in [RFC3031] and [RFC3945]. The most important definitions are repeated in this section; for other definitions, the reader is referred to [RFC3031] and [RFC3945].
このドキュメントでは、MPLSおよびGMPLS固有の用語を使用しています。MPLSおよびGMPLS用語の定義と詳細は、[RFC3031]および[RFC3945]に記載されています。このセクションでは、最も重要な定義が繰り返されます。他の定義については、読者は[RFC3031]および[RFC3945]と呼ばれます。
Core network: An MPLS/GMPLS core network is defined as the central network infrastructure that consists of P and PE routers. An MPLS/GMPLS core network may consist of one or more networks belonging to a single SP.
コアネットワーク：MPLS/GMPLSコアネットワークは、PおよびPEルーターで構成される中央ネットワークインフラストラクチャとして定義されます。MPLS/GMPLSコアネットワークは、単一のspに属する1つ以上のネットワークで構成されている場合があります。
Customer Edge (CE) device: A Customer Edge device is a router or a switch in the customer's network interfacing with the Service Provider's network.
顧客エッジ（CE）デバイス：顧客エッジデバイスは、サービスプロバイダーのネットワークとインターフェースする顧客のネットワークのルーターまたはスイッチです。
Forwarding Equivalence Class (FEC): A group of IP packets that are forwarded in the same manner (e.g., over the same path, with the same forwarding treatment).
転送等価クラス（FEC）：同じ方法で転送されるIPパケットのグループ（たとえば、同じパスで、同じ転送処理を伴う）。
Label: A short, fixed length, physically contiguous identifier, usually of local significance.
ラベル：通常、局所的な重要性の短い固定長、物理的に隣接する識別子。
Label merging: the replacement of multiple incoming labels for a particular FEC with a single outgoing label.
ラベルマージ：特定のFECの複数の着信ラベルを単一の発信ラベルに置き換えること。
Label Switched Hop: A hop between two MPLS nodes, on which forwarding is done using labels.
ラベルスイッチホップ：2つのMPLSノード間のホップで、ラベルを使用して転送が行われます。
Label Switched Path (LSP): The path through one or more LSRs at one level of the hierarchy followed by packets in a particular FEC.
ラベルスイッチ付きパス（LSP）：階層の1つのレベルで1つ以上のLSRを通るパスに続いて、特定のFECにパケットが続きます。
Label Switching Routers (LSRs): An MPLS/GMPLS node assumed to have a forwarding plane that is capable of (a) recognizing either packet or cell boundaries, and (b) being able to process either packet headers or cell headers.
ラベルスイッチングルーター（LSRS）：（a）パケットまたはセルの境界を認識し、（b）パケットヘッダーまたはセルヘッダーのいずれかを処理できると想定されるMPLS/GMPLSノード。
Loop Detection: A method of dealing with loops in which loops are allowed to be set up, and data may be transmitted over the loop, but the loop is later detected.
ループ検出：ループをセットアップし、データをループ上に送信できるループを扱う方法ですが、ループは後で検出されます。
Loop Prevention: A method of dealing with loops in which data is never transmitted over a loop.
ループ予防：データがループ上に送信されないループを扱う方法。
Label Stack: An ordered set of labels.
ラベルスタック：注文されたラベルセット。
Merge Point: A node at which label merging is done.
マージポイント：ラベルマージが完了するノード。
MPLS Domain: A contiguous set of nodes that perform MPLS routing and forwarding and are also in one Routing or Administrative Domain.
MPLSドメイン：MPLSルーティングと転送を実行し、1つのルーティングドメインまたは管理ドメインにもある隣接するノードのセット。
MPLS Edge Node: An MPLS node that connects an MPLS domain with a node outside of the domain, either because it does not run MPLS, or because it is in a different domain. Note that if an LSR has a neighboring host not running MPLS, then that LSR is an MPLS edge node.
MPLS EDGEノード：MPLSを実行しないか、別のドメインにあるため、MPLSドメインをドメインの外側のノードに接続するMPLSノード。LSRにMPLSを実行していない隣接ホストがある場合、そのLSRはMPLSエッジノードであることに注意してください。
MPLS Egress Node: An MPLS edge node in its role in handling traffic as it leaves an MPLS domain.
MPLS出力ノード：MPLSドメインを離れるときにトラフィックを処理する際の役割におけるMPLSエッジノード。
MPLS Ingress Node: A MPLS edge node in its role in handling traffic as it enters a MPLS domain.
MPLS Ingressノード：MPLSドメインに入るときにトラフィックを処理する際の役割におけるMPLSエッジノード。
MPLS Label: A label carried in a packet header, which represents the packet's FEC.
MPLSラベル：パケットのFECを表すパケットヘッダーで運ばれたラベル。
MPLS Node: A node running MPLS. An MPLS node is aware of MPLS control protocols, runs one or more routing protocols, and is capable of forwarding packets based on labels. An MPLS node may optionally be also capable of forwarding native IP packets.
MPLSノード：MPLSを実行しているノード。MPLSノードは、MPLS制御プロトコルを認識し、1つ以上のルーティングプロトコルを実行し、ラベルに基づいてパケットを転送できます。MPLSノードは、オプションでネイティブIPパケットを転送することもできます。
Multiprotocol Label Switching (MPLS): MPLS is an architecture for efficient data packet switching and routing. MPLS assigns data packets with labels. Instead of performing the longest match for each packet's destination as in conventional IP forwarding, MPLS makes the packet-forwarding decisions solely on the contents of the label without examining the packet itself. This allows the creation of end-to-end circuits across any type of transport medium, using any protocols.
マルチプロトコルラベルスイッチング（MPLS）：MPLSは、効率的なデータパケットの切り替えとルーティングのためのアーキテクチャです。MPLSは、データパケットをラベルで割り当てます。MPLSは、従来のIP転送のように各パケットの宛先で最も長い一致を実行する代わりに、パケット自体を調べずにラベルの内容のみでパケットに向かって決定する決定を行います。これにより、あらゆるプロトコルを使用して、あらゆる種類の輸送媒体全体にエンドツーエンド回路を作成できます。
P: Provider Router. A Provider Router is a router in the Service Provider's core network that does not have interfaces directly towards the customer. A P router is used to interconnect the PE routers and/or other P routers within the core network.
P：プロバイダールーター。プロバイダールーターは、サービスプロバイダーのコアネットワークのルーターであり、顧客に直接インターフェイスを持たない。Pルーターは、コアネットワーク内のPEルーターおよび/または他のPルーターを相互接続するために使用されます。
PE: Provider Edge device. A Provider Edge device is the equipment in the Service Provider's network that interfaces with the equipment in the customer's network.
PE：プロバイダーエッジデバイス。プロバイダーエッジデバイスは、顧客のネットワーク内の機器とインターフェイスするサービスプロバイダーのネットワーク内の機器です。
PPVPN: Provider-Provisioned Virtual Private Network, including Layer 2 VPNs and Layer 3 VPNs.
PPVPN：レイヤー2 VPNとレイヤー3 VPNを含むプロバイダーがプロビジョニングした仮想プライベートネットワーク。
VPN: Virtual Private Network, which restricts communication between a set of sites, making use of an IP backbone shared by traffic not going to or not coming from those sites [RFC4110].
VPN：サイトのセット間の通信を制限する仮想プライベートネットワークは、それらのサイト[RFC4110]から来ないか、そうでないトラフィックが共有するIPバックボーンを使用します[RFC4110]。
This section defines a reference model for security in MPLS/GMPLS networks.
このセクションでは、MPLS/GMPLSネットワークのセキュリティの参照モデルを定義します。
This document defines each MPLS/GMPLS core in a single domain to be a trusted zone. A primary concern is about security aspects that relate to breaches of security from the "outside" of a trusted zone to the "inside" of this zone. Figure 1 depicts the concept of trusted zones within the MPLS/GMPLS framework.
このドキュメントは、単一のドメイン内の各MPLS/GMPLSコアを信頼できるゾーンに定義します。主な関心事は、信頼できるゾーンの「外部」からこのゾーンの「内部」へのセキュリティの侵害に関連するセキュリティの側面についてです。図1は、MPLS/GMPLSフレームワーク内の信頼できるゾーンの概念を示しています。
/-------------\
+------------+ / \ +------------+
| MPLS/GMPLS +---/ \--------+ MPLS/GMPLS |
| user | MPLS/GMPLS Core | user |
| site +---\ /XXX-----+ site |
+------------+ \ / XXX +------------+
\-------------/ | |
| |
| +------\
+--------/ "Internet"
|<- Trusted zone ->|
MPLS/GMPLS Core with user connections and Internet connection
ユーザー接続とインターネット接続を備えたMPLS/GMPLSコア
Figure 1: The MPLS/GMPLS Trusted Zone Model
図1：MPLS/GMPLS信頼できるゾーンモデル
The trusted zone is the MPLS/GMPLS core in a single AS within a single Service Provider.
信頼できるゾーンは、単一のサービスプロバイダー内で1つのMPLS/GMPLSコアです。
A trusted zone contains elements and users with similar security properties, such as exposure and risk level. In the MPLS context, an organization is typically considered as one trusted zone.
信頼できるゾーンには、エクスポージャーやリスクレベルなど、同様のセキュリティプロパティを持つ要素とユーザーが含まれています。MPLSコンテキストでは、組織は通常、1つの信頼できるゾーンと見なされます。
The boundaries of a trust domain should be carefully defined when analyzing the security properties of each individual network, e.g., the boundaries can be at the link termination, remote peers, areas, or quite commonly, ASes.
各個々のネットワークのセキュリティプロパティを分析する場合、信頼ドメインの境界を慎重に定義する必要があります。
In principle, the trusted zones should be separate; however, typically MPLS core networks also offer Internet access, in which case a transit point (marked with "XXX" in Figure 1) is defined. In the case of MPLS/GMPLS inter-provider connections or InterCarrier Interconnect (ICI), the trusted zone of each provider ends at the respective ASBRs (ASBR1 and ASBR2 for Provider A and ASBR3 and ASBR4 for Provider B in Figure 2).
原則として、信頼できるゾーンは分離する必要があります。ただし、通常、MPLSコアネットワークもインターネットアクセスを提供します。この場合、トランジットポイント（図1の「xxx」がマークされている）が定義されています。MPLS/GMPLSインタープロバイダー接続またはInterCarrier Interconnect（ICI）の場合、各プロバイダーの信頼できるゾーンはそれぞれのASBRSで終了します（図2のプロバイダーAおよびASBR3およびASBR3およびASBR4のASBR1およびASBR4）。
A key requirement of MPLS and GMPLS networks is that the security of the trusted zone not be compromised by interconnecting the MPLS/GMPLS core infrastructure with another provider's core (MPLS/GMPLS or non-MPLS/GMPLS), the Internet, or end users.
MPLSおよびGMPLSネットワークの重要な要件は、MPLS/GMPLSコアインフラストラクチャを別のプロバイダーのコア（MPLS/GMPLSまたは非MPLS/GMPLS）、インターネット、またはエンドユーザーと相互接続することにより、信頼できるゾーンのセキュリティが損なわれないことです。
In addition, neighbors may be trusted or untrusted. Neighbors may be authorized or unauthorized. An authorized neighbor is the neighbor one establishes a peering relationship with. Even though a neighbor may be authorized for communication, it may not be trusted. For example, when connecting with another provider's ASBRs to set up inter-AS LSPs, the other provider is considered an untrusted but authorized neighbor.
さらに、隣人は信頼されていないか、信頼されていない場合があります。隣人は許可されているか、許可されていない場合があります。承認された隣人は、覗き見を確立する隣人です。隣人がコミュニケーションを許可されている場合でも、信頼されない可能性があります。たとえば、別のプロバイダーのASBRと接続してLSP間をASを設定する場合、他のプロバイダーは信頼されていないが認定された隣人と見なされます。
+---------------+ +----------------+
| | | |
| MPLS/GMPLS ASBR1----ASBR3 MPLS/GMPLS |
CE1--PE1 Network | | Network PE2--CE2
| Provider A ASBR2----ASBR4 Provider B |
| | | |
+---------------+ +----------------+
InterCarrier
Interconnect (ICI)
For Provider A:
Trusted Zone: Provider A MPLS/GMPLS network
Authorized but untrusted neighbor: provider B
Unauthorized neighbors: CE1, CE2
Figure 2: MPLS/GMPLS Trusted Zone and Authorized Neighbor
図2：MPLS/GMPLS信頼できるゾーンと認可された隣人
All aspects of network security independent of whether a network is an MPLS/GMPLS network, are out of scope. For example, attacks from the Internet to a user's web-server connected through the MPLS/GMPLS network are not considered here, unless the way the MPLS/GMPLS network is provisioned could make a difference to the security of this user's server.
ネットワークセキュリティのすべての側面は、ネットワークがMPLS/GMPLSネットワークであるかどうかとは無関係に、範囲外です。たとえば、MPLS/GMPLSネットワークがプロビジョニングされている方法がこのユーザーのサーバーのセキュリティに違いをもたらす可能性がない限り、MPLS/GMPLSネットワークを介して接続されたユーザーのWebサーバーへの攻撃は、ここでは考慮されません。
This section discusses the various network security threats that may endanger MPLS/GMPLS networks. RFC 4778 [RFC4778] provided the best current operational security practices in Internet Service Provider environments.
このセクションでは、MPLS/GMPLSネットワークを危険にさらす可能性のあるさまざまなネットワークセキュリティの脅威について説明します。RFC 4778 [RFC4778]は、インターネットサービスプロバイダー環境で現在の最良の運用セキュリティプラクティスを提供しました。
A successful attack on a particular MPLS/GMPLS network or on an SP's MPLS/GMPLS infrastructure may cause one or more of the following ill effects:
特定のMPLS/GMPLSネットワークまたはSPのMPLS/GMPLSインフラストラクチャに対する攻撃が成功すると、次の1つ以上の悪影響が生じる可能性があります。
- Observation, modification, or deletion of a provider's or user's data.
- プロバイダーまたはユーザーのデータの観察、変更、または削除。
- Replay of a provider's or user's data.
- プロバイダーまたはユーザーのデータのリプレイ。
- Injection of inauthentic data into a provider's or user's traffic stream.
- プロバイダーまたはユーザーのトラフィックストリームへの不正データの注入。
- Traffic pattern analysis on a provider's or user's traffic.
- プロバイダーまたはユーザーのトラフィックに関するトラフィックパターン分析。
- Disruption of a provider's or user's connectivity.
- プロバイダーまたはユーザーの接続の混乱。
- Degradation of a provider's service quality.
- プロバイダーのサービス品質の劣化。
- Probing a provider's network to determine its configuration, capacity, or usage.
- プロバイダーのネットワークを調査して、構成、容量、または使用法を決定します。
It is useful to consider that threats, whether malicious or accidental, may come from different categories of sources. For example, they may come from:
脅威は、悪意のあるものであろうと偶発的であろうと、さまざまなカテゴリのソースから来ている可能性があると考えると便利です。たとえば、それらは次のようになります。
- Other users whose services are provided by the same MPLS/GMPLS core.
- 同じMPLS/GMPLSコアによってサービスが提供される他のユーザー。
- The MPLS/GMPLS SP or persons working for it.
- MPLS/GMPLS SPまたはそれのために働いている人。
- Other persons who obtain physical access to an MPLS/GMPLS SP's site.
- MPLS/GMPLS SPのサイトへの物理的アクセスを取得する他の人。
- Other persons who use social engineering methods to influence the behavior of an SP's personnel.
- SPの人員の行動に影響を与えるためにソーシャルエンジニアリング方法を使用する他の人。
- Users of the MPLS/GMPLS network itself, e.g., intra-VPN threats. (Such threats are beyond the scope of this document.)
- MPLS/GMPLSネットワーク自体のユーザー、たとえば、VPN内の脅威。（そのような脅威は、この文書の範囲を超えています。）
- Others, e.g., attackers from the Internet at large.
- その他、たとえば、インターネット全体からの攻撃者。
- Other SPs in the case of MPLS/GMPLS inter-provider connection. The core of the other provider may or may not be using MPLS/GMPLS.
- MPLS/GMPLS間接続の場合の他のSPS。他のプロバイダーのコアは、MPLS/GMPLSを使用している場合と使用していない場合があります。
- Those who create, deliver, install, and maintain software for network equipment.
- ネットワーク機器のソフトウェアを作成、配信、インストール、保守する人。
Given that security is generally a tradeoff between expense and risk, it is also useful to consider the likelihood of different attacks occurring. There is at least a perceived difference in the likelihood of most types of attacks being successfully mounted in different environments, such as:
セキュリティは一般に費用とリスクのトレードオフであることを考えると、異なる攻撃が発生する可能性を考慮することも有用です。次のような、ほとんどのタイプの攻撃がさまざまな環境に正常にマウントされる可能性には、少なくとも知覚された違いがあります。
- An MPLS/GMPLS core interconnecting with another provider's core.
- MPLS/GMPLSコアは、別のプロバイダーのコアと相互接続します。
- An MPLS/GMPLS configuration transiting the public Internet.
- パブリックインターネットを通過するMPLS/GMPLS構成。
Most types of attacks become easier to mount and hence more likely as the shared infrastructure via which service is provided expands from a single SP to multiple cooperating SPs to the global Internet. Attacks that may not be of sufficient likeliness to warrant concern in a closely controlled environment often merit defensive measures in broader, more open environments. In closed communities, it is often practical to deal with misbehavior after the fact: an employee can be disciplined, for example.
ほとんどの種類の攻撃は、取り付けが容易になるため、サービスが提供される共有インフラストラクチャが単一のSPから複数の協力SPSにグローバルインターネットに拡大するため、より可能性が高くなります。密接に制御された環境で懸念を保証するのに十分な潜在性がないかもしれない攻撃は、しばしばより広範でオープンな環境で防御的な措置に値します。閉鎖されたコミュニティでは、事実の後に不正行為に対処することがしばしば実用的です。たとえば、従業員を規律することができます。
The following sections discuss specific types of exploits that threaten MPLS/GMPLS networks.
次のセクションでは、MPLS/GMPLSネットワークを脅かす特定のタイプのエクスプロイトについて説明します。
This category encompasses attacks on the control structures operated by the SP with MPLS/GMPLS cores.
このカテゴリには、MPLS/GMPLSコアを使用してSPによって動作する制御構造に対する攻撃が含まれます。
It should be noted that while connectivity in the MPLS control plane uses the same links and network resources as are used by the data plane, the GMPLS control plane may be provided by separate resources from those used in the data plane. That is, the GMPLS control plane may be physically separate from the data plane.
MPLSコントロールプレーンの接続性は、データプレーンで使用されるのと同じリンクとネットワークリソースを使用しますが、GMPLS制御プレーンは、データプレーンで使用されているリソースとは別のリソースによって提供される場合があります。つまり、GMPLSコントロールプレーンは、データプレーンから物理的に分離されている場合があります。
The different cases of physically congruent and physically separate control/data planes lead to slightly different possibilities of attack, although most of the cases are the same. Note that, for example, the data plane cannot be directly congested by an attack on a physically separate control plane as it could be if the control and data planes shared network resources. Note also that if the control plane uses diverse resources from the data plane, no assumptions should be made about the security of the control plane based on the security of the data plane resources.
物理的に一致し、物理的に分離された制御/データ面の異なるケースは、ほとんどの場合が同じですが、攻撃のわずかに異なる可能性につながります。たとえば、データプレーンは、コントロールプレーンとデータプレーンがネットワークリソースを共有している場合のように、物理的に個別の制御プレーンへの攻撃によって直接混雑することはできないことに注意してください。また、制御プレーンがデータプレーンから多様なリソースを使用している場合、データプレーンリソースのセキュリティに基づいて、制御プレーンのセキュリティについて仮定を立てるべきではないことに注意してください。
This section is focused the outsider attack. The insider attack is discussed in Section 4.4.
このセクションには、部外者攻撃に焦点を当てています。インサイダー攻撃については、セクション4.4で説明します。
The unauthorized element can be a local CE or a router in another domain. An unauthorized element can generate MPLS signaling messages. At the least, this can result in extra control plane and forwarding state, and if successful, network bandwidth could be reserved unnecessarily. This may also result in theft of service or even compromise the entire network.
不正な要素は、ローカルCEまたは別のドメインのルーターにすることができます。不正な要素は、MPLSシグナリングメッセージを生成できます。少なくとも、これにより、追加の制御プレーンと転送状態が発生する可能性があり、成功すれば、ネットワーク帯域幅は不必要に予約される可能性があります。また、これにより、サービスの盗難やネットワーク全体を侵害することさえあります。
This threat might be accomplished by monitoring network traffic, for example, after a physical intrusion. Without physical intrusion, it could be accomplished with an unauthorized software modification. Also, many technologies such as terrestrial microwave, satellite, or free-space optical could be intercepted without physical intrusion. If successful, it could provide information leading to label spoofing attacks. It also raises confidentiality issues.
この脅威は、たとえば物理的な侵入後、ネットワークトラフィックを監視することによって達成される可能性があります。物理的な侵入がなければ、許可されていないソフトウェアの変更で達成できます。また、陸生電子レンジ、衛星、自由空間光学などの多くの技術は、物理的な侵入なしに傍受することができます。成功した場合、スプーフィング攻撃のラベルにつながる情報を提供できます。また、機密性の問題を提起します。
RSVP-TE, described in [RFC3209], is the control protocol used to set up GMPLS and traffic engineered MPLS tunnels.
[RFC3209]に記載されているRSVP-TEは、GMPLSとトラフィックエンジニアリングMPLSトンネルのセットアップに使用される制御プロトコルです。
There are two major types of denial-of-service (DoS) attacks against an MPLS domain based on RSVP-TE. The attacker may set up numerous unauthorized LSPs or may send a storm of RSVP messages. It has been demonstrated that unprotected routers running RSVP can be effectively disabled by both types of DoS attacks.
RSVP-TEに基づいたMPLSドメインに対するサービス拒否（DOS）攻撃には、2つの主要なタイプのタイプがあります。攻撃者は、多数の不正なLSPを設定するか、RSVPメッセージの嵐を送信する場合があります。RSVPを実行する保護されていないルーターは、両方のタイプのDOS攻撃によって効果的に無効にできることが実証されています。
These attacks may even be combined, by using the unauthorized LSPs to transport additional RSVP (or other) messages across routers where they might otherwise be filtered out. RSVP attacks can be launched against adjacent routers at the border with the attacker, or against non-adjacent routers within the MPLS domain, if there is no effective mechanism to filter them out.
これらの攻撃は、許可されていないLSPを使用して、他の方法で除外される可能性のあるルーター全体に追加のRSVP（または他の）メッセージを輸送することにより、組み合わせることさえできます。RSVP攻撃は、攻撃者との境界の隣接するルーター、またはそれらをフィルタリングする効果的なメカニズムがない場合、MPLSドメイン内の非隣接ルーターに対して発射できます。
LDP, described in [RFC5036], is the control protocol used to set up MPLS tunnels without TE.
[RFC5036]に記載されているLDPは、TEのないMPLSトンネルのセットアップに使用される制御プロトコルです。
There are two significant types of attack against LDP. An unauthorized network element can establish an LDP session by sending LDP Hello and LDP Init messages, leading to the potential setup of an LSP, as well as accompanying LDP state table consumption. Even without successfully establishing LSPs, an attacker can launch a DoS attack in the form of a storm of LDP Hello messages or LDP TCP SYN messages, leading to high CPU utilization or table space exhaustion on the target router.
LDPに対する攻撃には2つの重要なタイプがあります。許可されていないネットワーク要素は、LDP HelloおよびLDP Initメッセージを送信することによりLDPセッションを確立し、LSPの潜在的なセットアップにつながり、LDP州のテーブル消費を伴うことがあります。LSPを正常に確立しなくても、攻撃者はLDP HelloメッセージまたはLDP TCP Synメッセージのストームの形でDOS攻撃を開始し、ターゲットルーターで高いCPU使用またはテーブルスペースの疲労を引き起こします。
DoS attacks could be accomplished through an MPLS signaling storm, resulting in high CPU utilization and possibly leading to control-plane resource starvation.
DOS攻撃は、MPLSシグナリングストームによって達成される可能性があり、その結果、CPUの利用率が高く、おそらくコントロール面のリソースの飢vにつながる可能性があります。
Control-plane DoS attacks can be mounted specifically against the mechanisms the SP uses to provide various services, or against the general infrastructure of the service provider, e.g., P routers or shared aspects of PE routers. (An attack against the general infrastructure is within the scope of this document only if the attack can occur in relation with the MPLS/GMPLS infrastructure; otherwise, it is not an MPLS/GMPLS-specific issue.) The attacks described in the following sections may each have denial of service as one of their effects. Other DoS attacks are also possible.
コントロールプレーンDOS攻撃は、SPがさまざまなサービスを提供するために使用するメカニズム、またはPEルーターのPルーターや共有側面などのサービスプロバイダーの一般的なインフラストラクチャを提供するために使用するメカニズムに対して具体的に取り付けることができます。（一般的なインフラストラクチャに対する攻撃は、MPLS/GMPLSインフラストラクチャに関連して攻撃が発生する可能性がある場合にのみ、このドキュメントの範囲内にあります。そうでなければ、MPLS/GMPLS固有の問題ではありません。）次のセクションで説明されている攻撃はそれぞれが彼らの効果の1つとしてサービスの拒否を持っているように。他のDOS攻撃も可能です。
This includes unauthorized access to an SP's infrastructure equipment, for example, to reconfigure the equipment or to extract information (statistics, topology, etc.) pertaining to the network.
これには、たとえば、機器を再構成したり、ネットワークに関連する情報（統計、トポロジなど）を抽出するためのSPのインフラストラクチャ機器への不正アクセスが含まれます。
This refers to the event in which expected isolation between separate users (who may be VPN users) is breached. This includes cases such as:
これは、別のユーザー（VPNユーザーである可能性がある）間の予想される隔離が違反されているイベントを指します。これには、次のようなケースが含まれます。
- A site being connected into the "wrong" VPN.
- 「間違った」VPNに接続されているサイト。
- Traffic being replicated and sent to an unauthorized user.
- トラフィックが複製され、不正なユーザーに送信されます。
- Two or more VPNs being improperly merged together.
- 2つ以上のVPNが不適切にマージされています。
- A point-to-point VPN connecting the wrong two points.
- 間違った2つのポイントを接続するポイントツーポイントVPN。
- Any packet or frame being improperly delivered outside the VPN to which it belongs
- 属するVPNの外側で不適切に配信されているパケットまたはフレームが属します
Misconnection or cross-connection of VPNs may be caused by service provider or equipment vendor error, or by the malicious action of an attacker. The breach may be physical (e.g., PE-CE links misconnected) or logical (e.g., improper device configuration).
VPNの誤解または相互接続は、サービスプロバイダーまたは機器ベンダーエラー、または攻撃者の悪意のあるアクションによって引き起こされる場合があります。違反は、物理的（例：PE-CEリンクが誤って接続されている）または論理（例：不適切なデバイス構成）である場合があります。
Anecdotal evidence suggests that the cross-connection threat is one of the largest security concerns of users (or would-be users).
逸話的な証拠は、相互接続の脅威がユーザー（またはユーザーになりたい）の最大のセキュリティ上の懸念の1つであることを示唆しています。
This encompasses attacks against underlying routing protocols that are run by the SP and that directly support the MPLS/GMPLS core. (Attacks against the use of routing protocols for the distribution of backbone routes are beyond the scope of this document.) Specific attacks against popular routing protocols have been widely studied and are described in [RFC4593].
これには、SPによって実行され、MPLS/GMPLSコアを直接サポートする基礎となるルーティングプロトコルに対する攻撃が含まれます。（バックボーンルートの分布のためのルーティングプロトコルの使用に対する攻撃は、このドキュメントの範囲を超えています。）一般的なルーティングプロトコルに対する特定の攻撃は広く研究されており、[RFC4593]で説明されています。
Besides routing and management protocols (covered separately in the previous sections), a number of other control protocols may be directly involved in delivering services by the MPLS/GMPLS core. These include but may not be limited to:
ルーティングおよび管理プロトコル（前のセクションで別々にカバー）に加えて、他の多くの制御プロトコルがMPLS/GMPLSコアによるサービスの提供に直接関与する可能性があります。これらには、以下に限定されることはありませんが、
- MPLS signaling (LDP, RSVP-TE) discussed above in subsections 4.1.4 and 4.1.3
- 上記のサブセクション4.1.4および4.1.3で説明したMPLSシグナリング（LDP、RSVP-TE）
- PCE signaling
- PCEシグナル伝達
- IPsec signaling (IKE and IKEv2)
- IPSECシグナル伝達（IKEおよびIKEV2）
- ICMP and ICMPv6
- ICMPおよびICMPV6
- L2TP
- L2TP
- BGP-based membership discovery
- BGPベースのメンバーシップ発見
- Database-based membership discovery (e.g., RADIUS)
- データベースベースのメンバーシップ発見（半径など）
- Other protocols that may be important to the control infrastructure, e.g., DNS, LMP, NTP, SNMP, and GRE.
- コントロールインフラストラクチャにとって重要である可能性のあるその他のプロトコル（DNS、LMP、NTP、SNMP、GREなど）。
Attacks might subvert or disrupt the activities of these protocols, for example via impersonation or DoS.
攻撃は、たとえばなりすましやDOSを介して、これらのプロトコルの活動を破壊または破壊する可能性があります。
Note that all of the data-plane attacks can also be carried out against the packets of the control and management planes: insertion, spoofing, replay, deletion, pattern analysis, and other attacks mentioned above.
すべてのデータプレーン攻撃は、制御および管理プレーンのパケットに対しても実行できることに注意してください：挿入、スプーフィング、リプレイ、削除、パターン分析、および上記のその他の攻撃。
This category encompasses attacks on the provider's or end-user's data. Note that from the MPLS/GMPLS network end user's point of view, some of this might be control-plane traffic, e.g., routing protocols running from user site A to user site B via IP or non-IP connections, which may be some type of VPN.
このカテゴリには、プロバイダーまたはエンドユーザーのデータに対する攻撃が含まれます。MPLS/GMPLSネットワークのエンドユーザーの観点から、これの一部はコントロールプレーントラフィックである可能性があることに注意してください。VPNの。
This refers to "sniffing" provider or end user packets and examining their contents. This can result in exposure of confidential information. It can also be a first step in other attacks (described below) in which the recorded data is modified and re-inserted, or simply replayed later.
これは、プロバイダーまたはエンドユーザーパケットを「スニッフィング」し、その内容を調べることを指します。これにより、機密情報が露出する可能性があります。また、記録されたデータが変更および再挿入されるか、後で再生される他の攻撃（以下で説明）の最初のステップでもあります。
This refers to modifying the contents of packets as they traverse the MPLS/GMPLS core.
これは、MPLS/GMPLSコアを通過するときにパケットの内容を変更することを指します。
Spoofing refers to sending a user packets or inserting packets into a data stream that do not belong, with the objective of having them accepted by the recipient as legitimate. Also included in this category is the insertion of copies of once-legitimate packets that have been recorded and replayed.
スプーフィングとは、ユーザーパケットを送信したり、属していないデータストリームにパケットを挿入したりすることを指します。また、このカテゴリには、記録および再生されたかつての高さのパケットのコピーの挿入も含まれています。
This refers to causing packets to be discarded as they traverse the MPLS/GMPLS networks. This is a specific type of denial-of-service attack.
これは、MPLS/GMPLSネットワークを横断するときにパケットを破棄することを指します。これは、特定のタイプのサービス拒否攻撃です。
This refers to "sniffing" provider or user packets and examining 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. For most users, this type of attack is generally considered to be significantly less of a concern than the other types discussed in this section.
これは、プロバイダーまたはユーザーパケットを「スニッフィング」し、パケット自体が暗号化されている場合でも表示される可能性のあるそれらの側面またはメタアスペクトを調べることを指します。攻撃者は、トラフィック、パケットサイズ、ソース、宛先アドレスなどの量とタイミングに基づいて有用な情報を取得する場合があります。ほとんどのユーザーの場合、このタイプの攻撃は一般に、これで説明されている他のタイプよりも懸念が大幅に少ないと考えられています。セクション。
Denial-of-service (DoS) attacks are those in which an attacker attempts to disrupt or prevent the use of a service by its legitimate users. Taking network devices out of service, modifying their configuration, or overwhelming them with requests for service are several of the possible avenues for DoS attack.
サービス拒否（DOS）攻撃は、攻撃者が正当なユーザーによるサービスの使用を混乱または防止しようとするものです。ネットワークデバイスを使用しなくて、構成の変更、またはサービスのリクエストでそれらを圧倒することは、DOS攻撃の可能性のある手段のいくつかです。
Overwhelming the network with requests for service, otherwise known as a "resource exhaustion" DoS attack, may target any resource in the network, e.g., link bandwidth, packet forwarding capacity, session capacity for various protocols, CPU power, table size, storage overflows, and so on.
「リソースの消耗」DOS攻撃とも呼ばれるサービスの要求でネットワークを圧倒することは、ネットワーク内の任意のリソース、例えばリンク帯域幅、パケット転送容量、さまざまなプロトコルのセッション容量、CPUパワー、テーブルサイズ、ストレージオーバーフローをターゲットにすることができます、 等々。
DoS attacks of the resource exhaustion type can be mounted against the data plane of a particular provider or end user by attempting to insert (spoofing) an overwhelming quantity of inauthentic data into the provider or end-user's network from outside of the trusted zone. Potential results might be to exhaust the bandwidth available to that provider or end user, or to overwhelm the cryptographic authentication mechanisms of the provider or end user.
リソース排出タイプのDOS攻撃は、信頼できるゾーンの外側からプロバイダーまたはエンドユーザーのネットワークに圧倒的な量の不正データを挿入しようとすることにより、特定のプロバイダーまたはエンドユーザーのデータプレーンに対してマウントできます。潜在的な結果は、そのプロバイダーまたはエンドユーザーが利用できる帯域幅を使い果たしたり、プロバイダーまたはエンドユーザーの暗号化認証メカニズムを圧倒することです。
Data-plane resource exhaustion attacks can also be mounted by overwhelming the service provider's general (MPLS/GMPLS-independent) infrastructure with traffic. These attacks on the general infrastructure are not usually an MPLS/GMPLS-specific issue, unless the attack is mounted by another MPLS/GMPLS network user from a privileged position. (For example, an MPLS/GMPLS network user might be able to monopolize network data-plane resources and thus disrupt other users.)
データプレーンのリソース消耗攻撃は、トラフィックを備えたサービスプロバイダーの一般（MPLS/GMPLSに依存しない）インフラストラクチャを圧倒することで取り付けることもできます。一般的なインフラストラクチャに対するこれらの攻撃は、特権的なポジションから別のMPLS/GMPLSネットワークユーザーによって攻撃がマウントされない限り、通常、MPLS/GMPLS固有の問題ではありません。（たとえば、MPLS/GMPLSネットワークユーザーは、ネットワークデータプレーンリソースを独占し、他のユーザーを破壊できる可能性があります。）
Many DoS attacks use amplification, whereby the attacker co-opts otherwise innocent parties to increase the effect of the attack. The attacker may, for example, send packets to a broadcast or multicast address with the spoofed source address of the victim, and all of the recipients may then respond to the victim.
多くのDOS攻撃は増幅を使用しています。それにより、攻撃者は攻撃者を採用して、攻撃の影響を高めています。たとえば、攻撃者は、被害者のスプーフィングされたソースアドレスで放送またはマルチキャストアドレスにパケットを送信する場合があり、すべての受信者が被害者に応答する場合があります。
Misconnection may arise through deliberate attack, or through misconfiguration or misconnection of the network resources. The result is likely to be delivery of data to the wrong destination or black-holing of the data.
誤解は、意図的な攻撃、またはネットワークリソースの誤解または誤解を通じて発生する可能性があります。結果は、間違った宛先へのデータの配信またはデータのブラックホーリングになる可能性があります。
In GMPLS with physically diverse control and data planes, it may be possible for data-plane misconnection to go undetected by the control plane.
物理的に多様なコントロールとデータプレーンを備えたGMPLSでは、データプレーンの誤解がコントロールプレーンによって検出されないことが可能になる場合があります。
In optical networks under GMPLS control, misconnection may give rise to physical safety risks as unprotected lasers may be activated without warning.
GMPLS制御下の光ネットワークでは、保護されていないレーザーが警告なしに活性化される可能性があるため、誤った接続が物理的安全リスクを引き起こす可能性があります。
Attacks on the Operation and Management plane have been discussed extensively as general network security issues over the last 20 years. RFC 4778 [RFC4778] may serve as the best current operational security practices in Internet Service Provider environments. RFC 4377 [RFC4377] provided Operations and Management Requirements for MPLS networks. See also the Security Considerations of RFC 4377 and Section 7 of RFC 4378 [RFC4378].
操作および管理機への攻撃は、過去20年間で一般的なネットワークセキュリティの問題として広範囲に議論されてきました。RFC 4778 [RFC4778]は、インターネットサービスプロバイダー環境で現在の最良の運用セキュリティプラクティスとして機能する可能性があります。RFC 4377 [RFC4377]は、MPLSネットワークの運用と管理要件を提供しました。RFC 4377およびRFC 4378 [RFC4378]のセクション7のセキュリティ上の考慮事項も参照してください。
Operation and Management across the MPLS-ICI could also be the source of security threats on the provider infrastructure as well as the service offered over the MPLS-ICI. A large volume of Operation and Management messages could overwhelm the processing capabilities of an ASBR if the ASBR is not properly protected. Maliciously generated Operation and Management messages could also be used to bring down an otherwise healthy service (e.g., MPLS Pseudowire), and therefore affect service security. LSP ping does not support authentication today, and that support should be a subject for future considerations. Bidirectional Forwarding Detection (BFD), however, does have support for carrying an authentication object. It also supports Time-To-Live (TTL) processing as an anti-replay measure. Implementations conformant with this MPLS-ICI should support BFD authentication and must support the procedures for TTL processing.
MPLS-ICI全体の運用と管理は、MPLS-ICIで提供されるサービスだけでなく、プロバイダーインフラストラクチャのセキュリティ脅威の源でもあります。ASBRが適切に保護されていない場合、大量の操作および管理メッセージは、ASBRの処理機能を圧倒する可能性があります。悪意のある操作および管理メッセージを使用して、そうでなければ健康的なサービス（MPLS Pseudowireなど）を削減するため、サービスセキュリティに影響を与えます。LSP Pingは今日の認証をサポートしておらず、そのサポートは将来の考慮事項の対象となるはずです。ただし、双方向転送検出（BFD）は、認証オブジェクトを運ぶことをサポートしています。また、アンチレプレイメジャーとしての時間（TTL）処理もサポートしています。このMPLS-ICIに準拠した実装は、BFD認証をサポートし、TTL処理の手順をサポートする必要があります。
Regarding GMPLS Operation and Management considerations in optical interworking, there is a good discussion on security for management interfaces to Network Elements [OIF-Sec-Mag].
光学インターワーキングにおけるGMPLSの運用と管理に関する考慮事項に関して、ネットワーク要素[OIF-SEC-Mag]への管理インターフェイスのセキュリティに関する良い議論があります。
Network elements typically have one or more (in some cases many) Operation and Management interfaces used for network management, billing and accounting, configuration, maintenance, and other administrative activities.
ネットワーク要素には、通常、ネットワーク管理、請求と会計、構成、メンテナンス、およびその他の管理活動に使用される1つ以上の（場合によっては、多くの場合）操作および管理インターフェイスがあります。
Remote access to a network element through these Operation and Management interfaces is frequently a requirement. Securing the control protocols while leaving these Operation and Management interfaces unprotected opens up a huge security vulnerability. Network elements are an attractive target for intruders who want to disrupt or gain free access to telecommunications facilities. Much has been written about this subject since the 1980s. In the 1990s, telecommunications facilities were identified in the U.S. and other countries as part of the "critical infrastructure", and increased emphasis was placed on thwarting such attacks from a wider range of potentially well-funded and determined adversaries.
これらの操作および管理インターフェイスを介したネットワーク要素へのリモートアクセスは、多くの場合要件です。これらの操作および管理インターフェイスを保護されていない操作および管理インターフェイスを離れながら、制御プロトコルを保護すると、大きなセキュリティの脆弱性が開きます。ネットワーク要素は、電気通信施設への自由なアクセスを中断または獲得したい侵入者にとって魅力的なターゲットです。1980年代以来、この主題について多くのことが書かれています。1990年代には、「重要なインフラストラクチャ」の一部として米国およびその他の国で電気通信施設が特定され、潜在的に資金提供された潜在的で決定された敵対者の幅広い範囲からの攻撃を妨害することに重点が置かれました。
At one time, careful access controls and password management were a sufficient defense, but are no longer. Networks using the TCP/IP protocol suite are vulnerable to forged source addresses, recording and later replay, packet sniffers picking up passwords, re-routing of traffic to facilitate eavesdropping or tampering, active hijacking attacks of TCP connections, and a variety of denial-of-service attacks. The ease of forging TCP/IP packets is the main reason network management protocols lacking strong security have not been used to configure network elements (e.g., with the SNMP SET command).
かつて、慎重なアクセス制御とパスワード管理は十分な防御でしたが、もはやありません。TCP/IPプロトコルスイートを使用したネットワークは、Forged Sourceアドレス、記録、およびその後のリプレイ、パッケージスニファーのパスワードのピックアップ、トラフィックの再ルーティング、TCP接続の盗聴または改ざん、アクティブなハイジャック攻撃、およびさまざまな否定を促進するためのトラフィックの再ルーティングに対して脆弱です。サービス攻撃の攻撃。TCP/IPパケットの策定の容易さは、強力なセキュリティを欠くネットワーク管理プロトコルがネットワーク要素の構成に使用されていない主な理由です（たとえば、SNMPセットコマンドを使用）。
Readily available hacking tools exist that let an eavesdropper on a LAN take over one end of any TCP connection, so that the legitimate party is cut off. In addition, enterprises and Service Providers in some jurisdictions need to safeguard data about their users and network configurations from prying. An attacker could eavesdrop and observe traffic to analyze usage patterns and map a network configuration; an attacker could also gain access to systems and manipulate configuration data or send malicious commands.
LAN上の盗聴者がTCP接続の一方の端を引き継ぐことができるように、すぐに利用可能なハッキングツールが存在し、正当なパーティーが遮断されます。さらに、一部の管轄区域の企業とサービスプロバイダーは、ユーザーとpr索からのネットワーク構成に関するデータを保護する必要があります。攻撃者は、使用パターンを分析し、ネットワーク構成をマッピングするためにトラフィックを盗聴して観察することができます。攻撃者は、システムにアクセスして構成データを操作したり、悪意のあるコマンドを送信したりすることもあります。
Therefore, in addition to authenticating the human user, more sophisticated protocol security is needed for Operation and Management interfaces, especially when they are configured over TCP/IP stacks. Finally, relying on a perimeter defense, such as firewalls, is insufficient protection against "insider attacks" or against penetrations that compromise a system inside the firewall as a launching pad to attack network elements. The insider attack is discussed in the following session.
したがって、人間のユーザーを認証することに加えて、特にTCP/IPスタックで構成されている場合、運用および管理インターフェイスには、より洗練されたプロトコルセキュリティが必要です。最後に、ファイアウォールなどの境界防御に依存することは、ネットワーク要素を攻撃するための発射パッドとしてファイアウォール内のシステムを妥協する「インサイダー攻撃」または侵入に対する保護が不十分です。インサイダー攻撃については、次のセッションで説明します。
The chain of trust model means that MPLS and GMPLS networks are particularly vulnerable to insider attacks. These can be launched by any malign person with access to any LSR in the trust domain. Insider attacks could also be launched by compromised software within the trust domain. Such attacks could, for example, advertise non-existent resources, modify advertisements from other routers, request unwanted LSPs that use network resources, or deny or modify legitimate LSP requests.
Chain of Trustモデルは、MPLSおよびGMPLSネットワークがインサイダー攻撃に対して特に脆弱であることを意味します。これらは、トラストドメイン内の任意のLSRにアクセスできる任意の悪意者が起動できます。インサイダー攻撃は、Trustドメイン内の侵害されたソフトウェアによって起動することもできます。このような攻撃は、たとえば、存在しないリソースを宣伝したり、他のルーターからの広告を変更したり、ネットワークリソースを使用する不要なLSPを要求したり、合法的なLSPリクエストを拒否または変更したりする可能性があります。
Protection against insider attacks is largely for future study in MPLS and GMPLS networks. Some protection can be obtained by providing strict security for software upgrades and tight OAM access control procedures. Further protection can be achieved by strict control of user (i.e., operator) access to LSRs. Software change management and change tracking (e.g., CVS diffs from text-based configuration files) helps in spotting irregularities and human errors. In some cases, configuration change approval processes may also be warranted. Software tools could be used to check configurations for consistency and compliance. Software tools may also be used to monitor and report network behavior and activity in order to quickly spot any irregularities that may be the result of an insider attack.
インサイダー攻撃に対する保護は、主にMPLSおよびGMPLSネットワークでの将来の研究のためのものです。ソフトウェアのアップグレードとタイトなOAMアクセス制御手順に厳格なセキュリティを提供することにより、いくつかの保護を取得できます。ユーザー（すなわち、オペレーター）のLSRへのアクセスの厳格な制御によって、さらなる保護を実現できます。ソフトウェアの変更管理と変更追跡（たとえば、CVSはテキストベースの構成ファイルとは異なります）は、不規則性や人的エラーの発見に役立ちます。場合によっては、構成変更承認プロセスも保証される場合があります。ソフトウェアツールを使用して、一貫性とコンプライアンスがあることを構成を確認できます。ソフトウェアツールを使用して、インサイダー攻撃の結果である可能性のある不規則性を迅速に見つけるために、ネットワークの動作とアクティビティを監視および報告することもできます。
The defensive techniques discussed in this document are intended to describe methods by which some security threats can be addressed. They are not intended as requirements for all MPLS/GMPLS implementations. The MPLS/GMPLS provider should determine the applicability of these techniques to the provider's specific service offerings, and the end user may wish to assess the value of these techniques to the user's service requirements. The operational environment determines the security requirements. Therefore, protocol designers need to provide a full set of security services, which can be used where appropriate.
このドキュメントで説明されている防御手法は、いくつかのセキュリティの脅威に対処できる方法を説明することを目的としています。これらは、すべてのMPL/GMPLS実装の要件として意図されていません。MPLS/GMPLSプロバイダーは、プロバイダーの特定のサービス提供にこれらの手法の適用性を決定する必要があり、エンドユーザーは、これらの手法の価値をユーザーのサービス要件に評価することを希望する場合があります。運用環境がセキュリティ要件を決定します。したがって、プロトコル設計者は、必要に応じて使用できるセキュリティサービスの完全なセットを提供する必要があります。
The techniques discussed here include encryption, authentication, filtering, firewalls, access control, isolation, aggregation, and others.
ここで説明する手法には、暗号化、認証、フィルタリング、ファイアウォール、アクセス制御、分離、集約などが含まれます。
Often, security is achieved by careful protocol design, rather than by adding a security method. For example, one method of mitigating DoS attacks is to make sure that innocent parties cannot be used to amplify the attack. Security works better when it is "designed in" rather than "added on".
多くの場合、セキュリティはセキュリティ方法を追加するのではなく、慎重なプロトコル設計によって達成されます。たとえば、DOS攻撃を緩和する1つの方法は、罪のない当事者を使用して攻撃を増幅できないことを確認することです。セキュリティは、「追加」ではなく「設計」されている場合、より良く機能します。
Nothing is ever 100% secure. Defense therefore involves protecting against those attacks that are most likely to occur or that have the most direct consequences if successful. For those attacks that are protected against, absolute protection is seldom achievable; more often it is sufficient just to make the cost of a successful attack greater than what the adversary will be willing or able to expend.
100％安全なものはありません。したがって、防衛には、発生する可能性が最も高い、または成功した場合に最も直接的な結果をもたらす攻撃から保護することが含まれます。保護されている攻撃の場合、絶対的な保護はめったに達成できません。より多くの場合、攻撃の成功のコストを、敵が喜んで支出するか、または支出することができるものよりも大きくなるだけで十分です。
Successfully defending against an attack does not necessarily mean the attack must be prevented from happening or from reaching its target. In many cases, the network can instead be designed to withstand the attack. For example, the introduction of inauthentic packets could be defended against by preventing their introduction in the first place, or by making it possible to identify and eliminate them before delivery to the MPLS/GMPLS user's system. The latter is frequently a much easier task.
攻撃に対する防御に成功すると、必ずしも攻撃が発生したり、ターゲットに到達することを防ぐ必要があるという意味ではありません。多くの場合、ネットワークは代わりに攻撃に耐えるように設計できます。たとえば、最初の場所での導入を防止するか、MPLS/GMPLSユーザーシステムに配信する前にそれらを特定して排除できるようにすることにより、不正なパケットの導入を防御することができます。後者はしばしばはるかに簡単な作業です。
To prevent security issues arising from some DoS attacks or from malicious or accidental misconfiguration, it is critical that devices in the MPLS/GMPLS should only accept connections or control messages from valid sources. Authentication refers to methods to ensure that message sources are properly identified by the MPLS/GMPLS devices with which they communicate. This section focuses on identifying the scenarios in which sender authentication is required and recommends authentication mechanisms for these scenarios.
一部のDOS攻撃または悪意のあるまたは偶発的な誤解から生じるセキュリティの問題を防ぐために、MPLS/GMPLのデバイスは、有効なソースからの接続または制御メッセージのみを受け入れることが重要です。認証とは、メッセージソースが通信するMPLS/GMPLSデバイスによって適切に識別されることを保証する方法を指します。このセクションでは、送信者認証が必要なシナリオの特定に焦点を当て、これらのシナリオの認証メカニズムを推奨します。
Cryptographic techniques (authentication, integrity, and encryption) do not protect against some types of denial-of-service attacks, specifically resource exhaustion attacks based on CPU or bandwidth exhaustion. In fact, the software-based cryptographic processing required to decrypt or check authentication may in some cases increase the effect of these resource exhaustion attacks. With a hardware cryptographic accelerator, attack packets can be dropped at line speed without a cost to software cycles. Cryptographic techniques may, however, be useful against resource exhaustion attacks based on the exhaustion of state information (e.g., TCP SYN attacks).
暗号化技術（認証、整合性、暗号化）は、一部の種類のサービス拒否攻撃、特にCPUまたは帯域幅の枯渇に基づくリソース疲労攻撃から保護しません。実際、認証を復号化またはチェックするために必要なソフトウェアベースの暗号化処理は、場合によっては、これらのリソース排出攻撃の効果を高める可能性があります。ハードウェア暗号化アクセラレータを使用すると、ソフトウェアサイクルにコストをかけずに攻撃パケットをライン速度で落とすことができます。ただし、暗号化技術は、状態情報の疲労（TCP Syn攻撃など）に基づいて、リソースの使い果たされた攻撃に対して有用である可能性があります。
The MPLS data plane, as presently defined, is not amenable to source authentication, as there are no source identifiers in the MPLS packet to authenticate. The MPLS label is only locally meaningful. It may be assigned by a downstream node or upstream node for multicast support.
現在定義されているMPLSデータプレーンは、MPLSパケットに認証するソース識別子がないため、ソース認証に適していません。MPLSラベルは、局所的に意味があります。マルチキャストサポートのために、下流ノードまたは上流ノードによって割り当てられる場合があります。
When the MPLS payload carries identifiers that may be authenticated (e.g., IP packets), authentication may be carried out at the client level, but this does not help the MPLS SP, as these client identifiers belong to an external, untrusted network.
MPLSペイロードが認証される可能性のある識別子（IPパケットなど）を運ぶと、クライアントレベルで認証が実行される場合がありますが、これらのクライアント識別子が外部の信頼できないネットワークに属しているため、これはMPLS SPに役立ちません。
Management system authentication includes the authentication of a PE to a centrally managed network management or directory server when directory-based "auto-discovery" is used. It also includes authentication of a CE to the configuration server, when a configuration server system is used.
管理システム認証には、ディレクトリベースの「自動配置」が使用される場合、中央管理ネットワーク管理またはディレクトリサーバーへのPEの認証が含まれます。また、構成サーバーシステムを使用する場合、CEのCEの認証も含まれています。
Authentication should be bidirectional, including PE or CE to configuration server authentication for the PE or CE to be certain it is communicating with the right server.
認証は、適切なサーバーと通信していることを確認するために、PEまたはCEの構成サーバー認証のPEまたはCEを含む双方向である必要があります。
Peer-to-peer authentication includes peer authentication for network control protocols (e.g., LDP, BGP, etc.) and other peer authentication (i.e., authentication of one IPsec security gateway by another).
ピアツーピア認証には、ネットワーク制御プロトコルのピア認証（LDP、BGPなど）およびその他のピア認証（つまり、1つのIPSECセキュリティゲートウェイによる別のIPSECセキュリティゲートウェイの認証）が含まれます。
Authentication should be bidirectional, including PE or CE to configuration server authentication for the PE or CE to be certain it is communicating with the right server.
認証は、適切なサーバーと通信していることを確認するために、PEまたはCEの構成サーバー認証のPEまたはCEを含む双方向である必要があります。
As indicated in Section 5.1.1, authentication should be bidirectional.
セクション5.1.1で示されているように、認証は双方向でなければなりません。
Cryptographic techniques offer several mechanisms for authenticating the identity of devices or individuals. These include the use of shared secret keys, one-time keys generated by accessory devices or software, user-ID and password pairs, and a range of public-private key systems. Another approach is to use a hierarchical Certification Authority system to provide digital certificates.
暗号化技術は、デバイスまたは個人のアイデンティティを認証するためのいくつかのメカニズムを提供します。これらには、共有されたシークレットキーの使用、アクセサリデバイスまたはソフトウェアによって生成された1回限りのキー、ユーザーIDとパスワードペア、さまざまな官民キーシステムが含まれます。もう1つのアプローチは、階層認証機関システムを使用してデジタル証明書を提供することです。
This section describes or provides references to the specific cryptographic approaches for authenticating identity. These approaches provide secure mechanisms for most of the authentication scenarios required in securing an MPLS/GMPLS network.
このセクションでは、アイデンティティを認証するための特定の暗号化アプローチへの参照について説明または提供します。これらのアプローチは、MPLS/GMPLSネットワークの保護に必要なほとんどの認証シナリオの安全なメカニズムを提供します。
MPLS/GMPLS defenses against a wide variety of attacks can be enhanced by the proper application of cryptographic techniques. These same cryptographic techniques are applicable to general network communications and can provide confidentiality (encryption) of communication between devices, authenticate the identities of the devices, and detect whether the data being communicated has been changed during transit or replayed from previous messages.
MPLS/GMPLSは、暗号化技術を適切に適用することにより、さまざまな攻撃に対する防御を強化できます。これらの同じ暗号化手法は、一般的なネットワーク通信に適用でき、デバイス間の通信の機密性（暗号化）を提供し、デバイスのアイデンティティを認証し、通信中のデータがトランジット中に変更されたか、以前のメッセージから再生されたかを検出できます。
Several aspects of authentication are addressed in some detail in a separate "Authentication" section (Section 5.1).
認証のいくつかの側面については、別の「認証」セクション（セクション5.1）で詳細に説明されています。
Cryptographic methods add complexity to a service and thus, for a few reasons, may not be the most practical solution in every case. Cryptography adds an additional computational burden to devices, which may reduce the number of user connections that can be handled on a device or otherwise reduce the capacity of the device, potentially driving up the provider's costs. Typically, configuring encryption services on devices adds to the complexity of their configuration and adds labor cost. Some key management system is usually needed. Packet sizes are typically increased when the packets are encrypted or have integrity checks or replay counters added, increasing the network traffic load and adding to the likelihood of packet fragmentation with its increased overhead. (This packet length increase can often be mitigated to some extent by data compression techniques, but at the expense of additional computational burden.) Finally, some providers may employ enough other defensive techniques, such as physical isolation or filtering and firewall techniques, that they may not perceive additional benefit from encryption techniques.
暗号化方法は、サービスに複雑さを追加するため、いくつかの理由で、すべての場合に最も実用的なソリューションではない場合があります。暗号化は、デバイスに追加の計算負荷を追加します。これにより、デバイスで処理できるユーザー接続の数が減り、デバイスの容量を減らし、プロバイダーのコストを引き上げる可能性があります。通常、デバイスで暗号化サービスを構成すると、構成の複雑さが追加され、人件費が追加されます。通常、いくつかの重要な管理システムが必要です。パケットが暗号化されているか、整合性チェックまたはリプレイカウンターが追加されている場合、パケットサイズは通常、ネットワークトラフィックの負荷を増加させ、オーバーヘッドの増加に伴ってパケットフラグメンテーションの可能性を増加させます。（このパケットの長さの増加は、しばしばデータ圧縮手法によってある程度緩和される可能性がありますが、追加の計算負担を犠牲にします。）最後に、一部のプロバイダーは、物理的分離やフィルタリングやファイアウォール技術など、他の防御技術を十分に採用する場合があります。暗号化技術からの追加の利点を認識しない場合があります。
Users may wish to provide confidentiality end to end. Generally, encrypting for confidentiality must be accompanied with cryptographic integrity checks to prevent certain active attacks against the encrypted communications. On today's processors, encryption and integrity checks run extremely quickly, but key management may be more demanding in terms of both computational and administrative overhead.
ユーザーは、端から端まで機密性を提供したい場合があります。一般に、機密性のために暗号化するには、暗号化された通信に対する特定のアクティブな攻撃を防ぐために、暗号化の整合性チェックを伴う必要があります。今日のプロセッサでは、暗号化と整合性チェックは非常に迅速に実行されますが、計算オーバーヘッドと管理上の両方のオーバーヘッドに関しては、重要な管理がより厳しい場合があります。
The trust model among the MPLS/GMPLS user, the MPLS/GMPLS provider, and other parts of the network is a major element in determining the applicability of cryptographic protection for any specific MPLS/GMPLS implementation. In particular, it determines where cryptographic protection should be applied:
MPLS/GMPLSユーザー、MPLS/GMPLSプロバイダー、およびネットワークの他の部分の間の信頼モデルは、特定のMPLS/GMPLS実装の暗号化保護の適用性を決定する主要な要素です。特に、暗号化保護を適用する場所を決定します。
- If the data path between the user's site and the provider's PE is not trusted, then it may be used on the PE-CE link.
- ユーザーのサイトとプロバイダーのPEの間のデータパスが信頼されていない場合、PE-CEリンクで使用できます。
- If some part of the backbone network is not trusted, particularly in implementations where traffic may travel across the Internet or multiple providers' networks, then the PE-PE traffic may be cryptographically protected. One also should consider cases where L1 technology may be vulnerable to eavesdropping.
- バックボーンネットワークの一部が信頼されていない場合、特にトラフィックがインターネットや複数のプロバイダーのネットワークを越えて移動する可能性がある場合、PE-PEトラフィックは暗号化されている可能性があります。また、L1テクノロジーが盗聴に対して脆弱である可能性がある場合も考慮する必要があります。
- If the user does not trust any zone outside of its premises, it may require end-to-end or CE-CE cryptographic protection. This fits within the scope of this MPLS/GMPLS security framework when the CE is provisioned by the MPLS/GMPLS provider.
- ユーザーが敷地外のゾーンを信頼していない場合、エンドツーエンドまたはCE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-Ce-Ce-Ce-Ce-Ce-Ce-Ce-Ce-Ce-Ce-Ce-Ce-Ce-Ce-Ce-Ce-Ce-Ce-Ce-Ceがこれは、CEがMPLS/GMPLSプロバイダーによってプロビジョニングされている場合、このMPLS/GMPLSセキュリティフレームワークの範囲内に適合します。
- If the user requires remote access to its site from a system at a location that is not a customer location (for example, access by a traveler), there may be a requirement for cryptographically protecting the traffic between that system and an access point or a customer's site. If the MPLS/GMPLS provider supplies the access point, then the customer must cooperate with the provider to handle the access control services for the remote users. These access control services are usually protected cryptographically, as well.
- ユーザーが、顧客の場所ではない場所のシステムからサイトへのリモートアクセスを必要とする場合（たとえば、旅行者によるアクセスなど）、そのシステムとアクセスポイントまたはAの間のトラフィックを暗号化して保護する必要がある場合があります。顧客のサイト。MPLS/GMPLSプロバイダーがアクセスポイントを提供する場合、顧客はプロバイダーと協力して、リモートユーザーのアクセス制御サービスを処理する必要があります。これらのアクセス制御サービスは、通常、暗号化されています。
Access control usually starts with authentication of the entity. If cryptographic services are part of the scenario, then it is important to bind the authentication to the key management. Otherwise, the protocol is vulnerable to being hijacked between the authentication and key management.
通常、アクセス制御はエンティティの認証から始まります。暗号化サービスがシナリオの一部である場合、認証を主要な管理に結合することが重要です。それ以外の場合、プロトコルは、認証と主要な管理の間でハイジャックされることに対して脆弱です。
Although CE-CE cryptographic protection can provide integrity and confidentiality against third parties, if the MPLS/GMPLS provider has complete management control over the CE (encryption) devices, then it may be possible for the provider to gain access to the user's traffic or internal network. Encryption devices could potentially be reconfigured to use null encryption, bypass cryptographic processing altogether, reveal internal configuration, or provide some means of sniffing or diverting unencrypted traffic. Thus an implementation using CE-CE encryption needs to consider the trust relationship between the MPLS/GMPLS user and provider. MPLS/GMPLS users and providers may wish to negotiate a service level agreement (SLA) for CE-CE encryption that provides an acceptable demarcation of responsibilities for management of cryptographic protection on the CE devices. The demarcation may also be affected by the capabilities of the CE devices. For example, the CE might support some partitioning of management, a configuration lock-down ability, or shared capability to verify the configuration. In general, the MPLS/GMPLS user needs to have a fairly high level of trust that the MPLS/GMPLS provider will properly provision and manage the CE devices, if the managed CE-CE model is used.
CE-CEの暗号化保護は、第三者に対して完全性と機密性を提供できますが、MPLS/GMPLSプロバイダーがCE（暗号化）デバイスを完全に管理する管理制御を持っている場合、プロバイダーはユーザーのトラフィックまたは内部にアクセスできる可能性があります通信網。暗号化デバイスは、ヌル暗号化を使用したり、暗号化処理を完全にバイパスしたり、内部構成を明らかにしたり、暗号化されていないトラフィックをスニッフィングまたは迂回させたりするために再構成される可能性があります。したがって、CE-CEの暗号化を使用した実装では、MPLS/GMPLSユーザーとプロバイダー間の信頼関係を考慮する必要があります。MPLS/GMPLSユーザーとプロバイダーは、CE-CE-CE-CE-CE-CE-CE-CE-CONTIONの管理の責任の許容可能な境界を提供するCE-CEの暗号化のサービスレベル契約（SLA）を交渉したい場合があります。境界は、CEデバイスの機能によっても影響を受ける可能性があります。たとえば、CEは、管理の一部のパーティション化、構成ロックダウン機能、または構成を確認する共有機能をサポートする場合があります。一般に、MPLS/GMPLSユーザーは、管理されたCE-CEモデルを使用する場合、MPLS/GMPLSプロバイダーがCEデバイスを適切にプロビジョニングおよび管理するというかなり高いレベルの信頼を持つ必要があります。
IPsec [RFC4301] [RFC4302] [RFC4835] [RFC4306] [RFC4309] [RFC2411] [IPSECME-ROADMAP] is the security protocol of choice for protection at the IP layer. IPsec provides robust security for IP traffic between pairs of devices. Non-IP traffic, such as IS-IS routing, must be converted to IP (e.g., by encapsulation) in order to use IPsec. When the MPLS is encapsulating IP traffic, then IPsec covers the encryption of the IP client layer; for non-IP client traffic, see Section 5.2.4 (MPLS PWs).
IPSEC [RFC4301] [RFC4302] [RFC4835] [RFC4306] [RFC4309] [RFC2411] [RFC2411] [IPSECME-ROADMAP]は、IPレイヤーでの保護の選択のセキュリティプロトコルです。IPSECは、デバイスのペア間のIPトラフィックに堅牢なセキュリティを提供します。IS-ISルーティングなどの非IPトラフィックは、IPSECを使用するために（例：カプセル化により）IPに変換する必要があります。MPLSがIPトラフィックをカプセル化している場合、IPSECはIPクライアントレイヤーの暗号化をカバーします。非IPクライアントトラフィックについては、セクション5.2.4（MPLS PWS）を参照してください。
In the MPLS/GMPLS model, IPsec can be employed to protect IP traffic between PEs, between a PE and a CE, or from CE to CE. CE-to-CE IPsec may be employed in either a provider-provisioned or a user-provisioned model. Likewise, IPsec protection of data performed within the user's site is outside the scope of this document, because it is simply handled as user data by the MPLS/GMPLS core. However, if the SP performs compression, pre-encryption will have a major effect on that operation.
MPLS/GMPLSモデルでは、IPSECを使用して、PE、PEとCEの間、またはCEからCEの間のIPトラフィックを保護することができます。CE-ty-CE IPSECは、プロバイダーがプロビジョニングしたモデルまたはユーザープロビジョニングモデルのいずれかで使用できます。同様に、ユーザーのサイト内で実行されるデータのIPSEC保護は、MPLS/GMPLSコアによってユーザーデータとして単純に処理されるため、このドキュメントの範囲外です。ただし、SPが圧縮を実行すると、その操作に大きな影響があります。
IPsec does not itself specify cryptographic algorithms. It can use a variety of integrity or confidentiality algorithms (or even combined integrity and confidentiality algorithms) with various key lengths, such as AES encryption or AES message integrity checks. There are trade-offs between key length, computational burden, and the level of security of the encryption. A full discussion of these trade-offs is beyond the scope of this document. In practice, any currently recommended IPsec protection offers enough security to reduce the likelihood of its being directly targeted by an attacker substantially; other weaker links in the chain of security are likely to be attacked first. MPLS/GMPLS users may wish to use a Service Level Agreement (SLA) specifying the SP's responsibility for ensuring data integrity and confidentiality, rather than analyzing the specific encryption techniques used in the MPLS/GMPLS service.
IPSEC自体は暗号化アルゴリズムを指定していません。AES暗号化やAESメッセージの整合性チェックなど、さまざまな整合性または機密保持アルゴリズム（または整合性と機密性の組み合わせアルゴリズム）を使用できます。キーの長さ、計算負担、暗号化のセキュリティレベルの間にはトレードオフがあります。これらのトレードオフの完全な議論は、このドキュメントの範囲を超えています。実際には、現在推奨されているIPSEC保護は、攻撃者が大幅に標的とする可能性を減らすのに十分なセキュリティを提供します。セキュリティチェーンの他の弱いリンクが最初に攻撃される可能性があります。MPLS/GMPLSユーザーは、MPLS/GMPLSサービスで使用される特定の暗号化技術を分析するのではなく、データの整合性と機密性を確保するためのSPの責任を指定するサービスレベル契約（SLA）を使用することをお勧めします。
Encryption algorithms generally come with two parameters: mode such as Cipher Block Chaining and key length such as AES-192. (This should not be confused with two other senses in which the word "mode" is used: IPsec itself can be used in Tunnel Mode or Transport Mode, and IKE [version 1] uses Main Mode, Aggressive Mode, or Quick Mode). It should be stressed that IPsec encryption without an integrity check is a state of sin.
暗号化アルゴリズムには、通常、2つのパラメーターが付属しています：暗号ブロックチェーンなどのモードとAES-192などのキー長。（これは、「モード」という単語が使用される他の2つの感覚と混同しないでください。IPSEC自体はトンネルモードまたは輸送モードで使用でき、IKE [バージョン1]はメインモード、攻撃モード、またはクイックモードを使用します）。整合性チェックなしのIPSEC暗号化は罪の状態であることを強調する必要があります。
For many of the MPLS/GMPLS provider's network control messages and some user requirements, cryptographic authentication of messages without encryption of the contents of the message may provide appropriate security. Using IPsec, authentication of messages is provided by the Authentication Header (AH) or through the use of the Encapsulating Security Protocol (ESP) with NULL encryption. Where control messages require integrity but do not use IPsec, other cryptographic authentication methods are often available. Message authentication methods currently considered to be secure are based on hashed message authentication codes (HMAC) [RFC2104] implemented with a secure hash algorithm such as Secure Hash Algorithm 1 (SHA-1) [RFC3174]. No attacks against HMAC SHA-1 are likely to play out in the near future, but it is possible that people will soon find SHA-1 collisions. Thus, it is important that mechanisms be designed to be flexible about the choice of hash functions and message integrity checks. Also, many of these mechanisms do not include a convenient way to manage and update keys.
MPLS/GMPLSプロバイダーのネットワーク制御メッセージと一部のユーザー要件の多くの場合、メッセージの内容を暗号化せずにメッセージの暗号化認証が適切なセキュリティを提供する場合があります。IPSECを使用すると、メッセージの認証は、認証ヘッダー（AH）によって提供されるか、null暗号化を備えたカプセル化セキュリティプロトコル（ESP）を使用して提供されます。コントロールメッセージには完全性が必要であるが、IPSECを使用しない場合、他の暗号化認証方法がよく利用可能です。現在安全であると考えられているメッセージ認証方法は、セキュアハッシュアルゴリズム1（SHA-1）[RFC3174]などの安全なハッシュアルゴリズムで実装されたハッシュされたメッセージ認証コード（HMAC）[RFC2104]に基づいています。HMAC SHA-1に対する攻撃は近い将来に発生する可能性が高いが、人々がすぐにSHA-1の衝突を見つける可能性がある。したがって、メカニズムは、ハッシュ関数の選択とメッセージの整合性チェックの選択について柔軟にするように設計することが重要です。また、これらのメカニズムの多くには、キーを管理および更新する便利な方法は含まれていません。
A mechanism to provide a combination of confidentiality, data-origin authentication, and connectionless integrity is the use of AES in GCM (Counter with CBC-MAC) mode (RFC 4106) [RFC4106].
機密性、データオリジン認証、およびコネクションレスの完全性の組み合わせを提供するメカニズムは、GCM（CBC-MACを備えたカウンター）モード（RFC 4106）[RFC4106]でのAEの使用です。
MPLS and GMPLS, which provide differentiated services based on traffic type, may encounter some conflicts with IPsec encryption of traffic. Because encryption hides the content of the packets, it may not be possible to differentiate the encrypted traffic in the same manner as unencrypted traffic. Although Diffserv markings are copied to the IPsec header and can provide some differentiation, not all traffic types can be accommodated by this mechanism. Using IPsec without IKE or IKEv2 (the better choice) is not advisable. IKEv2 provides IPsec Security Association creation and management, entity authentication, key agreement, and key update. It works with a variety of authentication methods including pre-shared keys, public key certificates, and EAP. If DoS attacks against IKEv2 are considered an important threat to mitigate, the cookie-based anti-spoofing feature of IKEv2 should be used. IKEv2 has its own set of cryptographic methods, but any of the default suites specified in [RFC4308] or [RFC4869] provides more than adequate security.
トラフィックタイプに基づいて差別化されたサービスを提供するMPLSおよびGMPLは、トラフィックのIPSEC暗号化との競合に遭遇する可能性があります。暗号化はパケットのコンテンツを隠すため、暗号化されていないトラフィックと同じ方法で暗号化されたトラフィックを区別することはできない場合があります。DiffServマーキングはIPSECヘッダーにコピーされ、いくつかの分化を提供できますが、すべてのトラフィックタイプがこのメカニズムによって対応できるわけではありません。IKEまたはIKEV2（より良い選択）なしでIPSECを使用することはお勧めできません。IKEV2は、IPSECセキュリティ協会の作成と管理、エンティティ認証、主要な契約、およびキーアップデートを提供します。事前共有キー、公開キー証明書、EAPなど、さまざまな認証方法で動作します。IKEV2に対するDOS攻撃が緩和するための重要な脅威と見なされる場合、IKEV2のCookieベースのアンチスポーフィング機能を使用する必要があります。IKEV2には独自の暗号化方法のセットがありますが、[RFC4308]または[RFC4869]で指定されたデフォルトスイートのいずれかは、適切なセキュリティ以上のものを提供します。
For configuration and management of MPLS/GMPLS devices, encryption and authentication of the management connection at a level comparable to that provided by IPsec is desirable.
MPLS/GMPLSデバイスの構成と管理には、IPSECが提供するレベルに匹敵するレベルでの管理接続の暗号化と認証が望ましいです。
Several methods of transporting MPLS/GMPLS device management traffic offer authentication, integrity, and confidentiality.
MPLS/GMPLSデバイス管理トラフィックを輸送するいくつかの方法は、認証、完全性、および機密性を提供します。
- Secure Shell (SSH) offers protection for TELNET [STD8] or terminal-like connections to allow device configuration.
- Secure Shell（SSH）は、テルネット[STD8]または端子のような接続を保護して、デバイスの構成を可能にします。
- SNMPv3 [STD62] provides encrypted and authenticated protection for SNMP-managed devices.
- SNMPV3 [STD62]は、SNMP管理されたデバイスの暗号化および認証された保護を提供します。
- Transport Layer Security (TLS) [RFC5246] and the closely-related Secure Sockets Layer (SSL) are widely used for securing HTTP-based communication, and thus can provide support for most XML- and SOAP-based device management approaches.
- トランスポートレイヤーセキュリティ（TLS）[RFC5246]および密接に関連するセキュアソケット層（SSL）は、HTTPベースの通信を保護するために広く使用されているため、ほとんどのXMLおよびSOAPベースのデバイス管理アプローチをサポートできます。
- Since 2004, there has been extensive work proceeding in several organizations (OASIS, W3C, WS-I, and others) on securing device management traffic within a "Web Services" framework, using a wide variety of security models, and providing support for multiple security token formats, multiple trust domains, multiple signature formats, and multiple encryption technologies.
- 2004年以来、「Webサービス」フレームワーク内でデバイス管理トラフィックを保護し、さまざまなセキュリティモデルを使用し、複数のサポートを提供するために、いくつかの組織（OASIS、W3C、WS-I、その他）で広範な作業手続きが行われています。セキュリティトークン形式、複数の信頼ドメイン、複数の署名形式、および複数の暗号化テクノロジー。
- IPsec provides security services including integrity and confidentiality at the network layer. With regards to device management, its current use is primarily focused on in-band management of user-managed IPsec gateway devices.
- IPSECは、ネットワークレイヤーでの整合性と機密性を含むセキュリティサービスを提供します。デバイス管理に関して、その現在の使用は、主にユーザー管理されたIPSECゲートウェイデバイスの帯域内管理に焦点を当てています。
- There is recent work in the ISMS WG (Integrated Security Model for SNMP Working Group) to define how to use SSH to secure SNMP, due to the limited deployment of SNMPv3, and the possibility of using Kerberos, particularly for interfaces like TELNET, where client code exists.
- ISMS WG（SNMPワーキンググループの統合セキュリティモデル）には、SNMPV3の展開が限られているため、SSSSSを使用してSNMPを保護する方法を定義する最近の研究があり、特にクライアントのようなインターネットの場合はKerberosを使用する可能性があります。コードが存在します。
In addition to IP traffic, MPLS networks may be used to transport other services such as Ethernet, ATM, Frame Relay, and TDM. This is done by setting up pseudowires (PWs) that tunnel the native service through the MPLS core by encapsulating at the edges. The PWE architecture is defined in [RFC3985].
IPトラフィックに加えて、MPLSネットワークを使用して、イーサネット、ATM、フレームリレー、TDMなどの他のサービスを輸送できます。これは、エッジをカプセル化することにより、MPLSコアを介してネイティブサービスをトンネルするPseudowires（PWS）をセットアップすることによって行われます。PWEアーキテクチャは[RFC3985]で定義されています。
PW tunnels may be set up using the PWE control protocol based on LDP [RFC4447], and thus security considerations for LDP will most likely be applicable to the PWE3 control protocol as well.
PWトンネルは、LDP [RFC4447]に基づくPWEコントロールプロトコルを使用してセットアップできます。したがって、LDPのセキュリティ上の考慮事項は、PWE3制御プロトコルにも適用される可能性が高いです。
PW user packets contain at least one MPLS label (the PW label) and may contain one or more MPLS tunnel labels. After the label stack, there is a four-byte control word (which is optional for some PW types), followed by the native service payload. It must be stressed that encapsulation of MPLS PW packets in IP for the purpose of enabling use of IPsec mechanisms is not a valid option.
PWユーザーパケットには、少なくとも1つのMPLSラベル（PWラベル）が含まれており、1つ以上のMPLSトンネルラベルが含まれている場合があります。ラベルスタックの後、4バイトのコントロールワード（一部のPWタイプではオプション）があり、その後ネイティブサービスペイロードが続きます。IPSECメカニズムの使用を可能にする目的で、IPでのMPLS PWパケットのカプセル化は有効なオプションではないことを強調する必要があります。
The following is a non-exhaustive list of PW-specific threats:
以下は、PW固有の脅威の非網羅的なリストです。
- Unauthorized setup of a PW (e.g., to gain access to a customer network)
- PWの不正なセットアップ（たとえば、顧客ネットワークへのアクセスを得るため）
- Unauthorized teardown of a PW (thus causing denial of service)
- PWの不正な分解（したがって、サービスの拒否を引き起こす）
- Malicious reroute of a PW
- PWの悪意のあるルート
- Unauthorized observation of PW packets
- PWパケットの不正な観察
- Traffic analysis of PW connectivity
- PW接続のトラフィック分析
- Unauthorized insertion of PW packets
- PWパケットの不正な挿入
- Unauthorized modification of PW packets
- PWパケットの不正な変更
- Unauthorized deletion of PW packets replay of PW packets
- PWパケットの不正な削除PWパケットのリプレイ
- Denial of service or significant impact on PW service quality
- サービスの拒否またはPWサービス品質への大きな影響
These threats are not mutually exclusive, for example, rerouting can be used for snooping or insertion/deletion/replay, etc. Multisegment PWs introduce additional weaknesses at their stitching points.
これらの脅威は相互に排他的ではありません。たとえば、リルートはスヌーピングまたは挿入/削除/リプレイなどに使用できます。マルチセグメントPWは、ステッチポイントに追加の弱点をもたらします。
The PW user plane suffers from the following inherent security weaknesses:
PWユーザープレーンは、次の固有のセキュリティの弱点に苦しんでいます。
- Since the PW label is the only identifier in the packet, there is no authenticatable source address.
- PWラベルはパケットの唯一の識別子であるため、認証可能なソースアドレスはありません。
- Since guessing a valid PW label is not difficult, it is relatively easy to introduce seemingly valid foreign packets.
- 有効なPWラベルを推測することは難しくないため、一見有効な外国のパケットを導入するのは比較的簡単です。
- Since the PW packet is not self-describing, minor modification of control-plane packets renders the data-plane traffic useless.
- PWパケットは自己記述的ではないため、コントロールプレーンパケットのマイナーな変更により、データプレーントラフィックが役に立たなくなります。
- The control-word sequence number processing algorithm is susceptible to a DoS attack.
- コントロールワードシーケンス番号処理アルゴリズムは、DOS攻撃の影響を受けやすくなります。
The PWE control protocol introduces its own weaknesses:
PWEコントロールプロトコルは、独自の弱点を導入します。
- No (secure) peer autodiscovery technique has been standardized .
- NO（安全な）ピアオートディスコビリテクニックが標準化されています。
- PE authentication is not mandated, so an intruder can potentially impersonate a PE; after impersonating a PE, unauthorized PWs may be set up, consuming resources and perhaps allowing access to user networks.
- PE認証は義務付けられていないため、侵入者はPEになりすます可能性があります。PEになりすました後、不正なPWSがセットアップされ、リソースが消費され、おそらくユーザーネットワークへのアクセスが可能になります。
- Alternately, desired PWs may be torn down, giving rise to denial of service.
- あるいは、望ましいPWSが取り壊される可能性があり、サービスの拒否が生じます。
The following characteristics of PWs can be considered security strengths:
PWSの次の特性は、セキュリティ強みと見なすことができます。
- The most obvious attacks require compromising edge or core routers (although not necessarily those along the PW path).
- 最も明白な攻撃では、エッジまたはコアルーターを妥協する必要があります（必ずしもPWパスに沿ったものではありませんが）。
- Adequate protection of the control-plane messaging is sufficient to rule out many types of attacks.
- 制御面のメッセージングの適切な保護は、多くの種類の攻撃を除外するのに十分です。
- PEs are usually configured to reject MPLS packets from outside the service provider network, thus ruling out insertion of PW packets from the outside (since IP packets cannot masquerade as PW packets).
- PESは通常、サービスプロバイダーネットワークの外部からMPLSパケットを拒否するように構成されているため、外部からのPWパケットの挿入を除外します（IPパケットはPWパケットを装っていないため）。
In MPLS/GMPLS, cryptographic protection could potentially be applied to the MPLS/GMPLS traffic at several different places. This section discusses some of the tradeoffs in implementing encryption in several different connection topologies among different devices within an MPLS/GMPLS network.
MPLS/GMPLSでは、暗号化保護がいくつかの異なる場所でMPLS/GMPLSトラフィックに適用される可能性があります。このセクションでは、MPLS/GMPLSネットワーク内の異なるデバイス間でいくつかの異なる接続トポロジに暗号化を実装する際のトレードオフのいくつかについて説明します。
Cryptographic protection typically involves a pair of devices that protect the traffic passing between them. The devices may be directly connected (over a single "hop"), or intervening devices may transport the protected traffic between the pair of devices. The extreme cases involve using protection between every adjacent pair of devices along a given path (hop-by-hop), or using protection only between the end devices along a given path (end-to-end). To keep this discussion within the scope of this document, the latter ("end-to-end") case considered here is CE-to-CE rather than fully end-to-end.
暗号化保護には、通常、それらの間のトラフィックを保護するデバイスのペアが含まれます。デバイスは（単一の「ホップ」を超える）直接接続されている場合があります。または、介在するデバイスは、保護されたトラフィックをデバイスのペア間で輸送する場合があります。極端なケースには、特定のパスに沿ったすべての隣接するデバイス間の保護（ホップバイホップ）を使用するか、特定のパスに沿ったエンドデバイス間でのみ保護（エンドツーエンド）を使用することが含まれます。この議論をこのドキュメントの範囲内に保持するために、ここで検討されている後者（「エンドツーエンド」）のケースは、完全にエンドツーエンドではなく、CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CE-CEです。
Figure 3 depicts a simplified topology showing the Customer Edge (CE) devices, the Provider Edge (PE) devices, and a variable number (three are shown) of Provider core (P) devices, which might be present along the path between two sites in a single VPN operated by a single service provider (SP).
図3は、顧客エッジ（CE）デバイス、プロバイダーエッジ（PE）デバイス、およびプロバイダーコア（P）デバイスの可変数（3つが表示される）を示す簡略化されたトポロジを示しています。単一のサービスプロバイダー（SP）が操作する単一のVPNで。
Site_1---CE---PE---P---P---P---PE---CE---Site_2
Site_1 --- CE --- PE --- P --- P --- P --- PE --- CE ---サイト_2
Figure 3: Simplified Topology Traversing through MPLS/GMPLS Core
図3：MPLS/GMPLSコアを通って横断する簡略化されたトポロジー
Within this simplified topology, and assuming that the P devices are not involved with cryptographic protection, four basic, feasible configurations exist for protecting connections among the devices:
この単純化されたトポロジ内で、Pデバイスが暗号化保護に関与していないと仮定すると、デバイス間の接続を保護するための4つの基本的な実行可能な構成が存在します。
1) Site-to-site (CE-to-CE) - Apply confidentiality or integrity services between the two CE devices, so that traffic will be protected throughout the SP's network.
1) サイトからサイト（CE-to-CE） - 2つのCEデバイス間に機密性または整合性サービスを適用して、SPのネットワーク全体でトラフィックが保護されます。
2) Provider edge-to-edge (PE-to-PE) - Apply confidentiality or integrity services between the two PE devices. Unprotected traffic is received at one PE from the customer's CE, then it is protected for transmission through the SP's network to the other PE, and finally it is decrypted or checked for integrity and sent to the other CE.
2) プロバイダーエッジツーエッジ（PE-TO-PE） - 2つのPEデバイス間で機密性または整合性サービスを適用します。保護されていないトラフィックは、顧客のCEから1つのPEで受信され、SPのネットワークを介して他のPEへの送信のために保護され、最終的に整備またはチェックされ、他のCEに送信されます。
3) Access link (CE-to-PE) - Apply confidentiality or integrity services between the CE and PE on each side or on only one side.
3) アクセスリンク（CE-to-PE） - 各側または片側のみに、CEとPEの間に機密性または整合性サービスを適用します。
4) Configurations 2 and 3 above can also be combined, with confidentiality or integrity running from CE to PE, then PE to PE, and then PE to CE.
4) 上記の構成2と3を組み合わせることができ、CEからPE、次にPEにPEに、次にPEに備えて、秘密性または整合性を実行します。
Among the four feasible configurations, key tradeoffs in considering encryption include:
4つの実行可能な構成の中には、暗号化を検討する際の主要なトレードオフが次のとおりです。
- Vulnerability to link eavesdropping or tampering - assuming an attacker can observe or modify data in transit on the links, would it be protected by encryption?
- 盗聴または改ざんのリンクに対する脆弱性 - 攻撃者がリンク上の輸送中のデータを観察または変更できると仮定して、暗号化によって保護されますか？
- Vulnerability to device compromise - assuming an attacker can get access to a device (or freely alter its configuration), would the data be protected?
- デバイスの妥協に対する脆弱性 - 攻撃者がデバイスにアクセスできる（または構成を自由に変更する）と仮定すると、データは保護されますか？
- Complexity of device configuration and management - given the number of sites per VPN customer as Nce and the number of PEs participating in a given VPN as Npe, how many device configurations need to be created or maintained, and how do those configurations scale?
- デバイスの構成と管理の複雑さ-VPN顧客あたりのサイトの数とNPEとしての特定のVPNに参加するPEの数を考えると、デバイス構成を作成または維持する必要があるデバイス構成の数、およびそれらの構成はどのように拡大しますか？
- Processing load on devices - how many cryptographic operations must be performed given N packets? - This raises considerations of device capacity and perhaps end-to-end delay.
- デバイスの処理負荷 - nパケットを考慮して、暗号化操作を実行する必要がありますか？ - これにより、デバイス容量とおそらくエンドツーエンドの遅延の考慮事項が生じます。
- Ability of the SP to provide enhanced services (QoS, firewall, intrusion detection, etc.) - Can the SP inspect the data to provide these services?
- 強化されたサービス（QOS、ファイアウォール、侵入検知など）を提供するSPの能力 - SPは、これらのサービスを提供するためにデータを検査できますか？
These tradeoffs are discussed for each configuration, below:
これらのトレードオフは、以下の構成ごとに議論されています。
1) Site-to-site (CE-to-CE)
1) サイトからサイト（CE-to-CE）
Link eavesdropping or tampering - protected on all links. Device compromise - vulnerable to CE compromise.
リンク盗聴または改ざん - すべてのリンクで保護されています。デバイスの妥協 - CE妥協に対して脆弱です。
Complexity - single administration, responsible for one device per site (Nce devices), but overall configuration per VPN scales as Nce**2.
複雑さ - 単一管理、サイトごとに1つのデバイス（NCEデバイス）を担当しますが、VPNあたりの全体的な構成はNCE ** 2としてスケーリングします。
Though the complexity may be reduced: 1) In practice, as Nce grows, the number of VPNs falls off from being a full clique; 2) If the CEs run an automated key management protocol, then they should be able to set up and tear down secured VPNs without any intervention.
複雑さは減少する可能性がありますが、1）実際には、NCEが成長するにつれて、VPNの数は完全なクリークではありません。2）CESが自動化された主要な管理プロトコルを実行する場合、介入なしに安全なVPNをセットアップして取り壊すことができるはずです。
Processing load - on each of the two CEs, each packet is cryptographically processed (2P), though the protection may be "integrity check only" or "integrity check plus encryption."
処理負荷 - 2つのCEのそれぞれで、各パケットは暗号化された処理（2P）ですが、保護は「整合性チェックのみ」または「整合性チェックと暗号化」である可能性があります。
Enhanced services - severely limited; typically only Diffserv markings are visible to the SP, allowing some QoS services. The CEs could also use the IPv6 Flow Label to identify traffic classes.
強化されたサービス - 厳しく制限されています。通常、DiffservマーキングのみがSPに表示され、いくつかのQoSサービスが許可されます。CESは、IPv6フローラベルを使用してトラフィッククラスを識別することもできます。
2) Provider Edge-to-Edge (PE-to-PE)
2) プロバイダーエッジとエッジ（PE-TO-PE）
Link eavesdropping or tampering - vulnerable on CE-PE links; protected on SP's network links.
リンク盗聴または改ざん - CE -PEリンクで脆弱です。SPのネットワークリンクで保護されています。
Device compromise - vulnerable to CE or PE compromise.
デバイスの妥協 - CEまたはPEの妥協に対して脆弱です。
Complexity - single administration, Npe devices to configure. (Multiple sites may share a PE device so Npe is typically much smaller than Nce.) Scalability of the overall configuration depends on the PPVPN type: if the cryptographic protection is separate per VPN context, it scales as Npe**2 per customer VPN. If it is per-PE, it scales as Npe**2 for all customer VPNs combined.
複雑さ - 単一の管理、構成するNPEデバイス。（複数のサイトがPEデバイスを共有する可能性があるため、NPEは通常NCEよりもはるかに小さくなります。）全体的な構成のスケーラビリティは、PPVPNタイプに依存します。暗号化保護がVPNコンテキストごとに分離されている場合、顧客VPNごとにNPE ** 2としてスケーリングします。PE PERの場合、すべての顧客VPNを組み合わせたNPE ** 2としてスケーリングします。
Processing load - on each of the two PEs, each packet is cryptographically processed (2P).
処理負荷 - 2つのPEのそれぞれで、各パケットは暗号化された処理（2P）です。
Enhanced services - full; SP can apply any enhancements based on detailed view of traffic.
強化されたサービス - フル;SPは、トラフィックの詳細なビューに基づいて、任意の拡張機能を適用できます。
3) Access Link (CE-to-PE)
3) アクセスリンク（CE-to-PE）
Link eavesdropping or tampering - protected on CE-PE link; vulnerable on SP's network links.
リンク盗聴または改ざん - CE -PEリンクで保護されています。SPのネットワークリンクで脆弱です。
Device compromise - vulnerable to CE or PE compromise.
デバイスの妥協 - CEまたはPEの妥協に対して脆弱です。
Complexity - two administrations (customer and SP) with device configuration on each side (Nce + Npe devices to configure), but because there is no mesh, the overall configuration scales as Nce.
複雑さ - 各側にデバイス構成を備えた2つの管理（顧客とSP）（NCE NPEデバイスを構成する）が、メッシュがないため、全体的な構成スケールはNCEとして拡大します。
Processing load - on each of the two CEs, each packet is cryptographically processed, plus on each of the two PEs, each packet is cryptographically processed (4P).
処理負荷 - 2つのCEのそれぞれで、各パケットは暗号化された処理され、さらに2つのPESのそれぞれで、各パケットは暗号化された処理（4P）です。
Enhanced services - full; SP can apply any enhancements based on a detailed view of traffic.
強化されたサービス - フル;SPは、トラフィックの詳細なビューに基づいて、任意の拡張機能を適用できます。
4) Combined Access link and PE-to-PE (essentially hop-by-hop).
4) Combined Access LinkとPE-ToPE（本質的にホップバイホップ）。
Link eavesdropping or tampering - protected on all links.
リンク盗聴または改ざん - すべてのリンクで保護されています。
Device compromise - vulnerable to CE or PE compromise.
デバイスの妥協 - CEまたはPEの妥協に対して脆弱です。
Complexity - two administrations (customer and SP) with device configuration on each side (Nce + Npe devices to configure). Scalability of the overall configuration depends on the PPVPN type: If the cryptographic processing is separate per VPN context, it scales as Npe**2 per customer VPN. If it is per-PE, it scales as Npe**2 for all customer VPNs combined.
複雑さ - 各側にデバイス構成を備えた2つの管理（顧客とSP）（構成するNCE NPEデバイス）。全体的な構成のスケーラビリティは、PPVPNタイプに依存します。暗号化処理がVPNコンテキストごとに分離されている場合、顧客VPNごとにNPE ** 2としてスケーリングします。PE PERの場合、すべての顧客VPNを組み合わせたNPE ** 2としてスケーリングします。
Processing load - on each of the two CEs, each packet is cryptographically processed, plus on each of the two PEs, each packet is cryptographically processed twice (6P).
処理負荷 - 2つのCEのそれぞれで、各パケットは暗号化された処理され、さらに2つのPESのそれぞれで、各パケットは暗号化された2回（6p）です。
Enhanced services - full; SP can apply any enhancements based on a detailed view of traffic.
強化されたサービス - フル;SPは、トラフィックの詳細なビューに基づいて、任意の拡張機能を適用できます。
Given the tradeoffs discussed above, a few conclusions can be drawn:
上記のトレードオフを考えると、いくつかの結論を導き出すことができます。
- Configurations 2 and 3 are subsets of 4 that may be appropriate alternatives to 4 under certain threat models; the remainder of these conclusions compare 1 (CE-to-CE) versus 4 (combined access links and PE-to-PE).
- 構成2と3は、特定の脅威モデルの下で4の適切な代替手段である可能性のある4のサブセットです。これらの結論の残りの部分は、1（CE-ty-CE）と4（結合アクセスリンクとPE-ToPE）を比較します。
- If protection from link eavesdropping or tampering is all that is important, then configurations 1 and 4 are equivalent.
- Link盗聴または改ざんから保護するだけで重要な場合、構成1と4は同等です。
- If protection from device compromise is most important and the threat is to the CE devices, both cases are equivalent; if the threat is to the PE devices, configuration 1 is better.
- デバイスの妥協からの保護が最も重要であり、脅威がCEデバイスに対する脅威である場合、どちらの場合も同等です。PEデバイスに対する脅威の場合、構成1の方が優れています。
- If reducing complexity is most important, and the size of the network is small, configuration 1 is better. Otherwise, configuration 4 is better because rather than a mesh of CE devices, it requires a smaller mesh of PE devices. Also, under some PPVPN approaches, the scaling of 4 is further improved by sharing the same PE-PE mesh across all VPN contexts. The scaling advantage of 4 may be increased or decreased in any given situation if the CE devices are simpler to configure than the PE devices, or vice-versa.
- 複雑さを減らすことが最も重要であり、ネットワークのサイズが小さい場合、構成1の方が優れています。それ以外の場合は、CEデバイスのメッシュではなく、PEデバイスの小さなメッシュが必要であるため、構成4の方が優れています。また、一部のPPVPNアプローチでは、すべてのVPNコンテキストで同じPE-PEメッシュを共有することにより、4のスケーリングがさらに改善されます。CEデバイスの構成がPEデバイスよりも簡単である場合、またはその逆の場合、4のスケーリングの利点は、特定の状況で増加または減少する場合があります。
- If the overall processing load is a key factor, then 1 is better, unless the PEs come with a hardware encryption accelerator and the CEs do not.
- 全体的な処理荷重が重要な要素である場合、PESにハードウェア暗号化アクセラレータが付属し、CESが搭載されていない限り、1の方が優れています。
- If the availability of enhanced services support from the SP is most important, then 4 is best.
- SPからの強化されたサービスサポートの可用性が最も重要な場合、4が最適です。
- If users are concerned with having their VPNs misconnected with other users' VPNs, then encryption with 1 can provide protection.
- ユーザーがVPNを他のユーザーのVPNと間違えていることに関心がある場合、1で暗号化すると保護を提供できます。
As a quick overall conclusion, CE-to-CE protection is better against device compromise, but this comes at the cost of enhanced services and at the cost of operational complexity due to the Order(n**2) scaling of a larger mesh.
全体的な結論として、CE-CE-CEの保護はデバイスの妥協に対して優れていますが、これはサービスの強化された犠牲と、より大きなメッシュの順序（n ** 2）のスケーリングにより、運用上の複雑さを犠牲にします。
This analysis of site-to-site vs. hop-by-hop tradeoffs does not explicitly include cases of multiple providers cooperating to provide a PPVPN service, public Internet VPN connectivity, or remote access VPN service, but many of the tradeoffs are similar.
サイトからサイトへのこの分析とホップバイホップトレードオフには、PPVPNサービス、パブリックインターネットVPN接続、またはリモートアクセスVPNサービスを提供するために協力している複数のプロバイダーのケースは明示的に含まれていませんが、トレードオフの多くは似ています。
In addition to the simplified models, the following should also be considered:
単純化されたモデルに加えて、以下も考慮する必要があります。
- There are reasons, perhaps, to protect a specific P-to-P or PE-to-P.
- おそらく、特定のP-to-PまたはPE-P-to-Pを保護する理由があります。
- There may be reasons to do multiple encryptions over certain segments. One may be using an encrypted wireless link under our IPsec VPN to access an SSL-secured web site to download encrypted email attachments: four layers.)
- 特定のセグメントで複数の暗号化を行う理由があるかもしれません。IPSEC VPNの下にある暗号化されたワイヤレスリンクを使用して、SSL-SECURED Webサイトにアクセスして、暗号化された電子メール添付ファイル：4つのレイヤーをダウンロードすることができます。
- It may be appropriate that, for example, cryptographic integrity checks are applied end to end, and confidentiality is applied over a shorter span.
- たとえば、暗号化の整合性チェックが端に適用され、より短いスパンにわたって機密性が適用されることが適切かもしれません。
- Different cryptographic protection may be required for control protocols and data traffic.
- 制御プロトコルとデータトラフィックには、異なる暗号化保護が必要になる場合があります。
- Attention needs to be given to how auxiliary traffic is protected, e.g., the ICMPv6 packets that flow back during PMTU discovery, among other examples.
- 他の例の中でも、PMTU発見中に戻ってくるICMPV6パケットなど、補助トラフィックがどのように保護されているかに注意する必要があります。
Access control techniques include packet-by-packet or packet-flow-by-packet-flow access control by means of filters and firewalls on IPv4/IPv6 packets, as well as by means of admitting a "session" for a control, signaling, or management protocol. Enforcement of access control by isolated infrastructure addresses is discussed in Section 5.4 of this document.
アクセス制御手法には、IPv4/IPv6パケットのフィルターとファイアウォール、およびコントロール、シグナリング、シグナリングの「セッション」を認めることによるパケットごとのパケットまたはパケットフローごとのアクセス制御が含まれます。または管理プロトコル。このドキュメントのセクション5.4では、孤立したインフラストラクチャアドレスによるアクセス制御の実施について説明します。
In this document, we distinguish between filtering and firewalls based primarily on the direction of traffic flow. We define filtering as being applicable to unidirectional traffic, while a firewall can analyze and control both sides of a conversation.
このドキュメントでは、主にトラフィックフローの方向に基づいてフィルタリングとファイアウォールを区別します。フィルタリングは一方向のトラフィックに適用できると定義しますが、ファイアウォールは会話の両側を分析および制御できます。
The definition has two significant corollaries:
定義には2つの重要な結果があります。
- Routing or traffic flow symmetry: A firewall typically requires routing symmetry, which is usually enforced by locating a firewall where the network topology assures that both sides of a conversation will pass through the firewall. A filter can operate upon traffic flowing in one direction, without considering traffic in the reverse direction. Beware that this concept could result in a single point of failure.
- ルーティングまたはトラフィックフローの対称性：通常、ファイアウォールにはルーティング対称性が必要です。これは通常、ネットワークトポロジが会話の両側がファイアウォールを通過することを保証するファイアウォールを見つけることによって強制されます。フィルターは、逆方向のトラフィックを考慮せずに、一方向に流れるトラフィックを動作させることができます。この概念が単一の失敗ポイントをもたらす可能性があることに注意してください。
- Statefulness: Because it receives both sides of a conversation, a firewall may be able to interpret a significant amount of information concerning the state of that conversation and use this information to control access. A filter can maintain some limited state information on a unidirectional flow of packets, but cannot determine the state of the bidirectional conversation as precisely as a firewall.
- ステートフルネス：会話の両側を受け取るため、ファイアウォールはその会話の状態に関するかなりの量の情報を解釈し、この情報を使用してアクセスを制御できる場合があります。フィルターは、パケットの一方向の流れに関するいくつかの限られた状態情報を維持できますが、双方向の会話の状態をファイアウォールと同じように正確に決定することはできません。
For a general description on filtering and rate limiting for IP networks, please also see [OPSEC-FILTER].
IPネットワークのフィルタリングとレートの制限に関する一般的な説明については、[OPSEC-Filter]も参照してください。
It is relatively common for routers to filter packets. That is, routers can look for particular values in certain fields of the IP or higher-level (e.g., TCP or UDP) headers. Packets matching the criteria associated with a particular filter may either be discarded or given special treatment. Today, not only routers, but most end hosts have filters, and every instance of IPsec is also a filter [RFC4301].
ルーターがパケットをフィルタリングするのは比較的一般的です。つまり、ルーターは、IPまたは高レベル（TCPやUDPなど）のヘッダーの特定のフィールドで特定の値を探すことができます。特定のフィルターに関連付けられた基準に一致するパケットは、廃棄されるか、特別な治療が与えられる場合があります。今日、ルーターだけでなく、ほとんどのエンドホストにはフィルターがあり、IPSECのすべてのインスタンスもフィルターです[RFC4301]。
In discussing filters, it is useful to separate the filter characteristics that may be used to determine whether a packet matches a filter from the packet actions applied to those packets matching a particular filter.
フィルターの議論では、パケットが特定のフィルターに一致するパケットに適用されるパケットアクションからフィルターを一致させるかどうかを判断するために使用できるフィルター特性を分離することが役立ちます。
o Filter Characteristics
o フィルター特性
Filter characteristics or rules are used to determine whether a particular packet or set of packets matches a particular filter.
フィルターの特性またはルールは、特定のパケットまたはパケットのセットが特定のフィルターと一致するかどうかを判断するために使用されます。
In many cases, filter characteristics may be stateless. A stateless filter determines whether a particular packet matches a filter based solely on the filter definition, normal forwarding information (such as the next hop for a packet), the interface on which a packet arrived, and the contents of that individual packet. Typically, stateless filters may consider the incoming and outgoing logical or physical interface, information in the IP header, and information in higher-layer headers such as the TCP or UDP header. Information in the IP header to be considered may for example include source and destination IP addresses; Protocol field, Fragment Offset, and TOS field in IPv4; or Next Header, Extension Headers, Flow label, etc. in IPv6. Filters also may consider fields in the TCP or UDP header such as the Port numbers, the SYN field in the TCP header, as well as ICMP and ICMPv6 type.
多くの場合、フィルターの特性はステートレスになる場合があります。ステートレスフィルターは、特定のパケットがフィルター定義、通常の転送情報（パケットの次のホップなど）のみに基づいてフィルターと一致するかどうか、パケットが到着したインターフェイス、およびその個々のパケットの内容を決定します。通常、ステートレスフィルターは、着信と発信の論理または物理インターフェイス、IPヘッダーの情報、およびTCPやUDPヘッダーなどの高層ヘッダーの情報を考慮する場合があります。考慮されるIPヘッダーの情報は、たとえば、ソースおよび宛先IPアドレスを含めることができます。IPv4のプロトコルフィールド、フラグメントオフセット、およびTOSフィールド。またはIPv6の次のヘッダー、拡張ヘッダー、フローラベルなど。また、フィルターは、ポート番号、TCPヘッダーのSynフィールド、ICMPおよびICMPV6タイプなど、TCPまたはUDPヘッダーのフィールドを考慮することもできます。
Stateful filtering maintains packet-specific state information to aid in determining whether a filter rule has been met. For example, a device might apply stateless filtering to the first fragment of a fragmented IPv4 packet. If the filter matches, then the data unit ID may be remembered and other fragments of the same packet may then be considered to match the same filter. Stateful filtering is more commonly done in firewalls, although firewall technology may be added to routers. The data unit ID can also be a Fragment Extension Header Identification field in IPv6.
ステートフルフィルタリングは、フィルタールールが満たされているかどうかを判断するのに役立つパケット固有の状態情報を維持します。たとえば、デバイスは、断片化されたIPv4パケットの最初のフラグメントにステートレスフィルタリングを適用する場合があります。フィルターが一致する場合、データユニットIDが記憶され、同じパケットの他のフラグメントが同じフィルターに一致すると見なされる場合があります。ステートフルフィルタリングは、ファイアウォールでより一般的に行われますが、ファイアウォールテクノロジーがルーターに追加される場合があります。データユニットIDは、IPv6のフラグメントエクステンションヘッダー識別フィールドでもあります。
o Actions based on Filter Results
o フィルターの結果に基づくアクション
If a packet, or a series of packets, matches a specific filter, then a variety of actions may be taken based on that match. Examples of such actions include:
パケット、または一連のパケットが特定のフィルターと一致する場合、その一致に基づいてさまざまなアクションが実行される場合があります。そのような行動の例は次のとおりです。
- Discard
- 破棄
In many cases, filters are set to catch certain undesirable packets. Examples may include packets with forged or invalid source addresses, packets that are part of a DoS or Distributed DoS (DDoS) attack, or packets trying to access unallowed resources (such as network management packets from an unauthorized source). Where such filters are activated, it is common to discard the packet or set of packets matching the filter silently. The discarded packets may of course also be counted or logged.
多くの場合、特定の望ましくないパケットをキャッチするようにフィルターが設定されています。例には、偽造または無効なソースアドレスを備えたパケット、DOSまたは分散DOS（DDO）攻撃の一部であるパケット、または許可されていないリソースにアクセスしようとするパケット（不正なソースからのネットワーク管理パケットなど）が含まれます。そのようなフィルターがアクティブ化されている場合、フィルターに一致するパケットまたはパケットのセットを静かに破棄することが一般的です。もちろん、廃棄されたパケットもカウントまたは記録される場合があります。
- Set CoS
- cosを設定します
A filter may be used to set the class of service associated with the packet.
フィルターを使用して、パケットに関連付けられたサービスのクラスを設定できます。
- Count packets or bytes
- パケットまたはバイトをカウントします
- Rate Limit
- レート制限
In some cases, the set of packets matching a particular filter may be limited to a specified bandwidth. In this case, packets or bytes would be counted, and would be forwarded normally up to the specified limit. Excess packets may be discarded or may be marked (for example, by setting a "discard eligible" bit in the IPv4 ToS field, or changing the EXP value to identify traffic as being out of contract).
場合によっては、特定のフィルターに一致するパケットのセットは、指定された帯域幅に制限される場合があります。この場合、パケットまたはバイトがカウントされ、通常は指定された制限まで転送されます。余分なパケットが廃棄されるか、マークされる場合があります（たとえば、IPv4 TOSフィールドに「適格な」ビットを設定するか、EXP値を変更してトラフィックを契約外であると識別することにより）。
- Forward and Copy
- 転送とコピー
It is useful in some cases to forward some set of packets normally, but also to send a copy to a specified other address or interface. For example, this may be used to implement a lawful intercept capability or to feed selected packets to an Intrusion Detection System.
場合によっては、一部のパケットセットを正常に転送するだけでなく、指定された他のアドレスまたはインターフェイスにコピーを送信することも役立ちます。たとえば、これは合法的な傍受機能を実装したり、選択したパケットを侵入検知システムに送ったりするために使用できます。
o Other Packet Filters Issues
o その他のパケットフィルターの問題
Filtering performance may vary widely according to implementation and the types and number of rules. Without acceptable performance, filtering is not useful.
フィルタリングパフォーマンスは、実装とルールの種類と数に応じて大きく異なる場合があります。許容可能なパフォーマンスがなければ、フィルタリングは役に立ちません。
The precise definition of "acceptable" may vary from SP to SP, and may depend upon the intended use of the filters. For example, for some uses, a filter may be turned on all the time to set CoS, to prevent an attack, or to mitigate the effect of a possible future attack. In this case, it is likely that the SP will want the filter to have minimal or no impact on performance. In other cases, a filter may be turned on only in response to a major attack (such as a major DDoS attack). In this case, a greater performance impact may be acceptable to some service providers.
「許容可能な」の正確な定義はSPによって異なる場合があり、フィルターの使用意図に依存する場合があります。たとえば、一部の用途では、COSを設定したり、攻撃を防ぎ、将来の攻撃の可能性の影響を軽減するために、常にフィルターをオンにすることができます。この場合、SPはフィルターにパフォーマンスに最小限の影響を与えるか、影響を与えないことを望んでいる可能性があります。それ以外の場合、フィルターは、主要な攻撃（主要なDDOS攻撃など）に応じてのみオンにすることができます。この場合、一部のサービスプロバイダーにはパフォーマンスへの影響が大きくなる可能性があります。
A key consideration with the use of packet filters is that they can provide few options for filtering packets carrying encrypted data. Because the data itself is not accessible, only packet header information or other unencrypted fields can be used for filtering.
パケットフィルターの使用に関する重要な考慮事項は、暗号化されたデータを運ぶパケットをフィルタリングするためのオプションがほとんどないことです。データ自体にアクセスできないため、パケットヘッダー情報または他の暗号化されていないフィールドのみをフィルタリングに使用できます。
Firewalls provide a mechanism for controlling traffic passing between different trusted zones in the MPLS/GMPLS model or between a trusted zone and an untrusted zone. Firewalls typically provide much more functionality than filters, because they may be able to apply detailed analysis and logical functions to flows, and not just to individual packets. They may offer a variety of complex services, such as threshold-driven DoS attack protection, virus scanning, acting as a TCP connection proxy, etc.
ファイアウォールは、MPLS/GMPLSモデルまたは信頼できるゾーンと信頼できないゾーンの間で信頼できるゾーン間を通過するトラフィックを制御するメカニズムを提供します。ファイアウォールは通常、フィルターよりもはるかに多くの機能を提供します。これは、個々のパケットだけでなく、流れに詳細な分析と論理関数を適用できる可能性があるためです。しきい値駆動型のDOS攻撃保護、ウイルススキャン、TCP接続プロキシとして機能するなど、さまざまな複雑なサービスを提供する場合があります。
As with other access control techniques, the value of firewalls depends on a clear understanding of the topologies of the MPLS/GMPLS core network, the user networks, and the threat model. Their effectiveness depends on a topology with a clearly defined inside (secure) and outside (not secure).
他のアクセス制御手法と同様に、ファイアウォールの価値は、MPLS/GMPLSコアネットワーク、ユーザーネットワーク、および脅威モデルのトポロジの明確な理解に依存します。それらの有効性は、内部（安全）および外側（安全ではない）を明確に定義されたトポロジーに依存します。
Firewalls may be applied to help protect MPLS/GMPLS core network functions from attacks originating from the Internet or from MPLS/GMPLS user sites, but typically other defensive techniques will be used for this purpose.
ファイアウォールは、インターネットまたはMPLS/GMPLSユーザーサイトから発生する攻撃からMPLS/GMPLSコアネットワーク関数を保護するために適用できますが、通常、この目的には他の防御技術が使用されます。
Where firewalls are employed as a service to protect user VPN sites from the Internet, different VPN users, and even different sites of a single VPN user, may have varying firewall requirements. The overall PPVPN logical and physical topology, along with the capabilities of the devices implementing the firewall services, has a significant effect on the feasibility and manageability of such varied firewall service offerings.
ファイアウォールがインターネットからユーザーVPNサイトを保護するサービスとして採用されている場合、異なるVPNユーザー、さらには1つのVPNユーザーの異なるサイトでさえ、ファイアウォール要件が異なる場合があります。全体的なPPVPN論理的および物理的トポロジは、ファイアウォールサービスを実装するデバイスの機能とともに、このようなさまざまなファイアウォールサービスの提供の実現可能性と管理性に大きな影響を及ぼします。
Another consideration with the use of firewalls is that they can provide few options for handling packets carrying encrypted data. Because the data itself is not accessible, only packet header information, other unencrypted fields, or analysis of the flow of encrypted packets can be used for making decisions on accepting or rejecting encrypted traffic.
ファイアウォールの使用に関するもう1つの考慮事項は、暗号化されたデータを運ぶパケットを処理するためのオプションがほとんどないことです。データ自体にアクセスできないため、暗号化されたパケットの流れのパケットヘッダー情報、その他の暗号化されていないフィールドのみ、または暗号化されたトラフィックの受け入れまたは拒否を決定するために使用できます。
Two approaches of using firewalls are to move the firewall outside of the encrypted part of the path or to register and pre-approve the encrypted session with the firewall.
ファイアウォールを使用する2つのアプローチは、パスの暗号化された部分の外側にファイアウォールを移動するか、ファイアウォールで暗号化されたセッションを登録して事前に承認することです。
Handling DoS attacks has become increasingly important. Useful guidelines include the following:
DOS攻撃の処理はますます重要になっています。有用なガイドラインには、以下が含まれます。
1. Perform ingress filtering everywhere.
1. どこでもイングレスフィルタリングを実行します。
2. Be able to filter DoS attack packets at line speed.
2. ライン速度でDOS攻撃パケットをフィルタリングできるようにします。
3. Do not allow oneself to amplify attacks.
3. 攻撃を増幅することを許可しないでください。
4. Continue processing legitimate traffic. Over provide for heavy loads. Use diverse locations, technologies, etc.
4. 正当なトラフィックの処理を続けます。重い負荷を供給しています。多様な場所、テクノロジーなどを使用してください。
Most of the security issues related to management interfaces can be addressed through the use of authentication techniques as described in the section on authentication (Section 5.1). However, additional security may be provided by controlling access to management interfaces in other ways.
管理インターフェイスに関連するセキュリティ問題のほとんどは、認証に関するセクション（セクション5.1）で説明されているように、認証手法の使用を通じて対処できます。ただし、他の方法で管理インターフェイスへのアクセスを制御することにより、追加のセキュリティが提供される場合があります。
The Optical Internetworking Forum has done relevant work on protecting such interfaces with TLS, SSH, Kerberos, IPsec, WSS, etc. See "Security for Management Interfaces to Network Elements" [OIF-SMI-01.0] and "Addendum to the Security for Management Interfaces to Network Elements" [OIF-SMI-02.1]. See also the work in the ISMS WG (http://datatracker.ietf.org/wg/isms/charter/).
Optical InternetWorkingフォーラムは、TLS、SSH、Kerberos、IPSEC、WSSなどのこのようなインターフェイスを保護することに関連する作業を行っています。ネットワーク要素へのインターフェイス "[oif-smi-02.1]。ISMS WG（http://datatracker.ietf.org/wg/isms/charter/）の作業も参照してください。
Management interfaces, especially console ports on MPLS/GMPLS devices, may be configured so they are only accessible out-of-band, through a system that is physically or logically separated from the rest of the MPLS/GMPLS infrastructure.
管理インターフェイス、特にMPL/GMPLSデバイスのコンソールポートは、MPLS/GMPLSインフラストラクチャの残りの部分から物理的または論理的に分離されたシステムを介して、帯域外でのみアクセスできるように構成できます。
Where management interfaces are accessible in-band within the MPLS/GMPLS domain, filtering or firewalling techniques can be used to restrict unauthorized in-band traffic from having access to management interfaces. Depending on device capabilities, these filtering or firewalling techniques can be configured either on other devices through which the traffic might pass, or on the individual MPLS/GMPLS devices themselves.
MPLS/GMPLSドメイン内の管理インターフェイスがインターフェイスにアクセス可能なインバンドである場合、フィルタリングまたはファイアウォール技術を使用して、不正なインターフェイスにアクセスすることを許可されていないバンドイントラフィックを制限できます。デバイス機能に応じて、これらのフィルタリングまたはファイアウォール手法は、トラフィックが通過する可能性のある他のデバイス、または個々のMPLS/GMPLSデバイス自体のいずれかで構成できます。
One way to protect the infrastructure used for support of MPLS/GMPLS is to separate the resources for support of MPLS/GMPLS services from the resources used for other purposes (such as support of Internet services). In some cases, this may involve using physically separate equipment for VPN services, or even a physically separate network.
MPLS/GMPLSのサポートに使用されるインフラストラクチャを保護する1つの方法は、MPLS/GMPLSサービスのサポートのためにリソースを他の目的（インターネットサービスのサポートなど）に使用するリソースから分離することです。場合によっては、これには、VPNサービスに物理的に個別の機器を使用するか、物理的に個別のネットワークを使用することが含まれる場合があります。
For example, PE-based IPVPNs may be run on a separate backbone not connected to the Internet, or may use separate edge routers from those supporting Internet service. Private IPv4 addresses (local to the provider and non-routable over the Internet) are sometimes used to provide additional separation. For a discussion of comparable techniques for IPv6, see "Local Network Protection for IPv6," RFC 4864 [RFC4864].
たとえば、PEベースのIPVPNは、インターネットに接続されていない別のバックボーンで実行される場合や、インターネットサービスをサポートするものと個別のエッジルーターを使用する場合があります。プライベートIPv4アドレス（プロバイダーにローカル、インターネット上では不可能）が追加されるために使用されることがあります。IPv6の同等の手法の議論については、「IPv6のローカルネットワーク保護」、RFC 4864 [RFC4864]を参照してください。
In a GMPLS network, it is possible to operate the control plane using physically separate resources from those used for the data plane. This means that the data-plane resources can be physically protected and isolated from other equipment to protect users' data while the control and management traffic uses network resources that can be accessed by operators to configure the network. Conversely, the separation of control and data traffic may lead the operator to consider that the network is secure because the data-plane resources are physically secure. However, this is not the case if the control plane can be attacked through a shared or open network, and control-plane protection techniques must still be applied.
GMPLSネットワークでは、データプレーンに使用されているリソースと物理的に個別のリソースを使用してコントロールプレーンを操作することができます。これは、データプレーンのリソースを物理的に保護および他の機器から分離してユーザーのデータを保護できることを意味し、制御および管理トラフィックは、オペレーターがアクセスしてネットワークを構成できるネットワークリソースを使用します。逆に、データプレーンリソースが物理的に安全であるため、制御とデータトラフィックの分離により、オペレーターはネットワークが安全であると考えるようになります。ただし、これは、共有またはオープンなネットワークを介してコントロールプレーンを攻撃できる場合ではなく、コントロールプレーン保護技術を適用する必要があります。
In general, it is not feasible to use a completely separate set of resources for support of each service. In fact, one of the main reasons for MPLS/GMPLS enabled services is to allow sharing of resources between multiple services and multiple users. Thus, even if certain services use a separate network from Internet services, nonetheless there will still be multiple MPLS/GMPLS users sharing the same network resources. In some cases, MPLS/GMPLS services will share network resources with Internet services or other services.
一般に、各サービスをサポートするために完全に個別のリソースセットを使用することは実現可能ではありません。実際、MPLS/GMPLS対応サービスの主な理由の1つは、複数のサービスと複数のユーザー間でリソースを共有できるようにすることです。したがって、特定のサービスがインターネットサービスから個別のネットワークを使用している場合でも、それでも同じネットワークリソースを共有する複数のMPLS/GMPLSユーザーが存在します。場合によっては、MPLS/GMPLSサービスは、インターネットサービスまたは他のサービスとネットワークリソースを共有します。
It is therefore important for MPLS/GMPLS services to provide protection between resources used by different parties. Thus, a well-behaved MPLS/GMPLS user should be protected from possible misbehavior by other users. This requires several security measurements to be implemented. Resource limits can be placed on a per service and per user basis. Possibilities include, for example, using a virtual router or logical router to define hardware or software resource limits per service or per individual user; using rate limiting per Virtual Routing and Forwarding (VRF) or per Internet connection to provide bandwidth protection; or using resource reservation for control-plane traffic. In addition to bandwidth protection, separate resource allocation can be used to limit security attacks only to directly impacted service(s) or customer(s). Strict, separate, and clearly defined engineering rules and provisioning procedures can reduce the risks of network-wide impact of a control-plane attack, DoS attack, or misconfiguration.
したがって、MPLS/GMPLSサービスがさまざまな関係者が使用するリソース間の保護を提供することが重要です。したがって、行儀の良いMPLS/GMPLSユーザーは、他のユーザーによって不正行為の可能性から保護される必要があります。これには、いくつかのセキュリティ測定値を実装する必要があります。リソース制限は、サービスごとに、ユーザーごとに配置できます。可能性には、たとえば、仮想ルーターまたは論理ルーターを使用して、サービスまたは個々のユーザーごとのハードウェアまたはソフトウェアリソースの制限を定義することが含まれます。仮想ルーティングと転送（VRF）またはインターネット接続ごとのレート制限を使用して、帯域幅保護を提供します。または、コントロールプレーントラフィックにリソース予約を使用します。帯域幅保護に加えて、個別のリソース割り当てを使用して、セキュリティ攻撃を制限して直接影響を受けるサービスまたは顧客のみを制限できます。厳密で明確に定義されたエンジニアリングルールとプロビジョニング手順は、コントロールプレーン攻撃、DOS攻撃、または誤解のネットワーク全体の影響のリスクを減らすことができます。
In general, the use of aggregated infrastructure allows the service provider to benefit from stochastic multiplexing of multiple bursty flows, and also may in some cases thwart traffic pattern analysis by combining the data from multiple users. However, service providers must minimize security risks introduced from any individual service or individual users.
一般に、集約されたインフラストラクチャを使用すると、サービスプロバイダーは複数のバーストフローの確率的多重化の恩恵を受けることができ、場合によっては複数のユーザーからのデータを組み合わせることでトラフィックパターン分析を阻止できます。ただし、サービスプロバイダーは、個々のサービスまたは個々のユーザーから導入されたセキュリティリスクを最小限に抑える必要があります。
Deployment of provider-provisioned VPN services in general requires a relatively large amount of configuration by the SP. For example, the SP needs to configure which VPN each site belongs to, as well as QoS and SLA guarantees. This large amount of required configuration leads to the possibility of misconfiguration.
一般に、プロバイダーがプロビジョニングしたVPNサービスの展開には、SPによって比較的大量の構成が必要です。たとえば、SPは、各サイトが属するVPN、およびQoSおよびSLA保証を構成する必要があります。この大量の必要な構成は、誤解の可能性につながります。
It is important for the SP to have operational processes in place to reduce the potential impact of misconfiguration. CE-to-CE authentication may also be used to detect misconfiguration when it occurs. CE-to-CE encryption may also limit the damage when misconfiguration occurs.
SPが、誤った構成の潜在的な影響を減らすために、運用プロセスを実施することが重要です。CE-CE-CEの認証を使用して、発生したときに誤解を検出することもできます。CE-CE-CEの暗号化は、誤った構成が発生したときに損傷を制限する場合があります。
This refers to solutions that can be readily tested to make sure they are configured correctly. For example, for a point-to-point connection, checking that the intended connectivity is working pretty much ensures that there is no unintended connectivity to some other site.
これは、それらが正しく構成されていることを確認するために容易にテストできるソリューションを指します。たとえば、ポイントツーポイント接続の場合、意図した接続性が機能していることを確認すると、他のサイトへの意図しない接続がないことが保証されます。
In order to protect against deliberate or accidental misconnection, mechanisms can be put in place to verify both end-to-end connectivity and hop-by-hop resources. These mechanisms can trace the routes of LSPs in both the control plane and the data plane.
意図的または偶発的な誤解から保護するために、エンドツーエンドの接続とホップバイホップリソースの両方を検証するために、メカニズムを導入できます。これらのメカニズムは、コントロールプレーンとデータプレーンの両方でLSPのルートを追跡できます。
It should be noted that if there is an attack on the control plane, data-plane connectivity test mechanisms that rely on the control plane can also be attacked. This may hide faults through false positives or disrupt functioning services through false negatives.
コントロールプレーンに攻撃がある場合、コントロールプレーンに依存するデータ平面接続テストメカニズムも攻撃できることに注意する必要があります。これにより、誤検知を介して障害を隠すか、誤ったネガを介して機能サービスを破壊する可能性があります。
MPLS/GMPLS network and service may be subject to attacks from a variety of security threats. Many threats are described in Section 4 of this document. Many of the defensive techniques described in this document and elsewhere provide significant levels of protection from a variety of threats. However, in addition to employing defensive techniques silently to protect against attacks, MPLS/GMPLS services can also add value for both providers and customers by implementing security monitoring systems to detect and report on any security attacks, regardless of whether the attacks are effective.
MPLS/GMPLSネットワークとサービスは、さまざまなセキュリティの脅威からの攻撃の対象となる場合があります。多くの脅威については、このドキュメントのセクション4で説明しています。この文書や他の場所で説明されている防御技術の多くは、さまざまな脅威からの大幅なレベルの保護を提供します。ただし、攻撃から保護するために静かに防御技術を採用することに加えて、MPLS/GMPLSサービスは、攻撃が効果的かどうかに関係なく、セキュリティ攻撃を検出および報告するセキュリティ監視システムを実装することにより、プロバイダーと顧客の両方に価値を追加することもできます。
Attackers often begin by probing and analyzing defenses, so systems that can detect and properly report these early stages of attacks can provide significant benefits.
攻撃者は多くの場合、防御を調査および分析することから始めます。そのため、これらの初期段階の攻撃段階を検出して適切に報告できるシステムは、大きな利益をもたらす可能性があります。
Information concerning attack incidents, especially if available quickly, can be useful in defending against further attacks. It can be used to help identify attackers or their specific targets at an early stage. This knowledge about attackers and targets can be used to strengthen defenses against specific attacks or attackers, or to improve the defenses for specific targets on an as-needed basis. Information collected on attacks may also be useful in identifying and developing defenses against novel attack types.
攻撃事件に関する情報は、特に迅速に利用可能な場合は、さらなる攻撃から防御するのに役立ちます。初期段階で攻撃者または特定のターゲットを特定するのに役立つために使用できます。攻撃者とターゲットに関するこの知識を使用して、特定の攻撃や攻撃者に対する防御を強化したり、必要に応じて特定のターゲットの防御を改善することができます。攻撃で収集された情報は、新しい攻撃タイプに対する防御の特定と開発にも役立つ場合があります。
Monitoring systems used to detect security attacks in MPLS/GMPLS typically operate by collecting information from the Provider Edge (PE), Customer Edge (CE), and/or Provider backbone (P) devices. Security monitoring systems should have the ability to actively retrieve information from devices (e.g., SNMP get) or to passively receive reports from devices (e.g., SNMP notifications). The systems may actively retrieve information from devices (e.g., SNMP get) or passively receive reports from devices (e.g., SNMP notifications).
MPLS/GMPLのセキュリティ攻撃を検出するために使用される監視システムは、通常、プロバイダーEdge（PE）、顧客エッジ（CE）、および/またはプロバイダーバックボーン（P）デバイスから情報を収集することにより動作します。セキュリティ監視システムには、デバイスから情報を積極的に取得（SNMP GETなど）を積極的に取得するか、デバイスからレポート（SNMP通知など）を受動的に受信することができます。システムは、デバイスから情報を積極的に取得する（SNMP GETなど）、またはデバイスからレポートを受動的に受信する場合があります（SNMP通知など）。
The specific information exchanged depends on the capabilities of the devices and on the type of VPN technology. Particular care should be given to securing the communications channel between the monitoring systems and the MPLS/GMPLS devices.
交換される特定の情報は、デバイスの機能とVPNテクノロジーのタイプに依存します。監視システムとMPLS/GMPLSデバイスの間の通信チャネルを保護することには、特に注意が必要です。
The CE, PE, and P devices should employ efficient methods to acquire and communicate the information needed by the security monitoring systems. It is important that the communication method between MPLS/GMPLS devices and security monitoring systems be designed so that it will not disrupt network operations. As an example, multiple attack events may be reported through a single message, rather than allowing each attack event to trigger a separate message, which might result in a flood of messages, essentially becoming a DoS attack against the monitoring system or the network.
CE、PE、およびPデバイスは、セキュリティ監視システムが必要とする情報を取得および通信するための効率的な方法を採用する必要があります。MPLS/GMPLSデバイスとセキュリティ監視システム間の通信方法を設計して、ネットワーク操作を破壊しないように設計することが重要です。例として、各攻撃イベントが個別のメッセージをトリガーすることを許可するのではなく、単一のメッセージを通じて複数の攻撃イベントを報告することができます。これにより、メッセージの洪水が発生し、本質的に監視システムまたはネットワークに対するDOS攻撃になります。
The mechanisms for reporting security attacks should be flexible enough to meet the needs of MPLS/GMPLS service providers, MPLS/GMPLS customers, and regulatory agencies, if applicable. The specific reports should depend on the capabilities of the devices, the security monitoring system, the type of VPN, and the service level agreements between the provider and customer.
セキュリティ攻撃を報告するためのメカニズムは、該当する場合、MPLS/GMPLSサービスプロバイダー、MPLS/GMPLSの顧客、規制機関のニーズを満たすのに十分な柔軟性が必要です。特定のレポートは、デバイスの機能、セキュリティ監視システム、VPNのタイプ、およびプロバイダーと顧客の間のサービスレベル契約に依存する必要があります。
While SNMP/syslog type monitoring and detection mechanisms can detect some attacks (usually resulting from flapping protocol adjacencies, CPU overload scenarios, etc.), other techniques, such as netflow-based traffic fingerprinting, are needed for more detailed detection and reporting.
SNMP/syslogタイプの監視および検出メカニズムは、いくつかの攻撃（通常、プロトコルの隣接、CPU過負荷シナリオなどから生じる）を検出できますが、Netflowベースのトラフィック指紋などの他の手法は、より詳細な検出と報告に必要です。
With netflow-based traffic fingerprinting, each packet that is forwarded within a device is examined for a set of IP packet attributes. These attributes are the IP packet identity or fingerprint of the packet and determine if the packet is unique or similar to other packets.
Netflowベースのトラフィックフィンガープリントにより、デバイス内に転送される各パケットは、一連のIPパケット属性について調べられます。これらの属性は、パケットのIPパケットIDまたは指紋であり、パケットが他のパケットと一意か類似しているかどうかを判断します。
The flow information is extremely useful for understanding network behavior, and detecting and reporting security attacks:
フロー情報は、ネットワークの動作を理解し、セキュリティ攻撃を検出および報告するのに非常に役立ちます。
- Source address allows the understanding of who is originating the traffic.
- ソースアドレスは、誰がトラフィックを発信しているかを理解することができます。
- Destination address tells who is receiving the traffic.
- 宛先アドレスは、誰がトラフィックを受け取っているかを示します。
- Ports characterize the application utilizing the traffic.
- ポートは、トラフィックを利用してアプリケーションを特徴付けます。
- Class of service examines the priority of the traffic.
- サービスのクラスは、トラフィックの優先順位を調べます。
- The device interface tells how traffic is being utilized by the network device.
- デバイスインターフェイスは、ネットワークデバイスによってトラフィックがどのように使用されているかを示しています。
- Tallied packets and bytes show the amount of traffic.
- 集計されたパケットとバイトは、トラフィックの量を示しています。
- Flow timestamps allow the understanding of the life of a flow; timestamps are useful for calculating packets and bytes per second.
- フロータイムスタンプは、流れの寿命を理解することを可能にします。タイムスタンプは、パケットとバイトの計算に役立ちます。
- Next-hop IP addresses including BGP routing Autonomous Systems (ASes).
- BGPルーティング自律システム（ASES）を含むNext-Hop IPアドレス。
- Subnet mask for the source and destination addresses are for calculating prefixes.
- ソースおよび宛先アドレスのサブネットマスクは、プレフィックスを計算するためのものです。
- TCP flags are useful for examining TCP handshakes.
- TCPフラグは、TCPの握手を調べるのに役立ちます。
This section covers security requirements the provider may have for securing its MPLS/GMPLS network infrastructure including LDP and RSVP-TE-specific requirements.
このセクションでは、プロバイダーがLDPおよびRSVP-TE固有の要件を含むMPLS/GMPLSネットワークインフラストラクチャを保護するためのセキュリティ要件をカバーしています。
The MPLS/GMPLS service provider's requirements defined here are for the MPLS/GMPLS core in the reference model. The core network can be implemented with different types of network technologies, and each core network may use different technologies to provide the various services to users with different levels of offered security. Therefore, an MPLS/GMPLS service provider may fulfill any number of the security requirements listed in this section. This document does not state that an MPLS/GMPLS network must fulfill all of these requirements to be secure.
ここで定義されているMPLS/GMPLSサービスプロバイダーの要件は、参照モデルのMPLS/GMPLSコア用です。コアネットワークは、さまざまなタイプのネットワークテクノロジーで実装でき、各コアネットワークは異なるテクノロジーを使用して、さまざまなレベルの提供されたセキュリティを持つさまざまなサービスをユーザーに提供する場合があります。したがって、MPLS/GMPLSサービスプロバイダーは、このセクションにリストされているセキュリティ要件の任意の数を満たすことができます。このドキュメントでは、MPLS/GMPLSネットワークがこれらの要件をすべて確保する必要があるとは述べていません。
These requirements are focused on: 1) how to protect the MPLS/GMPLS core from various attacks originating outside the core including those from network users, both accidentally and maliciously, and 2) how to protect the end users.
これらの要件は、1）ネットワークユーザーからのものを含むコアの外側のさまざまな攻撃からMPLS/GMPLSコアを偶然および悪意を持って保護する方法、および2）エンドユーザーを保護する方法に焦点を当てています。
- Filtering spoofed infrastructure IP addresses at edges
- エッジでスプーフィングされたインフラストラクチャIPアドレスをフィルタリングします
Many attacks on protocols running in a core involve spoofing a source IP address of a node in the core (e.g., TCP-RST attacks). It makes sense to apply anti-spoofing filtering at edges, e.g., using strict unicast reverse path forwarding (uRPF) [RFC3704] and/or by preventing the use of infrastructure addresses as source. If this is done comprehensively, the need to cryptographically secure these protocols is smaller. See [BACKBONE-ATTKS] for more elaborate description.
コアで実行されるプロトコルに対する多くの攻撃には、コア内のノードのソースIPアドレスをスプーフィングすることが含まれます（たとえば、TCP-RST攻撃）。エッジでアンチスポーフフィルタリングを適用することは理にかなっています。たとえば、厳密なユニキャスト逆パス転送（URPF）[RFC3704]を使用したり、インフラストラクチャアドレスをソースとして使用したりすることを防ぐことで理にかなっています。これが包括的に行われると、これらのプロトコルを暗号化する必要性は小さくなります。詳細な説明については、[Backbone-attks]を参照してください。
- Protocol authentication within the core
- コア内のプロトコル認証
The network infrastructure must support mechanisms for authentication of the control-plane messages. If an MPLS/GMPLS core is used, LDP sessions may be authenticated with TCP MD5. In addition, IGP and BGP authentication should be considered. For a core providing various IP, VPN, or transport services, PE-to-PE authentication may also be performed via IPsec. See the above discussion of protocol security services: authentication, integrity (with replay detection), and confidentiality. Protocols need to provide a complete set of security services from which the SP can choose. Also, the important but often more difficult part is key management. Considerations, guidelines, and strategies regarding key management are discussed in [RFC3562], [RFC4107], [RFC4808].
ネットワークインフラストラクチャは、コントロールプレーンメッセージの認証のメカニズムをサポートする必要があります。MPLS/GMPLSコアを使用する場合、LDPセッションはTCP MD5で認証される場合があります。さらに、IGPおよびBGP認証を考慮する必要があります。さまざまなIP、VPN、またはトランスポートサービスを提供するコアの場合、PE-PE認証もIPSECを介して実行できます。プロトコルセキュリティサービスの上記の説明：認証、整合性（リプレイ検出付き）、および機密性を参照してください。プロトコルは、SPが選択できるセキュリティサービスの完全なセットを提供する必要があります。また、重要であるがしばしばより難しい部分は、重要な管理です。主要な管理に関する考慮事項、ガイドライン、および戦略については、[RFC3562]、[RFC4107]、[RFC4808]で説明しています。
With today's processors, applying cryptographic authentication to the control plane may not increase the cost of deployment for providers significantly, and will help to improve the security of the core. If the core is dedicated to MPLS/GMPLS enabled services without any interconnects to third parties, then this may reduce the requirement for authentication of the core control plane.
今日のプロセッサを使用すると、制御プレーンに暗号化認証を適用すると、プロバイダーの展開コストが大幅に増加しない可能性があり、コアのセキュリティの改善に役立ちます。コアがMPLS/GMPLS有効なサービスに専念している場合、サードパーティとの相互接続なしでサービスを有効にすると、これにより、コア制御プレーンの認証の要件が削減される可能性があります。
- Infrastructure Hiding
- インフラストラクチャが隠れています
Here we discuss means to hide the provider's infrastructure nodes. An MPLS/GMPLS provider may make its infrastructure routers (P and PE) unreachable from outside users and unauthorized internal users. For example, separate address space may be used for the infrastructure loopbacks.
ここでは、プロバイダーのインフラストラクチャノードを非表示にする手段について説明します。MPLS/GMPLSプロバイダーは、外部ユーザーおよび不正な内部ユーザーからインフラストラクチャルーター（PおよびPE）を到達できないようにすることができます。たとえば、インフラストラクチャループバックには、個別のアドレススペースを使用できます。
Normal TTL propagation may be altered to make the backbone look like one hop from the outside, but caution needs to be taken for loop prevention. This prevents the backbone addresses from being exposed through trace route; however, this must also be assessed against operational requirements for end-to-end fault tracing.
バックボーンを外部から1回のホップのように見せるために、通常のTTL伝播を変更する場合がありますが、ループ予防には注意する必要があります。これにより、バックボーンアドレスがトレースルートを介して公開されないようにします。ただし、これは、エンドツーエンド障害追跡の運用要件に対しても評価する必要があります。
An Internet backbone core may be re-engineered to make Internet routing an edge function, for example, by using MPLS label switching for all traffic within the core and possibly making the Internet a VPN within the PPVPN core itself. This helps to detach Internet access from PPVPN services.
たとえば、インターネットルーティングをエッジ関数にするために、インターネットバックボーンコアを再設計することができます。たとえば、コア内のすべてのトラフィックのMPLSラベルスイッチングを使用し、場合によってはインターネットをPPVPNコア自体内のVPNにすることにより。これにより、PPVPNサービスからインターネットアクセスを取り外すのに役立ちます。
Separating control-plane, data-plane, and management-plane functionality in hardware and software may be implemented on the PE devices to improve security. This may help to limit the problems when attacked in one particular area, and may allow each plane to implement additional security measures separately.
ハードウェアとソフトウェアのコントロールプレーン、データプレーン、および管理面の機能を分離して、セキュリティを改善するためにPEデバイスに実装できます。これは、特定の領域で攻撃されたときに問題を制限するのに役立つ可能性があり、各飛行機が追加のセキュリティ対策を個別に実装できるようにする可能性があります。
PEs are often more vulnerable to attack than P routers, because PEs cannot be made unreachable from outside users by their very nature. Access to core trunk resources can be controlled on a per-user basis by using of inbound rate limiting or traffic shaping; this can be further enhanced on a per-class-of-service basis (see Section 8.2.3)
PESは、PESを外部ユーザーから到達できないようにすることができないため、PESよりも攻撃に対して脆弱なことがよくあります。コアトランクリソースへのアクセスは、インバウンドレートの制限またはトラフィックシェーピングを使用して、ユーザーごとに制御できます。これは、サービスごとのサービスベースでさらに強化できます（セクション8.2.3を参照）
In the PE, using separate routing processes for different services, for example, Internet and PPVPN service, may help to improve the PPVPN security and better protect VPN customers. Furthermore, if resources, such as CPU and memory, can be further separated based on applications, or even individual VPNs, it may help to provide improved security and reliability to individual VPN customers.
PEでは、インターネットやPPVPNサービスなど、さまざまなサービスに個別のルーティングプロセスを使用すると、PPVPNセキュリティの改善とVPN顧客の保護が向上する可能性があります。さらに、CPUやメモリなどのリソースをアプリケーション、または個々のVPNに基づいてさらに分離できる場合、個々のVPN顧客にセキュリティと信頼性の向上を提供するのに役立つ場合があります。
- General RSVP Security Tools
- 一般的なRSVPセキュリティツール
Isolation of the trusted domain is an important security mechanism for RSVP, to ensure that an untrusted element cannot access a router of the trusted domain. However, ASBR-ASBR communication for inter-AS LSPs needs to be secured specifically. Isolation mechanisms might also be bypassed by an IPv4 Router Alert or IPv6 using Next Header 0 packets. A solution could consist of disabling the processing of IP options. This drops or ignores all IP packets with IPv4 options, including the router alert option used by RSVP; however, this may have an impact on other protocols using IPv4 options. An alternative is to configure access-lists on all incoming interfaces dropping IPv4 protocol or IPv6 next header 46 (RSVP).
信頼できるドメインの分離は、信頼されていない要素が信頼できるドメインのルーターにアクセスできないようにするためのRSVPにとって重要なセキュリティメカニズムです。ただし、LSP間のASBR-ASBR通信は、具体的に保護する必要があります。分離メカニズムは、次のヘッダー0パケットを使用して、IPv4ルーターアラートまたはIPv6によってバイパスされる場合があります。ソリューションは、IPオプションの処理を無効にすることで構成できます。これにより、RSVPが使用するルーターアラートオプションを含むIPv4オプションを使用して、すべてのIPパケットがドロップまたは無視されます。ただし、これはIPv4オプションを使用して他のプロトコルに影響を与える可能性があります。別の方法は、IPv4プロトコルまたはIPv6 Next Header 46（RSVP）をドロップするすべての着信インターフェイスでアクセスリストを構成することです。
RSVP security can be strengthened by deactivating RSVP on interfaces with neighbors who are not authorized to use RSVP, to protect against adjacent CE-PE attacks. However, this does not really protect against DoS attacks or attacks on non-adjacent routers. It has been demonstrated that substantial CPU resources are consumed simply by processing received RSVP packets, even if the RSVP process is deactivated for the specific interface on which the RSVP packets are received.
RSVPセキュリティは、隣接するCE-PE攻撃から保護するために、RSVPを使用することを許可されていないネイバーとのインターフェイスでRSVPを非アクティブ化することにより、強化できます。ただし、これはDOS攻撃や非隣接ルーターに対する攻撃から実際に保護するものではありません。RSVPパケットが受信された特定のインターフェイスに対してRSVPプロセスが非アクティブ化された場合でも、受信したRSVPパケットを処理するだけで、実質的なCPUリソースが消費されることが実証されています。
RSVP neighbor filtering at the protocol level, to restrict the set of neighbors that can send RSVP messages to a given router, protects against non-adjacent attacks. However, this does not protect against DoS attacks and does not effectively protect against spoofing of the source address of RSVP packets, if the filter relies on the neighbor's address within the RSVP message.
RSVPネイバーフィルタリングは、プロトコルレベルでフィルタリングされ、特定のルーターにRSVPメッセージを送信できる近隣のセットを制限し、非隣接攻撃から保護します。ただし、これはDOS攻撃から保護せず、RSVPメッセージ内の近隣のアドレスにフィルターが依存している場合、RSVPパケットのソースアドレスのスプーフィングから効果的に保護しません。
RSVP neighbor filtering at the data-plane level, with an access list to accept IP packets with port 46 only for specific neighbors, requires Router Alert mode to be deactivated and does not protect against spoofing.
データプレーンレベルでのRSVPネイバーフィルタリングは、特定の近隣のみでポート46のIPパケットを受け入れるアクセスリストを備えており、ルーターアラートモードを非アクティブ化する必要があり、スプーフィングから保護しません。
Another valuable tool is RSVP message pacing, to limit the number of RSVP messages sent to a given neighbor during a given period. This allows blocking DoS attack propagation.
もう1つの貴重なツールは、特定の期間中に特定の隣人に送信されるRSVPメッセージの数を制限するために、RSVPメッセージペーシングです。これにより、DOS攻撃の伝播をブロックできます。
- Another approach is to limit the impact of an attack on control-plane resources.
- 別のアプローチは、コントロールプレーンリソースに対する攻撃の影響を制限することです。
To ensure continued effective operation of the MPLS router even in the case of an attack that bypasses packet filtering mechanisms such as Access Control Lists in the data plane, it is important that routers have some mechanisms to limit the impact of the attack. There should be a mechanism to rate limit the amount of control-plane traffic addressed to the router, per interface. This should be configurable on a per-protocol basis, (and, ideally, on a per-sender basis) to avoid letting an attacked protocol or a given sender block all communications. This requires the ability to filter and limit the rate of incoming messages of particular protocols, such as RSVP (filtering at the IP protocol level), and particular senders. In addition, there should be a mechanism to limit CPU and memory capacity allocated to RSVP, so as to protect other control-plane elements. To limit memory allocation, it will probably be necessary to limit the number of LSPs that can be set up.
データプレーンのアクセス制御リストなどのパケットフィルタリングメカニズムをバイパスする攻撃の場合でも、MPLSルーターの継続的な効果的な動作を確保するために、ルーターには攻撃の影響を制限するためのいくつかのメカニズムがあることが重要です。インターフェイスごとに、ルーターに宛てられたコントロールプレーントラフィックの量を制限するメカニズムがあるはずです。これは、攻撃されたプロトコルまたは特定の送信者がすべての通信をブロックさせることを避けるために、プロトコルごと（および理想的にはセンダーごとのベース）で構成可能である必要があります。これには、RSVP（IPプロトコルレベルでのフィルタリング）、および特定の送信者など、特定のプロトコルの受信メッセージのレートをフィルタリングおよび制限する機能が必要です。さらに、他の制御面要素を保護するために、RSVPに割り当てられたCPUとメモリ容量を制限するメカニズムがあるはずです。メモリの割り当てを制限するには、おそらくセットアップできるLSPの数を制限する必要があります。
- Authentication for RSVP messages
- RSVPメッセージの認証
RSVP message authentication is described in RFC 2747 [RFC2747] and RFC 3097 [RFC3097]. It is one of the most powerful tools for protection against RSVP-based attacks. It applies cryptographic authentication to RSVP messages based on a secure message hash using a key shared by RSVP neighbors. This protects against LSP creation attacks, at the expense of consuming significant CPU resources for digest computation. In addition, if the neighboring RSVP speaker is compromised, it could be used to launch attacks using authenticated RSVP messages. These methods, and certain other aspects of RSVP security, are explained in detail in RFC 4230 [RFC4230]. Key management must be implemented. Logging and auditing as well as multiple layers of cryptographic protection can help here. IPsec can also be used in some cases (see [RFC4230]).
RSVPメッセージ認証は、RFC 2747 [RFC2747]およびRFC 3097 [RFC3097]で説明されています。これは、RSVPベースの攻撃から保護するための最も強力なツールの1つです。RSVP Neighborsが共有するキーを使用して、安全なメッセージハッシュに基づいて、RSVPメッセージに暗号化認証を適用します。これは、ダイジェスト計算のために重要なCPUリソースを消費することを犠牲にして、LSPの作成攻撃から保護します。さらに、隣接するRSVPスピーカーが侵害されている場合、認証されたRSVPメッセージを使用して攻撃を起動するために使用できます。これらの方法、およびRSVPセキュリティの他の特定の側面については、RFC 4230 [RFC4230]で詳細に説明されています。キー管理を実装する必要があります。ロギングと監査、および暗号化の保護の複数の層がここで役立ちます。IPSECは場合によっては使用することもできます（[RFC4230]を参照）。
One challenge using RSVP message authentication arises in many cases where non-RSVP nodes are present in the network. In such cases, the RSVP neighbor may not be known up front, thus neighbor-based keying approaches fail, unless the same key is used everywhere, which is not recommended for security reasons. Group keying may help in such cases. The security properties of various keying approaches are discussed in detail in [RSVP-key].
RSVPメッセージ認証を使用した1つの課題は、ネットワークに非RSVPノードが存在する多くの場合に発生します。そのような場合、RSVP隣人は前もって知られていない可能性があるため、同じキーがどこでも使用されない限り、隣接ベースのキーイングアプローチは失敗します。これはセキュリティ上の理由で推奨されません。グループキーイングは、そのような場合に役立つ場合があります。さまざまなキーイングアプローチのセキュリティプロパティについては、[RSVP-Key]で詳しく説明しています。
The approaches to protect MPLS routers against LDP-based attacks are similar to those for RSVP, including isolation, protocol deactivation on specific interfaces, filtering of LDP neighbors at the protocol level, filtering of LDP neighbors at the data-plane level (with an access list that filters the TCP and UDP LDP ports), authentication with a message digest, rate limiting of LDP messages per protocol per sender, and limiting all resources allocated to LDP-related tasks. LDP protection could be considered easier in a certain sense. UDP port matching may be sufficient for LDP protection. Router alter options and beyond might be involved in RSVP protection.
MPLSルーターをLDPベースの攻撃から保護するアプローチは、特定のインターフェイスでの分離、プロトコルの非アクティブ化、プロトコルレベルでのLDPネイバーのフィルタリング、データプレーンレベルでのLDP近隣のフィルタリングなど、RSVPのアプローチと類似しています（アクセスを使用します（アクセス付き）TCPおよびUDP LDPポートをフィルタリングするリスト、メッセージダイジェストを使用した認証、送信者ごとのプロトコルごとのLDPメッセージのレート制限、およびLDP関連のタスクに割り当てられたすべてのリソースを制限します。LDP保護は、ある意味でより簡単に見なされる可能性があります。UDPポートマッチングでは、LDP保護に十分な場合があります。ルーターの変更オプション以降は、RSVP保護に関与している可能性があります。
IPsec can provide authentication, integrity, confidentiality, and replay detection for provider or user data. It also has an associated key management protocol.
IPSECは、プロバイダーまたはユーザーデータの認証、整合性、機密性、およびリプレイ検出を提供できます。また、関連する主要な管理プロトコルもあります。
In today's MPLS/GMPLS, ATM, or Frame Relay networks, encryption is not provided as a basic feature. Mechanisms described in Section 5 can be used to secure the MPLS data-plane traffic carried over an MPLS core. Both the Frame Relay Forum and the ATM Forum standardized cryptographic security services in the late 1990s, but these standards are not widely implemented.
今日のMPLS/GMPL、ATM、またはフレームリレーネットワークでは、暗号化は基本的な機能として提供されていません。セクション5で説明されているメカニズムは、MPLSコアに搭載されたMPLSデータプレーントラフィックを保護するために使用できます。1990年代後半には、フレームリレーフォーラムとATMフォーラム標準化された暗号セキュリティサービスの両方がありますが、これらの標準は広く実装されていません。
Peer or neighbor protocol authentication may be used to enhance security. For example, BGP MD5 authentication may be used to enhance security on PE-CE links using eBGP. In the case of inter-provider connections, cryptographic protection mechanisms, such as IPsec, may be used between ASes.
ピアまたはネイバーのプロトコル認証を使用して、セキュリティを強化することができます。たとえば、BGP MD5認証を使用して、EBGPを使用してPE-CEリンクのセキュリティを強化することができます。プロバイダー間接続の場合、IPSECなどの暗号化保護メカニズムをASE間で使用できます。
If multiple services are provided on the same PE platform, different WAN address spaces may be used for different services (e.g., VPN and non-VPN) to enhance isolation.
同じPEプラットフォームで複数のサービスが提供されている場合、分離を強化するために異なるサービス（VPNや非VPNなど）に異なるWANアドレススペースを使用できます。
Firewall and Filtering: access control mechanisms can be used to filter any packets destined for the service provider's infrastructure prefix or eliminate routes identified as illegitimate. Filtering should also be applied to prevent sourcing packets with infrastructure IP addresses from outside.
ファイアウォールとフィルタリング：アクセス制御メカニズムを使用して、サービスプロバイダーのインフラストラクチャのプレフィックスに向けられたパケットをフィルタリングしたり、違法であると特定されたルートを排除したりできます。また、外部からインフラストラクチャIPアドレスを使用してパケットを調達するのを防ぐために、フィルタリングを適用する必要があります。
Rate limiting may be applied to the user interface/logical interfaces as a defense against DDoS bandwidth attack. This is helpful when the PE device is supporting both multiple services, especially VPN and Internet Services, on the same physical interfaces through different logical interfaces.
レート制限は、DDOS帯域幅攻撃に対する防御として、ユーザーインターフェイス/論理インターフェイスに適用される場合があります。これは、PEデバイスが異なる論理インターフェイスを介した同じ物理インターフェイスで、複数のサービス、特にVPNサービスとインターネットサービスの両方をサポートしている場合に役立ちます。
Authentication can be used to validate site access to the network via fixed or logical connections, e.g., L2TP or IPsec, respectively. If the user wishes to hold the authentication credentials for access, then provider solutions require the flexibility for either direct authentication by the PE itself or interaction with a customer authentication server. Mechanisms are required in the latter case to ensure that the interaction between the PE and the customer authentication server is appropriately secured.
認証は、それぞれ固定または論理接続、例えばL2TPまたはIPSECを介してネットワークへのサイトアクセスを検証するために使用できます。ユーザーがアクセスの認証資格情報を保持したい場合、プロバイダーソリューションは、PE自体による直接認証または顧客認証サーバーとの対話の柔軟性を必要とします。後者のケースでは、PEと顧客認証サーバー間の相互作用が適切に保護されていることを確認するために、メカニズムが必要です。
Choice of routing protocols, e.g., RIP, OSPF, or BGP, may be used to provide control access between a CE and a PE. Per-neighbor and per-VPN routing policies may be established to enhance security and reduce the impact of a malicious or non-malicious attack on the PE; the following mechanisms, in particular, should be considered:
RIP、OSPF、またはBGPなど、ルーティングプロトコルの選択を使用して、CEとPE間の制御アクセスを提供できます。NeighborおよびVPNごとのルーティングポリシーを確立して、セキュリティを強化し、PEに対する悪意のあるまたは非悪意のある攻撃の影響を減らすことができます。特に、次のメカニズムを考慮する必要があります。
- Limiting the number of prefixes that may be advertised on a per-access basis into the PE. Appropriate action may be taken should a limit be exceeded, e.g., the PE shutting down the peer session to the CE
- アクセスごとに宣伝される可能性のあるプレフィックスの数をPEに制限します。制限を超えた場合、たとえばPEがピアセッションをCEにシャットダウンした場合、適切なアクションが実行される場合があります
- Applying route dampening at the PE on received routing updates
- 受信したルーティングアップデートでPEでのルート減衰を適用する
- Definition of a per-VPN prefix limit after which additional prefixes will not be added to the VPN routing table.
- VPNごとのプレフィックス制限の定義により、追加のプレフィックスはVPNルーティングテーブルに追加されません。
In the case of inter-provider connection, access protection, link authentication, and routing policies as described above may be applied. Both inbound and outbound firewall or filtering mechanisms between ASes may be applied. Proper security procedures must be implemented in inter-provider interconnection to protect the providers' network infrastructure and their customers. This may be custom designed for each inter-provider peering connection, and must be agreed upon by both providers.
プロバイダー間接続の場合、上記のようにアクセス保護、リンク認証、およびルーティングポリシーが適用される場合があります。ASE間のインバウンドファイアウォールとアウトバウンドファイアウォールまたはフィルタリングメカニズムが適用される場合があります。プロバイダーのネットワークインフラストラクチャとその顧客を保護するには、適切なセキュリティ手順をインタープロバイダーの相互接続に実装する必要があります。これは、各プロバイダーのピアリング接続ごとにカスタム設計されている場合があり、両方のプロバイダーが合意する必要があります。
MPLS/GMPLS providers offering QoS-enabled services require mechanisms to ensure that individual accesses are validated against their subscribed QoS profile and as such gain access to core resources that match their service profile. Mechanisms such as per-class-of-service rate limiting or traffic shaping on ingress to the MPLS/GMPLS core are two options for providing this level of control. Such mechanisms may require the per-class-of-service profile to be enforced either by marking, remarking, or discarding of traffic outside of the profile.
QoS対応サービスを提供するMPLS/GMPLSプロバイダーは、個々のアクセスがサブスクライブされたQoSプロファイルに対して検証され、サービスプロファイルに一致するコアリソースへのアクセスを取得するためのメカニズムを必要とします。MPLS/GMPLSコアへのイングレスでのクラスごとのレートの制限またはトラフィックシェーピングなどのメカニズムは、このレベルの制御を提供するための2つのオプションです。このようなメカニズムでは、プロファイルの外側のトラフィックをマーク、リマー、または破棄することにより、サービスごとのプロファイルを実施する必要があります。
End users needing specific statistics on the core, e.g., routing table, interface status, or QoS statistics, place requirements on mechanisms at the PE both to validate the incoming user and limit the views available to that particular user. Mechanisms should also be considered to ensure that such access cannot be used as means to construct a DoS attack (either maliciously or accidentally) on the PE itself. This could be accomplished either through separation of these resources within the PE itself or via the capability to rate limiting, which is performed on the basis of each physical interface or each logical connection.
コアの特定の統計、例えばルーティングテーブル、インターフェイスステータス、QoS統計を必要とするエンドユーザーは、受信ユーザーを検証し、その特定のユーザーが利用できるビューを制限するために、PEのメカニズムの要件をPEに配置します。また、メカニズムは、PE自体にDOS攻撃（悪意を持ってまたは誤って）を構築する手段としてそのようなアクセスを使用できないことを保証する必要があります。これは、PE自体内のこれらのリソースを分離すること、または各物理インターフェイスまたは各論理接続に基づいて実行される制限を評価する能力によって達成できます。
MPLS/GMPLS providers must support end users' security requirements. Depending on the technologies used, these requirements may include:
MPLS/GMPLSプロバイダーは、エンドユーザーのセキュリティ要件をサポートする必要があります。使用するテクノロジーに応じて、これらの要件には以下が含まれます。
- User control plane separation through routing isolation when applicable, for example, in the case of MPLS VPNs.
- MPLS VPNSの場合、該当する場合、ルーティングの分離によるユーザー制御プレーンの分離。
- Protection against intrusion, DoS attacks, and spoofing
- 侵入、DOS攻撃、およびスプーフィングに対する保護
- Access Authentication
- アクセス認証
- Techniques highlighted throughout this document that identify methodologies for the protection of resources and the MPLS/GMPLS infrastructure.
- リソースとMPLS/GMPLSインフラストラクチャの保護の方法論を特定するこのドキュメント全体で強調表示された手法。
Hardware or software errors in equipment leading to breaches in security are not within the scope of this document.
セキュリティの違反につながる機器のハードウェアまたはソフトウェアエラーは、このドキュメントの範囲内ではありません。
This section discusses security capabilities that are important at the MPLS/GMPLS inter-provider connections and at devices (including ASBR routers) supporting these connections. The security capabilities stated in this section should be considered as complementary to security considerations addressed in individual protocol specifications or security frameworks.
このセクションでは、これらの接続をサポートするMPLS/GMPLS間接続およびデバイス（ASBRルーターを含む）で重要なセキュリティ機能について説明します。このセクションに記載されているセキュリティ機能は、個々のプロトコル仕様またはセキュリティフレームワークで対処されているセキュリティに関する考慮事項を補完するものと見なす必要があります。
Security vulnerabilities and exposures may be propagated across multiple networks because of security vulnerabilities arising in one peer's network. Threats to security originate from accidental, administrative, and intentional sources. Intentional threats include events such as spoofing and denial-of-service (DoS) attacks.
セキュリティの脆弱性とエクスポージャーは、1つのピアネットワークで発生するセキュリティの脆弱性のため、複数のネットワークにわたって伝播される場合があります。セキュリティに対する脅威は、偶発的、管理的、意図的な情報源から発生します。意図的な脅威には、スポーフィングやサービス拒否（DOS）攻撃などのイベントが含まれます。
The level and nature of threats, as well as security and availability requirements, may vary over time and from network to network. This section, therefore, discusses capabilities that need to be available in equipment deployed for support of the MPLS InterCarrier Interconnect (MPLS-ICI). Whether any particular capability is used in any one specific instance of the ICI is up to the service providers managing the PE equipment offering or using the ICI services.
脅威のレベルと性質、ならびにセキュリティと可用性の要件は、時間とネットワークごとに異なる場合があります。したがって、このセクションでは、MPLS Intercarrier Interconnect（MPLS-ICI）をサポートするために展開された機器で利用できる必要がある機能について説明します。ICIの特定のインスタンスで特定の機能が使用されるかどうかは、PE機器の提供を管理するか、ICIサービスを使用するサービスプロバイダー次第です。
This section discusses capabilities for control-plane protection, including protection of routing, signaling, and OAM capabilities.
このセクションでは、ルーティング、シグナル、OAM機能の保護など、制御面保護の能力について説明します。
Authentication may be needed for signaling sessions (i.e., BGP, LDP, and RSVP-TE) and routing sessions (e.g., BGP), as well as OAM sessions across domain boundaries. Equipment must be able to support the exchange of all protocol messages over IPsec ESP, with NULL encryption and authentication, between the peering ASBRs. Support for message authentication for LDP, BGP, and RSVP-TE authentication must also be provided. Manual keying of IPsec should not be used. IKEv2 with pre-shared secrets or public key methods should be used. Replay detection should be used.
シグナリングセッション（つまり、BGP、LDP、およびRSVP-TE）およびルーティングセッション（BGPなど）、およびドメイン境界全体のOAMセッションには認証が必要になる場合があります。Peering ASBRの間で、機器はIPSEC ESPを介したすべてのプロトコルメッセージの交換をサポートできる必要があります。LDP、BGP、およびRSVP-TE認証のメッセージ認証のサポートも提供する必要があります。IPSECの手動キーは使用しないでください。事前に共有された秘密または公開キーの方法を備えたIKEV2を使用する必要があります。リプレイ検出を使用する必要があります。
Mechanisms to authenticate and validate a dynamic setup request must be available. For instance, if dynamic signaling of a TE-LSP or PW is crossing a domain boundary, there must be a way to detect whether the LSP source is who it claims to be and that it is allowed to connect to the destination.
動的なセットアップ要求を認証および検証するメカニズムが利用可能でなければなりません。たとえば、TE-LSPまたはPWの動的シグナルがドメイン境界を越えている場合、LSPソースが誰であるかを検出する方法があり、宛先に接続できるかどうかを検出する方法が必要です。
Message authentication support for all TCP-based protocols within the scope of the MPLS-ICI (i.e., LDP signaling and BGP routing) and Message authentication with the RSVP-TE Integrity Object must be provided to interoperate with current practices. Equipment should be able to support the exchange of all signaling and routing (LDP, RSVP-TE, and BGP) protocol messages over a single IPsec association pair in tunnel or transport mode with authentication but with NULL encryption, between the peering ASBRs. IPsec, if supported, must be supported with HMAC-SHA-1 and alternatively with HMAC-SHA-2 and optionally SHA-1. It is expected that authentication algorithms will evolve over time and support can be updated as needed.
MPLS-ICIの範囲内のすべてのTCPベースのプロトコル（つまり、LDPシグナル伝達とBGPルーティング）およびRSVP-TEの整合性オブジェクトを使用したメッセージ認証のメッセージ認証サポートは、現在のプラクティスと相互運用するために提供する必要があります。機器は、ピアリングASBRの間で、認証を伴うがヌル暗号化を備えたトンネルまたは輸送モードの単一のIPSEC関連ペアで、すべてのシグナルとルーティング（LDP、RSVP-TE、およびBGP）のプロトコルメッセージの交換をサポートできる必要があります。IPSECは、サポートされている場合は、HMAC-SHA-1で、代わりにHMAC-SHA-2およびオプションでSHA-1でサポートする必要があります。認証アルゴリズムは時間とともに進化し、必要に応じてサポートを更新できると予想されます。
OAM operations across the MPLS-ICI could also be the source of security threats on the provider infrastructure as well as the service offered over the MPLS-ICI. A large volume of OAM messages could overwhelm the processing capabilities of an ASBR if the ASBR is not properly protected. Maliciously generated OAM messages could also be used to bring down an otherwise healthy service (e.g., MPLS Pseudowire), and therefore affect service security. LSP ping does not support authentication today, and that support should be a subject for future consideration. Bidirectional Forwarding Detection (BFD), however, does have support for carrying an authentication object. It also supports Time-To-Live (TTL) processing as an anti-replay measure. Implementations conformant with this MPLS-ICI should support BFD authentication and must support the procedures for TTL processing.
MPLS-ICI全体のOAM運用は、MPLS-ICIで提供されるサービスだけでなく、プロバイダーインフラストラクチャのセキュリティ脅威のソースでもあります。ASBRが適切に保護されていない場合、大量のOAMメッセージはASBRの処理機能を圧倒する可能性があります。悪意を持って生成されたOAMメッセージを使用して、そうでなければ健康的なサービス（MPLS Pseudowireなど）を削減するため、サービスセキュリティに影響を与えます。LSP Pingは今日の認証をサポートしておらず、そのサポートは将来の検討の対象となるはずです。ただし、双方向転送検出（BFD）は、認証オブジェクトを運ぶことをサポートしています。また、アンチレプレイメジャーとしての時間（TTL）処理もサポートしています。このMPLS-ICIに準拠した実装は、BFD認証をサポートし、TTL処理の手順をサポートする必要があります。
Implementations must have the ability to prevent signaling and routing DoS attacks on the control plane per interface and provider. Such prevention may be provided by rate limiting signaling and routing messages that can be sent by a peer provider according to a traffic profile and by guarding against malformed packets.
実装には、インターフェイスとプロバイダーごとの制御プレーンに対するDOS攻撃のシグナリングとルーティングを防ぐ機能が必要です。このような予防は、トラフィックプロファイルに応じてピアプロバイダーによって送信され、不正なパケットを守ることができるレート制限信号とルーティングメッセージによって提供される場合があります。
Equipment must provide the ability to filter signaling, routing, and OAM packets destined for the device, and must provide the ability to rate limit such packets. Packet filters should be capable of being separately applied per interface, and should have minimal or no performance impact. For example, this allows an operator to filter or rate limit signaling, routing, and OAM messages that can be sent by a peer provider and limit such traffic to a given profile.
機器は、デバイス向けのシグナリング、ルーティング、およびOAMパケットをフィルタリングする機能を提供する必要があり、そのようなパケットを制限する機能を提供する必要があります。パケットフィルターは、インターフェイスごとに個別に適用できる必要があり、パフォーマンスへの影響を最小限に抑えるか、まったくない必要があります。たとえば、これにより、オペレーターは、ピアプロバイダーによって送信され、そのようなトラフィックを特定のプロファイルに制限できるシグナル、ルーティング、およびOAMメッセージをフィルタリングまたはレートすることができます。
During a control-plane DoS attack against an ASBR, the router should guarantee sufficient resources to allow network operators to execute network management commands to take corrective action, such as turning on additional filters or disconnecting an interface under attack. DoS attacks on the control plane should not adversely affect data-plane performance.
ASBRに対するコントロールプレーンのDOS攻撃中、ルーターは、ネットワークオペレーターがネットワーク管理コマンドを実行して、追加のフィルターをオンにしたり、攻撃下でインターフェイスを切断したりするなど、ネットワーク管理コマンドを実行できるようにするための十分なリソースを保証する必要があります。コントロールプレーンでのDOS攻撃は、データプレーンのパフォーマンスに悪影響を及ぼさないはずです。
Equipment running BGP must support the ability to limit the number of BGP routes received from any particular peer. Furthermore, in the case of IPVPN, a router must be able to limit the number of routes learned from a BGP peer per IPVPN. In the case that a device has multiple BGP peers, it should be possible for the limit to vary between peers.
BGPを実行している機器は、特定のピアから受け取ったBGPルートの数を制限する機能をサポートする必要があります。さらに、IPVPNの場合、ルーターはIPVPNごとにBGPピアから学習したルートの数を制限できる必要があります。デバイスに複数のBGPピアがある場合、制限がピア間で変化する可能性があるはずです。
Equipment should be robust in the presence of malformed protocol packets. For example, malformed routing, signaling, and OAM packets should be treated in accordance with the relevant protocol specification.
奇形のプロトコルパケットの存在下では、機器は堅牢である必要があります。たとえば、不正なルーティング、シグナリング、およびOAMパケットは、関連するプロトコル仕様に従って処理する必要があります。
Equipment must have the ability to drop any signaling or routing protocol messages when these messages are to be processed by the ASBR but the corresponding protocol is not enabled on that interface.
これらのメッセージがASBRによって処理されるが、対応するプロトコルはそのインターフェイスでは有効になっていない場合、機器にはシグナリングまたはルーティングプロトコルメッセージをドロップする機能が必要です。
Equipment must allow an administrator to enable or disable a protocol (by default, the protocol is disabled unless administratively enabled) on an interface basis.
機器は、管理者がインターフェイスベースでプロトコルを有効または無効にすることを許可する必要があります（デフォルトでは、管理上有効にしない限り、プロトコルは無効になります）。
Equipment must be able to drop any signaling or routing protocol messages when these messages are to be processed by the ASBR but the corresponding protocol is not enabled on that interface. This dropping should not adversely affect data-plane or control-plane performance.
これらのメッセージをASBRによって処理する場合、機器はシグナリングまたはルーティングプロトコルメッセージをドロップできる必要がありますが、対応するプロトコルはそのインターフェイスで有効にされていません。このドロップは、データプレーンやコントロールプレーンのパフォーマンスに悪影響を及ぼさないはずです。
The capability to detect and locate faults in an LSP cross-connect must be provided. Such faults may cause security violations as they result in directing traffic to the wrong destinations. This capability may rely on OAM functions. Equipment must support MPLS LSP ping [RFC4379]. This may be used to verify end-to-end connectivity for the LSP (e.g., PW, TE Tunnel, VPN LSP, etc.), and to verify PE-to-PE connectivity for IPVPN services.
LSPクロスコネクトで障害を検出して特定する機能を提供する必要があります。そのような障害は、間違った目的地へのトラフィックを向けるため、セキュリティ違反を引き起こす可能性があります。この機能は、OAM関数に依存する場合があります。機器はMPLS LSP ping [RFC4379]をサポートする必要があります。これを使用して、LSPのエンドツーエンドの接続（PW、TEトンネル、VPN LSPなど）を検証し、IPVPNサービスのPE-PE接続性を検証するために使用できます。
When routing information is advertised from one domain to the other, operators must be able to guard against situations that result in traffic hijacking, black-holing, resource stealing (e.g., number of routes), etc. For instance, in the IPVPN case, an operator must be able to block routes based on associated route target attributes. In addition, mechanisms to defend against routing protocol attack must exist to verify whether a route advertised by a peer for a given VPN is actually a valid route and whether the VPN has a site attached to or reachable through that domain.
ルーティング情報が1つのドメインから他のドメインに宣伝される場合、オペレーターは、トラフィックハイジャック、ブラックホーリング、リソース盗み（ルートの数など）などの状況を防ぐことができなければなりません。たとえば、IPVPNの場合、IPVPNの場合、オペレーターは、関連するルートターゲット属性に基づいてルートをブロックできる必要があります。さらに、ルーティングプロトコル攻撃を防御するメカニズムは、特定のVPNのピアによって宣伝されているルートが実際に有効なルートであるかどうか、およびVPNにそのドメインを介して接続または到達可能なサイトがあるかどうかを検証するために存在する必要があります。
Equipment (ASBRs and Route Reflectors (RRs)) supporting operation of BGP must be able to restrict which route target attributes are sent to and accepted from a BGP peer across an ICI. Equipment (ASBRs, RRs) should also be able to inform the peer regarding which route target attributes it will accept from a peer, because sending an incorrect route target can result in an incorrect cross-connection of VPNs. Also, sending inappropriate route targets to a peer may disclose confidential information. This is another example of defense against routing protocol attacks.
BGPの操作をサポートする機器（ASBRSおよびルートリフレクター（RRS））は、ICI全体でBGPピアから送信され、受け入れられるルートターゲット属性を制限できる必要があります。機器（ASBRS、RRS）は、誤ったルートターゲットを送信するとVPNの間違った相互接続が生じる可能性があるため、ピアから受け入れるルートターゲット属性についてピアに通知できる必要があります。また、不適切なルートターゲットをピアに送信すると、機密情報が開示される場合があります。これは、ルーティングプロトコル攻撃に対する防御のもう1つの例です。
Equipment must support route filtering of routes received via a BGP peer session by applying policies that include one or more of the following: AS path, BGP next hop, standard community, or extended community.
機器は、次の1つ以上を含むポリシーを適用することにより、BGPピアセッションで受信したルートのルートフィルタリングをサポートする必要があります：パス、BGP次のホップ、標準コミュニティ、または拡張コミュニティなど。
The ability to identify and block messages with confidential information from leaving the trusted domain that can reveal confidential information about network operation (e.g., performance OAM messages or LSP ping messages) is required. SPs must have the flexibility to handle these messages at the ASBR.
ネットワーク操作に関する機密情報（パフォーマンスOAMメッセージやLSP Pingメッセージなど）を明らかにする可能性のある信頼できるドメインを離れることを、機密情報を使用してメッセージを識別してブロックする機能が必要です。SPSには、ASBRでこれらのメッセージを処理する柔軟性が必要です。
Equipment should be able to identify and restrict where it sends messages that can reveal confidential information about network operation (e.g., performance OAM messages, LSP Traceroute messages). Service Providers must have the flexibility to handle these messages at the ASBR. For example, equipment supporting LSP Traceroute may limit to which addresses replies can be sent. Note that this capability should be used with care. For example, if an SP chooses to prohibit the exchange of LSP ping messages at the ICI, it may make it more difficult to debug incorrect cross-connection of LSPs or other problems.
機器は、ネットワーク操作に関する機密情報（パフォーマンスOAMメッセージ、LSP Tracerouteメッセージなど）を明らかにするメッセージを送信する場所を特定して制限できる必要があります。サービスプロバイダーは、ASBRでこれらのメッセージを処理する柔軟性を持つ必要があります。たとえば、LSP Tracerouteをサポートする機器は、アドレスを送信できるように制限する場合があります。この機能は注意して使用する必要があることに注意してください。たとえば、SPがICIでのLSP Pingメッセージの交換を禁止することを選択した場合、LSPまたはその他の問題の誤った相互接続をデバッグすることがより困難になる可能性があります。
An SP may decide to progress these messages if they arrive from a trusted provider and are targeted to specific, agreed-on addresses. Another provider may decide to traffic police, reject, or apply other policies to these messages. Solutions must enable providers to control the information that is relayed to another provider about the path that an LSP takes. For example, when using the RSVP-TE record route object or LSP ping / trace, a provider must be able to control the information contained in corresponding messages when sent to another provider.
SPは、信頼できるプロバイダーから到着し、特定の合意されたアドレスをターゲットにしている場合、これらのメッセージを進めることを決定する場合があります。別のプロバイダーは、これらのメッセージに他のポリシーを交通、拒否、または適用することを決定する場合があります。ソリューションは、プロバイダーがLSPがとるパスについて別のプロバイダーに中継する情報を制御できるようにする必要があります。たとえば、RSVP-TEレコードルートオブジェクトまたはLSP Ping / Traceを使用する場合、プロバイダーは別のプロバイダーに送信されたときに対応するメッセージに含まれる情報を制御できる必要があります。
In addition to the control-plane protection mechanisms listed in the previous section on control-plane protection with RSVP-TE, the ASBR must be able both to limit the number of LSPs that can be set up by other domains and to limit the amount of bandwidth that can be reserved. A provider's ASBR may deny an LSP setup request or a bandwidth reservation request sent by another provider's whose limits have been reached.
RSVP-TEを使用したコントロールプレーン保護に関する前のセクションにリストされているコントロールプレーン保護メカニズムに加えて、ASBRは、他のドメインによって設定できるLSPの数を制限し、量の量を制限できる必要があります。予約できる帯域幅。プロバイダーのASBRは、LSPのセットアップリクエストまたは限界に達した別のプロバイダーから送信された帯域幅予約リクエストを拒否する場合があります。
This is described in Section 5 of this document.
これは、このドキュメントのセクション5で説明されています。
Equipment must be able to verify that a label received across an interconnect was actually assigned to an LSP arriving across that interconnect. If a label not assigned to an LSP arrives at this router from the correct neighboring provider, the packet must be dropped. This verification can be applied to the top label only. The top label is the received top label and every label that is exposed by label popping is to be used for forwarding decisions.
機器は、相互接続全体で受信したラベルが実際にその相互接続に到着するLSPに割り当てられたことを確認できる必要があります。LSPに割り当てられていないラベルが正しい隣接プロバイダーからこのルーターに到着した場合、パケットをドロップする必要があります。この検証は、トップレーベルのみに適用できます。トップレーベルは受信したトップレーベルであり、ラベルポップによって公開されるすべてのラベルは、決定の転送に使用されます。
Equipment must provide the capability to drop MPLS-labeled packets if all labels in the stack are not processed. This lets SPs guarantee that every label that enters its domain from another carrier is actually assigned to that carrier.
スタック内のすべてのラベルが処理されていない場合、機器はMPLSラベルパケットをドロップする機能を提供する必要があります。これにより、SPSは、別のキャリアからドメインに入るすべてのラベルが実際にそのキャリアに割り当てられていることを保証できます。
The following requirements are not directly reflected in this document but must be used as guidance for addressing further work.
次の要件はこのドキュメントに直接反映されていませんが、さらなる作業に対処するためのガイダンスとして使用する必要があります。
Solutions must NOT force operators to reveal reachability information to routers within their domains. Note that it is believed that this requirement is met via other requirements specified in this section plus the normal operation of IP routing, which does not reveal individual hosts.
ソリューションは、オペレーターにドメイン内のルーターに到達可能な情報を明らかにするように強制してはなりません。この要件は、このセクションで指定された他の要件と、個々のホストを明らかにしないIPルーティングの通常の操作を介して満たされると考えられていることに注意してください。
Mechanisms to authenticate and validate a dynamic setup request must be available. For instance, if dynamic signaling of a TE-LSP or PW is crossing a domain boundary, there must be a way to detect whether the LSP source is who it claims to be and that it is allowed to connect to the destination.
動的なセットアップ要求を認証および検証するメカニズムが利用可能でなければなりません。たとえば、TE-LSPまたはPWの動的シグナルがドメイン境界を越えている場合、LSPソースが誰であるかを検出する方法があり、宛先に接続できるかどうかを検出する方法が必要です。
The following simple diagram illustrates a potential security issue on the data plane across an MPLS interconnect:
次の簡単な図は、MPLS相互接続全体のデータプレーンの潜在的なセキュリティの問題を示しています。
SP2 - ASBR2 - labeled path - ASBR1 - P1 - SP1's PSN - P2 - PE1
| | | |
|< AS2 >|<MPLS interconnect>|< AS1 >|
Traffic flow direction is from SP2 to SP1
トラフィックフローの方向は、SP2からSP1までです
In the case of downstream label assignment, the transit label used by ASBR2 is allocated by ASBR1, which in turn advertises it to ASBR2 (downstream unsolicited or on-demand); this label is used for a service context (VPN label, PW VC label, etc.), and this LSP is normally terminated at a forwarding table belonging to the service instance on PE (PE1) in SP1.
ダウンストリームラベルの割り当ての場合、ASBR2が使用するトランジットラベルはASBR1によって割り当てられ、ASBR2（下流の未承諾またはオンデマンド）に宣伝されます。このラベルは、サービスコンテキスト（VPNラベル、PW VCラベルなど）に使用され、このLSPは通常、SP1のPE（PE1）のサービスインスタンスに属する転送テーブルで終了します。
In the example above, ASBR1 would not know whether the label of an incoming packet from ASBR2 over the interconnect is a VPN label or PSN label for AS1. So it is possible (though unlikely) that ASBR2 can be accidentally or intentionally configured such that the incoming label could match a PSN label (e.g., LDP) in AS1. Then, this LSP would end up on the global plane of an infrastructure router (P or PE1), and this could invite a unidirectional attack on that P or PE1 where the LSP terminates.
上記の例では、ASBR1は、InterConnectを介したASBR2からの着信パケットのラベルがAS1のVPNラベルまたはPSNラベルであるかどうかを知りません。したがって、ASBR2がAS1のPSNラベル（LDPなど）と一致するようにASBR2を誤ってまたは意図的に構成できることは可能です。その後、このLSPはインフラストラクチャルーター（PまたはPE1）のグローバル平面に終わり、これにより、LSPが終了するそのPまたはPE1に対する単方向の攻撃を誘う可能性があります。
To mitigate this threat, implementations should be able to do a forwarding path look-up for the label on an incoming packet from an interconnect in a Label Forwarding Information Base (LFIB) space that is only intended for its own service context or provide a mechanism on the data plane that would ensure the incoming labels are what ASBR1 has allocated and advertised.
この脅威を緩和するために、実装は、独自のサービスコンテキストのみを目的としたラベル転送情報ベース（LFIB）スペースのインターコネクトからの入っているパケットのラベルの転送パスの検索を行うことができるはずです。着信ラベルがASBR1が割り当てて宣伝したものを保証するデータプレーンで。
A similar concept has been proposed in "Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)" [RFC5254].
同様の概念が「マルチセグメントの擬似具体的エミュレーションエッジからエッジ（PWE3）の要件」[RFC5254]で提案されています。
When using upstream label assignment, the upstream source must be identified and authenticated so the labels can be accepted as from a trusted source.
アップストリームラベルの割り当てを使用する場合、上流のソースを識別し、認証する必要があります。そうすることで、信頼できるソースからラベルを受け入れることができます。
The following summary provides a quick checklist of MPLS and GMPLS security threats, defense techniques, and the best-practice outlines for MPLS and GMPLS deployment.
次の要約は、MPLSおよびGMPLSセキュリティの脅威、防御技術、およびMPLSおよびGMPLS展開の最良の概要のクイックチェックリストを提供します。
Types of attacks on the control plane:
コントロールプレーンに対する攻撃の種類：
- Unauthorized LSP creation
- 不正なLSP作成
- LSP message interception
- LSPメッセージインターセプト
Attacks against RSVP-TE: DoS attacks that set up unauthorized LSP and/or LSP messages.
RSVP-TEに対する攻撃：不正なLSPおよび/またはLSPメッセージを設定するDOS攻撃。
Attacks against LDP: DoS attack with storms of LDP Hello messages or LDP TCP SYN messages.
LDPに対する攻撃：LDP HelloメッセージまたはLDP TCP Synメッセージの嵐によるDOS攻撃。
Attacks may be launched from external or internal sources, or through an SP's management systems.
攻撃は、外部または内部のソースから、またはSPの管理システムを介して発売される場合があります。
Attacks may be targeted at the SP's routing protocols or infrastructure elements.
攻撃は、SPのルーティングプロトコルまたはインフラストラクチャ要素を対象とする場合があります。
In general, control protocols may be attacked by:
一般に、コントロールプロトコルは以下によって攻撃される場合があります。
- MPLS signaling (LDP, RSVP-TE)
- MPLSシグナリング（LDP、RSVP-TE）
- PCE signaling
- PCEシグナル伝達
- IPsec signaling (IKE and IKEv2)
- IPSECシグナル伝達（IKEおよびIKEV2）
- ICMP and ICMPv6
- ICMPおよびICMPV6
- L2TP
- L2TP
- BGP-based membership discovery
- BGPベースのメンバーシップ発見
- Database-based membership discovery (e.g., RADIUS)
- データベースベースのメンバーシップ発見（半径など）
- OAM and diagnostic protocols such as LSP ping and LMP
- LSP PingやLMPなどのOAMおよび診断プロトコル
- Other protocols that may be important to the control infrastructure, e.g., DNS, LMP, NTP, SNMP, and GRE
- コントロールインフラストラクチャにとって重要な他のプロトコル、例えばDNS、LMP、NTP、SNMP、GRE
- Unauthorized observation of data traffic
- データトラフィックの不正な観察
- Data-traffic modification
- データトラフィックの変更
- Spoofing and replay
- スプーフィングとリプレイ
- Unauthorized deletion
- 不正な削除
- Unauthorized traffic-pattern analysis
- 不正なトラフィックパターン分析
- Denial of Service
- サービス拒否
1) Authentication:
1) 認証：
- Bidirectional authentication
- 双方向認証
- Key management
- キー管理
- Management system authentication
- 管理システム認証
- Peer-to-peer authentication
- ピアツーピア認証
2) Cryptographic techniques
2) 暗号化技術
3) Use of IPsec in MPLS/GMPLS networks
3) MPLS/GMPLSネットワークでのIPSECの使用
4) Encryption for device configuration and management
4) デバイスの構成と管理用の暗号化
5) Cryptographic techniques for MPLS pseudowires
5) MPLS擬似動物の暗号化技術
6) End-to-End versus Hop-by-Hop protection (CE-CE, PE-PE, PE-CE)
6) エンドツーエンドとホップバイホップ保護（CE-CE、PE-PE、PE-CE）
7) Access control techniques
7) アクセス制御手法
- Filtering
- フィルタリング
- Firewalls
- ファイアウォール
- Access Control to management interfaces
- 管理インターフェイスへのアクセス制御
8) Infrastructure isolation
8) インフラストラクチャの分離
9) Use of aggregated infrastructure 10) Quality control processes
9) 集約されたインフラストラクチャ10）品質管理プロセス
11) Testable MPLS/GMPLS service
11）テスト可能なMPLS/GMPLSサービス
12) End-to-end connectivity verification
12）エンドツーエンドの接続検証
13) Hop-by-hop resource configuration verification and discovery
13）ホップバイホップリソースの構成の検証と発見
1) General control-plane protection
1) 一般的なコントロールプレーン保護
- Filtering out infrastructure source addresses at edges
- エッジでインフラストラクチャソースアドレスをフィルタリングします
- Protocol authentication within the core
- コア内のプロトコル認証
- Infrastructure hiding (e.g., disable TTL propagation)
- インフラストラクチャの隠れ（例：TTL伝播を無効にする）
2) RSVP control-plane protection
2) RSVP制御面保護
- RSVP security tools
- RSVPセキュリティツール
- Isolation of the trusted domain
- 信頼できるドメインの分離
- Deactivating RSVP on interfaces with neighbors who are not authorized to use RSVP
- RSVPを使用することを許可されていない隣人とのインターフェイスでRSVPを非アクティブ化
- RSVP neighbor filtering at the protocol level and data-plane level
- プロトコルレベルとデータプレーンレベルでのRSVP隣接フィルタリング
- Authentication for RSVP messages
- RSVPメッセージの認証
- RSVP message pacing
- RSVPメッセージペーシング
3) LDP control-plane protection (similar techniques as for RSVP)
3) LDPコントロールプレーン保護（RSVPと同様の手法）
4) Data-plane protection
4) データプレーン保護
- User access link protection
- ユーザーアクセスリンク保護
- Link authentication
- 認証をリンクします
- Access routing control (e.g., prefix limits, route dampening, routing table limits (such as VRF limits)
- アクセスルーティングコントロール（例：プレフィックス制限、ルートの減衰、ルーティングテーブル制限（VRF制限など）
- Access QoS control
- QoSコントロールにアクセスします
- Customer service monitoring tools
- カスタマーサービス監視ツール
- Use of LSP ping (with its own control-plane security) to verify end-to-end connectivity of MPLS LSPs
- MPLS LSPのエンドツーエンドの接続性を検証するためのLSP Ping（独自のコントロールプレーンセキュリティを使用）の使用
- LMP (with its own security) to verify hop-by-hop connectivity.
- ホップバイホップ接続を確認するためのLMP（独自のセキュリティを備えています）。
Inter-provider connections are high security risk areas. Similar techniques and procedures as described for SP's general core protection are listed below for inter-provider connections.
プロバイダー間接続は、セキュリティリスクの高い領域です。SPの一般的なコア保護について説明した同様の手法と手順は、プロバイダー間接続について以下にリストされています。
1) Control-plane protection at inter-provider connections
1) プロバイダー間接続でのコントロールプレーン保護
- Authentication of signaling sessions
- シグナリングセッションの認証
- Protection against DoS attacks in the control plane
- コントロールプレーンでのDOS攻撃に対する保護
- Protection against malformed packets
- 不正なパケットに対する保護
- Ability to enable/disable specific protocols
- 特定のプロトコルを有効/無効にする機能
- Protection against incorrect cross connection
- 間違ったクロス接続に対する保護
- Protection against spoofed updates and route advertisements
- スプーフィングされた更新およびルート広告に対する保護
- Protection of confidential information
- 機密情報の保護
- Protection against an over-provisioned number of RSVP-TE LSPs and bandwidth reservation
- RSVP-TE LSPの過剰な数の数と帯域幅の予約に対する保護
2) Data-plane protection at the inter-provider connections
2) プロバイダー間接続でのデータプレーン保護
- Protection against DoS in the data plane
- データプレーンのDOSに対する保護
- Protection against label spoofing
- ラベルのスプーフィングに対する保護
For MPLS VPN interconnections [RFC4364], in practice, inter-AS option a), VRF-to-VRF connections at the AS (Autonomous System) border, is commonly used for inter-provider connections. Option c), Multi-hop EBGP redistribution of labeled VPN-IPv4 routes between source and destination ASes with EBGP redistribution of labeled IPv4 routes from AS to a neighboring AS, on the other hand, is not normally used for inter-provider connections due to higher security risks. For more details, please see [RFC4111].
MPLS VPN相互接続[RFC4364]の場合、実際には、オプションa）、As（自律システム）境界でのVRFへのVRF接続は、一般的にプロバイダー間接続に一般的に使用されます。オプションc）、隣接するASからの標識IPv4ルートのeBGP再分布を伴うソースと宛先ASEの間のラベル付きVPN-IPV4ルートのマルチホップEBGP再分布は、通常、プロバイダー間接続に通常使用されていません。より高いセキュリティリスク。詳細については、[RFC4111]を参照してください。
Security considerations constitute the sole subject of this memo and hence are discussed throughout. Here we recap what has been presented and explain at a high level the role of each type of consideration in an overall secure MPLS/GMPLS system.
セキュリティ上の考慮事項は、このメモの唯一の主題を構成するため、全体を通して説明します。ここでは、提示されたものを要約し、全体的な安全なMPLS/GMPLSシステムにおける各タイプの考慮事項の役割を高レベルで説明します。
The document describes a number of potential security threats. Some of these threats have already been observed occurring in running networks; others are largely hypothetical at this time.
このドキュメントは、多くの潜在的なセキュリティの脅威について説明しています。これらの脅威のいくつかは、ランニングネットワークで発生していることがすでに観察されています。この時点では、その他は主に仮説的です。
DoS attacks and intrusion attacks from the Internet against an SPs' infrastructure have been seen. DoS "attacks" (typically not malicious) have also been seen in which CE equipment overwhelms PE equipment with high quantities or rates of packet traffic or routing information. Operational or provisioning errors are cited by SPs as one of their prime concerns.
SPSのインフラストラクチャに対するインターネットからのDOS攻撃と侵入攻撃が見られました。DOSの「攻撃」（通常は悪意のある）も、CE機器がパケットトラフィックまたはルーティング情報の大量またはレートを備えたPE機器を圧倒しています。運用またはプロビジョニングエラーは、SPSが最大の懸念事項の1つとして引用しています。
The document describes a variety of defensive techniques that may be used to counter the suspected threats. All of the techniques presented involve mature and widely implemented technologies that are practical to implement.
このドキュメントでは、疑わしい脅威に対抗するために使用される可能性のあるさまざまな防御技術について説明しています。提示されたすべての手法には、実装するのが実用的な成熟した広く実装されたテクノロジーが含まれます。
The document describes the importance of detecting, monitoring, and reporting attacks, both successful and unsuccessful. These activities are essential for "understanding one's enemy", mobilizing new defenses, and obtaining metrics about how secure the MPLS/GMPLS network is. As such, they are vital components of any complete PPVPN security system.
このドキュメントでは、攻撃を検出、監視、および報告することの重要性について説明します。これは、成功と失敗の両方です。これらのアクティビティは、「敵の理解」、新しい防御の動員、MPLS/GMPLSネットワークの安全性に関するメトリックを取得するために不可欠です。そのため、それらは完全なPPVPNセキュリティシステムの重要なコンポーネントです。
The document evaluates MPLS/GMPLS security requirements from a customer's perspective as well as from a service provider's perspective. These sections re-evaluate the identified threats from the perspectives of the various stakeholders and are meant to assist equipment vendors and service providers, who must ultimately decide what threats to protect against in any given configuration or service offering.
このドキュメントは、MPLS/GMPLSセキュリティ要件を顧客の観点から、およびサービスプロバイダーの観点から評価します。これらのセクションは、特定された脅威をさまざまな利害関係者の視点から再評価し、機器ベンダーとサービスプロバイダーを支援することを目的としています。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747] Baker、F.、Lindell、B。、およびM. Talwar、「RSVP暗号認証」、RFC 2747、2000年1月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication -- Updated Message Type Value", RFC 3097, April 2001.
[RFC3097] Braden、R。およびL. Zhang、「RSVP暗号化認証 - 更新されたメッセージタイプ値」、RFC 3097、2001年4月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、 "RSVP-TE：LSP TunnelsのRSVPへの拡張"、RFC 3209、12月2001年。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945] Mannie、E.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）アーキテクチャ」、RFC 3945、2004年10月。
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, June 2005.
[RFC4106] Viega、J。およびD. McGrew、「セキュリティペイロードをカプセル化するIPSEC（ESP）でのガロア/カウンターモード（GCM）の使用」、RFC 4106、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月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306] Kaufman、C.、ed。、「Internet Key Exchange（IKEV2）Protocol」、RFC 4306、2005年12月。
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)", RFC 4309, December 2005.
[RFC4309] Housley、R。、「Advanced Encryption Standard（AES）CCMモードを使用して、IPSECがセキュリティペイロードをカプセル化する（ESP）を使用して」、RFC 4309、2005年12月。
[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月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379] Kompella、K。およびG. Swallow、「Multi-Protocol Label Switched（MPLS）データプレーン障害の検出」、RFC 4379、2006年2月。
[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4447] Martini、L.、Ed。、Ed。、Rosen、E.、El-Aawar、N.、Smith、T.、およびG. Heron、「ラベル分布プロトコル（LDP）を使用した擬似ワイヤーのセットアップとメンテナンス」、RFC 4447、2006年4月。
[RFC4835] Manral, V., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4835, April 2007.
[RFC4835] Manral、V。、「セキュリティペイロード（ESP）および認証ヘッダー（AH）をカプセル化するための暗号化アルゴリズムの実装要件」、RFC 4835、2007年4月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.2」、RFC 5246、2008年8月。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[RFC5036] Andersson、L.、ed。、Minei、I.、ed。、およびB. Thomas、ed。、「LDP仕様」、RFC 5036、2007年10月。
[STD62] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[STD62] Harrington、D.、Presuhn、R。、およびB. Wijnen、「単純なネットワーク管理プロトコル（SNMP）管理フレームワークを説明するためのアーキテクチャ」、STD 62、RFC 3411、2002年12月。
Case, J., Harrington, D., Presuhn, R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3412, December 2002.
Case、J.、Harrington、D.、Presuhn、R。、およびB. Wijnen、「Simple Network Management Protocol（SNMP）のメッセージ処理とディスパッチ」、STD 62、RFC 3412、2002年12月。
Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002.
Levi、D.、Meyer、P。、およびB. Stewart、「Simple Network Management Protocol（SNMP）アプリケーション」、STD 62、RFC 3413、2002年12月。
Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
Blumenthal、U.およびB. Wijnen、「Simple Network Management Protocol（SNMPV3）のバージョン3のユーザーベースのセキュリティモデル（USM）」、STD 62、RFC 3414、2002年12月。
Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002.
Wijnen、B.、Presuhn、R。、およびK. McCloghrie、「シンプルネットワーク管理プロトコル（SNMP）のビューベースのアクセス制御モデル（VACM）」、STD 62、RFC 3415、2002年12月。
Presuhn, R., Ed., "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002.
Presuhn、R.、ed。、「Simple Network Management Protocol（SNMP）のプロトコル操作のバージョン2」、STD 62、RFC 3416、2002年12月。
Presuhn, R., Ed., "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002.
Presuhn、R.、ed。、「Simple Network Management Protocol（SNMP）の輸送マッピング」、STD 62、RFC 3417、2002年12月。
Presuhn, R., Ed., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002.
Presuhn、R.、ed。、「Simple Network Management Protocol（SNMP）の管理情報ベース（MIB）」、STD 62、RFC 3418、2002年12月。
[STD8] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[STD8] Postel、J。およびJ. Reynolds、「Telnet Protocol Specification」、STD 8、RFC 854、1983年5月。
Postel, J. and J. Reynolds, "Telnet Option Specifications", STD 8, RFC 855, May 1983.
Postel、J。およびJ. Reynolds、「Telnetオプション仕様」、STD 8、RFC 855、1983年5月。
[OIF-SMI-01.0] Renee Esposito, "Security for Management Interfaces to Network Elements", Optical Internetworking Forum, Sept. 2003.
[OIF-SMI-01.0] Renee Esposito、「ネットワーク要素への管理インターフェイスのセキュリティ」、光学インターネットワーキングフォーラム、2003年9月。
[OIF-SMI-02.1] Renee Esposito, "Addendum to the Security for Management Interfaces to Network Elements", Optical Internetworking Forum, March 2006.
[OIF-SMI-02.1] Renee Esposito、「ネットワーク要素への管理インターフェイスのセキュリティへの補遺」、光学インターネットワークフォーラム、2006年3月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. CaNetti、「HMAC：メッセージ認証のためのキー付きハッシング」、RFC 2104、1997年2月。
[RFC2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[RFC2411] Thayer、R.、Doraswamy、N。、およびR. Glenn、「IP Security Document Roadmap」、RFC 2411、1998年11月。
[RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.
[RFC3174] EastLake 3rd、D。およびP. Jones、「US Secure Hash Algorithm 1（SHA1）」、RFC 3174、2001年9月。
[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月。
[RFC3631] Bellovin, S., Ed., Schiller, J., Ed., and C. Kaufman, Ed., "Security Mechanisms for the Internet", RFC 3631, December 2003.
[RFC3631] Bellovin、S.、Ed。、Schiller、J.、Ed。、およびC. Kaufman、ed。、「インターネットのセキュリティメカニズム」、RFC 3631、2003年12月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704] Baker、F。およびP. Savola、「マルチホームネットワークのイングレスフィルタリング」、BCP 84、RFC 3704、2004年3月。
[RFC3985] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985] Bryant、S.、ed。、およびP. Pate、ed。、「Pseudo Wire Emulation Edge-to-Edge（PWE3）Architecture」、RFC 3985、2005年3月。
[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月。
[RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4110, July 2005.
[RFC4110] Callon、R。およびM. Suzuki、「レイヤー3プロバイダーがプロビジョニングした仮想プライベートネットワーク（PPVPNS）のフレームワーク」、RFC 4110、2005年7月。
[RFC4111] Fang, L., Ed., "Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4111, July 2005.
[RFC4111] Fang、L.、ed。、「プロバイダーが提供する仮想プライベートネットワーク（PPVPNS）のセキュリティフレームワーク」、RFC 4111、2005年7月。
[RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security Properties", RFC 4230, December 2005.
[RFC4230] Tschofenig、H。およびR. Graveman、「RSVPセキュリティプロパティ」、RFC 4230、2005年12月。
[RFC4308] Hoffman, P., "Cryptographic Suites for IPsec", RFC 4308, December 2005.
[RFC4308] Hoffman、P。、「IPSEC用の暗号スイート」、RFC 4308、2005年12月。
[RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. Matsushima, "Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks", RFC 4377, February 2006.
[RFC4377] Nadeau、T.、Morrow、M.、Swallow、G.、Allan、D。、およびS. Matsushima、「Operation and Management（OAM）要件マルチプロトコルラベルスイッチ（MPLS）ネットワーク」、RFC 4377、2006年2月。
[RFC4378] Allan, D., Ed., and T. Nadeau, Ed., "A Framework for Multi-Protocol Label Switching (MPLS) Operations and Management (OAM)", RFC 4378, February 2006.
[RFC4378] Allan、D.、ed。、およびT. Nadeau、ed。、「マルチプロトコルラベルスイッチング（MPLS）オペレーションおよび管理（OAM）のフレームワーク」、RFC 4378、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月。
[RFC4778] Kaeo, M., "Operational Security Current Practices in Internet Service Provider Environments", RFC 4778, January 2007.
[RFC4778] Kaeo、M。、「インターネットサービスプロバイダー環境における運用セキュリティ現在の慣行」、RFC 4778、2007年1月。
[RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5", RFC 4808, March 2007.
[RFC4808] Bellovin、S。、「TCP-MD5の重要な変更戦略」、RFC 4808、2007年3月。
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, "Local Network Protection for IPv6", RFC 4864, May 2007.
[RFC4864] van de Velde、G.、Hain、T.、Droms、R.、Carpenter、B。、およびE. Klein、「IPv6のローカルネットワーク保護」、RFC 4864、2007年5月。
[RFC4869] Law, L. and J. Solinas, "Suite B Cryptographic Suites for IPsec", RFC 4869, May 2007.
[RFC4869] Law、L。and J. Solinas、「IPSECのスイートB暗号スイート」、RFC 4869、2007年5月。
[RFC5254] Bitar, N., Ed., Bocci, M., Ed., and L. Martini, Ed., "Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)", RFC 5254, October 2008.
[RFC5254] Bitar、N.、ed。、Bocci、M.、ed。、およびL. Martini、ed。、「マルチセグメント擬似ワイヤーエミュレーションエッジツーエッジ（PWE3）の要件」、RFC 5254、2008年10月。
[MFA-MPLS-ICI] N. Bitar, "MPLS InterCarrier Interconnect Technical Specification," IP/MPLS Forum 19.0.0, April 2008.
[MFA-MPLS-ICI] N. Bitar、「MPLS InterCarrier InterConnect Technical Specification」、IP/MPLS Forum 19.0.0、2008年4月。
[OIF-Sec-Mag] R. Esposito, R. Graveman, and B. Hazzard, "Security for Management Interfaces to Network Elements," OIF-SMI-01.0, September 2003.
[OIF-Sec-Mag] R. Esposito、R。Graveman、およびB. Hazzard、「ネットワーク要素への管理インターフェイスのセキュリティ」、OIF-SMI-01.0、2003年9月。
[BACKBONE-ATTKS] Savola, P., "Backbone Infrastructure Attacks and Protections", Work in Progress, January 2007.
[Backbone-attks] Savola、P。、「バックボーンインフラストラクチャの攻撃と保護」、2007年1月、進行中の作業。
[OPSEC-FILTER] Morrow, C., Jones, G., and V. Manral, "Filtering and Rate Limiting Capabilities for IP Network Infrastructure", Work in Progress, July 2007.
[Opsec-filter] Morrow、C.、Jones、G。、およびV. Manral、「IPネットワークインフラストラクチャのフィルタリングとレートの制限機能」、2007年7月、進行中の作業。
[IPSECME-ROADMAP] Frankel, S. and S. Krishnan, "IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap", Work in Progress, May 2010.
[IPSECME-ROADMAP] Frankel、S。およびS. Krishnan、「IP Security（IPSEC）およびInternet Key Exchange（IKE）Document Roadmap」、2010年5月の作業。
[OPSEC-EFFORTS] Lonvick, C. and D. Spak, "Security Best Practices Efforts and Documents", Work in Progress, May 2010.
[Opsec-Efforts] Lonvick、C。and D. Spak、「セキュリティベストプラクティスの取り組みと文書」、2010年5月の進行中。
[RSVP-key] Behringer, M. and F. Le Faucheur, "Applicability of Keying Methods for RSVP Security", Work in Progress, June 2009.
[RSVP-Key] Behringer、M。およびF. Le Faucheur、「RSVPセキュリティのためのキーイングメソッドの適用可能性」、2009年6月、進行中の作業。
The authors and contributors would also like to acknowledge the helpful comments and suggestions from Sam Hartman, Dimitri Papadimitriou, Kannan Varadhan, Stephen Farrell, Mircea Pisica, Scott Brim in particular for his comments and discussion through GEN-ART review,as well as Suresh Krishnan for his GEN-ART review and comments. The authors would like to thank Sandra Murphy and Tim Polk for their comments and help through Security AD review, thank Pekka Savola for his comments through ops-dir review, and Amanda Baber for her IANA review.
著者と貢献者は、特にジェンアートレビューを通じて彼のコメントや議論、およびスレシュ・クリシュナナナナナナナナナナナナナナナナナナがサム・ハートマン、ディミトリ・パパディミトリウ、カンナン・バラダン、カンナン・バラダン、スティーブン・ファレル、スコット・ブリムからの有益なコメントと提案を認めたいと思います。彼のgen-artのレビューとコメントのために。著者は、サンドラ・マーフィーとティム・ポークのコメントに感謝し、セキュリティ広告のレビューを通じて支援、OPS-DIRレビューを通じて彼のコメントについてペッカ・サヴォラに感謝し、アマンダ・バベルが彼女のIANAレビューをしてくれました。
This document has used relevant content from RFC 4111 "Security Framework of Provider Provisioned VPN for Provider-Provisioned Virtual Private Networks (PPVPNs)" [RFC4111]. We acknowledge the authors of RFC 4111 for the valuable information and text.
このドキュメントでは、RFC 4111「プロバイダープロビジョンプロビジャーVPNのセキュリティフレームワーク（PPVPNS）のプロバイダープロビジョニングVPNのセキュリティフレームワーク」[RFC4111]を使用しています。貴重な情報とテキストについては、RFC 4111の著者を認めます。
Authors:
著者：
Luyuan Fang, Ed., Cisco Systems, Inc. Michael Behringer, Cisco Systems, Inc. Ross Callon, Juniper Networks Richard Graveman, RFG Security, LLC J. L. Le Roux, France Telecom Raymond Zhang, British Telecom Paul Knight, Individual Contributor Yaakov Stein, RAD Data Communications Nabil Bitar, Verizon Monique Morrow, Cisco Systems, Inc. Adrian Farrel, Old Dog Consulting
Luyuan Fang、ed。、Cisco Systems、Inc。Michael Behringer、Cisco Systems、Inc。Ross Callon、Juniper Networks Richard Graveman、RFG Security、LLC J. L. Le Roux、France Telecom Raymond Zhang、British Telecom Paul Knight、個人貢献者Yaakov Stein、Rad Data Communications Nabil Bitar、Verizon Monique Morrow、Cisco Systems、Inc。Adrian Farrel、Old Dog Consulting
As a design team member for the MPLS Security Framework, Jerry Ash also made significant contributions to this document.
MPLSセキュリティフレームワークの設計チームメンバーとして、ジェリーアッシュはこのドキュメントにも大きな貢献をしました。
Michael Behringer Cisco Systems, Inc. Village d'Entreprises Green Side 400, Avenue Roumanille, Batiment T 3 06410 Biot, Sophia Antipolis FRANCE EMail: mbehring@cisco.com
Michael Behringer Cisco Systems、Inc。Village D'Entreprises Green Side 400、Avenue Roumanille、Batiment T 3 06410 Biot、Sophia Antipolis France Email：mbehring@cisco.com
Ross Callon Juniper Networks 10 Technology Park Drive Westford, MA 01886 USA EMail: rcallon@juniper.net
ロスコロンジュニパーネットワーク10テクノロジーパークドライブマサチューセッツ州ウェストフォード01886 USAメール：rcallon@juniper.net
Richard Graveman RFG Security 15 Park Avenue Morristown, NJ 07960 EMail: rfg@acm.org
リチャードグレイグマンRFGセキュリティ15パークアベニューモリスタウン、ニュージャージー07960メール：rfg@acm.org
Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex FRANCE EMail: jeanlouis.leroux@francetelecom.com
Jean-Louis Le Roux France Telecom 2、Avenue Pierre-Marzin 22307 Lannion Cedex Franceメール：jeanlouis.leroux@francetelecom.com
Raymond Zhang British Telecom BT Center 81 Newgate Street London, EC1A 7AJ United Kingdom EMail: raymond.zhang@bt.com Paul Knight 39 N. Hancock St. Lexington, MA 02420 EMail: paul.the.knight@gmail.com
Raymond Zhang British Telecom Bt Center 81 Newgate Street London、EC1A 7AJ United Kingdom Email：Raymond.zhang@bt.com Paul Knight 39 N. Hancock St. Lexington、MA 02420メール：Paul.knight@gmail.com
Yaakov (Jonathan) Stein RAD Data Communications 24 Raoul Wallenberg St., Bldg C Tel Aviv 69719 ISRAEL EMail: yaakov_s@rad.com
Yaakov（Jonathan）Stein Rad Data Communications 24 Raoul Wallenberg St.、Bldg C Tel Aviv 69719 Israel Email：yaakov_s@rad.com
Nabil Bitar Verizon 40 Sylvan Road Waltham, MA 02145 EMail: nabil.bitar@verizon.com
Nabil Bitar Verizon 40 Sylvan Road Waltham、MA 02145メール：nabil.bitar@verizon.com
Monique Morrow Glatt-com CH-8301 Glattzentrum Switzerland EMail: mmorrow@cisco.com
Monique Morrow Glatt-Com CH-8301 Glattzentrum Switzerlandメール：mmorrow@cisco.com
Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk
Adrian Farrel Old Dog Consultingメール：adrian@olddog.co.uk
Editor's Address
編集者のアドレス
Luyuan Fang (editor) Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 USA EMail: lufang@cisco.com
Luyuan Fang（編集者）Cisco Systems、Inc。300 Beaver Brook Road Boxborough、MA 01719 USAメール：lufang@cisco.com