RFC4111 日本語訳
4111 Security Framework for Provider-Provisioned Virtual PrivateNetworks (PPVPNs). L. Fang, Ed.. July 2005. (Format: TXT=106626 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group L. Fang, Ed. Request for Comments: 4111 AT&T Labs. Category: Informational July 2005
エド、ワーキンググループL.牙をネットワークでつないでください。コメントのために以下を要求してください。 4111のAT&T研究室。 カテゴリ: 情報の2005年7月
Security Framework for
Provider-Provisioned Virtual Private Networks (PPVPNs)
プロバイダーで食糧を供給された仮想私設網のためのセキュリティフレームワーク(PPVPNs)
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 (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This document addresses security aspects pertaining to Provider- Provisioned Virtual Private Networks (PPVPNs). First, it describes the security threats in the context of PPVPNs and defensive techniques to combat those threats. It considers security issues deriving both from malicious behavior of anyone and from negligent or incorrect behavior of the providers. It also describes how these security attacks should be detected and reported. It then discusses possible user requirements for security of a PPVPN service. These user requirements translate into corresponding provider requirements. In addition, the provider may have additional requirements to make its network infrastructure secure to a level that can meet the PPVPN customer's expectations. Finally, this document defines a template that may be used to describe and analyze the security characteristics of a specific PPVPN technology.
このドキュメントは、セキュリティがProviderの食糧を供給されたVirtual兵士のNetworks(PPVPNs)に関係する局面であると扱います。 まず最初に、それはそれらの脅威と戦うPPVPNsと防衛的なテクニックの文脈における軍事的脅威について説明します。 それはだれの悪意のある態度と、そして、プロバイダーの怠慢であるか不正確な振舞いから両方を引き出す安全保障問題を考えます。 また、それはこれらのセキュリティー攻撃がどう検出されて、報告されるべきであるかを説明します。 そして、それはPPVPNサービスのセキュリティのために可能なユーザ要件について議論します。 これらのユーザ要件は対応するプロバイダー要件に翻訳されます。 さらに、プロバイダーには、ネットワークインフラをPPVPN顧客の期待に合うことができるレベルに安全にするという追加要件があるかもしれません。 最終的に、このドキュメントは特定のPPVPN技術のセキュリティの特性を説明して、分析するのに使用されるかもしれないテンプレートを定義します。
Table of Contents
目次
1. Introduction ................................................. 2
2. Terminology .................................................. 4
3. Security Reference Model ..................................... 4
4. Security Threats ............................................. 6
4.1. Attacks on the Data Plane .............................. 7
4.2. Attacks on the Control Plane ........................... 9
5. Defensive Techniques for PPVPN Service Providers ............. 11
5.1. Cryptographic Techniques ............................... 12
5.2. Authentication ......................................... 20
5.3. Access Control Techniques .............................. 22
5.4. Use of Isolated Infrastructure ......................... 27
1. 序論… 2 2. 用語… 4 3. セキュリティ規範モデル… 4 4. セキュリティの脅威… 6 4.1. データ飛行機に対する攻撃… 7 4.2. 制御飛行機に対する攻撃… 9 5. PPVPNサービスプロバイダーのための防衛的なテクニック… 11 5.1. 暗号のテクニック… 12 5.2. 認証… 20 5.3. 制御方法にアクセスしてください… 22 5.4. 孤立しているインフラストラクチャの使用… 27
Fang Informational [Page 1] RFC 4111 PPVPN Security Framework July 2005
[1ページ]RFC4111PPVPNセキュリティフレームワーク2005年7月の情報の牙
5.5. Use of Aggregated Infrastructure ....................... 27
5.6. Service Provider Quality Control Processes ............. 28
5.7. Deployment of Testable PPVPN Service ................... 28
6. Monitoring, Detection, and Reporting of Security Attacks ..... 28
7. User Security Requirements ................................... 29
7.1. Isolation .............................................. 30
7.2. Protection ............................................. 30
7.3. Confidentiality ........................................ 31
7.4. CE Authentication ...................................... 31
7.5. Integrity .............................................. 31
7.6. Anti-replay ............................................ 32
8. Provider Security Requirements ............................... 32
8.1. Protection within the Core Network ..................... 32
8.2. Protection on the User Access Link ..................... 34
8.3. General Requirements for PPVPN Providers ............... 36
9. Security Evaluation of PPVPN Technologies .................... 37
9.1. Evaluating the Template ................................ 37
9.2. Template ............................................... 37
10. Security Considerations ...................................... 40
11. Contributors ................................................. 41
12. Acknowledgement .............................................. 42
13. Normative References ......................................... 42
14. Informative References ....................................... 43
5.5. 集められたインフラストラクチャの使用… 27 5.6. サービスプロバイダー品質管理は処理されます… 28 5.7. 試験できるPPVPNサービスの展開… 28 6. セキュリティのモニター、検出、および報告は攻撃されます… 28 7. ユーザセキュリティ要件… 29 7.1. 分離… 30 7.2. 保護… 30 7.3. 秘密性… 31 7.4. Ce認証… 31 7.5. 保全… 31 7.6. 反再生… 32 8. プロバイダーセキュリティ要件… 32 8.1. コアネットワークの中の保護… 32 8.2. ユーザアクセスリンクにおける保護… 34 8.3. PPVPNプロバイダーのための一般要件… 36 9. PPVPN技術の機密保護評価… 37 9.1. テンプレートを評価します… 37 9.2. テンプレート… 37 10. セキュリティ問題… 40 11. 貢献者… 41 12. 承認… 42 13. 標準の参照… 42 14. 有益な参照… 43
1. Introduction
1. 序論
Security is an integral aspect of Provider-Provisioned Virtual Private Network (PPVPN) services. The motivation and rationale for both Provider-Provisioned Layer-2 VPN and Provider-Provisioned Layer-3 VPN services are provided by [RFC4110] and [RFC4031]. These documents acknowledge that security is an important and integral aspect of PPVPN services, for both VPN customers and VPN service providers. Both will benefit from a PPVPN Security Framework document that lists the customer and provider security requirements related to PPVPN services, and that can be used to assess how much a particular technology protects against security threats and fulfills the security requirements.
セキュリティはProviderによって食糧を供給されたVirtual兵士のNetwork(PPVPN)サービスの不可欠の局面です。 Providerによって食糧を供給されたLayer-2 VPNとProviderによって食糧を供給されたLayer-3 VPNサービスの両方のための動機と原理は[RFC4110]と[RFC4031]によって提供されます。 これらのドキュメントは、セキュリティが重要で不可欠のPPVPNサービスの局面であると認めます、VPN顧客とVPNサービスプロバイダーの両方のために。 両方がPPVPNサービスに関連する顧客とプロバイダーセキュリティ要件をリストアップして、どのくらい評価するかに使用されて、特定の技術が軍事的脅威から守って、セキュリティ要件を実現させるということであるかもしれないPPVPN Security Frameworkドキュメントの利益を得るでしょう。
First, we describe the security threats that are relevant in the context of PPVPNs, and the defensive techniques that can be used to combat those threats. We consider security issues deriving both from malicious or incorrect behavior of users and other parties and from negligent or incorrect behavior of the providers. An important part of security defense is the detection and report of a security attack,
まず最初に、私たちはPPVPNsの文脈で関連している軍事的脅威、およびそれらの脅威と戦うのに使用できる防衛的なテクニックについて説明します。 私たちはユーザと相手の悪意があるか不正確な振舞いと、そして、プロバイダーの怠慢であるか不正確な振舞いから両方を引き出す安全保障問題を考えます。 セキュリティディフェンスの重要な部分は、セキュリティー攻撃の検出とレポートです。
Fang Informational [Page 2] RFC 4111 PPVPN Security Framework July 2005
[2ページ]RFC4111PPVPNセキュリティフレームワーク2005年7月の情報の牙
which is also addressed in this document. Special considerations engendered by IP mobility within PPVPNs are not in the scope of this document.
また、本書では扱われます。 PPVPNsの中でIPの移動性によって生み出された特別な問題がこのドキュメントの範囲にありません。
Then, we discuss the possible user and provider security requirements for a PPVPN service. Users expectations must be met for the security characteristics of a VPN service. These user requirements translate into corresponding requirements for the providers offering the service. Furthermore, providers have security requirements to protect their network infrastructure, securing it to the level required to provide the PPVPN services in addition to other services.
そして、私たちはPPVPNサービスのための可能なユーザとプロバイダーセキュリティ要件について議論します。 VPNサービスのセキュリティの特性のためにユーザ期待を迎えなければなりません。 これらのユーザ要件はサービスを提供するプロバイダーのための対応する要件に翻訳されます。 その上、プロバイダーには、それらのネットワークインフラを保護するというセキュリティ要件があります、他のサービスに加えたPPVPNサービスを提供するのに必要であるレベルにそれを機密保護して。
Finally, we define a template that may be used to describe the security characteristics of a specific PPVPN technology in a manner consistent with the security framework described in this document. It is not within the scope of this document to analyze the security properties of specific technologies. Instead, our intention is to provide a common tool, in the form of a checklist, that may be used in other documents dedicated to an in-depth security analysis of individual PPVPN technologies to describe their security characteristics in a comprehensive and coherent way, thereby providing a common ground for comparison between different technologies.
最終的に、私たちは本書では説明されるセキュリティフレームワークと一致した方法における、特定のPPVPN技術のセキュリティの特性について説明するのに使用されるかもしれないテンプレートを定義します。 独自技術のセキュリティの特性を分析するために、このドキュメントの範囲の中にそれはありません。 代わりに、私たちの意志は一般的なツールを提供することです、チェックリストの形で、異なった技術での比較のためのそんなに包括的で論理的な方法でそれらのセキュリティの特性について説明する独特のPPVPN技術の徹底的な証券分析に捧げられた他のドキュメントで使用されるかもしれない、その結果、提供している共通基盤。
It is important to clarify that this document is limited to describing users' and providers' security requirements that pertain to PPVPN services. It is not the intention to formulate precise "requirements" on each specific technology by defining the mechanisms and techniques that must be implemented to satisfy such users' and providers' requirements.
はっきりさせるために、このドキュメントがPPVPNサービスに関係するユーザとプロバイダーのセキュリティ要件について説明するのに制限されるのは、重要です。 ユーザとプロバイダーのそのような要件を満たすために実装しなければならないのは、メカニズムとテクニックを定義することによって各独自技術に関する正確な「要件」を定式化するという意志ではありません。
This document is organized as follows. Section 2 defines the terminology used in the document. Section 3 defines the security reference model for security in PPVPN networks. Section 4 describes the security threats that are specific of PPVPNs. Section 5 reviews defense techniques that may be used against those threats. Section 6 describes how attacks may be detected and reported. Section 7 discusses the user security requirements that apply to PPVPN services. Section 8 describes additional security requirements on the provider to guarantee the security of the network infrastructure providing PPVPN services. In Section 9, we provide a template that may be used to describe the security characteristics of specific PPVPN technologies. Finally, Section 10 discusses security considerations.
このドキュメントは以下の通りまとめられます。 セクション2はドキュメントで使用される用語を定義します。 セクション3はセキュリティのためにPPVPNネットワークでセキュリティ規範モデルを定義します。 セクション4はPPVPNsで特定の軍事的脅威について説明します。 セクション5はそれらの脅威に対して使用されるかもしれないディフェンスのテクニックを見直します。 セクション6は攻撃がどう検出されて、報告されるかもしれないかを説明します。 セクション7はPPVPNサービスに適用されるユーザセキュリティ要件について論じます。 セクション8はサービスをPPVPNに供給するネットワークインフラのセキュリティを保証するというプロバイダーに関する追加担保要件について説明します。 セクション9に、私たちは特定のPPVPN技術のセキュリティの特性について説明するのに使用されるかもしれないテンプレートを提供します。 最終的に、セクション10はセキュリティ問題について議論します。
Fang Informational [Page 3] RFC 4111 PPVPN Security Framework July 2005
[3ページ]RFC4111PPVPNセキュリティフレームワーク2005年7月の情報の牙
2. Terminology
2. 用語
This document uses PPVPN-specific terminology. Definitions and details specific to PPVPN terminology can be found in [RFC4026] and [RFC4110]. The most important definitions are repeated in this section; for other definitions, the reader is referred to [RFC4026] and [RFC4110].
このドキュメントはPPVPN特有の用語を使用します。 [RFC4026]と[RFC4110]でPPVPN用語に特定の定義と詳細を見つけることができます。 最も重要な定義はこのセクションで繰り返されます。 他の定義について、読者は[RFC4026]と[RFC4110]を参照されます。
CE: Customer Edge device, a router or a switch in the customer
network interfacing with the service provider's network.
Ce: 顧客の顧客Edgeデバイス、ルータまたはスイッチがサービスプロバイダーのネットワークとの連結をネットワークでつなぎます。
P: Provider Router. The Provider Router is a router in the
service provider's core network that does not have interfaces
directly toward the customer. A P router is used to
interconnect the PE routers. A P router does not have to
maintain VPN state and is thus VPN unaware.
P: プロバイダールータ。 Provider Routerは顧客直接に向かってインタフェースを持っていないサービスプロバイダーのコアネットワークでルータです。 Pルータは、PEルータとインタコネクトするのに使用されます。 PルータはVPN状態を維持する必要はありません、そして、その結果、VPNは気づきませんか?
PE: Provider Edge device, the equipment in the service provider's
network that interfaces with the equipment in the customer's
network.
PE: プロバイダーEdgeデバイス、顧客のネットワークで設備に連結するサービスプロバイダーのネットワークにおける設備。
PPVPN: Provider-Provisioned Virtual Private Network, a VPN that is
configured and managed by the service provider (and thus not by
the customer itself).
PPVPN: プロバイダーで食糧を供給されたVirtual兵士のNetwork(サービスプロバイダーによって構成されて、管理された、(その結果、顧客自身で、そうしません)であるVPN)。
SP: Service Provider.
SP: サービスプロバイダー。
VPN: Virtual Private Network, which restricts communication
between a set of sites using an IP backbone shared by traffic
that is not going to or coming from those sites.
VPN: 仮想の兵士のNetwork、どれがIPバックボーンを使用することで1セットのサイトのコミュニケーションを制限するかはそれらのサイトから行かないか、または来ないトラフィックによって共有されました。
3. Security Reference Model
3. セキュリティ規範モデル
This section defines a reference model for security in PPVPN networks.
このセクションはセキュリティのためにPPVPNネットワークで規範モデルを定義します。
A PPVPN core network is the central network infrastructure (P and PE routers) over which PPVPN services are delivered. A PPVPN core network consists of one or more SP networks. All network elements in the core are under the operational control of one or more PPVPN service providers. Even if the PPVPN core is provided by several service providers, it appears to the PPVPN users as a single zone of trust. However, several service providers providing a common PPVPN core still have to secure themselves against the other providers. PPVPN services can also be delivered over the Internet, in which case the Internet forms a logical part of the PPVPN core.
PPVPNコアネットワークはPPVPNサービスが提供される主要なネットワークインフラ(PとPEルータ)です。 PPVPNコアネットワークは1つ以上のSPネットワークから成ります。 コアのすべてのネットワーク要素が1つ以上のPPVPNサービスプロバイダーの運用統制の下にあります。 PPVPNコアがいくつかのサービスプロバイダーによって提供されても、それは信頼のただ一つのゾーンとしてPPVPNユーザにとって現れます。 しかしながら、一般的なPPVPNコアを提供するいくつかのサービスプロバイダーがまだ他のプロバイダーに対して自分たちを機密保護しなければなりません。 また、PPVPNサービスをインターネットの上に提供できます、その場合、インターネットはPPVPNコアの論理的な部分を形成します。
Fang Informational [Page 4] RFC 4111 PPVPN Security Framework July 2005
[4ページ]RFC4111PPVPNセキュリティフレームワーク2005年7月の情報の牙
A PPVPN user is a company, institution or residential client of the PPVPN service provider.
PPVPNユーザは、PPVPNサービスプロバイダーの会社、団体または住宅のクライアントです。
A PPVPN service is a private network service made available by a service provider to a PPVPN user. The service is implemented using virtual constructs built on a shared PPVPN core network. A PPVPN service interconnects sites of a PPVPN user.
PPVPNサービスはPPVPNサービスプロバイダーのようなユーザによって利用可能にされた個人的なネットワーク・サービスです。 サービスは、共有されたPPVPNコアネットワークに建てられた仮想の構造物を使用することで実装されます。 PPVPNサービスはPPVPNユーザのサイトとインタコネクトします。
Extranets are VPNs in which multiple sites are controlled by different (legal) entities. Extranets are another example of PPVPN deployment scenarios wherein restricted and controlled communication is allowed between trusted zones, often via well-defined transit points.
エクストラネットは複数のサイトが異なった(法的な)実体によって制御されるVPNsです。 エクストラネットはどの点で制限されているPPVPN展開シナリオに関する別の例です、そして、制御コミュニケーションは信じられたゾーンの間に許容されています、しばしば明確な乗り継ぎ地点で。
This document defines each PPVPN as a trusted zone and the PPVPN core as another trusted zone. A primary concern is security aspects that relate to breaches of security from the "outside" of a trusted zone to the "inside" of this zone. Figure 1 depicts the concept of trusted zones within the PPVPN framework.
このドキュメントは別の信じられたゾーンとして信じられたゾーンとPPVPNコアと各PPVPNを定義します。 プライマリ関心はセキュリティの信じられたゾーンの「外部」からこのゾーンの“inside"までの不履行に関連するセキュリティ局面です。 図1はPPVPNフレームワークの中に信じられたゾーンの概念について表現します。
+------------+ +------------+
| PPVPN +-----------------------------+ PPVPN |
| user PPVPN user |
| site +---------------------XXX-----+ site |
+------------+ +------------------XXX--+ +------------+
| PPVPN core | | |
+------------------| |--+
| |
| +------\
+--------/ Internet
+------------+ +------------+ | PPVPN+-----------------------------+ PPVPN| | ユーザPPVPNユーザ| | サイト+---------------------XXX-----+ サイト| +------------+ +------------------XXX--+ +------------+ | PPVPNコア| | | +------------------| |--+ | | | +------\ +--------/インターネット
Figure 1: The PPVPN trusted zone model
図1: PPVPNの信じられたゾーンモデル
In principle, the trusted zones should be separate. However, PPVPN core networks often offer Internet access, in which case a transit point (marked "XXX" in the figure) is defined.
原則として、信じられたゾーンは別々であるべきです。 しかしながら、PPVPNコアネットワークはしばしばインターネット・アクセスを提供します、その場合、乗り継ぎ地点(図の"XXX"であるとマークされる)は定義されます。
The key requirement of a "virtual private" network (VPN) is that the security of the trusted zone of the VPN is not compromised by sharing the core infrastructure with other VPNs.
a「仮想の兵卒」ネットワーク(VPN)の主要な要件は他のVPNsとコアインフラストラクチャを共有することによってVPNの信じられたゾーンのセキュリティが感染されないということです。
Security against threats that originate within the same trusted zone as their targets (for example, attacks from a user in a PPVPN to other users within the same PPVPN, or attacks entirely within the core network) is outside the scope of this document.
このドキュメントの範囲の外にそれらの目標(例えば、PPVPNのユーザから同じPPVPNの中の他のユーザまでの攻撃、または完全にコアネットワークの中の攻撃)と同じ信じられたゾーンの中で起因する脅威に対するセキュリティがあります。
Also outside the scope are all aspects of network security that are independent of whether a network is a PPVPN network or a private
範囲の外にも、ネットワークがPPVPNネットワークであるかどうかから独立しているネットワークセキュリティの全面か兵卒がいます。
Fang Informational [Page 5] RFC 4111 PPVPN Security Framework July 2005
[5ページ]RFC4111PPVPNセキュリティフレームワーク2005年7月の情報の牙
network. For example, attacks from the Internet to a web server inside a given PPVPN will not be considered here, unless the provisioning of the PPVPN network could make a difference to the security of this server.
ネットワークでつなぎます。 例えば、与えられたPPVPNの中のインターネットからウェブサーバーまでの攻撃はここで考えられないでしょう、PPVPNネットワークの食糧を供給するのがこのサーバのセキュリティに相違が生じることができなかったなら。
4. Security Threats
4. 軍事的脅威
This section discusses the various network security threats that may endanger PPVPNs. The discussion is limited to threats that are unique to PPVPNs, or that affect PPVPNs in unique ways. A successful attack on a particular PPVPN or on a service provider's PPVPN infrastructure may cause one or more of the following ill effects:
このセクションはPPVPNsを危険にさらすかもしれない様々なネットワーク軍事的脅威について論じます。 議論はPPVPNsにユニークであるか、またはユニークな方法でPPVPNsに影響する脅威に制限されます。 特定のPPVPN、または、サービスプロバイダーのPPVPNインフラストラクチャに対するうまくいっている攻撃は以下の害の1つ以上を引き起こすかもしれません:
- observation, modification, or deletion of PPVPN user data,
- PPVPN利用者データの観測、変更、または削除
- replay of PPVPN user data,
- PPVPN利用者データの再生
- injection of non-authentic data into a PPVPN,
- PPVPNへの非典拠のある資料の注射
- traffic pattern analysis on PPVPN traffic,
- トラフィックはPPVPNトラフィックの分析を型に基づいて作ります。
- disruption of PPVPN connectivity, or
- またはPPVPNの接続性の分裂。
- degradation of PPVPN service quality.
- PPVPNサービス品質の低下。
It is useful to consider that threats to a PPVPN, whether malicious or accidental, may come from different categories of sources. For example they may come from:
悪意があるか、または偶然であることにかかわらずPPVPNへの脅威がソースの異なったカテゴリから来るかもしれないと考えるのは役に立ちます。 例えば、彼らは以下から来るかもしれません。
- users of other PPVPNs provided by the same PPVPN service provider,
- 他のPPVPNsのユーザは同じPPVPNサービスプロバイダーで提供しました。
- the PPVPN service provider or persons working for it,
- それのために働いているPPVPNサービスプロバイダーか人々
- other persons who obtain physical access to a service provider
site,
- サービスプロバイダーサイトへの物理的なアクセスを得る他の人々
- other persons who use social engineering methods to influence
behavior of service provider personnel,
- サービスプロバイダー人員の振舞いに影響を及ぼすソーシャルエンジニアリングメソッドを使用する他の人々
- users of the PPVPN itself, i.e., intra-VPN threats (such threats
are beyond the scope of this document), or
- またはすなわち、PPVPN自身のユーザ、イントラ-VPNの脅威(そのような脅威はこのドキュメントの範囲を超えている)。
- others, i.e., attackers from the Internet at large.
- すなわち、他のもの、全体のインターネットからの攻撃者。
In the case of PPVPNs, some parties may be in more advantageous positions that enable them to launch types of attacks not available to others. For example, users of different PPVPNs provided by the
PPVPNsの場合には、いくつかのパーティーが他のものには、利用可能でない攻撃のタイプを送り出すのを可能にするより有利な位置であるかもしれません。 例えば、異なったPPVPNsのユーザは提供しました。
Fang Informational [Page 6] RFC 4111 PPVPN Security Framework July 2005
[6ページ]RFC4111PPVPNセキュリティフレームワーク2005年7月の情報の牙
same service provider may be able to launch attacks that those who are completely outside the network cannot.
同じサービスプロバイダーはネットワークの完全外にいる人が着手できない攻撃に着手できるかもしれません。
Given that security is generally a compromise between expense and risk, it is also useful to consider the likelihood of different attacks. There is at least a perceived difference in the likelihood of most types of attacks being successfully mounted in different environments, such as
また、セキュリティが一般に費用とリスクの間の感染であるなら、異なった攻撃の見込みを考えるのも役に立ちます。 異なった環境で首尾よく仕掛けられるほとんどのタイプの攻撃の見込みには少なくとも違いであると知覚されたaがあります、あれほどです。
- in a PPVPN contained within one service provider's network, or
- または1つのサービスプロバイダーのネットワークの中に含まれたPPVPNで。
- in a PPVPN transiting the public Internet.
- 公共のインターネットを通過するPPVPNで。
Most types of attacks become easier to mount, and hence more likely, as the shared infrastructure that provides VPN service expands from a single service provider to multiple cooperating providers, and then to the global Internet. Attacks that may not be sufficiently likely to warrant concern in a closely controlled environment often merit defensive measures in broader, more open environments.
ほとんどのタイプの攻撃は取り付けるのが、より簡単になります、そして、したがって、おそらく、提供される共有されたインフラストラクチャとして、VPNサービスはただ一つのサービスプロバイダーから複数の協力プロバイダーまでそして、世界的なインターネットに広がります。 しっかりと制御された環境における関心を十分保証しそうにないかもしれない攻撃はしばしばより広くて、より開いている環境における防衛策に値します。
The following sections discuss specific types of exploits that threaten PPVPNs.
以下のセクションはPPVPNsを脅かす特定のタイプの功績について論じます。
4.1. Attacks on the Data Plane
4.1. データ飛行機に対する攻撃
This category encompasses attacks on the PPVPN user's data, as viewed by the service provider. Note that from the PPVPN user's point of view, some of this might be control plane traffic, e.g., routing protocols running from PPVPN user site to PPVPN user site via an L2 PPVPN.
サービスプロバイダーによって見られるようにこのカテゴリはPPVPNユーザのデータに対する攻撃を成就します。 この何かがコントロール飛行機トラフィック、例えばPPVPNユーザの観点からの、L2 PPVPNを通してPPVPNユーザの現場からPPVPNユーザの現場まで稼働するルーティング・プロトコルであるかもしれないことに注意してください。
4.1.1. Unauthorized Observation of Data Traffic
4.1.1. データ通信量の権限のない観測
This refers to "sniffing" VPN packets and examining their contents. This can result in exposure of confidential information. It can also be a first step in other attacks (described below) in which the recorded data is modified and re-inserted, or re-inserted unchanged.
これはVPNパケットを「かい」で、それらのコンテンツを調べるのを示します。 これは秘密情報の暴露をもたらすことができます。 また、それは記録データが変更されて、再び差し込まれるか、または変わりがない状態で再び差し込まれる他の攻撃(以下で、説明される)で第一歩であるかもしれません。
4.1.2. Modification of Data Traffic
4.1.2. データ通信量の変更
This refers to modifying the contents of packets as they traverse the VPN.
これはVPNを横断するのでパケットのコンテンツを変更するのを示します。
4.1.3. Insertion of Non-authentic Data Traffic: Spoofing and Replay
4.1.3. 非典拠のある資料トラフィックの挿入: スプーフィングと再生
This refers to the insertion into the VPN (or "spoofing") of packets that do not belong there, with the objective of having them accepted as legitimate by the recipient. Also included in this category is
これはそこで属しないパケットのVPN(または、「だます」)と挿入を呼びます、それらを受け入れさせる目的が受取人で正統の状態で。 また、これに含まれていて、カテゴリはそうです。
Fang Informational [Page 7] RFC 4111 PPVPN Security Framework July 2005
[7ページ]RFC4111PPVPNセキュリティフレームワーク2005年7月の情報の牙
the insertion of copies of once-legitimate packets that have been recorded and replayed.
記録されて、再演されたかつて正統のパケットのコピーの挿入。
4.1.4. Unauthorized Deletion of Data Traffic
4.1.4. データ通信量の権限のない削除
This refers to causing packets to be discarded as they traverse the VPN. This is a specific type of Denial-of-Service attack.
VPNを横断するのでパケットが捨てられることを引き起こすのをこれは示します。 これは特定のタイプのサービス不能攻撃です。
4.1.5. Unauthorized Traffic Pattern Analysis
4.1.5. 権限のないトラフィックパターン解析
This refers to "sniffing" VPN packets and examining aspects or meta- aspects of them that may be visible even when the packets themselves are encrypted. An attacker might gain useful information based on the amount and timing of traffic, packet sizes, source and destination addresses, etc. For most PPVPN users, this type of attack is generally considered significantly less of a concern than are the other types discussed in this section.
これはVPNパケットを「かい」で、それらのパケット自体が暗号化されてさえいるとき目に見えるかもしれない局面かメタ局面を調べるのを示します。 攻撃者は量とトラフィックのタイミングとパケットサイズとソースと送付先アドレスなどに基づく役に立つ情報を獲得するかもしれません。 一般に、ほとんどのPPVPNユーザに関しては、このタイプの攻撃はこのセクションで議論した他のタイプより関心でかなり少ない状態で考えられます。
4.1.6. Denial-of-Service Attacks on the VPN
4.1.6. VPNにおけるサービス不能攻撃
Denial-of-Service (DoS) attacks are those in which an attacker attempts to disrupt or prevent the use of a service by its legitimate users. Taking network devices out of service, modifying their configuration, or overwhelming them with requests for service are several of the possible avenues for DoS attack.
サービス妨害(DoS)攻撃は攻撃者が正統のユーザによるサービスの使用を中断するか、または防ぐのを試みるそれらです。 ネットワークデバイスを取って、いくつかのDoSに、可能な大通りが攻撃されます。
Overwhelming the network with requests for service, otherwise known as a "resource exhaustion" DoS attack, may target any resource in the network, e.g., link bandwidth, packet forwarding capacity, session capacity for various protocols, and CPU power.
サービスを求める要求でネットワークを別の方法で「リソース疲労困憊」DoS攻撃として知られている圧倒するのはネットワーク、例えば、リンク帯域幅、容量、様々なプロトコルのためのセッション容量を進めるパケット、およびCPUパワーにおけるどんなリソースも狙うかもしれません。
DoS attacks of the resource exhaustion type can be mounted against the data plane of a particular PPVPN by attempting to insert (spoof) an overwhelming quantity of non-authentic data into the VPN from outside of that VPN. Potential results might be to exhaust the bandwidth available to that VPN or to overwhelm the cryptographic authentication mechanisms of the VPN.
圧倒的な量の非典拠のある資料をそのVPNの外部からVPNに挿入するのを(だまします)試みることによって、特定のPPVPNのデータ飛行機に対してリソース疲労困憊タイプのDoS攻撃を仕掛けることができます。 潜在的結果は、そのVPNに利用可能な帯域幅を消耗させるか、またはVPNの暗号の認証機構を圧倒することであるかもしれません。
Data plane resource exhaustion attacks can also be mounted by overwhelming the service provider's general (VPN-independent) infrastructure with traffic. These attacks on the general infrastructure are not usually a PPVPN-specific issue, unless the attack is mounted by another PPVPN user from a privileged position. For example, a PPVPN user might be able to monopolize network data plane resources and thus to disrupt other PPVPNs.)
また、トラフィックでサービスプロバイダーの一般的な(VPNから独立している)インフラストラクチャを圧倒することによって、データ飛行機リソース疲労困憊攻撃を仕掛けることができます。 通常、一般的なインフラストラクチャに対するこれらの攻撃はPPVPN特有の問題ではありません、攻撃が別のPPVPNユーザによって特権的な地位から仕掛けられない場合。 例えば、PPVPNユーザは、ネットワークデータ飛行機リソースを独占して、その結果、他のPPVPNsを混乱させることができるかもしれません。)
Fang Informational [Page 8] RFC 4111 PPVPN Security Framework July 2005
[8ページ]RFC4111PPVPNセキュリティフレームワーク2005年7月の情報の牙
4.2. Attacks on the Control Plane
4.2. 制御飛行機に対する攻撃
This category encompasses attacks on the control structures operated by the PPVPN service provider.
このカテゴリはPPVPNサービスプロバイダーによって運用された制御構造に対する攻撃を成就します。
4.2.1. Denial-of-Service Attacks on Network Infrastructure
4.2.1. ネットワークインフラにおけるサービス不能攻撃
Control plane DoS attacks can be mounted specifically against the mechanisms that the service provider uses to provide PPVPNs (e.g., IPsec, MPLS) or against the general infrastructure of the service provider (e.g., P routers or shared aspects of PE routers.) Attacks against the general infrastructure are within the scope of this document only if the attack happens in relation to the VPN service; otherwise, they are not a PPVPN-specific issue.
特にサービスプロバイダーがPPVPNsを提供するのに使用するメカニズム(例えば、IPsec、MPLS)に対して、または、サービスプロバイダーの一般的なインフラストラクチャ(PEルータの例えば、Pルータか共有された局面)に対してコントロール飛行機DoS攻撃を仕掛けることができます。 攻撃がVPNサービスと関連して起こる場合にだけ、このドキュメントの範囲の中に一般的なインフラストラクチャに対する攻撃があります。 さもなければ、それらはPPVPN特有の問題ではありません。
Of special concern for PPVPNs is denial of service to one PPVPN user caused by the activities of another. This can occur, for example, if one PPVPN user's activities are allowed to consume excessive network resources of any sort that are also needed to serve other PPVPN users.
特別番組では、PPVPNsに関する心配は別のものの活動で引き起こされた1人のPPVPNユーザに対するサービスの否定です。 例えば、1人のPPVPNユーザの活動がまた、他のPPVPNユーザに役立つのに必要であるどんな種類の過度のネットワーク資源も消費できるなら、これは起こることができます。
The attacks described in the following sections may each have denial of service as one of their effects. Other DoS attacks are also possible.
以下のセクションで説明された攻撃はそれらの効果の1つとしてそれぞれサービスの否定を持っているかもしれません。 また、他のDoS攻撃も可能です。
4.2.2. Attacks on Service Provider Equipment via Management
Interfaces
4.2.2. Management Interfacesを通したService Provider Equipmentに対する攻撃
This includes unauthorized access to service provider infrastructure equipment, in order, for example, to reconfigure the equipment or to extract information (statistics, topology, etc.) about one or more PPVPNs.
これはサービスプロバイダーインフラストラクチャ設備への不正アクセスを含んでいます、例えば、設備を再構成するか、または情報(統計、トポロジーなど)およそ1PPVPNsを抽出する命令で。
This can be accomplished through malicious entrance of the systems, or as an inadvertent consequence of inadequate inter-VPN isolation in a PPVPN user self-management interface. (The former is not necessarily a PPVPN-specific issue.)
システムの悪意がある入り口、または、PPVPNユーザ自己管理インタフェースの不十分な相互VPN分離の不注意な結果としてこれを達成できます。 (前者は必ずPPVPN特有の問題であるというわけではありません。)
4.2.3. Social Engineering Attacks on Service Provider
Infrastructure
4.2.3. サービスプロバイダーインフラストラクチャに対するソーシャルエンジニアリング攻撃
Attacks in which the service provider network is reconfigured or damaged, or in which confidential information is improperly disclosed, may be mounted through manipulation of service provider personnel. These types of attacks are PPVPN-specific if they affect PPVPN-serving mechanisms. It may be observed that the organizational split (customer, service provider) that is inherent in PPVPNs may make it easier to mount such attacks against provider-provisioned
サービスプロバイダーネットワークが再構成されるか、破損する、または秘密情報が不適切に明らかにされる攻撃、サービスプロバイダー人員の操作で取り付けられるかもしれません。 PPVPNに役立っているメカニズムに影響するなら、これらのタイプの攻撃はPPVPN特有です。PPVPNsに固有の組織的な分裂(顧客、サービスプロバイダー)でプロバイダーで食糧を供給されることに対してそのような攻撃を仕掛けるのが、より簡単になるかもしれないのが観測されるかもしれません。
Fang Informational [Page 9] RFC 4111 PPVPN Security Framework July 2005
[9ページ]RFC4111PPVPNセキュリティフレームワーク2005年7月の情報の牙
VPNs than against VPNs that are self-provisioned by the customer at the IP layer.
VPNs、IP層の顧客によって自己に食糧を供給されるVPNsより。
4.2.4. Cross-Connection of Traffic between PPVPNs
4.2.4. PPVPNsの間のトラフィックの交差接続
This refers to events where expected isolation between separate PPVPNs is breached. This includes cases such as:
これは別々のPPVPNsの間の予想された分離が破られるところとイベントを呼びます。 これは以下などのケースを含んでいます。
- a site being connected into the "wrong" VPN,
- 「間違った」VPNにつなげられるサイト
- two or more VPNs being improperly merged,
- 不適切に合併されている、2VPNs
- a point-to-point VPN connecting the wrong two points, or
- または間違った2を接続する二地点間VPNが指す。
- any packet or frame being improperly delivered outside the VPN it
is sent in.
- VPNで外それが送られる不適切に提供されるどんなパケットやフレーム。
Misconnection or cross-connection of VPNs may be caused by service provider or equipment vendor error, or by the malicious action of an attacker. The breach may be physical (e.g., PE-CE links misconnected) or logical (improper device configuration).
VPNsの付け違いか交差接続がサービスプロバイダーか設備ベンダー誤り、または攻撃者の悪意がある行為で引き起こされるかもしれません。 不履行は、物理的であるか(例えば付け違いされたPE-CEリンク)、または当然であるかもしれません(不適当なデバイス構成)。
Anecdotal evidence suggests that the cross-connection threat is one of the largest security concerns of PPVPN users (or would-be users).
逸話の証拠は、交差接続の脅威がPPVPNユーザ(または、ひとりよがりのユーザ)の最も大きい安全上の配慮の1つであると示唆します。
4.2.5. Attacks against PPVPN Routing Protocols
4.2.5. PPVPNルーティング・プロトコルに対する攻撃
This encompasses attacks against routing protocols that are run by the service provider and that directly support the PPVPN service. In layer 3 VPNs this, typically relates to membership discovery or to the distribution of per-VPN routes. In layer 2 VPNs, this typically relates to membership and endpoint discovery. Attacks against the use of routing protocols for the distribution of backbone (non-VPN) routes are beyond the scope of this document. Specific attacks against popular routing protocols have been widely studied and are described in [RFC3889].
これはサービスプロバイダーによって述べられて、PPVPNがサービスであると直接サポートするルーティング・プロトコルに対して攻撃を成就します。 層3のVPNs、これ、会員資格発見、または、1VPNあたりのルートの分配に通常関係します。 層2のVPNsでは、これは会員資格と終点発見に通常関連します。 ルーティング・プロトコルのバックボーン(非VPN)ルートの分配の使用に対する攻撃はこのドキュメントの範囲を超えています。 特定の攻撃は、広く研究されて、[RFC3889]にポピュラーなルーティング・プロトコルに対して説明されます。
4.2.6. Attacks on Route Separation
4.2.6. ルート分離に対する攻撃
"Route separation" refers here to keeping the per-VPN topology and reachability information for each PPVPN separate from, and unavailable to, any other PPVPN (except as specifically intended by the service provider). This concept is only a distinct security concern for layer-3 VPN types for which the service provider is involved with the routing within the VPN (i.e., VR, BGP-MPLS, routed version of IPsec). A breach in the route separation can reveal topology and addressing information about a PPVPN. It can also cause
「ルート分離」はここに各PPVPNのための1VPNあたりのトポロジーと可到達性情報を別々で、入手できなく保つのを示します、いかなる他のPPVPN(サービスプロバイダーによって明確に意図されるのを除いて)。 この概念はサービスプロバイダーがVPNの中のルーティングにかかわる層-3つのVPNタイプに関する異なったセキュリティ心配にすぎません(すなわち、VR(BGP-MPLS)はIPsecのバージョンを発送しました)。 ルート分離における不履行はPPVPNに関するトポロジーとアドレス指定情報を明らかにすることができます。 また、それは引き起こす場合があります。
Fang Informational [Page 10] RFC 4111 PPVPN Security Framework July 2005
[10ページ]RFC4111PPVPNセキュリティフレームワーク2005年7月の情報の牙
black hole routing or unauthorized data plane cross-connection between PPVPNs.
PPVPNsの間のブラックホールルーティングか権限のないデータ飛行機交差接続。
4.2.7. Attacks on Address Space Separation
4.2.7. アドレス空間分離に対する攻撃
In layer-3 VPNs, the IP address spaces of different VPNs have to be kept separate. In layer-2 VPNs, the MAC address and VLAN spaces of different VPNs have to be kept separate. A control plane breach in this addressing separation may result in unauthorized data plane cross-connection between VPNs.
層-3VPNsでは、異なったVPNsのIPアドレス空間は別々に保たれなければなりません。 層-2VPNsでは、異なったVPNsのMACアドレスとVLAN空間は別々に保管されなければなりません。 このアドレシング分離におけるコントロール飛行機不履行はVPNsの間の権限のないデータ飛行機交差接続をもたらすかもしれません。
4.2.8. Other Attacks on PPVPN Control Traffic
4.2.8. PPVPNコントロールトラフィックに対する他の攻撃
Besides routing and management protocols (covered separately in the previous sections), a number of other control protocols may be directly involved in delivering the PPVPN service (e.g., for membership discovery and tunnel establishment in various PPVPN approaches). These include but may not be limited to:
Besides routing and management protocols (covered separately in the previous sections), a number of other control protocols may be directly involved in delivering the PPVPN service (e.g., for membership discovery and tunnel establishment in various PPVPN approaches). These include but may not be limited to:
- MPLS signaling (LDP, RSVP-TE), - IPsec signaling (IKE) , - L2TP, - BGP-based membership discovery, and - Database-based membership discovery (e.g., RADIUS-based).
- MPLS signaling (LDP, RSVP-TE), - IPsec signaling (IKE) , - L2TP, - BGP-based membership discovery, and - Database-based membership discovery (e.g., RADIUS-based).
Attacks might subvert or disrupt the activities of these protocols, for example, via impersonation or DoS attacks.
Attacks might subvert or disrupt the activities of these protocols, for example, via impersonation or DoS attacks.
5. Defensive Techniques for PPVPN Service Providers
5. Defensive Techniques for PPVPN Service Providers
The defensive techniques discussed in this document are intended to describe methods by which some security threats can be addressed. They are not intended as requirements for all PPVPN implementations. The PPVPN provider should determine the applicability of these techniques to the provider's specific service offerings, and the PPVPN user may wish to assess the value of these techniques in regard to the user's VPN requirements.
The defensive techniques discussed in this document are intended to describe methods by which some security threats can be addressed. They are not intended as requirements for all PPVPN implementations. The PPVPN provider should determine the applicability of these techniques to the provider's specific service offerings, and the PPVPN user may wish to assess the value of these techniques in regard to the user's VPN requirements.
The techniques discussed here include encryption, authentication, filtering, firewalls, access control, isolation, aggregation, and other techniques.
The techniques discussed here include encryption, authentication, filtering, firewalls, access control, isolation, aggregation, and other techniques.
Nothing is ever 100% secure. Defense therefore protects against those attacks that are most likely to occur or that could have the most dire consequences. Absolute protection against these attacks is seldom achievable; more often it is sufficient to make the cost of a successful attack greater than what the adversary would be willing to expend.
Nothing is ever 100% secure. Defense therefore protects against those attacks that are most likely to occur or that could have the most dire consequences. Absolute protection against these attacks is seldom achievable; more often it is sufficient to make the cost of a successful attack greater than what the adversary would be willing to expend.
Fang Informational [Page 11] RFC 4111 PPVPN Security Framework July 2005
Fang Informational [Page 11] RFC 4111 PPVPN Security Framework July 2005
Successful defense against an attack does not necessarily mean that the attack must be prevented from happening or from reaching its target. In many cases, the network can instead be designed to withstand the attack. For example, the introduction of non-authentic packets could be defended against by preventing their introduction in the first place, or by making it possible to identify and eliminate them before delivery to the PPVPN user's system. The latter is frequently a much easier task.
Successful defense against an attack does not necessarily mean that the attack must be prevented from happening or from reaching its target. In many cases, the network can instead be designed to withstand the attack. For example, the introduction of non-authentic packets could be defended against by preventing their introduction in the first place, or by making it possible to identify and eliminate them before delivery to the PPVPN user's system. The latter is frequently a much easier task.
5.1. Cryptographic Techniques
5.1. Cryptographic Techniques
PPVPN defenses against a wide variety of attacks can be enhanced by the proper application of cryptographic techniques. These are the same cryptographic techniques that are applicable to general network communications. In general, these techniques can provide confidentiality (encryption) of communication between devices, authentication of the identities of the devices, and detection of a change of the protected data during transit.
PPVPN defenses against a wide variety of attacks can be enhanced by the proper application of cryptographic techniques. These are the same cryptographic techniques that are applicable to general network communications. In general, these techniques can provide confidentiality (encryption) of communication between devices, authentication of the identities of the devices, and detection of a change of the protected data during transit.
Privacy is a key part (the middle name!) of any Virtual Private Network. In a PPVPN, privacy can be provided by two mechanisms: traffic separation and encryption. This section focuses on encryption; traffic separation is addressed separately.
Privacy is a key part (the middle name!) of any Virtual Private Network. In a PPVPN, privacy can be provided by two mechanisms: traffic separation and encryption. This section focuses on encryption; traffic separation is addressed separately.
Several aspects of authentication are addressed in some detail in a separate "Authentication" section.
Several aspects of authentication are addressed in some detail in a separate "Authentication" section.
Encryption adds complexity, and thus it may not be a standard offering within every PPVPN service. There are a few reasons for this. Encryption adds an additional computational burden to the devices performing encryption and decryption. This may reduce the number of user VPN connections that can be handled on a device or otherwise reduce the capacity of the device, potentially driving up the provider's costs. Typically, configuring encryption services on devices adds to the complexity of the device configuration and adds incremental labor cost. Encrypting packets typically increases packet lengths, thereby increasing the network traffic load and the likelihood of packet fragmentation, with its increased overhead. (Packet length increase can often be mitigated to some extent by data compression techniques, but with additional computational burden.) Finally, some PPVPN providers may employ enough other defensive techniques, such as physical isolation or filtering/firewall techniques, that they may not perceive additional benefit from encryption techniques.
Encryption adds complexity, and thus it may not be a standard offering within every PPVPN service. There are a few reasons for this. Encryption adds an additional computational burden to the devices performing encryption and decryption. This may reduce the number of user VPN connections that can be handled on a device or otherwise reduce the capacity of the device, potentially driving up the provider's costs. Typically, configuring encryption services on devices adds to the complexity of the device configuration and adds incremental labor cost. Encrypting packets typically increases packet lengths, thereby increasing the network traffic load and the likelihood of packet fragmentation, with its increased overhead. (Packet length increase can often be mitigated to some extent by data compression techniques, but with additional computational burden.) Finally, some PPVPN providers may employ enough other defensive techniques, such as physical isolation or filtering/firewall techniques, that they may not perceive additional benefit from encryption techniques.
The trust model among the PPVPN user, the PPVPN provider, and other parts of the network is a key element in determining the applicability of encryption for any specific PPVPN implementation.
The trust model among the PPVPN user, the PPVPN provider, and other parts of the network is a key element in determining the applicability of encryption for any specific PPVPN implementation.
Fang Informational [Page 12] RFC 4111 PPVPN Security Framework July 2005
Fang Informational [Page 12] RFC 4111 PPVPN Security Framework July 2005
In particular, it determines where encryption should be applied, as follows.
In particular, it determines where encryption should be applied, as follows.
- If the data path between the user's site and the provider's PE
is not trusted, then encryption may be used on the PE-CE link.
- If the data path between the user's site and the provider's PE is not trusted, then encryption may be used on the PE-CE link.
- If some part of the backbone network is not trusted,
particularly in implementations where traffic may travel across
the Internet or multiple provider networks, then the PE-PE
traffic may be encrypted.
- If some part of the backbone network is not trusted, particularly in implementations where traffic may travel across the Internet or multiple provider networks, then the PE-PE traffic may be encrypted.
- If the PPVPN user does not trust any zone outside of its
premises, it may require end-to-end or CE-CE encryption
service. This service fits within the scope of this PPVPN
security framework when the CE is provisioned by the PPVPN
provider.
- If the PPVPN user does not trust any zone outside of its premises, it may require end-to-end or CE-CE encryption service. This service fits within the scope of this PPVPN security framework when the CE is provisioned by the PPVPN provider.
- If the PPVPN user requires remote access to a PPVPN from a
system that is not at a PPVPN customer location (for example,
access by a traveler), there may be a requirement for
encrypting the traffic between that system and an access point
on the PPVPN or at a customer site. If the PPVPN provider
provides the access point, then the customer must cooperate
with the provider to handle the access control services for the
remote users. These access control services are usually
implemented by using encryption, as well.
- If the PPVPN user requires remote access to a PPVPN from a system that is not at a PPVPN customer location (for example, access by a traveler), there may be a requirement for encrypting the traffic between that system and an access point on the PPVPN or at a customer site. If the PPVPN provider provides the access point, then the customer must cooperate with the provider to handle the access control services for the remote users. These access control services are usually implemented by using encryption, as well.
Although CE-CE encryption provides confidentiality against third- party interception, if the PPVPN provider has complete management control over the CE (encryption) devices, then it may be possible for the provider to gain access to the user's VPN traffic or internal network. Encryption devices can potentially be configured to use null encryption, to bypass encryption processing altogether, or to provide some means of sniffing or diverting unencrypted traffic. Thus, a PPVPN implementation using CE-CE encryption has to consider the trust relationship between the PPVPN user and provider. PPVPN users and providers may wish to negotiate a service level agreement (SLA) for CE-CE encryption that will provide an acceptable demarcation of responsibilities for management of encryption on the CE devices.
Although CE-CE encryption provides confidentiality against third- party interception, if the PPVPN provider has complete management control over the CE (encryption) devices, then it may be possible for the provider to gain access to the user's VPN traffic or internal network. Encryption devices can potentially be configured to use null encryption, to bypass encryption processing altogether, or to provide some means of sniffing or diverting unencrypted traffic. Thus, a PPVPN implementation using CE-CE encryption has to consider the trust relationship between the PPVPN user and provider. PPVPN users and providers may wish to negotiate a service level agreement (SLA) for CE-CE encryption that will provide an acceptable demarcation of responsibilities for management of encryption on the CE devices.
The demarcation may also be affected by the capabilities of the CE devices. For example, the CE might support some partitioning of management or a configuration lock-down ability, or it might allow both parties to verify the configuration. In general, if the managed CE-CE model is used, the PPVPN user has to have a fairly high level of trust that the PPVPN provider will properly provision and manage the CE devices.
The demarcation may also be affected by the capabilities of the CE devices. For example, the CE might support some partitioning of management or a configuration lock-down ability, or it might allow both parties to verify the configuration. In general, if the managed CE-CE model is used, the PPVPN user has to have a fairly high level of trust that the PPVPN provider will properly provision and manage the CE devices.
Fang Informational [Page 13] RFC 4111 PPVPN Security Framework July 2005
Fang Informational [Page 13] RFC 4111 PPVPN Security Framework July 2005
5.1.1. IPsec in PPVPNs
5.1.1. IPsec in PPVPNs
IPsec [RFC2401] [RFC2402] [RFC2406] [RFC2407] [RFC2411] is the security protocol of choice for encryption at the IP layer (Layer 3), as discussed in [RFC3631]. IPsec provides robust security for IP traffic between pairs of devices. Non-IP traffic must be converted to IP packets, or it cannot be transported over IPsec. Encapsulation is a common conversion method.
IPsec [RFC2401] [RFC2402] [RFC2406] [RFC2407] [RFC2411] is the security protocol of choice for encryption at the IP layer (Layer 3), as discussed in [RFC3631]. IPsec provides robust security for IP traffic between pairs of devices. Non-IP traffic must be converted to IP packets, or it cannot be transported over IPsec. Encapsulation is a common conversion method.
In the PPVPN model, IPsec can be employed to protect IP traffic between PEs, between a PE and a CE, or from CE to CE. CE-to-CE IPsec may be employed in either a provider-provisioned or a user- provisioned model. The user-provisioned CE-CE IPsec model is outside the scope of this document and outside the scope of the PPVPN Working Group. Likewise, data encryption that is performed within the user's site is outside the scope of this document, as it is simply handled as user data by the PPVPN. IPsec can also be used to protect IP traffic between a remote user and the PPVPN.
In the PPVPN model, IPsec can be employed to protect IP traffic between PEs, between a PE and a CE, or from CE to CE. CE-to-CE IPsec may be employed in either a provider-provisioned or a user- provisioned model. The user-provisioned CE-CE IPsec model is outside the scope of this document and outside the scope of the PPVPN Working Group. Likewise, data encryption that is performed within the user's site is outside the scope of this document, as it is simply handled as user data by the PPVPN. IPsec can also be used to protect IP traffic between a remote user and the PPVPN.
IPsec does not itself specify an encryption algorithm. It can use a variety of encryption algorithms with various key lengths, such as AES encryption. There are trade-offs between key length, computational burden, and the level of security of the encryption. A full discussion of these trade-offs is beyond the scope of this document. In order to assess the level of security offered by a particular IPsec-based PPVPN service, some PPVPN users may wish to know the specific encryption algorithm and effective key length used by the PPVPN provider. However, in practice, any currently recommended IPsec encryption offers enough security to substantially reduce the likelihood of being directly targeted by an attacker. Other, weaker, links in the chain of security are likely to be attacked first. PPVPN users may wish to use a Service Level Agreement (SLA) specifying the service provider's responsibility for ensuring data confidentiality rather than to analyze the specific encryption techniques used in the PPVPN service.
IPsec does not itself specify an encryption algorithm. It can use a variety of encryption algorithms with various key lengths, such as AES encryption. There are trade-offs between key length, computational burden, and the level of security of the encryption. A full discussion of these trade-offs is beyond the scope of this document. In order to assess the level of security offered by a particular IPsec-based PPVPN service, some PPVPN users may wish to know the specific encryption algorithm and effective key length used by the PPVPN provider. However, in practice, any currently recommended IPsec encryption offers enough security to substantially reduce the likelihood of being directly targeted by an attacker. Other, weaker, links in the chain of security are likely to be attacked first. PPVPN users may wish to use a Service Level Agreement (SLA) specifying the service provider's responsibility for ensuring data confidentiality rather than to analyze the specific encryption techniques used in the PPVPN service.
For many of the PPVPN provider's network control messages and some PPVPN user requirements, cryptographic authentication of messages without encryption of the contents of the message may provide acceptable security. With IPsec, authentication of messages is provided by the Authentication Header (AH) or by the Encapsulating Security Protocol (ESP) with authentication only. Where control messages require authentication but do not use IPsec, other cryptographic authentication methods are available. Message authentication methods currently considered to be secure are based on hashed message authentication codes (HMAC) [RFC2104] implemented with a secure hash algorithm such as Secure Hash Algorithm 1 (SHA-1) [RFC3174].
For many of the PPVPN provider's network control messages and some PPVPN user requirements, cryptographic authentication of messages without encryption of the contents of the message may provide acceptable security. With IPsec, authentication of messages is provided by the Authentication Header (AH) or by the Encapsulating Security Protocol (ESP) with authentication only. Where control messages require authentication but do not use IPsec, other cryptographic authentication methods are available. Message authentication methods currently considered to be secure are based on hashed message authentication codes (HMAC) [RFC2104] implemented with a secure hash algorithm such as Secure Hash Algorithm 1 (SHA-1) [RFC3174].
Fang Informational [Page 14] RFC 4111 PPVPN Security Framework July 2005
Fang Informational [Page 14] RFC 4111 PPVPN Security Framework July 2005
One recommended mechanism for providing a combination confidentiality, data origin authentication, and connectionless integrity is the use of AES in Cipher Block Chaining (CBC) Mode, with an explicit Initialization Vector (IV) [RFC3602], as the IPsec ESP.
One recommended mechanism for providing a combination confidentiality, data origin authentication, and connectionless integrity is the use of AES in Cipher Block Chaining (CBC) Mode, with an explicit Initialization Vector (IV) [RFC3602], as the IPsec ESP.
PPVPNs that provide differentiated services based on traffic type may encounter some conflicts with IPsec encryption of traffic. As encryption hides the content of the packets, it may not be possible to differentiate the encrypted traffic in the same manner as unencrypted traffic. Although DiffServ markings are copied to the IPsec header and can provide some differentiation, not all traffic types can be accommodated by this mechanism.
PPVPNs that provide differentiated services based on traffic type may encounter some conflicts with IPsec encryption of traffic. As encryption hides the content of the packets, it may not be possible to differentiate the encrypted traffic in the same manner as unencrypted traffic. Although DiffServ markings are copied to the IPsec header and can provide some differentiation, not all traffic types can be accommodated by this mechanism.
5.1.2. Encryption for Device Configuration and Management
5.1.2. Encryption for Device Configuration and Management
For configuration and management of PPVPN devices, encryption and authentication of the management connection at a level comparable to that provided by IPsec is desirable.
For configuration and management of PPVPN devices, encryption and authentication of the management connection at a level comparable to that provided by IPsec is desirable.
Several methods of transporting PPVPN device management traffic offer security and confidentiality.
Several methods of transporting PPVPN device management traffic offer security and confidentiality.
- Secure Shell (SSH) offers protection for TELNET [STD8] or
terminal-like connections to allow device configuration.
- Secure Shell (SSH) offers protection for TELNET [STD8] or terminal-like connections to allow device configuration.
- SNMP v3 [STD62] provides encrypted and authenticated protection
for SNMP-managed devices.
- SNMP v3 [STD62] provides encrypted and authenticated protection for SNMP-managed devices.
- Transport Layer Security (TLS) [RFC2246] and the closely-related
Secure Sockets Layer (SSL) are widely used for securing HTTP-based
communication, and thus can provide support for most XML- and
SOAP-based device management approaches.
- Transport Layer Security (TLS) [RFC2246] and the closely-related Secure Sockets Layer (SSL) are widely used for securing HTTP-based communication, and thus can provide support for most XML- and SOAP-based device management approaches.
- As of 2004, extensive work is proceeding in several organizations
(OASIS, W3C, WS-I, and others) on securing device management
traffic within a "Web Services" framework. This work uses a wide
variety of security models and supports multiple security token
formats, multiple trust domains, multiple signature formats, and
multiple encryption technologies.
- As of 2004, extensive work is proceeding in several organizations (OASIS, W3C, WS-I, and others) on securing device management traffic within a "Web Services" framework. This work uses a wide variety of security models and supports multiple security token formats, multiple trust domains, multiple signature formats, and multiple encryption technologies.
- IPsec provides the services with security and confidentiality at
the network layer. With regard to device management, its current
use is primarily focused on in-band management of user-managed
IPsec gateway devices.
- IPsec provides the services with security and confidentiality at the network layer. With regard to device management, its current use is primarily focused on in-band management of user-managed IPsec gateway devices.
Fang Informational [Page 15] RFC 4111 PPVPN Security Framework July 2005
Fang Informational [Page 15] RFC 4111 PPVPN Security Framework July 2005
5.1.3. Cryptographic Techniques in Layer-2 PPVPNs
5.1.3. Cryptographic Techniques in Layer-2 PPVPNs
Layer-2 PPVPNs will generally not be able to use IPsec to provide encryption throughout the entire network. They may be able to use IPsec for PE-PE traffic where it is encapsulated in IP packets, but IPsec will generally not be applicable for CE-PE traffic in Layer-2 PPVPNs.
Layer-2 PPVPNs will generally not be able to use IPsec to provide encryption throughout the entire network. They may be able to use IPsec for PE-PE traffic where it is encapsulated in IP packets, but IPsec will generally not be applicable for CE-PE traffic in Layer-2 PPVPNs.
Encryption techniques for Layer-2 links are widely available but are not within the scope of this document or IETF documents in general. Layer-2 encryption could be applied to the links from CE to PE, or it could be applied from CE to CE, as long as the encrypted Layer-2 packets can be handled properly by the intervening PE devices. In addition, the upper-layer traffic transported by the Layer-2 VPN can be encrypted by the user. In this case, confidentiality will be maintained; however, this is transparent to the PPVPN provider and is outside the scope of this document.
Encryption techniques for Layer-2 links are widely available but are not within the scope of this document or IETF documents in general. Layer-2 encryption could be applied to the links from CE to PE, or it could be applied from CE to CE, as long as the encrypted Layer-2 packets can be handled properly by the intervening PE devices. In addition, the upper-layer traffic transported by the Layer-2 VPN can be encrypted by the user. In this case, confidentiality will be maintained; however, this is transparent to the PPVPN provider and is outside the scope of this document.
5.1.4. End-to-End vs. Hop-by-Hop Encryption Tradeoffs in PPVPNs
5.1.4. End-to-End vs. Hop-by-Hop Encryption Tradeoffs in PPVPNs
In PPVPNs, encryption could potentially be applied to the VPN traffic at several different places. This section discusses some of the tradeoffs in implementing encryption in several different connection topologies among different devices within a PPVPN.
In PPVPNs, encryption could potentially be applied to the VPN traffic at several different places. This section discusses some of the tradeoffs in implementing encryption in several different connection topologies among different devices within a PPVPN.
Encryption typically involves a pair of devices that encrypt the traffic passing between them. The devices may be directly connected (over a single "hop"), or there may be intervening devices that transport the encrypted traffic between the pair of devices. The extreme cases involve hop-by-hop encryption between every adjacent pair of devices along a given path or "end-to-end" encryption only between the end devices along a given path. To keep this discussion within the scope of PPVPNs, we consider the "end to end" case to be CE to CE rather than fully end to end.
Encryption typically involves a pair of devices that encrypt the traffic passing between them. The devices may be directly connected (over a single "hop"), or there may be intervening devices that transport the encrypted traffic between the pair of devices. The extreme cases involve hop-by-hop encryption between every adjacent pair of devices along a given path or "end-to-end" encryption only between the end devices along a given path. To keep this discussion within the scope of PPVPNs, we consider the "end to end" case to be CE to CE rather than fully end to end.
Figure 2 depicts a simplified PPVPN topology, showing the Customer Edge (CE) devices, the Provider Edge (PE) devices, and a variable number (three are shown) of Provider core (P) devices that might be present along the path between two sites in a single VPN, operated by a single service provider (SP).
Figure 2 depicts a simplified PPVPN topology, showing the Customer Edge (CE) devices, the Provider Edge (PE) devices, and a variable number (three are shown) of Provider core (P) devices that might be present along the path between two sites in a single VPN, operated by a single service provider (SP).
Site_1---CE---PE---P---P---P---PE---CE---Site_2
Site_1---CE---PE---P---P---P---PE---CE---Site_2
Figure 2: Simplified PPVPN topology
Figure 2: Simplified PPVPN topology
Fang Informational [Page 16] RFC 4111 PPVPN Security Framework July 2005
Fang Informational [Page 16] RFC 4111 PPVPN Security Framework July 2005
Within this simplified topology and assuming that P devices are not to be involved with encryption, there are four basic feasible configurations for implementing encryption on connections among the devices:
Within this simplified topology and assuming that P devices are not to be involved with encryption, there are four basic feasible configurations for implementing encryption on connections among the devices:
1) Site-to-site (CE-to-CE): Encryption can be configured between
the two CE devices, so that traffic will be encrypted
throughout the SP's network.
1) Site-to-site (CE-to-CE): Encryption can be configured between the two CE devices, so that traffic will be encrypted throughout the SP's network.
2) Provider edge-to-edge (PE-to-PE): Encryption can be configured
between the two PE devices. Unencrypted traffic is received at
one PE from the customer's CE; then it is encrypted for
transmission through the SP's network to the other PE, where it
is decrypted and sent to the other CE.
2) Provider edge-to-edge (PE-to-PE): Encryption can be configured between the two PE devices. Unencrypted traffic is received at one PE from the customer's CE; then it is encrypted for transmission through the SP's network to the other PE, where it is decrypted and sent to the other CE.
3) Access link (CE-to-PE): Encryption can be configured between
the CE and PE, on each side (or on only one side).
3) Access link (CE-to-PE): Encryption can be configured between the CE and PE, on each side (or on only one side).
4) Configurations 2) and 3) can be combined, with encryption
running from CE to PE, then from PE to PE, and then from PE to
CE.
4) Configurations 2) and 3) can be combined, with encryption running from CE to PE, then from PE to PE, and then from PE to CE.
Among the four feasible configurations, key tradeoffs in considering encryption include the following:
Among the four feasible configurations, key tradeoffs in considering encryption include the following:
- Vulnerability to link eavesdropping: Assuming that an attacker can
observe the data in transit on the links, would it be protected by
encryption?
- Vulnerability to link eavesdropping: Assuming that an attacker can observe the data in transit on the links, would it be protected by encryption?
- Vulnerability to device compromise: Assuming an attacker can get
access to a device (or freely alter its configuration), would the
data be protected?
- Vulnerability to device compromise: Assuming an attacker can get access to a device (or freely alter its configuration), would the data be protected?
- Complexity of device configuration and management: Given Nce, the
number of sites per VPN customer, and Npe, the number of PEs
participating in a given VPN, how many device configurations have
to be created or maintained and how do those configurations scale?
- Complexity of device configuration and management: Given Nce, the number of sites per VPN customer, and Npe, the number of PEs participating in a given VPN, how many device configurations have to be created or maintained and how do those configurations scale?
- Processing load on devices: How many encryption or decryption
operations must be done, given P packets? This influences
considerations of device capacity and perhaps end-to-end delay.
- Processing load on devices: How many encryption or decryption operations must be done, given P packets? This influences considerations of device capacity and perhaps end-to-end delay.
- Ability of SP to provide enhanced services (QoS, firewall,
intrusion detection, etc.): Can the SP inspect the data in order
to provide these services?
- Ability of SP to provide enhanced services (QoS, firewall, intrusion detection, etc.): Can the SP inspect the data in order to provide these services?
These tradeoffs are discussed below for each configuration.
These tradeoffs are discussed below for each configuration.
Fang Informational [Page 17] RFC 4111 PPVPN Security Framework July 2005
Fang Informational [Page 17] RFC 4111 PPVPN Security Framework July 2005
1) Site-to-site (CE-to-CE) Configurations
1) Site-to-site (CE-to-CE) Configurations
o Link eavesdropping: Protected on all links.
o Link eavesdropping: Protected on all links.
o Device compromise: Vulnerable to CE compromise.
o Device compromise: Vulnerable to CE compromise.
o Complexity: Single administration, responsible for one device
per site (Nce devices), but overall configuration per VPN
scales as Nce**2.
o Complexity: Single administration, responsible for one device per site (Nce devices), but overall configuration per VPN scales as Nce**2.
o Processing load: on each of two CEs, each packet is either
encrypted or decrypted (2P).
o Processing load: on each of two CEs, each packet is either encrypted or decrypted (2P).
o Enhanced services: Severely limited; typically only DiffServ
markings are visible to SP, allowing some QoS services.
o Enhanced services: Severely limited; typically only DiffServ markings are visible to SP, allowing some QoS services.
2) Provider edge-to-edge (PE-to-PE) Configurations
2) Provider edge-to-edge (PE-to-PE) Configurations
o Link eavesdropping: Vulnerable on CE-PE links; protected on
SP's network links.
o Link eavesdropping: Vulnerable on CE-PE links; protected on SP's network links.
o Device compromise: Vulnerable to CE or PE compromise.
o Device compromise: Vulnerable to CE or PE compromise.
o Complexity: Single administration; Npe devices to configure.
(Multiple sites may share a PE device, so Npe is typically much
less than Nce.) Scalability of the overall configuration
depends on the PPVPN type: If the encryption is separate per
VPN context, it scales as Npe**2 per customer VPN. If the
encryption is per PE, it scales as Npe**2 for all customer VPNs
combined.
o Complexity: Single administration; Npe devices to configure. (Multiple sites may share a PE device, so Npe is typically much less than Nce.) Scalability of the overall configuration depends on the PPVPN type: If the encryption is separate per VPN context, it scales as Npe**2 per customer VPN. If the encryption is per PE, it scales as Npe**2 for all customer VPNs combined.
o Processing load: On each of two PEs, each packet is either
encrypted or decrypted (2P).
o Processing load: On each of two PEs, each packet is either encrypted or decrypted (2P).
o Enhanced services: Full; SP can apply any enhancements based on
detailed view of traffic.
o Enhanced services: Full; SP can apply any enhancements based on detailed view of traffic.
3) Access link (CE-to-PE) Configuration
3) Access link (CE-to-PE) Configuration
o Link eavesdropping: Protected on CE-PE link; vulnerable on SP's
network links.
o Link eavesdropping: Protected on CE-PE link; vulnerable on SP's network links.
o Device compromise: Vulnerable to CE or PE compromise.
o Device compromise: Vulnerable to CE or PE compromise.
o Complexity: Two administrations (customer and SP) with device
configuration on each side (Nce + Npe devices to configure),
but as there is no mesh, the overall configuration scales as
Nce.
o Complexity: Two administrations (customer and SP) with device configuration on each side (Nce + Npe devices to configure), but as there is no mesh, the overall configuration scales as Nce.
Fang Informational [Page 18] RFC 4111 PPVPN Security Framework July 2005
Fang Informational [Page 18] RFC 4111 PPVPN Security Framework July 2005
o Processing load: On each of two CEs, each packet is either
encrypted or decrypted. On each of two PEs, each packet is
either encrypted or decrypted (4P).
o Processing load: On each of two CEs, each packet is either encrypted or decrypted. On each of two PEs, each packet is either encrypted or decrypted (4P).
o Enhanced services: Full; SP can apply any enhancements based on
detailed view of traffic.
o Enhanced services: Full; SP can apply any enhancements based on detailed view of traffic.
4) Combined Access link and PE-to-PE (essentially hop-by-hop).
4) Combined Access link and PE-to-PE (essentially hop-by-hop).
o Link eavesdropping: Protected on all links.
o Link eavesdropping: Protected on all links.
o Device compromise: Vulnerable to CE or PE compromise.
o Device compromise: Vulnerable to CE or PE compromise.
o Complexity: Two administrations (customer and SP), with device
configuration on each side (Nce + Npe devices to configure).
Scalability of the overall configuration depends on the PPVPN
type. If the encryption is separate per VPN context, it scales
as Npe**2 per customer VPN. If the encryption is per-PE, it
scales as Npe**2 for all customer VPNs combined.
o Complexity: Two administrations (customer and SP), with device configuration on each side (Nce + Npe devices to configure). Scalability of the overall configuration depends on the PPVPN type. If the encryption is separate per VPN context, it scales as Npe**2 per customer VPN. If the encryption is per-PE, it scales as Npe**2 for all customer VPNs combined.
o Processing load: On each of two CEs, each packet is either
encrypted or decrypted. On each of two PEs, each packet is
both encrypted and decrypted (6P).
o Processing load: On each of two CEs, each packet is either encrypted or decrypted. On each of two PEs, each packet is both encrypted and decrypted (6P).
o Enhanced services: Full; SP can apply any enhancements based on
detailed view of traffic.
o Enhanced services: Full; SP can apply any enhancements based on detailed view of traffic.
Given the tradeoffs discussed above, a few conclusions can be reached.
Given the tradeoffs discussed above, a few conclusions can be reached.
- Configurations 2 and 3, which are subsets of 4, may be appropriate
alternatives to 4 under certain threat models. The remainder of
these conclusions compare 1 (CE-to-CE) with 4 (combined access
links and PE-to-PE).
- Configurations 2 and 3, which are subsets of 4, may be appropriate alternatives to 4 under certain threat models. The remainder of these conclusions compare 1 (CE-to-CE) with 4 (combined access links and PE-to-PE).
- If protection from link eavesdropping is most important, then
configurations 1 and 4 are equivalent.
- If protection from link eavesdropping is most important, then configurations 1 and 4 are equivalent.
- If protection from device compromise is most important and the
threat is to the CE devices, both cases are equivalent; if the
threat is to the PE devices, configuration 1 is best.
- If protection from device compromise is most important and the threat is to the CE devices, both cases are equivalent; if the threat is to the PE devices, configuration 1 is best.
- If reducing complexity is most important and the size of the
network is very small, configuration 1 is the best. Otherwise,
the comparison between options 1 and 4 is relatively complex ,
based on a number of issues such as, how close the CE to CE
communication is to a full mesh, and what tools are used for key
management. Option 1 requires configuring keys for each CE-CE
- If reducing complexity is most important and the size of the network is very small, configuration 1 is the best. Otherwise, the comparison between options 1 and 4 is relatively complex , based on a number of issues such as, how close the CE to CE communication is to a full mesh, and what tools are used for key management. Option 1 requires configuring keys for each CE-CE
Fang Informational [Page 19] RFC 4111 PPVPN Security Framework July 2005
Fang Informational [Page 19] RFC 4111 PPVPN Security Framework July 2005
pair that is communicating directly. Option 4 requires
configuring keys on both CE and PE devices but may offer benefit
from the fact that the number of PEs is generally much smaller
than the number of CEs.
pair that is communicating directly. Option 4 requires configuring keys on both CE and PE devices but may offer benefit from the fact that the number of PEs is generally much smaller than the number of CEs.
Also, under some PPVPN approaches, the scaling of 4 is further
improved by sharing the same PE-PE mesh across all VPN contexts.
The scaling characteristics of 4 may be increased or decreased in
any given situation if the CE devices are simpler to configure
than the PE devices, or vice versa. Furthermore, with option 4,
the impact of operational error may be significantly increased.
Also, under some PPVPN approaches, the scaling of 4 is further improved by sharing the same PE-PE mesh across all VPN contexts. The scaling characteristics of 4 may be increased or decreased in any given situation if the CE devices are simpler to configure than the PE devices, or vice versa. Furthermore, with option 4, the impact of operational error may be significantly increased.
- If the overall processing load is a key factor, then 1 is best.
- If the overall processing load is a key factor, then 1 is best.
- If the availability of enhanced services support from the SP is
most important, then 4 is best.
- If the availability of enhanced services support from the SP is most important, then 4 is best.
As a quick overall conclusion, CE-to-CE encryption provides greater protection against device compromise, but it comes at the cost of enhanced services and with additional operational complexity due to the Order(n**2) scaling of the mesh.
As a quick overall conclusion, CE-to-CE encryption provides greater protection against device compromise, but it comes at the cost of enhanced services and with additional operational complexity due to the Order(n**2) scaling of the mesh.
This analysis of site-to-site vs. hop-by-hop encryption tradeoffs does not explicitly include cases where multiple providers cooperate to provide a PPVPN service, public Internet VPN connectivity, or remote access VPN service, but many of the tradeoffs will be similar.
This analysis of site-to-site vs. hop-by-hop encryption tradeoffs does not explicitly include cases where multiple providers cooperate to provide a PPVPN service, public Internet VPN connectivity, or remote access VPN service, but many of the tradeoffs will be similar.
5.2. Authentication
5.2. Authentication
In order to prevent security issues from some denial-of-service attacks or from malicious misconfiguration, it is critical that devices in the PPVPN should only accept connections or control messages from valid sources. Authentication refers to methods for ensuring that message sources are properly identified by the PPVPN devices with which they communicate. This section focuses on identifying the scenarios in which sender authentication is required, and it recommends authentication mechanisms for these scenarios.
In order to prevent security issues from some denial-of-service attacks or from malicious misconfiguration, it is critical that devices in the PPVPN should only accept connections or control messages from valid sources. Authentication refers to methods for ensuring that message sources are properly identified by the PPVPN devices with which they communicate. This section focuses on identifying the scenarios in which sender authentication is required, and it recommends authentication mechanisms for these scenarios.
Cryptographic techniques (authentication and encryption) do not protect against some types of denial-of-service attacks, specifically, resource exhaustion attacks based on CPU or bandwidth exhaustion. In fact, the processing required to decrypt or check authentication may in some cases increase the effect of these resource exhaustion attacks. Cryptographic techniques may, however, be useful against resource exhaustion attacks based on exhaustion of state information (e.g., TCP SYN attacks).
Cryptographic techniques (authentication and encryption) do not protect against some types of denial-of-service attacks, specifically, resource exhaustion attacks based on CPU or bandwidth exhaustion. In fact, the processing required to decrypt or check authentication may in some cases increase the effect of these resource exhaustion attacks. Cryptographic techniques may, however, be useful against resource exhaustion attacks based on exhaustion of state information (e.g., TCP SYN attacks).
Fang Informational [Page 20] RFC 4111 PPVPN Security Framework July 2005
Fang Informational [Page 20] RFC 4111 PPVPN Security Framework July 2005
5.2.1. VPN Member Authentication
5.2.1. VPN Member Authentication
This category includes techniques for the CEs to verify that they are connected to the expected VPN. It includes techniques for CE-PE authentication, to verify that each specific CE and PE is actually communicating with its expected peer.
CEsが、彼らが予想されたVPNに接続されることを確かめるように、このカテゴリはテクニックを含んでいます。 それは、各特定のCEとPEが実際に予想された同輩とコミュニケートしていることを確かめるためにCE-PE認証のためのテクニックを含んでいます。
5.2.2. Management System Authentication
5.2.2. 管理システム認証
Management system authentication includes the authentication of a PE to a centrally-managed directory server when directory-based "auto- discovery" is used. It also includes authentication of a CE to its PPVPN configuration server when a configuration server system is used.
ディレクトリベースの「自動発見」が使用されているとき、管理システム認証は中心で管理されたディレクトリサーバにPEの認証を含んでいます。 また、構成サーバシステムが使用されているとき、それはPPVPN構成サーバにCEの認証を含めます。
5.2.3. Peer-to-Peer Authentication
5.2.3. ピアツーピア認証
Peer-to-peer authentication includes peer authentication for network control protocols (e.g., LDP, BGP), and other peer authentication (i.e., authentication of one IPsec security gateway by another).
ピアツーピア認証はネットワーク制御プロトコル(例えば、自由民主党、BGP)のための同輩認証、および他の同輩認証(すなわち、別のものによる1IPsecセキュリティ門の認証)を含んでいます。
5.2.4. Authenticating Remote Access VPN Members
5.2.4. 遠隔アクセスのVPNメンバーを認証します。
This section describes methods for authentication of remote access users connecting to a VPN.
このセクションはVPNに接続する遠隔アクセスのユーザの認証のためのメソッドを説明します。
Effective authentication of individual connections is a key requirement for enabling remote access to a PPVPN from an arbitrary Internet address (for instance, by a traveler).
個々の接続の有効な認証は、任意のインターネット・アドレス(例えば旅行者で)から遠隔アクセスをPPVPNに可能にするための主要な要件です。
There are several widely used standards-based protocols to support remote access authentication. These include RADIUS [RFC2865] and DIAMETER [RFC3588]. Digital certificate systems also provide authentication. In addition, there has been extensive development and deployment of mechanisms for securely transporting individual remote access connections within tunneling protocols, including L2TP [RFC2661] and IPsec.
リモートアクセスが認証であるとサポートするために、いくつかの広く使用された規格ベースのプロトコルがあります。 これらはRADIUS[RFC2865]とDIAMETER[RFC3588]を含んでいます。 また、デジタル証明書システムは認証を提供します。 さらに、トンネリングプロトコルの中でしっかりと個々の遠隔アクセスの接続を輸送するためのメカニズムの大規模な開発と展開がありました、L2TP[RFC2661]とIPsecを含んでいて。
Remote access involves connection to a gateway device, which provides access to the PPVPN. The gateway device may be managed by the user at a user site, or by the PPVPN provider at any of several possible locations in the network. The user-managed case is of limited interest within the PPVPN security framework, and it is not considered at this time.
遠隔アクセスはゲートウェイデバイスに接続を伴います。(それは、PPVPNへのアクセスを提供します)。 ゲートウェイデバイスはユーザの現場のユーザ、またはネットワークにおける数個の可能な位置のどれかのPPVPNプロバイダーによって管理されるかもしれません。 ユーザによって管理されたケースはPPVPNセキュリティフレームワークの中で限られておもしろいです、そして、それはこのとき、考えられません。
When a PPVPN provider manages authentication at the remote access gateway, this implies that authentication databases, which are usually extremely confidential user-managed systems, will have to be
PPVPNプロバイダーが遠隔アクセスのゲートウェイで認証を管理すると、これは、認証データベース(通常非常に秘密のユーザによって管理されたシステムである)がそうしなければならないのを含意します。
Fang Informational [Page 21] RFC 4111 PPVPN Security Framework July 2005
[21ページ]RFC4111PPVPNセキュリティフレームワーク2005年7月の情報の牙
referenced in a secure manner by the PPVPN provider. This can be accomplished through proxy authentication services, which accept an encrypted authentication credential from the remote access user, pass it to the PPVPN user's authentication system, and receive a yes/no response as to whether the user has been authenticated. Thus, the PPVPN provider does not have access to the actual authentication database, but it can use it on behalf of the PPVPN user to provide remote access authentication.
安全な方法で、PPVPNプロバイダーによって参照をつけられます。 プロキシ認証サービスでこれを達成できます。(認証サービスは、暗号化認証が遠隔アクセスのユーザから資格証明であると受け入れて、PPVPNユーザの認証システムにそれを通過して、ユーザが認証されたかどうかに関してはい/いいえ応答を受けます)。 したがって、PPVPNプロバイダーは実際の認証データベースに近づく手段を持っていませんが、それは、遠隔アクセスの認証を提供するのにPPVPNユーザを代表してそれを使用できます。
Specific cryptographic techniques for handling authentication are described in the following sections.
取り扱い認証のための特定の暗号のテクニックは以下のセクションで説明されます。
5.2.5. Cryptographic Techniques for Authenticating Identity
5.2.5. アイデンティティを認証するための暗号のテクニック
Cryptographic techniques offer several mechanisms for authenticating the identity of devices or individuals. These include the use of shared secret keys, one-time keys generated by accessory devices or software, user-ID and password pairs, and a range of public-private key systems. Another approach is to use a hierarchical Certificate Authority system to provide digital certificates.
暗号のテクニックは、デバイスか個人のアイデンティティを認証するために数個のメカニズムを提供します。 これらは共有された秘密鍵、アクセサリーデバイスかソフトウェアと、ユーザIDとパスワード組によって生成された、1回のキー、およびさまざまな公共の秘密鍵システムの使用を含んでいます。別のアプローチはデジタル証明書を提供するのに階層的なCertificate Authorityシステムを使用することです。
This section describes or provides references to the specific cryptographic approaches for authenticating identity. These approaches provide secure mechanisms for most of the authentication scenarios required in operating a PPVPN.
このセクションは、特定の暗号のアプローチのアイデンティティを認証する参照を説明するか、または提供します。 これらのアプローチはPPVPNを操作するのにおいて必要である認証シナリオの大部分に安全なメカニズムを提供します。
5.3. Access Control Techniques
5.3. アクセス制御のテクニック
Access control techniques include packet-by-packet or packet flow - by - packet flow access control by means of filters and firewalls, as well as by means of admitting a "session" for a control/signaling/management protocol that is being used to implement PPVPNs. Enforcement of access control by isolated infrastructure addresses is discussed elsewhere in this document.
テクニックがパケットごとに含むコントロールかパケット流動にアクセスしてください--フィルタとファイアウォールによるコントロール/シグナリング/経営者側がそれについて議定書の中で述べるので「セッション」がPPVPNsを実装するのに使用されていることを認めることによるパケット流れアクセスコントロール。 ほかの場所で本書では孤立しているインフラストラクチャアドレスによるアクセスコントロールの実施について議論します。
We distinguish between filtering and firewalls primarily by the direction of traffic flow. We define filtering as being applicable to unidirectional traffic, whereas a firewall can analyze and control both sides of a conversation.
私たちは主として交通の流れの方向でフィルタリングとファイアウォールを見分けます。 私たちは単方向のトラフィックに適切であるとフィルタリングを定義します、ファイアウォールが、会話の両側を分析して、制御できますが。
There are two significant corollaries of this definition:
この定義の2つの重要な推論があります:
- Routing or traffic flow symmetry: A firewall typically requires
routing symmetry, which is usually enforced by locating a firewall
where the network topology assures that both sides of a
conversation will pass through the firewall. A filter can then
operate upon traffic flowing in one direction without considering
traffic in the reverse direction.
- ルート設定か交通の流れ対称: ファイアウォールは、対称が発送するのを通常必要とします。(通常、対称は、ネットワーク形態が、会話の両側がファイアウォールを通り抜けることを保証するファイアウォールの場所を見つけることによって、励行されます)。 そして、フィルタは反対の方向とトラフィックを考えないで一方向に流れた状態でトラフィックを作動させることができます。
Fang Informational [Page 22] RFC 4111 PPVPN Security Framework July 2005
[22ページ]RFC4111PPVPNセキュリティフレームワーク2005年7月の情報の牙
- Statefulness: Because it receives both sides of a conversation, a
firewall may be able to obtain a significant amount of information
concerning that conversation and to use this information to
control access. A filter can maintain some limited state
information on a unidirectional flow of packets, but it cannot
determine the state of the bi-directional conversation as
precisely as a firewall can.
- Statefulness: 会話の両側を受けるので、ファイアウォールは、その会話に関して重要な情報量を得て、アクセサリーを制御するのにこの情報を使用できるかもしれません。 フィルタはパケットの単方向の流動の何らかの限られた州の情報を保守できますが、それはファイアウォールがそうすることができるくらい正確に双方向の会話の状態を決定できません。
5.3.1. Filtering
5.3.1. フィルタリング
It is relatively common for routers to filter data packets. That is, routers can look for particular values in certain fields of the IP or higher level (e.g., TCP or UDP) headers. Packets that match the criteria associated with a particular filter may be either discarded or given special treatment.
ルータがデータ・パケットをフィルターにかけるのは、比較的一般的です。 すなわち、ルータはIPか、より高い平らな(例えば、TCPかUDP)ヘッダーのある一定の分野で特定の値を探すことができます。 特定のフィルタに関連している評価基準に合っているパケットは、捨てるか、または特別な処理を与えるかもしれません。
In discussing filters, it is useful to separate the filter characteristics that may be used to determine whether a packet matches a filter from the packet actions that are applied to packets that match a particular filter.
フィルタについて議論する際に、パケットが特定のフィルタに合っているパケットに適用されるパケット動作からフィルタに合っているかどうか決定するのに使用されるかもしれないフィルター特性を切り離すのは役に立ちます。
o Filter Characteristics
o フィルター特性
Filter characteristics are used to determine whether a particular
packet or set of packets matches a particular filter.
フィルター特性は、特定のパケットか1セットのパケットが特定のフィルタに合っているかどうか決定するのに使用されます。
In many cases, filter characteristics may be stateless. A
stateless filter determines whether a particular packet matches a
filter based solely on the filter definition, on normal forwarding
information (such as the next hop for a packet), and on the
characteristics of that individual packet. Typically, stateless
filters may consider the incoming and outgoing logical or physical
interface, information in the IP header, and information in higher
layer headers such as the TCP or UDP header. Information in the
IP header to be considered may, for example, include source and
destination IP address, Protocol field, Fragment Offset, and TOS
field. Filters may also consider fields in the TCP or UDP header
such as the Port fields and the SYN field in the TCP header.
多くの場合、フィルター特性は状態がないかもしれません。 状態がないフィルタは、特定のパケットが唯一フィルター定義と、そして、正常な推進情報(パケットのための次のホップなどの)と、そして、その個々のパケットの特性に基づくフィルタに合っているかどうか決定します。 通常、状態がないフィルタはTCPかUDPヘッダーの送受信の論理的であるか物理的なインタフェース、IPヘッダーの情報、および、より高い層のヘッダーの情報を考えるかもしれません。 例えば、考えられるIPヘッダーの情報はソース、送付先IPアドレス、プロトコル分野、Fragment Offset、およびTOS分野を含むかもしれません。 また、フィルタは、TCPかUDPヘッダーのPortなどの分野が分野とTCPヘッダーのSYN分野であると考えるかもしれません。
Stateful filtering maintains packet-specific state information to
aid in determining whether a filter has been met. For example, a
device might apply stateless filters to the first fragment of a
fragmented IP packet. If the filter matches, then the data unit
ID may be remembered, and other fragments of the same packet may
then be considered to match the same filter. Stateful filtering
is more commonly done in firewalls, although firewall technology
may be added to routers.
Statefulフィルタリングは、フィルタが触れられたかどうか決定する際に支援するためにパケット特有の州の情報を保守します。 例えば、デバイスは断片化しているIPパケットの最初の断片に状態がないフィルタを適用するかもしれません。 フィルタが合っているなら、データ単位IDは覚えていられるかもしれません、そして、次に、同じパケットの他の断片が同じフィルタに合っていると考えられるかもしれません。 ファイアウォール技術をルータに加えるかもしれませんが、ファイアウォールで、より一般的にStatefulフィルタリングをします。
Fang Informational [Page 23] RFC 4111 PPVPN Security Framework July 2005
[23ページ]RFC4111PPVPNセキュリティフレームワーク2005年7月の情報の牙
o Actions Based on Filter Results
o フィルタ結果に基づく動作
If a packet, or a series of packets, match a specific filter, then
there are a variety of actions that may be taken based on that
filter match. Examples of such actions include:
パケット、または一連のパケットが特定のフィルタに合っているなら、そのフィルタマッチに基づいて取られるかもしれないさまざまな行動があります。 そのような動作に関する例は:
- Discard
- 破棄
In many cases, filters may be set to catch certain undesirable
packets. Examples may include packets with forged or invalid
source addresses, packets that are part of a DoS or DDoS
attack, or packets that are trying to access forbidden
resources (such as network management packets from an
unauthorized source). Where such filters are activated, it is
common to silently discard the packet or set of packets
matching the filter. The discarded packets may also be counted
and/or logged, of course.
多くの場合、フィルタが、ある望ましくないパケットを捕らえるように設定されるかもしれません。 例は禁制のリソースにアクセスしようとしている偽造しているか無効のソースアドレス、DoSの一部であるパケット、DDoS攻撃、またはパケット(権限のないソースからのネットワークマネージメントパケットなどの)があるパケットを含むかもしれません。 そのようなフィルタが活性であるところでは、静かにフィルタに合っているパケットのパケットかセットを捨てるのは一般的です。 また、捨てられたパケットが数えられる、そして/または、登録されるかもしれない、もちろん。
- Set CoS
- CoSを設定してください。
A filter may be used to set the Class of Service associated
with the packet.
フィルタは、パケットに関連しているServiceのClassを設定するのに使用されるかもしれません。
- Count Packets and/or Bytes
- パケット、そして/または、バイトを数えてください。
- Rate Limit
- レート限界
In some cases, the set of packets that match a particular
filter may be limited to a specified bandwidth. Packets and/or
bytes would be counted and forwarded normally up to the
specified limit. Excess packets may be discarded or marked
(for example, by setting a "discard eligible" bit in the IP ToS
field or the MPLS EXP field).
いくつかの場合、特定のフィルタに合っているパケットのセットは指定された帯域幅に制限されるかもしれません。 通常、パケット、そして/または、バイトを指定限界まで数えて、進めるでしょう。 余分なパケットは、捨てられるか、またはマークされるかもしれません(例えばIP ToS分野かMPLS EXP分野に「廃棄適性」ビットをはめ込むことによって)。
- Forward and Copy
- フォワードとコピー
It is useful in some cases not only to forward some set of
packets normally, but also to send a copy to a specified other
address or interface. For example, this may be used to
implement a lawful intercept capability, or to feed selected
packets to an Intrusion Detection System.
いくつかの場合、単に通常何らかのセットのパケットを進めるのではなく、指定された他のアドレスかインタフェースにコピーを送りもするのも役に立ちます。 例えば、これは、合法的なインタセプト能力を実装するか、または選択されたパケットをIntrusion Detection Systemに提供するのに使用されるかもしれません。
o Other Issues Related to Packet Filters
o パケットフィルタに関連する他の問題
There may be a very wide variation in the performance impact of
filtering. This may occur both due to differences between
implementations, and due to differences between types or numbers
フィルタリングの性能影響の非常に広い変化があるかもしれません。 これは実装の違いのためと、タイプか数の違いのため起こるかもしれません。
Fang Informational [Page 24] RFC 4111 PPVPN Security Framework July 2005
[24ページ]RFC4111PPVPNセキュリティフレームワーク2005年7月の情報の牙
of filters deployed. For filtering to be useful, the performance
of the equipment has to be acceptable in the presence of filters.
配布されたフィルタについて。 フィルタリングが役に立つように、設備の性能はフィルタがあるとき許容していなければなりません。
The precise definition of "acceptable" may vary from service
provider to service provider and may depend on the intended use of
the filters. For example, for some uses a filter may be turned on
all the time in order to set CoS, to prevent an attack, or to
mitigate the effect of a possible future attack. In this case it
is likely that the service provider will want the filter to have
minimal or no impact on performance. In other cases, a filter may
be turned on only in response to a major attack (such as a major
DDoS attack). In this case a greater performance impact may be
acceptable to some service providers.
「許容できること」の厳密な定義は、サービスプロバイダーによって異なって、フィルタの意図している使用によるかもしれません。 例えば、いくつかの用途において、フィルタは、絶えず、攻撃を防ぐか、または可能な今後の攻撃の効果を緩和するためにCoSを設定するためにつけられるかもしれません。 この場合、最小量にするフィルタが欲しいのですが、サービスプロバイダーはどんな影響も性能に必要としそうにないでしょう。 他の場合では、単に大規模な攻撃(主要なDDoS攻撃などの)に対応してフィルタはつけられるかもしれません。 この場合、よりすばらしい性能影響はいくつかのサービスプロバイダーに許容しているかもしれません。
A key consideration with the use of packet filters is that they
can provide few options for filtering packets carrying encrypted
data. Because the data itself is not accessible, only packet
header information or other unencrypted fields can be used for
filtering.
パケットフィルタの使用による重要な考慮すべき事柄は暗号化されたデータを運びながらパケットをフィルターにかけるためのわずかなオプションしか提供できないということです。 データ自体がアクセス可能でないので、フィルタリングにパケットヘッダー情報か他の非暗号化された分野しか使用できません。
5.3.2. Firewalls
5.3.2. ファイアウォール
Firewalls provide a mechanism for control over traffic passing between different trusted zones in the PPVPN model, or between a trusted zone and an untrusted zone. Firewalls typically provide much more functionality than filters, as they may be able to apply detailed analysis and logical functions to flows and not just to individual packets. They may offer a variety of complex services, such as threshold-driven denial-of-service attack protection, virus scanning, or acting as a TCP connection proxy. As with other access control techniques, the value of firewalls depends on a clear understanding of the topologies of the PPVPN core network, the user networks, and the threat model. Their effectiveness depends on a topology with a clearly defined inside (secure) and outside (not secure).
ファイアウォールは、PPVPNモデルの異なった信じられたゾーンの間、または、信じられたゾーンと信頼されていないゾーンの間を通りながら、トラフィックの上でメカニズムをコントロールに提供します。 ファイアウォールはフィルタよりはるかに多くの機能性を通常提供します、個々のパケットだけではなく、流れに詳細に渡る分析と論理関数を適用できるとき。 彼らはさまざまな複雑なサービスを提供するかもしれません、TCP接続プロキシとしての敷居駆動のサービス不能攻撃保護、ウイルススキャン、または芝居などのように。 他のアクセス制御方法のように、ファイアウォールの値はPPVPNコアネットワーク、ユーザネットワーク、および脅威モデルのtopologiesの明確な理解に依存します。 それらの有効性は(安全)である内部が明確に定義されているトポロジーの上と外で(安全でない)で依存します。
Within the PPVPN framework, traffic typically is not allowed to pass between the various user VPNs. This inter-VPN isolation is usually not performed by a firewall, but it is a part of the basic VPN mechanism. An exception to the total isolation of VPNs is the case of "extranets", which allow specific external access to a user's VPN, potentially from another VPN. Firewalls can be used to provide the services required for secure extranet implementation.
PPVPNフレームワークの中では、トラフィックは様々なユーザVPNsの間を通常通ることができません。 この相互VPN分離はファイアウォールによって通常実行されませんが、それは基本的なVPNメカニズムの一部です。 VPNsの総分離への例外は「エクストラネット」に関するケースです。(それは、別のVPNからユーザのVPNへの特定の外部のアクセスを潜在的に許します)。 安全なエクストラネット実装に必要であるサービスを提供するのにファイアウォールを使用できます。
Fang Informational [Page 25] RFC 4111 PPVPN Security Framework July 2005
[25ページ]RFC4111PPVPNセキュリティフレームワーク2005年7月の情報の牙
In a PPVPN, firewalls can be applied between the public Internet and user VPNs, in cases where Internet access services are offered by the provider to the VPN user sites. In addition, firewalls may be applied between VPN user sites and any shared network-based services offered by the PPVPN provider.
PPVPNでは、公共のインターネットとユーザVPNsの間でファイアウォールを適用できます、インターネットアクセス・サービスがプロバイダーによってVPNユーザの現場に提供される場合で。 さらに、ファイアウォールはVPNユーザの現場とPPVPNプロバイダーによって提供されたどんな共有されたネットワークベースのサービスの間でも適用されるかもしれません。
Firewalls may be applied to help protect PPVPN core network functions from attacks originating from the Internet or from PPVPN user sites, but typically other defensive techniques will be used for this purpose.
ファイアウォールはインターネットから発する攻撃かPPVPNユーザの現場からPPVPNコアネットワーク機能を保護するのを助けるために適用されるかもしれませんが、通常、他の防衛的なテクニックはこのために使用されるでしょう。
Where firewalls are employed as a service to protect user VPN sites from the Internet, different VPN users, and even different sites of a single VPN user, may have varying firewall requirements. The overall PPVPN logical and physical topology, along with the capabilities of the devices implementing the firewall services, will have a significant effect on the feasibility and manageability of such varied firewall service offerings.
ファイアウォールがインターネットからユーザVPNサイトを保護するのにサービスとして使われるところでは、異なったVPNユーザ、および独身のVPNユーザの異なったサイトさえ異なったファイアウォール要件を持っているかもしれません。 総合的なPPVPN論理的で物理的なトポロジーには、実行可能性への重要な効果とそのような様々なファイアウォールサービス提供の管理可能性がデバイスがファイアウォールサービスを実装する能力と共にあるでしょう。
Another consideration with the use of firewalls is that they can provide few options for handling packets carrying encrypted data. As the data itself is not accessible, only packet header information, other unencrypted fields, or analysis of the flow of encrypted packets can be used for making decisions on accepting or rejecting encrypted traffic.
ファイアウォールの使用による別の考慮は暗号化されたデータを運びながら取り扱いパケットのためのわずかなオプションしか提供できないということです。 データ自体がアクセス可能でないので、暗号化されたトラフィックを受け入れるか、または拒絶する決定をするのに暗号化されたパケットの流れのパケットヘッダー情報、他の非暗号化された分野、または分析しか使用できません。
5.3.3. Access Control to Management Interfaces
5.3.3. 管理インタフェースへのアクセスコントロール
Most of the security issues related to management interfaces can be addressed through the use of authentication techniques described in the section on authentication. However, additional security may be provided by controlling access to management interfaces in other ways.
認証のときにセクションで説明された認証のテクニックの使用で管理インタフェースに関連する安全保障問題の大部分を扱うことができます。 しかしながら、他の方法で管理インタフェースへのアクセスを制御することによって、追加担保を提供するかもしれません。
Management interfaces, especially console ports on PPVPN devices, may be configured so that they are only accessible out of band, through a system that is physically or logically separated from the rest of the PPVPN infrastructure.
管理インタフェース(特にPPVPNデバイスの上のコンソールポート)が構成されるかもしれないので、それらは単にバンドからアクセスしやすいです、PPVPNインフラストラクチャの残りと物理的か論理的に切り離されるシステムを通して。
Where management interfaces are accessible in-band within the PPVPN domain, filtering or firewalling techniques can be used to restrict unauthorized in-band traffic from having access to management interfaces. Depending on device capabilities, these filtering or firewalling techniques can be configured either on other devices through which the traffic might pass, or on the individual PPVPN devices themselves.
管理インタフェースがPPVPNドメインの中でバンドでアクセスしやすいところでは、管理インタフェースに近づく手段を持っているのでバンドにおける権限のないトラフィックを制限するのにテクニックをフィルターにかけるか、またはfirewallingするのを使用できます。 デバイス能力によって、トラフィックが終わるかもしれない他のデバイスの上、または、個々のPPVPNデバイス自体の上にテクニックをフィルターにかけるか、またはfirewallingするこれらは構成できます。
Fang Informational [Page 26] RFC 4111 PPVPN Security Framework July 2005
[26ページ]RFC4111PPVPNセキュリティフレームワーク2005年7月の情報の牙
5.4. Use of Isolated Infrastructure
5.4. 孤立しているインフラストラクチャの使用
One way to protect the infrastructure used for support of VPNs is to separate the VPN support resources from the resources used for other purposes (such as support of Internet services). In some cases, this may require the use of physically separate equipment for VPN services, or even a physically separate network.
VPNsのサポートに使用されるインフラストラクチャを保護する1つの方法は他の目的(インターネットのサービスのサポートなどの)のために運用資金とVPN支援資源を切り離すことです。 いくつかの場合、これは肉体的に別々の設備のVPNサービスの使用、または肉体的に別々のネットワークさえ必要とするかもしれません。
For example, PE-based L3 VPNs may be run on a separate backbone not connected to the Internet, or they may use separate edge routers from those used to support Internet service. Private IP addresses (local to the provider and non-routable over the Internet) are sometimes used to provide additional separation.
例えば、PEベースのL3 VPNsがインターネットに関連づけられなかった別々のバックボーンで実行されるかもしれませんか、または彼らはインターネットのサービスをサポートするのに使用されるものから別々の縁のルータを使用するかもしれません。 (プロバイダーへの地方でインターネットの上で非発送可能)のプライベートIPアドレスは、追加分離を提供するのに時々使用されます。
It is common for CE-based L3VPNs to make use of CE devices that are dedicated to one specific VPN. In many or most cases, CE-based VPNs may make use of normal Internet services to interconnect CE devices.
CEベースのL3VPNsが1特定のVPNに捧げられるCEデバイスを利用するのは、一般的です。 多くかほとんどの場合では、CEベースのVPNsは、CEデバイスとインタコネクトするのに正常なインターネットのサービスを利用するかもしれません。
5.5. Use of Aggregated Infrastructure
5.5. 集められたインフラストラクチャの使用
In general it is not feasible to use a completely separate set of resources for support of each VPN. One of the main reasons for VPN services is to allow sharing of resources between multiple users, including multiple VPNs. Thus, even if VPN services make use of a separate network from Internet services, there will still be multiple VPN users sharing the same network resources. In some cases, VPN services will share the use of network resources with Internet services or other services.
一般に、それぞれのVPNのサポートに完全に別々のセットのリソースを使用するのは可能ではありません。 VPNサービスの主な理由の1つは複数のVPNsを含む複数のユーザの間のリソースの共有を許容することです。 したがって、VPNサービスがインターネットのサービスから別々のネットワークを利用しても、それでも、同じネットワーク資源を共有する複数のVPNユーザがいるでしょう。 いくつかの場合、VPNサービスはインターネットのサービスか他のサービスによるネットワーク資源の使用を共有するでしょう。
It is therefore important for VPN services to provide protection between resource use by different VPNs. Thus, a well-behaved VPN user should be protected from possible misbehavior by other VPNs. This requires that limits be placed on the amount of resources that can be used by any one VPN. For example, both control traffic and user data traffic may be rate limited. In some cases or in some parts of the network where a sufficiently large number of queues are available, each VPN (and, optionally, each VPN and CoS within the VPN) may make use of a separate queue. Control-plane resources such as link bandwidth and CPU and memory resources may be reserved on a per-VPN basis.
したがって、VPNサービスが異なったVPNsによるリソース使用の間に保護を提供するのは、重要です。 したがって、品行方正のVPNユーザは他のVPNsによって可能な不正行為から保護されるはずです。 これは、限界がどんなVPNも使用できるリソースの量に置かれるのを必要とします。 例えば、コントロールトラフィックと利用者データトラフィックの両方が制限されたレートであるかもしれません。 いくつかの場合か十分多くの待ち行列が利用可能であるネットワークのいくつかの部分では、各VPN(任意にVPNの中の各VPNとCoS)は別々の待ち行列を利用するかもしれません。 リンク帯域幅やCPUなどの制御飛行機リソースとメモリリソースは1VPNあたり1個のベースで予約されるかもしれません。
The techniques that are used to provision resource protection between multiple VPNs served by the same infrastructure can also be used to protect VPN services from Internet services.
また、インターネットのサービスからVPNサービスを保護するのに同じインフラストラクチャによって役立たれる複数のVPNsの間の支給リソース保護に使用されるテクニックは使用できます。
The use of aggregated infrastructure allows the service provider to benefit from stochastic multiplexing of multiple bursty flows and may
そしてであるかもしれないサービスプロバイダーが集められたインフラストラクチャの使用で複数のbursty流れの推計的なマルチプレクシングの利益を得ることができる。
Fang Informational [Page 27] RFC 4111 PPVPN Security Framework July 2005
[27ページ]RFC4111PPVPNセキュリティフレームワーク2005年7月の情報の牙
also, in some cases, thwart traffic pattern analysis by combining the data from multiple VPNs.
また、いくつかの場合、複数のVPNsからのデータを結合することによって、トラフィックパターン解析を阻んでください。
5.6. Service Provider Quality Control Processes
5.6. サービスプロバイダー品質管理プロセス
Deployment of provider-provisioned VPN services requires a relatively large amount of configuration by the service provider. For example, the service provider has to configure which VPN each site belongs to, as well as QoS and SLA guarantees. This large amount of required configuration leads to the possibility of misconfiguration.
プロバイダーで食糧を供給されたVPNサービスの展開はサービスプロバイダーで比較的多量の構成を必要とします。 例えば、サービスプロバイダーは、各サイトがどのVPNに属すかを構成しなければなりません、QoSとSLA保証と同様に。 この多量の必要な構成がmisconfigurationの可能性につながります。
It is important for the service provider to have operational processes in place to reduce the potential impact of misconfiguration. CE-to-CE authentication may also be used to detect misconfiguration when it occurs.
サービスプロバイダーがmisconfigurationの可能性のある衝撃を減少させるために適所に操作上のプロセスを持っているのは、重要です。 また、起こるとき、CEからCEへの認証は、misconfigurationを検出するのに使用されるかもしれません。
5.7. Deployment of Testable PPVPN Service
5.7. 試験できるPPVPNサービスの展開
This refers to solutions that can readily be tested for correct configuration. For example, for a point-point VPN, checking that the intended connectivity is working largely ensures that there is not connectivity to some unintended site.
これは正しい構成がないかどうか容易にテストできるソリューションを示します。 例えば、ポイント-ポイントVPNがないかどうか意図している接続性が働いているのをチェックするのが何らかの故意でないサイトへの接続性がないのを主に確実にします。
6. Monitoring, Detection, and Reporting of Security Attacks
6. セキュリティー攻撃のモニター、検出、および報告
A PPVPN service may be subject to attacks from a variety of security threats. Many threats are described in another part of this document. Many of the defensive techniques described in this document and elsewhere provide significant levels of protection from a variety of threats. However, in addition to silently employing defensive techniques to protect against attacks, PPVPN services can add value for both providers and customers by implementing security- monitoring systems that detect and report on any security attacks that occur, regardless of whether the attacks are effective.
PPVPNサービスはさまざまな軍事的脅威からの攻撃を受けることがあるかもしれません。 多くの脅威がこのドキュメントの別の部分で説明されます。 本書ではとほかの場所で説明された防衛的なテクニックの多くがさまざまな脅威から有意水準の保護を提供します。 セキュリティ監視システムがそれであると実装することによって攻撃から守るのに静かに防衛的なテクニックを使うことに加えたPPVPNサービスがプロバイダーと顧客の両方のためにどうしたら価値を高めることができても、攻撃が有効であるかどうかにかかわらず起こるあらゆるセキュリティー攻撃に関して、検出して、報告してください。
Attackers often begin by probing and analyzing defenses, so systems that can detect and properly report these early stages of attacks can provide significant benefits.
攻撃者がディフェンスを調べて、分析することによってしばしば始めるので、攻撃のこれらの初期段階を検出して、適切に報告できるシステムは重要な利益を提供できます。
Information concerning attack incidents, especially if available quickly, can be useful in defending against further attacks. It can be used to help identify attackers and their specific targets at an early stage. This knowledge about attackers and targets can be used to further strengthen defenses against specific attacks or attackers, or to improve the defensive services for specific targets on an as- needed basis. Information collected on attacks may also be useful in identifying and developing defenses against novel attack types.
情報は攻撃インシデントに関係がある場合、特に利用可能であるなら、すぐに、さらなる攻撃に対して防御する際に役に立つ場合があります。 初期のときに攻撃者と彼らの特定の目標を特定するのを助けるのにそれを使用できます。 さらに特定の攻撃か攻撃者に対してディフェンスを強化するか、または特定の目標のための防衛的なサービスを改良するのに攻撃者と目標に関するこの知識を使用できる、-、必要な基礎。 また、攻撃のときに集められた情報も目新しい攻撃タイプに対してディフェンスを特定して、開発する際に役に立つかもしれません。
Fang Informational [Page 28] RFC 4111 PPVPN Security Framework July 2005
[28ページ]RFC4111PPVPNセキュリティフレームワーク2005年7月の情報の牙
Monitoring systems used to detect security attacks in PPVPNs will typically operate by collecting information from Provider Edge (PE), Customer Edge (CE), and/or Provider backbone (P) devices. Security monitoring systems should have the ability to actively retrieve information from devices (e.g., SNMP get) or to passively receive reports from devices (e.g., SNMP notifications). The specific information exchanged will depend on the capabilities of the devices and on the type of VPN technology. Particular care should be given to securing the communications channel between the monitoring systems and the PPVPN devices.
PPVPNsにセキュリティー攻撃を検出するのに使用される監視システムは情報集めでProvider Edge(PE)、Customer Edge(CE)、そして/または、Providerバックボーン(P)デバイスから通常動作するでしょう。 セキュリティ監視システムには、活発にデバイス(例えば、SNMPは得る)からの情報を検索するか、またはデバイス(例えば、SNMP通知)からレポートを受け身に受け取る能力があるはずです。 交換された特殊情報はデバイスの能力と、そして、VPN技術のタイプに頼るでしょう。 監視システムとPPVPNデバイスの間でコミュニケーションチャンネルを固定するのに特定の注意を与えるべきです。
The CE, PE, and P devices should employ efficient methods to acquire and communicate the information needed by the security monitoring systems. It is important that the communication method between PPVPN devices and security monitoring systems be designed so that it will not disrupt network operations. As an example, multiple attack events may be reported through a single message, rather than allow each attack event to trigger a separate message, which might result in a flood of messages, essentially becoming a denial-of-service attack against the monitoring system or the network.
CE、PE、およびPデバイスはセキュリティ監視システムによって必要とされた情報を取得して、伝える効率的なメソッドを使うはずです。PPVPNデバイスとセキュリティ監視システムの間の通信方式がネットワーク操作を中断しないように設計されているのは、重要です。 例として、それぞれの攻撃イベントが別々のメッセージの引き金となるのを許容するより複数の攻撃イベントがただ一つのメッセージを通してむしろ報告されるかもしれません、本質的には監視システムかネットワークに対するサービス不能攻撃になって。メッセージはメッセージの洪水をもたらすかもしれません。
The mechanisms for reporting security attacks should be flexible enough to meet the needs of VPN service providers, VPN customers, and regulatory agencies. The specific reports will depend on the capabilities of the devices, the security monitoring system, the type of VPN, and the service level agreements between the provider and customer.
セキュリティー攻撃を報告するためのメカニズムはVPNサービスプロバイダー、VPN顧客、および監督官庁の需要を満たすほどフレキシブルであるべきです。 特定のレポートはデバイス、セキュリティ監視システム、VPNのタイプ、およびプロバイダーと顧客とのサービスレベル協定の能力によるでしょう。
7. User Security Requirements
7. ユーザセキュリティ要件
This section defines a list of security-related requirements that the users of PPVPN services may have for their PPVPN service. Typically, these translate into requirements for the provider in offering the service.
このセクションはPPVPNサービスのユーザが彼らのPPVPNサービスのために持っているかもしれないセキュリティ関連の要件のリストを定義します。 通常、これらはサービスを提供する際にプロバイダーのための要件に翻訳されます。
The following sections detail various requirements that ensure the security of a given trusted zone. Since in real life there are various levels of security, a PPVPN may fulfill any or all of these security requirements. This document does not state that a PPVPN must fulfill all of these requirements to be secure. As mentioned in the Introduction, it is not within the scope of this document to define the specific requirements that each VPN technology must fulfill in order to be secure.
以下のセクションは与えられた信じられたゾーンのセキュリティを確実にする様々な要件を詳しく述べます。 現実に、様々なレベルのセキュリティがあるので、PPVPNはこれらのセキュリティ要件のいずれかすべてを実現させるかもしれません。 このドキュメントは、PPVPNが安全であるというこれらの要件のすべてを実現させなければならないと述べません。 Introductionで言及されるように、それぞれのVPN技術が安全になるように実現させなければならない決められた一定の要求を定義するために、このドキュメントの範囲の中にそれはありません。
Fang Informational [Page 29] RFC 4111 PPVPN Security Framework July 2005
[29ページ]RFC4111PPVPNセキュリティフレームワーク2005年7月の情報の牙
7.1. Isolation
7.1. 分離
A virtual private network usually defines "private" as isolation from other PPVPNs and the Internet. More specifically, isolation has several components, which are discussed in the following sections.
通常、仮想私設網は他のPPVPNsとインターネットから「個人的」を分離と定義します。 分離で、より明確に、いくつかのコンポーネントがあります。(以下のセクションでコンポーネントについて議論します)。
7.1.1. Address Separation
7.1.1. アドレス分離
A given PPVPN can use the full Internet address range, including private address ranges [RFC1918], without interfering with other PPVPNs that use PPVPN services from the same service provider(s). When Internet access is provided (e.g., by the same service provider that is offering PPVPN service), NAT functionality may be needed.
与えられたPPVPNは最大限のインターネット・アドレス範囲を使用できます、プライベート・アドレス範囲[RFC1918]を含んでいて、同じサービスプロバイダーからPPVPNサービスを利用する他のPPVPNsを妨げないで。 インターネット・アクセスを提供するとき(例えば、サービスをPPVPNに提供しているのと同じサービスプロバイダーで)、NATの機能性を必要とするかもしれません。
In layer-2 VPNs, the same requirement exists for the layer 2 addressing schemes, such as MAC addresses.
層-2VPNsでは、同じ要件はMACアドレスなどの層2のアドレシング大要のために存在しています。
7.1.2. Routing Separation
7.1.2. ルート設定分離
A PPVPN core must maintain routing separation between the trusted zones. This means that routing information must not leak from any trusted zone to any other, unless the zones are specifically engineered this way (e.g., for Internet access.)
PPVPNコアは信じられたゾーンの間のルーティング分離を維持しなければなりません。 これは、ルーティング情報がどんな信じられたゾーンからいかなる他のも漏れてはいけないことを意味します、ゾーンがこのように明確に設計されない場合(例えば、インターネット・アクセスのための。)
In layer-2 VPNs, the switching information must be kept separate between the trusted zones, so that switching information of one PPVPN does not influence other PPVPNs or the PPVPN core.
層-2VPNsでは、信じられたゾーンの間で切り換え情報を別々に保たなければなりません、1PPVPNの切り換え情報が他のPPVPNsかPPVPNコアに影響を及ぼさないように。
7.1.3. Traffic Separation
7.1.3. トラフィック分離
Traffic from a given trusted zone must never leave this zone, and traffic from another zone must never enter this zone. Exceptions are made where zones are is specifically engineered that way (e.g., for extranet purposes or Internet access.)
与えられた信じられたゾーンからのトラフィックはこのゾーンを決して出てはいけません、そして、別のゾーンからのトラフィックはこのゾーンに決して入れてはいけません。 例外は作られていて、ゾーンがどこにあるかがそのように明確に設計されるということです。(例えば、エクストラネット目的かインターネット・アクセスのための。)
7.2. Protection
7.2. 保護
The common perception is that a completely separated "private" network has defined entry points and is only subject to attack or intrusion over those entry points. By sharing a common core, a PPVPN appears to lose some of these clear interfaces to networks outside the trusted zone. Thus, one of the key security requirements of PPVPN services is that they offer the same level of protection as private networks.
一般的な知覚は、完全に切り離された「個人的な」ネットワークがエントリー・ポイントを定義したということであり、それらのエントリー・ポイントの上の攻撃か単に侵入を受けることがあります。 一般的なコアを共有することによって、PPVPNは、信じられたゾーンの外のネットワークにこれらの明確なインタフェースのいくつかを失うように見えます。 したがって、PPVPNサービスの主要なセキュリティ要件の1つは私設のネットワークへの同じレベルの保護を提供するということです。
Fang Informational [Page 30] RFC 4111 PPVPN Security Framework July 2005
[30ページ]RFC4111PPVPNセキュリティフレームワーク2005年7月の情報の牙
7.2.1. Protection against Intrusion
7.2.1. 侵入に対する保護
An intrusion is defined here as the penetration of a trusted zone from outside. This could be from the Internet, another PPVPN, or the core network itself.
侵入はここで外部から信じられたゾーンの侵入と定義されます。 これはインターネット、別のPPVPN、またはコアネットワーク自体から来ているかもしれません。
The fact that a network is "virtual" must not expose it to additional threats over private networks. Specifically, it must not add new interfaces to other parts outside the trusted zone. Intrusions from known interfaces such as Internet gateways are outside the scope of this document.
ネットワークが「仮想」であるという事実は私設のネットワークの上の追加脅威にそれを暴露してはいけません。 明確に、それは信じられたゾーンの外の他の部品に新しいインタフェースを加えてはいけません。 このドキュメントの範囲の外にインターネット・ゲートウェイなどの知られているインタフェースからの侵入があります。
7.2.2. Protection against Denial-of-Service Attacks
7.2.2. サービス不能攻撃に対する保護
A denial-of-service (DoS) attack aims at making services or devices unavailable to legitimate users. In the framework of this document, only those DoS attacks are considered that are a consequence of providing network service through a VPN. DoS attacks over the standard interfaces into a trusted zone are not considered here.
サービスの否定(DoS)攻撃はサービスかデバイスを正統のユーザにとって入手できなくするのを目的とします。 このドキュメントのフレームワークでは、VPNを通してネットワーク・サービスを提供する結果であるそれらの唯一のDoS攻撃は考えられます。 信じられたゾーンへの標準インターフェースの上のDoS攻撃はここで考えられません。
The requirement is that a PPVPN is not more vulnerable against DoS attacks than it would be if the same network were private.
要件は同じネットワークが私設であるならPPVPNがそれであるだろうというほどDoS攻撃に対して被害を受け易くないということです。
7.2.3. Protection against Spoofing
7.2.3. スプーフィングに対する保護
It must not be possible to violate the integrity of a PPVPN by changing the sender identification (source address, source label, etc) of traffic in transit. For example, if two CEs are connected to the same PE, it must not be possible for one CE to send crafted packets that make the PE believe those packets are coming from the other CE, thus inserting them into the wrong PPVPN.
通過運送の送付者識別(ソースアドレス、ソースラベルなど)を変えることによってPPVPNの保全に違反するのは可能であるはずがありません。 例えば、2CEsが同じPEに接続されるなら、1CEが発信するのがPEがそれらのパケットがもう片方のCEから来る予定であると信じているパケットを作ったのは、可能であるはずがありません、その結果、間違ったPPVPNにそれらを挿入します。
7.3. Confidentiality
7.3. 秘密性
This requirement means that data must be cryptographically secured in transit over the PPVPN core network to avoid eavesdropping.
この要件は、盗み聞くのを避けるためにPPVPNコアネットワークの上のトランジットで暗号でデータを保証しなければならないことを意味します。
7.4. CE Authentication
7.4. Ce認証
Where CE authentication is provided, it is not possible for an outsider to install a CE and pretend to belong to a specific PPVPN to which this CE does not belong in reality.
CE認証を提供するところでは、部外者が、CEをインストールして、このCEがほんとうは属しない特定のPPVPNに属すふりをするのは、可能ではありません。
7.5. Integrity
7.5. 保全
Data in transit must be secured in such a manner that it cannot be altered or that any alteration may be detected at the receiver.
それを変更できないか、またはどんな変更も受信機に検出されるくらいの方法でトランジットにおけるデータを保証しなければなりません。
Fang Informational [Page 31] RFC 4111 PPVPN Security Framework July 2005
[31ページ]RFC4111PPVPNセキュリティフレームワーク2005年7月の情報の牙
7.6. Anti-replay
7.6. 反再生
Anti-replay means that data in transit cannot be recorded and replayed later. To protect against anti-replay attacks, the data must be cryptographically secured.
反再生は、後でトランジットにおけるデータを記録して、再演できないことを意味します。 反反射攻撃から守るために、暗号でデータを保証しなければなりません。
Note: Even private networks do not necessarily meet the requirements of confidentiality, integrity, and anti-reply. Thus, when private and "virtually private" PPVPN services are compared, these requirements are only applicable if the comparable private service also included these services. However, the fact that VPNs operate over a shared infrastructure may make some of these requirements more important in a VPN environment than in a private network environment.
以下に注意してください。 私設のネットワークさえ必ず秘密性、保全、および反回答に関する必要条件を満たすというわけではありません。 個人的で「実際には個人的な」PPVPNサービスが比べるときだけ、したがって、また、匹敵する密葬がこれらのサービスを含んでいたなら、これらの要件は適切です。 しかしながら、VPNsが共有されたインフラストラクチャの上で作動するという事実で、これらの要件のいくつかがVPN環境で個人的なネットワーク環境より重要になるかもしれません。
8. Provider Security Requirements
8. プロバイダーセキュリティ要件
In this section, we discuss additional security requirements that the provider may have in order to secure its network infrastructure as it provides PPVPN services.
このセクションで、私たちはプロバイダーがサービスをPPVPNに供給するときネットワークインフラを保証するために持っているかもしれない追加担保要件について議論します。
The PPVPN service provider requirements defined here are the requirements for the PPVPN core in the reference model. The core network can be implemented with different types of network technologies, and each core network may use different technologies to provide the PPVPN services to users with different levels of offered security. Therefore, a PPVPN service provider may fulfill any number of the security requirements listed in this section. This document does not state that a PPVPN must fulfill all of these requirements to be secure.
ここで定義されたPPVPNサービスプロバイダー要件は規範モデルのPPVPNコアのための要件です。 異なったタイプのネットワーク技術でコアネットワークを実装することができます、そして、それぞれのコアネットワークは異なったレベルの提供されたセキュリティをユーザに対するPPVPNサービスに提供する異なった技術を使用するかもしれません。 したがって、PPVPNサービスプロバイダーはこのセクションでリストアップされたいろいろなセキュリティ要件を実現させるかもしれません。 このドキュメントは、PPVPNが安全であるというこれらの要件のすべてを実現させなければならないと述べません。
These requirements are focused on 1) how to protect the PPVPN core from various attacks outside the core, including PPVPN users and non-PPVPN alike, both accidentally and maliciously, and 2) how to protect the PPVPN user VPNs and sites themselves. Note that a PPVPN core is not more vulnerable against attacks than a core that does not provide PPVPNs. However, providing PPVPN services over such a core may lead to additional security requirements, if only because most users are expecting higher security standards in a core delivering PPVPN services.
これらの要件は1)に焦点を合わせられて、様々であるのからPPVPNコアをどう保護するかが一様に、偶然、陰湿にPPVPNユーザと非PPVPNを含むコアと2の)外でどうPPVPNユーザVPNsを保護するかを攻撃するということであり、サイトは自分たちです。 PPVPNコアがPPVPNsを提供しないコアほど攻撃に対して被害を受け易くないことに注意してください。 しかしながら、サービスをPPVPNに供給して、唯一なら、ほとんどのユーザが導くので、そのようなコアの上では、サービスをPPVPNに提供するコアのおめでたの予定の、より高い機密保護基準は追加担保要件に導いているかもしれません。
8.1. Protection within the Core Network
8.1. コアネットワークの中の保護
8.1.1. Control Plane Protection
8.1.1. コントロール飛行機保護
- Protocol Authentication within the Core:
- コアの中で認証について議定書の中で述べてください:
PPVPN technologies and infrastructure must support mechanisms for
authentication of the control plane. For an IP core, IGP and BGP
PPVPN技術とインフラストラクチャは制御飛行機の認証のためにメカニズムをサポートしなければなりません。 IPコア、IGP、およびBGPのために
Fang Informational [Page 32] RFC 4111 PPVPN Security Framework July 2005
[32ページ]RFC4111PPVPNセキュリティフレームワーク2005年7月の情報の牙
sessions may be authenticated by using TCP MD5 or IPsec. If an
MPLS core is used, LDP sessions may be authenticated by using TCP
MD5. In addition, IGP and BGP authentication should also be
considered. For a core providing layer-2 services, PE to PE
authentication may also be used via IPsec.
セッションは、TCP MD5かIPsecを使用することによって、認証されるかもしれません。 MPLSコアが使用されているなら、自由民主党のセッションは、TCP MD5を使用することによって、認証されるかもしれません。 また、さらに、IGPとBGP認証は考えられるべきです。 また、層-2つのサービスを提供するコアのために、PE認証へのPEはIPsecを通して使用されるかもしれません。
With the cost of authentication coming down rapidly, the
application of control plane authentication may not increase the
cost of implementation for providers significantly, and it will
improve the security of the core. If the core is dedicated to VPN
services and there are no interconnects to third parties, then it
may reduce the requirement for authentication of the core control
plane.
認証の費用が急速に下りていて、コントロール飛行機認証の応用はプロバイダーのために実装の費用をかなり増強しないかもしれません、そして、それはコアのセキュリティを向上させるでしょう。 コアがVPNサービスに捧げられて、第三者への内部連絡が全くなければ、それはコア制御飛行機の認証のための要件を減らすかもしれません。
- Elements protection
- 要素保護
Here we discuss means to hide the provider's infrastructure nodes.
ここで、私たちはプロバイダーのインフラストラクチャノードを隠す手段について議論します。
A PPVPN provider may make the infrastructure routers (P and PE
routers) unreachable by outside users and unauthorized internal
users. For example, separate address space may be used for the
infrastructure loopbacks.
PPVPNプロバイダーは外部のユーザで手の届かないルータ(PとPEルータ)と権限のない内部利用者にインフラストラクチャを作るかもしれません。 例えば、別々のアドレス空間はインフラストラクチャループバックに使用されるかもしれません。
Normal TTL propagation may be altered to make the backbone look
like one hop from the outside, but caution should be taken for
loop prevention. This prevents the backbone addresses from being
exposed through trace route; however, it must also be assessed
against operational requirements for end-to-end fault tracing.
バックボーンを見えさせるように外部からワンバウンドであることのように通常のTTL伝播を変更するかもしれませんが、輪の防止に警告を取るべきです。 これは暴露されるのから跡のアドレスが発送するバックボーンを防ぎます。 しかしながら、また、終わりから終わりへの欠点たどる操作上の要件に対してそれを評価しなければなりません。
An Internet backbone core may be re-engineered to make Internet
routing an edge function, for example, by using MPLS label
switching for all traffic within the core and possibly by making
the Internet a VPN within the PPVPN core itself. This helps
detach Internet access from PPVPN services.
インターネットの基幹コアは、例えばコアの中ですべてのトラフィックのためのMPLSラベルの切り換えを使用して、ことによるとPPVPNコア自体の中でインターネットをVPNにすることによってインターネット・ルーティングを縁の機能にするように改良されるかもしれません。 これは、PPVPNサービスからインターネット・アクセスを離すのを助けます。
PE devices may implement separate control plane, data plane, and
management plane functionality in terms of hardware and software,
to improve security. This may help limit the problems when one
particular area is attacked, and it may allow each plane to
implement additional security measurement separately.
PEデバイスは、セキュリティを向上させるためにハードウェアとソフトウェアに関して別々のコントロールが飛行機と、データ飛行機と、管理飛行機の機能性であると実装するかもしれません。 1つの特定の領域が攻撃されるとき、これは、問題を制限するのを助けるかもしれません、そして、それは各飛行機が、別々に追加担保が測定であると実装するのを許容するかもしれません。
PEs are often more vulnerable to attack than P routers, since, by
their very nature, PEs cannot be made unreachable to outside
users. Access to core trunk resources can be controlled on a
per-user basis by the application of inbound rate-
limiting/shaping. This can be further enhanced on a per-Class of
Service basis (see section 8.2.3).
PEsは攻撃するためにPルータよりしばしば被害を受け易いです、彼らのまさしくその本質でPEsをユーザにとって手が届かなくすることができないので。 1ユーザあたり1個のベースで本国行きのレート制限/形成のアプリケーションでコアトランクリソースへのアクセスを制御できます。 Service基礎のクラスでさらにこれを高めることができます(セクション8.2.3を見てください)。
Fang Informational [Page 33] RFC 4111 PPVPN Security Framework July 2005
[33ページ]RFC4111PPVPNセキュリティフレームワーク2005年7月の情報の牙
In the PE, using separate routing processes for Internet and PPVPN
service may help improve the PPVPN security and better protect VPN
customers. Furthermore, if the resources, such as CPU and memory,
may be further separated based on applications, or even on
individual VPNs, it may help provide improved security and
reliability to individual VPN customers.
PEでは、インターネットとPPVPNサービスに別々のルーティングプロセスを使用するのは、PPVPNセキュリティを向上させるのを助けて、VPN顧客を保護するほうがよいです。 その上、CPUやメモリなどのリソースがアプリケーションに基づいた個々のVPNsの上でさえさらに切り離されるかもしれないなら、それは、向上したセキュリティと信頼性を個々のVPN顧客に提供するのを助けるかもしれません。
Many of these were not particular issues when an IP core was
designed to support Internet services only. Providing PPVPN
services introduces new security requirements for VPN services.
Similar consideration apply to L2 VPN services.
IPコアがインターネットのサービスだけをサポートするように設計されたとき、これらの多くが特定の問題ではありませんでした。 サービスをPPVPNに供給すると、VPNサービスのための新しいセキュリティ要件は導入されます。 同様の考慮はL2 VPNサービスに適用されます。
8.1.2. Data Plane Protection
8.1.2. データ飛行機保護
PPVPN using IPsec technologies provides VPN users with encryption of secure user data.
IPsec技術を使用するPPVPNが安全な利用者データの暗号化をVPNユーザに提供します。
In today's MPLS, ATM, and Frame Relay networks, encryption is not provided as a basic feature. Mechanisms can be used to secure the MPLS data plane and to secure the data carried over the MPLS core. Additionally, if the core is dedicated to VPN services and there are no external interconnects to third party networks, then there is no obvious need for encryption of the user data plane.
今日のMPLS、ATM、およびFrame Relayネットワークには、暗号化は基本的特徴として提供されません。 MPLSデータ飛行機を固定して、MPLSコアの上まで運ばれたデータを保証するのにメカニズムを使用できます。 さらに、コアがVPNサービスに捧げられて、第三者ネットワークへのどんな外部の内部連絡もなければ、利用者データ飛行機の暗号化の明白な必要は全くありません。
Inter-working IPsec/L3 PPVPN technologies or IPsec/L2 PPVPN technologies may be used to provide PPVPN users with end-to-end PPVPN services.
IPsec/L3 PPVPN技術かIPsec/L2 PPVPNが技術であると織り込むのが終わりから終わりに対するPPVPNサービスをPPVPNユーザに提供するのに使用されるかもしれません。
8.2. Protection on the User Access Link
8.2. ユーザアクセスリンクにおける保護
Peer/Neighbor protocol authentication may be used to enhance security. For example, BGP MD5 authentication may be used to enhance security on PE-CE links using eBGP. In the case of an inter-provider connection, authentication/encryption mechanisms between ASes, such as IPsec, may be used.
同輩/隣人プロトコル認証は、セキュリティを高めるのに使用されるかもしれません。 例えば、BGP MD5認証は、PE-CEリンクでeBGPを使用することでセキュリティを高めるのに使用されるかもしれません。 相互プロバイダー接続の場合では、IPsecなどのASesの間の認証/暗号化メカニズムは使用されるかもしれません。
WAN link address space separation for VPN and non-VPN users may be implemented to improve security in order to protect VPN customers if multiple services are provided on the same PE platform.
VPNと非VPNユーザのためのWANリンクアドレス宇宙分離は、同じPEプラットホームで複数のサービスを提供するならVPN顧客を保護するためにセキュリティを向上させるために実装されるかもしれません。
Firewall/Filtering: Access control mechanisms can be used to filter out any packets destined for the service provider's infrastructure prefix or to eliminate routes identified as illegitimate.
ファイアウォール/フィルタリング: サービスプロバイダーのインフラストラクチャ接頭語のために運命づけられたどんなパケットも無視するか、または違法であるとして特定されたルートを排除するのにアクセス管理機構を使用できます。
Fang Informational [Page 34] RFC 4111 PPVPN Security Framework July 2005
[34ページ]RFC4111PPVPNセキュリティフレームワーク2005年7月の情報の牙
Rate limiting may be applied to the user interface/logical interfaces against DDoS bandwidth attack. This is very helpful when the PE device is supporting both VPN services and Internet services, especially when it supports VPN and Internet services on the same physical interfaces through different logical interfaces.
レート制限はDDoS帯域幅攻撃に対するユーザーインタフェース/論理的なインタフェースに付けられるかもしれません。 PEデバイスがVPNサービスとインターネットのサービスの両方をサポートしているとき、これは非常に役立っています、特に異なった論理的なインタフェースを通して同じ物理インターフェースでVPNとインターネットのサービスをサポートすると。
8.2.1. Link Authentication
8.2.1. リンク認証
Authentication mechanisms can be employed to validate site access to the PPVPN network via fixed or logical (e.g., L2TP, IPsec) connections. When the user wishes to hold the 'secret' associated to acceptance of the access and site into the VPN, then PPVPN based solutions require the flexibility for either direct authentication by the PE itself or interaction with a customer PPVPN authentication server. Mechanisms are required in the latter case to ensure that the interaction between the PE and the customer authentication server is controlled, for example, by limiting it simply to an exchange in relation to the authentication phase and with other attributes (e.g., optional filtering of RADIUS).
修理されたか論理的な(例えば、L2TP、IPsec)接続でPPVPNネットワークへのサイトアクセスを有効にするのに認証機構を使うことができます。 ユーザがいつ'秘密'を保持したがっているかはVPNへのアクセスとサイトの承認と交際しました; 次に、PPVPNのベースのソリューションはPE自身によるダイレクト認証か相互作用のどちらかのために顧客PPVPN認証サーバで柔軟性を必要とします。メカニズムは、後者の場合で例えば、PEと顧客認証サーバとの相互作用が単にそれを認証フェーズと関連した他の属性に従った交換(例えば、RADIUSの任意のフィルタリング)に制限することによって制御されるのを保証しなければなりません。
8.2.2. Access Routing
8.2.2. アクセスルート設定
Mechanisms may be used to provide control at a routing protocol level (e.g., RIP, OSPF, BGP) between the CE and PE. Per-neighbor and per- VPN routing policies may be established to enhance security and reduce the impact of a malicious or non-malicious attack on the PE, in particular, the following mechanisms should be considered:
メカニズムは、CEとPEの間のルーティング・プロトコルレベル(例えば、リップ、OSPF、BGP)でコントロールを提供するのに使用されるかもしれません。 そして、隣人、-、VPNルーティング方針はセキュリティを高めて、PEで悪意があるか非悪意ある攻撃の影響を減少させるために確立されるかもしれません、特に以下のメカニズムは考えられるべきです:
- Limiting the number of prefixes that may be advertised into the PE
on a per-access basis . Appropriate action may be taken should a
limit be exceeded; for example, the PE might shut down the peer
session to the CE.
- 限界が超えられているなら、1アクセスあたり1個のベースのPEに広告を出して. 適切な行動を取るかもしれないということであるかもしれない接頭語の数を制限します。 例えば、PEは同輩セッションをCEに止めるかもしれません。
- Applying route dampening at the PE on received routing updates.
- 容認されたルーティングアップデートのときにPEで弱まるルートを適用します。
- Definition of a per-VPN prefix limit, after which additional
prefixes will not be added to the VPN routing table.
- 1VPNあたり1つの接頭語限界の定義。(その時、追加接頭語はVPN経路指定テーブルに加えられなかったでしょう後)。
In the case of inter-provider connection, access protection, link authentication, and routing policies as described above may be applied. Both inbound and outbound firewall/filtering mechanism may be applied between ASes. Proper security procedures must be implemented in inter-provider VPN interconnection to protect the providers' network infrastructure and their customer VPNs. This may be custom designed for each inter-Provider VPN peering connection, and both providers must agree on it.
相互プロバイダー接続の場合では、上で説明されるアクセス保護、リンク認証、およびルーティング方針は適用されるかもしれません。 本国行きの、そして、外国行きの両方のファイアウォール/フィルタリングメカニズムはASesの間で適用されるかもしれません。 プロバイダーのネットワークインフラと彼らの顧客VPNsを保護するために相互プロバイダーVPNインタコネクトで適切なセキュリティ手順を実装しなければなりません。 これはそれぞれの相互Provider VPNじっと見る接続のために設計されていた状態でカスタムであるかもしれません、そして、両方のプロバイダーはそれに同意しなければなりません。
Fang Informational [Page 35] RFC 4111 PPVPN Security Framework July 2005
[35ページ]RFC4111PPVPNセキュリティフレームワーク2005年7月の情報の牙
8.2.3. Access QoS
8.2.3. アクセスQoS
PPVPN providers offering QoS-enabled services require mechanisms to ensure that individual accesses are validated against their subscribed QOS profile and are granted access to core resources that match their service profile. Mechanisms such as per-Class of Service rate limiting/traffic shaping on ingress to the PPVPN core are one option in providing this level of control. Such mechanisms may require the per-Class of Service profile to be enforced by marking, remarking, or discarding traffic that is outside of the profile.
QoSによって可能にされたサービスを提供するPPVPNプロバイダーは、個々のアクセスはそれらの申し込まれたQOSプロフィールに対して有効にされて、それらのサービスプロフィールに合っているコアリソースへのアクセスを承諾されるのを保証するためにメカニズムを必要とします。 イングレスでPPVPNコアに形成されるServiceレート制限/トラフィックのクラスなどのメカニズムはこの管理水準を提供することにおいて1つのオプションです。 そのようなメカニズムは、プロフィールの外にあるトラフィックをマークするか、述べるか、または捨てることによって実施されるためにServiceプロフィールをクラスに要求するかもしれません。
8.2.4. Customer VPN Monitoring Tools
8.2.4. ツールをモニターしている顧客VPN
End users requiring visibility of VPN-specific statistics on the core (e.g., routing table, interface status, QoS statistics) impose requirements for mechanisms at the PE both to validate the incoming user and to limit the views available to that particular user's VPN. Mechanisms should also be considered to ensure that such access cannot be used to create a DoS attack (either malicious or accidental) on the PE itself. This could be accomplished either through separation of these resources within the PE itself or via the capability to rate-limit such traffic on a per-VPN basis.
コア(例えば、テーブルを発送して、状態を連結してください、QoS統計)におけるVPN特有の統計の目に見えることを必要とするエンドユーザがPEのメカニズムがともに入って来るユーザを有効にして、その特定のユーザのVPNに利用可能な視点を制限するという要件を課します。 また、メカニズムが、PE自身で(悪意があるか偶然)でDoS攻撃を作成するのにそのようなアクセスを使用できないのを保証すると考えられるべきです。 1VPNあたり1個のベースでこれらのリソースの分離でPE自身以内かそのようなトラフィックをレートで制限する能力でこれを達成できるでしょう。
8.3. General Requirements for PPVPN Providers
8.3. PPVPNプロバイダーのための一般要件
The PPVPN providers must support the users' security requirements as listed in Section 7. Depending on the technologies used, these requirements may include the following.
PPVPNプロバイダーは、セクション7に記載されているようにユーザのセキュリティが要件であるとサポートしなければなりません。 使用される技術によって、これらの要件は以下を含むかもしれません。
- User control plane separation: Routing isolation.
- ユーザコントロール飛行機分離: 分離を発送します。
- User address space separation: Supporting overlapping addresses
from different VPNs.
- ユーザアドレス空間分離: 異なったVPNsからのアドレスを重なるのにサポートします。
- User data plane separation: One VPN traffic cannot be intercepted
by other VPNs or any other users.
- 利用者データ修正面分離: 他のVPNsかいかなる他のユーザも1VPNのトラフィックを妨害できません。
- Protection against intrusion, DoS attacks and spoofing.
- 侵入、DoS攻撃、およびスプーフィングに対する保護。
- Access Authentication.
- 認証にアクセスしてください。
- Techniques highlighted through this document identify
methodologies for the protection of PPVPN resources and
infrastructure.
- このドキュメントを通して強調されたテクニックはPPVPNリソースとインフラストラクチャの保護のために方法論を特定します。
Hardware or software bugs in equipment that lead to security breaches are outside the scope of this document.
このドキュメントの範囲の外に設備の機密保護違反につながるハードウェアかソフトウェアのバグがあります。
Fang Informational [Page 36] RFC 4111 PPVPN Security Framework July 2005
[36ページ]RFC4111PPVPNセキュリティフレームワーク2005年7月の情報の牙
9. Security Evaluation of PPVPN Technologies
9. PPVPN技術の機密保護評価
This section presents a brief template that may be used to evaluate and summarize how a given PPVPN approach (solution) measures up against the PPVPN Security Framework. An evaluation using this template should appear in the applicability statement for each PPVPN approach.
このセクションは与えられたPPVPNアプローチ(ソリューション)がPPVPN Security Frameworkに直面してどう測定するかを評価して、まとめるのに使用されるかもしれない簡潔なテンプレートを贈ります。 このテンプレートを使用する評価は適用性証明にそれぞれのPPVPNアプローチに関して載るべきです。
9.1. Evaluating the Template
9.1. テンプレートを評価します。
The first part of the template is in the form of a list of security assertions. For each assertion the approach is assessed and one or more of the following ratings is assigned:
テンプレートの最初の部分がセキュリティ主張のリストの形にあります。 各主張において、アプローチは評価されます、そして、以下の格付けの1つ以上は割り当てられます:
- The requirement is not applicable to the VPN approach because ...
(fill in reason).
- 要件がVPNアプローチに適切でない、… (理由に記入します。)
- The base VPN approach completely addresses the requirement by ...
(fill in technique).
- VPNアプローチが要件を完全に扱うベース… (テクニックに記入します。)
- The base VPN approach partially addresses the requirement by ...
(fill in technique and extent to which it addresses the
requirement).
- VPNアプローチが要件を部分的に扱うベース… (それが要件を扱うテクニックと範囲に記入します。)
- An optional extension to the VPN approach completely addresses the
requirement by ... (fill in technique).
- アプローチが要件を完全に扱うVPNへの任意の拡大… (テクニックに記入します。)
- An optional extension to the VPN approach partially addresses the
requirement by ... (fill in technique and extent to which it
addresses the requirement).
- アプローチが要件を部分的に扱うVPNへの任意の拡大… (それが要件を扱うテクニックと範囲に記入します。)
- The requirement is addressed in a way that is beyond the scope of
the VPN approach. (Explain.) (One example of this would be a VPN
approach in which some aspect, such as membership discovery, is
done via configuration. The protection afforded to the
configuration would be beyond the scope of the VPN approach.).
- 要件はVPNアプローチの範囲にある方法で扱われます。 (説明してください。) (この1つの例は会員資格発見などの何らかの局面が構成で行われるVPNアプローチでしょう。 構成に提供された保護はVPNアプローチの範囲を超えているでしょう。).
- The VPN approach does not meet the requirement.
- VPNアプローチは条件を満たしません。
9.2. Template
9.2. テンプレート
The following assertions solicit responses of the types listed in the previous section.
以下の主張は前項で記載されたタイプの応答に請求します。
1. The approach provides complete IP address space separation for
each L3 VPN.
1. アプローチは完全なIPアドレス空間分離を各L3 VPNに供給します。
Fang Informational [Page 37] RFC 4111 PPVPN Security Framework July 2005
[37ページ]RFC4111PPVPNセキュリティフレームワーク2005年7月の情報の牙
2. The approach provides complete L2 address space separation for
each L2 VPN.
2. アプローチは完全なL2アドレス空間分離を各L2 VPNに供給します。
3. The approach provides complete VLAN ID space separation for each
L2 VPN.
3. アプローチは完全なVLAN ID宇宙分離を各L2 VPNに供給します。
4. The approach provides complete IP route separation for each L3
VPN.
4. アプローチは完全なIPルート分離を各L3 VPNに供給します。
5. The approach provides complete L2 forwarding separation for each
L2 VPN.
5. アプローチは、各L2 VPNのために分離を進めながら、完全なL2を提供します。
6. The approach provides a means to prevent improper cross-
connection of sites in separate VPNs.
6. アプローチは別々のVPNsでのサイトの不適当な十字接続を防ぐ手段を提供します。
7. The approach provides a means to detect improper cross-connection
of sites in separate VPNs.
7. アプローチは別々のVPNsのサイトの不適当な交差接続を検出する手段を提供します。
8. The approach protects against the introduction of unauthorized
packets into each VPN
a. in the CE-PE link,
b. in a single- or multi-provider PPVPN backbone, or
c. in the Internet used as PPVPN backbone.
8. アプローチはCE-PEリンク(PPVPNバックボーンとして使用されるインターネットの単一の、または、マルチプロバイダーのPPVPNバックボーン、またはc.のb.)の各VPN a.に権限のないパケットの挿入から守ります。
9. The approach provides confidentiality (secrecy) protection for
PPVPN user data
a. in the CE-PE link,
b. in a single- or multi-provider PPVPN backbone, or
c. in the Internet used as PPVPN backbone.
9. アプローチはCE-PEリンク(PPVPNバックボーンとして使用されるインターネットの単一の、または、マルチプロバイダーのPPVPNバックボーン、またはc.のb.)にPPVPN利用者データa.のための秘密性(秘密保持)保護を供給します。
10. The approach provides sender authentication for PPVPN user data.
a. in the CE-PE link,
b. in a single- or multi-provider PPVPN backbone, or
c. in the Internet used as PPVPN backbone.
10. アプローチはPPVPN利用者データCE-PEリンクのa.のための送付者認証、単一の、または、マルチプロバイダーのPPVPNバックボーンにおけるb.、またはPPVPNバックボーンとして使用されるインターネットのc.を提供します。
11. The approach provides integrity protection for PPVPN user data
a. in the CE-PE link,
b. in a single- or multi- provider PPVPN backbone, or
c. in the Internet used as PPVPN backbone.
11. アプローチはCE-PEリンク(PPVPNバックボーンとして使用されるインターネットの単一の、または、マルチプロバイダーのPPVPNバックボーン、またはc.のb.)にPPVPN利用者データa.のための保全保護を供給します。
12. The approach provides protection against replay attacks for PPVPN
user data
a. in the CE-PE link,
b. in a single- or multi-provider PPVPN backbone, or
c. in the Internet used as PPVPN backbone.
12. アプローチはCE-PEリンク(PPVPNバックボーンとして使用されるインターネットの単一の、または、マルチプロバイダーのPPVPNバックボーン、またはc.のb.)で反射攻撃に対する保護をPPVPN利用者データa.に提供します。
Fang Informational [Page 38] RFC 4111 PPVPN Security Framework July 2005
[38ページ]RFC4111PPVPNセキュリティフレームワーク2005年7月の情報の牙
13. The approach provides protection against unauthorized traffic
pattern analysis for PPVPN user data
a. in the CE-PE link,
b. in a single- or multi-provider PPVPN backbone, or
c. in the Internet used as PPVPN backbone.
13. アプローチはCE-PEリンク(PPVPNバックボーンとして使用されるインターネットの単一の、または、マルチプロバイダーのPPVPNバックボーン、またはc.のb.)のPPVPN利用者データa.のための権限のないトラフィックパターン解析に対する保護を提供します。
14. The control protocol(s) used for each of the following functions
provides message integrity and peer authentication
14. それぞれの以下の機能に使用される制御プロトコルはメッセージの保全と同輩認証を提供します。
a. VPN membership discovery.
b. Tunnel establishment.
c. VPN topology and reachability advertisement:
i. PE-PE.
ii. PE-CE.
d. VPN provisioning and management.
e. VPN monitoring, attack detection, and reporting.
f. Other VPN-specific control protocols, if any (list).
a。 VPN会員資格発見b。 設立cにトンネルを堀ってください。 VPNトポロジーと可到達性広告: i。 PE-PE ii。 PE-CE. d。 VPNの食糧を供給するのと管理e。 VPNモニター、攻撃検出、および報告f。 もしあれば(記載する)他のVPN特有の制御プロトコル。
The following questions solicit free-form answers.
以下の質問は自由形式答えに請求します。
15. Describe the protection, if any, the approach provides against
PPVPN-specific DoS attacks (i.e., inter-trusted-zone DoS
attacks):
15. アプローチがPPVPN特有のDoS攻撃(すなわち、相互の信じられたゾーンDoS攻撃)をいくらか備えるなら、保護について説明してください:
a. Protection of the service provider infrastructure against
Data Plane or Control Plane DoS attacks originated in a
private (PPVPN user) network and aimed at PPVPN mechanisms.
a。 Data PlaneかControl Plane DoS攻撃に対するサービスプロバイダーインフラストラクチャの保護は、私設(PPVPNユーザ)のネットワークで起こって、PPVPNメカニズムを目的としました。
b. Protection of the service provider infrastructure against
Data Plane or Control Plane DoS attacks originated in the
Internet and aimed at PPVPN mechanisms.
b。 Data PlaneかControl Plane DoS攻撃に対するサービスプロバイダーインフラストラクチャの保護は、インターネットで起こって、PPVPNメカニズムを目的としました。
c. Protection of PPVPN users against Data Plane or Control
Plane DoS attacks originated from the Internet or from other
PPVPN users and aimed at PPVPN mechanisms.
c。 Data Planeに対するPPVPNユーザかControl Plane DoS攻撃の保護は、インターネットか他のPPVPNユーザから起因して、PPVPNメカニズムを目的としました。
16. Describe the protection, if any, the approach provides against
unstable or malicious operation of a PPVPN user network
16. アプローチがPPVPNユーザネットワークの不安定であるか悪意がある操作をいくらか備えるなら、保護について説明してください。
a. Protection against high levels of, or malicious design of,
routing traffic from PPVPN user networks to the service
provider network.
a。 高いレベルに対する保護、悪意があるデザイン、PPVPNユーザネットワークからサービスプロバイダーネットワークまでトラフィックを発送します。
b. Protection against high levels of, or malicious design of,
network management traffic from PPVPN user networks to the
service provider network.
b。 高いレベルに対する保護、悪意があるデザイン、PPVPNユーザネットワークからサービスプロバイダーネットワークまでのネットワークマネージメントトラフィック。
Fang Informational [Page 39] RFC 4111 PPVPN Security Framework July 2005
[39ページ]RFC4111PPVPNセキュリティフレームワーク2005年7月の情報の牙
c. Protection against worms and probes originated in the PPVPN
user networks, sent toward the service provider network.
c。 ワームと徹底的調査に対する保護はサービスプロバイダーネットワークに向かって送られたPPVPNユーザネットワークで起こりました。
17. Is the approach subject to any approach-specific vulnerabilities
not specifically addressed by this template? If so, describe the
defense or mitigation, if any, that the approach provides for
each.
17. 何かアプローチ特有の脆弱性を条件としたアプローチはこのテンプレートによって明確に扱われませんか? そうだとすれば、もしあればアプローチがそれぞれ備えるディフェンスか緩和について説明してください。
10. Security Considerations
10. セキュリティ問題
Security considerations constitute the sole subject of this memo and hence are discussed throughout. Here we recap what has been presented and explain at a very high level the role of each type of consideration in an overall secure PPVPN system. The document describes a number of potential security threats. Some of these threats have already been observed occurring in running networks; others are largely theoretical at this time.
セキュリティ問題について、このメモの唯一の対象を構成して、したがって、あらゆる点で議論します。 ここで、私たちは、提示されたことをリキャップして、非常に高いレベルで総合的な安全なPPVPNシステムにおける、それぞれのタイプの考慮の役割について説明します。 ドキュメントは多くの潜在的軍事的脅威について説明します。 これらの脅威のいくつかが実行しているネットワークで起こっていると既に認められました。 他のものはこのとき、主に理論的です。
DoS attacks and intrusion attacks from the Internet against service provider infrastructure have been seen. DoS "attacks" (typically not malicious) have also been seen in which CE equipment overwhelms PE equipment with high quantities or rates of packet traffic or routing information. Operational/provisioning errors are cited by service providers as one of their prime concerns.
サービスプロバイダーインフラストラクチャに対するインターネットからのDoS攻撃と侵入攻撃を見てあります。 また、DoS「攻撃」(通常悪意がない)は、どのCE設備がパケットトラフィックの高い量かレートでPE設備を圧倒するかで見られるか、または情報を発送しています。 操作上の、または、食糧を供給している誤りは彼らの最大の関心事の1つとしてサービスプロバイダーによって引用されます。
The document describes a variety of defensive techniques that may be used to counter the suspected threats. All of the techniques presented involve mature and widely implemented technologies that are practical to implement.
ドキュメントは疑われた脅威に対抗するのに使用されるかもしれないさまざまな防衛的なテクニックについて説明します。 提示されたテクニックのすべてが実装するために実用的な熟していて広く実装している技術にかかわります。
The document describes the importance of detecting, monitoring, and reporting both successful and unsuccessful attacks. These activities are essential for "understanding one's enemy", mobilizing new defenses, and obtaining metrics about how secure the PPVPN service is. As such, they are vital components of any complete PPVPN security system.
ドキュメントはうまくいっていて失敗の両方の攻撃を検出して、モニターして、報告する重要性について説明します。 「人の敵を理解しています」に、これらの活動は不可欠です、PPVPNサービスがどれくらい安全であるかに関して、新しいディフェンスを動員して、測定基準を得て。 そういうものとして、それらはどんな完全なPPVPNセキュリティシステムの重大な部品です。
The document evaluates PPVPN security requirements from a customer perspective and from a service provider perspective. These sections re-evaluate the identified threats from the perspectives of the various stakeholders and are meant to assist equipment vendors and service providers, who must ultimately decide what threats to protect against in any given equipment or service offering.
ドキュメントは顧客見解とサービスプロバイダー見解からのPPVPNセキュリティ要件を評価します。 これらのセクションは、様々な利害関係者の見解から特定された脅威を再評価して、設備ベンダーとサービスプロバイダーを補助することになっています。(サービスプロバイダーは結局、何か与えられた設備やサービス提供でどんな脅威から守ったらよいかを決めなければなりません)。
Finally, the document includes a template for use by authors of PPVPN technical solutions for evaluating how those solutions measure up against the security considerations presented in this memo.
最終的に、ドキュメントはそれらのソリューションがどうセキュリティに対してこのメモに提示された問題を推定するかを評価するPPVPN技術的解決法の作者による使用のためにテンプレートを含んでいます。
Fang Informational [Page 40] RFC 4111 PPVPN Security Framework July 2005
[40ページ]RFC4111PPVPNセキュリティフレームワーク2005年7月の情報の牙
11. Contributors
11. 貢献者
The following people made major contributions to writing this document: Michael Behringer, Ross Callon, Fabio Chiussi, Jeremy De Clerque, Paul Hitchen, and Paul Knignt.
以下の人々はこのドキュメントを書くことへの主要な貢献をしました: マイケルBehringer、ロスCallon、ファビオChiussi、ジェレミーDe Clerque、ポールHitchen、およびポールKnignt。
Michael Behringer Cisco Village d'Entreprises Green Side, Phone: +33.49723-2652 400, Avenue Roumanille, Bat. T 3 EMail: mbehring@cisco.com 06410 Biot, Sophia Antipolis France
マイケルBehringerコクチマス村のd'Entreprisesグリーン側、電話: +33.49723-2652 400(Avenueルーマニーユ)は打たれます。 T3はメールされます: mbehring@cisco.com 06410Biot、ソフィア・Antipolisフランス
Ross Callon Juniper Networks 10 Technology Park Drive Phone: 978-692-6724 Westford, MA 01886 EMail: rcallon@juniper.net
ロスCallon Juniperは10技術公園ドライブ電話をネットワークでつなぎます: 978-692-6724 ウェストフォード、MA 01886はメールされます: rcallon@juniper.net
Fabio Chiussi Phone: 1 978 367-8965 Airvana EMail: fabio@airvananet.com 19 Alpha Road Chelmsford, Massachusetts 01824
ファビオChiussiは以下に電話をします。 1 978 367-8965Airvanaはメールします: Roadチェルムズフォード、 fabio@airvananet.com 19Alphaマサチューセッツ 01824
Jeremy De Clercq Alcatel Fr. Wellesplein 1, 2018 Antwerpen EMail: jeremy.de_clercq@alcatel.be Belgium
ジェレミーDe ClercqアルカテルFr。 Wellesplein1、2018アントウェルペンはメールされます: jeremy.de_clercq@alcatel.be ベルギー
Mark Duffy Sonus Networks 250 Apollo Drive Phone: 1 978-614-8748 Chelmsford, MA 01824 EMail: mduffy@sonusnet.com
マークダフィーSonusネットワーク250アポロは電話を動かします: チェルムズフォード、1 978-614-8748MA 01824はメールされます: mduffy@sonusnet.com
Paul Hitchen BT BT Adastral Park Martlesham Heath Phone: 44-1473-606-344 Ipswich IP53RE EMail: paul.hitchen@bt.com UK
ポールHitchen BT BT AdastralはMartleshamヒース電話を駐車します: 44-1473-606-344 イプスウィッチIP53REはメールします: paul.hitchen@bt.com イギリス
Paul Knight Nortel 600 Technology Park Drive Phone: 978-288-6414 Billerica, MA 01821 EMail: paul.knight@nortel.com
ポールナイトノーテル600技術公園ドライブ電話: 978-288-6414 ビルリカ、MA 01821はメールされます: paul.knight@nortel.com
Fang Informational [Page 41] RFC 4111 PPVPN Security Framework July 2005
[41ページ]RFC4111PPVPNセキュリティフレームワーク2005年7月の情報の牙
12. Acknowledgement
12. 承認
The author and contributors would also like to acknowledge the helpful comments and suggestions from Paul Hoffman, Eric Gray, Ron Bonica, Chris Chase, Jerry Ash, and Stewart Bryant.
また、作者と貢献者はポール・ホフマン、エリック・グレー、ロンBonica、クリス・チェイス、ジェリーAsh、およびスチュワートブライアントから役に立つコメントと提案を承諾したがっています。
13. Normative References
13. 引用規格
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot,
G., and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、マスコウィッツ、B.、Karrenberg、D.、deグルート、G.とE.リア、「個人的なインターネットのためのアドレス配分」BCP5、RFC1918(1996年2月)。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC2246] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header",
RFC 2402, November 1998.
[RFC2402] ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[RFC2406]ケントとS.とR.アトキンソン、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC2406、1998年11月。
[RFC2407] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2407]パイパー、D.、「ISAKMPのための解釈のインターネットIPセキュリティー領域」、RFC2407、1998年11月。
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
G., and B. Palter, "Layer Two Tunneling Protocol
"L2TP"", RFC 2661, August 1999.
[RFC2661]Townsley、W.、バレンシア、A.、ルーベン、A.、祭服、G.、ゾルン、G.、およびB.はあしらいます、「層Twoはプロトコル"L2TP"にトンネルを堀っ」て、RFC2661、1999年8月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC2865] Rigney、C.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、「ユーザサービス(半径)におけるリモート認証ダイヤル」、RFC2865(2000年6月)。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September
2003.
[RFC3588] カルフーンとP.とLoughneyとJ.とGuttmanとE.とゾルン、G.とJ.Arkko、「直径基地のプロトコル」、RFC3588、2003年9月。
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC
Cipher Algorithm and Its Use with IPsec", RFC 3602,
September 2003.
[RFC3602] フランケル、S.、グレン、R.、およびS.ケリー、「AES-CBCはIPsecと共にアルゴリズムとその使用を解きます」、RFC3602、2003年9月。
Fang Informational [Page 42] RFC 4111 PPVPN Security Framework July 2005
[42ページ]RFC4111PPVPNセキュリティフレームワーク2005年7月の情報の牙
[STD62] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC
3411, December 2002.
[STD62] ハリントン、D.、Presuhn、R.、およびB.Wijnen、「簡単なネットワーク管理プロトコル(SNMP)管理フレームワークについて説明するためのアーキテクチャ」、STD62、RFC3411(2002年12月)。
Case, J., Harrington, D., Presuhn, R., and B. Wijnen,
"Message Processing and Dispatching for the Simple
Network Management Protocol (SNMP)", STD 62, RFC 3412,
December 2002.
ケース、J.、ハリントン、D.、Presuhn、R.、およびB.Wijnen、「メッセージ処理と簡単なネットワークマネージメントのために急いでいるのは(SNMP)について議定書の中で述べます」、STD62、RFC3412、2002年12月。
Levi, D., Meyer, P., and B. Stewart, "Simple Network
Management Protocol (SNMP) Applications", STD 62, RFC
3413, December 2002.
レビ、D.、マイヤー、P.、およびB.スチュワート、「簡単なネットワーク管理プロトコル(SNMP)アプリケーション」、STD62、RFC3413、2002年12月。
Blumenthal, U. and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
ブルーメンソルとU.とB.Wijnen、「Simple Network Managementプロトコル(SNMPv3)のバージョン3のためのユーザベースのSecurity Model(USM)」、STD62、RFC3414、2002年12月。
Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
Access Control Model (VACM) for the Simple Network
Management Protocol (SNMP)", STD 62, RFC 3415, December
2002.
Wijnen、B.、Presuhn、R.、およびK.McCloghrie、「簡単なネットワークマネージメントのための視点ベースのアクセス制御モデル(VACM)は(SNMP)について議定書の中で述べます」、STD62、RFC3415、2002年12月。
Presuhn, R., "Version 2 of the Protocol Operations for
the Simple Network Management Protocol (SNMP)", STD 62,
RFC 3416, December 2002.
Presuhn、R.、「簡単なネットワークマネージメントのためのプロトコル操作のバージョン2は(SNMP)について議定書の中で述べます」、STD62、RFC3416、2002年12月。
Presuhn, R., "Transport Mappings for the Simple Network
Management Protocol (SNMP)", STD 62, RFC 3417, December
2002.
Presuhn、R.、「簡単なネットワーク管理プロトコル(SNMP)のための輸送マッピング」、STD62、RFC3417、2002年12月。
Presuhn, R., "Management Information Base (MIB) for the
Simple Network Management Protocol (SNMP)", STD 62, RFC
3418, December 2002.
Presuhn、R.、「簡単なネットワーク管理プロトコル(SNMP)のための管理情報ベース(MIB)」、STD62、RFC3418、2002年12月。
[STD8] Postel, J. and J. Reynolds, "Telnet Protocol
Specification", STD 8, RFC 854, May 1983.
[STD8] ポステル、J.、およびJ.レイノルズ(「telnetプロトコル仕様」、STD8、RFC854)は1983がそうするかもしれません。
14. Informative References
14. 有益な参照
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication", RFC 2104,
February 1997.
[RFC2104] Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[RFC2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security
Document Roadmap", RFC 2411, November 1998.
[RFC2411] セイヤーとR.とDoraswamy、N.とR.グレン、「IPセキュリティドキュメント道路地図」、RFC2411、1998年11月。
Fang Informational [Page 43] RFC 4111 PPVPN Security Framework July 2005
[43ページ]RFC4111PPVPNセキュリティフレームワーク2005年7月の情報の牙
[RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm
1 (SHA1)", RFC 3174, September 2001.
[RFC3174]イーストレーク3番目とD.とP.ジョーンズ、「米国安全なハッシュアルゴリズム1(SHA1)」、RFC3174 2001年9月。
[RFC3631] Bellovin, S., Schiller, J., and C. Kaufman, "Security
Mechanisms for the Internet", RFC 3631, December 2003.
2003年12月の[RFC3631]BellovinとS.とシラー、J.とC.コーフマン、「インターネットへのセキュリティー対策」RFC3631。
[RFC3889] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to
Routing Protocols", RFC 3889, October 2004.
2004年10月の[RFC3889]BarbirとA.とマーフィー、S.とY.陽、「ルーティング・プロトコルへのジェネリックの脅威」RFC3889。
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned
Virtual Private Network (VPN) Terminology", RFC 4026,
March 2005.
[RFC4026] アンデションとL.とT.マドセン、「プロバイダーの食糧を供給された仮想私設網(VPN)用語」、RFC4026、2005年3月。
[RFC4031] Carugi, M. and D. McDysan, Eds., "Service Requirements
for Layer 3 Provider Provisioned Virtual Private
Networks (PPVPNs)", RFC 4031, April 2005.
[RFC4031]Carugi(M.とD.McDysan(Eds))は「層3のプロバイダーの食糧を供給された仮想私設網(PPVPNs)のための要件を修理します」、RFC4031、2005年4月。
[RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3
Provider Provisioned Virtual Private Networks", RFC
4110, July 2005.
[RFC4110] CallonとR.とM.鈴木、「層3のプロバイダーのためのフレームワークは仮想私設網に食糧を供給した」RFC4110、2005年7月。
Author's Address
作者のアドレス
Luyuan Fang AT&T Labs. 200 Laurel Avenue, Room C2-3B35 Middletown, NJ 07748
Luyuan牙のAT&T研究室。 ニュージャージー 200ローレルAvenue、余地のC2-3B35ミドルタウン、07748
Phone: 732-420-1921 EMail: luyuanfang@att.com
以下に電話をしてください。 732-420-1921 メールしてください: luyuanfang@att.com
Fang Informational [Page 44] RFC 4111 PPVPN Security Framework July 2005
[44ページ]RFC4111PPVPNセキュリティフレームワーク2005年7月の情報の牙
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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 currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Fang Informational [Page 45]
牙の情報です。[45ページ]
一覧
スポンサーリンク
