[要約] RFC 4111は、プロバイダ提供の仮想プライベートネットワーク（PPVPN）のセキュリティフレームワークに関するものです。このRFCの目的は、PPVPNのセキュリティ要件とアーキテクチャを定義し、安全な通信を確保することです。
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)
プロバイダーがプロビジョニングされた仮想プライベートネットワークのセキュリティフレームワーク（PPVPNS）
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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のコンテキストで関連するセキュリティの脅威と、それらの脅威と戦うために使用できる防御技術について説明します。ユーザーや他の関係者の悪意のあるまたは誤った行動の両方、およびプロバイダーの過失または誤った行動の両方から派生したセキュリティの問題を検討します。セキュリティ防衛の重要な部分は、このドキュメントでも対処されているセキュリティ攻撃の検出とレポートです。PPVPN内の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コアネットワークは、1つ以上のSPネットワークで構成されています。コア内のすべてのネットワーク要素は、1つ以上の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:
このセクションでは、PPVPNを危険にさらす可能性のあるさまざまなネットワークセキュリティの脅威について説明します。議論は、PPVPNに固有の脅威に限定されているか、ユニークな方法でPPVPNに影響を与えます。特定のPPVPNまたはサービスプロバイダーのPPVPNインフラストラクチャに対する攻撃が成功すると、次の1つ以上の悪影響が生じる可能性があります。
- observation, modification, or deletion of PPVPN user data,
- PPVPNユーザーデータの観察、変更、または削除、
- replay of PPVPN user data,
- ppvpnユーザーデータのリプレイ、
- injection of non-authentic data into a PPVPN,
- 非受典データのPPVPNへの注入、
- traffic pattern analysis on PPVPN traffic,
- PPVPNトラフィックに関するトラフィックパターン分析、
- disruption of PPVPN connectivity, or
- PPVPN接続の破壊、または
- degradation of PPVPN service quality.
- PPVPNサービス品質の劣化。
It is useful to consider that threats to a PPVPN, whether malicious or accidental, may come from different categories of sources. For example they may come from:
PPVPNに対する脅威は、悪意のあるものであろうと偶発的であろうと、さまざまなカテゴリのソースから来る可能性があることを考慮すると便利です。たとえば、それらは次のとおりです。
- users of other PPVPNs provided by the same PPVPN service provider,
- 同じPPVPNサービスプロバイダーによって提供される他のPPVPNのユーザー、
- the PPVPN service provider or persons working for it,
- PPVPNサービスプロバイダーまたはそれのために働いている人、
- other persons who obtain physical access to a service provider site,
- サービスプロバイダーサイトへの物理的なアクセスを取得する他の人、
- other persons who use social engineering methods to influence behavior of service provider personnel,
- ソーシャルエンジニアリング方法を使用してサービスプロバイダーの担当者の行動に影響を与える他の人、
- users of the PPVPN itself, i.e., intra-VPN threats (such threats are beyond the scope of this document), or
- PPVPN自体のユーザー、つまりVPN内の脅威（このような脅威はこのドキュメントの範囲を超えています）、または
- others, i.e., attackers from the Internet at large.
- その他、つまり、インターネット全体からの攻撃者。
In the case of PPVPNs, some parties may be in more advantageous positions that enable them to launch types of attacks not available to others. For example, users of different PPVPNs provided by the same service provider may be able to launch attacks that those who are completely outside the network cannot.
PPVPNSの場合、一部の当事者は、他の関係者が利用できない種類の攻撃を開始できるようにするより有利な位置にある場合があります。たとえば、同じサービスプロバイダーによって提供される異なるPPVPNのユーザーは、ネットワークの外にいる人ができない攻撃を開始できる場合があります。
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
- 1つのサービスプロバイダーのネットワーク内に含まれるPPVPN、または
- in a PPVPN transiting the public Internet.
- PPVPNでパブリックインターネットを通過します。
Most types of attacks become easier to mount, and hence more likely, as the shared infrastructure that provides VPN service expands from a single service provider to multiple cooperating providers, and then to the global Internet. Attacks that may not be sufficiently likely to warrant concern in a closely controlled environment often merit defensive measures in broader, more open environments.
VPNサービスを提供する共有インフラストラクチャが単一のサービスプロバイダーから複数の協力プロバイダーに、そしてグローバルインターネットに拡大するため、ほとんどのタイプの攻撃が容易になるため、より可能性が高くなります。密接に制御された環境での懸念を十分に保証する可能性が十分にない可能性がある攻撃は、しばしばより広範でオープンな環境で防御策に値することがよくあります。
The following sections discuss specific types of exploits that threaten PPVPNs.
次のセクションでは、PPVPNを脅かす特定のタイプのエクスプロイトについて説明します。
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ユーザーは、ネットワークデータプレーンリソースを独占し、他のPPVPNを破壊することができる場合があります。）
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など）を提供するために使用するメカニズムまたはサービスプロバイダーの一般的なインフラストラクチャ（PEルーターのPルーターまたは共有側面など）に対して特別に取り付けることができます。一般的なインフラストラクチャは、VPNサービスに関連して攻撃が発生した場合にのみ、このドキュメントの範囲内にあります。それ以外の場合、それらはPPVPN固有の問題ではありません。
Of special concern for PPVPNs is denial of service to one PPVPN user caused by the activities of another. This can occur, for example, if one PPVPN user's activities are allowed to consume excessive network resources of any sort that are also needed to serve other PPVPN users.
PPVPNSの特別な懸念は、別のアクティビティによって引き起こされる1人のPPVPNユーザーに対するサービスの拒否です。これは、たとえば、1つのPPVPNユーザーのアクティビティが、他のPPVPNユーザーにサービスを提供するために必要なあらゆる種類の過剰なネットワークリソースを消費することが許可されている場合に発生する可能性があります。
The attacks described in the following sections may each have denial of service as one of their effects. Other DoS attacks are also possible.
以下のセクションで説明されている攻撃は、それぞれがその効果の1つとしてサービスの拒否を持っている可能性があります。他のDOS攻撃も可能です。
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つ以上のPPVPNについて情報（統計、トポロジなど）を抽出するために、サービスプロバイダーインフラストラクチャ機器への不正アクセスが含まれます。
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固有の問題ではありません。）
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 VPNs than against VPNs that are self-provisioned by the customer at the IP layer.
サービスプロバイダーネットワークが再構成または破損している攻撃、または機密情報が不適切に開示されている攻撃は、サービスプロバイダー担当者の操作を通じてマウントされる場合があります。これらのタイプの攻撃は、PPVPNサービングメカニズムに影響する場合、PPVPN固有です。PPVPNSに固有の組織分割（顧客、サービスプロバイダー）は、IPレイヤーで顧客が自己プロビジョニングするVPNよりも、プロバイダープロビジョニングVPNに対するそのような攻撃を容易にすることができることが観察される場合があります。
This refers to events where expected isolation between separate PPVPNs is breached. This includes cases such as:
これは、個別のPPVPN間の予想される分離が侵害されているイベントを指します。これには、次のようなケースが含まれます。
- a site being connected into the "wrong" VPN,
- 「間違った」VPNに接続されているサイト、
- two or more VPNs being improperly merged,
- 不適切にマージされている2つ以上の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ユーザー（またはユーザーになりたいユーザー）の最大のセキュリティ上の懸念の1つであることを示唆しています。
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 VPNSでは、これは通常、メンバーシップとエンドポイントの発見に関連しています。バックボーン（非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内のルーティングに関与しているレイヤー-3 VPNタイプの明確なセキュリティの懸念にすぎません（つまり、VR、BGP-MPLS、ルーティングバージョンのIPSEC）。ルート分離の違反は、トポロジーを明らかにし、PPVPNに関する情報に対処することができます。また、ブラックホールルーティングまたはPPVPN間の不正なデータプレーンの相互接続を引き起こす可能性があります。
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では、トラフィックの分離と暗号化という2つのメカニズムによってプライバシーを提供できます。このセクションでは、暗号化に焦点を当てています。交通分離は別々に対処されます。
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.
- このサービスは、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トラフィックまたは内部ネットワークにアクセスできる可能性があります。暗号化デバイスは、null暗号化を使用し、暗号化処理を完全にバイパスするか、暗号化されていないトラフィックを嗅ぎ、または迂回させるための何らかの手段を提供するように構成する可能性があります。したがって、CE-CE暗号化を使用したPPVPN実装では、PPVPNユーザーとプロバイダーの間の信頼関係を考慮する必要があります。PPVPNユーザーとプロバイダーは、CE-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、PEとCEの間、またはCEからCEまでのIPトラフィックを保護することができます。CE-To-CE IPSECは、プロバイダーがプロビジョニングしたモデルまたはユーザーがプロビジョニングしたモデルのいずれかで採用できます。ユーザーがプロビジョニングしたCE-CE-CEIPSECモデルは、このドキュメントの範囲外で、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プロバイダーが使用する特定の暗号化アルゴリズムと有効なキー長を知ることをお勧めします。ただし、実際には、現在推奨されている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.
IPSEC ESPのように、明示的な初期化ベクトル（IV）[RFC3602]を使用した、Cipherブロックチェーン（CBC）モード（CBC）モードでのAEの使用が、IPSEC ESPとして、Cipherブロックチェーン（CBC）モードでのAEの使用です。
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.
トラフィックタイプに基づいて差別化されたサービスを提供するPPVPNは、トラフィックの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.
- Secure Shell（SSH）は、テルネット[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 PPVPNの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デバイスで適切に処理できる限り、レイヤー2暗号化は、CEから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.
PPVPNでは、暗号化がいくつかの異なる場所で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からCEから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）デバイス、および2つの間にパスに沿って存在する可能性のあるプロバイダーコア（P）デバイスの可変数（3つが表示されている）を示す単純化されたPPVPNトポロジを示しています。単一のサービスプロバイダー（SP）が運営する単一のVPNのサイト。
Site_1---CE---PE---P---P---P---PE---CE---Site_2
Site_1 --- CE --- PE --- P --- P --- P --- PE --- CE ---サイト_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デバイスが暗号化に関与しないと仮定すると、デバイス間の接続に暗号化を実装するための4つの基本的な実行可能な構成があります。
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-to-CE）：暗号化は2つのCEデバイス間で構成できるため、SPのネットワーク全体でトラフィックが暗号化されます。
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-To-PE）：暗号化は、2つのPEデバイス間で構成できます。暗号化されていないトラフィックは、顧客のCEから1つのPEで受信されます。次に、SPのネットワークを介して他のPEに送信するために暗号化され、そこで復号化され、他のCEに送信されます。
3) Access link (CE-to-PE): Encryption can be configured between the CE and PE, on each side (or on only one side).
3) アクセスリンク（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?
- 強化されたサービスを提供するSPの能力（QOS、ファイアウォール、侵入検知など）：SPは、これらのサービスを提供するためにデータを検査できますか？
These tradeoffs are discussed below for each configuration.
これらのトレードオフは、各構成について以下で説明します。
1) Site-to-site (CE-to-CE) Configurations
1) サイトからサイト（CE-to-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デバイス）を担当しますが、VPNあたりの全体的な構成はNCE ** 2としてスケーリングします。
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マーキングのみがSPに表示され、いくつかのQoSサービスが許可されます。
2) Provider edge-to-edge (PE-to-PE) Configurations
2) プロバイダーのエッジからエッジ（PE-to-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デバイス。（複数のサイトがPEデバイスを共有する可能性があるため、通常、NPEはNCEよりもはるかに少ないです。）全体的な構成のスケーラビリティは、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-to-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 複雑さ：両側にデバイス構成を備えた2つの管理（顧客とSP）（構成するNCE NPEデバイス）がありますが、メッシュがないため、全体的な構成はNCEとしてスケールされます。
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) Combined Access LinkとPE-ToPE（本質的にホップバイホップ）。
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を組み合わせたNPE ** 2としてスケーリングします。
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-ty-CE）と4（組み合わせたアクセスリンクとPE-To-PE）を比較します。
- If protection from link eavesdropping is most important, then configurations 1 and 4 are equivalent.
- Link盗聴からの保護が最も重要な場合、構成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の数が一般にCESよりもはるかに少ないという事実から利益を提供する場合があります。
Also, under some PPVPN approaches, the scaling of 4 is further improved by sharing the same PE-PE mesh across all VPN contexts. The scaling characteristics of 4 may be increased or decreased in any given situation if the CE devices are simpler to configure than the PE devices, or vice versa. Furthermore, with option 4, the impact of operational error may be significantly increased.
また、一部のPPVPNアプローチでは、すべてのVPNコンテキストで同じPE-PEメッシュを共有することにより、4のスケーリングがさらに改善されます。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-to-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.
このカテゴリには、CESが予想されるVPNに接続されていることを確認するための手法が含まれています。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.
リモートアクセス認証をサポートするために、広く使用されている標準ベースのプロトコルがいくつかあります。これらには、半径[RFC2865]および直径[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ユーザーの認証システムに渡し、ユーザーが認証されているかどうかについてのYES/NO応答を受信するプロキシ認証サービスを通じて実現できます。したがって、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.
暗号化技術は、デバイスまたは個人のアイデンティティを認証するためのいくつかのメカニズムを提供します。これらには、共有されたシークレットキーの使用、アクセサリデバイスまたはソフトウェアによって生成された1回限りのキー、ユーザー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:
この定義には2つの重要な結果があります。
- Routing or traffic flow symmetry: A firewall typically requires routing symmetry, which is usually enforced by locating a firewall where the network topology assures that both sides of a conversation will pass through the firewall. A filter can then operate upon traffic flowing in one direction without considering traffic in the reverse direction.
- ルーティングまたはトラフィックフローの対称性：通常、ファイアウォールにはルーティング対称性が必要です。これは通常、ネットワークトポロジが会話の両側がファイアウォールを通過することを保証するファイアウォールを見つけることによって強制されます。その後、フィルターは、トラフィックを逆方向に考慮せずに一方向に流れるトラフィックを動作させます。
- 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.
- stign性：会話の両側を受け取るため、ファイアウォールはその会話に関するかなりの量の情報を取得し、この情報を使用してアクセスを制御できる場合があります。フィルターは、パケットの単方向の流れに関するいくつかの限られた状態情報を維持できますが、ファイアウォールができるように、双方向の会話の状態を正確に決定することはできません。
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.
多くの場合、フィルターの特性はステートレスになる場合があります。ステートレスフィルターは、特定のパケットがフィルター定義のみに基づいてフィルターと一致し、通常の転送情報（パケットの次のホップなど）、およびその個々のパケットの特性に一致するかどうかを判断します。通常、ステートレスフィルターは、着信と発信の論理または物理インターフェイス、IPヘッダーの情報、およびTCPやUDPヘッダーなどの高層ヘッダーの情報を考慮する場合があります。考慮される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モデルの異なる信頼できるゾーン間の交通を通過するトラフィックを制御するメカニズムを提供します。ファイアウォールは通常、フィルターよりもはるかに多くの機能を提供します。これは、個々のパケットだけでなく、フローに詳細な分析と論理関数を適用できる可能性があるためです。これらは、しきい値駆動型のサービス攻撃攻撃保護、ウイルススキャン、または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ユーザー、さらには1つの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のサポートに使用されるインフラストラクチャを保護する1つの方法は、VPNサポートリソースを他の目的に使用するリソース（インターネットサービスのサポートなど）から分離することです。場合によっては、これには、VPNサービスに物理的に個別の機器を使用するか、物理的に個別のネットワークを使用する必要がある場合があります。
For example, PE-based L3 VPNs may be run on a separate backbone not connected to the Internet, or they may use separate edge routers from those used to support Internet service. Private IP addresses (local to the provider and non-routable over the Internet) are sometimes used to provide additional separation.
たとえば、PEベースのL3 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は、1つの特定の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サービスの主な理由の1つは、複数の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によって不正行為の可能性から保護されるべきです。これには、1つの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-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.
PPVPNのセキュリティ攻撃の検出に使用される監視システムは、通常、プロバイダーEdge（PE）、Customer Edge（CE）、および/またはプロバイダーバックボーン（P）デバイスから情報を収集することにより動作します。セキュリティ監視システムには、デバイスから情報を積極的に取得（SNMP GETなど）またはデバイスからレポートを受動的に受信する機能（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.
仮想プライベートネットワークは通常、「プライベート」を他のPPVPNおよびインターネットからの分離として定義します。より具体的には、分離にはいくつかのコンポーネントがあり、これらについては次のセクションで説明します。
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サービスを使用する他のPPVPNを妨害することなく、プライベートアドレス範囲[RFC1918]を含む完全なインターネットアドレス範囲を使用できます。インターネットアクセスが提供される場合（たとえば、PPVPNサービスを提供しているのと同じサービスプロバイダーによって）、NAT機能が必要になる場合があります。
In layer-2 VPNs, the same requirement exists for the layer 2 addressing schemes, such as MAC addresses.
レイヤー2 VPNSでは、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.
レイヤー2 VPNでは、1つのPPVPNの切り替え情報が他のPPVPNまたはPPVPNコアに影響を与えないように、スイッチング情報を信頼できるゾーン間で分離する必要があります。
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.
一般的な認識は、完全に分離された「プライベート」ネットワークはエントリポイントを定義しており、それらのエントリポイントに対する攻撃または侵入のみを受けるということです。Common Coreを共有することにより、PPVPNは、これらの明確なインターフェイスの一部を信頼できるゾーンの外側のネットワークに失うように見えます。したがって、PPVPNサービスの主要なセキュリティ要件の1つは、プライベートネットワークと同じレベルの保護を提供することです。
An intrusion is defined here as the penetration of a trusted zone from outside. This could be from the Internet, another PPVPN, or the core network itself.
ここでは、侵入は、外部から信頼できるゾーンの浸透として定義されます。これは、インターネット、別のPPVPN、またはコアネットワーク自体からのものです。
The fact that a network is "virtual" must not expose it to additional threats over private networks. Specifically, it must not add new interfaces to other parts outside the trusted zone. Intrusions from known interfaces such as Internet gateways are outside the scope of this document.
ネットワークが「仮想」であるという事実は、プライベートネットワークよりも追加の脅威にさらされてはなりません。具体的には、信頼できるゾーンの外側の他の部品に新しいインターフェイスを追加してはなりません。インターネットゲートウェイなどの既知のインターフェイスからの侵入は、このドキュメントの範囲外です。
A denial-of-service (DoS) attack aims at making services or devices unavailable to legitimate users. In the framework of this document, only those DoS attacks are considered that are a consequence of providing network service through a VPN. DoS attacks over the standard interfaces into a trusted zone are not considered here.
サービス拒否（DOS）攻撃は、正当なユーザーが利用できないサービスまたはデバイスを作成することを目的としています。このドキュメントのフレームワークでは、VPNを介してネットワークサービスを提供した結果であるDOS攻撃のみが考慮されています。標準インターフェイスを介して信頼できるゾーンへのDOS攻撃は、ここでは考慮されません。
The requirement is that a PPVPN is not more vulnerable against DoS attacks than it would be if the same network were private.
要件は、PPVPNが同じネットワークがプライベートである場合よりもDOS攻撃に対して脆弱ではないことです。
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がこれらのパケットが他のCEから来ていると信じる細工パケットを送信することは不可能である必要があります。
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.
これらの要件は、1）PPVPNユーザーと非PPVPNを含むコアの外側のさまざまな攻撃からPPVPNコアを偶然および悪意を持って保護する方法、および2）PPVPNユーザーVPNとサイト自体を保護する方法に焦点を当てています。PPVPNコアは、PPVPNを提供しないコアよりも攻撃に対して脆弱ではないことに注意してください。ただし、このようなコアで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.
バックボーンを外から1つのホップのように見せるために、通常のTTL伝播が変更される場合がありますが、ループ予防には注意する必要があります。これにより、バックボーンアドレスがトレースルートを介して公開されないようにします。ただし、エンドツーエンド障害追跡の運用要件に対しても評価する必要があります。
An Internet backbone core may be re-engineered to make Internet routing an edge function, for example, by using MPLS label switching for all traffic within the core and possibly by making the Internet a VPN within the PPVPN core itself. This helps detach Internet access from PPVPN services.
たとえば、インターネットルーティングをエッジ関数にするために、インターネットバックボーンコアを再設計することができます。たとえば、コア内のすべてのトラフィックのMPLSラベルスイッチングを使用し、場合によってはインターネットをPPVPNコア自体内のVPNにすることにより。これにより、PPVPNサービスからインターネットアクセスを取り外すことができます。
PE devices may implement separate control plane, data plane, and management plane functionality in terms of hardware and software, to improve security. This may help limit the problems when one particular area is attacked, and it may allow each plane to implement additional security measurement separately.
PEデバイスは、セキュリティを改善するために、ハードウェアとソフトウェアの観点から個別の制御プレーン、データプレーン、および管理プレーンの機能を実装する場合があります。これは、特定の領域が攻撃されたときに問題を制限するのに役立つ可能性があり、各飛行機が追加のセキュリティ測定を個別に実装できるようにすることができます。
PEs are often more vulnerable to attack than P routers, since, by their very nature, PEs cannot be made unreachable to outside users. Access to core trunk resources can be controlled on a per-user basis by the application of inbound rate-limiting/shaping. This can be further enhanced on a per-Class of Service basis (see section 8.2.3).
PESは、PESを外部ユーザーに到達できないようにすることができないため、PESは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 Technologiesを使用する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.
今日のMPL、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などのASE間の認証/暗号化メカニズムを使用できます。
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ユーザーのSPACEの分離は、同じ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ベースのソリューションでは、PE自体による直接認証の柔軟性または顧客PPVPN認証サーバーとの対話が必要です。後者のケースでは、PEと顧客認証サーバー間の相互作用が制御されるようにメカニズムが必要です。たとえば、認証フェーズおよび他の属性（例えば、RADIUSのオプションのフィルタリングに関連する交換に単純に制限すること））。
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など）で制御を提供するために使用できます。Neighborおよび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.
プロバイダー間接続の場合、上記のようにアクセス保護、リンク認証、およびルーティングポリシーが適用される場合があります。ASE間にインバウンドファイアウォール/フィルタリングメカニズムの両方が適用される場合があります。プロバイダーのネットワークインフラストラクチャと顧客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コアへのイングレスの制限/トラフィックシェーピングの1つのクラスなどのメカニズムは、このレベルの制御を提供する1つのオプションです。このようなメカニズムでは、プロファイルの外側にあるトラフィックをマーク、リマー、または破棄することにより、サービスプロファイルの一人が施行される必要があります。
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統計など）は、PEのメカニズムの要件を課し、その特定のユーザーの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.
PPVPNプロバイダーは、セクション7にリストされているユーザーのセキュリティ要件をサポートする必要があります。使用するテクノロジーに応じて、これらの要件には以下が含まれる場合があります。
- 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.
- ユーザーデータプレーンの分離：1つの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アプローチのapplicabilityステートメントに表示される必要があります。
The first part of the template is in the form of a list of security assertions. For each assertion the approach is assessed and one or more of the following ratings is assigned:
テンプレートの最初の部分は、セキュリティアサーションのリストの形式です。各アサーションについて、アプローチが評価され、次の評価の1つ以上が割り当てられます。
- The requirement is not applicable to the VPN approach because ... (fill in reason).
- 要件は、...（理由で記入）のために、VPNアプローチには適用されません。
- The base VPN approach completely addresses the requirement by ... (fill in technique).
- ベースVPNアプローチは、...（テクニックに記入してください）の要件に完全に対処します。
- The base VPN approach partially addresses the requirement by ... (fill in technique and extent to which it addresses the requirement).
- ベースVPNアプローチは、要件に部分的に対処します...（技術と要件に対処する程度に記入してください）。
- An optional extension to the VPN approach completely addresses the requirement by ... (fill in technique).
- VPNアプローチへのオプションの拡張機能は、...（テクニックに記入してください）の要件に完全に対処します。
- An optional extension to the VPN approach partially addresses the requirement by ... (fill in technique and extent to which it addresses the requirement).
- VPNアプローチへのオプションの拡張機能は、...（要件に対処する手法と程度に記入してください）の要件に部分的に対処します。
- The requirement is addressed in a way that is beyond the scope of the VPN approach. (Explain.) (One example of this would be a VPN approach in which some aspect, such as membership discovery, is done via configuration. The protection afforded to the configuration would be beyond the scope of the VPN approach.).
- 要件は、VPNアプローチの範囲を超えた方法で対処されます。（説明。）（これの1つの例は、メンバーシップの発見などのいくつかの側面が構成を介して行われるVPNアプローチです。構成に与えられる保護は、VPNアプローチの範囲を超えています。）
- The VPN approach does not meet the requirement.
- VPNアプローチは要件を満たしていません。
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.
6. このアプローチは、個別の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ユーザーデータの機密性（秘密）保護を提供します。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ユーザーデータの整合性保護を提供します。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ユーザーデータのリプレイ攻撃に対する保護を提供します。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ユーザーデータの不正なトラフィックパターン分析に対する保護を提供します。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).
a. VPNメンバーシップの発見。b。トンネル設立。c。VPNトポロジとリーチ可能性広告：i。PE-PE。ii。PE-CE。d。VPNプロビジョニングと管理。e。VPN監視、攻撃検出、およびレポート。f。他のVPN固有の制御プロトコル（リスト）があれば。
The following questions solicit free-form answers.
次の質問は、自由形式の回答を求めています。
15. Describe the protection, if any, the approach provides against PPVPN-specific DoS attacks (i.e., inter-trusted-zone DoS attacks):
15. PPVPN固有のDOS攻撃（つまり、信頼されたゾーンDOS攻撃）に対して提供されるアプローチが保護を説明してください。
a. Protection of the service provider infrastructure against Data Plane or Control Plane DoS attacks originated in a private (PPVPN user) network and aimed at PPVPN mechanisms.
a. データプレーンまたはコントロールプレーンDOS攻撃に対するサービスプロバイダーインフラストラクチャの保護は、プライベート（PPVPNユーザー）ネットワークで発生し、PPVPNメカニズムを対象としています。
b. Protection of the service provider infrastructure against Data Plane or Control Plane DoS attacks originated in the Internet and aimed at PPVPN mechanisms.
b. データプレーンまたはコントロールプレーン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.
a. PPVPNユーザーネットワークからサービスプロバイダーネットワークへのルーティングトラフィックの高レベルまたは悪意のある設計に対する保護。
b. Protection against high levels of, or malicious design of, network management traffic from PPVPN user networks to the service provider network.
b. PPVPNユーザーネットワークからサービスプロバイダーネットワークへのネットワーク管理トラフィックの高レベルまたは悪意のある設計に対する保護。
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機器を圧倒しています。運用/プロビジョニングエラーは、サービスプロバイダーが最大の関心事の1つとして引用しています。
The document describes a variety of defensive techniques that may be used to counter the suspected threats. All of the techniques presented involve mature and widely implemented technologies that are practical to implement.
このドキュメントでは、疑わしい脅威に対抗するために使用される可能性のあるさまざまな防御技術について説明しています。提示されたすべての手法には、実装するのが実用的な成熟した広く実装されたテクノロジーが含まれます。
The document describes the importance of detecting, monitoring, and reporting both successful and unsuccessful attacks. These activities are essential for "understanding one's enemy", mobilizing new defenses, and obtaining metrics about how secure the PPVPN service is. As such, they are vital components of any complete PPVPN security system.
このドキュメントでは、成功した攻撃と失敗した攻撃の両方を検出、監視、報告することの重要性について説明しています。これらの活動は、「敵の理解」、新しい防御の動員、PPVPNサービスの安全性に関するメトリックを取得するために不可欠です。そのため、それらは完全なPPVPNセキュリティシステムの重要なコンポーネントです。
The document evaluates PPVPN security requirements from a customer perspective and from a service provider perspective. These sections re-evaluate the identified threats from the perspectives of the various stakeholders and are meant to assist equipment vendors and service providers, who must ultimately decide what threats to protect against in any given equipment or service offering.
このドキュメントは、顧客の観点から、およびサービスプロバイダーの観点からPPVPNセキュリティ要件を評価します。これらのセクションは、特定された脅威をさまざまな利害関係者の視点から再評価し、機器のベンダーとサービスプロバイダーを支援することを目的としています。
Finally, the document includes a template for use by authors of PPVPN technical solutions for evaluating how those solutions measure up against the security considerations presented in this memo.
最後に、このドキュメントには、PPVPNテクニカルソリューションの著者が使用するテンプレートが含まれており、これらのソリューションがこのメモに示されているセキュリティに関する考慮事項に対してどのように測定されるかを評価します。
The following people made major contributions to writing this document: Michael Behringer, Ross Callon, Fabio Chiussi, Jeremy De Clerque, Paul Hitchen, and Paul 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
マイケルベーリンガーシスコビレッジD'Entreprises Green Side、電話：33.49723-2652 400、Avenue Roumanille、Bat。T 3メール：mbehring@cisco.com 06410 Biot、Sophia Antipolis France
Ross Callon
Juniper Networks
10 Technology Park Drive Phone: 978-692-6724
Westford, MA 01886 EMail: rcallon@juniper.net
Fabio Chiussi Phone: 1 978 367-8965
Airvana EMail: fabio@airvananet.com
19 Alpha Road
Chelmsford, Massachusetts 01824
Jeremy De Clercq Alcatel Fr. Wellesplein 1, 2018 Antwerpen EMail: jeremy.de_clercq@alcatel.be Belgium
Jeremy de Clercq Alcatel Fr.Wellesplein 1、2018 Antwerpen Email：jeremy.de_clercq@alcatel.beベルギー
Mark Duffy
Sonus Networks
250 Apollo Drive Phone: 1 978-614-8748
Chelmsford, MA 01824 EMail: mduffy@sonusnet.com
Paul Hitchen
BT
BT Adastral Park
Martlesham Heath Phone: 44-1473-606-344
Ipswich IP53RE EMail: paul.hitchen@bt.com
UK
Paul Knight
Nortel
600 Technology Park Drive Phone: 978-288-6414
Billerica, MA 01821 EMail: 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.
著者と貢献者は、ポール・ホフマン、エリック・グレイ、ロン・ボニカ、クリス・チェイス、ジェリー・アッシュ、スチュワート・ブライアントからの有益なコメントと提案も認めたいと思います。
[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.、Moskowitz、B.、Karrenberg、D.、De Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246] Dierks、T。およびC. Allen、「TLSプロトコルバージョン1.0」、RFC 2246、1999年1月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、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] Kent、S。およびR. Atkinson、「IPカプセンシングセキュリティペイロード（ESP）」、RFC 2406、1998年11月。
[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2407] Piper、D。、「ISAKMPの解釈のインターネットIPセキュリティドメイン」、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.、Valencia、A.、Rubens、A.、Pall、G.、Zorn、G。、およびB. Palter、 "Layer Two Tunneling Protocol" 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.
[RFC2865] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588] Calhoun、P.、Loughney、J.、Guttman、E.、Zorn、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] Harrington、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.
Case、J.、Harrington、D.、Presuhn、R。、およびB. Wijnen、「Simple Network Management Protocol（SNMP）のメッセージ処理とディスパッチ」、STD 62、RFC 3412、2002年12月。
Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002.
Levi、D.、Meyer、P。、およびB. Stewart、「Simple Network Management Protocol（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.
Blumenthal、U.およびB. Wijnen、「Simple Network Management Protocol（SNMPV3）のバージョン3のユーザーベースのセキュリティモデル（USM）」、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、「シンプルネットワーク管理プロトコル（SNMP）のビューベースのアクセス制御モデル（VACM）」、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。、「Simple Network Management Protocol（SNMP）のプロトコル操作のバージョン2」、STD 62、RFC 3416、2002年12月。
Presuhn, R., "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002.
Presuhn、R。、「Simple Network Management Protocol（SNMP）の輸送マッピング」、STD 62、RFC 3417、2002年12月。
Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002.
Presuhn、R。、「シンプルネットワーク管理プロトコル（SNMP）の管理情報ベース（MIB）」、STD 62、RFC 3418、2002年12月。
[STD8] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[STD8] Postel、J。およびJ. Reynolds、「Telnetプロトコル仕様」、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.、Bellare、M。、およびR. CaNetti、「HMAC：メッセージ認証のためのキー付きハッシング」、RFC 2104、1997年2月。
[RFC2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[RFC2411] Thayer、R.、Doraswamy、N。、およびR. Glenn、「IP Security Document Roadmap」、RFC 2411、1998年11月。
[RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.
[RFC3174] EastLake 3rd、D。およびP. Jones、「US Secure Hash Algorithm 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.、Schiller、J。、およびC. Kaufman、「インターネットのセキュリティメカニズム」、RFC 3631、2003年12月。
[RFC3889] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 3889, October 2004.
[RFC3889] Barbir、A.、Murphy、S。、およびY. Yang、「ルーティングプロトコルに対する一般的な脅威」、RFC 3889、2004年10月。
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, March 2005.
[RFC4026] Andersson、L。およびT. Madsen、「プロバイダープロビジョニング仮想プライベートネットワーク（VPN）用語」、RFC 4026、2005年3月。
[RFC4031] Carugi, M. and D. McDysan, Eds., "Service Requirements for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs)", RFC 4031, April 2005.
[RFC4031] Carugi、M。およびD. McDysan編、「レイヤー3プロバイダープロビジョニング仮想プライベートネットワーク（PPVPNS）のサービス要件」、RFC 4031、2005年4月。
[RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3 Provider Provisioned Virtual Private Networks", RFC 4110, July 2005.
[RFC4110] Callon、R。およびM. Suzuki、「レイヤー3プロバイダープロビジョニング仮想プライベートネットワークのフレームワーク」、RFC 4110、2005年7月。
Author's Address
著者の連絡先
Luyuan Fang AT&T Labs. 200 Laurel Avenue, Room C2-3B35 Middletown, NJ 07748
Luyuan Fang AT＆T Labs。200ローレルアベニュー、部屋C2-3B35ミドルタウン、ニュージャージー07748
Phone: 732-420-1921 EMail: luyuanfang@att.com
電話：732-420-1921メール：luyuanfang@att.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。