[要約] RFC 3837は、Open Pluggable Edge Services（OPES）におけるセキュリティの脅威とリスクについての情報を提供するものです。その目的は、OPESの実装者や運用者がセキュリティに関する問題を理解し、適切な対策を講じるためのガイドラインを提供することです。
Network Working Group A. Barbir
Request for Comments: 3837 Nortel Networks
Category: Informational O. Batuner
Independent consultant
B. Srinivas
Nokia
M. Hofmann
Bell Labs/Lucent Technologies
H. Orman
Purple Streak Development
August 2004
Security Threats and Risks for Open Pluggable Edge Services (OPES)
オープンプラグ可能なエッジサービス（OPES）のセキュリティの脅威とリスク
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 (2004).
著作権（c）The Internet Society（2004）。
Abstract
概要
The document investigates the security threats associated with the Open Pluggable Edge Services (OPES) and discusses the effects of security threats on the underlying architecture. The main goal of this document is threat discovery and analysis. The document does not specify or recommend any solutions.
このドキュメントは、オープンプラグ可能なエッジサービス（OPES）に関連するセキュリティの脅威を調査し、基礎となるアーキテクチャに対するセキュリティの脅威の影響について説明します。このドキュメントの主な目標は、脅威の発見と分析です。ドキュメントは、ソリューションを指定または推奨していません。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. OPES Data Flow Threats . . . . . . . . . . . . . . . . . . . . 4
2.1. OPES Flow Network Level Threats . . . . . . . . . . . . 5
2.1.1. Connection-Flow Denial-of-Service (DoS). . . . . 6
2.1.2. Threats to Network Robustness. . . . . . . . . . 6
2.2. OPES Flow Application Level Threats. . . . . . . . . . . 6
2.2.1. Unauthorized OPES Entities . . . . . . . . . . . 6
2.2.2. Unauthorized Actions of legitimate OPES Entities 7
2.2.3. Unwanted Content Transformations . . . . . . . . 7
2.2.4. Corrupted Content . . . . . . . . . . . . . . . 7
2.2.5. Threats to Message Structure Integrity . . . . . 8
2.2.6. Granularity of Protection . . . . . . . . . . . 8
2.2.7. Risks of Hop-by-Hop Protection . . . . . . . . . 8
2.2.8. Threats to Integrity of Complex Data . . . . . . 8
2.2.9. Denial of Service (DoS) . . . . . . . . . . . . 9
2.2.10. Tracing and Notification Information . . . . . . 9
2.2.11. Unauthenticated Communication in OPES Flow . . . 9
3. Threats to Out-of-Band Data . . . . . . . . . . . . . . . . . 9
3.1. Threats that Endanger the OPES Data Flow . . . . . . . . 10
3.2. Inaccurate Accounting Information . . . . . . . . . . . 10
3.3. OPES Service Request Repudiation . . . . . . . . . . . . 11
3.4. Inconsistent Privacy Policy . . . . . . . . . . . . . . 11
3.5. Exposure of Privacy Preferences . . . . . . . . . . . . 11
3.6. Exposure of Security Settings . . . . . . . . . . . . . 11
3.7. Improper Enforcement of Privacy and Security Policy . . 11
3.8. DoS Attacks . . . . . . . . . . . . . . . . . . . . . . 12
4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Normative References . . . . . . . . . . . . . . . . . . 12
5.2. Informative References . . . . . . . . . . . . . . . . . 12
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
7. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
8. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 14
The Open Pluggable Edge Services (OPES) [1] architecture enables cooperative application services (OPES services) between a data provider, a data consumer, and zero or more OPES processors. The application services under consideration analyze and possibly transform application-level messages exchanged between the data provider and the data consumer. The OPES processor can distribute the responsibility of service execution by communicating and collaborating with one or more remote callout servers. The details of the OPES architecture can be found in [1].
Open Pluggable Edge Services（OPES）[1]アーキテクチャにより、データプロバイダー、データ消費者、およびゼロ以上のOPESプロセッサ間の協力アプリケーションサービス（OPESサービス）が可能になります。検討中のアプリケーションサービスは、データプロバイダーとデータ消費者との間で交換されるアプリケーションレベルのメッセージを分析し、おそらく変換する可能性があります。OPESプロセッサは、1つ以上のリモートコールアウトサーバーと通信および協力することにより、サービス実行の責任を分配できます。OPESアーキテクチャの詳細は[1]にあります。
Security threats with respect to OPES can be viewed from different angles. There are security risks that affect content consumer applications, and those that affect the data provider applications. These threats affect the quality and integrity of data that the applications either produce or consume. On the other hand, the security risks can also be categorized into trust within the system (i.e., OPES service providers) and protection of the system from threats imposed by outsiders such as hackers and attackers. Insiders are those parties that are part of the OPES system. Outsiders are those entities that are not participating in the OPES system.
OPESに関するセキュリティの脅威は、さまざまな角度から見ることができます。コンテンツコンシューマーアプリケーションに影響を与えるセキュリティリスク、およびデータプロバイダーアプリケーションに影響を与えるリスクがあります。これらの脅威は、アプリケーションが生成または消費するデータの品質と完全性に影響します。一方、セキュリティのリスクは、システム内の信頼に分類され（つまり、OPESサービスプロバイダー）、ハッカーや攻撃者などの部外者が課した脅威からシステムの保護を行うこともできます。インサイダーは、OPESシステムの一部であるパーティーです。部外者は、OPESシステムに参加していないエンティティです。
It must be noted that not everyone in an OPES delivery path is equally trusted. Each OPES administrative trust domain must protect itself from all outsiders. Furthermore, it may have a limited trust relationship with another OPES administrative domain for certain purposes.
Opes配信パスにいるすべての人が等しく信頼されているわけではないことに注意する必要があります。各OPES Administrative Trustドメインは、すべての部外者から自分自身を保護する必要があります。さらに、特定の目的のために、別のOPES管理ドメインとの信頼関係が限られている可能性があります。
OPES service providers must use authentication as the basis for building trust relationships between administrative domains. Insiders can intentionally or unintentionally inflict harm and damage on the data consumer and data provider applications. This can be through bad system configuration, execution of bad software or, if their networks are compromised, by inside or outside hackers.
OPESサービスプロバイダーは、管理ドメイン間の信頼関係を構築するための基礎として認証を使用する必要があります。インサイダーは、データ消費者およびデータプロバイダーのアプリケーションに意図的または意図せずに危害と損害を与えることができます。これは、悪いシステム構成、悪いソフトウェアの実行、またはネットワークが侵害された場合、内部または外側のハッカーによって行われる可能性があります。
Depending on the deployment scenario, the trust within the OPES system is based on a set of transitive trust relationships between the data provider application, the OPES entities, and the data consumer application. Threats to OPES entities can be at the OPES flow level and/or at the network level.
展開シナリオに応じて、OPESシステム内の信頼は、データプロバイダーアプリケーション、OPESエンティティ、およびデータ消費者アプリケーションの間の一連の推移的な信頼関係に基づいています。OPESエンティティに対する脅威は、OPESフローレベルおよび/またはネットワークレベルである場合があります。
In considering threats to the OPES system, the document will follow a threat analysis model that identifies the threats from the perspective of how they will affect the data consumer and the data provider applications.
OPESシステムに対する脅威を検討する際、ドキュメントは、データ消費者とデータプロバイダーアプリケーションにどのように影響するかという観点から脅威を特定する脅威分析モデルに従います。
The main goal of this document is threat discovery and analysis. The document does not specify or recommend any solutions.
このドキュメントの主な目標は、脅威の発見と分析です。ドキュメントは、ソリューションを指定または推奨していません。
It is important to mention that the OPES architecture has many similarities with other so called overlay networks, specifically web caches and content delivery networks (CDN) (see [2], [4]). This document focuses on threats that are introduced by the existence of the OPES processor and callout servers. Security threats specific to content services that do not use the OPES architecture are considered out-of-scope of this document. However, this document can be used as input when considering security implications for web caches and CDNs.
OPESアーキテクチャは、他のいわゆるオーバーレイネットワーク、特にWebキャッシュとコンテンツ配信ネットワーク（CDN）と多くの類似点があることに言及することが重要です（[2]、[4]を参照）。このドキュメントは、OPESプロセッサとコールアウトサーバーの存在によって導入される脅威に焦点を当てています。OPESアーキテクチャを使用しないコンテンツサービスに固有のセキュリティの脅威は、このドキュメントのスコープ外と見なされます。ただし、このドキュメントは、WebキャッシュとCDNのセキュリティへの影響を考慮する際に入力として使用できます。
The document is organized as follows: Section 2 discusses threats to OPES data flow on the network and application level, section 3 discusses threats to other parts of the system, and section 4 discusses security considerations.
ドキュメントは次のように編成されています。セクション2では、ネットワークとアプリケーションレベルのOPESデータフローに対する脅威について、セクション3ではシステムの他の部分に対する脅威について、セクション4でセキュリティに関する考慮事項について説明します。
Threats to the OPES data flow can affect the data consumer and data provider applications. At the OPES flow level, threats can occur at Policy Enforcement Points, and Policy Decision Points [3], and along the OPES flow path where network elements are used to process the data.
OPESデータフローに対する脅威は、消費者およびデータプロバイダーのアプリケーションに影響を与える可能性があります。OPESフローレベルでは、ポリシー執行ポイント、およびポリシーの決定ポイント[3]で脅威が発生し、データの処理にネットワーク要素を使用するOPESフローパスに沿って発生する可能性があります。
A serious problem is posed by the very fact that the OPES architecture is based on widely adopted protocols (HTTP is used as an example). The architecture document specifically requires that "the presence of an OPES processor in the data request/response flow SHALL NOT interfere with the operations of non-OPES aware clients and servers". This greatly facilitates OPES' deployment, but on the other hand a vast majority of clients (browsers) will not be able to exploit any safeguards added as base protocol extensions.
OPESアーキテクチャは広く採用されているプロトコルに基づいているという事実によって深刻な問題が提起されます（HTTPは例として使用されます）。アーキテクチャドキュメントでは、「データ要求/応答フローにOPESプロセッサが存在することは、非OPES認識クライアントおよびサーバーの操作を妨害しない」ことを特に要求しています。これにより、Opesの展開が大幅に促進されますが、一方で、大多数のクライアント（ブラウザ）は、ベースプロトコル拡張として追加された保護ガードを悪用することはできません。
For the usual data consumer, who might have questions such as (Where does this content come from? Can I get it another way? What is the difference? Is it legitimate?). Even if there are facilities and technical expertise present to pursue these questions, such thorough examination of each result is prohibitively expensive in terms of time and effort. OPES-aware content providers may try to protect themselves by adding verification scripts and special page structures. OPES-aware end users may use special tools. In all other cases (non-OPES aware clients and servers) protection will rely on monitoring services and investigation of occasionally discovered anomalies.
通常のデータ消費者にとって、誰が（このコンテンツはどこから来たのか？別の方法で入手できますか？違いは何ですか？それは合法ですか？）。これらの質問を追求するために施設と技術的な専門知識が存在している場合でも、各結果を徹底的に調査することは、時間と労力の点で法外に高価です。Opes Awareコンテンツプロバイダーは、検証スクリプトと特別なページ構造を追加することにより、自分自身を保護しようとする場合があります。Opes-Awareのエンドユーザーは、特別なツールを使用する場合があります。他のすべてのケース（非OPESEARSクライアントとサーバー）の保護は、監視サービスと時折発見された異常の調査に依存します。
An OPES system poses a special danger as a possible base for classical man-in-the-middle attacks. One of the reasons why such attacks are relatively rare is the difficulty in finding an appropriate base: a combination of a traffic interception point controlling a large flow of data and an application codebase running on a high-performance hardware with sufficient performance to analyze and possibly modify all passing data. An OPES processor meets this definition. This calls for special attention to protection measures at all levels of the system.
OPESシステムは、古典的なマンインザミドル攻撃の可能性のある基盤として特別な危険をもたらします。そのような攻撃が比較的まれである理由の1つは、適切なベースを見つけるのが難しいことです。トラフィックインターセプトポイントの組み合わせが、データの大きなフローを制御することと、分析し、場合によっては十分なパフォーマンスを備えた高性能ハードウェアで実行されているアプリケーションコードベースの組み合わせです。すべてのパッシングデータを変更します。OPESプロセッサがこの定義を満たしています。これには、システムのすべてのレベルでの保護対策に特別な注意が必要です。
Any compromise of an OPES processor or remote callout server can have a ripple effect on the integrity of the affected OPES services across all service providers that use the service. To mitigate this threat, appropriate security procedures and tools (e.g., a firewall) should be applied.
OPESプロセッサまたはリモートコールアウトサーバーの妥協は、サービスを使用するすべてのサービスプロバイダーにわたって影響を受けるOPESサービスの整合性にリップル効果をもたらす可能性があります。この脅威を軽減するには、適切なセキュリティ手順とツール（ファイアウォールなど）を適用する必要があります。
Specific threats can exist at the network level and at the OPES data flow level.
特定の脅威は、ネットワークレベルとOPESデータフローレベルで存在する可能性があります。
OPES processor and callout servers are susceptible to network level attacks from outsiders or from the networks of other OPES service providers (i.e., if the network of a contracted OPES service is compromised).
OPESプロセッサとコールアウトサーバーは、部外者または他のOPESサービスプロバイダーのネットワークからのネットワークレベルの攻撃の影響を受けやすくなります（つまり、契約されたOPESサービスのネットワークが侵害されている場合）。
The OPES architecture is based on common application protocols that do not provide strong guarantees of privacy, authentication, or integrity. The IAB considerations [4] require that the IP address of an OPES processor be accessible to data consumer applications at the IP addressing level. This requirement limits the ability of service providers to position the OPES processor behind firewalls and may expose the OPES processor and remote callout servers to network level attacks. For example, the use of TCP/IP as a network level protocol makes OPES processors subject to many known attacks, such as IP spoofing and session stealing.
OPESアーキテクチャは、プライバシー、認証、または整合性の強力な保証を提供しない一般的なアプリケーションプロトコルに基づいています。IABの考慮事項[4]では、OPESプロセッサのIPアドレスにIPアドレスリングレベルでデータコンシューマーアプリケーションにアクセスできることが必要です。この要件により、サービスプロバイダーがOPESプロセッサをファイアウォールの背後に配置する機能が制限され、OPESプロセッサとリモートコールアウトサーバーをネットワークレベルの攻撃に公開する場合があります。たとえば、ネットワークレベルのプロトコルとしてTCP/IPを使用すると、OPESプロセッサは、IPスプーフィングやセッション盗みなど、多くの既知の攻撃を受けます。
The OPES system is also susceptible to a number of security threats that are commonly associated with network infrastructure. These threats include snooping, denial of service, sabotage, vandalism, industrial espionage, and theft of service.
OPESシステムは、ネットワークインフラストラクチャに一般的に関連付けられている多くのセキュリティ脅威の影響を受けやすくなっています。これらの脅威には、スヌーピング、奉仕の拒否、妨害行為、破壊行為、産業スパイ、および奉仕の盗難が含まれます。
There are best practice solutions to mitigate network level threats. It is recommended that the security of the OPES entities at the network level be enhanced using known techniques and methods that minimize the risks of IP spoofing, snooping, denial of service, and session stealing.
ネットワークレベルの脅威を緩和するためのベストプラクティスソリューションがあります。ネットワークレベルのOPESエンティティのセキュリティは、IPスプーフィング、スヌーピング、サービス拒否、およびセッション盗みのリスクを最小限に抑える既知の手法と方法を使用して強化することをお勧めします。
At the OPES Flow level, connection-level security between the OPES processor and callout servers is an important consideration. For example, it is possible to spoof the OPES processor or the remote callout server. There are threats to data confidentiality between the OPES processor and the remote callout server in an OPES flow.
OPESフローレベルでは、OPESプロセッサとコールアウトサーバー間の接続レベルのセキュリティが重要な考慮事項です。たとえば、OPESプロセッサまたはリモートコールアウトサーバーをスプーフィングすることができます。OPESプロセッサとOPESフロー内のリモートコールアウトサーバーとの間にデータの機密性を脅かす脅威があります。
The next subsections cover possible DoS attacks on an OPES processor, remote callout server or data consumer application, and network robustness.
次のサブセクションでは、OPESプロセッサ、リモートコールアウトサーバーまたはデータコンシューマーアプリケーション、およびネットワークの堅牢性に対するDOS攻撃の可能性をカバーします。
OPES processors, callout servers, and data consumer applications can be vulnerable to DoS attacks. DoS attacks can be of various types. One example of a DoS attack is the overloading of OPES processors or callout servers by spurious service requests issued by a malicious node, which denies the legal data traffic the necessary resources to render service. The resources include CPU cycles, memory, network interfaces, etc. A Denial-of-Service attack can be selective, generic, or random in terms of which communication streams are affected.
OPESプロセッサ、コールアウトサーバー、およびデータコンシューマーアプリケーションは、DOS攻撃に対して脆弱です。DOS攻撃にはさまざまなタイプがあります。DOS攻撃の1つの例は、悪意のあるノードによって発行された偽のサービスリクエストによるOPESプロセッサまたはコールアウトサーバーの過負荷です。リソースには、CPUサイクル、メモリ、ネットワークインターフェイスなどが含まれます。サービス拒否攻撃は、通信ストリームが影響を受けるという点で選択的、一般的、またはランダムになります。
Distributed DoS is also possible when an attacker successfully directs multiple nodes over the network to initiate spurious service requests to an OPES processor (or callout server) simultaneously.
分散DOSは、攻撃者がネットワーク上に複数のノードを正常に指示し、OPESプロセッサ（またはCallout Server）に同時にスプリアスサービス要求を開始する場合にも可能です。
If OPES implementation violates end-to-end addressing principles, it could endanger the Internet infrastructure by complicating routing and connection management. If it does not use flow-control principles for managing connections, or if it interferes with end-to-end flow control of connections that it did not originate, then it could cause Internet congestion.
OPESの実装がエンドツーエンドのアドレス指定原則に違反している場合、ルーティングと接続管理を複雑にすることにより、インターネットインフラストラクチャを危険にさらす可能性があります。接続を管理するためにフローコントロール原則を使用しない場合、または発生しなかった接続のエンドツーエンドのフロー制御に干渉した場合、インターネットの混雑を引き起こす可能性があります。
An implementation that violates the IAB requirement of explicit IP level addressing (for example, by adding OPES functional capabilities to an interception proxy) may defeat some of the protective mechanisms and safeguards built into the OPES architecture.
明示的なIPレベルアドレス指定のIAB要件に違反する実装（たとえば、OPES機能機能をインターセプトプロキシに追加することにより）は、OPESアーキテクチャに組み込まれた保護メカニズムとセーフガードの一部を打ち負かす可能性があります。
At the content level, threats to the OPES system can come from outsiders or insiders. The threat from outsiders is frequently intentional. Threats from insiders can be intentional or accidental. Accidents may result from programming or configuration errors that result in bad system behavior.
コンテンツレベルでは、OPESシステムに対する脅威は、部外者やインサイダーから生じることがあります。部外者からの脅威はしばしば意図的です。インサイダーからの脅威は、意図的または偶発的である可能性があります。事故は、システムの動作が不良になるプログラミングまたは構成エラーから生じる場合があります。
Application level problems and threats to the OPES systems are discussed below:
OPESシステムに対するアプリケーションレベルの問題と脅威については、以下で説明します。
Although one party authorization is mandated by the OPES architecture, such authorization occurs out-of-band. Discovering the presence of an OPES entity and verifying authorization requires special actions and may present a problem.
OPESアーキテクチャによって1つの当事者認可が義務付けられていますが、そのような許可は帯域外に発生します。OPESエンティティの存在を発見し、承認を確認するには、特別なアクションが必要であり、問題を提示する可能性があります。
Adding notification and authorization information to the data messages (by using base protocol extensions) may help, especially if the data consumer's software is aware of such extensions.
特にデータ消費者のソフトウェアがそのような拡張機能を認識している場合、データメッセージに通知と認証情報をデータメッセージに追加することが役立ちます。
According to the OPES architecture, the authorization is not tightly coupled with specific rules and procedures triggered by the rules. Even if a requirement to approve each particular rule and procedure was set, it looks at least impractical, if not impossible, to request such permission from the end user. Authorization granularity extends to transformation classes, but not to individual rules or transformations. The actual rules and triggered procedures may (maliciously or due to a programming error) perform actions that they are not authorized for.
OPESアーキテクチャによると、認可は、ルールによってトリガーされた特定のルールと手順と密接に結びついていません。特定の各ルールと手順を承認する要件が設定されたとしても、エンドユーザーにそのような許可を要求することは、少なくとも不可能ではないにしても非現実的であると考えています。承認の粒度は、変換クラスにまで及びますが、個々のルールや変換には拡張されません。実際のルールとトリガーされた手順は、（悪意のある、またはプログラミングエラーによる）許可されていないアクションを実行する場合があります。
An authorized OPES service may perform actions that do not adhere to the expectations of the party that gave the authorization for the service. Examples may include ad flooding by a local ad insertion service or use of inappropriate policy by a content filtering service.
許可されたOPESサービスは、サービスの許可を与えた当事者の期待に従わないアクションを実行する場合があります。例には、ローカル広告挿入サービスによる広告洪水や、コンテンツフィルタリングサービスによる不適切なポリシーの使用が含まれます。
On the other hand, an OPES entity acting on behalf of one party may perform transformations that another party deems inappropriate. Examples may include replacing ads initially inserted by the content provider or applying filtering transformations that change the meaning of the text.
一方、一方の当事者に代わって行動するOPESエンティティは、別の当事者が不適切とみなす変革を実行する場合があります。例には、最初にコンテンツプロバイダーによって挿入された広告の交換、またはテキストの意味を変更するフィルタリング変換を適用することが含まれます。
The OPES system may deliver outdated or otherwise distorted information due to programming problems or as a result of malicious attacks. For example, a compromised server, instead of performing an OPES service, may inject bogus content. Such an action may be an act of cyber-vandalism (including virus injection) or intentional distribution of misleading information (such as manipulations with financial data).
OPESシステムは、プログラミングの問題や悪意のある攻撃の結果として、時代遅れまたは歪んだ情報を提供する場合があります。たとえば、侵害されたサーバーは、OPESサービスを実行する代わりに、偽のコンテンツを注入する場合があります。このような行動は、サイバーバンダリズム（ウイルス注入を含む）または誤解を招く情報の意図的な分布（財務データによる操作など）である可能性があります。
A compromised OPES server or malicious entity in the data flow may introduce changes specifically intended to cause improper actions in the OPES server or callout server. These changes may be in the message body, headers, or both. This type of threat is discussed in more detail below.
データフロー内の侵害されたOPESサーバーまたは悪意のあるエンティティは、OPESサーバーまたはCallout Serverで不適切なアクションを引き起こすことを特に意図した変更を導入する場合があります。これらの変更は、メッセージ本文、ヘッダー、またはその両方にある場合があります。このタイプの脅威については、以下で詳しく説明します。
An OPES server may add, remove, or delete certain headers in a request and/or response message (for example, to implement additional privacy protection or assist in content filtering). Such changes may violate end-to-end integrity requirements or defeat services that use information provided in such headers (for example, some local filtering services or reference-based services).
OPESサーバーは、リクエストおよび/または応答メッセージに特定のヘッダーを追加、削除、または削除することができます（たとえば、追加のプライバシー保護を実装したり、コンテンツフィルタリングを支援したりします）。このような変更は、そのようなヘッダーで提供される情報を使用するエンドツーエンドの整合性要件または敗北サービスに違反する可能性があります（たとえば、一部のローカルフィルタリングサービスや参照ベースのサービス）。
OPES services have implicit permission to modify content. However, the permissions generally apply only to portions of the content, for example, URL's between particular HTML tags, text in headlines, or URL's matching particular patterns. In order to express such policies, one must be able to refer to portions of messages and to detect modifications to message parts.
OPESサービスには、コンテンツを変更するための暗黙の許可があります。ただし、許可は通常、コンテンツの一部にのみ適用されます。たとえば、特定のHTMLタグ、見出しのテキスト、またはURLの特定のパターンの一致するURLはURLです。このようなポリシーを表現するには、メッセージの一部を参照し、メッセージパーツの変更を検出できる必要があります。
Because there is currently very little support for policies that are expressed in terms of message parts, it will be difficult to attribute any particular modification to a particular OPES processor, or to automatically detect policy violations.
現在、メッセージパーツの観点から表明されているポリシーに対するサポートはほとんどないため、特定のOPESプロセッサに特定の変更を起因するか、ポリシー違反を自動的に検出することは困難です。
A fine-grained policy language should be devised, and it could be enforced using digital signatures. This would avoid the problems inherent in hop-by-hop data integrity measures (see next section).
きめ細かい政策言語を考案する必要があり、デジタル署名を使用して実施することができます。これにより、ホップバイホップデータの整合性測定に固有の問題が回避されます（次のセクションを参照）。
Generally, OPES services cannot be applied to data protected with end-to-end encryption methods because the decryption key cannot be shared with OPES processors without compromising the intended confidentiality of the data. This means that if the endpoint policies permit OPES services, the data must either be transmitted without confidentiality protections or an alternative model to end-to-end encryption must be developed, one in which the confidentiality is guaranteed hop-by-hop. Extending the end-to-end encryption model is out of scope of this work.
一般的に、復号化キーを意図したデータの機密性を損なうことなくOPESプロセッサと共有できないため、OPESサービスをエンドツーエンドの暗号化方法で保護されたデータに適用することはできません。これは、エンドポイントポリシーがOPESサービスを許可する場合、データを機密保護なしに送信する必要があるか、エンドツーエンドの暗号化の代替モデルを開発する必要があることを意味します。エンドツーエンドの暗号化モデルを拡張することは、この作業の範囲外です。
OPES services that modify data are incompatible with end-to-end integrity protection methods, and this work will not attempt to define hop-by-hop integrity protection methods.
データを変更するOPESサービスは、エンドツーエンドの整合性保護方法と互換性があり、この作業はホップバイホップの整合性保護方法を定義しようとはしません。
The OPES system may violate data integrity by applying inconsistent transformations to interrelated data objects or references within the data object. Problems may range from a broken reference structure (modified/missing targets, references to wrong locations or missing documents) to deliberate replacement/deletion/insertion of links that violate intentions of the content provider.
OPESシステムは、相互に関連するデータオブジェクトまたはデータオブジェクト内の参照に一貫性のない変換を適用することにより、データの整合性に違反する場合があります。問題は、壊れた参照構造（変更/欠落したターゲット、間違った場所への参照、または欠落したドキュメントへの参照）から、コンテンツプロバイダーの意図に違反するリンクの意図的な交換/削除/挿入にまで及びます。
The data consumer application may not be able to access data if the OPES system fails for any reason.
Data Consumerアプリケーションは、OPESシステムが何らかの理由で失敗した場合、データにアクセスできない場合があります。
A malicious or malfunctioning node may be able to block all traffic. The data traffic destined for the OPES processor (or callout server) may not be able to use the services of the OPES device. The DoS may be achieved by preventing the data traffic from reaching the processor or the callout server.
悪意のあるまたは誤動作しているノードは、すべてのトラフィックをブロックできる場合があります。OPESプロセッサ（またはCallout Server）向けのデータトラフィックは、OPESデバイスのサービスを使用できない場合があります。DOSは、データトラフィックがプロセッサまたはコールアウトサーバーに到達するのを防ぐことで達成される場合があります。
Inadequate or vulnerable implementation of the tracing and notification mechanisms may defeat safeguards built into the OPES architecture.
トレースおよび通知メカニズムの不十分または脆弱な実装は、OPESアーキテクチャに組み込まれたセーフガードを打ち負かす可能性があります。
Tracing and notification facilities may become a target of malicious attack. Such an attack may create problems in discovering and stopping other attacks.
追跡施設と通知施設は、悪意のある攻撃の標的になる可能性があります。このような攻撃は、他の攻撃を発見して停止する際に問題を引き起こす可能性があります。
The absence of a standard for tracing and notification information may present an additional problem. This information is produced and consumed by the independent entities (OPES servers/user agents/ content provider facilities). This calls for a set of standards related to each base protocol in use.
トレースおよび通知情報の標準がない場合、追加の問題が発生する場合があります。この情報は、独立したエンティティ（OPESサーバー/ユーザーエージェント/コンテンツプロバイダー施設）によって作成および消費されます。これには、使用中の各ベースプロトコルに関連する一連の標準が必要です。
There are risks and threats that could arise from unauthenticated communication between the OPES server and callout servers. Lack of use of strong authentication between OPES processors and callout servers may open security holes whereby DoS and other types of attacks (see sections [2 and 3]) can be performed.
OPESサーバーとコールアウトサーバー間の認定されていない通信から生じる可能性のあるリスクと脅威があります。OPESプロセッサとコールアウトサーバー間で強力な認証の使用が不足すると、DOSやその他の種類の攻撃（セクション[2および3]を参照）を実行できるセキュリティホールを開く場合があります。
The OPES architecture separates a data flow from a control information flow (loading rulesets, trust establishment, tracing, policy propagation, etc.). There are certain requirements set for the latter, but no specific mechanism is prescribed. This gives more flexibility for implementations, but creates more burden for implementers and potential customers to ensure that each specific implementation meets all requirements for data security, entity authentication, and action authorization.
OPESアーキテクチャは、データフローを制御情報フロー（ロードルールセット、信頼の確立、トレース、ポリシーの伝播など）から分離しています。後者には特定の要件が設定されていますが、特定のメカニズムは規定されていません。これにより、実装の柔軟性が向上しますが、実装者と潜在的な顧客がより多くの負担を生み出し、特定の各実装がデータセキュリティ、エンティティ認証、およびアクション承認に関するすべての要件を満たすことができます。
In addition to performing correct actions on the OPES data flow, any OPES implementation has to provide an adequate mechanism to satisfy requirements for out-of-band data and signaling information integrity.
OPESデータフローで正しいアクションを実行することに加えて、OPESの実装は、バンド外データとシグナリング情報の完全性の要件を満たすための適切なメカニズムを提供する必要があります。
Whatever the specific mechanism may be, it inevitably becomes subject to multiple security threats and possible attacks. The way the threats and attacks may be realized depends on implementation specifics but the resulting harm generally falls into two categories: threats to OPES data flow and threats to data integrity.
特定のメカニズムが何であれ、それは必然的に複数のセキュリティの脅威と可能な攻撃の対象となります。脅威と攻撃が実現する方法は、実装の詳細に依存しますが、結果として生じる害は一般に、OPESデータフローへの脅威とデータの完全性に対する脅威の2つのカテゴリに分類されます。
The specific threats are:
特定の脅威は次のとおりです。
Any weakness in the implementation of a security, authentication, or authorization mechanism may open the door to the attacks described in section 2.
セキュリティ、認証、または許可メカニズムの実装の弱点は、セクション2で説明されている攻撃への扉を開く可能性があります。
An OPES system implementation should address all these threats and prove its robustness and ability to withstand malicious attacks or networking and programming problems.
OPESシステムの実装は、これらすべての脅威に対処し、悪意のある攻撃やネットワーキングとプログラミングの問題に耐える堅牢性と能力を証明する必要があります。
Collecting and reporting accurate accounting data may be vital when OPES servers are used to extend a business model of a content provider, service provider, or as a basis for third party service. The ability to collect and process accounting data is an important part of OPES' system functionality. This functionality may be challenged by distortion or destruction of base accounting data (usually logs), processed accounting data, accounting parameters, and reporting configuration.
OPESサーバーを使用して、コンテンツプロバイダー、サービスプロバイダー、またはサードパーティサービスの基礎として使用される場合、正確な会計データの収集と報告が不可欠です。会計データを収集および処理する機能は、Opesのシステム機能の重要な部分です。この機能は、基本会計データ（通常はログ）の歪みまたは破壊、処理された会計データ、会計パラメーター、およびレポート構成によって挑戦される場合があります。
As a result a data consumer may be inappropriately charged for viewing content that was not successfully delivered, or a content provider or independent OPES services provider may not be compensated for the services performed.
その結果、データ消費者は、正常に配信されなかったコンテンツを表示するために不適切に請求される場合があります。または、コンテンツプロバイダーまたは独立したOPESサービスプロバイダーが実行されたサービスに対して補償されない場合があります。
The OPES system may use accounting information to distribute resources between different consumers or limit resource usage by a specific consumer. In this case an attack on the accounting system (by distortion of data or issuing false configuration commands) may result in incorrect resource management and DoS by artificial resource starvation.
OPESシステムは、会計情報を使用して、異なる消費者間でリソースを配布したり、特定の消費者によるリソースの使用を制限する場合があります。この場合、会計システムへの攻撃（データの歪みまたは誤った構成コマンドの発行による）により、人工リソースの飢vによって誤ったリソース管理とDOSが生じる可能性があります。
An entity (producer or consumer) might make an authorized request and later claim that it did not make that request. As a result, an OPES entity may be held liable for unauthorized changes to the data flow, or will be unable to receive compensation for a service.
エンティティ（プロデューサーまたは消費者）は、許可された要求を行い、後にその要求を行わなかったと主張する場合があります。その結果、OPESエンティティは、データフローの不正な変更に対して責任を負うか、サービスの報酬を受け取ることができません。
There should be a clear request that this service is required and there should be a clear course of action on behalf of all parties. This action should have a request, an action, a non-repudiable means of verifying the request, and a means of specifying the effect of the action.
このサービスが必要であるという明確な要求があり、すべての関係者に代わって明確な行動方針があるはずです。このアクションには、リクエスト、アクション、リクエストを検証する修正できない手段、およびアクションの効果を指定する手段が必要です。
The OPES entities may have privacy policies that are not consistent with the data consumer application or content provider application.
OPESエンティティには、データ消費者アプリケーションまたはコンテンツプロバイダーアプリケーションと一致しないプライバシーポリシーがある場合があります。
Privacy related problems may be further complicated if OPES entities, content providers, and end users belong to different jurisdictions with different requirements and different levels of legal protection. As a result, the end user may not be aware that he or she does not have the expected legal protection. The content provider may be exposed to legal risks due to a failure to comply with regulations of which he is not even aware.
OPESエンティティ、コンテンツプロバイダー、およびエンドユーザーが、異なる要件と異なるレベルの法的保護を備えた異なる管轄区域に属している場合、プライバシー関連の問題はさらに複雑になる可能性があります。その結果、エンドユーザーは、予想される法的保護がないことを認識していない場合があります。コンテンツプロバイダーは、彼が認識していない規制を順守しなかったため、法的リスクにさらされる可能性があります。
The OPES system may inadvertently or maliciously expose end user privacy settings and requirements.
OPESシステムは、エンドユーザーのプライバシー設定と要件を不注意にまたは悪意のあると公開する場合があります。
There are risks that the OPES system may expose end user security settings when handling the request and responses. The user data must be handled as sensitive system information and protected against accidental and deliberate disclosure.
リクエストと応答を処理するときに、OPESシステムがエンドユーザーセキュリティ設定を公開する可能性があるというリスクがあります。ユーザーデータは、敏感なシステム情報として処理され、偶発的かつ意図的な開示から保護される必要があります。
OPES entities are part of the content distribution system and as such take on certain obligations to support security and privacy policies mandated by the content producer and/or end user. However there is a danger that these policies are not properly implemented and enforced. The data consumer application may not be aware that its protections are no longer in effect.
OPESエンティティはコンテンツ配信システムの一部であり、コンテンツプロデューサーおよび/またはエンドユーザーが義務付けているセキュリティおよびプライバシーポリシーをサポートするための特定の義務を負います。ただし、これらのポリシーが適切に実装および施行されていないという危険があります。データ消費者アプリケーションは、その保護がもはや有効ではないことを認識していない場合があります。
There is also the possibility of security and privacy leaks due to the accidental misconfiguration or, due to misunderstanding what rules are in effect for a particular user or request.
また、偶発的な誤解のために、または特定のユーザーまたはリクエストのルールが有効なルールの誤解により、セキュリティとプライバシーのリークの可能性もあります。
Privacy and security related parts of the systems can be targeted by malicious attacks and the ability to withstand such attacks is of paramount importance.
システムのプライバシーとセキュリティに関連する部分は、悪意のある攻撃によって標的にされる可能性があり、そのような攻撃に耐える能力は非常に重要です。
DoS attacks can be of various types. One type of DoS attack takes effect by overloading the client. For example, an intruder can direct an OPES processor to issue numerous responses to a client. There is also additional DoS risk from a rule misconfiguration that would have the OPES processor ignore a data consumer application.
DOS攻撃にはさまざまなタイプがあります。1つのタイプのDOS攻撃は、クライアントを過負荷にすることで有効になります。たとえば、侵入者はOPESプロセッサにクライアントに多数の応答を発行するよう指示できます。また、OPESプロセッサがデータコンシューマーアプリケーションを無視するようにするルールの誤解からの追加のDOSリスクもあります。
This document discusses multiple security and privacy issues related to the OPES services.
このドキュメントでは、OPESサービスに関連する複数のセキュリティおよびプライバシーの問題について説明します。
[1] Barbir, A., Penno, R., Chen, R., Hofmann, M., and H. Orman, "An Architecture for Open Pluggable Edge Services (OPES)", RFC 3835, August 2004.
[1] Barbir、A.、Penno、R.、Chen、R.、Hofmann、M。、およびH. Orman、「Open Pluggable Edge Services（OPES）のアーキテクチャ」、RFC 3835、2004年8月。
[2] Barbir, A., Burger, E., Chen, R., McHenry, S., Orman, H., and R. Penno, "OPES Use Cases and Deployment Scenarios", RFC 3752, April 2004.
[2] Barbir、A.、Burger、E.、Chen、R.、Mchenry、S.、Orman、H。、およびR. Penno、「Opesユースケースと展開シナリオ」、RFC 3752、2004年4月。
[3] Barbir, A., Batuner, O., Beck, A., Chan, T., and H. Orman, "Policy, Authorization, and Enforcement Requirements of Open Pluggable Edge Services (OPES)", RFC 3838, August 2004.
[3] Barbir、A.、Batuner、O.、Beck、A.、Chan、T。、およびH. Orman、「Open Pluggable Edge Services（OPES）のポリシー、承認、および執行要件」、RFC 3838、2004年8月。
[4] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.
[4] Floyd、S。and L. Daigle、「Open Pluggable Edge ServicesのIAB建築および政策上の考慮事項」、RFC 3238、2002年1月。
Many thanks to T. Chan (Nokia) and A. Beck (Lucent).
T. Chan（Nokia）とA. Beck（Lucent）に感謝します。
Abbie Barbir Nortel Networks 3500 Carling Avenue Nepean, Ontario K2H 8E9 Canada
Abbie Barbir Nortel Networks 3500 Carling Avenue Nepean、オンタリオK2H 8E9カナダ
Phone: +1 613 763 5229
EMail: abbieb@nortelnetworks.com
Oskar Batuner Independent consultant
Oskar Batuner Independent Consultant
EMail: batuner@attbi.com
Bindignavile Srinivas Nokia 5 Wayside Road Burlington, MA 01803 USA
Bindignavile Srinivas Nokia 5ウェイサイドロードバーリントン、マサチューセッツ州01803 USA
EMail: bindignavile.srinivas@nokia.com
Markus Hofmann Bell Labs/Lucent Technologies Room 4F-513 101 Crawfords Corner Road Holmdel, NJ 07733 US
Markus Hofmann Bell Labs/Lucent Technologies Room 4F-513 101 Crawfords Corner Road Holmdel、NJ 07733 US
Phone: +1 732 332 5983
EMail: hofmann@bell-labs.com
Hilarie Orman Purple Streak Development
ヒラリーオーマンパープルストリーク開発
EMail: ho@alum.mit.edu
Copyright (C) The Internet Society (2004). 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.
著作権（c）The Internet Society（2004）。この文書は、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エディター機能の資金は現在、インターネット協会によって提供されています。