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)
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).
著作権（C）インターネット協会（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はインターネットStandardのどんなレベルの候補ではありません。 IETFは、いかなる目的のために、このRFCのフィットネスの知識を否認し、特にノートに公開するという決定は、セキュリティ、輻輳制御または展開されたプロトコルとの不適切な相互作用のようなもののためにIETFレビューに基づいていないこと。 RFC Editorはその裁量でこの文書を公開することを選択しました。この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の顧客への懸念が高まっています。この文書では、[1] RFC 4364に記載されている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コアは、」プロバイダエッジ（PE）及びプロバイダ（P）は、典型的には、単一のサービスプロバイダ（SP）の制御下で、BGP / MPLS IP VPNサービスを提供するルータのセットとして、この文書のために定義されています。この文書では、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.
アーキテクチャ、実装、およびシステムの動作：システム全体のセキュリティは、三つの側面があります。セキュリティの問題は、これらの態様のいずれかに存在することができます。この文書は、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].
この文書は、サービスプロバイダーや企業の技術スタッフを対象としています。基本的なBGP / MPLS IP VPNアーキテクチャの知識RFC 4364に記載されているように[1]このドキュメントを理解する必要があります。特定のレイヤ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章では、マルチ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サービスと顧客のいずれかのタイプを提供し、両方のサービスプロバイダは、セキュリティのための特定の要求を持っています。これらは広く展開して受け入れられているので、ほとんどの場合、彼らは、フレームリレーやATMなどの伝統的なレイヤ2ベースのVPNソリューションとMPLSベースのソリューションを比較します。このセクションでは、VPNネットワークの代表的なセキュリティ要件の概要を説明します。次のセクションでは、以下の場合に、どのようにBGP / MPLS IP VPNのは、MPLSコアと接続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は、独立したアドレス空間を持っていると仮定されます。例えば、二つの非交差VPNは、各競合することなく同じ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トラフィックは、1 VPNから、トラフィックをルーティングすることを含む、別のVPNに流れてはなりません。 1つのVPNインスタンスに対して、情報、ならびにその情報の配布とルーティング処理をoを他の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内のホストABCD宛てのパケットを防ぐために、それがない場合でも、他の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 Securityフレームワーク[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.
DoS攻撃、資源は資源が無許可のユーザーに利用できるようになる許可されたユーザー、および侵入に利用できなくなる：攻撃の2つの基本タイプがあります。 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つの基本的な方法がある：最初に、悪用される可能性プロトコルを硬化させる（例えば、ルータへのTelnet）、及び第二、できるだけネットワークのようなアクセスできないようにします。上述したようにこれは、パケットフィルタリング/ファイアウォールとアドレス隠蔽の組み合わせにより達成されます。
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.
単一の既知のIPアドレスは、マシンを攻撃するのに十分な情報であるかもしれないので、DoS攻撃は、実行するのが容易です。これは、トラフィックを「許可」が、他のユーザーが対象マシンにアクセスできないように、通常のパケット率よりも高いを使用して、通常のを使用して行うことができます。この種の攻撃に難攻不落なるための唯一の方法は、再びパケットフィルタリングにより、任意のアドレス隠蔽により、マシンは到達できないことを確認することです。
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コア内から、外部から行うことができます。我々は、コアネットワークが確実に提供されることを前提とするので（コア内から）、後者の場合には、説明しません。安全でないコアに対する保護が必要とされなければならないPEがコアに属しているので、少なくとも、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ラベルスプーフィングまたは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]）。これは、MPLSコアでもユニークなVPN-一意のアドレスを作り、各IPv4ルートに64ビットのルート識別子（RD）を添加することによって達成されます。この「拡張」アドレスも、「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
各PEルータは、各接続されたVPNのための別個の仮想ルーティングおよび転送インスタンス（VRF）を維持します。 VRFは、VPNのアドレスだけでなく、CEルータはピアリングされるPEルータのアドレスを含みます。これらのPEアドレスを含むVRFのすべてのアドレスは、VPNに論理的に属し、VPNからアクセスできます。 PEアドレスがVPNにアクセス可能であるという事実は、パケットフィルタは、PEルータ上のVRFのすべてのアドレスへのアクセスをブロックするために展開することができますので、スタティックルーティングは、PEとCEルータ間で使用されている場合は問題ではありません。動的ルーティングプロトコルが使用される場合、CEルータは、設定コア内のピアPEルータのアドレスを有する必要があります。サービスプロバイダーが管理する環境では、
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.
CPEとしてCEルータは、これは顧客には見えないことができます。 （ピアリングPEアドレスを含む）CE-PEリンク上のアドレス空間は、VPNアドレス空間の一部とみなされます。アドレス空間は、VPNの間で重複することができるので、CE-PEリンクアドレスは、VPNの間で重複することができます。実用的な管理を考慮して、SPは、典型的には、コアを横切って一意性を維持し、グローバルプールから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ルータ間で実行するルーティングプロトコルを介しての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、[8] RFC 2858）コアを横切ることによりPEルータ間で交換されます。これらのBGPルーティングアップデートはだけ情報がVPN-特定のVRFに再び保持され、他のPEルータへの、コアに再分配されません。このように、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-特定のラベルプリペンディング入口PEによって達成されます。 VPNラベル付きパケットは、VPNラベルが出口VRFを選択するために使用される出口PEにコアを介して送信されます。
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 VPNの中で達成することができます。しかし、暗号化は、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）からのパケットをフィルタリングするために、任意のコア・ネットワークのために推奨されています。これは、コアルータへのpingなどの一部の機能が失われますが、それは非常に難しい、コアを攻撃することができます。それはコア外部の宛先を扱うため、コア間で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ネットワーク（インターネットにアクセス）で、これは、既存のレイヤ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ルータ（S）（S）インターネットのピアリングのピアリングアドレス（複数可）を除いて、明らかにされません。これらのアドレスは、従来の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クラウドからのインターネットアクセスでは、サービスプロバイダは、次のプロバイダに（ピアリングPEルータの）少なくとも1つのIPアドレスを明らかにしているので、外の世界へ。
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).
直接PEルータを攻撃することによって1。 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ルータのピアインターフェイスである。このルールの唯一の例外があります。 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の背後にあるネットワークへの静的ルートで構成され、およびCEが静的VPNの他の部分の任意のネットワーク（主にデフォルトルート）のためにPEルータを指すように構成されています。二つのサブケースがある：静的ルートは、PEルータのIPアドレスまたはCEルータ（例えば、シリアル0）のインターフェイスを指すことができます。 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（RID、即ち、ピアのIPアドレス）を知っている必要があり、したがって、攻撃の潜在的な宛先を有しています。一つは、ルータ上で実行されているさまざまなサービスで様々な攻撃を想像できます。実際には、CE-PEインタフェースを介してPEルータへのアクセスはアクセス制御リスト（ACL）を使用して、必要なルーティングプロトコルに限定することができます。これは、1つのルーティングプロトコル、例えば、BGPへの攻撃のポイントを制限します。潜在的な攻撃は、ルートの広範な数を送信する、またはルーティングアップデートと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はPEにCEからのみルーティングプロトコルパケットを許可すべきです。ルーティングプロトコルのMD5認証を構成することにより、O。これは、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から侵入することは不可能です。しかし、PEルータに対してDoS攻撃を実行するルーティングプロトコルポートを攻撃することは理論的に可能です。これは、順番に、このPEルータ上の他のVPNにマイナスの影響があるかもしれません。この理由のため、PEルータは、特にCEルータへのインターフェイス上で、非常に良好に確保しなければなりません。 ACLは、唯一のルーティングプロトコルのポート（複数可）に、唯一CEルータからのアクセスを制限するように構成されなければなりません。例えばMD5認証など、さらにルーティングプロトコルのセキュリティメカニズム、最大プレフィクスの制限、及び生存時間（TTL）セキュリティメカニズムは、すべてのPE-CEピアリングに使用されるべきです。これらすべてのセキュリティ対策では、唯一可能な攻撃は、ルーティングプロトコル自体に対するDoS攻撃です。 BGPは、プレフィックスフィルタリングなどの対策の数を有し、かつ安定性を補助するために、プロトコルに組み込まれたダンピング。このような潜在的なDoS攻撃の発生源を追跡することも容易です。 CEとPE間の動的ルーティングなしに、セキュリティが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ルータ）から、又はインターネットから、外部からMPLSネットワークに偽装されたラベル付きパケットを挿入することが可能であるかどうかです。
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インターフェイス上でラベルを受け入れるための潜在的にそれはRFCによって許可されていない他のVPNにパケットを渡すことが可能になります。
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.
プロバイダ間のインターフェイス上で、通常のラベルが交換されるとパケット以来のInter-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に記載のBGP / MPLS IP VPNアーキテクチャ[7]サービスプロバイダネットワークから見た唯一の外部インターフェースとして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に標識されたパケットを送信することができます。ラベルは、以前にCEにPEによって割り当てられ、ラベルがキャリアのネットワークを介して遠隔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].
トップラベルの下にパケットがあろう - 2547標準RFCのように[7]ネットワークは、 - 顧客のキャリアのVPNに対してローカルのままであり、キャリアのキャリア芯材に検査することがありません。その後のラベルやIPアドレスの潜在的なスプーフィングは、キャリアのVPNにローカルのまま。それはキャリアのキャリアコア上でも、コア内の他のVPNには何の意味を持っていません。これは、特にRFC 4364のセクション6に記載されている[1]。
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のインフラストラクチャを使用して相互接続されている場合は、攻撃がそのPEルータ上のVPNに侵入するために、共有レイヤ2ネットワーク上のサードパーティを有効かもしれない層2の上に可能であることに留意されたいです。 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）自律システム境界ルータ（ASBRが）で、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は、CEのような他のPEを見て扱います。それぞれは、標識されたパケットを受け入れないであろう、そして両側の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のすべてのルートを保持する必要があることの潜在的なスケーラビリティの問題があります。このように、ASBRは、1つのVRFがあまりにも多くのルートが含まれている場合は、すべての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のセキュリティ侵害が不可能であることを意味します。サービスプロバイダは、このように接続されるべきではない2つのVPNを相互接続する、間違ったインターフェイスに特定のVPNを接続することが考えられます。これは、運用に制御しなければなりません。
b) EBGP redistribution of labeled VPN-IPv4 routes from AS to neighboring AS.
隣接ASへのASからの標識されたVPN-IPv4経路のB）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の完全なルーティング情報を保持します。これは、別のVRFではなく、BGPデータベース内に保持されていません。 （これは、典型的には、フィルタを介してインターAS VPNに限定されている。）PE内部分離は、VPN-IPv4アドレスを使用することによって維持されます。 ASBR間の制御プレーンは、マルチプロトコルBGP使用（MP-BGPは、RFC 2858 [8]）。これは、BGPネクストホップIPv4アドレス、およびデータプレーンで使用するラベルとしてASBRアドレス、VPN-IPv4アドレスとしてVPNルートを交換します。
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つの接続AS間の信頼関係が存在しなければならないと述べています。事実上、このように相互接続され、すべてのASは、信頼の単一のゾーンを形成します。 VPNの顧客は、このアーキテクチャ上の彼のVPNのプロビジョニングに関係するすべてのサービスプロバイダを信頼する必要があります。
c) PEs exchange labeled VPN-IPv4 routes, ASBRs only exchange loopbacks of PEs with labels.
C）のPES交換は、VPN-IPv4ルート、ラベル付きのASBRのPEのみ交換ループバックを標識しました。
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.
このソリューションでは、AS間つの制御接続が効果的に存在します。ルートリフレクタ（RRS）は、マルチホップのeBGPを介してVPN-IPv4ルートを交換します。 ASBRは、それらのAS間で共有される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を指定し、第二の標識は、この出口PEに接続されたVPNを指定します。 ASBR接続のセキュリティは）溶液Bと同じ制約があります。ASBRは、それは、このようにパケットが有効なPEルータ宛てであることを確認し、他のルータに割り当てられた最上位ラベルの付いたパケットを受け入れる必要があります。他のASBRに割り当てられた任意のラベルには、受け入れられます。 ASBRが異なる出口PE間またはそれらのPE上の異なるVPNを区別することは不可能です。一つとしての悪意のあるサービスプロバイダは、他のASのPE上の任意のVPNにパケットを導入することができ、それだけで、他のASに対応するPEへのASBRおよびPEの上で有効な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).
これは、b）で説明したようなASBR-ASBR接続のみ、プライベートインターフェイス上で、信頼できる相手と行うことができることを意味します。
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アドレスを標識。制御プレーン自体は、ルーティング情報が期待RRによって発信されており、トランジットで変更されていないことを確実にルーティング認証（RFC 2385 [6]）を介して保護することができます。受信されたVPN情報は、以前の場合のように、確認することができません。このように、サービスプロバイダは、任意の共有VPNのための偽のルートを導入することができます。 ASが正しくそれぞれのネットワークを設定するには、お互いを信頼する必要があります。このデザインフォーム1信頼ゾーンに関わるすべてのAS。顧客は、関係するすべてのサービスプロバイダを信頼する必要があります。
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）でのASBRは、そのASのためのiBGPネクストホップとして働くことです。このように、各SPは他のSPのコアのASBRのアドレスのみを知っている必要があります。ケースc）において、SPはそのPEルータのループバックアドレスを交換します。従って、各SPは、PEルータに関する他の情報を明らかにし、これらのルータは、他のASからアクセス可能でなければなりません。上述したように、アクセシビリティが必ずしも不安を意味するものではありません、とのネットワークは、「あいまいさを使用してセキュリティ」に頼るべきではありません。 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のスケーラビリティの考慮事項が）あります。 BGPピアリングの数はこのようにリンクされているすべてのASを含むネットワーク全体のために作らなければなりません。両側のSPは、おそらくルートリフレクタと、スケーラブルなアーキテクチャを定義する際に一緒に作業する必要があります。
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構成のすべてのケースでは、すべてのASは信頼の単一のゾーンを形成し、サービスプロバイダは、互いを信頼する必要があります。 VPNの顧客のために、ソリューション全体のセキュリティは、従来のRFC 2547 [7]ネットワークのセキュリティに等しいですが、お客様は、このインターASソリューションの提供に関わるすべてのサービスプロバイダを信頼する必要があります。
5.1. Protection against Misconfigurations of the Core and Attacks 'within' the Core
5.1. コアの設定ミスとCore「内の」攻撃に対する保護
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 VPNは唯一の安全なサービスを提供することができます。この文書では、このようなケースであることを前提としています。
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はそのうちの一つです。文書「CE-に-CEメンバー検証レイヤ3つのVPNは、」[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.
彼らは他のVPNサービスと同等になるように、BGP / MPLS IP VPNを確保することができます。しかし、コアネットワークのセキュリティは、お客様のネットワーク全体のセキュリティのための唯一の要因です。今日のネットワークにおける脅威は、「外」の接続から、だけでなく、「内側」から、その他のエントリポイント（例えばモデム）からのみ付属していません。 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.
上記の設計の中には、ラベル付きパケットの交換を必要とします。第三者が正しく作られた場合に効果的にVPNに偽のパケットを導入し、BGP / MPLS IP 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.
現在の推奨は2つのネットワーク例えばインターネットエクスチェンジ（のIXP）などの一般的な共有媒体層上に標識されたパケットを廃棄することです。ラベル付きパケットを交換する必要がある場合は、それを強くプライベート接続を使用することをお勧めします。
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です。これは他のVPNやインターネットからのDoS攻撃にアーキテクチャを開くことがありますので、（接続されている場合）これは、MPLSに向けて業界に大きな懐疑的な見方を引き起こしました。
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].
この文書に示されているように、同等のATMまたはFRサービスと同じレベルのセキュリティにBGP / MPLS IP VPNインフラストラクチャを確保することができます。安全な方法で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.
著者は、この文書に入力を提供してきたみんなに感謝したいと思います。特定のおかげで彼らの拡張フィードバックとサポートのために、彼の継続的な強力な支援のためのヤコフ・レックター、そしてエリック・ローゼン、ロア・アンダーソン、アレクサンダー・レナー、ジム・ギシャール、モニークモロー、エリックVyncke、とスティーブSimloに行きます。
[1] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[1]ローゼン、E.およびY. Rekhter、 "BGP / MPLS IP仮想プライベートネットワーク（VPN）"、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.、モスコウィッツ、R.、Karrenberg、D.、グルート、G.、およびE.リア、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月を。
[3] Baker, F., Atkinson, R., and G. Malkin, "RIP-2 MD5 Authentication", RFC 2082, January 1997.
[3]ベーカー、F.、アトキンソン、R.、およびG.マルキン、 "RIP-2 MD5認証"、RFC 2082、1997年1月。
[4] Murphy, S., Badger, M., and B. Wellington, "OSPF with Digital Signatures", RFC 2154, June 1997.
[4]マーフィー、S.、アナグマ、M.、およびB.ウェリントン、 "デジタル署名とOSPF"、RFC 2154、1997年6月。
[5] Fraser, B., "Site Security Handbook", RFC 2196, September 1997.
[5]フレイザー、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]ローゼン、E.およびY. Rekhter、 "BGP / MPLS VPNの"、RFC 2547、1999年3月。
[8] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
[8]ベイツ、T.、Rekhter、Y.、チャンドラ、R.、およびD.カッツ、RFC 2858、2000年6月 "BGP-4のためのマルチプロトコル拡張機能"。
[9] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[9]ローゼン、E.、Viswanathanの、A.、およびR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、RFC 3031、2001年1月。
[10] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL Security Mechanism (GTSM)", RFC 3682, February 2004.
[10]ギル、V.、Heasley、J.、およびD.マイヤー、 "一般TTLセキュリティメカニズム（GTSM）"、RFC 3682、2004年2月。
[11] Fang, L., "Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4111, July 2005.
[11]牙、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]ベリンガー、M.、ギシャール、J.、およびP.マルケス、 "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、 "CE-に-CEメンバー検証レイヤ3 VPNのため"、進歩、2003年9月の作業。
[14] DataComm, "Data Communications Report, Vol 15, No 4: Frame Relay and ATM: Are they really secure?", February 2000.
[14] DataComm、 "データ通信レポート、第15巻は、ありません4：フレームリレーや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
マイケル・H. Behringerのシスコシステムズ株式会社ヴィレッジグリーン企業サイド400アベニューRoumanille Batiment T 3ビオ - ソフィアアンティポリスフランス06410
EMail: mbehring@cisco.com URI: http://www.cisco.com
電子メール：mbehring@cisco.com URI：http://www.cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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）によって提供されます。