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
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の文脈に関連するセキュリティの側面に対処しています。これは、セキュリティ上の脅威、関連守備の技術、および検出および報告のためのメカニズムについて説明します。この文書では、構築し、異なるドメインまたは異なるサービスプロバイダ間でMPLSとGMPLSネットワークを維持するためにRSVP-TE及びLDPセキュリティの考慮事項のほか、インター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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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とGMPLSは、[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ネットワークのセキュリティ特性のために期待しています。これらは、機器サポートMPLSと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].
セキュリティ上のリスク要因が相互プロバイダ接続と高いためのInter-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
本文書に、私たちが接続されているユーザサイトを含めないMPLSとGMPLSネットワークに関連するプロバイダのセキュリティ要件を記述するに自分自身を制限し、それを明確にすることが重要です。読者は、「セキュリティのベストプラクティスの取り組みを参照してもよいし、
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.
『一般的なネットワーク運用のセキュリティの考慮事項については、[RFC3631]。これは、正確な定式化するために、しかし、我々の意図ではない『インターネットのためのドキュメント」[OPSEC-努力]と』セキュリティメカニズムのメカニズムを定義するという点で、それぞれ特定の技術要件を』とこのようなセキュリティ要件を満たすために実装しなければならない技術。
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
サービスの自律システムASBR自律システム境界ルータATM非同期転送モードBGPボーダーゲートウェイプロトコルBFD双方向フォワーディング検出CEカスタマーエッジデバイスのCoSクラスCPU中央演算処理装置サービスESPカプセル化セキュリティペイロードFEC転送等価クラスGMPLSのDNSドメインネームシステムのDoS拒否AS IPバージョン6 IGP内部ゲートウェイプロトコルIKEインターネットキー交換IPインターネットプロトコルのIPsec IPセキュリティIPVPN IPベースVPN LDPラベル配布でGCMガロアカウンタモードGRE総称ルーティングカプセル化ICIインタインターコネクトICMPインターネット制御メッセージプロトコルのICMPv6 ICMPスイッチング汎用マルチプロトコルラベルMP-BGPマルチプロトコルBGP NTPネットワークタイムプロトコルOAM運用、管理、およびメンテナンスPCE経路計算エレメントPE PスイッチングルータMD5メッセージダイジェストアルゴリズムMPLSマルチプロトコルラベルスイッチングプロトコルL2TPレイヤ2トンネリングプロトコルLMPリンク管理プロトコルLSPラベルスイッチパスのLSRラベルrovider-EdgeデバイスPPVPNプロバイダー・プロビジョニングされた仮想プライベートネットワークPSNパケット交換ネットワーク
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
トラフィックエンジニアリングの拡張SLAサービスレベル契約SNMP簡易ネットワーク管理プロトコルSPサービスプロバイダーSSHとサービスRRルートリフレクタRSVPリソース予約プロトコルRSVP-TEリソース予約プロトコルのPW擬似回線のQoS品質TCP TCP伝送制御におけるシェルSSLセキュア・ソケット・レイヤーSYN同期パケットを固定しますサービスTTLのTime-To-ライブUDPユーザーデータグラムプロトコルVCのプロトコルTDM時分割多重TEトラフィックエンジニアリングTLSトランスポートレイヤセキュリティのToSタイプIETF WSS WebサービスセキュリティのバーチャルサーキットVPN仮想プライベートネットワークWGワーキンググループ
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).
（同一の転送処理と、同じ経路上に、例えば）同じ方法で転送されるIPパケットのグループ：等価クラス（FEC）を転送します。
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.
ラベルスイッチングルータ（LSRの）：MPLS / GMPLSノードは、（a）は、パケットまたはセルの境界のいずれかを認識し、そして（b）パケットヘッダ又はセルヘッダーのいずれかを処理することが可能である転送プレーンを有するもの。
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ルーティングおよび転送を実行し、一方の引き回し又は管理ドメインにもあるノードの隣接セット。
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エッジノード：ドメイン外のノードと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イングレスノード：それは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制御プロトコルを認識している一つまたは複数のルーティングプロトコルを実行し、ラベルに基づいてパケットを転送することが可能です。 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ラベルとデータパケットを割り当てます。代わりに、従来のIPフォワーディングのように、各パケットの宛先のための最長一致を実行する、MPLSはパケット自体を調査することなく、単にラベルの内容のパケット転送を決定します。これは、任意のプロトコルを使用して、輸送媒体の任意のタイプを横切ってエンド・ツー・エンド回路の作成を可能にします。
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バックボーンを利用して、サイトのセットとの間の通信を制限します。
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.
信頼ゾーンは、単一のサービスプロバイダ内のAS単独での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.
個々のネットワークのセキュリティプロパティを分析する際に信頼ドメインの境界は慎重に定義する必要があり、例えば、境界はリンク終了、リモートピア、エリア、または非常に一般的に、のASにすることができます。
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相互プロバイダー接続またはインターインターコネクト（ICI）の場合には、各プロバイダの信頼ゾーンは、（図2のプロバイダB用プロバイダAとASBR3とASBR4ためASBR1およびASBR2）それぞれのASBRで終了します。
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.
また、隣人は、信頼できるか、信頼できないことがあります。隣人は許可または無許可することができます。認可隣人は隣人1は、とのピアリング関係を確立しています。ネイバーが通信を許可することができるにもかかわらず、それが信頼できない場合があります。例えば、AS間のLSPを設定するには、別のプロバイダのASBRはと接続する際に、他のプロバイダが信頼されていないが、認可隣人と考えられています。
+---------------+ +----------------+
| | | |
| 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インフラストラクチャ上の攻撃が成功すると、以下の悪影響の一つ以上を引き起こすことがあります。
- 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相互プロバイダー接続の場合に他のSP。他のプロバイダのコアまたは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にシングルSPから膨張するが設けられている。これを介して共有インフラとしてマウントすることが容易となりやすくなります。厳密に制御された環境での懸念を正当化するのに十分ならしさのではないかもしれない攻撃は、多くの場合、広い、よりオープンな環境での防衛策に値します。閉じられた社会では、多くの場合、事実の後に不正行為に対処するために実用的である：従業員は、例えば、懲戒することができます。
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.
これらの攻撃であっても、彼らはそれ以外の場合は除外される可能性がありますルータ間で追加のRSVP（または他の）メッセージを転送するために、不正なLSPを使用することによって、組み合わせることができます。それらをフィルタリングするための有効なメカニズムが存在しない場合は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.
自民党に対する攻撃の二つの重要な種類があります。不正なネットワーク要素は、LSPの潜在的なセットアップにつながる、LDPこんにちは、LDP初期化メッセージを送信するだけでなく、LDP状態テーブルの消費を伴うことにより、LDPセッションを確立することができます。でも成功したLSPを確立することなく、攻撃者がターゲットルータ上の高いCPU使用率または表スペースの枯渇につながる、LDP HelloメッセージやLDP TCP SYNメッセージの嵐の形でのDoS攻撃を仕掛けることができます。
DoS attacks could be accomplished through an MPLS signaling storm, resulting in high CPU utilization and possibly leading to control-plane resource starvation.
DoS攻撃は、高いCPU使用率をもたらし、おそらくはリソース不足を、平面を制御する主要、MPLSシグナリングストームを介して達成することができます。
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.)
コントロールプレーンのDoS攻撃は、例えば、PルータまたはPEルータの共有側面、SPは、様々なサービスを提供するために使用するメカニズムに対して、またはサービスプロバイダの一般的なインフラストラクチャに対して特異的に装着することができます。 （一般的なインフラストラクチャに対する攻撃は、攻撃がMPLS / GMPLSインフラストラクチャとの関係で発生することができた場合のみ、この文書の範囲内であり、そうでない場合は、MPLS / GMPLS特有の問題ではありません。）
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攻撃も可能です。
4.1.6. Attacks on the SP's MPLS/GMPLS Equipment via Management Interfaces
4.1.6. 管理インターフェイスを経由してSPのMPLS / GMPLS機器に対する攻撃
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.
- 二つ以上の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).
事例証拠は、クロスコネクトの脅威は、ユーザーの最大のセキュリティ上の懸念事項の一つである（またはユーザー-だろう）ことを示唆しています。
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)
- データベースに基づく会員の発見（例えば、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ネットワークのエンドユーザの視点から、このの一部は例えば、ルーティングプロトコルがIPまたは非IP接続を介してユーザサイトAからユーザサイトBに実行し、コントロールプレーントラフィックであるかもしれないことに注意してください、いくつかのタイプとすることができます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
MPLS-ICI全体で運用し、また、経営陣は、プロバイダのインフラストラクチャのセキュリティ脅威の源としてだけでなく、MPLS-ICI上で提供するサービスである可能性があります。 ASBRが適切に保護されていない場合は運用管理のメッセージの大量は、ASBRの処理能力を圧倒することができます。悪意を持って生成されました
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擬似回線）をダウンさせるので、サービスのセキュリティに影響を与えるために使用することができます。 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).
1時間で、慎重なアクセス制御やパスワードの管理は十分な防衛なかったが、もはやです。 TCP / IPプロトコルスイートを使用するネットワークは、盗聴や改ざんを容易にするために、トラフィックの再ルーティング、パケットスニファは、パスワードを拾って、TCP接続のアクティブハイジャック攻撃偽造送信元アドレス、記録し、後で再生に対して脆弱であり、denial-の様々なサービス攻撃。 TCP / IPパケットを鍛造の容易さは、強力なセキュリティを欠いているネットワーク管理プロトコルは（SNMP SETコマンドを使用して、例えば、）ネットワーク要素を構成するために使用されていない主な理由です。
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コネクションの一端を引き継ぐましょう存在します。また、いくつかの法域における企業やサービスプロバイダは、詮索好きから自分のユーザーとネットワーク構成に関するデータを保護する必要があります。攻撃者が使用パターンを分析し、ネットワーク構成をマップするためにトラフィックを盗聴して観察することができました。攻撃者はシステムにアクセスし、構成データを操作したり、悪質なコマンドを送信することができます。
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.
信頼モデルのチェーンは、MPLSとGMPLSネットワークは、インサイダー攻撃に対して特に脆弱であることを意味しています。これらは、信頼ドメイン内の任意のLSRへのアクセス権を持つ任意の悪性人によって起動することができます。インサイダー攻撃も信頼ドメイン内妥協し、ソフトウェアで起動することができました。このような攻撃は、例えば、存在しないリソースを宣伝し、他のルータからの広告を修正することができ、ネットワークリソースを使用し、不要な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.
このドキュメントで説明守備の技術は、いくつかのセキュリティ上の脅威に対処することができる方法を説明することを意図しています。これらは、すべてのMPLS / 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攻撃を軽減する方法の一つは、無実の当事者が攻撃を増幅するために使用することができないことを確認することです。それは「に設計された」というより「上の追加」されたときにセキュリティが良い作品。
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 / GMPLS内のデバイスは、唯一の有効な情報源からの接続や制御メッセージを受け入れる必要があることが重要です。認証は、メッセージのソースが適切にそれらが通信する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の認証を含みます。
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など）および他のピア認証のためのピア認証を含む（すなわち、別のずつ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.
暗号技術は、デバイスまたは個人の身元を認証するためのいくつかのメカニズムを提供します。これらは、共有秘密鍵、付属装置またはソフトウェアによって生成されたワンタイムキー、ユーザーIDとパスワードのペアを使用すると、公開鍵と秘密鍵のシステムの範囲を含みます。別のアプローチは、デジタル証明書を提供するために、階層的な認証局システムを使用することです。
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がMPLS / GMPLSプロバイダによってプロビジョニングされたときに/ GMPLSのセキュリティフレームワークをMPLSこの範囲内に収まります。
- 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.
- ユーザが顧客の場所ではない場所でシステムからそのサイトへのリモートアクセスを必要とする場合（たとえば、ユーザーによるアクセス）は、暗号そのシステムとアクセスポイントまたは間のトラフィックを保護する必要があるかもしれませんお客様のサイト。 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.
MPLS / GMPLSプロバイダは、CE（暗号化）デバイスを完全に管理制御を持っている場合は、CE-CE暗号保護は、第三者に対して完全性と機密性を提供することができるが、プロバイダがユーザーのトラフィックや内部へのアクセスを得るためにするために、それは可能かもしれません通信網。暗号化デバイスは、潜在的に、完全にヌル暗号化、バイパス暗号処理を使用して内部構造を明らかにする、または暗号化されていないトラフィックを盗聴や流用のいくつかの手段を提供するように再構成することができます。したがって、CE-CEの暗号化を使用して実装は、MPLS / GMPLSのユーザーとプロバイダ間の信頼関係を考慮する必要があります。 MPLS / GMPLSのユーザーとプロバイダは、CEデバイス上の暗号保護の管理のための責任の許容可能な境界を提供して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] [IPSECME-ROADMAP] IPレイヤでの保護のための選択のセキュリティプロトコルです。 IPsecは、デバイスのペアの間のIPトラフィックのための強固なセキュリティを提供します。非IPトラフィックは、IS-ISなどのルーティング例えば、IPsecを使用するために（例えば、カプセル化によって）IPに変換されなければなりません。 MPLSは、IPトラフィックをカプセル化した場合、その後、IPsecはIPクライアント層の暗号化をカバー。非IPクライアントのトラフィックのために、5.2.4項（MPLS PWの）を参照してください。
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とCEの間、またはCEからCEに、PE間のIPトラフィックを保護するために使用することができます。 CE-に-CE IPsecは、プロバイダ・プロビジョニングまたはユーザプロビジョニングモデルのいずれかで使用することができます。それは単にMPLS / GMPLSコアにより、ユーザデータとして処理されるため同様に、ユーザーのサイト内で実行されるデータのIPsec保護は、この文書の範囲外です。 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.
このような暗号ブロック連鎖モードとして、そのような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]でAESを使用することです。
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とGMPLSは、トラフィックのIPsec暗号化といくつかの競合が発生する場合があります。暗号化は、パケットの内容を隠しているので、暗号化されていないトラフィックと同様に暗号化されたトラフィックを区別することはできないかもしれません。 Diffservのマーキングは、IPsecヘッダにコピーされ、いくつかの分化を提供することができるが、必ずしもすべてのトラフィックタイプは、この機構によって収容することができます。 IKEまたはIKEv2の（より良い選択）することなく、IPsecを使用することはお勧めできません。 IKEv2のは、IPsecセキュリティアソシエーションの作成と管理、エンティティ認証、鍵交換、および鍵の更新を提供します。これは、事前共有鍵、公開鍵証明書、およびEAPなどの認証方法の多様で動作します。 IKEv2のに対してDoS攻撃を軽減するための重要な脅威とみなされる場合は、IKEv2ののクッキーベースのアンチスプーフィング機能を使用する必要があります。 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.
- シェル（SSH）は、デバイスの設定を可能にするためにTELNET [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の限られた展開、および特にTELNET、のようなインターフェースのために、Kerberosを使用する可能性に、SNMPを確保するためにSSHを使用する方法を定義することがありますクライアントコードは存在しています。
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コアを介して疑似回線（PWの）そのトンネルネイティブサービスを設定することによって行われます。 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トンネルは[RFC4447] LDPに基づい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のユーザパケットは、少なくとも一つのMPLSラベル（PWラベル）を含み、一つ以上の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.
これらの脅威は、マルチセグメントPWSが彼らのステッチポイントで追加の弱点を導入など、スヌーピングまたは挿入/削除/再生に使用することができリルーティング、例えば、相互に排他的ではありません。
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 .
- なし（固定）ピア自動検出技術が標準化されています。
- 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.
- あるいは、所望のPWは、サービスの拒否を引き起こす、解体されてもよいです。
The following characteristics of PWs can be considered security strengths:
PW次の特性は、セキュリティ強度を考慮することができます。
- 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).
- のPEは通常、（IPパケットがPWパケットになりすますことができないので）、従って、外部からのPWパケットの挿入を除外、サービス・プロバイダ・ネットワークの外部からMPLSパケットを拒否するように構成されています。
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.
暗号保護は、通常、それらの間を通過するトラフィックを保護するデバイスのペアを必要とします。デバイスは、直接（単一の「ホップ」の上に）接続することができる、またはデバイスを介在するデバイスのペアの間の保護されたトラフィックを転送することができます。極端な場合には、（ホップバイホップ）所定の経路に沿ってデバイスのすべての隣接する対の間の保護を使用して、または指定されたパス（エンドツーエンド）に沿ってのみエンドデバイス間の保護を使用することを含みます。この文書の範囲内でこの議論を維持するために、ここで検討後者（「エンドツーエンド」）場合がto-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は、2つの部位の間の経路に沿って存在するかもしれないプロバイダーコア（P）デバイスのカスタマエッジ（CE）デバイス、プロバイダエッジ（PE）デバイス、および可変数を示す簡略化されたトポロジー（3つ示されている）を示しています単一のVPNに単一のサービスプロバイダ（SP）によって運営。
Site_1---CE---PE---P---P---P---PE---CE---Site_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デバイスが暗号保護に関与していないと仮定内、四つの基本的な、実行可能な構成は、装置間の接続を保護するために存在します。
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-に-CE） - トラフィックがSPのネットワーク全体に保護されるように、2つのCEデバイス間で機密性や完全性サービスを適用します。
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-に-PE） - 2つのPEデバイス間で機密性や完全性サービスを適用します。保護されていないトラフィックは、それが他のPEにSPのネットワークを介して送信するために保護され、顧客のCEから1個の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ツー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はまた、PEはCEに次いでPEのPE次いで、機密性や完全性は、CEから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?
- デバイスの構成と管理の複雑さ - NCE、多くのデバイス構成を作成または維持する必要がある、とどのようにそれらの構成の規模をどのように行うNPE、として与えられたVPNに参加するPEの数としてVPNの顧客ごとのサイト数与えられましたか？
- 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-に-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.
複雑 - VPNごとサイトごとに1台のデバイス（NCEデバイス）を担当する単回投与、が、全体の構成は、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.
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マーキングは、いくつかのQoSサービスをできるように、SPに表示されます。 CEはまた、トラフィッククラスを識別するためのIPv6フローラベルを使用することができます。
2) Provider Edge-to-Edge (PE-to-PE)
2）プロバイダ・エッジ・ツー・エッジ（PE-に-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デバイスが構成します。 （NPEは、典型的には、NCEよりもはるかに小さいので、複数のサイトがPEデバイスを共有することができる）全体構成のスケーラビリティPPVPNタイプに依存：暗号化保護はVPNコンテキストごとに別個である場合、それは顧客VPN当たりNPEとして** 2をスケーリングします。それは-PEごとであれば、それは結合されたすべての顧客のVPNの2 **としてNPEスケール。
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ツーPE）
Link eavesdropping or tampering - protected on CE-PE link;
vulnerable on SP's network 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), 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個のPEのそれぞれに、各パケットは、暗号（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）複合アクセスリンク及びPE-に-PE（本質的にホップバイホップ）。
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ごとであれば、それは結合されたすべての顧客のVPNの2 **としてNPEスケール。
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個のPEのそれぞれに、各パケットは、暗号二回（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のサブセットです。これらの結論の残りは4（合わせアクセスリンクおよびPE-に-PE）対1（CE-に-CE）を比較します。
- If protection from link eavesdropping or tampering is all that is important, then configurations 1 and 4 are equivalent.
- リンクの盗聴や改ざんからの保護は、すべてのことが重要であるである場合には、構成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アプローチの下で、4のスケーリングはさらに、すべてのVPNコンテキストを横切るメッシュ同じPE-PEを共有することによって改善されます。 4のスケーリングの利点は、増加またはCEデバイスがPEデバイス、またはその逆よりも構成が簡単であれば、任意の所与の状況に減少させることができます。
- 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.
- 全体的な処理負荷が重要な要因である場合にはPEがハードウェア暗号化アクセラレータに来て、CEがない場合を除き、その後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保護は、デバイスの妥協案に対して優れているが、これは原因次数（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対PまたはPE対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.)
- 特定のセグメント上で複数の暗号化を行うには理由があるかもしれません。一つは、暗号化された電子メールの添付ファイルダウンロードするにはSSLで保護されたWebサイトにアクセスするために私たちのIPsec VPNの下で暗号化された無線リンクを使用している可能性があり：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:
定義は二つの重要な帰結があります。
- 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.
多くの場合、フィルタ特性は、ステートレスであってもよいです。ステートレスフィルタは、特定のパケットがフィルタ定義、（例えば、パケットの次のホップとして）通常の転送情報のみに基づいてフィルタ、パケットが到着したインタフェース、およびその個々のパケットの内容と一致するか否かを判定する。典型的には、ステートレスフィルタは、TCPまたはUDPヘッダとして上位層ヘッダの着信および発信論理的または物理的インターフェイス、IPヘッダ内の情報、及び情報を考慮することができます。例えば、5月考慮すべきIPヘッダ内の情報は、送信元および宛先IPアドレスを含みます。 IPv4のプロトコルフィールド、フラグメントオフセット、及びTOSフィールド。または次ヘッダ、拡張ヘッダ、フローラベルなどIPv6のインチフィルタはまた、ポート番号、TCPヘッダ内のSYNフィールドとしてTCP又はUDPヘッダ内のフィールド、ならびにICMPおよびICMPv6のタイプを考慮することができます。
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攻撃（DDoS攻撃）攻撃、または（例えば、不正なソースからネットワーク管理パケットなどの）許可されていないリソースにアクセスしようとするパケットの一部であるパケットを含むことができます。このようなフィルタが活性化される場合、パケットまたはサイレントフィルタに一致するパケットのセットを破棄することが一般的です。廃棄されたパケットは、もちろんカウント又は記録されることができます。
- 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から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コアネットワーク機能を保護するために適用することができます
MPLS/GMPLS user sites, but typically other defensive techniques will be used for this purpose.
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ユーザ、および単一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攻撃を処理するますます重要になってきています。便利なガイドラインは次のとおりです。
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/).
オプティカル・インターネットフォーラムは、[OIF-SMI-01.0]と「補遺セキュリティの管理の「ネットワーク要素への管理インタフェースのセキュリティ」を参照してくださいなどTLS、SSH、ケルベロス、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.
それらはアウトオブバンド、物理的または論理的にMPLS / 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のサポートに使用されるインフラストラクチャを保護する一つの方法は、（例えば、インターネットサービスのサポートなど）他の目的のために使用されるリソースから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ベースIPVPNsは、インターネットに接続されていない別バックボーン上で実行することができる、またはインターネットサービスをサポートするものとは別のエッジ・ルータを使用することができます。 （インターネット上で提供し、ルーティング不可能にローカル）プライベート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対応サービスの主な理由の一つは、複数のサービスと複数のユーザー間でのリソースの共有を可能にすることです。このように、特定のサービスは、インターネットサービスから独立したネットワークを使用している場合でも、それにもかかわらず、依然として同じネットワークリソースを共有する複数の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）ごとまたはインターネット接続あたりのレート制限を使用しました。またはコントロールプレーントラフィックのためのリソース予約を使用します。帯域幅の保護に加え、個別の資源配分にのみに直接影響を受けたサービス（複数可）または顧客（S）セキュリティ攻撃を制限するために使用することができます。厳格な、別個の、明確に定義されたエンジニアリング規則及びプロビジョニング手順は、コントロールプレーンの攻撃、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の暗号化にもダメージを制限することがあります。
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 / GMPLSのセキュリティ攻撃を検出するために使用される監視システムは、典型的には、プロバイダエッジ（PE）、カスタマエッジ（CE）から情報を収集することによって動作する、および/またはプロバイダバックボーン（P）デバイス。セキュリティ監視システムを積極的にデバイスから情報を取得する機能を持っていなければならない（例えば、SNMPを取得する）または受動デバイス（例えば、SNMP通知）からの報告を受信します。システムは、積極的に（例えば、SNMPを取得する）または受動デバイス（例えば、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の型モニタリング及び検出機構は、いくつかの攻撃を検出することができるが、このようなNetFlowベーストラフィックフィンガープリントなど、他の技術、（通常はプロトコルの隣接関係、CPUの過負荷シナリオ、等フラッピングから生じる）、より詳細な検出および報告のために必要とされます。
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).
- 自律システム（のAS）のBGPルーティングを含むネクストホップ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
コア内のノードの送信元IPアドレスを偽装伴うコアで実行されているプロトコルの多くの攻撃（例えば、TCP-RST攻撃）。それは、及び/又は防止することにより、[RFC3704]の転送厳密ユニキャストリバースパス（uRPFの）を使用して、例えば、エッジでスプーフィング防止フィルタを適用することは理にかなって
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.
ソースとしてのインフラアドレスの使用。これが包括行われている場合は、暗号的にこれらのプロトコルを確保する必要性が小さくなっています。より精巧な説明については、[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.
今日のプロセッサでは、コントロールプレーンに暗号認証を適用すると、かなりのプロバイダーの展開のコストを増加させないこと、およびコアのセキュリティを向上させるのに役立ちます。コアは、第三者への配線なし/ GMPLS対応のサービスをMPLSに専用されている場合、これはコア制御プレーンの認証のための要件を低減することができます。
- 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.
通常のTTL伝播はバックボーンを作るために変更することができる外部から1つのホップのように見えますが、注意がループ防止のために取られる必要があります。これは、トレースルートを介して公開されることから、バックボーンアドレスを防ぎます。しかし、これは、エンド・ツー・エンドの障害追跡のための運用要件に照らして評価する必要があります。
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.
インターネットバックボーンコアは、例えば、コア内のすべてのトラフィックのためのスイッチングおよびおそらくはPPVPNコア自体の内部にインターネットVPNを作成するMPLSラベルを用いて、エッジ機能ルーティングインターネットを作るために再設計であってもよいです。これは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デバイス上に実装されてもよいです。これは、1つの特定のエリアに襲われたときに問題を制限するのに役立つかもしれない、と各平面は、別途追加のセキュリティ対策を実施することを可能にします。
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)
PEはその性質上、外部ユーザから到達不能にすることはできませんので、PEは、多くの場合、Pルータよりも攻撃に対してより脆弱です。コアトランクリソースへのアクセスは、インバウンドレート制限やトラフィックシェーピングを使用することによって、ユーザーごとに制御することができます。これはさらに、クラスごとのサービス毎に向上させることができる（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のための重要なセキュリティメカニズムです。しかし、AS間のLSPのためのASBR-ASBRの通信は、具体的に確保する必要があります。分離機構はまた、次ヘッダ0パケットを使用してIPv4ルーター警告またはIPv6によってバイパスされるかもしれません。ソリューションは、IPオプションの処理を無効にすることで構成することができます。これは、RSVPが使用するルーターの警告オプションを含むIPv4オプションを持つすべてのIPパケットを廃棄したり無視します。しかし、これは、IPv4オプションを使用して、他のプロトコルに影響を与えることができます。代替的には、IPv4プロトコルまたはIPv6の次のヘッダ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.
のみ、特定のネイバーのポート46でIPパケットを受け入れるために、アクセスリストで、データプレーンレベルでのフィルタリングRSVP隣人は、非アクティブにするためにルータアラートモードを必要とし、なりすましを防ぐことはできません。
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.
もう一つの貴重なツールは、与えられた期間内に特定のネイバーに送信された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ベースの攻撃から保護するための最も強力なツールの一つです。これは、RSVP隣人で共有キーを使用してセキュアメッセージハッシュに基づいてメッセージを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-キー]に詳細に記載されています。
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.
LDPベースの攻撃からMPLSルータを保護するための方法の特定のインターフェイス上の分離、プロトコル非活性化を含む、RSVPのものと類似している、プロトコルレベルでLDPネイバーのフィルタリング、アクセスデータプレーンレベルでLDPネイバーのフィルタリング（ TCPおよびUDPポート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 / GMPLS、ATM、またはフレームリレーネットワークでは、暗号化は、基本的な機能として提供されていません。セクション5で説明されたメカニズムは、MPLSコアを介して搬送されるMPLSデータプレーントラフィックを保護するために使用することができます。フレームリレーフォーラムとATMフォーラムはどちらも1990年代後半に暗号化セキュリティサービスを標準化し、これらの規格は、広く実装されていません。
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などのインタープロバイダー接続、暗号保護機構の場合には、AS間使用されてもよいです。
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のプラットフォーム上に設けられている場合、異なるWANアドレス空間は、分離を向上させるために、異なるサービス（例えば、VPNおよび非VPN）のために使用することができます。
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間の制御アクセスを提供するために使用され得ます。隣人単位および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.
インタープロバイダ接続、アクセス保護、リンク認証、及び上述のようにルーティングポリシーの場合にも適用することができます。 AS間の両方のインバウンドおよびアウトバウンドのファイアウォールまたはフィルタリングメカニズムが適用されてもよいです。適切なセキュリティ手順は、プロバイダのネットワークインフラストラクチャとその顧客を保護するためにインタープロバイダの相互接続で実装する必要があります。これは、カスタムの各インタープロバイダピアリング接続用に設計されてもよいし、両方のプロバイダが合意しなければなりません。
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.
MPLS / QoS対応サービスを提供する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自体に対する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 VPNの場合です。
- 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インタインターコネクト（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セッションのために必要とされてもよいです。機器は、ピアリングASBR間、NULL暗号化および認証で、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.
RSVP-TE整合オブジェクトとMPLS-ICI（即ち、LDPシグナリングおよびBGPルーティング）の範囲内でのすべてのTCPベースのプロトコルのメッセージ認証サポートとメッセージ認証は、現在の慣行と相互運用するために提供されなければなりません。装置は、ピアリングASBR間、認証ではなくNULLの暗号化トンネル又はトランスポートモードにおける単一のIPsecアソシエーションペア上のすべてのシグナリングおよびルーティング（LDP、RSVP-TE、およびBGP）プロトコルメッセージの交換をサポートすることができなければなりません。 IPsecは、サポートされている場合、HMAC-SHA-2および任意にSHA-1を用いてHMAC-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擬似回線）をダウンさせるために使用されるので、サービスのセキュリティに影響を与える可能性があります。 LSPピングは、今日の認証をサポートしていない、とそのサポートは将来の検討のための対象とすべきです。双方向フォワーディング検出（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ピング[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ケースで、例えば等、トラフィックハイジャックをもたらす状況、ブラックホール化、リソースが盗む（例えば、経路の数）を防ぐことができなければなりません、オペレータは、関連するルートターゲット属性に基づいて経路を遮断することができなければなりません。また、機構は、与えられた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.
機器（のASBRとルートリフレクタ（RRS））BGPの支持動作属性はICI横切ってBGPピアとの間で送信され、受け入れられているルートターゲットを制限することができなければなりません。機器（ASBRは、RRは）も誤ったルートターゲットを送信すると、VPNの間違った相互接続をもたらすことができるので、ルートターゲットは、それがピアから受け入れるどの属性に関するピアに通知することができなければなりません。また、ピアに不適切なルートターゲットを送信することは、機密情報を開示することができます。これは、ルーティングプロトコル攻撃に対する防御の別の例です。
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.
パスAS、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メッセージ）に関する機密情報を明らかにすることができる信頼されたドメインを残してから、機密情報を含むメッセージを識別し、ブロックする能力が必要とされます。 SPは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のピング・メッセージの交換を禁止することを選択した場合、例えば、それはより困難の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ピング/トレースを使用する場合、例えば、プロバイダは、別のプロバイダに送信されたときにメッセージを対応に含まれる情報を制御することができなければなりません。
8.1.8. Protection against Over-provisioned Number of RSVP-TE LSPs and Bandwidth Reservation
8.1.8. オーバープロビジョニングRSVP-TEのLSPの数や帯域幅予約に対する保護
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ラベル付きパケットを廃棄する機能を提供しなければなりません。これは、SPは別のキャリアからそのドメインを入力し、すべてのラベルが実際にそのキャリアに割り当てられていることを保証することができます。
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 >|
SP2 - ASBR2 - ラベルされたパス - ASBR1 - P1 - SP1のPSN - P2 - PE1 | | | | | <AS2> | <MPLS相互接続> | <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で使用トランジットラベルが順番にASBR2（下流迷惑またはオンデマンド）にそれをアドバタイズASBR1、によって割り当てられます。このラベルは、サービスコンテキスト（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は、配線上ASBR2からの着信パケットのラベルは、AS1のVPNラベルまたはPSNラベルがあるかどうかわからないであろう。それはASBR2が誤ってまたは意図的に、着信ラベルAS1におけるPSNラベル（例えば、LDP）と一致する可能性があるように構成することができる（低いが）可能です。次に、この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.
不正なLSPおよび/またはLSPメッセージを設定DoS攻撃：RSVP-TEに対する攻撃。
Attacks against LDP: DoS attack with storms of LDP Hello messages or LDP TCP SYN messages.
自民党に対する攻撃：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)
- データベースに基づく会員の発見（例えば、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
MPLSの疑似回線5）暗号技術
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
凝集インフラ9）使用
10) Quality control processes
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
- （独自のコントロールプレーンセキュリティを有する）LSPピングを使用するMPLS LSPのエンドツーエンドの接続を確認します
- 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]については、AS間は、オプションA）、AS（自律システム）国境でVRF-に-VRFの接続は、一般的に相互プロバイダーの接続に使用されます。隣接ASへのASからの標識されたIPv4ルートのEBGP再分配とソースと宛先AS間標識VPN-IPv4ルートのオプションc）は、マルチホップ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.
DoS攻撃とのSPのインフラに対するインターネットからの侵入攻撃が見られています。 DoS攻撃「攻撃」（典型的には、悪意のない）も、CE機器がパケットトラフィックまたはルーティング情報の多量又は速度でPE機器を圧倒している見られています。運用またはプロビジョニングエラーが全盛期の懸念の一つとしてのSPで引用されています。
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]ベーカー、F.、リンデル、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]ローゼン、E.、Viswanathanの、A.、およびR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、RFC 3031、2001年1月。
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication -- Updated Message Type Value", RFC 3097, April 2001.
[RFC3097]ブレーデン、R.とL.チャン、 "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.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：LSPトンネルのためのRSVPの拡張"、RFC 3209年12月2001。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945]マニー、E.、エド。、 "一般化マルチプロトコルラベルスイッチング（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.マグリュー、 "IPsecのカプセル化セキュリティペイロード（ESP）におけるガロア/カウンタモード（GCM）の使用"、RFC 4106、2005年6月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]カウフマン、C.、エド。、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、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.、RFC 4309、2005年12月 "IPsecのカプセル化セキュリティペイロード（ESP）でのAdvanced Encryption Standard（AES）CCMモードを使用しました"。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]ローゼン、E.およびY. Rekhter、 "BGP / MPLS IP仮想プライベートネットワーク（VPN）"、RFC 4364、2006年2月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379] Kompella、K.とG.ツバメ、2006年2月、RFC 4379 "を検出マルチプロトコルラベルは（MPLS）データプレーン障害をスイッチ"。
[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]、RFC 4447マティーニ、L.、エド。、ローゼン、E.、エルAawar、N.、スミス、T.、およびG.サギ、 "ラベル配布プロトコル（LDP）を使用して疑似回線の設定とメンテナンス" 、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.、RFC 4835、2007年4月 "カプセル化セキュリティペイロード（ESP）と認証ヘッダー（AH）のための暗号アルゴリズム実装要件"。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（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]アンデション、L.、エド。、Minei、I.、エド。、およびB.トーマス、エド。、 "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]ハリントン、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.
Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002.
レヴィ、D.、マイヤー、P.、およびB.スチュワート、 "簡易ネットワーク管理プロトコル（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.
ブルーメンソール、U.とB. Wijnenの、 "ユーザベースセキュリティモデル（USM）簡易ネットワーク管理プロトコル（SNMPv3の）のバージョン3のために"、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、 "ビューベースアクセス制御モデル（VACM）簡易ネットワーク管理プロトコル（SNMP）のために"、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.、エド。、STD 62、RFC 3416、2002年12月、 "簡易ネットワーク管理プロトコル（SNMP）のためのプロトコル操作のバージョン2"。
Presuhn, R., Ed., "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002.
Presuhn、R.、エド。、 "簡易ネットワーク管理プロトコル（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.、エド。、 "管理情報ベース（MIB）簡易ネットワーク管理プロトコル（SNMP）のために"、STD 62、RFC 3418、2002年12月。
[STD8] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
【STD8]ポステル、J.、およびJ.レイノルズ、 "テルネットプロトコル仕様"、STD 8、RFC 854、1983年5月。
Postel, J. and J. Reynolds, "Telnet Option
Specifications", STD 8, RFC 855, May 1983.
[OIF-SMI-01.0] Renee Esposito, "Security for Management Interfaces to Network Elements", Optical Internetworking Forum, Sept. 2003.
[OIF-SMI-01.0]レニー・エスポジト、オプティカル・インターネットフォーラム、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]レニー・エスポジト、「ネットワーク要素への管理インターフェイスのセキュリティへの補遺」、オプティカル・インターネットフォーラム、2006年3月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、ベラー、M.、およびR.カネッティ、 "HMAC：メッセージ認証のための鍵付きハッシュ化"、RFC 2104、1997年2月。
[RFC2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[RFC2411]セイヤー、R.、Doraswamy、N.、およびR.グレン、 "IPセキュリティドキュメントロードマップ"、RFC 2411、1998年11月。
[RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.
[RFC3174]イーストレーク第3、D.とP.ジョーンズ、 "米国はハッシュアルゴリズム1（SHA1）を確保"、RFC 3174、2001年9月。
[RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 Signature Option", RFC 3562, July 2003.
[RFC3562]リーチ、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.、エド。、シラー、J.、エド。、およびC.カウフマン、エド。、 "インターネットのセキュリティメカニズム"、RFC 3631、2003年12月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]ベイカー、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]ブライアント、S.、エド。、およびP.パテ、エド。、 "疑似ワイヤーエミュレーション端から端まで（PWE3）アーキテクチャ"、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.鈴木、 "レイヤのためのフレームワーク3プロバイダ・プロビジョニングされた仮想プライベートネットワーク（PPVPNs）"、RFC 4110、2005年7月。
[RFC4111] Fang, L., Ed., "Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4111, July 2005.
[RFC4111]牙、L.、エド。、 "セキュリティフレームワークプロバイダ・プロビジョニングされた仮想プライベートネットワーク（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]ホフマン、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]ナドー、T.、モロー、M.、ツバメ、G.、アラン、D.、およびS.松島は、RFC 4377 "操作とマルチプロトコルラベルの管理（OAM）要件（MPLS）ネットワークのスイッチ" 、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]アラン、D.、エド。、およびT.ナドー、エド。、 "（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.、マーフィー、S.、およびY.ヤン、 "ルーティングプロトコルへの一般的な脅威"、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]ヴァン・デ・ヴェルデ、G.、ハイン、T.、Droms、R.、大工、B.、およびE.クライン、 "IPv6のローカルネットワークの保護"、RFC 4864、2007年5月。
[RFC4869] Law, L. and J. Solinas, "Suite B Cryptographic Suites for IPsec", RFC 4869, May 2007.
[RFC4869]法、L.および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]ビタール、N.編、ボッチ、M.、編、及びL.マティーニ、エド。、 "マルチセグメント疑似回線エミュレーションエッジ・ツー・エッジ（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.ビタール、 "MPLSインタインターコネクト技術仕様、" IP / MPLSフォーラム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.エスポジト、R. Graveman、およびB.ハザード、 "ネットワーク要素への管理インターフェイスのセキュリティ、" 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]モロー、C.、ジョーンズ、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]フランケル、S.とS.クリシュナン、 "IPセキュリティ（IPsec）やInternet Key Exchange（IKE）ドキュメントロードマップ"、進歩、2010年5月での作業。
[OPSEC-EFFORTS] Lonvick, C. and D. Spak, "Security Best Practices Efforts and Documents", Work in Progress, May 2010.
[OPSEC-努力] Lonvick、C.および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-キー]ベリンガー、M.とF.ル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のレビューを通じてサム・ハートマン、ディミトリPapadimitriou、Kannan Varadhan、スティーブン・ファレル、ミルチャPisica、彼のコメントや議論のために特にスコット・ブリムから有益なコメントや提案を認める、などのSureshクリシュナンしたいと思います彼GEN-ARTのレビューとコメント。作者は彼らのコメントのためにサンドラ・マーフィーとティムポークに感謝し、セキュリティADのレビューを通じて手助けしたいと思い、彼女のIANAのレビューのためにOPS-dirのレビューを通じて彼のコメントのためのペッカSavolaに感謝し、そしてアマンダBaber。
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）」[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
Luyuan牙、エド。、シスコシステムズ社マイケル・ベリンガー、シスコシステムズ、株式会社ロスCallon、ジュニパーネットワークスのリチャードGraveman、RFGセキュリティ、LLC J. L.ル・ルー、フランステレコムレイモンド・チャン、ブリティッシュテレコムポール・ナイト、個々のコントリビュータ
Yaakov Stein, RAD Data Communications Nabil Bitar, Verizon Monique Morrow, Cisco Systems, Inc. Adrian Farrel, Old Dog Consulting
Yaakovのスタイン、RADデータ・コミュニケーションズナビル・ビタール、ベライゾンモニークモロー、シスコシステムズ、株式会社エードリアンファレル、老犬のコンサルティング
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
マイケル・ベリンガーシスコシステムズ、株式会社ヴィレッジグリーン企業サイド400アベニューRoumanille Batiment T 3 06410ビオ、ソフィアアンティポリスFRANCE Eメール：mbehring@cisco.com
Ross Callon Juniper Networks 10 Technology Park Drive Westford, MA 01886 USA EMail: rcallon@juniper.net
ロスCallonジュニパーネットワークスの10テクノロジーパークドライブウェストフォード、MA 01886 USA電子メール：rcallon@juniper.net
Richard Graveman RFG Security 15 Park Avenue Morristown, NJ 07960 EMail: rfg@acm.org
リチャードGraveman RFGセキュリティ15パークアベニューモリスタウン、NJ 07960 Eメール：rfg@acm.org
Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex FRANCE EMail: jeanlouis.leroux@francetelecom.com
ジャン=ルイ・ルーフランステレコム2、大通りピエールMarzin 22307ラニオンCedexのFRANCE Eメール：jeanlouis.leroux@francetelecom.com
Raymond Zhang British Telecom BT Center 81 Newgate Street London, EC1A 7AJ United Kingdom EMail: raymond.zhang@bt.com
レイモンド・チャンブリティッシュテレコムBTセンター81ニューゲートストリートロンドン、EC1A 7AJイギリスメールアドレス：raymond.zhang@bt.com
Paul Knight 39 N. Hancock St. Lexington, MA 02420 EMail: paul.the.knight@gmail.com
ポール・ナイト39 N.ハンコックセントレキシントン、MA 02420 Eメール：paul.the.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の（ジョナサン）スタインRADデータ・コミュニケーションズ24ラウル・ワレンバーグセント、ビルCテルアビブ69719イスラエルEメール：yaakov_s@rad.com
Nabil Bitar Verizon 40 Sylvan Road Waltham, MA 02145 EMail: nabil.bitar@verizon.com
ナビル・ビタールベライゾン40シルバンロードウォルサム、MA 02145 Eメール：nabil.bitar@verizon.com
Monique Morrow Glatt-com CH-8301 Glattzentrum Switzerland EMail: mmorrow@cisco.com
モニークモローグラットコムCH-8301 Glattzentrumスイスメール：mmorrow@cisco.com
Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk
エードリアンファレル老犬のコンサルティングメール：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牙（エディタ）は、Cisco Systems、Inc.の300ビーバーブルック・ロードボックスボロー、MA 01719 USA Eメール：lufang@cisco.com