[要約] RFC 4381は、BGP/MPLS IP仮想プライベートネットワーク（VPN）のセキュリティに関する分析を提供しています。このRFCの目的は、BGP/MPLS IP VPNのセキュリティの問題を特定し、それに対する対策を提案することです。
Network Working Group M. Behringer
Request for Comments: 4381 Cisco Systems Inc
Category: Informational February 2006
Analysis of the Security of BGP/MPLS IP Virtual Private Networks (VPNs)
BGP/MPLS IP仮想ネットワーク（VPNS）のセキュリティの分析
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
IESG Note
IESGノート
The content of this RFC was at one time considered by the IETF, and therefore it may resemble a current IETF work in progress or a published IETF work. This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose, and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this RFC should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information.
このRFCの内容は、一度にIETFによって考慮されていたため、現在のIETF作業または公開されているIETF作業に似ている可能性があります。このRFCは、インターネット標準のレベルの候補者ではありません。IETFは、あらゆる目的のためにこのRFCのフィットネスに関する知識を放棄します。特に、公開する決定は、セキュリティ、混雑制御、または展開プロトコルとの不適切な相互作用などのIETFレビューに基づいていないことに注意してください。RFCエディターは、その裁量でこのドキュメントを公開することを選択しました。このRFCの読者は、実装と展開の価値を評価する際に注意する必要があります。詳細については、RFC 3932を参照してください。
Abstract
概要
This document analyses the security of the BGP/MPLS IP virtual private network (VPN) architecture that is described in RFC 4364, for the benefit of service providers and VPN users.
このドキュメントは、サービスプロバイダーとVPNユーザーの利益のために、RFC 4364で説明されているBGP/MPLS IP仮想プライベートネットワーク（VPN）アーキテクチャのセキュリティを分析します。
The analysis shows that BGP/MPLS IP VPN networks can be as secure as traditional layer-2 VPN services using Asynchronous Transfer Mode (ATM) or Frame Relay.
分析は、BGP/MPLS IP VPNネットワークが、非同期転送モード（ATM）またはフレームリレーを使用した従来のレイヤー2 VPNサービスと同じくらい安全であることを示しています。
Table of Contents
目次
1. Scope and Introduction ..........................................3
2. Security Requirements of VPN Networks ...........................4
2.1. Address Space, Routing, and Traffic Separation .............4
2.2. Hiding the Core Infrastructure .............................5
2.3. Resistance to Attacks ......................................5
2.4. Impossibility of Label Spoofing ............................6
3. Analysis of BGP/MPLS IP VPN Security ............................6
3.1. Address Space, Routing, and Traffic Separation .............6
3.2. Hiding of the BGP/MPLS IP VPN Core Infrastructure ..........7
3.3. Resistance to Attacks ......................................9
3.4. Label Spoofing ............................................11
3.5. Comparison with ATM/FR VPNs ...............................12
4. Security of Advanced BGP/MPLS IP VPN Architectures .............12
4.1. Carriers' Carrier .........................................13
4.2. Inter-Provider Backbones ..................................14
5. What BGP/MPLS IP VPNs Do Not Provide ...........................16
5.1. Protection against Misconfigurations of the Core
and Attacks 'within' the Core .............................16
5.2. Data Encryption, Integrity, and Origin Authentication .....17
5.3. Customer Network Security .................................17
6. Layer 2 Security Considerations ................................18
7. Summary and Conclusions ........................................19
8. Security Considerations ........................................20
9. Acknowledgements ...............................................20
10. Normative References ..........................................20
11. Informative References ........................................20
As Multiprotocol Label Switching (MPLS) is becoming a more widespread technology for providing IP virtual private network (VPN) services, the security of the BGP/MPLS IP VPN architecture is of increasing concern to service providers and VPN customers. This document gives an overview of the security of the BGP/MPLS IP VPN architecture that is described in RFC 4364 [1], and compares it with the security of traditional layer-2 services such as ATM or Frame Relay.
マルチプロトコルラベルスイッチング（MPLS）は、IP仮想プライベートネットワーク（VPN）サービスを提供するためのより広範なテクノロジーになりつつあるため、BGP/MPLS IP VPNアーキテクチャのセキュリティは、サービスプロバイダーとVPN顧客にとってますます懸念されています。このドキュメントは、RFC 4364 [1]で説明されているBGP/MPLS IP VPNアーキテクチャのセキュリティの概要を示し、ATMやフレームリレーなどの従来のレイヤー2サービスのセキュリティと比較します。
The term "MPLS core" is defined for this document as the set of Provider Edge (PE) and provider (P) routers that provide a BGP/MPLS IP VPN service, typically under the control of a single service provider (SP). This document assumes that the MPLS core network is trusted and secure. Thus, it does not address basic security concerns such as securing the network elements against unauthorised access, misconfigurations of the core, or attacks internal to the core. A customer that does not wish to trust the service provider network must use additional security mechanisms such as IPsec over the MPLS infrastructure.
「MPLSコア」という用語は、このドキュメントに対して、通常、単一のサービスプロバイダー（SP）の制御下にあるBGP/MPLS IP VPNサービスを提供するプロバイダーEDGE（PE）およびプロバイダー（P）ルーターのセットとして定義されています。このドキュメントは、MPLSコアネットワークが信頼され安全であることを前提としています。したがって、不正アクセス、コアの誤解、コアの内部攻撃に対するネットワーク要素を確保するなど、基本的なセキュリティの懸念には対処しません。サービスプロバイダーネットワークを信頼したくない顧客は、MPLSインフラストラクチャを介したIPSECなどの追加のセキュリティメカニズムを使用する必要があります。
This document analyses only the security features of BGP/MPLS IP VPNs, not the security of routing protocols in general. IPsec technology is also not covered, except to highlight the combination of MPLS VPNs with IPsec.
このドキュメントは、一般的なルーティングプロトコルのセキュリティではなく、BGP/MPLS IP VPNのセキュリティ機能のみを分析します。IPSECテクノロジーもカバーされていませんが、MPLS VPNとIPSECの組み合わせを強調することを除きます。
The overall security of a system has three aspects: the architecture, the implementation, and the operation of the system. Security issues can exist in any of these aspects. This document analyses only the architectural security of BGP/MPLS IP VPNs, not implementation or operational security issues.
システムの全体的なセキュリティには、アーキテクチャ、実装、およびシステムの操作の3つの側面があります。セキュリティの問題は、これらの側面のいずれかに存在する可能性があります。このドキュメントは、実装または運用セキュリティの問題ではなく、BGP/MPLS IP VPNのアーキテクチャセキュリティのみを分析します。
This document is targeted at technical staff of service providers and enterprises. Knowledge of the basic BGP/MPLS IP VPN architecture as described in RFC 4364 [1] is required to understand this document. For specific Layer 3 VPN terminology and reference models refer to [11].
このドキュメントは、サービスプロバイダーと企業の技術スタッフを対象としています。RFC 4364 [1]に記載されている基本的なBGP/MPLS IP VPNアーキテクチャの知識は、このドキュメントを理解するために必要です。特定のレイヤー3 VPN用語と参照モデルについては、[11]を参照してください。
Section 2 of this document specifies the typical VPN requirements a VPN user might have, and section 3 analyses how RFC 4364 [1] addresses these requirements. Section 4 discusses specific security issues of multi-AS (Autonomous System) MPLS architectures, and section 5 lists security features that are not covered by this architecture and therefore need to be addressed separately. Section 6 highlights potential security issues on layer 2 that might impact the overall security of a BGP/MPLS IP VPN service. The findings of this document are summarized in section 7.
このドキュメントのセクション2では、VPNユーザーが持っている典型的なVPN要件を指定し、セクション3でRFC 4364 [1]がこれらの要件に対処する方法を分析します。セクション4では、Multi-AS（自律システム）MPLSアーキテクチャの特定のセキュリティ問題について説明し、セクション5では、このアーキテクチャではカバーされていないセキュリティ機能をリストしているため、個別に対処する必要があります。セクション6では、BGP/MPLS IP VPNサービスの全体的なセキュリティに影響を与える可能性のあるレイヤー2の潜在的なセキュリティ問題を強調しています。このドキュメントの調査結果は、セクション7に要約されています。
Both service providers offering any type of VPN services and customers using them have specific demands for security. Mostly, they compare MPLS-based solutions with traditional layer 2-based VPN solutions such as Frame Relay and ATM, since these are widely deployed and accepted. This section outlines the typical security requirements for VPN networks. The following section discusses if and how BGP/MPLS IP VPNs address these requirements, for both the MPLS core and the connected VPNs.
どちらのサービスプロバイダーも、あらゆるタイプのVPNサービスを提供しており、それらを使用している顧客には、セキュリティに対する具体的な要求があります。主に、MPLSベースのソリューションを、フレームリレーやATMなどの従来のレイヤー2ベースのVPNソリューションと比較します。これらは広く展開され、受け入れられているためです。このセクションでは、VPNネットワークの典型的なセキュリティ要件の概要を説明します。次のセクションでは、MPLSコアと接続されたVPNの両方について、BGP/MPLS IP VPNがこれらの要件に対処するかどうか、および方法について説明します。
Non-intersecting layer 3 VPNs of the same VPN service are assumed to have independent address spaces. For example, two non-intersecting VPNs may each use the same 10/8 network addresses without conflict. In addition, traffic from one VPN must never enter another VPN. This implies separation of routing protocol information, so that routing tables must also be separate per VPN. Specifically:
同じVPNサービスの非交差レイヤー3 VPNは、独立したアドレススペースを持つと想定されています。たとえば、2つの非間隔VPNSは、それぞれ競合なしに同じ10/8ネットワークアドレスを使用する場合があります。さらに、1つのVPNからのトラフィックは、別のVPNを入力しないでください。これは、ルーティングプロトコル情報の分離を意味するため、ルーティングテーブルもVPNごとに分離する必要があります。具体的には：
o Any VPN must be able to use the same address space as any other VPN. o Any VPN must be able to use the same address space as the MPLS core. o Traffic, including routing traffic, from one VPN must never flow to another VPN. o Routing information, as well as distribution and processing of that information, for one VPN instance must be independent from any other VPN instance. o Routing information, as well as distribution and processing of that information, for one VPN instance must be independent from the core.
o VPNは、他のVPNと同じアドレススペースを使用できる必要があります。o任意のVPNは、MPLSコアと同じアドレス空間を使用できる必要があります。oルーティングトラフィックを含むトラフィックは、あるVPNから別のVPNに流れないでください。o 1つのVPNインスタンスのルーティング情報とその情報の配布と処理は、他のVPNインスタンスから独立している必要があります。o 1つのVPNインスタンスのルーティング情報とその情報の配布と処理は、コアから独立している必要があります。
From a security point of view, the basic requirement is to prevent packets destined to a host a.b.c.d within a given VPN reaching a host with the same address in another VPN or in the core, and to prevent routing packets to another VPN even if it does not contain that destination address.
セキュリティの観点から見ると、基本的な要件は、別のVPNまたはコア内の同じアドレスを持つホストに到達する特定のVPN内のホストA.B.C.Dに運命づけられているパケットを防ぐこと、およびたとえそうであっても別のVPNへのルーティングパケットを防ぐことです。その宛先アドレスが含まれていません。
Confidentiality, as defined in the L3VPN Security Framework [11], is a requirement that goes beyond simple isolation of VPNs and provides protection against eavesdropping on any transmission medium. Encryption is the mechanism used to provide confidentiality. This document considers confidentiality an optional VPN requirement, since many existing VPN deployments do not encrypt transit traffic.
L3VPNセキュリティフレームワーク[11]で定義されている機密性は、VPNの単純な分離を超えた要件であり、伝送媒体の盗聴に対する保護を提供します。暗号化は、機密性を提供するために使用されるメカニズムです。多くの既存のVPN展開はトランジットトラフィックを暗号化しないため、このドキュメントは機密性をオプションのVPN要件と見なしています。
The internal structure of the core network (MPLS PE and P elements) should not be externally visible. Whilst breaking this requirement is not a security problem in itself, many service providers believe it is advantageous if the internal addresses and network structure are hidden from the outside world. An argument is that denial-of-service (DoS) attacks against a core router are much easier to carry out if an attacker knows the router addresses. Addresses can always be guessed, but attacks are more difficult if addresses are not known. The core should be as invisible to the outside world as a comparable layer 2 infrastructure (e.g., Frame Relay, ATM). Core network elements should also not be accessible from within a VPN.
コアネットワークの内部構造（MPLS PEおよびP要素）は、外部から見えるべきではありません。この要件を破ること自体はセキュリティの問題ではありませんが、多くのサービスプロバイダーは、内部アドレスとネットワーク構造が外の世界から隠されている場合に有利であると考えています。議論は、攻撃者がルーターのアドレスを知っている場合、コアルーターに対するサービス拒否（DOS）攻撃ははるかに簡単に実行できるということです。アドレスはいつでも推測できますが、アドレスが不明な場合は攻撃がより困難です。コアは、同等のレイヤー2インフラストラクチャ（フレームリレー、ATMなど）と同じくらい外部の世界には見えないものでなければなりません。コアネットワーク要素もVPN内からアクセスできないはずです。
Security should never rely entirely on obscurity, i.e., the hiding of information. Services should be equally secure if the implementation is known. However, there is a strong market perception that hiding of details is advantageous. This point addresses that market perception.
セキュリティは、あいまいさ、つまり情報の隠蔽に完全に依存してはなりません。実装がわかっている場合は、サービスを等しく安全にする必要があります。ただし、詳細を隠すことは有利であるという強い市場認識があります。このポイントは、その市場認識に対処しています。
There are two basic types of attacks: DoS attacks, where resources become unavailable to authorised users, and intrusions, where resources become available to unauthorised users. BGP/MPLS IP VPN networks must provide at least the same level of protection against both forms of attack as current layer 2 networks.
攻撃には2つの基本的なタイプがあります。DOS攻撃では、認定ユーザーがリソースが利用できなくなり、侵入が不正ユーザーがリソースが利用できるようになります。BGP/MPLS IP VPNネットワークは、現在のレイヤー2ネットワークと同じ形式の攻撃に対して少なくとも同じレベルの保護を提供する必要があります。
For intrusions, there are two fundamental ways to protect the network: first, to harden protocols that could be abused (e.g., Telnet into a router), and second, to make the network as inaccessible as possible. This is achieved by a combination of packet filtering / firewalling and address hiding, as discussed above.
侵入には、ネットワークを保護するための2つの基本的な方法があります。1つ目は、乱用する可能性のあるプロトコルを強化する（例えば、ルーターにテルネット）、次にネットワークを可能な限りアクセスできないようにするためです。これは、上記で説明したように、パケットフィルタリング /ファイアーウォールと住所の隠蔽の組み合わせによって達成されます。
DoS attacks are easier to execute, since a single known IP address might be enough information to attack a machine. This can be done using normal "permitted" traffic, but using higher than normal packet rates, so that other users cannot access the targeted machine. The only way to be invulnerable to this kind of attack is to make sure that machines are not reachable, again by packet filtering and optionally by address hiding.
DOS攻撃は、単一の既知のIPアドレスがマシンを攻撃するのに十分な情報である可能性があるため、実行が容易です。これは、通常の「許可された」トラフィックを使用して実行できますが、通常のパケットレートよりも高いため、他のユーザーがターゲットマシンにアクセスできません。この種の攻撃に不死身にする唯一の方法は、パケットフィルタリングによって、そしてオプションで住所を隠すことで、マシンが到達できないことを確認することです。
This document concentrates on protecting the core network against attacks from the "outside", i.e., the Internet and connected VPNs. Protection against attacks from the "inside", i.e., an attacker who has logical or physical access to the core network, is not discussed here.
このドキュメントは、「外部」、つまりインターネットと接続されたVPNからの攻撃からコアネットワークを保護することに集中しています。「内部」からの攻撃、つまり、コアネットワークへの論理的または物理的アクセスを持つ攻撃者からの保護については、ここでは議論されていません。
Assuming the address and traffic separation discussed above, an attacker might try to access other VPNs by inserting packets with a label that he does not "own". This could be done from the outside, i.e., another Customer Edge (CE) router or from the Internet, or from within the MPLS core. The latter case (from within the core) will not be discussed, since we assume that the core network is provided securely. Should protection against an insecure core be required, it is necessary to use security protocols such as IPsec across the MPLS infrastructure, at least from CE to CE, since the PEs belong to the core.
上記のアドレスとトラフィックの分離を仮定すると、攻撃者は、自分が「所有」していないラベルにパケットを挿入することにより、他のVPNにアクセスしようとする可能性があります。これは、外部から、つまり、別の顧客エッジ（CE）ルーターまたはインターネットから、またはMPLSコア内から実行できます。コアネットワークが安全に提供されていると想定するため、後者のケース（コア内から）は議論されません。安全でないコアに対する保護が必要な場合、PESはコアに属しているため、少なくともCEからCEまでのMPLSインフラストラクチャ全体でIPSECなどのセキュリティプロトコルを使用する必要があります。
Depending on the way that CE routers are connected to PE routers, it might be possible to intrude into a VPN that is connected to the same PE, using layer 2 attack mechanisms such as 802.1Q-label spoofing or ATM VPI/VCI spoofing. Layer 2 security issues will be discussed in section 6.
CEルーターがPEルーターに接続されている方法に応じて、802.1Q-LabelスプーフィングやATM VPI/VCIスプーフィングなどのレイヤー2攻撃メカニズムを使用して、同じPEに接続されたVPNに侵入することが可能かもしれません。レイヤー2のセキュリティの問題については、セクション6で説明します。
It is required that VPNs cannot abuse the MPLS label mechanisms or protocols to gain unauthorised access to other VPNs or the core.
VPNは、他のVPNまたはコアへの不正アクセスを得るためにMPLSラベルメカニズムまたはプロトコルを悪用できないことが必要です。
In this section, the BGP/MPLS IP VPN architecture is analysed with respect to the security requirements listed above.
このセクションでは、上記のセキュリティ要件に関して、BGP/MPLS IP VPNアーキテクチャを分析します。
BGP/MPLS allows distinct IP VPNs to use the same address space, which can also be private address space (RFC 1918 [2]). This is achieved by adding a 64-bit Route Distinguisher (RD) to each IPv4 route, making VPN-unique addresses also unique in the MPLS core. This "extended" address is also called a "VPN-IPv4 address". Thus, customers of a BGP/MPLS IP VPN service do not need to change their current addressing plan.
BGP/MPLSを使用すると、個別のIP VPNが同じアドレススペースを使用できます。これは、プライベートアドレススペースでもあります（RFC 1918 [2]）。これは、各IPv4ルートに64ビットルートのDistimuniuther（RD）を追加することで達成され、VPN-UniqueアドレスをMPLSコアでもユニークにします。この「拡張」アドレスは、「VPN-IPV4アドレス」とも呼ばれます。したがって、BGP/MPLS IP VPNサービスの顧客は、現在のアドレス指定計画を変更する必要はありません。
Each PE router maintains a separate Virtual Routing and Forwarding instance (VRF) for each connected VPN. A VRF includes the addresses of that VPN as well as the addresses of the PE routers with which the CE routers are peering. All addresses of a VRF, including these PE addresses, belong logically to the VPN and are accessible from the VPN. The fact that PE addresses are accessible to the VPN is not an issue if static routing is used between the PE and CE routers, since packet filters can be deployed to block access to all addresses of the VRF on the PE router. If dynamic routing protocols are used, the CE routers need to have the address of the peer PE router in the core configured. In an environment where the service provider manages the CE routers as CPE, this can be invisible to the customer. The address space on the CE-PE link (including the peering PE address) is considered part of the VPN address space. Since address space can overlap between VPNs, the CE-PE link addresses can overlap between VPNs. For practical management considerations, SPs typically address CE-PE links from a global pool, maintaining uniqueness across the core.
各PEルーターは、接続された各VPNに対して個別の仮想ルーティングおよび転送インスタンス（VRF）を維持しています。VRFには、そのVPNのアドレスと、CEルーターがピアリングしているPEルーターのアドレスが含まれます。これらのPEアドレスを含むVRFのすべてのアドレスは、論理的にVPNに属し、VPNからアクセス可能です。PEルーターを展開してPEルーターのVRFのすべてのアドレスへのアクセスをブロックできるため、PEアドレスがVPNにアクセスしやすいという事実は問題ではありません。動的ルーティングプロトコルを使用する場合、CEルーターは、構成されたコアのピアPEルーターのアドレスを持つ必要があります。サービスプロバイダーがCEルーターをCPEとして管理する環境では、これは顧客には見えない場合があります。CE-PEリンクのアドレススペース（ピアリングPEアドレスを含む）は、VPNアドレススペースの一部と見なされます。アドレス空間はVPN間で重複する可能性があるため、CE-PEリンクアドレスはVPN間で重複する可能性があります。実際の管理上の考慮事項のために、SPSは通常、グローバルプールからのCE-PEリンクに対処し、コア全体で独自性を維持します。
Routing separation between VPNs can also be achieved. Each VRF is populated with routes from one VPN through statically configured routes or through routing protocols that run between the PE and CE router. Since each VPN is associated with a separate VRF there is no interference between VPNs on the PE router.
VPN間のルーティング分離も達成できます。各VRFには、静的に構成されたルートを介して、またはPEルーターとCEルーターの間で実行されるルーティングプロトコルを介して、1つのVPNからルートが入力されています。各VPNは個別のVRFに関連付けられているため、PEルーター上のVPN間に干渉はありません。
Across the core to the other PE routers separation is maintained with unique VPN identifiers in multiprotocol BGP, the Route Distinguishers (RDs). VPN routes including the RD are exclusively exchanged between PE routers by Multi-Protocol BGP (MP-BGP, RFC 2858 [8]) across the core. These BGP routing updates are not re-distributed into the core, but only to the other PE routers, where the information is kept again in VPN-specific VRFs. Thus, routing across a BGP/MPLS network is separate per VPN.
コアを横切って他のPEルーターの分離は、マルチプロトコルBGPの一意のVPN識別子で維持されます。ルート違い（RDS）が維持されます。RDを含むVPNルートは、コア全体でマルチプロトコルBGP（MP-BGP、RFC 2858 [8]）によってPEルーター間でのみ交換されます。これらのBGPルーティングの更新は、コアに再配布されるのではなく、他のPEルーターにのみvpn固有のVRFに保持されます。したがって、BGP/MPLSネットワークを横切るルーティングは、VPNごとに個別です。
On the data plane, traffic separation is achieved by the ingress PE pre-pending a VPN-specific label to the packets. The packets with the VPN labels are sent through the core to the egress PE, where the VPN label is used to select the egress VRF.
データプレーンでは、VPN固有のラベルをパケットに事前に保留することにより、トラフィックの分離が達成されます。VPNラベルを備えたパケットは、コアを介してEgress PEに送信されます。ここでは、VPNラベルを使用してEgress VRFを選択します。
Given the addressing, routing, and traffic separation across an BGP/ MPLS IP VPN core network, it can be assumed that this architecture offers in this respect the same security as a layer-2 VPN. It is not possible to intrude from a VPN or the core into another VPN unless this has been explicitly configured.
BGP/ MPLS IP VPNコアネットワーク全体でのアドレス指定、ルーティング、およびトラフィックの分離を考えると、このアーキテクチャはこの点でレイヤー2 VPNと同じセキュリティを提供すると想定できます。これが明示的に構成されていない限り、VPNまたはコアから別のVPNに侵入することはできません。
If and when confidentiality is required, it can be achieved in BGP/ MPLS IP VPNs by overlaying encryption services over the network. However, encryption is not a standard service on BGP/MPLS IP VPNs. See also section 5.2.
機密性が必要な場合、ネットワーク上で暗号化サービスをオーバーレイすることにより、BGP/ MPLS IP VPNSで達成できます。ただし、暗号化はBGP/MPLS IP VPNの標準サービスではありません。セクション5.2も参照してください。
Service providers and end-customers do not normally want their network topology revealed to the outside. This makes attacks more difficult to execute: If an attacker doesn't know the address of a victim, he can only guess the IP addresses to attack. Since most DoS attacks don't provide direct feedback to the attacker it would be difficult to attack the network. It has to be mentioned specifically that information hiding as such does not provide security. However, in the market this is a perceived requirement.
サービスプロバイダーとエンドカスタマーは、通常、ネットワークトポロジを外部に明らかにすることを望んでいません。これにより、攻撃の実行がより困難になります。攻撃者が被害者の住所を知らない場合、IPアドレスは攻撃のみを推測できます。ほとんどのDOS攻撃は攻撃者に直接フィードバックを提供しないため、ネットワークを攻撃することは困難です。そのように隠れる情報はセキュリティを提供しないことに特に言及する必要があります。ただし、市場では、これは認識されている要件です。
With a known IP address, a potential attacker can launch a DoS attack more easily against that device. Therefore, the ideal is to not reveal any information about the internal network to the outside world. This applies to the customer network and the core. A number of additional security measures also have to be taken: most of all, extensive packet filtering.
既知のIPアドレスを使用すると、潜在的な攻撃者はそのデバイスに対してより簡単にDOS攻撃を開始できます。したがって、理想は、内部ネットワークに関する情報を外の世界に明らかにしないことです。これは、顧客ネットワークとコアに適用されます。多くの追加のセキュリティ対策も実行する必要があります。何よりも、広範なパケットフィルタリングです。
For security reasons, it is recommended for any core network to filter packets from the "outside" (Internet or connected VPNs) destined to the core infrastructure. This makes it very hard to attack the core, although some functionality such as pinging core routers will be lost. Traceroute across the core will still work, since it addresses a destination outside the core.
セキュリティ上の理由から、コアネットワークは、コアインフラストラクチャに向けた「外部」（インターネットまたは接続されたVPN）からパケットをフィルタリングすることをお勧めします。これにより、コアを攻撃することが非常に困難になりますが、コアルーターの声などの一部の機能は失われます。コアの外側の目的地に対処するため、コアを横切るTracerouteは引き続き機能します。
MPLS does not reveal unnecessary information to the outside, not even to customer VPNs. The addressing of the core can be done with private addresses (RFC 1918 [2]) or public addresses. Since the interface to the VPNs as well as the Internet is BGP, there is no need to reveal any internal information. The only information required in the case of a routing protocol between PE and CE is the address of the PE router. If no dynamic routing is required, static routing on unnumbered interfaces can be configured between the PE and CE. With this measure, the BGP/MPLS IP VPN core can be kept completely hidden.
MPLSは、顧客VPNにさえ、外部に不必要な情報を明らかにしません。コアのアドレス指定は、プライベートアドレス（RFC 1918 [2]）またはパブリックアドレスで実行できます。VPNとインターネットへのインターフェイスはBGPであるため、内部情報を表示する必要はありません。PEとCEの間のルーティングプロトコルの場合に必要な唯一の情報は、PEルーターのアドレスです。動的ルーティングが不要な場合は、PEとCEの間には、番号のないインターフェイスでの静的ルーティングを構成できます。この尺度では、BGP/MPLS IP VPNコアを完全に隠すことができます。
Customer VPNs must advertise their routes to the BGP/MPLS IP VPN core (dynamically or statically), to ensure reachability across their VPN. In some cases, VPN users prefer that the service provider have no visibility of the addressing plan of the VPN. The following has to be noted: First, the information known to the core is not about specific hosts, but networks (routes); this offers a degree of abstraction. Second, in a VPN-only BGP/MPLS IP VPN network (no Internet access) this is equal to existing layer-2 models, where the customer has to trust the service provider. Also, in a Frame Relay or ATM network, routing and addressing information about the VPNs can be seen on the core network.
顧客VPNは、VPN全体のリーチ性を確保するために、BGP/MPLS IP VPNコア（動的または静的に）にルートを宣伝する必要があります。場合によっては、VPNユーザーは、サービスプロバイダーがVPNのアドレス指定計画の可視性を持たないことを好みます。以下に注意する必要があります。まず、コアに知られている情報は、特定のホストではなく、ネットワーク（ルート）に関するものです。これは、ある程度の抽象化を提供します。第二に、VPNのみのBGP/MPLS IP VPNネットワーク（インターネットアクセスなし）では、これは既存のLayer-2モデルに等しく、顧客はサービスプロバイダーを信頼しなければなりません。また、フレームリレーまたはATMネットワークでは、コアネットワークでVPNに関する情報をルーティングとアドレス指定することができます。
In a VPN service with shared Internet access, the service provider will typically announce the routes of customers who wish to use the Internet to his upstream or peer providers. This can be done directly if the VPN customer uses public address space, or via Network Address Translation (NAT) to obscure the addressing information of the customers' networks. In either case, the customer does not reveal more information than would be revealed by a general Internet service. Core information will not be revealed, except for the peering address(es) of the PE router(s) that hold(s) the peering with the Internet. These addresses must be secured as in a traditional IP backbone.
共有インターネットアクセスを備えたVPNサービスでは、サービスプロバイダーは通常、インターネットを上流またはピアプロバイダーに使用したい顧客のルートを発表します。これは、VPN顧客がパブリックアドレススペースを使用している場合、またはネットワークアドレス変換（NAT）を介して顧客のネットワークのアドレス指定情報を不明瞭にする場合に直接実行できます。どちらの場合でも、顧客は一般的なインターネットサービスによって明らかにされるよりも多くの情報を明らかにしません。インターネットでピアリングを保持するPEルーターのピアリングアドレス（es）を除いて、コア情報は明らかにされません。これらのアドレスは、従来のIPバックボーンのように保護する必要があります。
In summary, in a pure MPLS-VPN service, where no Internet access is provided, information hiding is as good as on a comparable FR or ATM network. No addressing information is revealed to third parties or the Internet. If a customer chooses to access the Internet via the BGP/MPLS IP VPN core, he will have to reveal the same information as required for a normal Internet service. NAT can be used for further obscurity. Being reachable from the Internet automatically exposes a customer network to additional security threats. Appropriate security mechanisms have to be deployed such as firewalls and intrusion detection systems. This is true for any Internet access, over MPLS or direct.
要約すると、インターネットアクセスが提供されていない純粋なMPLS-VPNサービスでは、情報の隠蔽は同等のFRまたはATMネットワークと同じくらい良いです。第三者やインターネットには、アドレス指定情報は明らかにされていません。顧客がBGP/MPLS IP VPNコアを介してインターネットにアクセスすることを選択した場合、通常のインターネットサービスに必要な情報を明らかにする必要があります。NATは、さらなるあいまいさに使用できます。インターネットから到達可能であることは、顧客ネットワークを追加のセキュリティの脅威に自動的に公開します。ファイアウォールや侵入検知システムなど、適切なセキュリティメカニズムを展開する必要があります。これは、MPLSまたは直接的なインターネットアクセスに当てはまります。
A BGP/MPLS IP VPN network with no interconnections to the Internet has security equal to that of FR or ATM VPN networks. With an Internet access from the MPLS cloud, the service provider has to reveal at least one IP address (of the peering PE router) to the next provider, and thus to the outside world.
インターネットとの相互接続がないBGP/MPLS IP VPNネットワークは、FRまたはATM VPNネットワークのセキュリティと等しいセキュリティを持っています。MPLSクラウドからのインターネットアクセスを使用すると、サービスプロバイダーは、少なくとも1つのIPアドレス（ピアリングPEルーターの）を次のプロバイダー、したがって外の世界に表示する必要があります。
Section 3.1 shows that it is impossible to directly intrude into other VPNs. Another possibility is to attack the MPLS core and try to attack other VPNs from there. As shown above, it is impossible to address a P router directly. The only addresses reachable from a VPN or the Internet are the peering addresses of the PE routers. Thus, there are two basic ways that the BGP/MPLS IP VPN core can be attacked:
セクション3.1は、他のVPNに直接侵入することが不可能であることを示しています。別の可能性は、MPLSコアを攻撃し、そこから他のVPNを攻撃しようとすることです。上記のように、Pルーターに直接対処することは不可能です。VPNまたはインターネットから到達可能なアドレスのみは、PEルーターのピアリングアドレスです。したがって、BGP/MPLS IP VPNコアを攻撃できる2つの基本的な方法があります。
1. By attacking the PE routers directly. 2. By attacking the signaling mechanisms of MPLS (mostly routing).
1. PEルーターを直接攻撃することにより。2. MPLSのシグナルメカニズムを攻撃することにより（主にルーティング）。
To attack an element of a BGP/MPLS IP VPN network, it is first necessary to know the address of the element. As discussed in section 3.2, the addressing structure of the BGP/MPLS IP VPN core is hidden from the outside world. Thus, an attacker cannot know the IP address of any router in the core to attack. The attacker could guess addresses and send packets to these addresses. However, due to the address separation of MPLS each incoming packet will be treated as belonging to the address space of the customer. Thus, it is impossible to reach an internal router, even by guessing IP addresses. There is only one exception to this rule, which is the peer interface of the PE router. This address of the PE is the only attack point from the outside (a VPN or Internet).
BGP/MPLS IP VPNネットワークの要素を攻撃するには、最初に要素のアドレスを知る必要があります。セクション3.2で説明したように、BGP/MPLS IP VPNコアのアドレス指定構造は、外の世界から隠されています。したがって、攻撃者は、コア内のルーターのIPアドレスを攻撃することができません。攻撃者はアドレスを推測し、これらのアドレスにパケットを送信できます。ただし、MPLSのアドレス分離により、各着信パケットは顧客の住所スペースに属するものとして扱われます。したがって、IPアドレスを推測しても、内部ルーターに到達することは不可能です。このルールには、PEルーターのピアインターフェイスである例外は1つだけです。PEのこのアドレスは、外部からの唯一の攻撃ポイント（VPNまたはインターネット）です。
The routing between a VPN and the BGP/MPLS IP VPN core can be configured two ways:
VPNとBGP/MPLS IP VPNコアの間のルーティングは、次の2つの方法を構成できます。
1. Static: In this case, the PE routers are configured with static routes to the networks behind each CE, and the CEs are configured to statically point to the PE router for any network in other parts of the VPN (mostly a default route). There are two sub-cases: The static route can point to the IP address of the PE router or to an interface of the CE router (e.g., serial0). 2. Dynamic: A routing protocol (e.g., Routing Information Protocol (RIP), OSPF, BGP) is used to exchange routing information between the CE and PE at each peering point.
1. 静的：この場合、PEルーターは各CEの背後にあるネットワークへの静的ルートで構成され、CESはVPNの他の部分の任意のネットワークのPEルーターを静的に指すように構成されています（主にデフォルトルート）。2つのサブケースがあります。静的ルートは、PEルーターのIPアドレスまたはCEルーターのインターフェイス（Serial0など）を指すことができます。2.動的：ルーティングプロトコル（例：ルーティング情報プロトコル（RIP）、OSPF、BGPなど）は、各ピアリングポイントでのCEとPE間のルーティング情報を交換するために使用されます。
In the case of a static route that points to an interface, the CE router doesn't need to know any IP addresses of the core network or even of the PE router. This has the disadvantage of needing a more extensive (static) configuration, but is the most secure option. In this case, it is also possible to configure packet filters on the PE interface to deny any packet to the PE interface. This protects the router and the whole core from attack.
インターフェイスを指す静的ルートの場合、CEルーターはコアネットワークまたはPEルーターのIPアドレスを知る必要はありません。これには、より広範な（静的）構成が必要なという欠点がありますが、最も安全なオプションです。この場合、PEインターフェイスでパケットフィルターを構成して、PEインターフェイスへのパケットを拒否することもできます。これにより、ルーターとコア全体が攻撃から保護されます。
In all other cases, each CE router needs to know at least the router ID (RID, i.e., peer IP address) of the PE router in the core, and thus has a potential destination for an attack. One could imagine various attacks on various services running on a router. In practice, access to the PE router over the CE-PE interface can be limited to the required routing protocol by using access control lists (ACLs). This limits the point of attack to one routing protocol, for example, BGP. A potential attack could be to send an extensive number of routes, or to flood the PE router with routing updates. Both could lead to a DoS, however, not to unauthorised access.
他のすべての場合、各CEルーターは、コアのPEルーターの少なくともルーターID（red、つまりピアIPアドレス）を知る必要があるため、攻撃の潜在的な目的地があります。ルーターで実行されているさまざまなサービスに対するさまざまな攻撃を想像できます。実際には、CE-PEインターフェイス上のPEルーターへのアクセスは、アクセス制御リスト（ACL）を使用して、必要なルーティングプロトコルに制限できます。これにより、攻撃のポイントは、たとえばBGPなどの1つのルーティングプロトコルに制限されます。潜在的な攻撃は、豊富な数のルートを送信するか、ルーティングの更新でPEルーターをあふれさせることです。どちらもDOSにつながる可能性がありますが、許可されていないアクセスにはなりません。
To reduce this risk, it is necessary to configure the routing protocol on the PE router to operate as securely as possible. This can be done in various ways:
このリスクを減らすには、PEルーター上のルーティングプロトコルを可能な限り安全に動作するように構成する必要があります。これはさまざまな方法で実行できます。
o By accepting only routing protocol packets, and only from the CE router. The inbound ACL on each CE interface of the PE router should allow only routing protocol packets from the CE to the PE. o By configuring MD5 authentication for routing protocols. This is available for BGP (RFC 2385 [6]), OSPF (RFC 2154 [4]), and RIP2 (RFC 2082 [3]), for example. This avoids packets being spoofed from other parts of the customer network than the CE router. It requires the service provider and customer to agree on a shared secret between all CE and PE routers. It is necessary to do this for all VPN customers. It is not sufficient to do this only for the customer with the highest security requirements.
o ルーティングプロトコルパケットのみを受け入れ、CEルーターからのみ。PEルーターの各CEインターフェイスのインバウンドACLは、CEからPEへのルーティングプロトコルパケットのみを許可する必要があります。oルーティングプロトコル用のMD5認証を構成します。これは、たとえば、BGP（RFC 2385 [6]）、OSPF（RFC 2154 [4]）、およびRIP2（RFC 2082 [3]）で利用できます。これにより、CEルーターよりも顧客ネットワークの他の部分からパケットがスプーフィングされることを回避できます。サービスプロバイダーと顧客は、すべてのCEルーターとPEルーターの間の共有秘密に同意する必要があります。すべてのVPN顧客に対してこれを行う必要があります。セキュリティ要件が最も高い顧客のためだけにこれを行うだけでは不十分です。
o By configuring parameters of the routing protocol to further secure this communication. For example, the rate of routing updates should be restricted where possible (in BGP through damping); a maximum number of routes accepted per VRF and per routing neighbor should be configured where possible; and the Generalized TTL Security Mechanism (GTSM; RFC 3682 [10]) should be used for all supported protocols.
o ルーティングプロトコルのパラメーターを構成して、この通信をさらに保護します。たとえば、ルーティングの更新率は、可能な限り（BGPで減衰を介して）制限する必要があります。VRFごとに受け入れられている最大数のルートとルーティング隣人ごとに、可能な場合は構成する必要があります。一般化されたTTLセキュリティメカニズム（GTSM; RFC 3682 [10]）は、すべてのサポートされているプロトコルに使用する必要があります。
In summary, it is not possible to intrude from one VPN into other VPNs, or the core. However, it is theoretically possible to attack the routing protocol port to execute a DoS attack against the PE router. This in turn might have a negative impact on other VPNs on this PE router. For this reason, PE routers must be extremely well secured, especially on their interfaces to CE routers. ACLs must be configured to limit access only to the port(s) of the routing protocol, and only from the CE router. Further routing protocols' security mechanisms such as MD5 authentication, maximum prefix limits, and Time to Live (TTL) security mechanisms should be used on all PE-CE peerings. With all these security measures, the only possible attack is a DoS attack against the routing protocol itself. BGP has a number of countermeasures such as prefix filtering and damping built into the protocol, to assist with stability. It is also easy to track the source of such a potential DoS attack. Without dynamic routing between CEs and PEs, the security is equivalent to the security of ATM or Frame Relay networks.
要約すると、あるVPNから他のVPN、またはコアに侵入することはできません。ただし、Routingプロトコルポートを攻撃してPEルーターに対するDOS攻撃を実行することは理論的には可能です。これは、このPEルーターの他のVPNにマイナスの影響を与える可能性があります。このため、特にCEルーターへのインターフェイスでは、PEルーターが非常によくセキュリティである必要があります。ACLは、ルーティングプロトコルのポートへのアクセスのみを制限するように構成する必要があります。MD5認証、最大プレフィックス制限、Live（TTL）のセキュリティメカニズムなどのさらなるルーティングプロトコルのセキュリティメカニズムは、すべてのPE-CEピーリングで使用する必要があります。これらすべてのセキュリティ対策により、唯一の可能な攻撃は、ルーティングプロトコル自体に対するDOS攻撃です。BGPには、安定性を支援するために、プレフィックスフィルタリングやプロトコルに組み込まれた減衰など、多くの対策があります。また、このような潜在的なDOS攻撃の原因を簡単に追跡することもできます。CESとPES間の動的ルーティングがなければ、セキュリティはATMまたはフレームリレーネットワークのセキュリティと同等です。
Similar to IP spoofing attacks, where an attacker fakes the source IP address of a packet, it is also theoretically possible to spoof the label of an MPLS packet. In the first section, the assumption was made that the core network is trusted. If this assumption cannot be made, IPsec must be run over the MPLS cloud. Thus in this section the emphasis is on whether it is possible to insert packets with spoofed labels into the MPLS network from the outside, i.e., from a VPN (CE router) or from the Internet.
攻撃者がパケットのソースIPアドレスを偽装するIPスプーフィング攻撃と同様に、MPLSパケットのラベルをスプーフィングすることも理論的に可能です。最初のセクションでは、コアネットワークが信頼されているという仮定がなされました。この仮定を行うことができない場合、IPSECはMPLSクラウドの上で実行する必要があります。したがって、このセクションでは、スプーフィングされたラベルを含むパケットを外部から、つまりVPN（CEルーター）からインターネットから挿入することが可能かどうかに重点が置かれています。
The interface between a CE router and its peering PE router is an IP interface, i.e., without labels. The CE router is unaware of the MPLS core, and thinks it is sending IP packets to another router. The "intelligence" is done in the PE device, where, based on the configuration, the label is chosen and pre-pended to the packet. This is the case for all PE routers, towards CE routers as well as the upstream service provider. All interfaces into the MPLS cloud only require IP packets, without labels.
CEルーターとそのピアリングPEルーターの間のインターフェイスは、IPインターフェイス、つまりラベルのないものです。CEルーターはMPLSコアに気付いておらず、IPパケットを別のルーターに送信していると考えています。「インテリジェンス」はPEデバイスで行われます。このデバイスでは、構成に基づいてラベルが選択され、パケットにプリペーディングされます。これは、CEルーターと上流のサービスプロバイダーに向けて、すべてのPEルーターの場合です。MPLSクラウドへのすべてのインターフェイスには、ラベルなしでIPパケットのみが必要です。
For security reasons, a PE router should never accept a packet with a label from a CE router. RFC 3031 [9] specifies: "Therefore, when a labeled packet is received with an invalid incoming label, it MUST be discarded, UNLESS it is determined by some means (not within the scope of the current document) that forwarding it unlabeled cannot cause any harm." Since accepting labels on the CE interface would potentially allow passing packets to other VPNs it is not permitted by the RFC.
セキュリティ上の理由から、PEルーターは、CEルーターのラベル付きのパケットを受け入れないでください。RFC 3031 [9]は次のように指定しています。「したがって、ラベル付きのパケットが無効なラベルで受信された場合、それを何らかの手段（現在の文書の範囲内ではなく）で決定しない限り、それは破棄する必要があります。害はありません。」CEインターフェイスでラベルを受け入れると、パケットを他のVPNに渡すことが可能になる可能性があるため、RFCは許可されていません。
Thus, it is impossible for an outside attacker to send labeled packets into the BGP/MPLS IP VPN core.
したがって、外部の攻撃者がラベル付きパケットをBGP/MPLS IP VPNコアに送信することは不可能です。
There remains the possibility to spoof the IP address of a packet being sent to the MPLS core. Since there is strict address separation within the PE router, and each VPN has its own VRF, this can only harm the VPN the spoofed packet originated from; that is, a VPN customer can attack only himself. MPLS doesn't add any security risk here.
MPLSコアに送信されるパケットのIPアドレスをスプーフィングする可能性が残っています。PEルーター内には厳密なアドレス分離があり、各VPNには独自のVRFがあるため、これは由来するVPNにのみ害を及ぼす可能性があります。つまり、VPNの顧客は自分自身のみを攻撃できます。MPLSはここでセキュリティリスクを追加しません。
The Inter-AS and Carrier's Carrier cases are special cases, since on the interfaces between providers typically packets with labels are exchanged. See section 4 for an analysis of these architectures.
AS間およびキャリアのキャリアのケースは特別なケースです。これは、プロバイダー間のインターフェイスで通常、ラベルを持つパケットが交換されるためです。これらのアーキテクチャの分析については、セクション4を参照してください。
ATM and FR VPN services enjoy a very high reputation in terms of security. Although ATM and FR VPNs can be provided in a secure manner, it has been reported that these technologies also can have security vulnerabilities [14]. In ATM/FR as in any other networking technology, the security depends on the configuration of the network being secure, and errors can also lead to security problems.
ATMとFR VPNサービスは、セキュリティの面で非常に高い評価を享受しています。ATMおよびFR VPNは安全な方法で提供できますが、これらの技術にはセキュリティの脆弱性もある可能性があることが報告されています[14]。ATM/FRでは、他のネットワーキングテクノロジーと同様に、セキュリティはネットワークの構成が安全であることに依存し、エラーもセキュリティの問題につながる可能性があります。
The BGP/MPLS IP VPN architecture described in RFC 2547 [7] defines the PE-CE interface as the only external interface seen from the service provider network. In this case, the PE treats the CE as untrusted and only accepts IP packets from the CE. The IP address range is treated as belonging to the VPN of the CE, so the PE maintains full control over VPN separation.
RFC 2547 [7]で説明されているBGP/MPLS IP VPNアーキテクチャは、PE-CEインターフェイスをサービスプロバイダーネットワークから見た唯一の外部インターフェイスとして定義しています。この場合、PEはCEを信頼されていないものとして扱い、CEからのIPパケットのみを受け入れます。IPアドレス範囲はCEのVPNに属するものとして扱われるため、PEはVPN分離を完全に制御します。
RFC 4364 [1] has subsequently defined a more complex architecture, with more open interfaces. These interfaces allow the exchange of label information and labeled packets to and from devices outside the control of the service provider. This section discusses the security implications of this advanced architecture.
RFC 4364 [1]は、その後、より複雑なアーキテクチャを定義し、よりオープンなインターフェイスを備えています。これらのインターフェイスにより、サービスプロバイダーの制御外のデバイスとの間でラベル情報とラベル付きパケットを交換することができます。このセクションでは、この高度なアーキテクチャのセキュリティへの影響について説明します。
In the Carriers' Carrier (CsC) architecture, the CE is linked to a VRF on the PE. The CE may send labeled packets to the PE. The label has been previously assigned by the PE to the CE, and represents the label switched path (LSP) from this CE to the remote CE via the carrier's network.
キャリアキャリア（CSC）アーキテクチャでは、CEはPEのVRFにリンクされています。CEは、ラベル付きパケットをPEに送信する場合があります。ラベルは以前にPEによってCEに割り当てられており、キャリアのネットワークを介してこのCEからリモートCEへのラベルスイッチパス（LSP）を表しています。
RFC 4364 [1] specifies for this case: "When the PE receives a labeled packet from a CE, it must verify that the top label is one that was distributed to that CE." This ensures that the CE can only use labels that the PE correctly associates with the corresponding VPN. Packets with incorrect labels will be discarded, and thus label spoofing is impossible.
RFC 4364 [1]は、このケースに次のように指定しています。「PEがCEからラベル付きパケットを受け取った場合、トップレーベルがそのCEに配布されたものであることを確認する必要があります。」これにより、CEは、PEが対応するVPNと正しく関連するラベルのみを使用できます。誤ったラベルを備えたパケットは破棄されるため、ラベルスプーフィングは不可能です。
The use of label maps on the PE leaves the control of the label information entirely with the PE, so that this has no impact on the security of the solution.
PEでラベルマップを使用すると、ラベル情報の制御がPEで完全に残されているため、これはソリューションのセキュリティに影響を与えません。
The packet underneath the top label will -- as in standard RFC 2547 [7] networks -- remain local to the customer carrier's VPN and not be inspected in the carriers' carrier core. Potential spoofing of subsequent labels or IP addresses remains local to the carrier's VPN; it has no implication on the carriers' carrier core nor on other VPNs in that core. This is specifically stated in section 6 of RFC 4364 [1].
トップレーベルの下にあるパケットは、標準のRFC 2547 [7]ネットワークのように、顧客キャリアのVPNのローカルのままであり、キャリアのキャリアコアでは検査されません。後続のラベルまたはIPアドレスの潜在的なスプーフィングは、キャリアのVPNに地元のままです。キャリアのキャリアコアにも、そのコアの他のVPNにも影響はありません。これは、RFC 4364 [1]のセクション6に特に述べられています。
Note that if the PE and CE are interconnected using a shared layer 2 infrastructure such as a switch, attacks are possible on layer 2, which might enable a third party on the shared layer 2 network to intrude into a VPN on that PE router. RFC 4364 [1] specifies therefore that either all devices on a shared layer 2 network have to be part of the same VPN, or the layer 2 network must be split logically to avoid this issue. This will be discussed in more detail in section 6.
PEとCEがスイッチなどの共有レイヤー2インフラストラクチャを使用して相互接続されている場合、レイヤー2で攻撃が可能であることに注意してください。これにより、共有レイヤー2ネットワーク上の第三者がそのPEルーターのVPNに侵入できるようになります。したがって、RFC 4364 [1]は、共有レイヤー2ネットワーク上のすべてのデバイスのいずれかが同じVPNの一部でなければならないか、この問題を回避するためにレイヤー2ネットワークを論理的に分割する必要があることを指定します。これについては、セクション6で詳しく説明します。
In the CsC architecture, the customer carrier needs to trust the carriers' carrier for correct configuration and operation. The customer of the carrier thus implicitly needs to trust both his carrier and the carriers' carrier.
CSCアーキテクチャでは、顧客キャリアは、正しい構成と操作のためにキャリアのキャリアを信頼する必要があります。したがって、運送業者の顧客は、暗黙的にキャリアとキャリアの運送業者の両方を信頼する必要があります。
In summary, a correctly configured carriers' carrier network provides the same level of security as comparable layer 2 networks or traditional RFC 2547 [7] networks.
要約すると、正しく構成されたキャリアのキャリアネットワークは、比較可能なレイヤー2ネットワークまたは従来のRFC 2547 [7]ネットワークと同じレベルのセキュリティを提供します。
RFC 4364 [1] specifies three sub-cases for the inter-provider backbone (Inter-AS) case.
RFC 4364 [1]は、プロバイダー間バックボーン（AS間）ケースの3つのサブケースを指定します。
a) VRF-to-VRF connections at the autonomous system border routers (ASBRs).
a) 自律システムのボーダールーター（ASBRS）でのVRFからVRF接続。
In this case, each PE sees and treats the other PE as a CE; each will not accept labeled packets, and there is no signaling between the PEs other than inside the VRFs on both sides. Thus, the separation of the VPNs on both sides and the security of those are the same as on a single AS RFC 2547 [7] network. This has already been shown to have the same security properties as traditional layer 2 VPNs.
この場合、各PEは他のPEをCEとして見て扱います。それぞれはラベル付きパケットを受け入れず、両側のVRFの内側以外のPEの間にシグナルはありません。したがって、両側でのVPNの分離とそれらのセキュリティは、RFC 2547 [7]ネットワークと同じです。これは、従来のレイヤー2 VPNと同じセキュリティプロパティを既に持っていることがすでに示されています。
This solution has potential scalability issues in that the ASBRs need to maintain a VRF per VPN, and all of the VRFs need to hold all routes of the specific VPNs. Thus, an ASBR can run into memory problems affecting all VPNs if one single VRF contains too many routes. Thus, the service providers needs to ensure that the ASBRs are properly dimensioned and apply appropriate security measures such as limiting the number of prefixes per VRF.
このソリューションには、ASBRがVPNごとにVRFを維持する必要があり、すべてのVRFが特定のVPNのすべてのルートを保持する必要があるという点で、潜在的なスケーラビリティの問題があります。したがって、1つのVRFにあまりにも多くのルートが含まれている場合、ASBRはすべてのVPNに影響を与えるメモリ問題に遭遇する可能性があります。したがって、サービスプロバイダーは、ASBRが適切に寸法化されていることを確認し、VRFあたりのプレフィックス数を制限するなどの適切なセキュリティ対策を適用する必要があります。
The two service providers connecting their VPNs in this way must trust each other. Since the VPNs are separated on different (sub-)interfaces, all signaling between ASBRs remains within a given VPN. This means that dynamic cross-VPN security breaches are impossible. It is conceivable that a service provider connects a specific VPN to the wrong interface, thus interconnecting two VPNs that should not be connected. This must be controlled operationally.
この方法でVPNを接続する2つのサービスプロバイダーは、お互いを信頼しなければなりません。VPNは異なる（サブ）インターフェイスで分離されているため、ASBR間のすべてのシグナリングは特定のVPN内に残ります。これは、動的なクロスVPNセキュリティ侵害が不可能であることを意味します。サービスプロバイダーが特定のVPNを間違ったインターフェイスに接続し、接続しないでください。これは動作的に制御する必要があります。
b) EBGP redistribution of labeled VPN-IPv4 routes from AS to neighboring AS.
b) ASから隣接するASからの標識VPN-IPV4ルートのEBGP再分布。
In this case, ASBRs on both sides hold full routing information for all shared VPNs on both sides. This is not held in separate VRFs, but in the BGP database. (This is typically limited to the Inter-AS VPNs through filtering.) The separation inside the PE is maintained through the use of VPN-IPv4 addresses. The control plane between the ASBRs uses Multi-Protocol BGP (MP-BGP, RFC 2858 [8]). It exchanges VPN routes as VPN-IPv4 addresses, the ASBR addresses as BGP next-hop IPv4 addresses, and labels to be used in the data plane.
この場合、両側のASBRは、両側のすべての共有VPNの完全なルーティング情報を保持しています。これは、別々のVRFSではなく、BGPデータベースに保持されます。（これは通常、フィルタリングを介してVPNをAS間に制限します。）PE内の分離は、VPN-IPV4アドレスを使用して維持されます。ASBRS間のコントロールプレーンは、マルチプロトコルBGP（MP-BGP、RFC 2858 [8]）を使用します。VPN-IPV4アドレスとしてVPNルートを交換し、ASBRアドレスはBGP Next-Hop IPv4アドレスとして、データプレーンで使用するラベルを交換します。
The data plane is separated through the use of a single label, representing a VRF or a subset thereof. RFC 4364 [1] states that an ASBR should only accept packets with a label that it has assigned to this router. This prevents the insertion of packets with unknown labels, but it is possible for a service provider to use any label that the ASBR of the other provider has passed on. This allows one provider to insert packets into any VPN of the other provider for which it has a label.
データプレーンは、VRFまたはそのサブセットを表す単一のラベルを使用して分離されます。RFC 4364 [1]は、ASBRはこのルーターに割り当てられたラベルを持つパケットのみを受け入れる必要があると述べています。これにより、未知のラベルを持つパケットの挿入が防止されますが、サービスプロバイダーが他のプロバイダーのASBRが渡したラベルを使用することが可能です。これにより、1つのプロバイダーがラベルを持っている他のプロバイダーのVPNにパケットを挿入できます。
This solution also needs to consider the security on layer 2 at the interconnection. The RFC states that this type of interconnection should only be implemented on private interconnection points. See section 6 for more details.
また、このソリューションは、相互接続でレイヤー2のセキュリティを考慮する必要があります。RFCは、このタイプの相互接続はプライベート相互接続ポイントにのみ実装されるべきであると述べています。詳細については、セクション6を参照してください。
RFC 4364 [1] states that a trust relationship between the two connecting ASes must exist for this model to work securely. Effectively, all ASes interconnected in this way form a single zone of trust. The VPN customer needs to trust all the service providers involved in the provisioning of his VPN on this architecture.
RFC 4364 [1]は、このモデルが安全に機能するには、2つの接続ASEの信頼関係が存在する必要があると述べています。事実上、この方法ですべてのASEが相互に接続されていることは、単一の信頼ゾーンを形成します。VPNの顧客は、このアーキテクチャでのVPNのプロビジョニングに関与するすべてのサービスプロバイダーを信頼する必要があります。
c) PEs exchange labeled VPN-IPv4 routes, ASBRs only exchange loopbacks of PEs with labels.
c) VPN-IPV4ルートとラベル付けされたPES Exchange、ASBRSは、ラベルとPESのループバックのみを交換します。
In this solution, there are effectively two control connections between ASes. The route reflectors (RRs) exchange the VPN-IPv4 routes via multihop eBGP. The ASBRs only exchange the labeled addresses of those PE routers that hold VPN routes that are shared between those ASes. This maintains scalability for the ASBRs, since they do not need to know the VPN-IPv4 routes.
このソリューションでは、ASEの間に効果的に2つの制御接続があります。ルートリフレクター（RRS）は、マルチホップEBGPを介してVPN-IPV4ルートを交換します。ASBRSは、ASEの間で共有されるVPNルートを保持するPEルーターのラベル付きアドレスのみを交換します。これにより、VPN-IPV4ルートを知る必要がないため、ASBRのスケーラビリティが維持されます。
In this solution, the top label specifies an LSP to an egress PE router, and the second label specifies a VPN connected to this egress PE. The security of the ASBR connection has the same constraints as in solution b): An ASBR should only accept packets with top labels that it has assigned to the other router, thus verifying that the packet is addressed to a valid PE router. Any label, which was assigned to the other ASBR, will be accepted. It is impossible for an ASBR to distinguish between different egress PEs or between different VPNs on those PEs. A malicious service provider of one AS could introduce packets into any VPN on a PE of the other AS; it only needs a valid LSP on its ASBR and PEs to the corresponding PE on the other AS. The VPN label can be statistically guessed from the theoretical label space, which allows unidirectional traffic into a VPN.
このソリューションでは、トップレーベルは出力PEルーターにLSPを指定し、2番目のラベルはこの出口PEに接続されたVPNを指定します。ASBR接続のセキュリティには、ソリューションと同じ制約がありますb）：ASBRは、他のルーターに割り当てられたトップラベルを持つパケットのみを受け入れる必要があります。したがって、パケットが有効なPEルーターにアドレス指定されることを確認します。他のASBRに割り当てられたすべてのラベルは受け入れられます。ASBRが異なる出力PEを区別することは不可能です。一方の悪意のあるサービスプロバイダーは、他のPEのPEに任意のVPNにパケットを導入できます。ASBRには有効なLSPと、対応するPEに対して他のASに必要なLSPのみが必要です。VPNラベルは、VPNへの単方向トラフィックを可能にする理論ラベル空間から統計的に推測できます。
This means that such an ASBR-ASBR connection can only be made with a trusted party over a private interface, as described in b).
これは、このようなASBR-ASBR接続は、b）に記載されているように、プライベートインターフェイスを介して信頼できる当事者でのみ行うことができることを意味します。
In addition, this solution exchanges labeled VPN-IPv4 addresses between route reflectors (RRs) via MP-eBGP. The control plane itself can be protected via routing authentication (RFC 2385 [6]), which ensures that the routing information has been originated by the expected RR and has not been modified in transit. The received VPN information cannot be verified, as in the previous case. Thus, a service provider can introduce bogus routes for any shared VPN. The ASes need to trust each other to configure their respective networks correctly. All ASes involved in this design form one trusted zone. The customer needs to trust all service providers involved.
さらに、MP-EBGPを介してルートリフレクター（RRS）間のVPN-IPV4アドレスとラベル付けされたこのソリューション交換。コントロールプレーン自体は、ルーティング認証（RFC 2385 [6]）を介して保護できます。これにより、ルーティング情報が予想されるRRによって発信され、輸送中に変更されていないことが保証されます。前の場合のように、受信したVPN情報を検証することはできません。したがって、サービスプロバイダーは、共有VPNに偽のルートを導入できます。ASEは、それぞれのネットワークを正しく構成するためにお互いを信頼する必要があります。この設計に関与するすべてのASEは、1つの信頼できるゾーンを形成します。顧客は、関係するすべてのサービスプロバイダーを信頼する必要があります。
The difference between case b) and case c) is that in b) the ASBRs act as iBGP next-hops for their AS; thus, each SP needs to know of the other SP's core only the addresses of the ASBRs. In case c), the SPs exchange the loopback addresses of their PE routers; thus, each SP reveals information to the other about its PE routers, and these routers must be accessible from the other AS. As stated above, accessibility does not necessarily mean insecurity, and networks should never rely on "security through obscurity". This should not be an issue if the PE routers are appropriately secured. However, there is an increasing perception that network devices should generally not be accessible.
ケースb）とケースc）の違いは、b）asbrsがasのためにibgp次-hopsとして機能することです。したがって、各SPは、ASBRのアドレスのみを他のSPのコアのみを知る必要があります。ケースc）では、SPSはPEルーターのループバックアドレスを交換します。したがって、各SPはそのPEルーターに関する情報を他のSPに明らかにし、これらのルーターは他のルーターからアクセスできる必要があります。上記のように、アクセシビリティは必ずしも不安を意味するわけではなく、ネットワークは「あいまいさを通じてセキュリティ」に依存してはなりません。これは、PEルーターが適切に固定されている場合、問題ではありません。ただし、ネットワークデバイスは一般にアクセスできないはずであるという認識が高まっています。
In addition, there are scalability considerations for case c). A number of BGP peerings have to be made for the overall network including all ASes linked this way. SPs on both sides need to work together in defining a scalable architecture, probably with route reflectors.
さらに、ケースcにはスケーラビリティの考慮事項があります）。この方法でリンクされているすべてのASEを含む、ネットワーク全体に多くのBGPピーリングを作成する必要があります。両側のSPSは、おそらくルートリフレクターを使用して、スケーラブルなアーキテクチャを定義する際に協力する必要があります。
In summary, all of these Inter-AS solutions logically merge several provider networks. For all cases of Inter-AS configuration, all ASes form a single zone of trust and service providers need to trust each other. For the VPN customer, the security of the overall solution is equal to the security of traditional RFC 2547 [7] networks, but the customer needs to trust all service providers involved in the provisioning of this Inter-AS solution.
要約すると、これらのすべてのASソリューションはすべて、いくつかのプロバイダーネットワークを論理的にマージします。AS間の構成のすべての場合、すべてのASEは単一の信頼ゾーンを形成し、サービスプロバイダーはお互いを信頼する必要があります。VPN顧客の場合、ソリューション全体のセキュリティは、従来のRFC 2547 [7]ネットワークのセキュリティに等しくなりますが、顧客はこのInter-ASソリューションのプロビジョニングに関与するすべてのサービスプロバイダーを信頼する必要があります。
5.1. Protection against Misconfigurations of the Core and Attacks 'within' the Core
5.1. コア内のコアと攻撃の誤解に対する保護「コア内」
The security mechanisms discussed here assume correct configuration of the network elements of the core network (PE and P routers). Deliberate or inadvertent misconfiguration may result in severe security leaks.
ここで説明するセキュリティメカニズムは、コアネットワークのネットワーク要素（PEおよびPルーター）の正しい構成を想定しています。意図的または不注意な誤解は、深刻なセキュリティリークをもたらす可能性があります。
Note that this paragraph specifically refers to the core network, i.e., the PE and P elements. Misconfigurations of any of the customer side elements such as the CE router are covered by the security mechanisms above. This means that a potential attacker must have access to either PE or P routers to gain advantage from misconfigurations. If an attacker has access to core elements, or is able to insert into the core additional equipment, he will be able to attack both the core network and the connected VPNs. Thus, the following is important:
この段落は、コアネットワーク、つまりPEおよびP要素を具体的に指していることに注意してください。CEルーターなどの顧客側の要素のいずれかの誤解は、上記のセキュリティメカニズムでカバーされています。これは、潜在的な攻撃者が、誤解から有利になるためにPEまたはPルーターのいずれかにアクセスする必要があることを意味します。攻撃者がコア要素にアクセスできる場合、またはコア追加機器に挿入できる場合、コアネットワークと接続されたVPNの両方を攻撃することができます。したがって、以下は重要です。
o To avoid the risk of misconfigurations, it is important that the equipment is easy to configure and that SP staff have the appropriate training and experience when configuring the network. Proper tools are required to configure the core network. o To minimise the risk of "internal" attacks, the core network must be properly secured. This includes network element security, management security, physical security of the service provider infrastructure, access control to service provider installations, and other standard SP security mechanisms.
o 誤解のリスクを回避するには、機器を設定しやすく、SPスタッフがネットワークを構成する際に適切なトレーニングと経験を持つことが重要です。コアネットワークを構成するには、適切なツールが必要です。o「内部」攻撃のリスクを最小限に抑えるには、コアネットワークを適切に保護する必要があります。これには、ネットワーク要素のセキュリティ、管理セキュリティ、サービスプロバイダーインフラストラクチャの物理的セキュリティ、サービスプロバイダーのインストールへのアクセス制御、およびその他の標準SPセキュリティメカニズムが含まれます。
BGP/MPLS IP VPNs can only provide a secure service if the core network is provided in a secure fashion. This document assumes this to be the case.
BGP/MPLS IP VPNSは、コアネットワークが安全な方法で提供されている場合にのみ安全なサービスを提供できます。このドキュメントは、これが事実であると仮定しています。
There are various approaches to control the security of a core if the VPN customer cannot or does not want to trust the service provider. IPsec from customer-controlled devices is one of them. The document "CE-to-CE Member Verification for Layer 3 VPNs" [13] proposes a CE-based authentication scheme using tokens, aimed at detecting misconfigurations in the MPLS core. The document "MPLS VPN Import/Export Verification" [12] proposes a similar scheme based on using the MD5 routing authentication. Both schemes aim to detect and prevent misconfigurations in the core.
VPNの顧客がサービスプロバイダーを信頼できないか望んでいない場合、コアのセキュリティを制御するためのさまざまなアプローチがあります。顧客制御デバイスのIPSECもその1つです。ドキュメント「レイヤー3 VPNSのCE-to-CEメンバー検証」[13]は、MPLSコアの誤解を検出することを目的としたトークンを使用したCEベースの認証スキームを提案しています。ドキュメント「MPLS VPNインポート/エクスポート検証」[12]は、MD5ルーティング認証の使用に基づいて同様のスキームを提案しています。どちらのスキームも、コアでの誤った採掘を検出および防止することを目指しています。
BGP/MPLS IP VPNs themselves do not provide encryption, integrity, or authentication service. If these are required, IPsec should be used over the MPLS infrastructure. The same applies to ATM and Frame Relay: IPsec can provide these missing services.
BGP/MPLS IP VPN自体は、暗号化、整合性、または認証サービスを提供しません。これらが必要な場合は、IPSECをMPLSインフラストラクチャで使用する必要があります。同じことがATMとフレームリレーにも当てはまります。IPSECは、これらの不足しているサービスを提供できます。
BGP/MPLS IP VPNs can be secured so that they are comparable with other VPN services. However, the security of the core network is only one factor for the overall security of a customer's network. Threats in today's networks do not come only from an "outside" connection, but also from the "inside" and from other entry points (modems, for example). To reach a good security level for a customer network in a BGP/MPLS infrastructure, MPLS security is necessary but not sufficient. The same applies to other VPN technologies like ATM or Frame Relay. See also RFC 2196 [5] for more information on how to secure a network.
BGP/MPLS IP VPNは、他のVPNサービスに匹敵するように保護できます。ただし、コアネットワークのセキュリティは、顧客のネットワークの全体的なセキュリティの1つの要因にすぎません。今日のネットワークの脅威は、「外部」接続からだけでなく、「内部」や他のエントリポイント（モデムなど）からも生じます。BGP/MPLSインフラストラクチャの顧客ネットワークの適切なセキュリティレベルに到達するには、MPLSセキュリティが必要ですが、十分ではありません。同じことが、ATMやフレームリレーなどの他のVPNテクノロジーにも当てはまります。ネットワークを保護する方法の詳細については、RFC 2196 [5]も参照してください。
In most cases of Inter-AS or Carrier's Carrier solutions, a network will be interconnected to other networks via a point-to-point private connection. This connection cannot be interfered with by third parties. It is important to understand that the use of any shared-medium layer 2 technology for such interconnections, such as Ethernet switches, may carry additional security risks.
ほとんどの場合、ASまたはキャリアのキャリアソリューションのほとんどでは、ネットワークはポイントツーポイントプライベート接続を介して他のネットワークに相互接続されます。この接続は、第三者によって干渉することはできません。イーサネットスイッチなど、このような相互接続に共有されたメディウムレイヤー2テクノロジーを使用すると、追加のセキュリティリスクがある可能性があることを理解することが重要です。
There are two types of risks with layer 2 infrastructure:
レイヤー2インフラストラクチャには、2種類のリスクがあります。
a) Attacks against layer 2 protocols or mechanisms
a) レイヤー2プロトコルまたはメカニズムに対する攻撃
Risks in a layer 2 environment include many different forms of Address Resolution Protocol (ARP) attacks, VLAN trunking attacks, or Content Addressable Memory (CAM) overflow attacks. For example, ARP spoofing allows an attacker to redirect traffic between two routers through his device, gaining access to all packets between those two routers.
レイヤー2環境のリスクには、多くの異なる形式のアドレス解像度プロトコル（ARP）攻撃、VLANトランキング攻撃、またはコンテンツアドレス可能なメモリ（CAM）オーバーフロー攻撃が含まれます。たとえば、ARPスプーフィングにより、攻撃者はデバイスを介して2つのルーター間のトラフィックをリダイレクトし、これら2つのルーター間のすべてのパケットにアクセスできます。
These attacks can be prevented by appropriate security measures, but often these security concerns are overlooked. It is of the utmost importance that if a shared medium (such as a switch) is used in the above scenarios, that all available layer 2 security mechanisms are used to prevent layer 2 based attacks.
これらの攻撃は適切なセキュリティ対策によって防ぐことができますが、多くの場合、これらのセキュリティの懸念は見落とされます。上記のシナリオで共有媒体（スイッチなど）が使用されている場合、利用可能なすべてのレイヤー2セキュリティメカニズムがレイヤー2ベースの攻撃を防ぐために使用されることが最も重要です。
b) Traffic insertion attacks
b) トラフィック挿入攻撃
Where many routers share a common layer 2 network (for example, at an Internet exchange point), it is possible for a third party to introduce packets into a network. This has been abused in the past on traditional exchange points when some service providers have defaulted to another provider on this exchange point. In effect, they are sending all their traffic into the other SP's network even though the control plane (routing) might not allow that.
多くのルーターが共通のレイヤー2ネットワークを共有している場合（たとえば、インターネット交換ポイントで）、サードパーティがネットワークにパケットを導入することが可能です。これは、一部のサービスプロバイダーがこの交換ポイントで別のプロバイダーにデフォルトを行ったときに、従来の交換ポイントで過去に乱用されてきました。実際には、コントロールプレーン（ルーティング）が許可されていない場合でも、すべてのトラフィックを他のSPのネットワークに送信しています。
For this reason, routers on exchange points (or other shared layer 2 connections) should only accept non-labeled IP packets into the global routing table. Any labeled packet must be discarded. This maintains the security of connected networks.
このため、交換ポイントのルーター（またはその他の共有レイヤー2接続）は、グローバルルーティングテーブルにリラバルされていないIPパケットのみを受け入れる必要があります。ラベル付きパケットは廃棄する必要があります。これにより、接続されたネットワークのセキュリティが維持されます。
Some of the above designs require the exchange of labeled packets. This would make it possible for a third party to introduce labeled packets, which if correctly crafted might be associated with certain VPNs on an BGP/MPLS IP VPN network, effectively introducing false packets into a VPN.
上記の設計には、ラベル付きパケットの交換が必要です。これにより、サードパーティがラベル付きパケットを導入することが可能になります。これは、BGP/MPLS IP VPNネットワーク上の特定のVPNに正確に作成されている場合、誤ったパケットをVPNに効果的に導入する可能性があります。
The current recommendation is therefore to discard labeled packets on generic shared-medium layer 2 networks such as Internet exchange points (IXPs). Where labeled packets need to be exchanged, it is strongly recommended to use private connections.
したがって、現在の推奨事項は、インターネット交換ポイント（IXPS）などの汎用共有メディアレイヤー2ネットワークにラベル付きパケットを破棄することです。ラベル付きパケットを交換する必要がある場合は、プライベート接続を使用することを強くお勧めします。
BGP/MPLS IP VPNs provide full address and traffic separation as in traditional layer-2 VPN services. It hides addressing structures of the core and other VPNs, and it is not possible to intrude into other VPNs abusing the BGP/MPLS mechanisms. It is also impossible to intrude into the MPLS core if this is properly secured. However, there is a significant difference between BGP/MPLS-based IP VPNs and, for example, FR- or ATM-based VPNs: The control structure of the core is layer 3 in the case of MPLS. This caused significant skepticism in the industry towards MPLS, since this might open the architecture to DoS attacks from other VPNs or the Internet (if connected).
BGP/MPLS IP VPNは、従来のレイヤー2 VPNサービスのように、完全なアドレスとトラフィックの分離を提供します。コアおよび他のVPNのアドレス指定構造を隠しており、BGP/MPLSメカニズムを乱用する他のVPNに侵入することはできません。また、これが適切に保護されている場合、MPLSコアに侵入することも不可能です。ただし、BGP/MPLSベースのIP VPNと、たとえばFRおよびATMベースのVPNには大きな違いがあります。MPLSの場合、コアの制御構造はレイヤー3です。これにより、業界はMPLSに対する業界で大きな懐疑論を引き起こしました。これにより、他のVPNまたはインターネットからのDOS攻撃に対するアーキテクチャが開かれる可能性があるため（接続されている場合）。
As shown in this document, it is possible to secure a BGP/MPLS IP VPN infrastructure to the same level of security as a comparable ATM or FR service. It is also possible to offer Internet connectivity to MPLS VPNs in a secure manner, and to interconnect different VPNs via firewalls. Although ATM and FR services have a strong reputation with regard to security, it has been shown that also in these networks security problems can exist [14].
このドキュメントに示されているように、BGP/MPLS IP VPNインフラストラクチャを同等のATMまたはFRサービスと同じレベルのセキュリティに保護することができます。また、MPLS VPNにインターネット接続を安全な方法で提供し、ファイアウォールを介して異なるVPNを相互接続することも可能です。ATMとFRサービスはセキュリティに関して強い評判を持っていますが、これらのネットワークにはセキュリティの問題が存在する可能性があることが示されています[14]。
As far as attacks from within the MPLS core are concerned, all VPN classes (BGP/MPLS, FR, ATM) have the same problem: If an attacker can install a sniffer, he can read information in all VPNs, and if the attacker has access to the core devices, he can execute a large number of attacks, from packet spoofing to introducing new peer routers. There are a number of precautionary measures outlined above that a service provider can use to tighten security of the core, but the security of the BGP/MPLS IP VPN architecture depends on the security of the service provider. If the service provider is not trusted, the only way to fully secure a VPN against attacks from the "inside" of the VPN service is to run IPsec on top, from the CE devices or beyond.
MPLSコア内からの攻撃に関する限り、すべてのVPNクラス（BGP/MPLS、FR、ATM）に同じ問題があります。攻撃者がスニファーをインストールできる場合、すべてのVPNで情報を読むことができ、攻撃者が持っている場合コアデバイスへのアクセスでは、パケットスプーフィングから新しいピアルーターの導入まで、多数の攻撃を実行できます。サービスプロバイダーがコアのセキュリティを強化するために使用できる上記の多くの予防措置がありますが、BGP/MPLS IP VPNアーキテクチャのセキュリティはサービスプロバイダーのセキュリティに依存します。サービスプロバイダーが信頼されていない場合、VPNサービスの「内部」からの攻撃に対してVPNを完全に保護する唯一の方法は、CEデバイスまたはそれ以降からIPSECを上に実行することです。
This document discussed many aspects of BGP/MPLS IP VPN security. It has to be noted that the overall security of this architecture depends on all components and is determined by the security of the weakest part of the solution. For example, a perfectly secured static BGP/MPLS IP VPN network with secured Internet access and secure management is still open to many attacks if there is a weak remote access solution in place.
このドキュメントでは、BGP/MPLS IP VPNセキュリティの多くの側面について説明しました。このアーキテクチャの全体的なセキュリティは、すべてのコンポーネントに依存し、ソリューションの最も弱い部分のセキュリティによって決定されることに注意する必要があります。たとえば、保護されたインターネットアクセスと安全な管理を備えた完全に保護された静的BGP/MPLS IP VPNネットワークは、弱いリモートアクセスソリューションが整っている場合、多くの攻撃に対して開かれています。
The entire document is discussing security considerations of the RFC 4364 [1] architecture.
ドキュメント全体では、RFC 4364 [1]アーキテクチャのセキュリティ上の考慮事項について説明しています。
The author would like to thank everybody who has provided input to this document. Specific thanks go to Yakov Rekhter, for his continued strong support, and Eric Rosen, Loa Andersson, Alexander Renner, Jim Guichard, Monique Morrow, Eric Vyncke, and Steve Simlo, for their extended feedback and support.
著者は、この文書に入力を提供したすべての人に感謝したいと思います。彼の継続的な強力なサポートについて、Yakov Rekhterに感謝します。エリック・ローゼン、ロア・アンダーソン、アレクサンダー・レナー、ジム・ギチャード、モニーク・モロー、エリック・ヴィンケ、スティーブ・シムロの拡張フィードバックとサポート。
[1] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[1] Rosen、E。and Y. Rekhter、「BGP/MPLS IP仮想プライベートネットワーク（VPNS）」、RFC 4364、2006年2月。
[2] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[2] Rekhter、Y.、Moskowitz、R.、Karrenberg、D.、Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[3] Baker, F., Atkinson, R., and G. Malkin, "RIP-2 MD5 Authentication", RFC 2082, January 1997.
[3] Baker、F.、Atkinson、R。、およびG. Malkin、「RIP-2 MD5認証」、RFC 2082、1997年1月。
[4] Murphy, S., Badger, M., and B. Wellington, "OSPF with Digital Signatures", RFC 2154, June 1997.
[4] Murphy、S.、Badger、M.、およびB. Wellington、「Digital Signatures with Digital Signatures」、RFC 2154、1997年6月。
[5] Fraser, B., "Site Security Handbook", RFC 2196, September 1997.
[5] Fraser、B。、「サイトセキュリティハンドブック」、RFC 2196、1997年9月。
[6] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[6] Heffernan、A。、「TCP MD5署名オプションによるBGPセッションの保護」、RFC 2385、1998年8月。
[7] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March 1999.
[7] Rosen、E。およびY. Rekhter、「BGP/MPLS VPNS」、RFC 2547、1999年3月。
[8] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
[8] Bates、T.、Rekhter、Y.、Chandra、R。、およびD. Katz、「BGP-4のマルチプロトコル拡張」、RFC 2858、2000年6月。
[9] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[9] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。
[10] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL Security Mechanism (GTSM)", RFC 3682, February 2004.
[10] Gill、V.、Heasley、J。、およびD. Meyer、「一般化されたTTLセキュリティメカニズム（GTSM）」、RFC 3682、2004年2月。
[11] Fang, L., "Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4111, July 2005.
[11] Fang、L。、「プロバイダーがプロビジョニングされた仮想プライベートネットワーク（PPVPNS）のセキュリティフレームワーク」、RFC 4111、2005年7月。
[12] Behringer, M., Guichard, J., and P. Marques, "MPLS VPN Import/Export Verification", Work in Progress, June 2004.
[12] Behringer、M.、Guichard、J。、およびP. Marques、「MPLS VPNインポート/エクスポート検証」、2004年6月、進行中の作業。
[13] Bonica, R. and Y. Rekhter, "CE-to-CE Member Verification for Layer 3 VPNs", Work in Progress, September 2003.
[13] Bonica、R。およびY. Rekhter、「レイヤー3 VPNSのCe-to-CEメンバー検証」、2003年9月、進行中の作業。
[14] DataComm, "Data Communications Report, Vol 15, No 4: Frame Relay and ATM: Are they really secure?", February 2000.
[14] DataComm、「Data Communications Report、Vol 15、No 4：Frame Relay and ATM：本当に安全ですか？」、2000年2月。
Author's Address
著者の連絡先
Michael H. Behringer Cisco Systems Inc Village d'Entreprises Green Side 400, Avenue Roumanille, Batiment T 3 Biot - Sophia Antipolis 06410 France
Michael H. Behringer Cisco Systems Inc Village D'Entreprises Green Side 400、Avenue Roumanille、Batiment T 3 Biot -Sophia Antipolis 06410 France
EMail: mbehring@cisco.com
URI: http://www.cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78およびwww.rfc-editor.org/copyright.htmlに含まれる権利、ライセンス、および制限の対象となり、その中に記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。