[要約] 要約： RFC 4097は、MIDCOMプロトコルの評価に関する情報を提供するものであり、ミドルボックス間の通信に関する問題を解決するためのソリューションを提案しています。目的： - MIDCOMプロトコルの評価を通じて、ミドルボックス間の通信の効率性と信頼性を向上させる。 - ミドルボックス間の通信に関する問題を特定し、解決策を提案する。 - ネットワークのパフォーマンスとセキュリティを向上させるためのガイドラインを提供する。
Network Working Group M. Barnes, Ed.
Request for Comments: 4097 Nortel Networks
Category: Informational June 2005
Middlebox Communications (MIDCOM) Protocol Evaluation
Middlebox Communications（MIDCOM）プロトコル評価
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 provides an evaluation of the applicability of SNMP (Simple Network Management Protocol), RSIP (Realm Specific Internet Protocol), Megaco, Diameter, and COPS (Common Open Policy Service) as the MIDCOM (Middlebox Communications) protocol. A summary of each of the proposed protocols against the MIDCOM requirements and the MIDCOM framework is provided. Compliancy of each of the protocols against each requirement is detailed. A conclusion summarizes how each of the protocols fares in the evaluation.
このドキュメントは、SNMP（シンプルネットワーク管理プロトコル）、RSIP（レルム固有のインターネットプロトコル）、メガコ、直径、およびCOP（一般的なオープンポリシーサービス）のMIDCOM（Midbox Communications）プロトコルの適用性の評価を提供します。MIDCOM要件とMIDCOMフレームワークに対する提案された各プロトコルの概要が提供されます。各要件に対する各プロトコルの準拠について詳しく説明します。結論は、各プロトコルが評価にどのように運賃を運ぶかを要約しています。
Table of Contents
目次
Overview.......................................................... 2
Conventions Used in This Document................................. 3
1. Protocol Proposals............................................ 3
1.1. SNMP.................................................... 3
1.2. RSIP.................................................... 5
1.3. Megaco.................................................. 7
1.4. Diameter................................................ 8
1.5. COPS.................................................... 10
2. Item Level Compliance Evaluation.............................. 11
2.1. Protocol Machinery...................................... 11
2.2. Protocol Semantics...................................... 20
2.3. General Security Requirements........................... 27
3. Conclusions................................................... 29
4. Security Considerations....................................... 30
5. References.................................................... 31
5.1. Normative References.................................... 31
5.2. Informative References.................................. 33
6. Acknowledgements.............................................. 33
Appendix A - SNMP Overview........................................ 34
Appendix B - RSIP with Tunneling.................................. 35
Appendix C - Megaco Modeling Approach............................. 37
Appendix D - Diameter IPFilter Rule............................... 39
Contributors ..................................................... 42
Overview
概要
This document provides an evaluation of the applicability of SNMP (Simple Network Management Protocol), RSIP (Realm Specific Internet Protocol), Megaco, Diameter and COPS (Common Open Policy Service) as the MIDCOM (Middlebox Communications) protocol. This evaluation provides overviews of the protocols and general statements of applicability based upon the MIDCOM framework [2] and requirements [1] documents.
このドキュメントは、SNMP（シンプルネットワーク管理プロトコル）、RSIP（レルム固有のインターネットプロトコル）、メガコ、直径、COP（一般的なオープンポリシーサービス）のMIDCOM（Midbox Communications）プロトコルの適用性の評価を提供します。この評価は、MIDCOMフレームワーク[2]および要件[1]ドキュメントに基づいて、プロトコルの概要と適用可能性の一般的なステートメントを提供します。
The process for the protocol evaluation was fairly straightforward as individuals volunteered to provide an individual document evaluating a specific protocol. Thus, some protocols that might be considered as reasonably applicable as the MIDCOM protocol are not evaluated in this document since there were no volunteers to champion the work. The individual protocol documents for which there were volunteers were submitted for discussion on the list with feedback being incorporated into an updated document. The updated versions of these documents formed the basis for the content of this WG document.
プロトコル評価のプロセスは、個人が特定のプロトコルを評価する個々の文書を提供することに志願したため、かなり簡単でした。したがって、作品を支持するボランティアがいなかったため、MIDCOMプロトコルと同様に合理的に適用可能であると考えられる可能性のある一部のプロトコルは、このドキュメントでは評価されていません。ボランティアがいた個々のプロトコルドキュメントは、更新されたドキュメントにフィードバックが組み込まれ、リストに関する議論のために提出されました。これらのドキュメントの更新されたバージョンは、このWGドキュメントのコンテンツの基礎を形成しました。
Section 1 contains a list of the proposed protocols submitted for the purposes of the protocol evaluation with some background information on the protocols and similarities and differences with regards to the applicability to the framework [2] provided.
セクション1には、プロトコル評価の目的で提案されたプロトコルのリストが含まれています。
Section 2 provides the item level evaluation of the proposed protocols against the Requirements [1].
セクション2では、要件に対する提案されたプロトコルのアイテムレベルの評価を提供します[1]。
Section 3 provides a summary of the evaluation. A table containing a numerical breakdown for each of the protocols, with regards to its applicability to the requirements, for the following categories is provided: Fully met, Partially met through the use of extensions, Partially met through other changes to the protocol, or Failing to be met. This summary is not meant to provide a conclusive statement of the suitability of the protocols, but rather to provide information to be considered as input into the overall protocol decision process.
セクション3では、評価の概要を説明します。次のカテゴリに対して、要件への適用性に関して、各プロトコルの数値破壊を含むテーブルが提供されます。拡張機能を使用して部分的に満たし、プロトコルの他の変更を介して部分的に満たされる、または障害会う。この概要は、プロトコルの適合性に関する決定的な声明を提供することではなく、プロトコル全体の決定プロセスへの入力と見なされる情報を提供することを目的としています。
In order for this document to serve as a complete evaluation of the protocols, some of the background information and more detailed aspects of the proposals documenting enhancements and applications of the protocols to comply with the MIDCOM framework and requirements are included in Appendices.
このドキュメントがプロトコルの完全な評価として機能するためには、MIDCOMフレームワークと要件に準拠するためのプロトコルの強化とアプリケーションを文書化する提案のいくつかの背景情報とより詳細な側面が付録に含まれています。
Conventions Used in this Document
このドキュメントで使用されている規則
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [4].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC 2119 [4]に記載されているように解釈される。
The following protocols were submitted to the MIDCOM WG for consideration:
以下のプロトコルは、検討のためにMIDCOM WGに提出されました。
o SNMP o RSIP o Megaco o Diameter o COPS
o SNMP O RSIP O MEGACO O直径O警官
The following provides an overview of each of the protocols and the applicability of each protocol to the MIDCOM framework.
以下は、各プロトコルの概要と、各プロトコルのMIDCOMフレームワークへの適用性を示しています。
This section provides a general statement with regards to the applicability of SNMP as the MIDCOM protocol. A general overview and some specific details of SNMP are provided in Appendix A. This evaluation of SNMP is specific to SNMPv3, which provides the security required for MIDCOM usage. SNMPv1 and SNMPv2c would be inappropriate for MIDCOM since they have been declared Historic, and because their messages have only trivial security. Some specifics with regards to existing support for NAT and Firewall Control are provided in section 1.1.2. The differences between the SNMP framework and the MIDCOM framework are addressed in section 1.1.3.
このセクションでは、MIDCOMプロトコルとしてのSNMPの適用性に関する一般的な声明を提供します。SNMPの一般的な概要といくつかの特定の詳細は、付録Aに記載されています。SNMPのこの評価はSNMPV3に固有であり、Midcomの使用に必要なセキュリティを提供します。SNMPV1とSNMPV2Cは、歴史的であると宣言されているため、およびメッセージには些細なセキュリティしかないため、MIDCOMにとっては不適切です。NATおよびファイアウォール制御の既存のサポートに関するいくつかの詳細については、セクション1.1.2に記載されています。SNMPフレームワークとMIDCOMフレームワークの違いについては、セクション1.1.3で説明します。
The primary advantages of SNMPv3 are that it is a mature, well understood protocol, currently deployed in various scenarios, with mature toolsets available for SNMP managers and agents.
SNMPV3の主な利点は、SNMPマネージャーとエージェントが利用できる成熟したツールセットを使用して、さまざまなシナリオで展開されている成熟したよく理解されているプロトコルであることです。
Application intelligence is captured in MIB modules, rather than in the messaging protocol. MIB modules define a data model of the information that can be collected and configured for a managed functionality. The SNMP messaging protocol transports the data in a standardized format without needing to understand the semantics of the data being transferred. The endpoints of the communication understand the semantics of the data.
アプリケーションインテリジェンスは、メッセージングプロトコルではなく、MIBモジュールでキャプチャされます。MIBモジュールは、管理された機能のために収集および構成できる情報のデータモデルを定義します。SNMPメッセージングプロトコルは、転送されるデータのセマンティクスを理解する必要なく、データを標準化された形式で輸送します。通信のエンドポイントは、データのセマンティクスを理解しています。
Partly due to the lack of security in SNMPv1 and SNMPv2c, and partly due to variations in configuration requirements across vendors, few MIB modules have been developed that enable standardized configuration of managed devices across vendors. Since monitoring can be done using only a least-common-denominator subset of information across vendors, many MIB modules have been developed to provide standardized monitoring of managed devices. As a result, SNMP has been used primarily for monitoring rather than for configuring network nodes.
SNMPV1およびSNMPV2Cのセキュリティがないため、およびベンダー間での構成要件の変動の一部が原因で、ベンダー間で管理されたデバイスの標準化された構成を可能にするMIBモジュールはほとんど開発されていません。監視はベンダー間の情報の最小コモンデノミネーターサブセットのみを使用して行うことができるため、管理されたデバイスの標準化された監視を提供するために多くのMIBモジュールが開発されています。その結果、SNMPは、ネットワークノードの構成ではなく、主に監視に使用されています。
SNMPv3 builds upon the design of widely-deployed SNMPv1 and SNMPv2c versions. Specifically, SNMPv3 shares the separation of data modeling (MIBs) from the protocol to transfer data, so all existing MIBs can be used with SNMPv3. SNMPv3 also uses the SMIv2 standard, and it shares operations and transport with SNMPv2c. The major difference between SNMPv3 and earlier versions is the addition of strong message security and controlled access to data.
SNMPV3は、広く展開されたSNMPV1およびSNMPV2Cバージョンの設計に基づいています。具体的には、SNMPV3はデータモデリング（MIBS）の分離をプロトコルからデータ転送に共有するため、既存のMIBはすべてSNMPV3で使用できます。SNMPV3はSMIV2標準も使用しており、SNMPV2Cと運用と輸送を共有しています。SNMPV3と以前のバージョンの主な違いは、強力なメッセージセキュリティとデータへの制御アクセスの追加です。
SNMPv3 uses the architecture detailed in RFC 3411 [5], where all SNMP entities are capable of performing certain functions, such as the generation of requests, response to requests, the generation of asynchronous notifications, the receipt of notifications, and the proxy-forwarding of SNMP messages. SNMP is used to read and manipulate virtual databases of managed-application-specific operational parameters and statistics, which are defined in MIB modules.
SNMPV3は、RFC 3411 [5]で詳述されているアーキテクチャを使用します。ここでは、すべてのSNMPエンティティは、リクエストの生成、リクエストへの応答、非同期通知の生成、通知の受領、およびプロキシフォーワングなどの特定の機能を実行できます。SNMPメッセージの。SNMPは、MIBモジュールで定義されている管理されたアプリケーション固有の運用パラメーターと統計の仮想データベースの読み取りと操作に使用されます。
For configuring NATs, a NAT MIB module [16] has been developed. The NAT MIB module meets all of the MIDCOM requirements concerning NAT control with the exception of grouping of policy rules (requirement 2.2.3.). In order to support this, an additional grouping table in the NAT MIB module is required.
NATを構成するために、NAT MIBモジュール[16]が開発されました。NAT MIBモジュールは、ポリシールールのグループ化を除き、NATコントロールに関するすべてのMIDCOM要件を満たしています（要件2.2.3。）。これをサポートするには、NAT MIBモジュールの追加のグループテーブルが必要です。
Existing work for firewall control with SNMP only considered the monitoring of firewalls and not the configuration. Further work is required towards the development of MIBs for configuring firewalls.
SNMPを使用したファイアウォール制御の既存の作業は、構成ではなくファイアウォールの監視のみを考慮しています。ファイアウォールを構成するためのMIBSの開発に向けてさらなる作業が必要です。
The SNMP management framework provides functions equivalent to those defined by the MIDCOM framework, although there are a few architectural differences.
SNMP管理フレームワークは、Midcomフレームワークで定義された機能に相当する関数を提供しますが、いくつかのアーキテクチャの違いがあります。
Traditionally, SNMP entities have been called Manager and Agent. Manager and agent are now recognized as entities designed to support particular configurations of SNMPv3 functions. A traditional manager is an entity capable of generating requests and receiving notifications, and a traditional agent is an entity capable of responding to requests and generating notifications. The SNMP use of the term agent is different from its use in the MIDCOM framework: The SNMP Manager corresponds to the MIDCOM agent and the SNMP Agent corresponds to the MIDCOM PDP. The SNMP evaluation assumes that the MIDCOM PDP (SNMP Agent) is physically part of the middlebox, which is allowed by the MIDCOM framework as described in section 6.0 of [2]. Thus, for the purpose of this evaluation, the SNMP agent corresponds to the Middlebox.
従来、SNMPエンティティはマネージャーおよびエージェントと呼ばれてきました。マネージャーとエージェントは、SNMPV3関数の特定の構成をサポートするように設計されたエンティティとして認識されています。従来のマネージャーは、リクエストを生成して通知を受信できるエンティティであり、従来のエージェントは、リクエストに応答して通知を生成できるエンティティです。用語エージェントのSNMP使用は、MIDCOMフレームワークでの使用とは異なります。SNMPマネージャーはMIDCOMエージェントに対応し、SNMPエージェントはMIDCOM PDPに対応します。SNMP評価では、MIDCOM PDP（SNMPエージェント）が物理的にミドルボックスの一部であることを前提としています。したがって、この評価の目的のために、SNMPエージェントはミドルボックスに対応します。
While this evaluation is based on the assumption that the SNMP agent corresponds to the middlebox, SNMP does not force such a restriction.
この評価は、SNMPエージェントがミドルボックスに対応するという仮定に基づいていますが、SNMPはそのような制限を強制しません。
Proxy means many things to many people. SNMP can be deployed using intermediate entities to forward messages, or to help distribute policies to the middlebox, similar to the proxy capabilities of the other candidate protocols. Since proxy adds configuration and deployment complexity and is not necessary to meet the specified MIDCOM requirements, the use of a proxy agent or mid-level manager is not considered in this evaluation. Further details on SNMP proxy capabilities are provided in Appendix A.
プロキシとは、多くの人々にとって多くのことを意味します。SNMPは、中間エンティティを使用してメッセージを転送するか、他の候補プロトコルのプロキシ機能と同様に、ミドルボックスにポリシーを配布するのに役立つことができます。プロキシは構成と展開の複雑さを追加し、指定されたMIDCOM要件を満たすために必要ではないため、この評価ではプロキシエージェントまたはミッドレベルマネージャーの使用は考慮されません。SNMPプロキシ機能の詳細については、付録Aに記載されています。
Although the SNMP management framework does not have the concept of a session, session-like associations can be established through the use of managed objects. In order to implement the MIDCOM protocol based on SNMP, a MIDCOM MIB module is required. All requests from the MIDCOM agent to the Middlebox would be performed using write access to managed objects defined in the MIDCOM MIB module. Replies to requests are signaled by the Middlebox (SNMP agent), by modifying the managed objects. The MIDCOM agent (SNMP manager) can receive this information by reading or polling, if required, the corresponding managed object.
SNMP管理フレームワークにはセッションの概念はありませんが、セッションのような関連性は、管理されたオブジェクトを使用して確立できます。SNMPに基づいてMIDCOMプロトコルを実装するには、MIDCOM MIBモジュールが必要です。Midcomエージェントからミドルボックスへのすべての要求は、Midcom MIBモジュールで定義された管理されたオブジェクトへの書き込みアクセスを使用して実行されます。リクエストへの返信は、管理されたオブジェクトを変更することにより、ミドルボックス（SNMPエージェント）によって通知されます。MIDCOMエージェント（SNMPマネージャー）は、必要に応じて対応する管理されたオブジェクトを読み取りまたはポーリングすることにより、この情報を受信できます。
The RSIP framework and detailed protocol are defined in RFC 3102 [17] and RFC 3103 [18] respectively.
RSIPフレームワークと詳細なプロトコルは、それぞれRFC 3102 [17]およびRFC 3103 [18]で定義されています。
The following framework elements are common to MIDCOM and RSIP listed by their MIDCOM names, with the RSIP name indicated in parenthesis:
次のフレームワーク要素は、MIDCOMとRSIPのMIDCOM名でリストされており、RSIP名は括弧で示されています。
o Hosts o Applications o Middleboxes (RSIP gateways) o Private domain (private realm) o External domain (public realm) o Middlebox communication protocol (RSIP) o MIDCOM agent registration (host registration) o MIDCOM session (RSIP session) o MIDCOM Filter (local / remote address and port number(s) pairs)
o ホストoアプリケーションoミドルボックス（RSIPゲートウェイ）oプライベートドメイン（プライベートレルム）o外部ドメイン（パブリックレルム）oミドルボックス通信プロトコル（RSIP）o MIDCOMエージェント登録（ホスト登録）o MIDCOMセッション（RSIPセッション）o Midcomフィルター（ローカルフィルター（ローカル）/リモートアドレスとポート番号のペア）
The following MIDCOM framework elements are not supported by RSIP:
次のMIDCOMフレームワーク要素は、RSIPによってサポートされていません。
o Policy actions and rules. RSIP always implicitly assumes a permit action. To support MIDCOM, a more general and explicit action parameter would have to be defined. RSIP requests specifying local / remote address and port number(s) pairs would have to be extended to include an action parameter, in MIDCOM rules.
o ポリシーアクションとルール。RSIPは常に暗黙的に許可訴訟を想定しています。Midcomをサポートするには、より一般的で明示的なアクションパラメーターを定義する必要があります。MIDCOMルールにアクションパラメーターを含めるために、ローカル /リモートアドレスとポート番号の指定を指定するRSIP要求は、拡張する必要があります。
o MIDCOM agents. RSIP makes no distinction between applications and agents; address assignment operations can be performed equally by applications and agents.
o Midcomエージェント。RSIPは、アプリケーションとエージェントを区別しません。アドレス割り当て操作は、アプリケーションとエージェントによって均等に実行できます。
o Policy Decision Points. RSIP assumes that middleboxes grant or deny requests with reference to a policy known to them; the policy could be determined jointly by the middlebox and a policy decision point; such joint determination is not addressed by the RSIP framework, nor is it specifically precluded.
o 政策決定ポイント。RSIPは、ミドルボックスがそれらに知られているポリシーを参照してリクエストを付与または拒否すると想定しています。ポリシーは、ミドルボックスとポリシーの決定ポイントによって共同で決定できます。このような共同決定は、RSIPフレームワークによって対処されておらず、特に排除されていません。
The following elements are unique to the RSIP framework. If RSIP were adopted as the basis for the MIDCOM protocol, they could be added to the MIDCOM framework:
次の要素は、RSIPフレームワークに固有のものです。RSIPがMIDCOMプロトコルの基礎として採用された場合、MIDCOMフレームワークに追加できます。
o RSIP client: that portion of the application (or agent) that talks to the RSIP gateway using RSIP.
o RSIPクライアント：RSIPを使用してRSIPゲートウェイに話しかけるアプリケーション（またはエージェント）の部分。
o RSIP server: that portion of an RSIP gateway that talks to applications using RSIP.
o RSIPサーバー：RSIPを使用してアプリケーションに話しかけるRSIPゲートウェイのその部分。
o Realm Specific Address IP (RSA-IP) and Realm Specific Address and Port IP (RSAP-IP): RSIP distinguishes between filters that include all ports on an IP address and those that do not.
o レルム固有のアドレスIP（RSA-IP）およびレルム固有のアドレスとポートIP（RSAP-IP）：RSIPは、IPアドレス上のすべてのポートを含むフィルターとそうでないフィルターを区別します。
o Demultiplexing Fields: Any set of packet header or payload fields that an RSIP gateway uses to route an incoming packet to an RSIP host. RSIP allows a gateway to perform, and an application to control, packet routing to hosts in the private domain based on more than IP header fields.
o Demultiplexingフィールド：RSIPゲートウェイが使用するパケットヘッダーまたはペイロードフィールドのセットは、着信パケットをRSIPホストにルーティングします。RSIPを使用すると、ゲートウェイを実行し、IPヘッダーフィールド以上に基づいてプライベートドメインのホストへのパケットルーティングを制御するアプリケーションを可能にします。
o Host-to-middlebox tunnels: RSIP assumes that data communicated between a private realm host and a public realm host is transferred through the private realm by a tunnel between the inner host and the middle box, where it is converted to and from native IP based communications to the public realm host.
o ホストからミドルボックストンネル：RSIPは、プライベートレルムホストとパブリックレルムホストの間で通信されたデータが、内部ホストと中央のボックスの間のトンネルによってプライベートレルムを介して転送されると想定しています。パブリックレルムホストとのコミュニケーション。
RSIP with tunneling, has the advantage that the public realm IP addresses and port numbers are known to the private realm host application, thus no translation is needed for protocols such as SDP, the FTP control protocol, RTSP, SMIL, etc. However, this does require that an RSIP server and a tunneling protocol be implemented in the middlebox and an RSIP client and the tunneling protocol be implemented in the private realm host. The host modifications can generally be made without modification to the host application or requiring the implementation of a host application agent. This is viewed as a significant advantage over NAT (Network Address Translation).
トンネリングを備えたRSIPには、パブリックレルムIPアドレスとポート番号がプライベートレルムホストアプリケーションに知られているという利点があるため、SDP、FTP制御プロトコル、RTSP、スミルなどのプロトコルには翻訳は必要ありません。RSIPサーバーとトンネルプロトコルをMiddleboxに実装し、RSIPクライアントとトンネリングプロトコルをプライベートレルムホストに実装する必要があります。ホストの変更は、通常、ホストアプリケーションを変更したり、ホストアプリケーションエージェントの実装を要求したりすることなく行うことができます。これは、NAT（ネットワークアドレス変換）よりも大きな利点と見なされています。
Further details on the evaluation of RSIP with regards to tunneling in the context of NAT support are available in Appendix B of this document.
NATサポートのコンテキストでのトンネリングに関するRSIPの評価の詳細については、このドキュメントの付録Bに記載されています。
Megaco is a master-slave, transaction-oriented protocol defined in RFC 3015 [20] in which Media Gateway Controllers (MGC) control the operation of Media Gateways (MG). Originally designed to control IP Telephony gateways, it is used between an application-unaware device (the Media Gateway) and an intelligent entity (the Media Gateway Controller) having application awareness.
Megacoは、Media Gateway Controllers（MGC）がMedia Gateway（MG）の動作を制御するRFC 3015 [20]で定義されているマスタースレーブ、トランザクション指向のプロトコルです。もともとIPテレフォニーゲートウェイを制御するように設計されていましたが、アプリケーションとアウェアのデバイス（メディアゲートウェイ）とアプリケーションの認識を持つインテリジェントエンティティ（メディアゲートウェイコントローラー）の間で使用されます。
The Megaco model includes the following key concepts:
Megacoモデルには、次の重要な概念が含まれています。
1. Terminations: Logical entities on the MG that act as sources or sink of packet streams. A termination can be physical or ephemeral and is associated with a single MGC.
1. 終了：パケットストリームのソースまたはシンクとして機能するMG上の論理エンティティ。終了は物理的または一時的なものであり、単一のMGCに関連付けられています。
2. Context: An association between Terminations for sharing media between the Terminations. Terminations can be added, subtracted from a Context and can be moved from one Context to another. A Context and all of its Terminations are associated with a single MGC.
2. コンテキスト：終端間でメディアを共有するための終了間の関連。終了を追加して、コンテキストから差し引いて、あるコンテキストから別のコンテキストに移動できます。コンテキストとそのすべての終端は、単一のMGCに関連付けられています。
3. Virtual Media Gateways: A physical MG can be partitioned into multiple virtual MGs allowing multiple Controllers to interact with disjoint sets of Contexts/Terminations within a single physical device.
3. 仮想メディアゲートウェイ：物理MGを複数の仮想MGに分割することができ、複数のコントローラーが単一の物理デバイス内のコンテキスト/終端の分離セットと対話することができます。
4. Transactions/Messages: Each Megaco command applies to one Termination within a Context and generates a unique response. Commands may be replicated implicitly so that they act on all Terminations of a given Context through wildcarding of Termination identifiers. Multiple commands addressed to different Contexts can be grouped in a Transaction structure. Similarly, multiple Transactions can be concatenated into a Message.
4. トランザクション/メッセージ：各Megacoコマンドは、コンテキスト内の1つの終了に適用され、一意の応答を生成します。コマンドは、終了識別子のワイルドカードを通じて特定のコンテキストのすべての終了に作用するように暗黙的に複製できます。さまざまなコンテキストにアドレス指定された複数のコマンドは、トランザクション構造にグループ化できます。同様に、複数のトランザクションをメッセージに連結できます。
5. Descriptors/Properties: A Termination is described by a number of characterizing parameters or Properties, which are grouped in a set of Descriptors that are included in commands and responses.
5. 記述子/プロパティ：終了は、コマンドと応答に含まれる記述子のセットにグループ化された多くの特性化パラメーターまたはプロパティによって説明されます。
6. Events and signals: A Termination can be programmed to perform certain actions or to detect certain events and notify the Agent.
6. イベントとシグナル：特定のアクションを実行したり、特定のイベントを検出したり、エージェントに通知したりするために、終了をプログラムできます。
7. Packages: Packages are groups of properties, events, etc. associated with a Termination. Packages are simple means of extending the protocol to serve various types of devices or Middleboxes.
7. パッケージ：パッケージは、終了に関連するプロパティ、イベントなどのグループです。パッケージは、さまざまなタイプのデバイスまたはミドルボックスを提供するためにプロトコルを拡張する簡単な手段です。
In the MIDCOM architecture, the Middlebox plays the role of an application-unaware device being controlled by the application-aware Agent. In the Megaco architecture, the Media Gateway controller serves a role similar to the MIDCOM Agent (MA) and the Media Gateway serves a role similar to the Middlebox (MB). One major difference between the Megaco model and the MIDCOM protocol requirements is that MIDCOM requires that the MIDCOM Agent establish the session. Whereas, the Megaco definition is that a MG (Middlebox) establishes communication with an MGC (MIDCOM Agent).
Midcomアーキテクチャでは、Middleboxは、アプリケーションを認識しているエージェントによって制御されるアプリケーションとアウェアのデバイスの役割を果たします。Megaco Architectureでは、Media Gateway ControllerがMidcomエージェント（MA）と同様の役割を果たし、Media GatewayはMiddlebox（MB）と同様の役割を果たします。MegacoモデルとMIDCOMプロトコル要件の1つの大きな違いは、MIDCOMがMIDCOMエージェントがセッションを確立することを要求することです。一方、メガコの定義は、MG（Middlebox）がMGC（Midcomエージェント）との通信を確立することです。
Diameter is designed to support AAA for network access. It is meant to operate through networks of Diameter nodes, which both act upon and route messages toward their final destinations. Endpoints are characterized as either clients, which perform network access control, or servers, which handle authentication, authorization and accounting requests for a particular realm. Intermediate nodes perform relay, proxy, redirect, and translation services. Design requirements for the protocol include robustness in the face of bursty message loads and server failures, resistance to specific DOS attacks and protection of message contents, and extensibility including support for vendor-specific attributes and message types.
直径は、ネットワークアクセスのためにAAAをサポートするように設計されています。これは、直径ノードのネットワークを介して動作することを目的としています。これは、最終目的地に向かってメッセージに基づいて行動し、ルーティングすることができます。エンドポイントは、特定の領域の認証、承認、会計リクエストを処理するネットワークアクセス制御を実行するクライアント、またはサーバーを実行するクライアントとして特徴付けられます。中間ノードは、リレー、プロキシ、リダイレクト、および翻訳サービスを実行します。プロトコルの設計要件には、破裂したメッセージの負荷とサーバーの障害、特定のDOS攻撃に対する抵抗とメッセージコンテンツの保護、およびベンダー固有の属性とメッセージタイプのサポートを含む拡張性に直面した堅牢性が含まれます。
The protocol is designed as a base protocol in RFC 3588 [24] to be supported by all implementations, plus extensions devoted to specific applications. Messages consist of a header and an aggregation of "Attribute-Value Pairs (AVPs)", each of which is a tag-length-value construct. The header includes a command code, which determines the processing of the message and what other AVP types must or may be present. AVPs are strongly typed. Some basic and compound types are provided by the base protocol specification, while others may be added by application extensions. One of the types provided in the base is the IPFilterRule, which may be sufficient to express the Policy Rules that MIDCOM deals with.
このプロトコルは、RFC 3588 [24]のベースプロトコルとして設計されており、すべての実装と特定のアプリケーションに特化した拡張機能によってサポートされます。メッセージは、ヘッダーと「属性値ペア（AVPS）」の集約で構成されており、それぞれがタグレングス価値コンストラクトです。ヘッダーにはコマンドコードが含まれており、メッセージの処理と、他のAVPタイプが存在するかどうかを決定します。AVPは強く入力されます。基本的なタイプと化合物のいくつかは、ベースプロトコル仕様によって提供されますが、他のタイプはアプリケーション拡張機能によって追加される場合があります。ベースに提供されるタイプの1つはIPFilterruleです。これは、Midcomが扱うポリシールールを表現するのに十分かもしれません。
Messaging takes the form of request-answer exchanges. Some exchanges may take multiple round-trips to complete. The protocol is connection-oriented at both the transport and application levels. In addition, the protocol is tied closely to the idea of sessions, which relate sequences of message exchanges through use of a common session identifier. Each application provides its own definition of the semantics of a session. Multiple sessions may be open simultaneously.
メッセージングは、リクエストアンスワーの交換の形を取ります。一部の交換は、完了するために複数のラウンドトリップを取る場合があります。プロトコルは、輸送レベルとアプリケーションレベルの両方で接続指向です。さらに、プロトコルは、一般的なセッション識別子を使用してメッセージ交換のシーケンスを関連付けるセッションのアイデアに密接に結び付けられています。各アプリケーションは、セッションのセマンティクスの独自の定義を提供します。複数のセッションが同時に開いている場合があります。
The MIDCOM Agent does not perform the functions of a Diameter client, nor does the Middlebox support the functions of a Diameter server. Thus the MIDCOM application would introduce two new types of endpoints into the Diameter architecture. Moreover, the MIDCOM requirements do not at this time imply any type of intermediate node.
MIDCOMエージェントは、直径クライアントの機能を実行せず、MiddleBoxが直径サーバーの機能をサポートしていません。したがって、MIDCOMアプリケーションは、2つの新しいタイプのエンドポイントを直径アーキテクチャに導入します。さらに、MIDCOMの要件は、現時点では中間ノードの種類を暗示していません。
A general assessment might be that Diameter meets and exceeds MIDCOM architectural requirements, however the connection orientation may be too heavy for the number of relationships the Middlebox must support. Certainly the focus on extensibility, request-response messaging orientation, and treatment of the session, are all well-matched to what MIDCOM needs. At this point, MIDCOM is focused on simple point-to-point relationships, so the proxying and forwarding capabilities provided by Diameter are not needed. Most of the commands and AVPs defined in the base protocol are also surplus to MIDCOM requirements.
一般的な評価では、直径がMidcomアーキテクチャの要件を満たし、それを超えることがありますが、接続の方向は、ミドルボックスがサポートしなければならない関係の数に対して重すぎる可能性があります。確かに、拡張性、リクエスト応答メッセージングの向き、セッションの扱いに焦点を当てていることはすべて、MIDCOMが必要とするものによく一致しています。この時点で、Midcomは単純なポイントツーポイントとポイントの関係に焦点を合わせているため、直径によって提供されるプロキシおよび転送機能は必要ありません。ベースプロトコルで定義されているコマンドとAVPのほとんどは、MIDCOM要件にも余剰です。
Overall, COPS, defined in RFC 2748 [25], and COPS-PR, defined in RFC 3084 [26], have similar compliancy with regards to the MIDCOM protocol requirements. In this document, references to COPS are generally applicable to both COPS and COPS-PR. However, COPS-PR is explicitly identified to meet two of the requirements. The only other major difference between COPS-PR and COPS, as applied to the MIDCOM protocol, would be the description of the MIDCOM policy rule attributes with COPS-PR MIDCOM PIB attributes rather than COPS MIDCOM client specific objects.
全体として、RFC 2748 [25]で定義されているCOPS、およびRFC 3084 [26]で定義されているCOPS-PRは、MIDCOMプロトコル要件に関して同様の準拠を持っています。このドキュメントでは、COPへの参照は一般にCOPSとCOPS-PRの両方に適用されます。ただし、COPS-PRは、2つの要件を満たすために明示的に特定されています。MIDCOMプロトコルに適用されるCOPS-PRとCOPSの唯一の大きな違いは、COPS Midcomクライアント固有のオブジェクトではなく、COPS-PR MIDCOM PIB属性を持つMIDCOMポリシールール属性の説明です。
COPS is a simple query and response protocol that can be used to exchange policy information between a policy server (Policy Decision Point or PDP) and its clients (Policy Enforcement Points or PEPs). COPS was defined to be a simple and extensible protocol. The main characteristics of COPS include the following:
COPSは、ポリシーサーバー（ポリシー決定ポイントまたはPDP）とそのクライアント（ポリシー執行ポイントまたはPEP）の間のポリシー情報を交換するために使用できる簡単なクエリおよび応答プロトコルです。COPSは、シンプルで拡張可能なプロトコルであると定義されました。警官の主な特徴には、次のものが含まれます。
1. The protocol employs a client/server model. The PEP sends requests, updates, and deletions to the remote PDP and the PDP returns decisions back to the PEP.
1. プロトコルは、クライアント/サーバーモデルを採用しています。PEPはリクエスト、更新、削除をリモートPDPに送信し、PDPは決定をPEPに戻します。
2. The protocol uses TCP as its transport protocol for reliable exchange of messages between policy clients and a server.
2. プロトコルは、ポリシークライアントとサーバー間のメッセージの信頼できる交換のために、TCPをトランスポートプロトコルとして使用します。
3. The protocol is extensible in that it is designed to leverage self-identifying objects and can support diverse client specific information without requiring modification of the COPS protocol.
3. プロトコルは、自己識別オブジェクトを活用するように設計されており、COPSプロトコルの変更を必要とせずに多様なクライアント固有の情報をサポートできるという点で拡張可能です。
4. The protocol was created for the general administration, configuration, and enforcement of policies.
4. このプロトコルは、一般的な管理、構成、およびポリシーの実施のために作成されました。
5. COPS provides message level security for authentication, replay protection, and message integrity. COPS can make use of existing protocols for security such as IPSEC [22] or TLS [21] to authenticate and secure the channel between the PEP and the PDP.
5. COPSは、認証、リプレイ保護、メッセージの整合性のためのメッセージレベルのセキュリティを提供します。COPは、IPSEC [22]やTLS [21]などのセキュリティのために既存のプロトコルを使用して、PEPとPDPの間のチャネルを認証および保護できます。
6. The protocol is stateful in two main aspects:
6. このプロトコルは、2つの主な側面においてステートフルです。
(1) Request/Decision state is shared and kept synchronized in a transactional manner between client and server. Requests from the client PEP are installed or remembered by the remote PDP until they are explicitly deleted by the PEP. At the same time, Decisions from the remote PDP can be generated asynchronously at any time for a currently installed request state.
(1) リクエスト/決定状態は共有され、クライアントとサーバーの間のトランザクション的な方法で同期し続けます。クライアントPEPからのリクエストは、PEPによって明示的に削除されるまで、リモートPDPによってインストールまたは記憶されます。同時に、リモートPDPからの決定は、現在インストールされている要求状態について、いつでも非同期に生成できます。
(2) State from various events (Request/Decision pairs) may be inter-associated. The server may respond to new queries differently because of previously installed, related Request/Decision state(s).
(2) さまざまなイベント（リクエスト/決定ペア）からの状態は、相互に関連する場合があります。サーバーは、以前にインストールされた関連するリクエスト/決定状態により、新しいクエリに異なる方法で応答する場合があります。
7. The protocol is also stateful in that it allows the server to push configuration information to the client, and then allows the server to remove such state from the client when it is no longer applicable.
7. また、このプロトコルは、サーバーが構成情報をクライアントにプッシュできるようにし、サーバーが適用されなくなったときにクライアントからそのような状態を削除できるようにするという点でステートフルです。
In the MIDCOM framework, the Middlebox enforces the policy controlled by an application-aware Agent. Thus, when compared to the COPS architecture, the Middlebox serves as the PEP (COPS Client) and the MIDCOM Agent serves as the PDP (COPS Policy Server). One major difference between the COPS protocol model and the MIDCOM protocol requirements is that MIDCOM requires that the MIDCOM Agent establish the session. Whereas, the COPS definition is that a PEP (Middlebox) establishes communication with a PDP (MIDCOM Agent).
MIDCOMフレームワークでは、MiddleBoxはアプリケーション認識エージェントによって制御されるポリシーを実施します。したがって、COPSアーキテクチャと比較すると、ミドルボックスはPEP（COPSクライアント）として機能し、MIDCOMエージェントはPDP（COPSポリシーサーバー）として機能します。COPSプロトコルモデルとMIDCOMプロトコル要件の1つの大きな違いは、MIDCOMがMIDCOMエージェントがセッションを確立することを要求することです。一方、COPSの定義は、PEP（Middlebox）がPDP（MIDCOMエージェント）との通信を確立することです。
This section contains a review of the protocol's level of compliance to each of the MIDCOM Requirements [1]. The following key will be used to identify the level of compliancy of each of the individual protocols:
このセクションには、MIDCOM要件のそれぞれに対するプロトコルのコンプライアンスレベルのレビューが含まれています[1]。次のキーを使用して、個々のプロトコルのそれぞれの準拠のレベルを特定します。
T = Total Compliance. Meets the requirement fully.
T =総コンプライアンス。要件を完全に満たします。
P+ = Partial Compliance+. Fundamentally meets the requirement through the use of extensions (e.g., packages, additional parameters, etc).
P =部分コンプライアンス。拡張機能（パッケージ、追加のパラメーターなど）を使用して、基本的に要件を満たしています。
P = Partial Compliance. Meets some aspect of the requirement, however, the necessary changes require more than an extension and/or are inconsistent with the design intent of the protocol.
P =部分コンプライアンス。要件のいくつかの側面を満たしていますが、必要な変更には拡張機能以上のものが必要であり、および/またはプロトコルの設計意図と矛盾しています。
F = Failed Compliance. Does not meet the requirement.
F =コンプライアンスの失敗。要件を満たしていません。
This section describes the compliancy of the proposed protocols against the protocol machinery requirements from section 2.1 of the requirements document [1]. A short description of each of the protocols is provided to substantiate the evaluation.
このセクションでは、要件文書[1]のセクション2.1からのプロトコル機械要件に対する提案されたプロトコルの準拠について説明します。評価を実証するために、各プロトコルの簡単な説明が提供されます。
2.1.1. Ability to Establish Association Between Agent and Middlebox.
2.1.1. エージェントとミドルボックス間の関連を確立する能力。
SNMP: T, RSIP: P+, Megaco: P, Diameter: T, COPS: P
SNMP: SNMPv3 provides mutual authentication at the user level (where the user can be an application or a host if desired) via shared secrets. Each authenticated principal is associated with a group that has access rights that control the principals ability to perform operations on specific subsets of data. Failure to authenticate can generate a SNMP notification (administrator configurable choice).
SNMP：SNMPV3は、共有秘密を介してユーザーレベル（ユーザーがアプリケーションまたはホストになることができる）で相互認証を提供します。認証された各プリンシパルは、データの特定のサブセットで操作を実行するプリンシパル能力を制御するアクセス権を持つグループに関連付けられています。認証に失敗すると、SNMP通知（管理者設定可能な選択）が生成されます。
RSIP: RSIP allows sessions to be established between middleboxes and applications and MIDCOM agents. Authorization credentials would have to be added to the session establishment request to allow the middlebox to authorize the session requestor.
RSIP：RSIPでは、ミドルボックスとアプリケーションとMIDCOMエージェントの間でセッションを確立できます。MiddleBoxがセッション要求者を承認できるようにするために、認証資格情報をセッション確立リクエストに追加する必要があります。
Megaco: There is a directionality component implicit in this requirement in that the MA initiates the establishment of the authorized session. Megaco defines this association to be established in the opposite direction, i.e., the Middlebox(MG) initiates the establishment. If this restriction is not considered, then Megaco makes the syntax and semantics available for the endpoint to initiate the connection.
MEGACO：MAが承認されたセッションの確立を開始するという点で、この要件に暗黙の方向性コンポーネントがあります。Megacoは、この関連付けを反対方向に確立すると定義しています。つまり、Middlebox（MG）が施設を開始します。この制限が考慮されない場合、Megacoはエンドポイントが接続を開始するために構文とセマンティクスを利用できるようにします。
Diameter: Although this is out of scope, the Diameter specification describes several ways to discover a peer. Having done so, a Diameter node establishes a transport connection (TCP, TLS, or SCTP) to the peer. The two peers then exchange Capability Exchange Request/Answer messages to identify each other and determine the Diameter applications each supports.
直径：これは範囲外ですが、直径の仕様には、ピアを発見するいくつかの方法が説明されています。そうすることで、直径ノードは、ピアに輸送接続（TCP、TLS、またはSCTP）を確立します。2人のピアは、互いを識別し、それぞれサポートする直径アプリケーションを決定するために、機能交換リクエスト/応答メッセージを交換します。
If the connection between two peers is lost, Diameter prescribes procedures whereby it may be re-established. To ensure that loss of connectivity is detected quickly, Diameter provides the Device-Watchdog Request/Answer messages, to be used when traffic between the two peers is low.
2つのピア間の接続が失われた場合、直径は再確立される可能性のある手順を処方します。接続の損失が迅速に検出されるようにするために、2つのピア間のトラフィックが低い場合に使用するために、直径がデバイスウォッチドッグリクエスト/回答メッセージを提供します。
Diameter provides an extensive state machine to govern the relationship between two peers.
直径は、2人のピア間の関係を管理するための広範な状態マシンを提供します。
COPS: COPS does not meet the directionality part of the requirement. The definition of COPS allows a PEP (Middlebox) to establish communication with a PDP (MIDCOM Agent). However, nothing explicitly prohibits a PDP from establishing communication with a PEP. The PEP could have local policies dictating what action to take when it is contacted by an unknown PDP. These actions, defined in the local policies, would ensure the proper establishment of an authorized association.
警官：警官は要件の方向性の部分を満たしていません。COPSの定義により、PEP（Middlebox）がPDP（Midcomエージェント）とのコミュニケーションを確立することができます。ただし、PDPがPEPとのコミュニケーションを確立することを明示的に禁止するものはありません。PEPは、未知のPDPから連絡されたときにどのような行動をとるべきかを指示するローカルポリシーを持つことができます。ローカルポリシーで定義されているこれらのアクションは、認可された協会の適切な確立を保証します。
SNMP: T, RSIP: P, Megaco: T, Diameter: T, COPS: T
SNMP: An SNMP manager can communicate simultaneously with several Middleboxes.
SNMP：SNMPマネージャーは、いくつかのミドルボックスと同時に通信できます。
RSIP: RSIP sessions are identified by their IP source and destination addresses and their TCP / UDP port numbers. Thus each RSIP client can communicate with multiple servers, and each server can communicate with multiple clients. However, RSIP did not explicitly include agents in its design. The architecture and semantics of RSIP messages do not preclude agents, thus the RSIP architecture could certainly be extended to explicitly include agents; therefore RSIP is deemed partially compliant to this requirement.
RSIP：RSIPセッションは、IPソースと宛先アドレス、およびTCP / UDPポート番号によって識別されます。したがって、各RSIPクライアントは複数のサーバーと通信でき、各サーバーは複数のクライアントと通信できます。ただし、RSIPはその設計にエージェントを明示的に含めませんでした。RSIPメッセージのアーキテクチャとセマンティクスはエージェントを排除するものではないため、RSIPアーキテクチャを確実に拡張して、エージェントを明示的に含めることができます。したがって、RSIPはこの要件に部分的に準拠していると見なされます。
Megaco: Megaco allows an MA to control several Middleboxes. Each message carries an identifier of the endpoint that transmitted the message allowing the recipient to determine the source.
Megaco：Megacoは、MAがいくつかのミドルボックスを制御できるようにします。各メッセージには、受信者がソースを決定できるようにするメッセージを送信するエンドポイントの識別子が搭載されています。
Diameter: Diameter allows connection to more than one peer (and encourages this for improved reliability). Whether the Diameter connection state machine is too heavy to support the number of connections needed is a matter for discussion.
直径：直径により、複数のピアへの接続が可能になります（そして、信頼性を向上させるためにこれを促進します）。直径接続の状態マシンが必要な接続の数をサポートできないかどうかは、議論の問題です。
COPS: COPS PDPs are designed to communicate with several PEPs.
警官：COPS PDPは、いくつかのPEPと通信するように設計されています。
SNMP: T, RSIP: P, Megaco: T, Diameter: T, COPS: T
SNMP: An SNMP agent can communicate with several SNMP managers Simultaneously.
SNMP：SNMPエージェントは、複数のSNMPマネージャーと同時に通信できます。
RSIP: Refer to 2.1.2.
RSIP：2.1.2を参照してください。
Megaco: Megaco has the concept of Virtual Media Gateways (VMG), allowing multiple MGCs to communicate simultaneously with the same MG. Applying this model to MIDCOM would allow the same middlebox (MG) to have associations with multiple MIDCOM Agents (MGCs).
Megaco：Megacoには、仮想メディアゲートウェイ（VMG）の概念があり、複数のMGCが同じMGと同時に通信できるようにします。このモデルをMidcomに適用すると、同じミドルボックス（MG）が複数のMIDCOMエージェント（MGC）との関連を持つことができます。
Diameter: Diameter allows connection to more than one peer and encourages this for improved reliability. Whether the Diameter connection state machine is too heavy to support the number of connections needed is a matter for discussion. The Middlebox and Agent play symmetric roles as far as Diameter peering is concerned.
直径：直径は複数のピアへの接続を可能にし、信頼性を向上させるためにこれを促進します。直径接続の状態マシンが必要な接続の数をサポートできないかどうかは、議論の問題です。ミドルボックスとエージェントは、直径のピアリングに関する限り、対称的な役割を果たしています。
COPS: The COPS-PR framework specifies that a PEP should have a unique PDP in order to achieve effective policy control. The COPS-PR protocol would allow the scenario whereby a PEP establishes communication with multiple PDPs by creating a COPS client instance per PDP.
COPS：COPS-PRフレームワークは、効果的な政策管理を実現するために、PEPに一意のPDPが必要であることを指定しています。COPS-PRプロトコルは、PEPがPDPごとにCOPSクライアントインスタンスを作成することにより、複数のPDPとの通信を確立するシナリオを許可します。
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: While the architectural design of SNMP can permit race conditions to occur, there are mechanisms defined as part of the SNMPv3 standard, such as view-based access control and advisory locking that can be used to prevent the conditions, and MIB modules may also contain special functionality, such as RMONs OwnerString, to prevent conflicts. Deterministic behavior of SNMP agents when being accessed by multiple managers is important for several management applications and supported by SNMP.
SNMP：SNMPの建築設計により、人種条件が発生する可能性がありますが、条件を防ぐために使用できるビューベースのアクセス制御やアドバイザリーロックなど、SNMPV3標準の一部として定義されたメカニズムがあり、MIBモジュールもまた競合を防ぐために、RMONS OwnerStringなどの特別な機能が含まれています。複数のマネージャーがアクセスする場合のSNMPエージェントの決定論的動作は、いくつかの管理アプリケーションにとって重要であり、SNMPによってサポートされています。
RSIP: All RSIP requests are defined to be atomic. Near simultaneous requests are executed as is they were sequential.
RSIP：すべてのRSIP要求は、アトミックであると定義されています。順番であったように、同時リクエストが実行されます。
Megaco: Megaco supports the concept of VMGs to make these interactions deterministic and to avoid resource access conflicts. Each VMG has a single owner, in a MGC, and there can be no overlap between the sets of Terminations belonging to multiple VMGs. The Megaco protocol messages also include the identifier of the sending entity, so that the MG can easily determine to whom to send the response or asynchronously report certain events.
Megaco：Megacoは、VMGの概念をサポートして、これらの相互作用を決定的にし、リソースアクセスの競合を回避します。各VMGにはMGCに1人の所有者がいて、複数のVMGに属する終端のセット間にオーバーラップはありません。Megacoプロトコルメッセージには、送信エンティティの識別子も含まれているため、MGは誰に応答を送信するかを簡単に判断したり、特定のイベントを非同期に報告したりできます。
Diameter: Diameter depends partly upon the transport protocol to provide flow control when the server becomes heavily loaded. It also has application-layer messaging to indicate that it is too busy or out of space (Diameter_TOO_BUSY and Diameter_OUT_OF_SPACE result codes).
直径：直径は、サーバーが大幅にロードされるとフロー制御を提供するために、トランスポートプロトコルに部分的に依存します。また、アプリケーションレイヤーメッセージングがあり、忙しすぎたりスペースが外れたりしていることを示します（diameter_too_busy and diameter_out_of_space resultコード）。
COPS: COPS has built-in support for clear state and policy instances. This would allow the creation of well-behaved MIDCOM state machines.
警官：Copsには、明確な状態および政策インスタンスのサポートが組み込まれています。これにより、行儀の良いMidcom状態マシンの作成が可能になります。
SNMP: T, RSIP: T, Megaco: T, Diameter: P, COPS: T
SNMP: Requests are atomic in SNMP. MIB modules can define which data is persistent across reboots, so a known startup state can be established. The manager can poll the agent to determine the current state.
SNMP：リクエストはSNMPでアトミックです。MIBモジュールは、再起動全体でどのデータが永続的であるかを定義できるため、既知のスタートアップ状態を確立できます。マネージャーは、エージェントを投票して現在の状態を決定できます。
RSIP: RSIP assumes that on middlebox start-up no sessions are defined, and thus no allocations have been made. In effect, all resources are released upon restart after failure.
RSIP：RSIPは、ミドルボックスの起動ではセッションが定義されていないため、割り当てが行われていないと想定しています。実際、すべてのリソースは、障害後に再起動時にリリースされます。
Megaco: Megaco has extensive audit capabilities to synchronize states between the MG and the MGC. Megaco also provides the MGC with the ability to do mass resets, as well as individual resets. The MGC can always release resources in the MG. The MG can also initiate the release of resources by the MGC.
Megaco：Megacoには、MGとMGCの間で状態を同期させるための広範な監査機能があります。Megacoは、MGCにマスリセットを実行する機能と個別のリセットも提供します。MGCは常にMGでリソースをリリースできます。MGは、MGCによるリソースのリリースを開始することもできます。
Diameter: Diameter documentation does not discuss the degree of atomicity of message processing, so this would have to be specified in the MIDCOM extension.
直径：直径のドキュメントでは、メッセージ処理の原子性の程度については説明していないため、これはMIDCOM拡張機能で指定する必要があります。
COPS: The COPS protocol maintains synchronized states between Middleboxes and MA hence all the states are known on both sides.
COPS：COPSプロトコルは、ミドルボックスとMAの間で同期された状態を維持しているため、すべての状態は両側で知られています。
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: The status of a middlebox can be reported using asynchronous communications, or via polling.
SNMP：ミドルボックスのステータスは、非同期通信を使用して、またはポーリングを使用して報告できます。
RSIP: All RSIP client requests have explicit server responses. Additionally, a client may explicitly request server status using a QUERY request.
RSIP：すべてのRSIPクライアント要求には、明示的なサーバー応答があります。さらに、クライアントはクエリリクエストを使用してサーバーステータスを明示的に要求する場合があります。
Megaco: Megaco has extensive audit capabilities for the MG to report status information to the MGC. It can also report some status updates using the ServiceChange command.
Megaco：Megacoには、MGがMGCにステータス情報を報告するための広範な監査機能があります。また、ServiceChangeコマンドを使用していくつかのステータス更新を報告することもできます。
Diameter: Diameter provides a number of response codes by means of which a server can indicate error conditions reflecting status of the server as a whole. The Disconnect-Peer-Request provides a means in the extreme case to terminate a connection with a peer gracefully, informing the other end about the reason for the disconnection.
直径：直径は、サーバー全体のステータスを反映するエラー条件をサーバーに示すことができる多くの応答コードを提供します。切断パイアレクエストは、極端なケースでピアとの接続を優雅に終了するための手段を提供し、切断の理由を反対側に通知します。
COPS: The COPS Report message is designed to indicate any asynchronous conditions/events.
COPS：COPSレポートメッセージは、非同期条件/イベントを示すように設計されています。
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: SNMPv3 supports both confirmed and unconfirmed asynchronous notifications.
SNMP：SNMPV3は、確認された非同期通知と未確認の両方の通知をサポートしています。
RSIP: An RSIP server will send an unsolicited DE_REGISTER_RESPONSE to force an RSIP host to relinquish all of its bindings and terminate its relationship with the RSIP gateway. An RSIP server can send an asynchronous ERROR_RESPONSE to indicate less severe conditions.
RSIP：RSIPサーバーは、承認されていないDE_REGISTER_RESPONSEを送信して、RSIPホストにすべてのバインディングを放棄し、RSIPゲートウェイとの関係を終了させます。RSIPサーバーは、非同期error_responseを送信して、それほど深刻ではない条件を示すことができます。
Megaco: Megaco supports the asynchronous notification of events using the Notify command.
Megaco：Megacoは、Notifyコマンドを使用したイベントの非同期通知をサポートしています。
Diameter: The Diameter protocol permits either peer in a connection to originate transactions. Thus the protocol supports Middlebox-originated messages.
直径：直径プロトコルは、トランザクションの発生に関連してピアを許可します。したがって、プロトコルはミドルボックスに由来するメッセージをサポートします。
COPS: The COPS Report message is designed to indicate any asynchronous conditions/events.
COPS：COPSレポートメッセージは、非同期条件/イベントを示すように設計されています。
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: SNMPv3 meets this requirement. SNMPv3 supports user authentication and explicitly supports symmetric secret key encryption between MIDCOM agent (SNMP manager) and Middlebox (SNMP agent), thus supporting mutual authentication. The default authentication and encryption methods are specified in RFC 3414 [11] (MD5, SHA-1, and DES). Different users at the same management application (MIDCOM agent) can authenticate themselves with different authentication and encryption methods, and additional methods can be added to SNMPv3 entities as needed.
SNMP：SNMPV3はこの要件を満たしています。SNMPV3はユーザー認証をサポートし、Midcomエージェント（SNMPマネージャー）とMiddlebox（SNMPエージェント）の間の対称シークレットキー暗号化を明示的にサポートし、相互認証をサポートします。デフォルトの認証と暗号化方法は、RFC 3414 [11]（MD5、SHA-1、およびDES）で指定されています。同じ管理アプリケーション（MIDCOMエージェント）の異なるユーザーは、異なる認証と暗号化方法で自分自身を認証でき、必要に応じてSNMPV3エンティティに追加の方法を追加できます。
RSIP: This requirement can be met by operating RSIP over IPSec as described in RFC 3104 [19]. The RSIP framework recommends all communication between an RSIP host and gateway be authenticated. Authentication, in the form of a message hash appended to the end of each RSIP protocol packet, can serve to authenticate the RSIP host and gateway to one another, provide message integrity, and avoid replay attacks with an anti-replay counter. However, the message hash and replay counter parameters would need to be defined for the RSIP protocol.
RSIP：この要件は、RFC 3104 [19]で説明されているように、IPSECを介してRSIPを操作することで満たすことができます。RSIPフレームワークでは、RSIPホストとゲートウェイ間のすべての通信を認証することを推奨しています。認証は、各RSIPプロトコルパケットの最後に追加されたメッセージの形式で、RSIPホストとゲートウェイを互いに認証し、メッセージの整合性を提供し、アンチレプレイカウンターで再生攻撃を回避するのに役立ちます。ただし、RSIPプロトコルでは、メッセージハッシュとリプレイカウンターパラメーターを定義する必要があります。
Megaco: Megaco provides for the use of IPSec [22] for all security mechanisms including mutual authentication, integrity check and encryption. Use of IKE is recommended with support of RSA signatures and public key encryption.
Megaco：Megacoは、相互認証、整合性チェック、暗号化など、すべてのセキュリティメカニズムにIPSEC [22]を使用することを規定しています。IKEの使用は、RSA署名と公開キー暗号化のサポートを受けて推奨されます。
Diameter: The Diameter base protocol assumes that messages are secured by using either IPSec or TLS [21]. Diameter requires that when using the latter, peers must mutually authenticate themselves.
直径：直径ベースプロトコルは、IPSECまたはTLSのいずれかを使用してメッセージが保護されることを想定しています[21]。直径には、後者を使用する場合、ピアは相互に認証する必要があります。
COPS: COPS has built-in message level security for authentication, replay protection, and message integrity. COPS can also use TLS or IPSec.
警官：Copsには、認証、リプレイ保護、メッセージの整合性のためのメッセージレベルのセキュリティが組み込まれています。COPSはTLSまたはIPSECを使用することもできます。
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: Each SNMPv3 message is authenticated and authorized, so each message could be considered to have its own session, which automatically terminates after processing. Processing may be stopped for a number of reasons, such as security, and a response is sent.
SNMP：各snmpv3メッセージは認証され、承認されているため、各メッセージは独自のセッションがあると見なされる可能性があり、処理後に自動的に終了します。セキュリティなど、いくつかの理由で処理が停止される場合があり、応答が送信されます。
Either peer may stop operating, and be unavailable for further operations. The authentication and/or authorization parameters of a principal may be changed between operations if desired, to prevent further authentication or authorization for security reasons.
どちらのピアも運営を停止し、さらなる操作には利用できない場合があります。セキュリティ上の理由でさらなる認証または承認を防ぐために、元プリンシパルの認証および/または認証パラメーターを操作間で変更することができます。
Additionally, managed objects can be defined for realizing sessions that persist beyond processing of a single message. The MIB module would need to specify the responsibility for cleanup of the objects following normal/abnormal termination.
さらに、管理されたオブジェクトは、単一のメッセージの処理を超えて持続するセッションを実現するために定義できます。MIBモジュールは、正常/異常な終了後のオブジェクトのクリーンアップの責任を指定する必要があります。
RSIP: An RSIP client may terminate a session with a DE_REGISTER_REQUEST. An RSIP server may terminate a session with an unsolicited DE_REGISTER_RESPONSE, and then respond to subsequent requests on the session with a REGISTER_FIRST error.
RSIP：RSIPクライアントは、de_register_requestでセッションを終了する場合があります。RSIPサーバーは、未承諾のDE_REGISTER_RESPONSEでセッションを終了し、レジスタ_FIRSTエラーでセッションの後続のリクエストに応答する場合があります。
Megaco: The Megaco protocol allows both peers to terminate the association with proper reason code.
Megaco：Megacoプロトコルにより、両方のピアが適切な理由コードとの関連を終了できます。
Diameter: Either peer in a connection may issue a Disconnect-Peer-Request to end the connection gracefully.
直径：接続中のピアは、接続を優雅に終了するために切断されたピアリクエストを発行する場合があります。
COPS: COPS allows both the PEP and PDP to terminate a session.
警官：警官は、PEPとPDPの両方がセッションを終了することを許可します。
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: Each operation request has a corresponding response message that contains an error status to indicate success or failure. For complex requests that the middlebox cannot complete immediately, the corresponding MIB module may be designed to also provide asynchronous notifications of the success or failure of the complete transaction, and/or may provide pollable objects that indicate the success or failure of the complete transaction. For example, see ifAdminStatus and ifOperStatus in RFC 2863 [28].
SNMP：各操作要求には、成功または失敗を示すエラーステータスを含む対応する応答メッセージがあります。ミドルボックスがすぐに完了できないという複雑な要求の場合、対応するMIBモジュールは、完全なトランザクションの成功または失敗の非同期通知を提供するように設計されている場合があります。たとえば、RFC 2863 [28]のifadmintatusおよびifoperstatusを参照してください。
RSIP: All RSIP requests result in a paired RSIP response if the request was successful or an ERROR_RESPONSE if the request was not successful.
RSIP：すべてのRSIP要求により、リクエストが成功した場合はペアのRSIP応答が発生します。
Megaco: Megaco defines a special descriptor called an Error descriptor that contains the error code and an optional explanatory string.
Megaco：Megacoは、エラーコードとオプションの説明文字列を含むエラー記述子と呼ばれる特別な記述子を定義します。
Diameter: Every Diameter request is matched by a response, and this response contains a result code as well as other information.
直径：すべての直径要求は応答と一致し、この応答には結果コードとその他の情報が含まれています。
COPS: The COPS Report message directly fulfills this requirement.
警官：COPSレポートメッセージはこの要件を直接満たします。
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: SNMP has a separation of the protocol to carry data, and the data that defines additional management functionality. Additional functionality can be added easily through MIBs. Capability exchange in SNMP is usually uni-directional. Managers can query the middlebox (SNMP agent) to determine which MIBs are supported. In addition, multiple message versions can be supported simultaneously, and are identified by a version number in the message header.
SNMP：SNMPには、データを伝達するプロトコルの分離と、追加の管理機能を定義するデータがあります。MIBSを介して追加の機能を簡単に追加できます。SNMPの機能交換は通常、一方向です。マネージャーは、ミドルボックス（SNMPエージェント）を照会して、どのMIBがサポートされているかを判断できます。さらに、複数のメッセージバージョンを同時にサポートでき、メッセージヘッダーのバージョン番号によって識別されます。
RSIP: Each RSIP message contains a version parameter.
RSIP：各RSIPメッセージにはバージョンパラメーターが含まれています。
Megaco: Version interworking and negotiation are supported both for the protocol and any extension Packages.
Megaco：バージョンのインターワーキングとネゴシエーションは、プロトコルと任意の拡張パッケージの両方でサポートされています。
Diameter: The Capabilities Exchange Request/Answer allows two peers to determine information about what each supports, including protocol version and specific applications.
直径：機能交換リクエスト/回答により、2人のピアがプロトコルバージョンや特定のアプリケーションを含む各サポートに関する情報を決定できます。
COPS: The COPS protocol can carry a MIDCOM version number and capability negotiation between the COPS client and the COPS server. This capability negotiation mechanism allows the COPS client and server to communicate the supported features/capabilities. This would allow seamless version interworking.
COPS：COPSプロトコルは、COPSクライアントとCOPSサーバーの間のMIDCOMバージョン番号と能力交渉を担当できます。この機能交渉メカニズムにより、COPSクライアントとサーバーはサポートされている機能/機能を通信できます。これにより、シームレスなバージョンのインターワーキングが可能になります。
SNMP: T, RSIP: T, Megaco: P, Diameter: T, COPS: T
SNMP: Rulesets would be defined in MIBs. The priority of rulesets, and the resolution of conflict, can be defined in the MIB module definition. The SNMPConf policy MIB defines mechanisms to achieve deterministic behavior in the presence of overlapping rule sets.
SNMP：ルールセットはMIBSで定義されます。ルールセットの優先順位、および競合の解決は、MIBモジュール定義で定義できます。SNMPCONFポリシーMIBは、重複するルールセットの存在下で決定論的な動作を達成するメカニズムを定義します。
RSIP: All requests for allocation of IP addresses, or ports or both resulting in rule overlap are rejected by an RSIP server with a LOCAL_ADDR_INUSE error.
RSIP：IPアドレスの割り当て、またはポートのすべてのリクエスト、またはその両方がルールオーバーラップをもたらします。Local_Addr_inuseエラーを備えたRSIPサーバーによって拒否されます。
Megaco: This is met with the help of a model that separates Megaco protocol elements from the overlapping Policy rules (see Appendix C). However, new behavior for the Megaco protocol elements needs to be specified as part of a new MIDCOM specific Package.
Megaco：これは、メガコプロトコル要素を重複するポリシールールから分離するモデルの助けを借りて満たされています（付録Cを参照）。ただし、メガコプロトコル要素の新しい動作は、新しいMIDCOM固有のパッケージの一部として指定する必要があります。
Diameter: The IPFilterRule type specification, which would probably be used as the type of a Policy Rule AVP, comes with an extensive semantic description providing a deterministic outcome, which the individual Agent cannot know unless it knows all of the Policy Rules installed on the Middlebox. Rules for the appropriate direction are evaluated in order, with the first matched rule terminating the evaluation. Each packet is evaluated once. If no rule matches, the packet is dropped if the last rule evaluated was a permit, and passed if the last rule was a deny. The IPFilterRule format and further details on its applicability to this requirement are provided in Appendix D.
直径：おそらくポリシールールAVPのタイプとして使用されるIPFilterruleタイプの仕様には、決定論的な結果を提供する広範なセマンティック説明が付属しています。。適切な方向のルールは順番に評価され、最初の一致したルールが評価を終了します。各パケットは一度評価されます。ルールが一致しない場合、評価された最後のルールが許可である場合、パケットが削除され、最後のルールが拒否された場合に合格します。IPFilterrule形式と、この要件への適用性に関する詳細については、付録Dに記載されています。
COPS: The COPS protocol provides transactional-based communication between the PEP and PDP, hence the behavior is totally deterministic provided the middlebox state machine is designed correctly. The COPS protocol features encourage and support good state machine design.
COPS：COPSプロトコルは、PEPとPDP間のトランザクションベースの通信を提供するため、Middlebox Stateマシンが正しく設計されている場合、動作は完全に決定的です。COPSプロトコルは、優れたステートマシンの設計を奨励およびサポートしています。
This section contains the individual protocols as evaluated against the protocol semantic requirements from section 2.2 of the requirements document [1]. A short description of each of the protocols is provided to substantiate the evaluation.
このセクションには、要件文書[1]のセクション2.2からのプロトコルセマンティック要件に対して評価された個々のプロトコルが含まれています。評価を実証するために、各プロトコルの簡単な説明が提供されます。
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: Extensibility is a basic feature of the SNMP management Framework.
SNMP：拡張性は、SNMP管理フレームワークの基本的な機能です。
RSIP: All RSIP messages consist of three mandatory fields (protocol version, message type, and message length) and a sequence of parameterType / length / value 3-tuples. New messages may be defined by defining new values for the message type field. New parameter types may be defined, and existing messages may be extended, by defining new parameterType values. If new messages, parameters, or both are added in a non-backward compatible way, a new value of the protocol version field may be defined. This may be desirable even of the additions are backward compatible.
RSIP：すべてのRSIPメッセージは、3つの必須フィールド（プロトコルバージョン、メッセージタイプ、およびメッセージの長さ）と、パラメータ型 /長さ /値3タプルのシーケンスで構成されています。新しいメッセージは、メッセージタイプフィールドの新しい値を定義することで定義できます。新しいパラメータータイプが定義され、新しいパラメータ型値を定義することにより、既存のメッセージが拡張される場合があります。新しいメッセージ、パラメーター、またはその両方が非バックワード互換性のある方法で追加された場合、プロトコルバージョンフィールドの新しい値が定義される場合があります。これは、追加が後方互換性がある場合でも望ましい場合があります。
Megaco: Megaco is easily extensible through new Packages, which allow definition of new attributes and behavior of a Termination.
Megaco：Megacoは、新しい属性の定義と終了の動作を可能にする新しいパッケージを通じて簡単に拡張できます。
Diameter: Diameter provides a great deal of flexibility for extensions, including allowance for vendor-defined commands and AVPs and the ability to flag each AVP as must-understand or ignorable if not understood.
直径：直径は、ベンダー定義のコマンドやAVPの手当や、理解されていない場合は必須または無知として各AVPにフラグを立てる機能など、拡張機能に多大な柔軟性を提供します。
COPS: The COPS protocol is extensible, since it was designed to separate the Protocol from the Policy Control Information.
COPS：COPSプロトコルは、プロトコルをポリシー制御情報から分離するように設計されているため、拡張可能です。
SNMP: T, RSIP: P+, Megaco: T, Diameter: P+, COPS: T
SNMP: SNMP explicitly supports managing different device types with different capabilities. First the managed object called sysObjectID from basic MIB-II [3] identifies the type of box. For boxes with variable capabilities, SNMP can check the availability of corresponding MIBs.
SNMP：SNMPは、さまざまな機能を備えたさまざまなデバイスタイプの管理を明示的にサポートしています。最初に、Basic MIB-II [3]からSysobjectIDと呼ばれる管理されたオブジェクトは、ボックスのタイプを識別します。可変機能を備えたボックスの場合、SNMPは対応するMIBの可用性を確認できます。
RSIP: All types of middleboxes are supported so long as the ruleset action is permit. Other actions would require the definition of a new RSIP message parameter with values for permit and the other desired actions.
RSIP：ルールセットのアクションが許可されている限り、あらゆる種類のミドルボックスがサポートされています。他のアクションには、許可の値と他の目的のアクションを持つ新しいRSIPメッセージパラメーターの定義が必要です。
Megaco: Megaco can support multiple Middlebox types on the same interface either by designing the properties representing the Policy Rules to provide this support, or by using multiple terminations in the same session, each representing one type of action. In the latter case, the Megaco Context can be used as a convenient means of managing the related terminations as a group. However, the inherent idea of flow between terminations of a context is irrelevant and would have to be discarded.
Megaco：Megacoは、このサポートを提供するポリシールールを表すプロパティを設計するか、同じセッションで複数の終端を使用して、それぞれが1つのタイプのアクションを表すことにより、同じインターフェイス上の複数のミドルボックスタイプをサポートできます。後者の場合、メガコのコンテキストは、関連する終端をグループとして管理する便利な手段として使用できます。ただし、コンテキストの終端間の流れの固有のアイデアは無関係であり、破棄する必要があります。
Diameter: Any necessary additional AVPs or values must be specified as part of the MIDCOM application extension (see <2.2.8> below).
直径：必要な追加のAVPまたは値は、MIDCOMアプリケーション拡張の一部として指定する必要があります（以下の<2.2.8>を参照）。
COPS: COPS allows a PDP to provide filters and actions to multiple PEP functions through a single COPS session.
COPS：COPSでは、PDPが単一のCOPSセッションを通じて複数のPEP関数にフィルターとアクションを提供することを許可します。
SNMP: T, RSIP: P+, Megaco: T, Diameter: T, COPS: T
SNMP: This requirement can be realized via the SNMP management framework by an appropriate definition of a MIB module. The SNMPConf WG has already defined an SNMP Policy MIB that permits the definitions of policy rulesets and grouping of rulesets.
SNMP：この要件は、MIBモジュールの適切な定義により、SNMP管理フレームワークを介して実現できます。SNMPCONF WGは、ポリシールールセットの定義とルールセットのグループ化を許可するSNMPポリシーMIBをすでに定義しています。
RSIP: RSIP currently only allows one IP address, or address and port range, to be assigned to a bind-ID. RSIP could implement rulesets as required by adding an optional bind-ID parameter to the ASSIGN_REQUESTs to extend an existing ruleset rather than creating a new one. Similarly, the FREE_REQUESTs would have to be extended by adding optional, local and remote, address and port parameters.
RSIP：RSIPでは、現在、1つのIPアドレス、またはアドレスとポートの範囲をBind-IDに割り当てることができます。RSIPは、新しいルールセットを作成するのではなく、既存のルールセットを拡張するために、Optional Bind-IDパラメーターをAssight_Requestsに追加することにより、必要に応じてルールセットを実装できます。同様に、オプション、ローカル、リモート、アドレス、ポートパラメーターを追加して、free_requestsを拡張する必要があります。
Megaco: The Megaco context can be used to group terminations to be managed together. For example, all of the terminations, each representing an instantiation of a Policy Rule, can be deleted in one command by doing a wildcarded Subtract from the context. However, the inherent idea of media flows between terminations of a context would be irrelevant in this application of the protocol.
Megaco：Megacoコンテキストを使用して、終了をグループ化するために一緒に管理することができます。たとえば、ポリシールールのインスタンス化を表すすべての終端は、コンテキストからワイルドカードの減算を行うことにより、1つのコマンドで削除できます。ただし、コンテキストの終了間のメディアフローの固有のアイデアは、このプロトコルのアプリケーションでは無関係です。
Diameter: Diameter allows message syntax definitions where multiple instances of the same AVP (for example, a Policy Rule AVP whose syntax and low-level semantics are defined by the IPFilterRule type definition) may be present. If a tighter grouping is required, the set of Diameter base types includes the Grouped type. MIDCOM can choose how to make use of these capabilities to meet the ruleset group requirement when defining its application extension to the Diameter protocol.
直径：直径は、同じAVPの複数のインスタンス（たとえば、構文と低レベルのセマンティクスがIPFilTerruleタイプ定義によって定義されるポリシールールAVP）が存在する場合があるメッセージの構文定義を許可します。よりタイトなグループ化が必要な場合、直径ベースタイプのセットには、グループ化されたタイプが含まれます。Midcomは、適用プロトコルへのアプリケーション拡張を定義する際に、これらの機能を使用してルールセットグループの要件を満たす方法を選択できます。
COPS: The COPS-PR Handle State may be used to associate the set of closely related policy objects. As the Middlebox learns additional requirements, the Middlebox adds these resource requirements under the same handle ID, which constitutes the required aggregation.
COPS：COPS-PRハンドル状態を使用して、密接に関連するポリシーオブジェクトのセットを関連付けることができます。Middleboxが追加の要件を学習すると、MiddleBoxはこれらのリソース要件を同じハンドルIDに追加します。これは、必要な集約を構成します。
SNMP: P+, RSIP: T, Megaco: T, Diameter: T, COPS: P+
SNMP: This requirement can be realized via the SNMP management framework by an appropriate definition of a MIB module. The SNMPConf WG has developed a Policy MIB module that includes a pmPolicySchedule object with a modifiable lifetime.
SNMP：この要件は、MIBモジュールの適切な定義により、SNMP管理フレームワークを介して実現できます。SNMPCONF WGは、変更可能な寿命のPMPolicyScheduleオブジェクトを含むポリシーMIBモジュールを開発しました。
RSIP: A client may request an explicit lease time when a request is made to assign one or more IP addresses, ports or both. The server may grant the requested lease time, or assign one if none was requested. Subsequently, the lease time may be extended if a client's EXTEND_REQUEST is granted by the server.
RSIP：クライアントは、1つ以上のIPアドレス、ポート、またはその両方を割り当てるためにリクエストが行われたときに明示的なリース時間を要求する場合があります。サーバーは、要求されたリース時間を許可するか、要求されていない場合はそれを割り当てることができます。その後、クライアントのextend_requestがサーバーによって付与された場合、リース時間を延長することができます。
Megaco: The MG can report the imminent expiry of a policy rule to the MGC, which can then extend or delete the corresponding Termination.
MEGACO：MGは、ポリシールールの差し迫った有効期限をMGCに報告できます。MGCは、対応する終了を拡張または削除できます。
Diameter: The Diameter concept of a session includes the session lifetime, grace period, and lifetime extension. It may make sense to associate the Diameter session with the lifetime of a MIDCOM Policy Rule, in which case support for lifetime extension comes ready-made.
直径：セッションの直径の概念には、セッションの生涯、猶予期間、生涯延長が含まれます。直径セッションをMIDCOMポリシールールの生涯に関連付けることは理にかなっているかもしれません。
COPS: COPS allows a PDP to send unsolicited decisions to the PEP. However, the unsolicited events will be relevant to the COPS MIDCOM specific client or the MIDCOM specific PIB which needs to be defined. This would allow the PDP to extend the lifetime of an existing ruleset.
警官：警官は、PDPがPEPに未承諾の決定を送ることを許可します。ただし、未承諾イベントは、定義する必要があるCOPS Midcom固有のクライアントまたはMidcom固有のPIBに関連します。これにより、PDPは既存のルールセットの寿命を延長することができます。
SNMP: T, RSIP: T, Megaco: P+, Diameter: P+, COPS: T
SNMP: Unknown attributes in a read operation are flagged as exceptions in the Response message, but the rest of the read succeeds. In a write operation (a SET request), all attributes are validated before the write is performed. If there are unknown attributes, the request fails and no writes are done. Unknown attributes are flagged as exceptions in the Response message, and the error status is reported.
SNMP：読み取り操作の不明な属性は、応答メッセージの例外としてフラグが付けられますが、残りの読み取りは成功します。書き込み操作（セットリクエスト）では、すべての属性が実行される前に検証されます。不明な属性がある場合、要求は失敗し、書き込みは行われません。未知の属性は、応答メッセージの例外としてフラグが付けられ、エラーステータスが報告されます。
RSIP: All options of all requests are fully specified. Not understood parameters must be reported by an ERROR_RESPONSE with an EXTRA_PARM error value, with the entire request otherwise ignored.
RSIP：すべてのリクエストのすべてのオプションが完全に指定されています。理解されていないパラメーターは、extra_Parmエラー値を持つERROR_Responseによって報告する必要があり、要求全体はそれ以外の場合は無視されます。
Megaco: Megaco entities provide Error codes in response messages. If a command marked "Optional" in a transaction fails, the remaining commands will continue. However, the specified requirement deals with rules of processing properties that need definition in new Package.
Megaco：Megacoエンティティは、応答メッセージにエラーコードを提供します。トランザクションで「オプション」とマークされたコマンドが失敗した場合、残りのコマンドは継続します。ただし、指定された要件は、新しいパッケージで定義が必要な処理プロパティのルールを扱います。
Diameter: Indication of the mandatory or optional status of AVPs is fully supported, provided it is enabled in the AVP definition. No guidance is imposed regarding the return of diagnostic information for optional AVPs.
直径：AVP定義で有効になっていれば、AVPの必須またはオプションのステータスの表示が完全にサポートされています。オプションのAVPの診断情報の返品に関するガイダンスは課されていません。
COPS: COPS provides for the exchange of capabilities and limitations between the PEP and PDP to ensure well-known outcomes are understood for scenarios with unknown attributes. There is also clear error handling for situations when the request is rejected.
警官：COPSは、PEPとPDPの間の能力と制限の交換を提供し、未知の属性を持つシナリオについてよく知られている結果が理解されるようにします。また、リクエストが拒否された状況の明確なエラー処理もあります。
SNMP: T, RSIP: P+, Megaco: T, Diameter: T, COPS: T
SNMP: The SNMPv3 protocol returns error codes and exception codes in Response messages, to permit the requestor to modify their request. Errors and exceptions indicate the attribute that caused the error, and an error code identifies the nature of the error encountered.
SNMP：SNMPV3プロトコルは、応答メッセージのエラーコードと例外コードを返し、要求者がリクエストを変更できるようにします。エラーと例外は、エラーを引き起こした属性を示し、エラーコードは遭遇したエラーの性質を識別します。
If desired, a MIB can be designed to provide additional data about error conditions either via asynchronous notifications or polled objects.
必要に応じて、MIBは、非同期通知またはポーリングされたオブジェクトのいずれかを介してエラー条件に関する追加データを提供するように設計できます。
RSIP: RSIP defines a fairly large number of very specific error values. It is anticipated that additional error values will also have to be defined along with the new messages and parameters required for MIDCOM.
RSIP：RSIPは、非常に多数の非常に特定のエラー値を定義します。Midcomに必要な新しいメッセージとパラメーターとともに、追加のエラー値も定義する必要があることが予想されます。
Megaco: The MG can provide Error codes in response messages allowing the MGC to modify its behavior. Megaco uses transaction identifiers for correlation between a response and a command. If the same transaction id is received more than once, the receiving entity silently discards the message, thus providing some protection against replay attacks.
MEGACO：MGは、MGCが動作を変更できるようにする応答メッセージでエラーコードを提供できます。Megacoは、応答とコマンドとの相関にトランザクション識別子を使用します。同じトランザクションIDが複数回受信された場合、受信エンティティは静かにメッセージを破棄し、リプレイ攻撃に対する保護を提供します。
Diameter: Diameter provides an extensive set of failure reasons in the base protocol.
直径：直径は、基本プロトコルの大規模な障害理由を提供します。
COPS: COPS uses an error object to identify a particular COPS protocol error. The error sub-code field may contain additional detailed COPS client (MIDCOM Middlebox) specific error codes.
COPS：COPSはエラーオブジェクトを使用して、特定のCOPSプロトコルエラーを識別します。エラーサブコードフィールドには、追加の詳細なCOPSクライアント（MIDCOMミドルボックス）固有のエラーコードが含まれる場合があります。
2.2.7. Multiple Agents Operating on the Same Ruleset.
2.2.7. 同じルールセットで動作する複数のエージェント。
SNMP: T, RSIP: P, Megaco: P, Diameter: T, COPS: P
SNMP: The SNMP framework supports multiple managers working on the same managed objects. The View-based Access Control Model (VACM, RFC 3415 [14]) even offers means to customize the access rights of different managers in a fine-grained way.
SNMP：SNMPフレームワークは、同じ管理されたオブジェクトで作業する複数のマネージャーをサポートします。ビューベースのアクセス制御モデル（VACM、RFC 3415 [14]）は、さまざまなマネージャーのアクセス権をきれいな方法でカスタマイズするための手段を提供します。
RSIP: RSIP neither explicitly permits nor precludes an operation on a binding by a host that had not originally create the binding. However, to support this requirement, the RSIP semantics must be extended to explicitly permit any authorized host to request operations on a binding; this does not require a change to the protocol.
RSIP：RSIPは、元々バインディングを作成していなかったホストによるバインディングの操作を明示的に許可せず、排除することもありません。ただし、この要件をサポートするには、RSIPセマンティクスを拡張して、承認されたホストがバインディングの操作を要求することを明示的に許可する必要があります。これには、プロトコルの変更は必要ありません。
Megaco: If the Megaco state machine on the Middle Box is decoupled from the Middle Box policy rule management, this requirement can be met with local policies on the Middle Box. However, this violates the spirit of the Megaco protocol, thus Megaco is considered partially compliant to this requirement.
Megaco：中央のボックスのMegaco Stateマシンが中間ボックスのポリシールール管理から切り離されている場合、この要件は中央のボックスのローカルポリシーで満たすことができます。ただし、これはメガコプロトコルの精神に違反しているため、メガコはこの要件に部分的に準拠していると考えられています。
Diameter: The Diameter protocol, as currently defined, would allow multiple agents to operate on the same ruleset.
直径：現在定義されている直径プロトコルは、複数のエージェントが同じルールセットで動作することを可能にします。
COPS: It is possible to use COPS to operate the same resource with multiple agents. An underlying resource management function, separate from the COPS state machine, on the Middlebox will handle the arbitration when resource conflicts happen.
警官：COPSを使用して、複数のエージェントを使用して同じリソースを操作することができます。Middlebox上のCops State Machineとは別の基礎となるリソース管理機能は、リソースの競合が発生したときに仲裁を処理します。
SNMP: P+, RSIP: P+, Megaco: P+, Diameter: P+, COPS: P+
SNMP: This requirement can be met by an appropriate definition of a MIDCOM MIB module. SMI, the language used for defining MIB modules, is flexible enough to allow the implementation of a MIB module to meet the semantics of this requirement.
SNMP：この要件は、Midcom MIBモジュールの適切な定義によって満たすことができます。MIBモジュールの定義に使用される言語であるSMIは、MIBモジュールの実装がこの要件のセマンティクスを満たすことができるほど柔軟です。
RSIP: To support this requirement, a new optional enumeration parameter, transportProtocol, can be added to the RSIP ASSIGN_REQUESTs. When the parameter is included, the binding created applies only to the use of the bound addresses and ports, by the specific transportProtocol. When the parameter is not included, the binding applies to the use of all the bound addresses and ports, by any transport protocol, thus maintaining backward compatibility with the current definition of RSIP.
RSIP：この要件をサポートするには、新しいオプションの列挙パラメーターであるTransportProtocolをRSIP Assign_Requestsに追加できます。パラメーターが含まれている場合、作成されたバインディングは、特定のTransportProtocolによって、バインドアドレスとポートの使用にのみ適用されます。パラメーターが含まれていない場合、バインディングは、輸送プロトコルによって、すべてのバインドアドレスとポートの使用に適用されるため、RSIPの現在の定義との後方互換性を維持します。
Megaco: Megaco protocol can meet this requirement by defining a new property for the transport of filtering rules.
Megaco：Megacoプロトコルは、フィルタリングルールの輸送のための新しいプロパティを定義することにより、この要件を満たすことができます。
Diameter: While Diameter defines the promising IPFilterRule data type (see 2.1.12 above), there is no existing message, which would convey this to a Middlebox along with other required MIDCOM attributes. A new MIDCOM application extension of Diameter would have to be defined.
直径：直径は有望なIPFilTerruleデータ型を定義しますが（上記2.1.12を参照）、既存のメッセージはありません。直径の新しいMIDCOMアプリケーション拡張を定義する必要があります。
COPS: The COPS protocol can meet this requirement by using a COPS MIDCOM specific client or a MIDCOM specific PIB.
COPS：COPSプロトコルは、COPS Midcom固有のクライアントまたはMidcom固有のPIBを使用することにより、この要件を満たすことができます。
SNMP: P+, RSIP: P+, Megaco: P+, Diameter: P+, COPS: P+
SNMP: This requirement can be met by an appropriate definition of a MIDCOM MIB module.
SNMP：この要件は、Midcom MIBモジュールの適切な定義によって満たすことができます。
RSIP: To support this requirement, a new optional boolean parameter, portOddity, can be added to the RSIP ASSIGN_REQUESTs. If the parameter is TRUE, the remote port number of the binding created would have the same oddity as the local port. If the parameter is not specified, or is FALSE, the remote port's oddity is independent of the local port's oddity, thus maintaining backward compatibility with the current definition of RSIP.
RSIP：この要件をサポートするには、新しいオプションのブールパラメーターであるportoddityをRSIP Assign_Requestsに追加できます。パラメーターがtrueの場合、作成されたバインディングのリモートポート番号は、ローカルポートと同じ奇妙さを持ちます。パラメーターが指定されていない場合、またはfalseの場合、リモートポートの奇妙さはローカルポートの奇妙さに依存しないため、RSIPの現在の定義との後方互換性を維持します。
Megaco: Megaco can be easily extended using a MIDCOM specific Package to support this feature.
Megaco：Midcom固有のパッケージを使用してメガコを簡単に拡張して、この機能をサポートできます。
Diameter: This capability is not part of the current IPFilterRule type definition. Rather than modify the IPFilterRule type, MIDCOM could group it with other AVPs which add the missing information.
直径：この機能は、現在のIPFilTerruleタイプ定義の一部ではありません。IPFilterruleタイプを変更するのではなく、Midcomは、欠落している情報を追加する他のAVPとグループ化できます。
COPS: The COPS protocol has all the flexibility to meet this requirement by using a COPS MIDCOM specific client or a MIDCOM specific PIB.
COPS：COPSプロトコルには、COPS Midcom固有のクライアントまたはMidcom固有のPIBを使用して、この要件を満たす柔軟性がすべてあります。
SNMP: P+, RSIP: T, Megaco: P+, Diameter: P+, COPS: P+
SNMP: This requirement can be met by an appropriate definition of a MIDCOM MIB module. SMI, the language used for defining MIB modules, is flexible enough to allow the implementation of a MIB module to meet the semantics of this requirement.
SNMP：この要件は、Midcom MIBモジュールの適切な定義によって満たすことができます。MIBモジュールの定義に使用される言語であるSMIは、MIBモジュールの実装がこの要件のセマンティクスを満たすことができるほど柔軟です。
RSIP: The ports parameter of the RSIP ASSIGN_REQUESTs specifically allows multiple, consecutive port numbers to be specified.
RSIP：RSIP Assign_Requestsのポートパラメーターは、複数の連続したポート番号を指定することを特に許可します。
Megaco: Megaco can be easily extended using a MIDCOM specific Package to support this feature.
Megaco：Midcom固有のパッケージを使用してメガコを簡単に拡張して、この機能をサポートできます。
Diameter: This capability is not part of the current IPFilterRule type definition. Rather than modify the IPFilterRule type, MIDCOM could group it with other AVPs which add the missing information.
直径：この機能は、現在のIPFilTerruleタイプ定義の一部ではありません。IPFilterruleタイプを変更するのではなく、Midcomは、欠落している情報を追加する他のAVPとグループ化できます。
COPS: The COPS protocol has all the flexibility to meet this requirement by using a COPS MIDCOM specific client or a MIDCOM specific PIB.
COPS：COPSプロトコルには、COPS Midcom固有のクライアントまたはMidcom固有のPIBを使用して、この要件を満たす柔軟性がすべてあります。
SNMP: P+, RSIP: P+, Megaco: P+, Diameter: T, COPS: P+
SNMP: This requirement can be met by an appropriate definition of a MIDCOM MIB module.
SNMP：この要件は、Midcom MIBモジュールの適切な定義によって満たすことができます。
RSIP: To support this requirement, a new optional boolean parameter, overlapOK, can be added to the RSIP ASSIGN_REQUESTs. If the parameter is TRUE, the binding may overlap with an existing binding. If the parameter is unspecified, or is FALSE, the binding will not overlap with an existing binding, thus maintaining backward compatibility with the current definition of RSIP.
RSIP：この要件をサポートするには、新しいオプションのブールパラメーターであるOverlapokをRSIP Assign_Requestsに追加できます。パラメーターが真の場合、バインディングは既存のバインディングと重複する場合があります。パラメーターが不特定である、または誤っている場合、バインディングは既存のバインディングと重複しないため、RSIPの現在の定義との後方互換性を維持します。
Megaco: This requirement would be met if the policy in the Middlebox allows contradictory, overlapping policy rules to be installed.
MEGACO：この要件は、ミドルボックスのポリシーが矛盾した重複するポリシールールをインストールすることを許可した場合に満たされます。
Diameter: Allowed by the IPFilterRule semantics described in Appendix D.
直径：付録Dで説明されているIPFilterruleセマンティクスによって許可
COPS: The COPS protocol has all the flexibility to meet this requirement by using a COPS MIDCOM specific client or a MIDCOM specific PIB.
COPS：COPSプロトコルには、COPS Midcom固有のクライアントまたはMidcom固有のPIBを使用して、この要件を満たす柔軟性がすべてあります。
This section contains the individual protocols as evaluated against the General Security requirements from section 2.3 of the requirements document [1]. A short description of each of the protocols is provided to substantiate the evaluation.
このセクションには、要件文書[1]のセクション2.3からの一般的なセキュリティ要件に対して評価された個々のプロトコルが含まれています。評価を実証するために、各プロトコルの簡単な説明が提供されます。
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: SNMPv3 includes the User-based Security Model (USM, RFC 3414 [11]), which defines three standardized methods for providing authentication, confidentiality, and integrity. Additionally, USM has specific built-in mechanisms for preventing replay attacks including unique protocol engine IDs, timers and counters per engine and time windows for the validity of messages.
SNMP：SNMPV3には、ユーザーベースのセキュリティモデル（USM、RFC 3414 [11]）が含まれています。これは、認証、機密性、および完全性を提供するための3つの標準化された方法を定義します。さらに、USMには、一意のプロトコルエンジンID、エンジンあたりのタイマー、カウンター、メッセージの有効性のためのタイムウィンドウなど、リプレイ攻撃を防ぐための特定の組み込みメカニズムがあります。
RSIP: This requirement can be met by operating RSIP over IPSec. The RSIP framework recommends all communication between an RSIP host and gateway be authenticated. Authentication, in the form of a message hash appended to the end of each RSIP protocol packet, can serve to authenticate the RSIP host and gateway to one another, provide message integrity, and avoid replay attacks with an anti-replay counter. However, the message hash and replay counter parameters would need to be defined for the RSIP protocol.
RSIP：この要件は、IPSECを介してRSIPを操作することで満たすことができます。RSIPフレームワークでは、RSIPホストとゲートウェイ間のすべての通信を認証することを推奨しています。認証は、各RSIPプロトコルパケットの最後に追加されたメッセージの形式で、RSIPホストとゲートウェイを互いに認証し、メッセージの整合性を提供し、アンチレプレイカウンターで再生攻撃を回避するのに役立ちます。ただし、RSIPプロトコルでは、メッセージハッシュとリプレイカウンターパラメーターを定義する必要があります。
Megaco: Megaco provides for these functions with the combined usage of IPSEC [22] or TLS [21].
Megaco：Megacoは、これらの機能にIPSEC [22]またはTLS [21]の使用を組み合わせて提供します。
Diameter: Diameter relies on either IPSEC or TLS for these functions.
直径：直径は、これらの機能のIPSECまたはTLSのいずれかに依存しています。
COPS: COPS has built-in message level security for authentication, replay protection, and message integrity. COPS can also use TLS or IPSec, thus reusing existing security mechanisms that have interoperated in the markets.
警官：Copsには、認証、リプレイ保護、メッセージの整合性のためのメッセージレベルのセキュリティが組み込まれています。COPはTLSまたはIPSECを使用することもでき、市場で相互運用した既存のセキュリティメカニズムを再利用できます。
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: SNMPv3 includes the User-based Security Model, which defines three standardized methods for providing authentication, confidentiality, and integrity, and is open to add further methods. The method to use can be optionally chosen.
SNMP：SNMPV3には、認証、機密性、および整合性を提供するための3つの標準化された方法を定義するユーザーベースのセキュリティモデルが含まれており、さらなる方法を追加するために開かれています。使用する方法はオプションで選択できます。
RSIP: Refer to 2.3.1.
RSIP：2.3.1を参照してください。
Megaco: Refer to 2.3.1
メガコ：2.3.1を参照してください
Diameter: Implementation support of IPSEC ESP (RFC 2406 [23]) in Diameter applications is not optional. Deployment of either IPSEC or TLS is optional.
直径：直径アプリケーションのIPSEC ESP（RFC 2406 [23]）の実装サポートはオプションではありません。IPSECまたはTLSのいずれかの展開はオプションです。
COPS: Refer to 2.3.1.
警官：2.3.1を参照してください。
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: The User-based Security Model of SNMPv3 defines three standardized methods for providing authentication, confidentiality, and integrity, and it is open to add further methods. These methods operate securely across untrusted domains.
SNMP：SNMPV3のユーザーベースのセキュリティモデルは、認証、機密性、および整合性を提供するための3つの標準化された方法を定義しており、さらなる方法を追加することができます。これらの方法は、信頼できないドメイン全体で安全に動作します。
RSIP: Refer to 2.3.1.
RSIP：2.3.1を参照してください。
Megaco: Refer to 2.3.1.
メガコ：2.3.1を参照してください。
Diameter: The Diameter specification [24] recommends the use of TLS [21] across untrusted domains.
直径：直径仕様[24]は、信頼できないドメイン全体でTLS [21]の使用を推奨しています。
COPS: Refer to 2.3.1
警官：2.3.1を参照してください
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: The User-based Security Model for SNMPv3 has specific built-in mechanisms for preventing replay attacks including unique protocol engine IDs, timers and counters per engine and time windows for the validity of messages.
SNMP：SNMPV3のユーザーベースのセキュリティモデルには、メッセージの有効性のために、ユニークなプロトコルエンジンID、エンジンごとのタイマー、カウンター、タイムウィンドウなど、リプレイ攻撃を防ぐための特定の組み込みメカニズムがあります。
RSIP: Refer to 2.3.1 Megaco: Megaco commands and responses include matching transaction identifiers. The recipient receiving the same transaction id multiple times would discard the message, thus providing some protection against replay attacks. If even stronger protection against replay attack is needed, Megaco provides for the use of IPSec or TLS.
RSIP：2.3.1を参照してくださいMegaco：Megacoコマンドと応答には一致するトランザクション識別子が含まれます。同じトランザクションIDを複数回受け取った受信者はメッセージを破棄し、リプレイ攻撃に対するある程度の保護を提供します。リプレイ攻撃に対する強い保護がさらに必要な場合、MegacoはIPSECまたはTLSの使用を提供します。
Diameter: Diameter requires that implementations support the replay protection mechanisms of IPSEC.
直径：直径では、実装がIPSECのリプレイ保護メカニズムをサポートする必要があります。
COPS: Refer to 2.3.1
警官：2.3.1を参照してください
The overall statistics with regards to the number of Fully Compliant, Partially Compliant (P+ and P) and Failing Compliancy requirements for each of the protocols is summarized in table 1.
完全に準拠、部分的に準拠した（PおよびP）の数に関する全体的な統計と、各プロトコルのコンプライアンス要件の失敗を表1にまとめます。
T P+ P F
-----------------------------------------------------------------
SNMP 22 5 0 0
RSIP 17 7 3 0
Megaco 19 5 3 0
Diameter 21 5 1 0
COPS 20 5 2 0
Table 1: Totals across all Requirements
表1：すべての要件にわたる合計
In considering the P+ category of compliancy, an important aspect is the mechanism for support of extensibility. The extension mechanism provided by SNMP and COPS-PR using MIBs and PIBs respectively, provides extensions with no impact to the protocol. Diameter extensions require protocol changes, thus has a higher impact, although the extensions can be handled by other Diameter entities without being understood. Megaco's extension mechanisms of packages also requires protocol changes that must be understand by both sending and receiving entities, also being considered higher impact. The RSIP extension mechanism has the largest impact on the existing protocol and is based upon defining the necessary new parameters.
コンプライアンスのPカテゴリを検討する際に、重要な側面は、拡張性をサポートするメカニズムです。それぞれSNMPおよびCOPS-PRがMIBとPIBを使用して提供する拡張メカニズムは、プロトコルに影響を与えない拡張機能を提供します。直径の拡張にはプロトコルの変更が必要であるため、拡張機能は理解されずに他の直径エンティティによって処理される可能性がありますが、より大きな影響があります。Megacoのパッケージの拡張メカニズムには、エンティティの送信と受信の両方で理解しなければならないプロトコルの変更も必要であり、より高い影響と見なされます。RSIP拡張メカニズムは、既存のプロトコルに最大の影響を与え、必要な新しいパラメーターを定義することに基づいています。
The SNMP management framework meets all the specified MIDCOM protocol requirements with the appropriate design of a MIDCOM MIB module. SNMP is a proven technology with stable and proven development tools, already has extensions defined to support NAT configuration and policy-based management. SNMPv3 is a full standard, is more mature and has undergone more validation than the other protocols in the evaluation, and has been deployed to manage large-scale real-world networks (e.g., DOCSIS cable modem networks). The applicability of SNMP to the MIDCOM framework has a restriction in that it assumes the MIDCOM PDP is part of the Middlebox.
SNMP管理フレームワークは、MIDCOM MIBモジュールの適切な設計により、指定されたすべてのMIDCOMプロトコル要件を満たしています。SNMPは、安定した実績のある開発ツールを備えた実績のあるテクノロジーであり、NATの構成とポリシーベースの管理をサポートするために拡張機能が既に定義されています。SNMPV3は完全な標準であり、成熟しており、評価の他のプロトコルよりも検証が行われ、大規模な現実世界のネットワーク（Docsisケーブルモデムネットワークなど）を管理するために展開されています。MIDCOMフレームワークへのSNMPの適用性には、MIDCOM PDPがミドルボックスの一部であると仮定するという点で制限があります。
RSIP fully meets many of the MIDCOM requirements. However, it does require additions and extensions to meet several of the requirements. RSIP would also require several framework elements to be added to the MIDCOM framework as identified in section 1.2.3. In addition, the tunneling required for RSIP as described in section 1.2.4, results in RSIP not being acceptable by the WG as the MIDCOM protocol.
RSIPは、MIDCOM要件の多くを完全に満たしています。ただし、いくつかの要件を満たすには、追加と拡張機能が必要です。また、RSIPは、セクション1.2.3で特定されているように、MIDCOMフレームワークにいくつかのフレームワーク要素を追加する必要があります。さらに、セクション1.2.4で説明されているRSIPに必要なトンネルは、MIDCOMプロトコルとしてWGによって受け入れられない結果です。
Megaco fully meets most of the key requirements for the MIDCOM Protocol. Additional extensions in the form of a new Termination / Package definition would be required for MIDCOM to meet several of the requirements. In order to meet the remaining requirements, modeling the underlying Middlebox resources (e.g., filters, policy rules) as separate elements from the Megaco entities might allow the usage of the protocol as-is, satisfying some of the resource access control requirements.
Megacoは、MIDCOMプロトコルの主要な要件のほとんどを完全に満たしています。Midcomがいくつかの要件を満たすには、新しい終了 /パッケージ定義の形式の追加の拡張が必要です。残りの要件を満たすために、基礎となるミドルボックスリソース（たとえば、フィルター、ポリシールール）をMegacoエンティティとの別々の要素としてモデル化すると、プロトコルの使用が可能になり、リソースアクセス制御要件の一部を満たすことができます。
The Diameter evaluation indicated a good overall fit. Some partially met requirements were identified that could be addressed by a new application extension. However, the Diameter architecture may be too heavy for the MIDCOM application and clearly much of the Diameter base is not needed. In addition, Diameter is the only protocol, at the time of this evaluation, for which the RFCs had not yet been published. Other than these reservations, the protocol is a good fit to MIDCOM requirements.
直径の評価は、全体的な適合性を示しています。新しいアプリケーション拡張で対処できる部分的にMET要件が特定されました。ただし、直径のアーキテクチャはMidcomアプリケーションには重すぎる可能性があり、明らかに直径のベースの多くは必要ありません。さらに、この評価の時点での直径は唯一のプロトコルであり、RFCSはまだ公開されていません。これらの予約以外に、プロトコルはMIDCOM要件に適しています。
The COPS evaluation indicates that the protocol meets the majority of the MIDCOM protocol requirements by using the protocol's native extension techniques, with COPS-PR being explicitly required to meet requirements 2.1.3 and 2.2.3. In order to fully satisfy one partially met requirement, 2.1.1, the COPS model would need to allow a PDP to establish communication with a PEP. While not explicitly prohibited by the COPS model, this would require additions, in the form of local policy, to ensure the proper establishment of an authorized association.
COPS評価は、プロトコルのネイティブ拡張手法を使用して、プロトコルがMIDCOMプロトコル要件の大部分を満たしていることを示しており、COPS-PRは要件2.1.3および2.2.3を満たすために明示的に必要です。部分的に満たされた要件、2.1.1を完全に満たすためには、COPSモデルはPDPがPEPとのコミュニケーションを確立できるようにする必要があります。COPSモデルによって明示的に禁止されていませんが、これには、承認された協会の適切な設立を確保するために、ローカルポリシーの形で追加が必要になります。
Security considerations for the MIDCOM protocol are covered by the comparison against the specific Security requirements in the MIDCOM requirements document [1] and are specifically addressed by section 2.1.8 and section 2.3.
MIDCOMプロトコルのセキュリティ上の考慮事項は、MIDCOM要件ドキュメント[1]の特定のセキュリティ要件との比較でカバーされており、セクション2.1.8およびセクション2.3で特別に対処されています。
[1] Swale, R., Mart, P., Sijben, P., Brim, S., and M. Shore, "Middlebox Communications (MIDCOM) Protocol Requirements", RFC 3304, August 2002.
[1] Swale、R.、Mart、P.、Sijben、P.、Brim、S。、およびM. Shore、「Middlebox Communications（Midcom）プロトコル要件」、RFC 3304、2002年8月。
[2] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. Rayhan, "Middlebox Communications Architecture and Framework", RFC 3303, August 2002.
[2] Srisuresh、P.、Kuthan、J.、Rosenberg、J.、Molitor、A。、およびA. Rayhan、「Middlebox Communications Architecture and Framework」、RFC 3303、2002年8月。
[3] Rose, M. and K. McCloghrie, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, March 1991.
[3] Rose、M。and K. McCloghrie、「TCP/IPベースのインターネットのネットワーク管理のための管理情報基盤：MIB-II」、STD 17、RFC 1213、1991年3月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[5] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", STD 62, RFC 3411, December 2002.
[5] Harrington、D.、Presuhn、R。、およびB. Wijnen、「SNMP管理フレームワークを説明するためのアーキテクチャ」、STD 62、RFC 3411、2002年12月。
[6] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[6] McCloghrie、K.、Perkins、D。、およびJ. Schoenwaelder、「管理情報の構造バージョン2（SMIV2）」、STD 58、RFC 2578、1999年4月。
[7] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[7] McCloghrie、K.、Perkins、D。、およびJ. Schoenwaelder、「SMIV2のテキストコンベンション」、STD 58、RFC 2579、1999年4月。
[8] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
[8] McCloghrie、K.、Perkins、D。、およびJ. Schoenwaelder、「SMIV2の適合ステートメント」、STD 58、RFC 2580、1999年4月。
[9] Presuhn, R. (Ed.), "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002.
[9] Presuhn、R。（ed。）、「Simple Network Management Protocol（SNMP）の輸送マッピング」、STD 62、RFC 3417、2002年12月。
[10] 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.
[10] Case、J.、Harrington D.、Presuhn R.、およびB. Wijnen、「Simple Network Management Protocol（SNMP）のメッセージ処理とディスパッチ」、STD 62、RFC 3412、2002年12月。
[11] 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.
[11] Blumenthal、U.およびB. Wijnen、「Simple Network Management Protocol（SNMPV3）のバージョン3のユーザーベースのセキュリティモデル（USM）」、STD 62、RFC 3414、2002年12月。
[12] Presuhn, R. (Ed.), "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002.
[12] Presuhn、R。（ed。）、「Simple Network Management Protocol（SNMP）のプロトコル操作のバージョン2」、STD 62、RFC 3416、2002年12月。
[13] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", STD 62, RFC 3413, December 2002.
[13] Levi、D.、Meyer、P。、およびB. Stewart、「SNMPV3アプリケーション」、STD 62、RFC 3413、2002年12月。
[14] 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.
[14] Wijnen、B.、Presuhn、R。、およびK. McCloghrie、「シンプルネットワーク管理プロトコル（SNMP）のビューベースのアクセス制御モデル（VACM）」、STD 62、RFC 3415、2002年12月。
[15] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to Version 3 of the Internet-Standard Network Management Framework", RFC 3410, December 2002.
[15] Case、J.、Mundy、R.、Partain、D。、およびB. Stewart、「インターネット標準ネットワーク管理フレームワークのバージョン3の紹介」、RFC 3410、2002年12月。
[16] Rohit, R., Srisuresh, P., Raghunarayan, R., Pai, N., and C. Wang, "Definitions of Managed Objects for Network Address Translators (NAT)", RFC 4008, March 2005.
[16] Rohit、R.、Srisuresh、P.、Raghunarayan、R.、Pai、N。、およびC. Wang、「ネットワークアドレス翻訳者の管理オブジェクトの定義（NAT）」、RFC 4008、2005年3月。
[17] Borella, M., Lo, J., Grabelsky, D., and G. Montenegro, "Realm Specific IP: Framework", RFC 3102, October 2001.
[17] Borella、M.、Lo、J.、Grabelsky、D。、およびG. Montenegro、「Realm固有のIP：フレームワーク」、RFC 3102、2001年10月。
[18] Borella, M., Grabelsky, D., Lo, J., and K. Taniguchi, "Realm Specific IP: Protocol Specification", RFC 3103, October 2001.
[18] Borella、M.、Grabelsky、D.、Lo、J。、およびK. Taniguchi、「Realm固有のIP：プロトコル仕様」、RFC 3103、2001年10月。
[19] Montenegro, G. and M. Borella, "RSIP Support for End-to-end Ipsec", RFC 3104, October 2001.
[19] モンテネグロ、G。およびM.ボレラ、「エンドツーエンドIPSECのRSIPサポート」、RFC 3104、2001年10月。
[20] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B., and J. Segers, "Megaco Protocol Version 1.0", RFC 3015, October 2001.
[20] Cuervo、F.、Greene、N.、Rayhan、A.、Huitema、C.、Rosen、B。、およびJ. Segers、「Megaco Protocolバージョン1.0」、RFC 3015、2001年10月。
[21] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[21] Dierks、T。およびC. Allen、「TLSプロトコルバージョン1.0」、RFC 2246、1999年1月。
[22] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[22] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[23] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload", RFC 2406, November 1998.
[23] Kent、S。およびR. Atkinson、「IPカプセル化セキュリティペイロード」、RFC 2406、1998年11月。
[24] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[24] Calhoun、P.、Loughney、J.、Guttman、E.、Zorn、G。、およびJ. Arkko、「直径ベースプロトコル」、RFC 3588、2003年9月。
[25] Durham, D. (Ed.), Boyle, J., Cohen, R., Herzog, S., Rajan, R., and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000.
[25] Durham、D。（ed。）、Boyle、J.、Cohen、R.、Herzog、S.、Rajan、R.、およびA. Sastry、「The Cops（Common Open Policy Service）Protocol」、RFC 2748、1月2000。
[26] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A. Smith, "COPS Usage for Policy Provisioning", RFC 3084, March 2001.
[26] Chan、K.、Seligson、J.、Durham、D.、Gai、S.、McCloghrie、K.、Herzog、S.、Reichmeyer、F.、Yavatkar、R。、およびA. Smith、「警察の使用法の使用プロビジョニング」、RFC 3084、2001年3月。
[27] Raz, D., Schoenwalder, J., and B. Sugla, "An SNMP Application Level Gateway for Payload Address Translation", RFC 2962, October 2000.
[27] Raz、D.、Schoenwalder、J。、およびB. Sugla、「ペイロードアドレス翻訳のSNMPアプリケーションレベルゲートウェイ」、RFC 2962、2000年10月。
[28] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
[28] McCloghrie、K。およびF. Kastenholz、「The Interfaces Group MIB」、RFC 2863、2000年6月。
The editor would like to acknowledge the constructive feedback provided by Joel M. Halpern on the individual protocol evaluation contributions. In addition, a thanks to Elwyn Davies, Christopher Martin, Bob Penfield, Scott Brim and Martin Stiemerling for contributing to the mailing list discussion on the document content.
編集者は、個々のプロトコル評価の貢献についてJoel M. Halpernが提供する建設的なフィードバックを認めたいと考えています。さらに、エルウィン・デイビス、クリストファー・マーティン、ボブ・ペンフィールド、スコット・ブリム、マーティン・スティメーリングに感謝します。
Appendix A - SNMP Overview
付録A -SNMPの概要
The SNMP Management Framework presently consists of five major components:
SNMP管理フレームワークは現在、5つの主要なコンポーネントで構成されています。
o An overall architecture, described in RFC 3411 [5]. A more detailed introduction and applicability statements for the SNMP Management Framework can be found in RFC 3410 [15].
o RFC 3411 [5]に記載されている全体的なアーキテクチャ。SNMP管理フレームワークのより詳細な紹介と適用のステートメントは、RFC 3410 [15]に記載されています。
o Mechanisms for describing and naming objects and events for the purpose of management. The current version of this Structure of Management Information (SMI) is called SMIv2 and described in RFC 2578 [6], RFC 2579 [7] and RFC 2580 [8].
o 管理を目的としたオブジェクトとイベントを説明および名前を付けるためのメカニズム。この管理情報構造（SMI）の現在のバージョンはSMIV2と呼ばれ、RFC 2578 [6]、RFC 2579 [7]、およびRFC 2580 [8]で説明されています。
o Message protocols for transferring management information. The current version of the message protocol is called SNMPv3 and described in RFC 3412 [10], RFC 3414 [11] and RFC 3417 [9].
o 管理情報を転送するためのメッセージプロトコル。メッセージプロトコルの現在のバージョンはSNMPV3と呼ばれ、RFC 3412 [10]、RFC 3414 [11]およびRFC 3417 [9]で説明されています。
o Protocol operations for accessing management information. The current version of the protocol operations and associated PDU formats is described in RFC 3416 [12].
o 管理情報にアクセスするためのプロトコル操作。プロトコル操作と関連するPDU形式の現在のバージョンは、RFC 3416 [12]で説明されています。
o A set of fundamental applications described in RFC 3413 [13] and the view-based access control mechanism described in RFC 3415 [14].
o RFC 3413 [13]に記載されている一連の基本的なアプリケーションと、RFC 3415 [14]で説明されているビューベースのアクセス制御メカニズム。
Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI.
管理されたオブジェクトは、管理情報ベースまたはMIBと呼ばれる仮想情報ストアからアクセスされます。MIBのオブジェクトは、SMIで定義されたメカニズムを使用して定義されます。
SNMPv3 proxy forwarding (RFC 3413 [13]) provides a standardized mechanism to configure an intermediate node to forward SNMP messages. A command generating entity sends requests to a proxy forwarding entity that forwards the request to a third entity.
SNMPV3プロキシ転送（RFC 3413 [13]）は、SNMPメッセージを転送するために中間ノードを構成するための標準化されたメカニズムを提供します。コマンド生成エンティティは、リクエストを3番目のエンティティに転送するプロキシ転送エンティティにリクエストを送信します。
One SNMP entity may serve both functions as the SNMP agent to monitor and configure the node on which it is resident, and as an intermediate node in a proxy relationship to permit monitoring and configuration of additional entities.
1つのSNMPエンティティは、両方の機能をSNMPエージェントとして提供して、それが居住者であるノードを監視および構成すること、および追加のエンティティの監視と構成を許可するプロキシ関係の中間ノードとして提供する場合があります。
Each entity is identified by a unique engineID value, specifically to support proxy between addressing domains and/or trust domains. An SNMPv3 message contains two engineIDs- one to identify the database to be used for message security, and one to identify the source (or target) of the contained data. Message security is applied between the originator and the proxy, and then between the proxy and the end-target. The PDU contains the engineID of the node whose data is contained in the message, which passes end-to-end, unchanged by the proxy.
各エンティティは、特にドメインと信頼ドメインのアドレス指定間のプロキシをサポートするために、一意のEngineID値によって識別されます。SNMPV3メッセージには、メッセージセキュリティに使用されるデータベースを識別する2つのEngineIDSが含まれています。メッセージセキュリティは、オリジネーターとプロキシの間に、そしてプロキシとエンドターゲットの間に適用されます。PDUには、メッセージにデータが含まれているノードのエンジンが含まれており、プロキシによって変更されずにエンドツーエンドを渡します。
SNMPv3 proxy was designed to provide a standard SNMP approach to inserting an intermediate node in the middle of communications for a variety of scenarios. SNMPv3 proxy can support crossing addressing domains, such as IPv4 and IPv6, crossing SNMP version domains, such as SNMPv3 and SNMPv1, crossing security mechanism domains, such as DES and AES, and for providing a single point of management contact for a subset of the network, such as managing a private network through a NAT device or a VPN endpoint.
SNMPV3プロキシは、さまざまなシナリオの通信中に中間ノードを挿入するための標準的なSNMPアプローチを提供するように設計されました。SNMPV3プロキシは、IPv4やIPv6などの交差アドレス指定ドメイン、SNMPV3やSNMPV1などの交差SNMPバージョンドメイン、DESやAESなどのセキュリティメカニズムドメインの交差点ドメイン、および管理接触の単一のポイントを提供するために、NATデバイスやVPNエンドポイントを介してプライベートネットワークの管理などのネットワーク。
Proxies are generally preferred to Application Level Gateways for SNMP. ALGs typically modify the headers and content of messages. SNMP is a protocol designed for troubleshooting network (mis-) configurations. Because an operator needs to understand the actual configuration, the translation of addresses within SNMP data causes confusion, hiding the actual configuration of a managed device from the operator. ALGs also introduce security vulnerabilities, and other complexities related to modifying SNMP data.
プロキシは一般に、SNMPのアプリケーションレベルゲートウェイよりも好まれます。アルグは通常、メッセージのヘッダーとコンテンツを変更します。SNMPは、トラブルシューティングネットワーク（MIS-）構成のために設計されたプロトコルです。オペレーターは実際の構成を理解する必要があるため、SNMPデータ内のアドレスの変換は混乱を引き起こし、オペレーターから管理されたデバイスの実際の構成を隠します。ALGは、SNMPデータの変更に関連するセキュリティの脆弱性やその他の複雑さも導入します。
SNMP Proxies can modify message headers without modifying the contained data. This avoids the issues associated with translating the payload data, while permitting application level translation of addresses.
SNMPプロキシは、含まれるデータを変更せずにメッセージヘッダーを変更できます。これにより、アドレスのアプリケーションレベルの翻訳を許可しながら、ペイロードデータの翻訳に関連する問題が回避されます。
The issues of ALGs versus proxies for SNMP Payload Address Translation are discussed at length in RFC 2962 [27].
SNMPペイロードアドレスの翻訳のALGSとプロキシの問題は、RFC 2962 [27]で詳細に説明されています。
Appendix B - RSIP with Tunneling
付録B-トンネリング付きRSIP
NAT requires ALGs (Application Layer Gateways) in middleboxes without MIDCOM, and application modifications or agents for middleboxes with MIDCOM.
NATには、MidcomがないミドルボックスのALG（アプリケーションレイヤーゲートウェイ）、およびMIDCOMのミドルボックスのアプリケーションの変更またはエージェントが必要です。
Support for NAT without tunneling could easily be added to the RSIP control protocol. NAT would be defined as a new, null tunnel type. Support for the NAT null tunnels could be implemented in hosts, or in applications or application agents.
トンネリングなしのNATのサポートは、RSIP制御プロトコルに簡単に追加できます。NATは、新しいヌルトンネルタイプとして定義されます。Nat Nullトンネルのサポートは、ホスト、またはアプリケーションまたはアプリケーションエージェントに実装できます。
If support for NAT null tunnels were implemented in hosts, no modifications to applications would be required, and no application agents or ALGs would be required. This has obvious advantages. In addition to the NAT null tunnel, the host would have to implement an RSIP / MIDCOM client (or a STUN client) and the middlebox would have to implement an RSIP / MIDCOM server, or a STUN server would have to be available _beyond_ the middlebox. Note that the STUN client / server approach may not work with all types of middleboxes.
Nat Nullトンネルのサポートがホストに実装された場合、アプリケーションの変更は必要ありません。アプリケーションエージェントまたはALGは必要ありません。これには明らかな利点があります。NAT Nullトンネルに加えて、ホストはRSIP / MIDCOMクライアント（またはスタンクライアント）を実装する必要があり、ミドルボックスはRSIP / MIDCOMサーバーを実装する必要があります。。Stunクライアント /サーバーアプローチは、あらゆる種類のミドルボックスで動作しない場合があることに注意してください。
If support for NAT null tunnels were NOT implemented in hosts, then applications would have to be modified, or application agents or ALGs would have to be implemented. This has the advantage over tunnels (whether null or not) of not requiring modification to hosts, but would require the modification of host applications or the implementation of application agents, both of which would include an RSIP / MIDCOM client, and the implementation of an RSIP/MIDCOM server in the middlebox. Again, in some situations, STUN could be used instead of RSIP / MIDCOM.
Nat Nullトンネルのサポートがホストに実装されていない場合、アプリケーションを変更する必要があるか、アプリケーションエージェントまたはALGを実装する必要があります。これには、ホストの変更を必要としないというトンネルよりも利点がありますが、ホストアプリケーションの変更またはアプリケーションエージェントの実装が必要です。どちらもRSIP / MIDCOMクライアント、およびミドルボックスのRSIP/MIDCOMサーバー。繰り返しますが、状況によっては、RSIP / MIDCOMの代わりにスタンを使用できます。
Tunneled or not, an RSIP / MIDCOM server is needed in the middlebox. Tunneled, the host needs to be modified, but not the application. Untunneled, an agent must be added or the application must be modified, but there would be no host modifications. The advantages/disadvantages of tunneling would need to be evaluated in considering RSIP.
トンネリングであるかどうかにかかわらず、RSIP / MIDCOMサーバーがミドルボックスに必要です。トンネリングすると、ホストを変更する必要がありますが、アプリケーションではありません。反目に、エージェントを追加するか、アプリケーションを変更する必要がありますが、ホストの変更はありません。トンネルの利点/短所は、RSIPを考慮する際に評価する必要があります。
Appendix C - Megaco Modeling Approach
付録C-メガコモデリングアプローチ
To model the Middlebox functions such as firewall, NAT etc., a new Middlebox Termination type needs to be defined within Megaco. If policy-rule overlap or modification by multiple Agents is NOT required, then a policy rule is equivalent to a Termination (see Figure 1). The various components of a Policy rule such as filter, action, life-time, creator etc. are described as various properties of a Termination. Use of the Virtual Media Gateway (VMG) concept allows for conflict-free interaction of multiple MA's with the same MB.
ファイアウォール、NATなどのミドルボックス関数をモデル化するには、メガコ内で新しいミドルボックス終端タイプを定義する必要があります。複数のエージェントによるポリシールールの重複または変更が必要ない場合、ポリシールールは終了に相当します（図1を参照）。フィルター、アクション、寿命、作成者などのポリシールールのさまざまなコンポーネントは、終了のさまざまな特性として説明されています。Virtual Media Gateway（VMG）コンセプトの使用により、複数のMAと同じMBとの競合のない相互作用が可能になります。
+-------+ +-------+
| MA-1 | | MA-2 |
| | | |
+-------+ |IF2 +-------+
| | |
+-------------|---------|----------|-----------+
| +---------+ | +-------------+ |
IF1 |VMG1 | +--+ | | | +--+ +--+ |VMG2 |IF3
----------| |Tx|-------+ +---|Ty|--|Tz|----------------
| | +--+ | | | +--+ +--+ | |
| ....| | | +-------------+ |
| +---------+ | |
| +---------------------------------
| Middlebox | IF4
+----------------------------------------------+
Tx: Termination x = Policy rule x
Ty: Termination y = Policy rule y
Tz: Termination z = Policy rule z
MA: MIDCOM Agent
IF: Interface
Figure 1.
図1。
If it is required to allow multiple agents manipulate the same Middlebox resource (e.g., a Policy rule or a filter), the latter needs to be kept separate from the Termination (the Policy rule is manipulated by the MA by manipulating the properties of the associated Termination). For example, if overlapping policy rule manipulation is required, then a Termination shall be associated with a single policy rule, but a policy rule may be associated with more than one Termination. Thus, a Termination can share a policy rule with another Termination, or have a policy rule partially overlapping with that of another Termination. This model allows two MAs, controlling two distinct Terminations (see Figure 2), manipulate the same or overlapping policy rules. In Figure 2, policy rules 1 and 2 are overlapping and they are shared by MA-1 and MA-2.
複数のエージェントが同じミドルボックスリソース（ポリシールールまたはフィルターなど）を操作することを許可する必要がある場合、後者を終了とは別に保持する必要があります（ポリシールールは、関連するもののプロパティを操作することによりMAによって操作されます。終了）。たとえば、重複するポリシールール操作が必要な場合、終了は単一のポリシールールに関連付けられますが、ポリシールールは複数の終了に関連付けられている場合があります。したがって、終了は、ポリシールールを別の終了と共有するか、別の終了のそれと部分的に重複するポリシールールを持つことができます。このモデルにより、2つのMASが許可され、2つの異なる終了を制御し（図2を参照）、同じまたは重複するポリシールールを操作します。図2では、ポリシールール1と2が重複しており、MA-1とMA-2によって共有されています。
+-------+ +-------+
| MA-1 | | MA-2 |
| | | |
+-------+ |IF2 +-------+
| | | MB
+-------------|---------|----------|-----------+
| +-----------+ | +-------------+ |
IF1 |VMG1 | +--+ | | | +--+ +--+ |VMG2 |IF3
------------------|Ty|----+ +---|Tx|--|Tz|----------------
| | +--+ | | | +--+ +--+ | |
| .... | | | | +--/------\---+ |
| +-------|---+ | / \ |
| | +----/----------\------------------
| +------+----+------+ +------+ |IF4
| |Policy1 Policy2 | |Policy| |
| | | | | | 3 | |
| +----+------+------+ +------+ |
+----------------------------------------------+
Tx: Termination x Ty: Termination y Tz: Termination z MA: MIDCOM Agent IF: Interface MB: Middlebox
TX：終端x Ty：終端y tz：終端z ma：midcomエージェントの場合：インターフェイスMB：ミドルボックス
Figure 2.
図2。
This requires that the Agent and the Middlebox adhere to the following principles:
これには、エージェントとミドルボックスが次の原則を順守する必要があります。
(1) Only one Termination has read/write access to a filter at any time.
(1) いつでもフィルターへの読み取り/書き込みアクセスがあるのは1つだけです。
(2) When the policy rule is being modified by a new agent (i.e., not the one that created the policy) the Middlebox makes a policy decision and decides whether to accept the requested modification or not. In the case the modification is accepted the initial MIDCOM agent may be notified.
(2) ポリシールールが新しいエージェント（つまり、ポリシーを作成したものではない）によって変更されている場合、ミドルボックスはポリシーの決定を下し、要求された変更を受け入れるかどうかを決定します。変更が受け入れられた場合、最初のMIDCOMエージェントに通知される場合があります。
Appendix D - Diameter IPFilter Rule
付録D-直径IPFilterルール
The IPFilterRule format is derived from the OctetString AVP Base Format. It uses the UTF-8 encoding and has the same requirements as the UTF8String. Packets may be filtered based on the following information that is associated with it:
IPFilTerrule形式は、OctetString AVPベース形式から派生しています。UTF-8エンコーディングを使用し、UTF8Stringと同じ要件を持っています。パケットは、それに関連付けられている以下の情報に基づいてフィルタリングされる場合があります。
Direction (in or out) Source and destination IP address (possibly masked) Protocol Source and destination port (lists or ranges) TCP flags IP fragment flag IP options ICMP types
方向（インまたはアウト）ソースおよび宛先IPアドレス（おそらくマスクされた）プロトコルソースと宛先ポート（リストまたは範囲）TCPフラグIPフラグメントフラグIPオプションICMPタイプ
Rules for the appropriate direction are evaluated in order, with the first matched rule terminating the evaluation. Each packet is evaluated once. If no rule matches, the packet is dropped if the last rule evaluated was a permit, and passed if the last rule was a deny.
適切な方向のルールは順番に評価され、最初の一致したルールが評価を終了します。各パケットは一度評価されます。ルールが一致しない場合、評価された最後のルールが許可である場合、パケットが削除され、最後のルールが拒否された場合に合格します。
IPFilterRule filters MUST follow the format:
IPFILTERRULEフィルターは、次の形式に従う必要があります。
action dir proto from src to dst [options]
SRCからDSTへのアクションディルプロト[オプション]
action permit - Allow packets that match the rule. deny - Drop packets that match the rule.
アクション許可 - ルールに一致するパケットを許可します。拒否 - ルールに一致するパケットをドロップします。
dir "in" is from the terminal, "out" is to the terminal.
dir "in"はターミナルから、「out」は端末にあります。
proto An IP protocol specified by number. The "ip" keyword means any protocol will match.
Proto番号で指定されたIPプロトコル。「IP」キーワードは、すべてのプロトコルが一致することを意味します。
src and dst <address/mask> [ports]
SRCおよびDST <アドレス/マスク> [ポート]
The <address/mask> may be specified as:
<アドレス/マスク>は次のように指定できます。
ipno An IPv4 or IPv6 number in dotted-quad or canonical IPv6 form. Only this exact IP number will match the rule.
点線または正規のIPv6形式のIPNO AN IPv4またはIPv6番号。この正確なIP番号のみがルールと一致します。
ipno/bits An IP number as above with a mask width of the form 1.2.3.4/24. In this case, all IP numbers from 1.2.3.0 to 1.2.3.255 will match. The bit width MUST be valid for the IP version and the IP number MUST NOT have bits set beyond the mask.
IPNO/は、フォーム1.2.3.4/24のマスク幅を使用して、上記のようにIP番号をビットします。この場合、1.2.3.0から1.2.3.255のすべてのIP番号が一致します。ビット幅はIPバージョンで有効でなければならず、IP番号にマスクを超えてビットが設定されてはなりません。
For a match to occur, the same IP version must be present in the packet that was used in describing the IP address. To test for a particular IP version, the bits part can be set to zero. The keyword "any" is 0.0.0.0/0 or the IPv6 equivalent. The keyword "assigned" is the address or set of addresses assigned to the terminal. For IPv4, a typical first rule is often "deny in ip! assigned"
一致するには、IPアドレスの説明に使用されたパケットに同じIPバージョンが存在する必要があります。特定のIPバージョンをテストするには、ビットパーツをゼロに設定できます。キーワード「ANY」は0.0.0.0/0またはIPv6等価です。「割り当てられた」キーワードは、ターミナルに割り当てられたアドレスまたはアドレスのセットです。IPv4の場合、典型的な最初のルールは、多くの場合「IPで拒否します！割り当て」です。
The sense of the match can be inverted by preceding an address with the not modifier (!), causing all other addresses to be matched instead. This does not affect the selection of port numbers.
一致の感覚は、NOT Modifier（！）を使用してアドレスの前に反転することができ、代わりに他のすべてのアドレスが一致します。これは、ポート番号の選択には影響しません。
With the TCP, UDP and SCTP protocols, optional ports may be specified as:
TCP、UDP、およびSCTPプロトコルを使用すると、オプションのポートを次のように指定できます。
{port|port-port}[,ports[,...]]
{port | port-port} [、ports [、...]]
The '-' notation specifies a range of ports (including boundaries).
「 - 」表記は、さまざまなポート（境界を含む）を指定します。
Fragmented packets that have a non-zero offset (i.e., not the first fragment) will never match a rule that has one or more port specifications. See the frag option for details on matching fragmented packets.
ゼロ以外のオフセット（つまり、最初のフラグメントではない）を持つ断片化されたパケットは、1つ以上のポート仕様を持つルールと一致することはありません。断片化されたパケットの一致の詳細については、fragオプションを参照してください。
options:
オプション：
frag Match if the packet is a fragment and this is not the first fragment of the datagram. frag may not be used in conjunction with either tcpflags or TCP/UDP port specifications.
断片は、パケットがフラグメントであり、これがデータグラムの最初のフラグメントではない場合に一致します。フラグは、TCPFLAGSまたはTCP/UDPポート仕様のいずれかと組み合わせて使用できません。
ipoptions spec Match if the IP header contains the comma separated list of options specified in spec. The supported IP options are:
IPOPTIONS SPEC一致IPヘッダーに、仕様で指定されたオプションのコンマ分離リストが含まれている場合。サポートされているIPオプションは次のとおりです。
ssrr (strict source route), lsrr (loose source route), rr (record packet route) and ts (timestamp). The absence of a particular option may be denoted with a '!'.
SSRR（Strict Source Route）、LSRR（ルーズソースルート）、RR（レコードパケットルート）、TS（タイムスタンプ）。特定のオプションがないことは、「！」で示される場合があります。
tcpoptions spec Match if the TCP header contains the comma separated list of options specified in spec. The supported TCP options are:
TCPPOPTIONS SPECマッチTCPヘッダーに、仕様で指定されたオプションのコンマ分離リストが含まれている場合。サポートされているTCPオプションは次のとおりです。
mss (maximum segment size), window (tcp window advertisement), sack (selective ack), ts (rfc1323 timestamp) and cc (rfc1644 t/tcp connection count). The absence of a particular option may be denoted with a '!'.
MSS（最大セグメントサイズ）、ウィンドウ（TCPウィンドウ広告）、サック（選択的ACK）、TS（RFC1323タイムスタンプ）、CC（RFC1644 T/TCP接続カウント）。特定のオプションがないことは、「！」で示される場合があります。
established TCP packets only. Match packets that have the RST or ACK bits set.
確立されたTCPパケットのみ。RSTまたはACKビットが設定されているパケットを一致させます。
setup TCP packets only. Match packets that have the SYN bit set but no ACK bit.
TCPパケットのみをセットアップします。synビットが設定されているが、ackビットがないマッチパケット。
tcpflags spec TCP packets only. Match if the TCP header contains the comma separated list of flags specified in spec. The supported TCP flags are:
TCPFLAGS SPEC TCPパケットのみ。TCPヘッダーに、仕様で指定されたフラグのコンマ分離リストが含まれている場合に一致します。サポートされているTCPフラグは次のとおりです。
fin, syn, rst, psh, ack and urg. The absence of a particular flag may be denoted with a '!'. A rule that contains a tcpflags specification can never match a fragmented packet that has a non-zero offset. See the frag option for details on matching fragmented packets.
Fin、syn、rst、psh、ack、urg。特定のフラグがないことは、「！」で示される場合があります。TCPFLAGS仕様を含むルールは、ゼロ以外のオフセットを持つ断片化されたパケットと一致することはありません。断片化されたパケットの一致の詳細については、fragオプションを参照してください。
icmptypes types ICMP packets only. Match if the ICMP type is in the list types. The list may be specified as any combination of ranges or individual types separated by commas. Both the numeric values and the symbolic values listed below can be used. The supported ICMP types are:
icmptypesタイプICMPパケットのみ。ICMPタイプがリストタイプにある場合に一致します。このリストは、範囲またはコンマで区切られた個々のタイプの任意の組み合わせとして指定される場合があります。以下にリストされている数値値とシンボリック値の両方を使用できます。サポートされているICMPタイプは次のとおりです。
echo reply (0), destination unreachable (3), source quench (4), redirect (5), echo request (8), router advertisement (9), router solicitation (10), time-to-live exceeded (11), IP header bad (12), timestamp request (13), timestamp reply (14), information request (15), information reply (16), address mask request (17) and address mask reply (18).
Echo Reply（0）、Destination Unerachable（3）、Source Quench（4）、Redirect（5）、Echo Request（8）、Router Advertisement（9）、Router Salicitation（10）、Time-to-Live（11）、、IPヘッダーバッド（12）、タイムスタンプリクエスト（13）、タイムスタンプの返信（14）、情報リクエスト（15）、情報返信（16）、アドレスマスク要求（17）、アドレスマスク応答（18）。
There is one kind of packet that the access device MUST always discard, that is an IP fragment with a fragment offset of one. This is a valid packet, but it only has one use, to try to circumvent firewalls.
アクセスデバイスが常に破棄する必要があるパケットの種類が1つあります。これは、フラグメントオフセットを持つIPフラグメントです。これは有効なパケットですが、ファイアウォールを回避しようとするための1つの使用しかありません。
An access device that is unable to interpret or apply a deny rule MUST terminate the session. An access device that is unable to interpret or apply a permit rule MAY apply a more restrictive rule. An access device MAY apply deny rules of its own before the supplied rules, for example to protect the access device owner's infrastructure.
拒否ルールを解釈または適用できないアクセスデバイスは、セッションを終了する必要があります。許可ルールを解釈または適用できないアクセスデバイスは、より制限的なルールを適用する場合があります。アクセスデバイスは、アクセスデバイスの所有者のインフラストラクチャを保護するために、提供されるルールの前に独自の拒否ルールを適用する場合があります。
The rule syntax is a modified subset of ipfw(8) from FreeBSD, and the ipfw.c code may provide a useful base for implementations.
ルール構文は、FreeBSDのIPFW（8）の修正されたサブセットであり、IPFW.Cコードは実装に有用なベースを提供する場合があります。
Contributors
貢献者
The following identifies the key contributors who provided the primary content for this document in the form of individual documents for each protocol:
以下は、各プロトコルの個々のドキュメントの形でこのドキュメントの主要なコンテンツを提供した主要な貢献者を識別します。
RSIP:
rsip：
Jim Renkel
ジム・レンケル
SNMP:
SNMP：
Juergen Quittek NEC Europe Ltd. EMail: quittek@ccrle.nec.de David Harrington Co-chair SNMPv3 WG EMail: dbh@enterasys.com
Juergen Quittek Nec Europe Ltd.メール：quittek@ccrle.nec.de David Harrington共同議長snmpv3 wgメール：dbh@enterasys.com
Megaco:
メガコ：
Sanjoy Sen
サンジョイ・セン
Cedric Aoun Nortel EMail: cedric.aoun@nortel.com
セドリックaoun nortelメール：cedric.aoun@nortel.com
Tom Taylor Nortel EMail: taylor@nortel.com
Tom Taylor Nortelメール：taylor@nortel.com
Diameter:
直径：
Tom Taylor Nortel EMail: taylor@nortel.com
Tom Taylor Nortelメール：taylor@nortel.com
COPS:
警官：
Cedric Aoun Nortel EMail: cedric.aoun@nortel.com
セドリックaoun nortelメール：cedric.aoun@nortel.com
Kwok-Ho Chan Nortel EMail: khchan@nortel.com
kwok-ho chan nortelメール：khchan@nortel.com
Louis-Nicolas Hamer
ルイ・ニコラス・ハマー
Reinaldo Penno EMail: rpenno@juniper.net
Reinaldo Pennoメール：rpenno@juniper.net
Sanjoy Sen
サンジョイ・セン
Author's Address
著者の連絡先
Mary Barnes Nortel 2201 Lakeside Blvd. Richardson, TX USA
メアリーバーンズノーテル2201 Lakeside Blvd.テキサス州リチャードソン
Phone: 1-972-684-5432 EMail: mary.barnes@nortel.com
電話：1-972-684-5432メール：mary.barnes@nortel.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 gement
RFCエディター関数の資金は現在、インターネットゲメントによって提供されています