RFC4381 日本語訳
4381 Analysis of the Security of BGP/MPLS IP Virtual Private Networks(VPNs). M. Behringer. February 2006. (Format: TXT=55200 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Behringer Request for Comments: 4381 Cisco Systems Inc Category: Informational February 2006
Behringerがコメントのために要求するワーキンググループM.をネットワークでつないでください: 4381年のシスコシステムズIncカテゴリ: 情報の2006年2月
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)インターネット協会(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はどんな目的、および発行するという決定が配布しているプロトコルとのセキュリティのようなもの、輻輳制御または不適当な相互作用のためのIETFレビューに基づいていないという特定のメモでもこのRFCのフィットネスに関するどんな知識も放棄します。 RFC Editorは、自己判断でこのドキュメントを発表するのを選びました。 このRFCの読者は実装と展開のために値を評価する際に警戒するべきです。 詳しい情報に関してRFC3932を見てください。
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.
このドキュメントはRFC4364で説明されるBGP/MPLS IP仮想私設網(VPN)アーキテクチャのセキュリティを分析します、サービスプロバイダーの利益と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ネットワークが伝統的な層-2VPNがAsynchronous Transfer Mode(ATM)を使用するか、Frame Relayを調整するのと同じくらい安全であることができることを示します。
Behringer Informational [Page 1] RFC 4381 Security of BGP/MPLS IP VPNs February 2006
BGP/MPLS IP VPNs2006年2月のBehringerの情報[1ページ]のRFC4381セキュリティ
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
1. 範囲と序論…3 2. VPNネットワークのセキュリティ要件…4 2.1. アドレス空間、ルート設定、およびトラフィック分離…4 2.2. コアインフラストラクチャを隠します…5 2.3. 攻撃への抵抗…5 2.4. ラベルスプーフィングの不可能…6 3. BGP/MPLS IP VPNセキュリティの分析…6 3.1. アドレス空間、ルート設定、およびトラフィック分離…6 3.2. BGP/MPLS IP VPNコアインフラストラクチャの隠れること…7 3.3. 攻撃への抵抗…9 3.4. スプーフィングをラベルしてください…11 3.5. 気圧/FR VPNsとの比較…12 4. 高度なBGP/MPLS IP VPNアーキテクチャのセキュリティ…12 4.1. キャリアズキャリア…13 4.2. 相互プロバイダーバックボーン…14 5. BGP/MPLS IP VPNsがすることは提供されません…16 5.1. コアと攻撃'within'コアのMisconfigurationsに対する保護…16 5.2. データ暗号化、保全、および発生源認証…17 5.3. 顧客ネットワークセキュリティ…17 6. 2つのセキュリティ問題を層にしてください…18 7. 概要と結論…19 8. セキュリティ問題…20 9. 承認…20 10. 標準の参照…20 11. 有益な参照…20
Behringer Informational [Page 2] RFC 4381 Security of BGP/MPLS IP VPNs February 2006
BGP/MPLS IP VPNs2006年2月のBehringerの情報[2ページ]のRFC4381セキュリティ
1. Scope and Introduction
1. 範囲と序論
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.
Multiprotocol Label Switching(MPLS)がIP仮想私設網(VPN)サービスを提供するための、より広範囲の技術になっているように、BGP/MPLS IP VPNアーキテクチャのセキュリティはサービスプロバイダーとVPN顧客への高まる関心のものです。 このドキュメントは、RFC4364[1]で説明されるBGP/MPLS IP VPNアーキテクチャのセキュリティの概要を与えて、伝統的にATMかFrame Relayなどの層-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コア」という用語はこのドキュメントのためにProvider Edge(PE)とBGP/MPLS IP VPNサービスを提供するプロバイダー(P)ルータのセットと定義されます、通常ただ一つのサービスプロバイダー(SP)のコントロールの下で。 このドキュメントは、MPLSコアネットワークが信じられて安全であると仮定します。 したがって、それは、基本的なセキュリティが権限のないアクセスに対するネットワーク要素、コアのmisconfigurationsを固定するか、コアへの内部の攻撃などの関心であると扱いません。 サービスプロバイダーネットワークを信じたがっていない顧客は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 VPNsのセキュリティ機能だけを分析します。 また、IPsecへのMPLS VPNsの組み合わせを強調する以外に、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 VPNsの建築セキュリティだけを分析します。
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].
このドキュメントはサービスプロバイダーと企業の技術スタッフをターゲットにします。 RFC4364[1]の説明されるとしての基本的なBGP/MPLS IP VPNアーキテクチャに関する知識が、このドキュメントを理解するのに必要です。 特定のLayer3について、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はRFC4364[1]がどうこれらの要件を扱うかを分析します。 セクション4はマルチAS(自治のSystem)MPLSアーキテクチャの特定の安全保障問題について論じます、そして、セクション5はこのアーキテクチャでカバーされていなくて、したがって別々に扱われる必要があるセキュリティ機能を記載します。 セクション6は総合的なBGP/MPLS IP VPNサービスのセキュリティに影響を与えるかもしれない層2に潜在的安全保障問題を強調します。 このドキュメントの調査結果はセクション7でまとめられます。
Behringer Informational [Page 3] RFC 4381 Security of BGP/MPLS IP VPNs February 2006
BGP/MPLS IP VPNs2006年2月のBehringerの情報[3ページ]のRFC4381セキュリティ
2. Security Requirements of VPN Networks
2. VPNネットワークのセキュリティ要件
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サービスと顧客も提供する両方のサービスプロバイダーがセキュリティの特定の要求を持っています。 ほとんど、彼らはFrame RelayやATMなどの伝統的な層の2ベースのVPN溶液とMPLSベースのソリューションを比べます、これらを広く配布して、受け入れるので。 このセクションはVPNネットワークのための典型的なセキュリティ要件について概説します。 以下のセクションが論ずる、そして、BGP/MPLS IP VPNsは、両方のためのこれらの要件がMPLSコアと接続VPNsであるとどう扱うか。
2.1. Address Space, Routing, and Traffic Separation
2.1. アドレス空間、ルート設定、およびトラフィック分離
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のVPNsには独立しているアドレス空間があると思われます。 例えば、2非交差VPNsが闘争なしで同じ10/8のネットワーク・アドレスをそれぞれ使用するかもしれません。 さらに、1VPNからのトラフィックは別の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 Any VPNはMPLSコアと同じアドレス空間を使用できなければなりません。1VPNからトラフィックを発送するのを含むo Trafficは別の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の中のホスト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 Security Framework[11]で定義される秘密性はVPNsの簡単な分離を越えて、どんなトランスミッション媒体も立ち聞きすることに対する保護を提供する要件です。 暗号化は秘密性を提供するのに使用されるメカニズムです。 多くの既存のVPN展開がトランジットトラフィックを暗号化しないので、このドキュメントは、秘密性が任意のVPN要件であると考えます。
Behringer Informational [Page 4] RFC 4381 Security of BGP/MPLS IP VPNs February 2006
BGP/MPLS IP VPNs2006年2月のBehringerの情報[4ページ]のRFC4381セキュリティ
2.2. Hiding the Core Infrastructure
2.2. コアインフラストラクチャを隠します。
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のインフラストラクチャ(例えば、Frame Relay、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.
セキュリティは不鮮明、すなわち、情報の隠れることを完全に決して当てにするべきではありません。 実装が知られているなら、サービスは等しく安全であるべきです。 しかしながら、詳細を隠して、有利な強気市況知覚があります。 このポイントはその市場認識を扱います。
2.3. Resistance to Attacks
2.3. 攻撃への抵抗
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つの基本的な方法があります: まず最初に、それは、プロトコルを堅くするために、乱用されて(例えば、ルータへのTelnet)、できるだけ近づきがたいネットワークを造と後援するかもしれません。 これはパケットフィルタリング/firewallingの組み合わせと上で議論するように隠れるアドレスによって達成されます。
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.
このドキュメントはコアのすなわち、「外部」、インターネットからの攻撃に対するネットワークと接続VPNsを保護するのに集中します。 ここで“inside"からの攻撃に対する保護(すなわち、論理的であるか物理的なアクセスをコアネットワークに持っている攻撃者)について議論しません。
Behringer Informational [Page 5] RFC 4381 Security of BGP/MPLS IP VPNs February 2006
BGP/MPLS IP VPNs2006年2月のBehringerの情報[5ページ]のRFC4381セキュリティ
2.4. Impossibility of Label Spoofing
2.4. ラベルスプーフィングの不可能
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.
アドレスとトラフィックが上で議論した分離であると仮定する場合、攻撃者は彼がするラベルがあるパケットを挿入するのによる他のVPNsが「所有していない」アクセスに試みるかもしれません。 これは、すなわち、外部、別のCustomer Edgeからされた(CE)ルータであるかインターネットか、MPLSコアからのそうであることができました。 後者のケース(コアからの)について議論しないでしょう、私たちが、コアネットワークがしっかりと提供されると思うので。 不安定なコアに対する保護が必要であるなら、MPLSインフラストラクチャの向こう側のIPsecなどのセキュリティプロトコルを使用するのが必要です、少なくともCEからCEまで、PEsがコアに属すので。
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ルータに関連づけられる方法によって、同じPEに接続されるVPNに押し入るのは可能であるかもしれません、802.1Q-ラベルスプーフィングかATM VPI/VCIスプーフィングなどの層2の攻撃メカニズムを使用して。 セクション6で層2の安全保障問題について議論するでしょう。
It is required that VPNs cannot abuse the MPLS label mechanisms or protocols to gain unauthorised access to other VPNs or the core.
VPNsが他のVPNsかコアへの権限のないアクセスを得るためにMPLSラベルメカニズムかプロトコルを誤用できないのが必要です。
3. Analysis of BGP/MPLS IP VPN Security
3. BGP/MPLS IP VPNセキュリティの分析
In this section, the BGP/MPLS IP VPN architecture is analysed with respect to the security requirements listed above.
このセクションでは、BGP/MPLS IP VPNアーキテクチャは上にリストアップされたセキュリティ要件に関して分析されます。
3.1. Address Space, Routing, and Traffic Separation
3.1. アドレス空間、ルート設定、およびトラフィック分離
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 VPNsに同じアドレス空間を使用させます、また、プライベート・アドレススペースであるかもしれないもの。(RFC1918[2])。 これは64ビットのRoute Distinguisher(RD)をそれぞれのIPv4ルートに追加することによって、達成されます、MPLSコアでVPNユニークなアドレスをまた、ユニークにして。 また、この「広げられた」アドレスは「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のために、別々のVirtualルート設定とForwardingインスタンス(VRF)を維持します。 VRFはCEルータがじっと見ているPEルータのアドレスと同様にそのVPNのアドレスを含んでいます。 これらのPEアドレスを含むVRFのすべてのアドレスが、VPNに論理的に属して、VPNより理解できます。 スタティックルーティングがPEとCEルータの間で使用されるなら、PEアドレスがVPNに理解できるという事実は問題ではありません、PEルータでVRFのすべてのアドレスへのアクセスを妨げるためにパケットフィルタを配布することができるので。 ダイナミックルーティングプロトコルが使用されているなら、CEルータは、コアの同輩PEルータのアドレスを構成させる必要があります。 サービスプロバイダーが管理する環境
Behringer Informational [Page 6] RFC 4381 Security of BGP/MPLS IP VPNs February 2006
BGP/MPLS IP VPNs2006年2月のBehringerの情報[6ページ]のRFC4381セキュリティ
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ルータであり、顧客にとって、これは目に見えない場合があります。 CE-PEリンク(PEが扱うじっと見ることを含んでいる)のアドレス空間はVPNアドレス空間の一部であると考えられます。 アドレス空間がVPNsの間に重なることができるので、CE-PEリンクアドレスはVPNsの間に重なることができます。 実用的な管理問題のために、コアの向こう側にユニークさを維持して、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.
また、VPNsの間のルート設定分離を達成できます。 ルートで各VRFは1VPNから静的に構成されたルートを通して、または、PEとCEルータの間を動くルーティング・プロトコルを通して居住されます。 それぞれのVPNが別々のVRFに関連しているので、PEルータのVPNsの間には、干渉が全くありません。
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.
横切って、ユニークなVPN識別子がmultiprotocol BGP(Route Distinguishers(RDs))にある状態で、もう片方のPEルータ分離へのコアは維持されます。 交換して、RDを含むVPNルートは排他的にMulti-プロトコルBGPによるPEルータの間のそうです。(MP-BGP(コアの向こう側のRFC2858[8]))。 コアに再配付するのではなく、これらのBGPルーティングアップデートを他のPEルータだけに再配付します、情報が再びVPN特有のVRFsに保たれるところで。 したがって、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.
データ飛行機の上では、トラフィック分離はプレ未定のa VPN-詳細がパケットとラベルするイングレスPEによって達成されます。 コアを通してVPNラベルがあるパケットを出口PEに送ります。そこでは、VPNラベルが、出口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コアネットワークの向こう側のアドレシング、ルーティング、およびトラフィック分離を考えて、このアーキテクチャがこの点で層-2VPNと同じセキュリティを提供すると思うことができます。 これが明らかに構成されていない場合、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 VPNsにおける標準のサービスではありません。 また、セクション5.2を見てください。
3.2. Hiding of the BGP/MPLS IP VPN Core Infrastructure
3.2. BGP/MPLS IP VPNコアインフラストラクチャの隠れること
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
通常、サービスプロバイダーと末端顧客は彼らのネットワーク形態を外部に明らかにして欲しくはありません。 これは、攻撃を実行するのをより難しくします: 攻撃者が犠牲者のアドレスを知らないなら、彼は、IPアドレスが攻撃されると推測できるだけです。 ほとんどのDoS攻撃がダイレクトフィードバックを攻撃者に提供しないので、ネットワークを攻撃するのは難しいでしょう。 それは明確に言及されなければなりません。
Behringer Informational [Page 7] RFC 4381 Security of BGP/MPLS IP VPNs February 2006
BGP/MPLS IP VPNs2006年2月のBehringerの情報[7ページ]のRFC4381セキュリティ
that information hiding as such does not provide security. However, in the market this is a perceived requirement.
そういうもののその情報隠蔽はセキュリティを提供しません。 しかしながら、市場では、これが知覚された要件です。
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.
安全保障上の理由で、どんなコアネットワークもコアインフラストラクチャに運命づけられた「外部」(インターネットか接続VPNs)からパケットをフィルターにかけるのは、お勧めです。 これで、ノッキングコアルータなどの何らかの機能性が失われますが、コアを攻撃するのは非常に困難になります。 それでも、コアの外で目的地を扱うので、コアの向こう側のトレースルートは働くでしょう。
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は顧客VPNsさえではなく、外部に不要な情報を明らかにしません。 プライベート・アドレスでコアのアドレシングができます。(RFC1918[2])か場内放送。 インターネットと同様にVPNsへのインタフェースが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.
顧客VPNsは、それらのVPNの向こう側に可到達性を確実にするためにBGP/MPLS IP VPNコア(ダイナミックか静的である)に彼らのルートの広告を出さなければなりません。 いくつかの場合、VPNユーザは、サービスプロバイダーにはVPNのアドレシングプランの目に見えることが全くないのを好みます。 以下は注意されなければなりません: まず最初に、ネットワーク(ルート)に関してコアに知られている情報が特定のホストに関してあるのではなく、あります。 これは抽象化の度合いを提供します。 2番目に、VPNだけBGP/MPLS IP VPNネットワーク(インターネット・アクセスがない)において、これは既存の層-2つのモデルと等しいです。そこでは、顧客がサービスプロバイダーを信じなければなりません。 また、Frame RelayかATMネットワークでは、コアネットワークでVPNsに関するルーティングとアドレス指定情報を見ることができます。
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
共有されたインターネット・アクセスとのVPNサービスでは、サービスプロバイダーは彼の上流か同輩プロバイダーにインターネットを使用したがっている顧客のルートを通常発表するでしょう。 顧客のネットワークに関するアドレス指定情報をあいまいにするために、VPN顧客が場内放送スペースを使用するなら直接するか、Network Address Translation(NAT)を通してこれはあることができます。 どちらの場合ではも、顧客は一般的なインターネットのサービスによって明らかにされるだろうより多くの情報を明らかにしません。 コア情報は明らかにされないでしょう。
Behringer Informational [Page 8] RFC 4381 Security of BGP/MPLS IP VPNs February 2006
BGP/MPLS IP VPNs2006年2月のBehringerの情報[8ページ]のRFC4381セキュリティ
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.
(s) インターネットとのじっと見ることを保持する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ルータの)を次のプロバイダーと、そして、その結果、外の世界に明らかにしなければなりません。
3.3. Resistance to Attacks
3.3. 攻撃への抵抗
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は、直接他のVPNsに押し入るのが不可能であることを示します。 別の可能性は、MPLSコアを攻撃して、そこから他のVPNsを攻撃しようとすることです。 上に示されるように、直接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アドレスを推測さえすることによって内部のルータに達するのは不可能です。 この規則への1つの例外しかありません。(規則はPEルータの同輩インタフェースです)。 PEのこのアドレスは唯一の攻撃ポイントに外部(VPNかインターネット)から来ています。
Behringer Informational [Page 9] RFC 4381 Security of BGP/MPLS IP VPNs February 2006
BGP/MPLS IP VPNs2006年2月のBehringerの情報[9ページ]のRFC4381セキュリティ
The routing between a VPN and the BGP/MPLS IP VPN core can be configured two ways:
2つの方法でVPNとBGP/MPLS IP VPNコアの間のルーティングを構成できます:
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. 動力: ルーティング・プロトコル(例えば、ルーティング情報プロトコル(リップ)、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アドレス)を知るのが必要であり、その結果、攻撃のための潜在的目的地を持っています。 人はルータで動く様々なサービスに対する様々な攻撃を想像できました。 実際には、アクセスコントロールリスト(ACLs)を使用することによって、CE-PEインタフェースの上のPEルータへのアクセスを必要なルーティング・プロトコルに制限できます。 これは攻撃のポイントを例えば、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はルーティング・プロトコルのためのMD5認証を構成する. o ByをCEからPEまでのルーティング・プロトコルパケットだけに許容するはずです。 これがBGPに利用可能である、(RFC2385[6])、OSPF、(RFC2154[4])、およびRIP2、(例えば、RFC2082[3])。 これはCEルータ以外の顧客ネットワークの部分から偽造されるパケットを避けます。 すべてのCEとPEルータの間の共有秘密キーに同意するのがサービスプロバイダーと顧客を必要とします。 すべてのVPN顧客のためにこれをするのが必要です。 顧客のためだけに最も高いセキュリティ要件でこれをするのは十分ではありません。
Behringer Informational [Page 10] RFC 4381 Security of BGP/MPLS IP VPNs February 2006
BGP/MPLS IP VPNs2006年2月のBehringerの情報[10ページ]のRFC4381セキュリティ
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とルーティング隣人単位で受け入れられた最大数のルートは可能であるところで構成されるべきです。 Generalized TTL Security Mechanism、(GTSM; プロトコルであるとサポートされる限り、RFC3682[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.
概要では、1VPNから他のVPNs、またはコアに侵入するのは可能ではありません。 しかしながら、PEルータに対してDoS攻撃を実行するためにルーティング・プロトコルポートを攻撃するのは理論的に可能です。 これはこのPEルータで他のVPNsで順番にマイナスの影響があるかもしれません。 この理由で、特にそれらのインタフェースでCEルータにPEルータを非常によく保証しなければなりません。 ルーティング・プロトコルのポートだけと、CEルータだけからアクセスを制限するためにACLsを構成しなければなりません。 MD5認証や、最大の接頭語限界や、Live(TTL)セキュリティー対策へのTimeなどのさらなるルーティング・プロトコルのセキュリティー対策はすべてのPE-CE peeringsで使用されるべきです。 これらのすべての安全策で、唯一の可能な攻撃はルーティング・プロトコル自体に対するDoS攻撃です。 BGPは、安定性を助けるためにプロトコルを接頭語フィルタリングや湿気などの多くの対策に組み込ませます。 また、そのような潜在的DoS攻撃の源を追跡するのも簡単です。 CEsとPEsの間のダイナミックルーティングがなければ、セキュリティはATMかFrame Relayネットワークのセキュリティに同等です。
3.4. Label Spoofing
3.4. ラベルスプーフィング
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パケットのラベルを偽造するのも理論的に可能です。 最初のセクションでは、コアネットワークが信じられるという仮定はされました。 この仮定をすることができないなら、MPLS雲の上にIPsecを実行しなければなりません。 したがって、このセクションに、偽造しているラベルで外部か、すなわち、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デバイスでして、パケットにあらかじめpendedします。(構成に基づいて、そこでは、ラベルが選ばれています)。 これは上流のサービスプロバイダーと同様にCEルータに向かったすべてのPEルータのためのそうです。 MPLS雲の中へのすべてのインタフェースがラベルなしでIPパケットを必要とするだけです。
Behringer Informational [Page 11] RFC 4381 Security of BGP/MPLS IP VPNs February 2006
BGP/MPLS IP VPNs2006年2月のBehringerの情報[11ページ]のRFC4381セキュリティ
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ルータからパケットを決して受け入れるべきではありません。 RFC3031[9]は指定します: 「したがって、無効の入って来るラベルでラベルされたパケットを受け取るときそれを捨てなければならなくて、それがいくつか決定しているUNLESSがそれを進めながらそれを意味する、(現在のドキュメントのいずれの範囲の中でもそうしません)ラベルされていなさ、少しの害も引き起こさない場合がある、」 以来CEインタフェースでラベルを受け入れるのに、潜在的にそれがRFCによって可能にされない他のVPNsにパケットを通過するでしょう。
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とCarrierのCarrierケースは特別なケースです、プロバイダーの間のインタフェースとラベルがあるパケットを通常交換するので。 これらのアーキテクチャの分析に関してセクション4を見てください。
3.5. Comparison with ATM/FR VPNs
3.5. 気圧/FR VPNsとの比較
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 VPNsを提供できますが、これらの技術もセキュリティの脆弱性[14]を持つことができると報告しました。 ATM/FRでは、セキュリティをいかなる他のネットワーク・テクノロジーのようにも安全なネットワークの構成に依存します、そして、また、誤りは警備上の問題につながることができます。
4. Security of Advanced BGP/MPLS IP VPN Architectures
4. 高度なBGP/MPLS IP VPNアーキテクチャのセキュリティ
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.
RFC2547[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.
RFC4364[1]は次に、よりオープンなインタフェースで、より複雑なアーキテクチャを定義しました。 これらのインタフェースはデバイスとサービスプロバイダーのコントロールの外におけるデバイスからラベル情報とラベルされたパケットの交換を許容します。 このセクションはこの高度なアーキテクチャのセキュリティ含意について論じます。
Behringer Informational [Page 12] RFC 4381 Security of BGP/MPLS IP VPNs February 2006
BGP/MPLS IP VPNs2006年2月のBehringerの情報[12ページ]のRFC4381セキュリティ
4.1. Carriers' Carrier
4.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.
CarriersのCarrier(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.
RFC4364[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].
標準のRFC2547[7]ネットワークトップラベルの下のパケットはそうするでしょう--顧客キャリヤーのVPNに地方のままで残ってください、そして、キャリアズキャリアコアで点検されないでください。 その後のラベルかIPアドレスの潜在的スプーフィングはキャリヤーのVPNに地方のままで残っています。 それはそのコアにキャリアズキャリアコアの上と、そして、他のVPNsの上に意味を全く持っていません。 これはRFC4364[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に押し入るのを可能にするかもしれません)。 したがって、RFC4364[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のネットワークを供給するか、または2547の[7]ネットワークを伝統的なRFCに供給します。
Behringer Informational [Page 13] RFC 4381 Security of BGP/MPLS IP VPNs February 2006
BGP/MPLS IP VPNs2006年2月のBehringerの情報[13ページ]のRFC4381セキュリティ
4.2. Inter-Provider Backbones
4.2. 相互プロバイダーバックボーン
RFC 4364 [1] specifies three sub-cases for the inter-provider backbone (Inter-AS) case.
RFC4364[1]は相互プロバイダーバックボーン(相互AS)ケースに3つのサブケースを指定します。
a) VRF-to-VRF connections at the autonomous system border routers (ASBRs).
a) VRFからVRFとの自律システムでの接続はルータ(ASBRs)に接しています。
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として扱います。 それぞれがラベルされたパケットを受け入れないでしょう、そして、両側のVRFs以外のPEsの間で合図してはいけません。 したがって、両側におけるVPNsの分離とそれらのセキュリティは2547年のただ一つのAS RFC[7]ネットワークと同じです。 これは、伝統的な層2のVPNsと同じセキュリティの特性を持つために既に示されました。
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.
このソリューションには、ASBRsが、1VPNあたり1VRFを維持する必要があるので、潜在的スケーラビリティ問題があります、そして、VRFsのすべてが特定のVPNsのすべてのルートを保持する必要があります。 したがって、ASBRは1独身のVRFがあまりに多くのルートを含んでいるならすべてのVPNsに影響することにおける記憶障害を出くわすことができます。 したがって、ASBRsが適切にdimensionedされるのを確実にして、申し込むサービスプロバイダーの必要性は1VRFあたりの接頭語の数を制限などなどの安全策を当てます。
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.
このようにそれらのVPNsを接続する2つのサービスプロバイダーが互いを信じなければなりません。 以来VPNsが異なるところで切り離される、(サブ、)、インタフェースであり、ASBRsの間のすべてのシグナリングが与えられたVPNに残っています。 これは、ダイナミックな十字-VPN機密保護違反が不可能であることを意味します。 サービスプロバイダーが特定のVPNを間違ったインタフェースに接続するのが想像できます、その結果、接続されるべきでない2VPNsとインタコネクトします。 これを操作上制御しなければなりません。
b) EBGP redistribution of labeled VPN-IPv4 routes from AS to neighboring AS.
b) ラベルされたVPN-IPv4ルートのASによる隣接する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.
この場合、両側のASBRsは両側のすべての共有されたVPNsに、完全なルーティング情報を保持します。 これは別々のVRFsに保持されるのではなく、BGPデータベースに保持されます。 (これはフィルタリングを通してInter-AS VPNsに通常制限されます。) PEの中の分離はVPN-IPv4アドレスの使用で維持されます。 ASBRsの間の制御飛行機はMulti-プロトコルBGPを使用します。(MP-BGP、RFC2858[8])。 それは、データ飛行機で使用されるためにVPN-IPv4アドレス、BGP次のホップIPv4アドレスとしてのASBRアドレス、およびラベルとして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
VRFかそれの部分集合を表して、データ飛行機は単一のラベルの使用で切り離されます。 RFC4364[1]は、ASBRがそれがこのルータに割り当てたラベルでパケットを受け入れるだけであるはずであると述べます。 これは未知のラベルによるパケットの挿入を防ぎますが、サービスプロバイダーがどんなラベルも使用するのは、可能です。
Behringer Informational [Page 14] RFC 4381 Security of BGP/MPLS IP VPNs February 2006
BGP/MPLS IP VPNs2006年2月のBehringerの情報[14ページ]のRFC4381セキュリティ
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.
もう片方のプロバイダーの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.
RFC4364[1]は、このモデルがしっかりと働くように2接続ASesの間の信頼関係が存在しなければならないと述べます。 事実上、このようにインタコネクトされたすべてのASesが信頼のただ一つのゾーンを形成します。 VPN顧客は、このアーキテクチャの彼のVPNの食糧を供給するのにかかわるすべてのサービスプロバイダーを信じる必要があります。
c) PEs exchange labeled VPN-IPv4 routes, ASBRs only exchange loopbacks of PEs with labels.
c) PEs交換はラベルでPEsの交換ループバックだけとVPN-IPv4ルート、ASBRsをラベルしました。
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.
このソリューションには、ASesの間には、2つのコントロール接続が有効にあります。 ルート反射鏡(RRs)はマルチホップeBGPを通してVPN-IPv4ルートを交換します。 ASBRsはそれらのASesの間で共有されるVPNルートを保持するそれらのPEルータのラベルされたアドレスを交換するだけです。 彼らがVPN-IPv4ルートを知る必要はないので、これはASBRsのためにスケーラビリティを維持します。
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が異なった出口PEsの間、または、それらのPEsの上の異なったVPNsの間で区別するのは、不可能です。 1ASの悪意があるサービスプロバイダーは他のASのPEの上のどんなVPNにもパケットを紹介できました。 それはそのASBRとPEsの上の有効なLSPを他のASの上の対応するPEに必要とするだけです。 理論上のラベルスペースから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
さらに、交換がVPN-IPv4とラベルしたこのソリューションはMP-eBGPを通してルート反射鏡の間で(RRs)を扱います。 ルーティング認証で制御飛行機自体を保護できます。(RFC2385[6])(ルーティング情報が予想されたRRによって溯源されて、トランジットで変更されていないのを確実にするもの)。 容認されたVPN
Behringer Informational [Page 15] RFC 4381 Security of BGP/MPLS IP VPNs February 2006
BGP/MPLS IP VPNs2006年2月のBehringerの情報[15ページ]のRFC4381セキュリティ
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.
先の事件のように情報について確かめることができません。 したがって、サービスプロバイダーはどんな共有されたVPNのためにもにせのルートを導入できます。 ASesは、互いが正しく彼らのそれぞれのネットワークを構成すると信じる必要があります。 すべてのASesが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がiBGPとしてそれらのASのために次のホップであるのに機能するということです。 したがって、各SPは、SPのものがASBRsのアドレスだけの芯を取るのをもう片方を知る必要があります。 場合c)では、SPsはそれらの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 peeringsがこのようにリンクされたすべてのASesを含む総合的なネットワークのために作られていなければなりません。 両側の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.
概要では、これらのInter-ASソリューションのすべてがいくつかのプロバイダーネットワークを論理的に合併します。 Inter-AS構成に関するすべてのケースのために、すべてのASesが信頼のただ一つのゾーンを形成します、そして、サービスプロバイダーは互いを信じる必要があります。 VPN顧客にとって、総合的なソリューションのセキュリティは伝統的なRFC2547[7]ネットワークのセキュリティと等しいのですが、顧客は、このInter-ASソリューションの食糧を供給するのにかかわるすべてのサービスプロバイダーを信じる必要があります。
5. What BGP/MPLS IP VPNs Do Not Provide
5. BGP/MPLS IP VPNsがすることは提供されません。
5.1. Protection against Misconfigurations of the Core and Attacks
'within' the Core
5.1. コアと攻撃'within'コアのMisconfigurationsに対する保護
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ルータ)のネットワーク原理の正しい構成を仮定します。 慎重であるか不注意なmisconfigurationは激しい安全保障機密の漏洩をもたらすかもしれません。
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
このパラグラフが明確にコアネットワーク、すなわち、PEとP要素を示すことに注意してください。 CEルータなどの顧客サイド要素のどれかのMisconfigurationsは上のセキュリティー対策でカバーされています。 これは、潜在的攻撃者がmisconfigurationsから利点を獲得するためにPEかPルータのどちらかに近づく手段を持たなければならないことを意味します。 攻撃者が炉心構成要素に近づく手段を持っているか、またはいるなら
Behringer Informational [Page 16] RFC 4381 Security of BGP/MPLS IP VPNs February 2006
BGP/MPLS IP VPNs2006年2月のBehringerの情報[16ページ]のRFC4381セキュリティ
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:
コア追加装備に挿入できます、彼はコアネットワークと接続VPNsの両方を攻撃できるでしょう。 したがって、以下は重要です:
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 misconfigurationsの危険を避けるために、設備は構成しやすいのが重要であり、ネットワークを構成するとき、そのSPスタッフは適切なトレーニングと経験を持っています。 コアネットワークを構成するために適切なツールを必要とします。o Toは「内部」の攻撃の危険を最小とならせて、適切にコアネットワークを保証しなければなりません。 これはネットワーク要素セキュリティ、管理セキュリティ、サービスプロバイダーインフラストラクチャの物理的なセキュリティ、サービスプロバイダー施設へのアクセスコントロール、および他の標準の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は彼らのひとりです。 [13]がmisconfigurationsを検出するのが目的とされたトークンを使用するCEベースの認証体系を提案する「層3のVPNsのためのCeからCeへのメンバー検証」というMPLSが芯を取るドキュメント。 MD5ルーティング認証を使用することに基づいてドキュメント「MPLS VPN Import/Export Verification」[12]は同様の体系を提案します。 両方の体系は、コアでmisconfigurationsを検出して、防ぐことを目指します。
5.2. Data Encryption, Integrity, and Origin Authentication
5.2. データ暗号化、保全、および発生源認証
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 VPNs自身は暗号化、保全、または認証サービスを提供しません。 これらが必要であるなら、IPsecはMPLSインフラストラクチャの上で使用されるべきです。 同じくらいはATMとFrame Relayに適用されます: IPsecはこれらのなくなったサービスを提供できます。
5.3. Customer Network Security
5.3. 顧客ネットワークセキュリティ
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 VPNsを固定できるので、彼らは他のVPNサービスに匹敵しています。 しかしながら、コアネットワークのセキュリティは顧客のネットワークの総合的なセキュリティのための1つの要素にすぎません。 今日のネットワークにおける脅威は単に「外」の接続から来るのではなく、“inside"と他のエントリー・ポイント(例えば、モデム)から来もします。 BGP/MPLSインフラストラクチャで顧客ネットワークのための優れた警備体制レベルに達するように、MPLSセキュリティは、必要ですが、十分ではありません。 同じくらいはATMやFrame Relayのような他のVPN技術に適用されます。 また、どうネットワークを保証するかに関する詳しい情報のためのRFC2196[5]を見てください。
Behringer Informational [Page 17] RFC 4381 Security of BGP/MPLS IP VPNs February 2006
BGP/MPLS IP VPNs2006年2月のBehringerの情報[17ページ]のRFC4381セキュリティ
6. Layer 2 Security Considerations
6. 層2のセキュリティ問題
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.
多くの場合、Inter-ASかCarrierのCarrierソリューションでは、ネットワークは他のネットワークと二地点間個人的な接続でインタコネクトされるでしょう。 第三者はこの接続を妨げることができません。 どんな共有された媒体層の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環境におけるリスクは多くの異なった形式のAddress Resolutionプロトコル(ARP)攻撃、VLAN中継方式攻撃、またはContent Addressable Memory(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ネットワークのあるVPNsに関連するかもしれないラベルされたパケットを導入するのが可能になるでしょう、事実上、偽のパケットをVPNに紹介して。
Behringer Informational [Page 18] RFC 4381 Security of BGP/MPLS IP VPNs February 2006
BGP/MPLS IP VPNs2006年2月のBehringerの情報[18ページ]のRFC4381セキュリティ
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のネットワークをパケットとラベルされた破棄には現在の推薦があります。 交換されるべきパケットの必要性とラベルされるところでは、個人的な接続を使用することが強く勧められます。
7. Summary and Conclusions
7. 概要と結論
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 VPNsは層-2つの伝統的なVPNサービスのように完全なアドレスとトラフィック分離を提供します。 それはコアと他のVPNsの構造を扱いながら、隠れます、そして、BGP/MPLSメカニズムを誤用する他のVPNsに押し入るのは可能ではありません。また、これが適切に機密保護されるなら、MPLSコアに押し入るのも不可能です。 しかしながら、例えば、BGP/MPLSベースのIP VPNsと、FRかATMベースのVPNsの間には、著しい違いがあります: コアの制御構造はMPLSの場合で層3です。 これは産業でMPLSに向かって重要な懐疑を引き起こしました、これが他のVPNsかインターネットから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].
本書では示されるように、匹敵するATMかFRサービスへの同じレベルのセキュリティにBGP/MPLS IP VPNインフラストラクチャを保証するのは可能です。 また、安全な方法でインターネットの接続性をMPLS VPNsに提供して、ファイアウォールで異なったVPNsとインタコネクトするのも可能です。 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)には、同じ問題があります: 攻撃者がパケット盗聴プログラムをインストールできるなら、彼はすべてのVPNsの情報を読むことができます、そして、攻撃者がコアデバイスに近づく手段を持っているなら、多くの攻撃を実行できます、パケットスプーフィングから新しい同輩ルータを導入するまで。 上に概説されたサービスプロバイダーがコアのセキュリティをきびしくするのに使用できる多くの予防策がありますが、BGP/MPLS IP VPNアーキテクチャのセキュリティはサービスプロバイダーのセキュリティによります。 サービスプロバイダーが信じられないなら、攻撃に対してVPNサービスの“inside"から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ネットワークはまだ多くの攻撃に開かれています。
Behringer Informational [Page 19] RFC 4381 Security of BGP/MPLS IP VPNs February 2006
BGP/MPLS IP VPNs2006年2月のBehringerの情報[19ページ]のRFC4381セキュリティ
8. Security Considerations
8. セキュリティ問題
The entire document is discussing security considerations of the RFC 4364 [1] architecture.
全体のドキュメントはRFC4364[1]アーキテクチャのセキュリティ問題について議論しています。
9. Acknowledgements
9. 承認
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.
作者はこのドキュメントに入力を供給したみんなに感謝したがっています。 特定の感謝は彼の継続的な強力な支持のためのヤコフRekhter、エリック・ローゼン、Loaアンデション、アレクサンダー・ラナー、ジム・ギシャール、モニーク・モロー、エリックVyncke、およびスティーブSimloに行きます、彼らの拡張フィードバックとサポートのために。
10. Normative References
10. 引用規格
[1] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks
(VPNs)", RFC 4364, February 2006.
[1] ローゼンとE.とY.Rekhter、「BGP/MPLS IP仮想私設網(VPNs)」、RFC4364 2006年2月。
11. Informative References
11. 有益な参照
[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.リア、「個人的なインターネットのためのアドレス配分」BCP5、RFC1918(1996年2月)。
[3] Baker, F., Atkinson, R., and G. Malkin, "RIP-2 MD5
Authentication", RFC 2082, January 1997.
[3] ベイカー、F.、アトキンソン、R.、およびG.マルキン、「裂け目-2MD5認証」、RFC2082、1997年1月。
[4] Murphy, S., Badger, M., and B. Wellington, "OSPF with Digital
Signatures", RFC 2154, June 1997.
1997年6月の[4] マーフィーとS.とムジナ、M.とB.ウェリントン、「デジタル署名があるOSPF」RFC2154。
[5] Fraser, B., "Site Security Handbook", RFC 2196, September 1997.
[5] フレーザ、B.、「サイトセキュリティハンドブック」、RFC2196、1997年9月。
[6] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
[6] ヘファーナン、A.、「TCP MD5 Signature Optionを通したBGPセッションズの保護」、RFC2385、1998年8月。
[7] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547,
March 1999.
[7] ローゼンとE.と1999年のY.Rekhter、「BGP/MPLS VPNs」、RFC2547行進。
[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.キャッツ、「BGP-4インチのためのMultiprotocol拡張子、RFC2858、2000年6月。」
[9] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label
Switching Architecture", RFC 3031, January 2001.
[9] ローゼンとE.とViswanathan、A.とR.Callon、「Multiprotocolラベル切り換えアーキテクチャ」、RFC3031、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)」、RFC3682 2004年2月。
Behringer Informational [Page 20] RFC 4381 Security of BGP/MPLS IP VPNs February 2006
BGP/MPLS IP VPNs2006年2月のBehringerの情報[20ページ]のRFC4381セキュリティ
[11] Fang, L., "Security Framework for Provider-Provisioned Virtual
Private Networks (PPVPNs)", RFC 4111, July 2005.
[11] 牙、L.、「プロバイダーで食糧を供給された仮想私設網(PPVPNs)のためのセキュリティフレームワーク」、RFC4111、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 Import/Export Verification」というBehringerは進歩、2004年6月に働いています。
[13] Bonica, R. and Y. Rekhter, "CE-to-CE Member Verification for
Layer 3 VPNs", Work in Progress, September 2003.
[13] 「層3のVPNsのためのCeからCeへのメンバー検証」というBonica、R.、およびY.Rekhterは進歩、2003年9月に働いています。
[14] DataComm, "Data Communications Report, Vol 15, No 4: Frame
Relay and ATM: Are they really secure?", February 2000.
[14] データコム、「データ通信レポート、Vol15、いいえ4:」 フレームリレーと気圧: 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シスコシステムズInc村のd'Entreprisesグリーン側400、Avenueルーマニーユ、Batiment T3Biot--ソフィアAntipolis06410フランス
EMail: mbehring@cisco.com URI: http://www.cisco.com
メール: mbehring@cisco.com ユリ: http://www.cisco.com
Behringer Informational [Page 21] RFC 4381 Security of BGP/MPLS IP VPNs February 2006
BGP/MPLS IP VPNs2006年2月のBehringerの情報[21ページ]のRFC4381セキュリティ
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78と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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Behringer Informational [Page 22]
Behringer情報です。[22ページ]
一覧
スポンサーリンク
