Network Working Group L. Fang, Ed.
Request for Comments: 4111 AT&T Labs.
Category: Informational July 2005
Security Framework for
Provider-Provisioned Virtual Private Networks (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).
著作権（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.
この文書では、プロバイダ・プロビジョニングされた仮想プライベートネットワーク（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
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
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.
セキュリティは、プロバイダ・プロビジョニングされた仮想プライベートネットワーク（PPVPN）サービスの一体的な側面です。プロバイダのプロビジョニングレイヤ2の両方の動機と理論的根拠は、VPNとプロバイダ・プロビジョニング・レイヤ3 VPNサービスは、[RFC4110]及び[RFC4031]で提供されます。これらの文書は、セキュリティはVPNの顧客とVPNサービスプロバイダーの両方のために、PPVPNサービスの重要かつ不可欠な側面であることを認めます。どちらも、PPVPNサービスに関連する顧客とプロバイダのセキュリティ要件を示していますPPVPNセキュリティフレームワークドキュメントの恩恵を受ける、それは特定の技術は、セキュリティ上の脅威から保護し、セキュリティ要件を満たしてどのくらい評価するために使用することができます。
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, which is also addressed in this document. Special considerations engendered by IP mobility within PPVPNs are not in the scope of this document.
まず、我々はPPVPNsの文脈に関連するセキュリティの脅威、およびそれらの脅威に対抗するために使用することができ守備のテクニックを説明します。私たちは、ユーザおよび他の当事者の悪意のあるまたは誤った動作からとプロバイダの過失や不正な動作の両方から派生するセキュリティ問題を考えます。セキュリティ防衛の重要な部分はまた、本書で扱われているセキュリティ攻撃の検出とレポートです。 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は、セキュリティ上の考慮事項について説明します。
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特有の用語を使用しています。 PPVPNの用語に特定の定義および詳細は[RFC4026]及び[RFC4110]に見出すことができます。最も重要な定義は、このセクションで繰り返され、他の定義については、読者は[RFC4026]及び[RFC4110]と呼ばれます。
CE: Customer Edge device, a router or a switch in the customer network interfacing with the service provider's network.
CE：カスタマーエッジデバイス、ルータやサービスプロバイダのネットワークとのインターフェースを顧客ネットワーク内のスイッチ。
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：プロバイダールータ。プロバイダールータは、直接顧客に向けインターフェースを持っていないサービスプロバイダのコアネットワーク内のルータです。 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：プロバイダーエッジデバイス、顧客のネットワーク内の機器とのインタフェースとサービスプロバイダのネットワーク内の機器。
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：プロバイダ・プロビジョニングされた仮想プライベートネットワーク、（顧客自身によるひいてはいない）設定および管理サービスプロバイダによってれる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：仮想プライベートネットワーク、に行くか、これらのサイトから来ていないトラフィックが共有するIPバックボーンを使用してサイトのセットとの間の通信を制限します。
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コアネットワークは、一つ以上のSPネットワークから成ります。コアのすべてのネットワーク要素は、一つ以上のPPVPNサービスプロバイダの動作制御下にあります。 PPVPNコアがいくつかのサービスプロバイダによって提供されていても、それは信頼の単一ゾーンとしてPPVPNユーザに表示されます。しかし、一般的なPPVPNコアを提供するいくつかのサービスプロバイダは、まだ他のプロバイダに対して自身を確保する必要があります。 PPVPNサービスは、インターネットをPPVPNコアの論理的な部分を形成する場合には、インターネットを介して配信することができます。
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.
エクストラネットは、複数のサイトが異なる（法的）事業体によって制御されているVPNのです。エクストラネットは制限され、制御された通信は、多くの場合、明確に定義された通過点を介して、信頼されたゾーン間で許可される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を定義します。主な関心事は、「内部」このゾーンのに信頼ゾーンの「外」からのセキュリティの侵害に関連するセキュリティの側面です。図1は、PPVPNの枠組みの中で、信頼ゾーンの概念を示しています。
+------------+ +------------+
| PPVPN +-----------------------------+ PPVPN |
| user PPVPN user |
| site +---------------------XXX-----+ site |
+------------+ +------------------XXX--+ +------------+
| PPVPN core | | |
+------------------| |--+
| |
| +------\
+--------/ Internet
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.
「仮想プライベート」ネットワーク（VPN）の重要な要件は、VPNの信頼ゾーンのセキュリティは他の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 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ネットワークのプロビジョニングは、このサーバーのセキュリティに違いを作ることができない限り、例えば、インターネットから与えられたPPVPN内部のWebサーバへの攻撃は、ここでは考慮されません。
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インフラストラクチャ上の攻撃が成功すると、以下の悪影響の一つ以上を引き起こすことがあります。
- 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,
- 同じPPVPNサービスプロバイダーによって提供される他のPPVPNsのユーザー、
- 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 same service provider may be able to launch attacks that those who are completely outside the network cannot.
PPVPNsの場合は、一部の締約国は、他の人に利用できない攻撃の種類を起動するためにそれらを可能にするより有利な位置にあってもよいです。例えば、同じサービスプロバイダによって提供される異なるPPVPNsのユーザーがネットワーク外に完全にしている人がいないことを攻撃を開始することができるかもしれません。
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
セキュリティは、一般的に費用とリスクとの間の妥協点であることを考えると、さまざまな攻撃の可能性を検討することも有用です。首尾異なる環境で実装された攻撃のほとんどの種類の可能性が認識される違いは、次のような、少なくともあり
- in a PPVPN contained within one service provider's network, or
- 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を脅かす悪用特定の種類を議論します。
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ユーザサイトに実行して、制御プレーントラフィックであるかもしれないことに留意されたいです。
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パケットを「盗聴」とその内容を調べるに言及します。これは、機密情報の暴露につながることができます。また、記録されたデータが変更され、再挿入、または変化しない再挿入されている（後述）の攻撃の最初のステップであることができます。
This refers to modifying the contents of packets as they traverse the VPN.
これは、VPNを横断するようにパケットの内容を変更することをいいます。
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 the insertion of copies of once-legitimate packets that have been recorded and replayed.
これは、彼らが受信者によって正当なものとして受け入れたことを目的に、そこに属していないパケットのVPNへの挿入（または「なりすまし」）を指します。また、このカテゴリーに含まれて記録され、再生されたかつての正当なパケットのコピーの挿入があります。
This refers to causing packets to be discarded as they traverse the VPN. This is a specific type of Denial-of-Service attack.
これは、VPNを横断するように、パケットが廃棄させることをいいます。これは、サービス拒否攻撃の特定のタイプです。
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ユーザの場合、この種の攻撃は、一般的にこの中で議論される他のタイプよりも懸念の大幅に少ないと考えられているトラフィック、パケットサイズ、送信元と送信先のアドレスの量とタイミングに基づいて有用な情報などを得るかもしれませんセクション。
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.
資源枯渇型のDoS攻撃は、そのVPNの外部からVPNへの非真正データの圧倒的な量（なりすまし）を挿入しようとすることによって、特定のPPVPNのデータプレーンに対して取り付けることができます。潜在的な結果は、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を破壊することができるかもしれません。）
This category encompasses attacks on the control structures operated by the PPVPN service provider.
このカテゴリはPPVPNサービスプロバイダーが運営する制御構造への攻撃を包含する。
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.
制御プレーンDoS攻撃は、サービスプロバイダがPPVPNsを提供するために使用するメカニズムに対して特異的に装着することができる（例えば、IPsecの、MPLS）またはサービスプロバイダの一般的なインフラストラクチャ（例えば、PルータまたはPEルータの共有側面）に対する攻撃に対する一般的なインフラは、攻撃が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.
次のセクションで説明された攻撃には、それぞれの効果の一つとして、サービス拒否を有することができます。その他のDoS攻撃も可能です。
4.2.2. Attacks on Service Provider Equipment via Management Interfaces
4.2.2. 管理インターフェイスを経由してサービスプロバイダーの機器に対する攻撃
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.
これは順番に、例えば、装置を再構成する、または1つ以上のPPVPNsに関する情報（統計情報、トポロジなど）を抽出するために、サービス・プロバイダ・インフラ機器への不正なアクセスを含みます。
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に固有の組織分割（顧客、サービスプロバイダが）それが簡単にプロバイダプロビジョニングに対するこのような攻撃をマウントするために作ることが観察されます
VPNs than against VPNs that are self-provisioned by the customer at the IP layer.
セルフプロビジョニングIP層での顧客であるのVPNに対してよりVPNを。
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,
- 複数のVPNが不適切にマージされ、
- 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).
誤接続またはVPNの相互接続は、サービスプロバイダーや機器ベンダーエラーによって、または攻撃者の悪質な行為によって引き起こされ得ます。違反が物理的であってもよい（例えば、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ユーザの最大のセキュリティ上の懸念事項の一つである（またはユーザー-だろう）ことを示唆しています。
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つのVPNこれでは、典型的には、会員発見またはあたり-VPN経路の分布に関する。レイヤ2つのVPNでは、これは通常、会員およびエンドポイントの発見に関する。骨格の分配のためのルーティングプロトコルを使用する（非VPN）ルートに対する攻撃は、この文書の範囲を超えています。人気のルーティングプロトコルに対する特定の攻撃は、広く研究されていると、[RFC3889]で説明されています。
"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 black hole routing or unauthorized data plane cross-connection between PPVPNs.
「ルート分離」から分離し、使用できなく、（などの具体的サービス・プロバイダによって意図除く）任意の他のPPVPN各PPVPNごとのVPNトポロジーおよび到達可能性情報を維持するためにここにいいます。この概念は、サービスプロバイダは、VPN内のルーティング（すなわち、VR、BGP-MPLSは、IPsecのバージョンをルーティング）と関与するためのレイヤ3 VPNタイプについてのみ異なるセキュリティ上の問題です。ルート分離で違反がPPVPNについてのトポロジとアドレス情報を明らかにすることができます。また、ブラックホールルーティングまたはPPVPNs間の不正なデータプレーン相互接続を引き起こす可能性があります。
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.
レイヤ3のVPNにおいて、異なるVPNのIPアドレス空間を別々に維持されなければなりません。レイヤ2のVPNにおいて、異なるVPNのMACアドレスとVLAN空間は別々に維持されなければなりません。このアドレッシング分離における制御プレーン違反は、VPN間の不正なデータプレーン相互接続をもたらすことができます。
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:
ルーティングおよび管理プロトコル（前のセクションで別々に覆われた）に加えて、他の制御プロトコルの数は、直接（例えば、種々のPPVPNアプローチにおけるメンバーシップ発見およびトンネル確立のため）PPVPNサービスを提供することに関与し得ます。これらは、これらに限定されないことがあります。
- MPLS signaling (LDP, RSVP-TE), - IPsec signaling (IKE) , - L2TP, - BGP-based membership discovery, and - Database-based membership discovery (e.g., RADIUS-based).
- MPLSシグナリング（LDP、RSVP-TE）、 - IPsecのシグナリング（IKE）、 - L2TP、 - BGPベースのメンバーシップの発見、および - データベースベースのメンバーシップ検出（例えば、RADIUSに基づきます）。
Attacks might subvert or disrupt the activities of these protocols, for example, via impersonation or DoS attacks.
攻撃は、偽装やDoS攻撃を経由して、例えば、これらのプロトコルの活動を破壊または中断される可能性があります。
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.
このドキュメントで説明守備の技術は、いくつかのセキュリティ上の脅威に対処することができる方法を説明することを意図しています。これらは、すべてのPPVPNの実装のための要件として意図されていません。 PPVPNプロバイダーは、プロバイダーの特定のサービスの提供にこれらの技術の適用可能性を判断する必要があり、かつPPVPNのユーザは、ユーザのVPN要件に関してこれらの技術の価値を評価することを望むかもしれません。
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.
何事も100％安全なものはありません。防衛は、それゆえに発生する可能性が最も高いか、それは最も悲惨な結果を持つことができ、これらの攻撃から保護します。これらの攻撃に対する絶対的な保護はめったに達成可能です。多くの場合、敵が費やすことをいとわないものよりも大きい攻撃が成功の費用を作るために十分なものです。
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.
攻撃に対する防衛に成功は必ずしも攻撃が起こってから、あるいはそのターゲットに到達することを防止しなければならないことを意味するものではありません。多くの場合、ネットワークではなく、攻撃に耐えるように設計することができます。例えば、非本物のパケットの導入は、最初の場所での導入を防止することによって、または特定し、PPVPNユーザーのシステムに配信する前にそれらを排除することを可能にすることによりに対して擁護することができます。後者は頻繁にはるかに簡単な作業です。
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防衛は、暗号技術を適切に適用することにより向上させることができます。これらは、一般的なネットワーク通信に適用される同じ暗号化技術です。一般に、これらの技術は、デバイス、デバイスのアイデンティティの認証、及び輸送中の保護されたデータの変化の検出との間の通信の機密性（暗号化）を提供することができます。
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.
プライバシーは任意の仮想プライベートネットワークの重要な部分（ミドルネーム！）です。トラフィック分離と暗号化：PPVPNでは、プライバシーは二つのメカニズムによって提供することができます。このセクションでは、暗号化に焦点を当てて。トラフィックの分離は、別々に扱われます。
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.
暗号化は、複雑さが増し、ひいてはそれがすべてのPPVPNサービス内で標準提供できない場合があります。このため、いくつかの理由があります。暗号化は、暗号化と復号化を実行するデバイスに追加の計算負荷を追加します。これは、潜在的に、プロバイダのコストを押し上げ、デバイス上で処理またはそうでなければ、デバイスの容量を削減することができるユーザのVPN接続の数を減らすことができます。一般的に、デバイス上の暗号化サービスを設定すると、デバイス構成の複雑さに追加し、増分人件費が追加されます。パケットを暗号化することは、典型的には、その増加したオーバーヘッドで、それによってネットワーク・トラフィック負荷とパケットの断片化の可能性を高める、パケット長を増加させます。 （パケット長の増加は、多くの場合、しかし、追加の計算負荷と、データ圧縮技術によって、ある程度緩和することができる。）最後に、いくつかのPPVPNプロバイダは、彼らが認識しないことが、そのような物理的な分離またはフィルタリング/ファイアウォール技術として十分な他の防御技術を採用してもよいです暗号化技術から付加的な利点。
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.
PPVPNユーザ間の信頼モデル、PPVPNプロバイダ、およびネットワークの他の部分は、任意の特定のPPVPNの実装のための暗号化の適用性を決定する上で重要な要素です。
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.
- ユーザのサイトとプロバイダのPE間のデータパスが信頼されていない場合、暗号化は、PE-CEリンク上で使用することができます。
- If some part of the backbone network is not trusted, particularly in implementations where traffic may travel across the Internet or multiple provider networks, then the PE-PE traffic may be encrypted.
- バックボーンネットワークの一部は、特に、トラフィックがインターネットまたは複数のプロバイダネットワークを横切って移動することができる実装では、信頼されていない場合には、PE-PEトラフィックが暗号化されてもよいです。
- 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.
- PPVPNユーザがその建物の外のゾーンを信頼していない場合は、エンド・ツー・エンドまたはCE-CEの暗号化サービスを必要とするかもしれません。 CEはPPVPNプロバイダーによって提供されている場合、このサービスは、このPPVPNセキュリティフレームワークの範囲内に収まります。
- 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.
- PPVPNユーザがPPVPN顧客の場所ではないシステムからPPVPNへのリモートアクセスを必要とする場合（例えば、ユーザーによるアクセス）は、そのシステムとのアクセスポイントの間のトラフィックを暗号化する必要があるかもしれませんPPVPNや顧客サイトで。 PPVPNプロバイダーは、アクセスポイントを提供する場合、顧客は、リモートユーザーのアクセス制御サービスを処理するために、プロバイダと協力しなければなりません。これらのアクセス制御サービスは、通常、同様、暗号化を使用して実装されています。
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.
CE-CEの暗号化は、サードパーティの傍受に対する機密性を提供していますがPPVPNプロバイダーは、CE（暗号化）デバイスを完全に管理制御を持っている場合、プロバイダは、ユーザーのVPNトラフィックや内部ネットワークへのアクセスを得るためにするために、それは可能かもしれません。暗号化デバイスは、潜在的に、ヌル暗号化を使用するように完全に暗号化処理をバイパスする、または暗号化されていないトラフィックを盗聴や流用のいくつかの手段を提供するように構成することができます。このように、CE-CEの暗号化を使用してPPVPNの実装では、PPVPNユーザとプロバイダ間の信頼関係を考慮しなければなりません。 PPVPNのユーザーとプロバイダは、CEデバイス上の暗号化を管理するための責任の許容可能な境界を提供しますCE-CEの暗号化のためのサービスレベル契約（SLA）を交渉することを望むかもしれません。
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.
境界はまた、CEデバイスの機能によって影響を受ける可能性があります。例えば、CEは、管理のいくつかのパーティショニングや設定のロックダウン機能をサポートするかもしれない、またはそれは双方が設定を確認できる場合があります。管理CE-CEモデルが使用されている場合、一般的には、PPVPNユーザはPPVPNプロバイダーが適切に提供することを信頼のかなり高いレベルを持っており、CEデバイスを管理する必要があります。
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]、[RFC3631]で説明したようにIP層（レイヤ3）での暗号化のための選択のセキュリティプロトコルは、です。 IPsecは、デバイスのペアの間のIPトラフィックのための強固なセキュリティを提供します。非IPトラフィックは、IPパケットに変換しなければならない、またはそれは、IPsec上で転送することはできません。カプセル化は、一般的な変換方法です。
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.
PPVPNモデルでは、IPsecはPEとCEの間、またはCEからCEに、PE間のIPトラフィックを保護するために使用することができます。 CE-に-CE IPsecは、プロバイダ・プロビジョニングまたはユーザプロビジョニングモデルのいずれかで使用することができます。ユーザー・プロビジョニングCE-CEのIPsecモデルは、この文書の範囲外とPPVPNワーキンググループの範囲外です。それは単にPPVPNによりユーザデータとして扱われるよう同様に、ユーザのサイト内で実行されるデータの暗号化は、この文書の範囲外です。 IPsecは、リモートユーザーとPPVPN間のIPトラフィックを保護するために使用することができます。
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は、それ自体は、暗号化アルゴリズムを指定していません。そのようなAES暗号化などの様々なキーの長さ、と暗号化アルゴリズムの様々なを使用することができます。キーの長さ、計算負荷、および暗号化のセキュリティのレベル間のトレードオフがあります。これらのトレードオフの完全な議論は、この文書の範囲を超えています。特定のIPsecベースのPPVPNサービスによって提供されるセキュリティのレベルを評価するために、いくつかのPPVPNユーザはPPVPNプロバイダーによって使用される特定の暗号化アルゴリズムと効果的なキーの長さを知りたいことがあります。しかし、実際には、任意の現在推奨IPsec暗号化は、実質的に直接攻撃者が標的とされる可能性を減らすために十分なセキュリティを提供しています。セキュリティのチェーンにおける他、弱い、リンクが最初に攻撃される可能性があります。 PPVPNユーザは、データの機密性を確保するのではなくPPVPNサービスで使用される特定の暗号化技術を分析するためのサービスプロバイダの責任を指定してサービスレベルアグリーメント（SLA）を使用することもできます。
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].
PPVPNプロバイダーのネットワーク制御メッセージと、いくつかのPPVPNユーザの要求の多くにとって、メッセージの内容を暗号化せずにメッセージの暗号化認証は、許容可能なセキュリティを提供することができます。 IPsecで、メッセージの認証は、認証だけで認証ヘッダー（AH）またはカプセル化セキュリティプロトコル（ESP）によって提供されます。制御メッセージは、認証を必要とするが、IPsecを使用しない場合は、他の暗号認証方法が用意されています。現在、安全であると考えられてメッセージ認証方法は、セキュア・ハッシュ・アルゴリズム1（SHA-1）[RFC3174]などのセキュアハッシュアルゴリズムを用いて実施ハッシュメッセージ認証コード（HMAC）[RFC2104]に基づいています。
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.
組み合わせの機密性、データ発信元認証、およびコネクションレス完全性を提供するための1つの推奨される機構は、IPsec ESPとして、明示的な初期化ベクトル（IV）[RFC3602]と暗号ブロック連鎖（CBC）モードでAESを使用することです。
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は、トラフィックのIPsec暗号化といくつかの競合が発生する場合があります。暗号化は、パケットの内容を隠したように、暗号化されていないトラフィックと同じ方法で暗号化されたトラフィックを区別することはできないかもしれません。 DiffServのマーキングは、IPsecヘッダにコピーされ、いくつかの分化を提供することができるが、必ずしもすべてのトラフィックタイプは、この機構によって収容することができます。
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.
PPVPNデバイスの構成および管理のために、IPSecで提供されるものに匹敵するレベルで管理接続の暗号化と認証が望ましいです。
Several methods of transporting PPVPN device management traffic offer security and confidentiality.
PPVPNデバイス管理トラフィックオファーセキュリティと機密性を輸送するいくつかの方法。
- Secure Shell (SSH) offers protection for TELNET [STD8] or terminal-like connections to allow device configuration.
- シェル（SSH）は、デバイスの設定を可能にするためにTELNET [STD8]または端末のような接続のために保護を提供するセキュア。
- SNMP v3 [STD62] provides encrypted and authenticated protection for SNMP-managed devices.
- SNMP v3の[STD62]は、SNMP管理のデバイス用の暗号化と認証された保護を提供します。
- 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.
- トランスポート層セキュリティ（TLS）[RFC2246]と密接に関連するセキュア・ソケット・レイヤー（SSL）が広くHTTPベースの通信を確保し、したがって最もXML-とSOAPベースのデバイス管理のアプローチのためのサポートを提供することができるために使用されます。
- 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.
- 2004年、大規模な作品は、「Webサービス」枠組みの中で、デバイス管理トラフィックを確保する上でいくつかの組織（OASIS、W3C、WS-I、など）で進行されます。この作品は、セキュリティモデルのさまざまなを使用し、複数のセキュリティ・トークン形式、複数の信頼ドメイン、複数の署名形式、および複数の暗号化技術をサポートしています。
- 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はネットワーク層でのセキュリティと機密性とサービスを提供しています。デバイス管理に関しては、現在の使用は、主にユーザー管理IPsecゲートウェイデバイスのインバンド管理に焦点を当てています。
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.
レイヤ2 PPVPNsは、一般的にネットワーク全体の暗号化を提供するために、IPsecを使用することはできません。彼らはそれがIPパケットにカプセル化されたPE-PEトラフィックにIPsecを使用することができるかもしれませんが、IPsecは、一般的にレイヤ2 PPVPNsにCE-PEトラフィックには適用されません。
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.
レイヤ2リンクのための暗号化技術が広く利用されているが、一般的には、この文書またはIETF文書の範囲内ではありません。レイヤ2暗号化は、PEへのCEからのリンクに適用することができ、またはそれは限り、暗号化されたレイヤ2パケットが介在PEデバイスによって適切に処理することができますよう、CEへのCEから適用することができます。また、レイヤ2 VPNによって搬送上層トラフィックは、ユーザによって暗号化することができます。この場合、機密性が維持されます。しかし、これは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.
PPVPNsでは、暗号化は、潜在的に、いくつかの異なる場所でVPNトラフィックに適用することができます。このセクションでは、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.
暗号化は、通常、それらの間を通過するトラフィックを暗号化デバイスのペアを必要とします。デバイスは、直接（単一の「ホップ」の上に）接続することができる、またはデバイスのペアの間の暗号化されたトラフィックを転送するデバイスが介在してもよいです。極端な場合は、所定の経路に沿ってエンドデバイスとの間の指定されたパスまたは「エンドツーエンド」の暗号化に沿ってデバイスのすべての隣接する対の間のホップ・バイ・ホップの暗号化を含みます。 PPVPNsの範囲内でこの議論を保つために、我々は、CEにCEことではなく、完全に最後まで終了し、「エンドツーエンド」の場合を考えます。
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).
図2は、カスタマエッジ（CE）デバイス、プロバイダエッジ（PE）デバイスを示す、簡略化されたPPVPNトポロジーを示し、両者の間の経路に沿って存在するかもしれないプロバイダーコア（P）デバイスの可変数（3が示されています）単一のサービスプロバイダ（SP）が運営する、単一のVPN内のサイト、。
Site_1---CE---PE---P---P---P---PE---CE---Site_2
Figure 2: Simplified PPVPN topology
図2：簡体PPVPNトポロジ
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:
この簡略化されたトポロジ内およびPデバイスは、暗号化に関与することがされていないと仮定して、デバイス間の接続の暗号化を実装するための四つの基本的な実現可能な構成があります。
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）サイトツーサイト（CE-に-CE）：トラフィックは、SPのネットワーク全体に暗号化されるように、暗号化は、2つの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.
2）プロバイダ・エッジ・ツー・エッジ（PE-に-PE）：暗号化は、2つのPEデバイス間で設定することができます。暗号化されていないトラフィックは、顧客のCEから1個のPEで受信されます。それは、それを解読し、他のCEに送信される他のPEにSPのネットワークを介して送信するために暗号化されています。
3) Access link (CE-to-PE): Encryption can be configured between the CE and PE, on each side (or on only one side).
3）アクセスリンク（CEツーPE）：暗号化は各側に（または片側のみに、CEおよびPE間で設定することができます）。
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）構成2）及び3）暗号化は、CEからPEへ、次いでPEからPEへ、次いでPEからCEを実行して、組み合わせることができます。
Among the four feasible configurations, key tradeoffs in considering encryption include the following:
4つの実現可能な構成の中で、暗号化を考える上で重要なトレードオフは、次のものがあります。
- 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?
- デバイスの妥協の脆弱性：攻撃者と仮定すると、デバイスへのアクセスを取得します（または、自由にその構成を変更）することができますが、データが保護されるのでしょうか？
- 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?
- デバイスの設定と管理の複雑さ：NCE、VPNの顧客あたりのサイト数、および多くのデバイス構成を作成または維持する必要があるとどのようにそれらの構成の規模をどのように行うNPE、特定のVPNに参加するPEの数を、与えられましたか？
- 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.
- デバイスの処理負荷：行う必要がありますどのように多くの暗号化や復号化の操作、Pパケット与えられましたか？これは、デバイスの容量と、おそらくエンドツーエンド遅延の考慮事項に影響を与えます。
- Ability of SP to provide enhanced services (QoS, firewall, intrusion detection, etc.): Can the SP inspect the data in order to provide these services?
- 拡張サービス（QoSの、ファイアウォール、侵入検知など）を提供するために、SPの能力：SPは、これらのサービスを提供するためにデータを検査することはできますか？
These tradeoffs are discussed below for each configuration.
これらのトレードオフは、各コンフィギュレーションについては、以下で議論されます。
1) Site-to-site (CE-to-CE) Configurations
1）サイトツーサイト（CE-に-CE）の構成
o Link eavesdropping: Protected on all links.
Oリンクの盗聴：すべてのリンクで保護されました。
o Device compromise: Vulnerable to CE compromise.
Oデバイスの妥協：CEの妥協に対して脆弱。
o Complexity: Single administration, responsible for one device per site (Nce devices), but overall configuration per VPN scales as Nce**2.
O複雑さ：サイトごとに1台のデバイス（NCEデバイス）を担当する単回投与、が、NCE ** 2としてVPNスケールあたりの全体構成。
o Processing load: on each of two CEs, each packet is either encrypted or decrypted (2P).
O処理負荷が2つのCEのそれぞれに、各パケットは、暗号化または復号化（2P）のいずれかです。
o Enhanced services: Severely limited; typically only DiffServ markings are visible to SP, allowing some QoS services.
O拡張サービス：厳しく制限。通常、唯一のDiffServマーキングは、いくつかのQoSサービスをできるように、SPに表示されます。
2) Provider edge-to-edge (PE-to-PE) Configurations
2）プロバイダ・エッジ・ツー・エッジ（PE-に-PE）構成
o Link eavesdropping: Vulnerable on CE-PE links; protected on SP's network links.
Oリンクの盗聴：CE-PEリンク上の脆弱。 SPのネットワークリンク上で保護されています。
o Device compromise: Vulnerable to CE or PE compromise.
Oデバイス妥協：CEまたはPEの妥協に脆弱。
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複雑さ：単回投与。設定するには、NPEデバイス。 （NPEは、典型的にははるかに少ないNCE以上であるので、複数のサイトは、PEデバイスを共有することができる。）全体構成のスケーラビリティPPVPNタイプに依存：暗号化は、VPNコンテキストごとに独立している場合、それは顧客VPN当たりNPE ** 2とスケール。暗号化はPEごとのであれば、それは結合されたすべての顧客のVPNのためのNPE ** 2とスケール。
o Processing load: On each of two PEs, each packet is either encrypted or decrypted (2P).
O処理負荷が2個のPEのそれぞれに、各パケットは、暗号化または復号化（2P）のいずれかです。
o Enhanced services: Full; SP can apply any enhancements based on detailed view of traffic.
Oの拡張サービス：フル; SPは、トラフィックの詳細な図に基づいて任意の機能強化を適用することができます。
3) Access link (CE-to-PE) Configuration
3）アクセスリンク（CEツーPE）構成
o Link eavesdropping: Protected on CE-PE link; vulnerable on SP's network links.
Oリンクの盗聴：CE-PEリンク上で保護されました。 SPのネットワークリンク上の脆弱。
o Device compromise: Vulnerable to CE or PE compromise.
Oデバイス妥協：CEまたはPEの妥協に脆弱。
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複雑：NOメッシュが存在しないように、全体的な構成は、NCEとしてスケール各側の装置構成で2回の投与（顧客及びSP）（NCE + NPEデバイス構成する）、しかし。
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処理負荷：2つのCEのそれぞれには、各パケットを暗号化または復号化されますか。 2個のPEのそれぞれに、各パケットは、暗号化または復号化（4P）のいずれかです。
o Enhanced services: Full; SP can apply any enhancements based on detailed view of traffic.
Oの拡張サービス：フル; SPは、トラフィックの詳細な図に基づいて任意の機能強化を適用することができます。
4) Combined Access link and PE-to-PE (essentially hop-by-hop).
4）複合アクセスリンク及びPE-に-PE（本質的にホップバイホップ）。
o Link eavesdropping: Protected on all links.
Oリンクの盗聴：すべてのリンクで保護されました。
o Device compromise: Vulnerable to CE or PE compromise.
Oデバイス妥協：CEまたはPEの妥協に脆弱。
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複雑：各側の装置構成で2回の投与（顧客及びSP）、（NCE + NPEデバイス構成します）。全体構成のスケーラビリティは、PPVPNの種類によって異なります。暗号化は、VPNコンテキストごとに独立している場合、それは顧客のVPNあたりNPE ** 2とスケール。暗号化は-PEごとであれば、それは結合されたすべての顧客のVPNの2 **としてNPEスケール。
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処理負荷：2つのCEのそれぞれには、各パケットを暗号化または復号化されますか。 2個のPEのそれぞれに、各パケットは、両方の暗号化され、（6P）復号化されます。
o Enhanced services: Full; SP can apply any enhancements based on detailed view of traffic.
Oの拡張サービス：フル; SPは、トラフィックの詳細な図に基づいて任意の機能強化を適用することができます。
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).
- 4のサブセットで構成2及び3は、特定の脅威モデルの下4に適切な代替物であり得ます。これらの結論の残りは1（CE-に-CE）4（合わせアクセスリンクおよびPE-に-PE）とを比較します。
- If protection from link eavesdropping is most important, then configurations 1 and 4 are equivalent.
- リンクの盗聴からの保護が最も重要である場合には、構成1と4は同じです。
- If protection from device compromise is most important and the threat is to the CE devices, both cases are equivalent; if the threat is to the PE devices, configuration 1 is best.
- デバイスの妥協からの保護が最も重要であり、脅威がCEデバイスにある場合は、どちらの場合は同等です。脅威はPEデバイスにある場合は、設定1が最高です。
- 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 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.
- 複雑さを低減することが最も重要であり、ネットワークのサイズが非常に小さい場合は、設定1が最高です。それ以外の場合は、オプション1と4の間の比較は、CEへの通信CEがフルメッシュにし、どのようなツールは、鍵管理のために使用されているどれだけ近いか、などの問題の数に基づいて、比較的複雑です。オプション1が直接通信している各CE-CEペアの設定キーを必要とします。オプション4は、CEおよびPEの両方のデバイス上の設定キーを必要とするが、PEの数は、一般的にCEの数よりもはるかに小さいことから恩恵を提供することができます。
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.
また、いくつかのPPVPNアプローチの下で、4のスケーリングはさらに、すべてのVPNコンテキストを横切るメッシュ同じPE-PEを共有することによって改善されます。 CEデバイスは、PEデバイス、またはその逆よりも構成が簡単であれば4のスケーリング特性を増加または任意の所与の状況に減少させることができます。また、オプション4を用いて、演算誤差の影響が大幅に増加することができます。
- If the overall processing load is a key factor, then 1 is best.
- 全体的な処理負荷が重要な要因である場合は、1が最高です。
- If the availability of enhanced services support from the SP is most important, then 4 is best.
- SPからの拡張サービスサポートの可用性が最も重要である場合には、4が最高です。
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.
迅速な全体的な結論としては、CE-に-CE暗号化は、デバイスの妥協に対する保護を提供し、それが原因次数（n ** 2）メッシュのスケーリングに高度なサービスの追加や運用の複雑さとコストがかかります。
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.
サイトツーサイトホップ・バイ・ホップの暗号化のトレードオフのこの分析は、明示的に複数のプロバイダがPPVPNサービス、公共のインターネットVPN接続、またはリモートアクセスVPNサービスを提供するために協働する例が含まれていませんが、トレードオフの多くは次のようになります類似しました。
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.
いくつかのサービス拒否攻撃または悪意のある設定ミスからセキュリティ問題を防ぐためには、PPVPN内のデバイスは、唯一の有効な情報源からの接続や制御メッセージを受け入れる必要があることが重要です。認証は、メッセージのソースが適切にそれらが通信するPPVPNデバイスによって識別されることを確保するための方法を指します。このセクションでは、送信者認証が必要とされるシナリオを特定することに焦点を当て、それはこれらのシナリオのための認証メカニズムをお勧めします。
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).
暗号化技術（認証と暗号化）は、CPUまたは帯域幅枯渇に基づいていくつかの特別サービス拒否攻撃の種類、リソースの枯渇攻撃から保護することはできません。実際には、認証を解読または確認するために必要な処理は、いくつかのケースでは、これらのリソースの枯渇攻撃の効果を増大させることができます。暗号技術は、しかしながら、状態情報（例えば、TCP SYN攻撃）の枯渇に基づいてリソースの枯渇攻撃に対して有用であり得ます。
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.
このカテゴリには、彼らが期待されるVPNに接続されていることを確認するためのCEのための技術を含みます。これは、各特定のCEおよびPEは実際に期待ピアと通信していることを確認するために、CE-PE認証の技術を含みます。
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の認証を含んでいます。
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).
ピアツーピア認証は、ネットワーク制御プロトコル（例えば、LDP、BGP）のピア認証、および他のピア認証を含む（すなわち、別のずつIPsecセキュリティゲートウェイの認証）。
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 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プロバイダーは実際の認証データベースへのアクセス権を持っていませんが、それは、リモートアクセス認証を提供するために、PPVPNユーザーの代わりにそれを使用することができます。
Specific cryptographic techniques for handling authentication are described in the following sections.
認証を処理するための具体的な暗号化技術は、以下のセクションで説明されています。
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とパスワードのペアを使用すると、公開鍵と秘密鍵のシステムの範囲を含みます。別のアプローチは、デジタル証明書を提供するために、階層的な認証機関システムを使用することです。
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を動作させるに必要な認証シナリオのほとんどのための安全なメカニズムを提供します。
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:
この定義の二つの重要な帰結があります。
- 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.
- ルーティングまたはトラフィックフローの対称性：ファイアウォールは、典型的には、通常、ネットワークトポロジが会話の両側がファイアウォールを通過することを保証するファイアウォールを配置することによって実施されるルーティング対称性を必要とします。フィルタは、逆方向のトラフィックを考慮することなく、1つの方向に流れるトラフィックに応じて動作することができます。
- 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.
- ステートフルネス：それは会話の両側を受けるので、ファイアウォールはその会話に関する情報のかなりの量を得ることができるかもしれないとのアクセスを制御するためにこの情報を使用します。フィルタは、パケットの一方向の流れにいくつかの制限された状態情報を維持することができ、それはファイアウォールできる限り正確に双方向の会話の状態を判断できません。
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.
フィルタ特性は、パケットの特定のパケット又はセットが特定のフィルタに一致するかどうかを決定するために使用されます。
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アドレス、プロトコルフィールド、フラグメントオフセット、及びTOSフィールドを含むことができます。フィルタはまた、TCPヘッダ内のポートフィールドとSYNフィールドとしてTCPやUDPヘッダ内のフィールドを考慮することができます。
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.
ステートフルフィルタは、フィルタが満たされているかどうかを決定するのを助けるために、パケット固有の状態情報を維持します。例えば、デバイスは、断片化したIPパケットの最初のフラグメントにステートレスフィルタを適用される場合があります。フィルタが一致した場合、データユニットIDが記憶されてもよいし、同じパケットの他のフラグメントは、同じフィルタに一致することが考えられます。ファイアウォール技術は、ルータに追加されてもよいが、ステートフルフィルタリングは、より一般的に、ファイアウォールで行われます。
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.
フィルタは、パケットに関連付けられたサービスクラスを設定するために使用されてもよいです。
- 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.
通常のパケットのいくつかのセットを転送するために、だけでなく、指定された他のアドレスまたはインターフェイスにコピーを送信するだけでなく、いくつかのケースで有用です。例えば、これは、合法的傍受機能を実現するために、または侵入検知システムに選択されたパケットを供給するために使用されてもよいです。
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 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.
パケットフィルタの使用で重要な考慮事項は、彼らが暗号化されたデータを運ぶパケットをフィルタリングのためのいくつかのオプションを提供できることです。データ自体にアクセスできないため、唯一のパケットヘッダ情報又は他の暗号化されていないフィールドは、フィルタリングのために使用することができます。
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モデルで、または信頼ゾーンと信頼されていない領域との間の異なる信頼のゾーンとの間を通過するトラフィックを制御するためのメカニズムを提供します。彼らは流れに詳細な分析と論理機能を適用することだけではなく、個々のパケットとすることができるようファイアウォールは一般的に、フィルタよりもはるかに多くの機能を提供します。彼らは、このようなしきい値主導のDoS攻撃防御、ウイルススキャン、またはTCP接続のプロキシとして動作するように複雑なサービス、さまざまなを提供することがあります。他のアクセス制御技術と同様に、ファイアウォールの値はPPVPNコアネットワークのトポロジを明確に理解、ユーザネットワーク、および脅威モデルに依存します。その有効性は明確に定義された内部（セキュア）と外側（安全ではありません）とトポロジによって異なります。
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フレームワーク内で、トラフィックは、典型的には、様々なユーザのVPN間を通過することができません。このVPN間の分離は、通常、ファイアウォールによって行われますが、それは基本的なVPN機構の一部であるされていません。 VPNの総分離の例外は、潜在的に他のVPNから、ユーザのVPNに固有の外部アクセスを許可する「エクストラネット」の場合です。ファイアウォールは、安全なエクストラネットの実装に必要なサービスを提供するために使用することができます。
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では、ファイアウォールは、インターネット接続サービスは、VPNのユーザサイトへのプロバイダによって提供されている場合には、公共のインターネットとユーザの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.
ファイアウォールを使用したもう1つの考慮事項は、彼らは暗号化されたデータを搬送するパケットを処理するためのいくつかのオプションを提供できることです。データ自体にアクセスできないように、唯一のパケットヘッダ情報、暗号化されていない他のフィールド、または暗号化されたパケットのフローの分析は、受け入れまたは暗号化されたトラフィックを拒否の決定を行うために使用することができます。
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ドメイン、フィルタリングやファイアウォール技術内でアクセス可能である場合、管理インターフェイスにアクセスする権限のない帯域内のトラフィックを制限するために使用することができます。デバイスの機能に応じて、これらのフィルタリングやファイアウォール技術は、トラフィックが自分自身を渡すか、個々のPPVPNデバイスの可能性がありますを介して他の装置のいずれかに設定することができます。
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.
VPNのサポートに使用されるインフラストラクチャを保護する一つの方法は、（例えば、インターネットサービスのサポートなど）他の目的のために使用されるリソースからの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 VPNは、インターネットに接続されていない別バックボーン上で実行されてもよい、またはそれらは、インターネットサービスをサポートするために使用されるものとは別のエッジ・ルータを使用することができます。 （インターネット上で提供し、ルーティング不可能にローカル）プライベート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は、ある特定のVPNに特化されているCEデバイスを利用することが一般的です。多くのまたはほとんどの場合、CEベースのVPNは、CEデバイスを相互接続するために、通常のインターネットサービスを利用することができます。
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サービスのための主な理由の一つは、複数のVPNを含む複数のユーザ間のリソースの共有を可能にすることです。このように、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サービスは、異なるVPNによるリソース使用の間に保護を提供することがが重要です。したがって、行儀VPNユーザは、他のVPNによって可能不正行為から保護されるべきです。これは制限がいずれVPNによって使用可能なリソースの量に置かれることを必要とします。例えば、制御トラフィックとユーザデータトラフィックの両方は、レート制限することができます。いくつかの場合において、またはキューの十分に大きな数は、各VPN利用可能であるネットワークの一部で（必要に応じて、及び、VPN内の各VPNおよびCoS）は、別個のキューを利用することができます。このようなリンクの帯域幅とCPUとメモリリソースなどの制御プレーン資源ごとのVPNベースで予約することができます。
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間のプロビジョニングリソースの保護に使用されている技術はまた、インターネットサービスからVPNサービスを保護するために使用することができます。
The use of aggregated infrastructure allows the service provider to benefit from stochastic multiplexing of multiple bursty flows and may also, in some cases, thwart traffic pattern analysis by combining the data from multiple VPNs.
凝集したインフラストラクチャの使用は、サービスプロバイダは、複数のバーストのフローの確率的多重化から利益を得ることができ、また、いくつかのケースでは、複数のVPNからのデータを組み合わせることにより、トラフィックパターンの分析を妨害することができます。
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保証する必要があります。必要な設定のこの大量の設定ミスの可能性につながります。
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.
サービスプロバイダが設定ミスの潜在的な影響を軽減するための場所で業務プロセスを持つことが重要です。 CE-に-CE認証はまた、それが発生したときに設定ミスを検出するために使用することができます。
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のために、意図した接続が大きく働いていることを確認することは、いくつかの意図しないサイトへの接続が存在しないことを保証します。
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.
攻撃事件に関する情報に、特に急速に利用可能な場合、さらなる攻撃からの防御に役立ちます。早い段階で攻撃し、その具体的な目標を識別しやすくするために使用することができます。攻撃者とターゲットについてのこの知識は、さらに、特定の攻撃や攻撃に対する防御を強化するため、または、必要に応じて、特定のターゲットの防御的なサービスを改善するために使用することができます。攻撃に収集された情報は、新規の攻撃タイプに対する防御を特定し、開発に有用である可能性があります。
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.
典型的には、プロバイダエッジ（PE）、カスタマエッジ（CE）、および/またはプロバイダバックボーン（P）デバイスから情報を収集することによって動作するPPVPNsのセキュリティ攻撃を検出するために使用される監視システム。セキュリティ監視システムを積極的にデバイスから情報を取得する機能を持っていなければならない（例えば、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の種類、およびプロバイダと顧客との間のサービス・レベル・アグリーメントの能力に依存します。
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が安全であることを、これらの要件のすべてを満たさなければならないと述べていません。はじめに述べたように、各VPN技術は安全であるためには満たさなければならない特定の要件を定義するには、この文書の範囲内ではありません。
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、インターネットから隔離として「プライベート」を定義します。より具体的には、分離は、以下のセクションで説明されるいくつかの構成要素を有しています。
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は、同じサービスプロバイダー（複数可）からPPVPNサービスを使用する他PPVPNsと干渉することなく、プライベートアドレス範囲[RFC1918]を含む、完全なインターネットアドレスの範囲を使用することができます。インターネットアクセスが提供される場合（例えば、PPVPNサービスを提供される同じサービスプロバイダによって）、NAT機能が必要とされ得ます。
In layer-2 VPNs, the same requirement exists for the layer 2 addressing schemes, such as MAC addresses.
レイヤ2のVPNにおいて、同じ要件は、MACアドレスのようなレイヤ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.
1 PPVPNの切替情報が他のPPVPNsまたはPPVPNコアに影響を与えないように、レイヤ2のVPNにおいて、切替情報は、信頼ゾーン間別々に維持されなければなりません。
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.)
与えられた信頼ゾーンからのトラフィックは、このゾーンを残してはいけませんし、別のゾーンからのトラフィックは、このゾーンに入ることはありませんしなければなりません。ゾーンは、具体的にそのように操作されている場合に例外が行われる（エクストラネットの目的やインターネットアクセスのために、例えばします。）
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サービスの重要なセキュリティ要件の一つは、彼らがプライベートネットワークとして同じレベルの保護を提供することです。
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.
ネットワークは、「仮想」であるという事実は、プライベートネットワーク上の追加の脅威にさらさないでなければなりません。具体的には、信頼ゾーン外の他の部分に新しいインターフェイスを追加してはなりません。このようなインターネットゲートウェイとして知られているインターフェースからの侵入は、この文書の範囲外です。
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）攻撃は、正当なユーザーには使用できないサービスやデバイスを作ることを目指しています。この文書の枠組みの中で、唯一のそれらのDoS攻撃は、VPNを介してネットワークサービスを提供する結果であると考えられています。信頼ゾーンへの標準インタフェースを介して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攻撃に対してより脆弱ではないということです。
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の整合性に違反することは可能であってはなりません。 2つのCEが同じPEに接続されている場合は、1つのCEは、これらのパケットは、このように間違ったPPVPNにそれらを挿入し、他のCEから来ていると信じてPEを作る細工されたパケットを送信するために例えば、それが可能であってはなりません。
This requirement means that data must be cryptographically secured in transit over the PPVPN core network to avoid eavesdropping.
この要件は、データが暗号的に盗聴を避けるためにPPVPNコアネットワーク上でのトランジットで確保しなければならないことを意味しています。
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に属しているふりをすることは不可能です。
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.
転送中のデータは、それが変更または改変が受信機で検出することができるということができないように固定されなければなりません。
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サービスを比較した場合、同等のプライベートサービスも、これらのサービスが含まれている場合このように、これらの要件にのみ適用されています。しかし、VPNは、共有インフラストラクチャ上で動作しているという事実は、プライベートネットワーク環境におけるよりもVPN環境でより重要なこれらの要件の一部を行うことができます。
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.
これらの要件は、両方の偶然や悪意を持っPPVPN利用者と非PPVPN問わず、を含むコアの外側様々な攻撃からPPVPNコアを保護する方法、および2）PPVPNユーザのVPNとサイト身を守る方法）1に焦点を当てています。 PPVPNコアがPPVPNsを提供していないコアよりも攻撃に対して脆弱ではないことに注意してください。ほとんどのユーザーはPPVPNサービスを提供するコアで高いセキュリティ基準を期待している場合のみ、しかし、このようなコアの上にPPVPNサービスを提供することは、追加のセキュリティ要件につながる可能性があります。
- 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 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.
PPVPN技術とインフラストラクチャは、制御プレーンの認証のためのメカニズムをサポートしている必要があります。 IPコアのために、IGPとBGPセッションがTCP MD5やIPsecを使用して認証することができます。 MPLSコアが使用される場合、LDPセッションは、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の伝播は、バックボーンは外部から1つのホップのように見えるようにするために変更することができるが、注意がループ防止のために取られるべきです。これは、トレースルートを介して公開されることから、バックボーンアドレスを防ぎます。しかし、それはまた、エンド・ツー・エンドの障害追跡のための運用要件に照らして評価する必要があります。
An Internet backbone core may be re-engineered to make Internet routing an edge function, for example, by using MPLS label switching for all traffic within the core and possibly by making the Internet a VPN within the PPVPN core itself. This helps detach Internet access from PPVPN services.
インターネットバックボーンコアは、インターネットは、コア内およびおそらくインターネットPPVPNコア自体の内部VPNを行うことで、すべてのトラフィックのためのスイッチングMPLSラベルを用いて、例えば、エッジ機能をルーティングするために再設計されてもよいです。これは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).
その性質上、PEは外のユーザーに到達不能にすることはできません、ので、PEは、多くの場合、Pルータよりも攻撃に対してより脆弱です。コアトランクリソースへのアクセスは、インバウンド速度制限/シェーピングを適用することによって、ユーザーごとに制御することができます。これはさらに、クラスごとのサービスに基づいて向上させることができる（セクション8.2.3を参照してください）。
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やメモリなどのリソースが、さらにアプリケーションに、あるいは個々のVPNに基づいて分離することができる場合はさらに、それは、個々の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サービスに適用されます。
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、およびフレームリレーネットワークでは、暗号化は、基本的な機能として提供されていません。メカニズムは、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ユーザに提供するために使用することができます。
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認証がのeBGPを使用して、PE-CEリンク上のセキュリティを強化するために使用することができます。 IPsecなどのASとの間の相互プロバイダー接続、認証/暗号化メカニズムの場合には、使用されてもよいです。
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.
ファイアウォール/フィルタリング：アクセス制御メカニズムは、サービスプロバイダのインフラプレフィックス宛てのすべてのパケットをフィルタリングするか、不正として識別ルートを排除するために使用することができます。
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サービスとインターネットサービスの両方をサポートしている場合、これは非常に有用です。
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ベースのソリューションは、顧客のPPVPN認証サーバとPE自体または相互作用による直接認証のいずれかのための柔軟性が必要です。メカニズムは単に認証フェーズに関して交換および他の属性（RADIUSの例えば、任意のフィルタでそれを制限することにより、PE及び顧客認証サーバとの間の相互作用は、例えば、制御されることを保証するために、後者の場合には必要とされています）。
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間のルーティングプロトコルレベル（例えば、RIP、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.
- ごとのアクセスに基づいてPEにアドバタイズすることができるプレフィクスの数を制限します。制限を超過しなければならない適切な処置をとることができます。例えば、PEはCEにピアセッションをシャットダウンするかもしれません。
- Applying route dampening at the PE on received routing updates.
- 受信したルーティングアップデート上のPEに減衰経路を適用します。
- Definition of a per-VPN prefix limit, after which additional prefixes will not be added to the VPN routing table.
- 付加的なプレフィックスがVPNルーティングテーブルに追加されませんその後当たり-VPNプレフィックス限界の定義。
In the case of inter-provider connection, access protection, link authentication, and routing policies as described above may be applied. Both inbound and outbound firewall/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.
インタープロバイダ接続、アクセス保護、リンク認証、及び上述のようにルーティングポリシーの場合にも適用することができます。インバウンドとアウトバウンドの両方のファイアウォール/フィルタリング機構は、AS間適用されてもよいです。適切なセキュリティ手順は、プロバイダのネットワークインフラストラクチャとその顧客VPNを保護するためにインタープロバイダVPN相互接続で実装する必要があります。これは、カスタムの各インタープロバイダVPNのピアリング接続用に設計されてもよいし、両方のプロバイダはそれに同意しなければなりません。
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コアに進入シェーピングなど、クラスごとのサービスレート制限/トラフィックのようメカニズムは、このレベルの制御を提供する一つの選択肢です。そのようなメカニズムは、マーキングリマーク、またはプロファイル外のトラフィックを廃棄することによって実施されるクラスごとのサービスのプロファイルを必要とし得ます。
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.
コア上のVPN固有の統計情報の視認性（例えば、ルーティングテーブル、インターフェイスステータス、QoS統計情報）を要求するエンドユーザは、着信ユーザを検証するために、その特定のユーザのVPNに使用可能なビューを制限するために、両方のPEでのメカニズムのための要件を課します。メカニズムはまた、そのようなアクセスはPE自体に（悪意のあるまたは偶発いずれか）DoS攻撃を作成するために使用することができないことを確実にするために考慮されるべきです。これは、これらのリソースの分離を介してPE自体の内部またはあたり-VPNに基づいてレート制限このようなトラフィックの能力のいずれかを介して達成することができます。
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.
使用される技術に応じて、セクション7に記載されているようにPPVPNプロバイダーは、ユーザーのセキュリティ要件をサポートする必要があり、これらの要件は、以下のものが挙げられます。
- User control plane separation: Routing isolation.
- ユーザ制御プレーンの分離：ルーティング分離。
- User address space separation: Supporting overlapping addresses from different VPNs.
- ユーザーのアドレス空間の分離：異なるVPNから重複アドレスをサポート。
- User data plane separation: One VPN traffic cannot be intercepted by other VPNs or any other users.
- ユーザーデータプレーンの分離：ワンVPNトラフィックが他のVPNや他のユーザーによって傍受することはできません。
- 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.
セキュリティ侵害につながる機器におけるハードウェアやソフトウェアのバグは、この文書の範囲外です。
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セキュリティフレームワークに対して、最大測定方法を要約するために使用することができる簡単なテンプレートを提供します。このテンプレートを使用した評価は、各PPVPNアプローチのための適用性声明に表示されます。
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:
テンプレートの最初の部分は、セキュリティアサーションのリストの形式です。各アサーションについてアプローチが評価され、次の評価の一つ以上が割り当てられます。
- 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アプローチの範囲を超えた方法で対処されます。 （説明）（この一例は、いくつかの態様は、そのような会員発見として、構成を介して行われているVPNアプローチであろう。構成に与えられる保護は、VPNのアプローチの範囲を超えるであろう。）。
- The VPN approach does not meet the requirement.
- VPNのアプローチが要件を満たしていません。
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のアプローチは、各L3 VPNのための完全なIPアドレス空間の分離を提供します。
2. The approach provides complete L2 address space separation for each L2 VPN.
2.アプローチは、各L2 VPNのための完全なL2アドレス空間分離を提供します。
3. The approach provides complete VLAN ID space separation for each L2 VPN.
3.アプローチは、各L2 VPNのための完全なVLAN ID空間分離を提供します。
4. The approach provides complete IP route separation for each L3 VPN.
4.アプローチは、各L3 VPNのための完全なIPルート分離を提供します。
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.
前記アプローチは、別々のVPNのサイトの不適切な相互接続を防止する手段を提供します。
7. The approach provides a means to detect improper cross-connection of sites in separate VPNs.
7.アプローチは、別々のVPNのサイトの不適切な相互接続を検出する手段を提供します。
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.アプローチは、各VPN Aに不正パケットの導入から保護します。 CE-PEリンクにおいて、B。単一または複数のプロバイダPPVPNバックボーン、またはcインチインターネットでPPVPNバックボーンとして使用します。
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.アプローチはPPVPN利用者データaの機密性（機密性）保護を提供します。 CE-PEリンクにおいて、B。単一または複数のプロバイダPPVPNバックボーン、またはcインチインターネットでPPVPNバックボーンとして使用します。
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ユーザデータの送信者の認証を提供します。 A。 CE-PEリンクにおいて、B。単一または複数のプロバイダPPVPNバックボーン、またはcインチインターネットでPPVPNバックボーンとして使用します。
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.アプローチはPPVPNユーザデータaのための完全性保護を提供します。 CE-PEリンクにおいて、B。シングルまたはマルチプロバイダのPPVPNバックボーン、またはcインチインターネットでPPVPNバックボーンとして使用します。
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.アプローチはPPVPN利用者データaのリプレイ攻撃に対する保護を提供します。 CE-PEリンクにおいて、B。単一または複数のプロバイダPPVPNバックボーン、またはcインチインターネットでPPVPNバックボーンとして使用します。
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.アプローチはPPVPN利用者データaの不正トラフィックパターン分析に対する保護を提供します。 CE-PEリンクにおいて、B。単一または複数のプロバイダPPVPNバックボーン、またはcインチインターネットでPPVPNバックボーンとして使用します。
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).
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.
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。データプレーンや制御プレーン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。データプレーンや制御プレーンDoS攻撃に対するPPVPN利用者の保護は、インターネットからまたは他の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.
b. Protection against high levels of, or malicious design of, network management traffic from PPVPN user networks to the service provider network.
B。高レベルの、またはサービスプロバイダのネットワークへのPPVPNユーザネットワークからの悪意のあるの設計、ネットワーク管理トラフィックに対する保護。
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.特にこのテンプレートで扱われていない任意のアプローチ固有の脆弱性へのアプローチの対象ですか？その場合、もしあれば、アプローチはそれぞれに提供することを、防衛または軽減を記述する。
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機器を圧倒している見られています。運用/プロビジョニングエラーが全盛期の懸念の一つとして、サービスプロバイダによって引用されています。
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技術ソリューションの作者が使用するためのテンプレートが含まれています。
The following people made major contributions to writing this document: Michael Behringer, Ross Callon, Fabio Chiussi, Jeremy De Clerque, Paul Hitchen, and Paul Knignt.
マイケル・ベリンガー、ロスCallon、ファビオChiussi、ジェレミー・デ・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
マイケル・ベリンガーシスコエンタープライズヴィレッジグリーンサイド、電話：+ 400 33.49723から2652アベニューRoumanilleバット。 T 3電子メール：mbehring@cisco.com 06410ビオ、ソフィアアンティポリス、フランス
Ross Callon Juniper Networks 10 Technology Park Drive Phone: 978-692-6724 Westford, MA 01886 EMail: rcallon@juniper.net
ロスCallonジュニパーネットワークスの10テクノロジーパークドライブ電話：978-692-6724ウェストフォード、MA 01886 Eメール：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から8965 Airvana社の電子メール：fabio@airvananet.com 19アルファロードチェルムズフォード、マサチューセッツ州01824
Jeremy De Clercq Alcatel Fr. Wellesplein 1, 2018 Antwerpen EMail: jeremy.de_clercq@alcatel.be Belgium
ジェレミー・デ・Clercqアルカテル神父Wellesplein 1、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
マーク・ダフィーソナス・ネットワーク250アポロドライブ電話：1 978-614-8748チェルムズフォード、MA 01824 Eメール：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 Eメール：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 Eメール：paul.knight@nortel.com
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、クリス・チェイス、ジェリー・アッシュ、およびスチュワートブライアントから有益なコメントや提案を承認したいと思います。
[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.、グルート、G.、およびE.リアド、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246]ダークス、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[RFC2402]ケント、S.とR.アトキンソン、 "IP認証ヘッダー"、RFC 2402、1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 2406、1998年11月。
[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
"ISAKMPのための解釈のインターネットIPセキュリティー領域" [RFC2407]パイパー、D.、RFC 2407、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. Palter、 "レイヤ2トンネリングプロトコル "L2TP""、RFC 2661、1999年8月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
、RFC 2865、2000年6月 "ユーザーサービス（RADIUS）でリモート認証ダイヤル" [RFC2865] Rigney、C.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588]カルフーン、P.、Loughney、J.、ガットマン、E.、ゾルン、G.、およびJ. Arkko、 "直径ベースプロトコル"、RFC 3588、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での使用"、RFC 3602、2003年9月。
[STD62] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[STD62]ハリントン、D.、Presuhn、R.、およびB. Wijnenの、 "簡易ネットワーク管理プロトコル（SNMP）管理フレームワークを記述するためのアーキテクチャ"、STD 62、RFC 3411、2002年12月。
Case, J., Harrington, D., Presuhn, R., and B. Wijnen,
"Message Processing and Dispatching for the Simple
Network Management Protocol (SNMP)", STD 62, RFC 3412,
December 2002.
Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002.
レヴィ、D.、マイヤー、P.、およびB.スチュワート、 "簡易ネットワーク管理プロトコル（SNMP）アプリケーション"、STD 62、RFC 3413、2002年12月。
Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
ブルーメンソール、U.とB. Wijnenの、 "ユーザベースセキュリティモデル（USM）簡易ネットワーク管理プロトコル（SNMPv3の）のバージョン3のために"、STD 62、RFC 3414、2002年12月。
Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002.
Wijnenの、B.、Presuhn、R.、およびK. McCloghrie、 "ビューベースアクセス制御モデル（VACM）簡易ネットワーク管理プロトコル（SNMP）のために"、STD 62、RFC 3415、2002年12月。
Presuhn, R., "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002.
Presuhn、R.、STD 62、RFC 3416、2002年12月 "簡易ネットワーク管理プロトコル（SNMP）のためのプロトコル操作のバージョン2"。
Presuhn, R., "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002.
、STD 62 Presuhn、R.、 "簡易ネットワーク管理プロトコル（SNMP）のためのマッピングを輸送します"、RFC 3417、2002年12月。
Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002.
、STD 62、RFC 3418、2002年12月Presuhn、R.、 "簡易ネットワーク管理プロトコル（SNMP）管理情報ベース（MIB）"。
[STD8] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
【STD8]ポステル、J.、およびJ.レイノルズ、 "テルネットプロトコル仕様"、STD 8、RFC 854、1983年5月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、ベラー、M.、およびR.カネッティ、 "HMAC：メッセージ認証のための鍵付きハッシュ化"、RFC 2104、1997年2月。
[RFC2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[RFC2411]セイヤー、R.、Doraswamy、N.、およびR.グレン、 "IPセキュリティドキュメントロードマップ"、RFC 2411、1998年11月。
[RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.
[RFC3174]イーストレーク第3、D.とP.ジョーンズ、 "米国はハッシュアルゴリズム1（SHA1）を確保"、RFC 3174、2001年9月。
[RFC3631] Bellovin, S., Schiller, J., and C. Kaufman, "Security Mechanisms for the Internet", RFC 3631, December 2003.
"インターネットのセキュリティメカニズム" [RFC3631] Bellovin氏、S.、シラー、J.、およびC.カウフマン、RFC 3631、2003年12月。
[RFC3889] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 3889, October 2004.
[RFC3889] Barbir、A.、マーフィー、S.、およびY.ヤン、 "ルーティングプロトコルへの一般的な脅威"、RFC 3889、2004年10月。
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, March 2005.
[RFC4026]アンデションとL.とT.マドセン、 "プロバイダーのプロビジョニングされた仮想プライベートネットワーク（VPN）用語"、RFC 4026、2005月。
[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編、RFC 4031、2005年4月、 "レイヤ3プロバイダプロビジョニングされた仮想プライベートネットワーク（PPVPNs）のためのサービスの要件"。
[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プロバイダのための枠組み"、RFC 4110、2005年7月。
Author's Address
著者のアドレス
Luyuan Fang AT&T Labs. 200 Laurel Avenue, Room C2-3B35 Middletown, NJ 07748
Luyuan牙AT＆T研究所。 200ローレルアベニュー、ルームC2-3B35ミドルタウン、NJ 07748
Phone: 732-420-1921 EMail: luyuanfang@att.com
電話：732-420-1921 Eメール：luyuanfang@att.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。