RFC4097 日本語訳
4097 Middlebox Communications (MIDCOM) Protocol Evaluation. M. Barnes,Ed.. June 2005. (Format: TXT=99303 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Barnes, Ed. Request for Comments: 4097 Nortel Networks Category: Informational June 2005
ワーキンググループのM.バーンズ、エドをネットワークでつないでください。コメントのために以下を要求してください。 4097 ノーテルはカテゴリをネットワークでつなぎます: 情報の2005年6月
Middlebox Communications (MIDCOM) Protocol Evaluation
Middleboxコミュニケーション(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)インターネット協会(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.
MIDCOM(Middlebox Communications)が議定書を作るとき、このドキュメントはSNMP(簡単なNetwork Managementプロトコル)、RSIP(分野Specificインターネットプロトコル)、Megaco、Diameter、およびCOPS(一般的なオープンPolicy Service)の適用性の評価を提供します。 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
概要… 本書では使用される2つのコンベンション… 3 1. 提案について議定書の中で述べてください… 3 1.1. SNMP… 3 1.2. RSIP… 5 1.3. Megaco… 7 1.4. 直径… 8 1.5. 巡査… 10 2. 項目レベル承諾評価… 11 2.1. 機械について議定書の中で述べてください… 11 2.2. 意味論について議定書の中で述べてください… 20 2.3. 総合証券要件… 27 3. 結論… 29 4. セキュリティ問題… 30 5. 参照… 31 5.1. 標準の参照… 31 5.2. 有益な参照… 33 6. 承認… 33
Barnes Informational [Page 1] RFC 4097 MIDCOM Protocol Evaluation June 2005
バーンズ情報[1ページ]のRFC4097MIDCOMは評価2005年6月に議定書を作ります。
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
付録A--SNMP概要… 34付録B--、トンネリングがあるRSIP… 35 付録C--Megacoモデル化法… 37 付録D--直径IPFilterは統治します… 39人の貢献者… 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.
MIDCOM(Middlebox Communications)が議定書を作るとき、このドキュメントはSNMP(簡単なNetwork Managementプロトコル)、RSIP(分野Specificインターネットプロトコル)、Megaco、Diameter、およびCOPS(一般的なオープンPolicy Service)の適用性の評価を提供します。 この評価は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はプロトコル評価の目的のためにあいさつがあるプロトコルに関する何らかの基礎的な情報、類似性、および違いで[2]が提供したフレームワークへの適用性に提出された提案されたプロトコルのリストを含みます。
Section 2 provides the item level evaluation of the proposed protocols against the Requirements [1].
セクション2はRequirements[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は評価の概要を提供します。 以下のカテゴリを提供するのであいさつでそれぞれのプロトコルのための数字の故障を要件への適用性に含むテーブル: 完全に会われます、Partiallyは会われるために拡張子の使用、他の変化でプロトコルに会われたPartially、またはFailingを通して会いました。 プロトコルの適合の決定的な声明を提供することが意味されるのではなく、この概要は、むしろ考えられるために総合的なプロトコル決定プロセスに入力されるように情報を提供するために意味されます。
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フレームワークと要件に従うためにプロトコルの増進と応用を記録する提案の基礎的な情報と、より詳細な局面のいくつかがAppendicesに含まれています。
Barnes Informational [Page 2] RFC 4097 MIDCOM Protocol Evaluation June 2005
バーンズ情報[2ページ]のRFC4097MIDCOMは評価2005年6月に議定書を作ります。
Conventions Used in this Document
このDocumentのコンベンションUsed
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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[4])で説明されるように本書では解釈されることであるべきです。
1. Protocol Proposals
1. プロトコル提案
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 Diameter o COPS
The following provides an overview of each of the protocols and the applicability of each protocol to the MIDCOM framework.
以下はそれぞれのプロトコルとそれぞれのプロトコルの適用性の概要をMIDCOMフレームワークに提供します。
1.1. SNMP
1.1. SNMP
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の概要といくつかの特定の細部はAppendix A.Thisでは、SNMPの評価がSNMPv3に特定であるかどうかということです。(SNMPv3はMIDCOM用法に必要であるセキュリティを提供します)。 MIDCOMに、それらがHistoricであると宣言されて、それらのメッセージに些細なセキュリティしかないのでSNMPv1とSNMPv2cは不適当でしょう。 NATとFirewall Controlの既存のサポートへの尊敬があるいくつかの詳細をセクション1.1.2に提供します。 SNMPフレームワークとMIDCOMフレームワークの違いはセクション1.1.3で扱われます。
1.1.1. SNMP General Applicability
1.1.1. SNMPの一般適用性
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メッセージング・プロトコルは標準化された形式でデータを輸送します。 コミュニケーションの終点はデータの意味論を理解しています。
Barnes Informational [Page 3] RFC 4097 MIDCOM Protocol Evaluation June 2005
バーンズ情報[3ページ]のRFC4097MIDCOMは評価2005年6月に議定書を作ります。
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)の分離を共有するので、SNMPv3と共にすべての既存のMIBsを使用できます。 また、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はすべてのSNMP実体が、ある機能を実行できるRFC3411[5]で詳細なアーキテクチャを使用します、要求の世代などのように、要求への応答、非同期な通知の世代、通知の受領、およびSNMPのプロキシ推進メッセージ。 SNMPは、管理されたアプリケーション詳細の操作上のパラメタとMIBモジュールで定義される統計の仮想のデータベースを読んで、操るのに使用されます。
1.1.2. SNMP Existing Support for NAT and Firewall Control
1.1.2. NATのSNMPの既存のサポートとファイアウォールコントロール
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.
NATsを構成するのにおいて、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の開発に向かって必要です。
1.1.3. Architectural Differences between SNMP and MIDCOM
1.1.3. SNMPとMIDCOMの建築違い
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
伝統的に、SNMP実体はマネージャとエージェントと呼ばれました。 実体がSNMPv3機能の特定の構成をサポートに設計したので、マネージャとエージェントは現在、見分けられます。 伝統的なマネージャ
Barnes Informational [Page 4] RFC 4097 MIDCOM Protocol Evaluation June 2005
バーンズ情報[4ページ]のRFC4097MIDCOMは評価2005年6月に議定書を作ります。
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使用はMIDCOMフレームワークにおける使用と異なっています: SNMPマネージャはMIDCOMエージェントに文通します、そして、SNMPエージェントはMIDCOM PDPに文通します。 SNMP評価は、MIDCOM PDP(SNMPエージェント)が[2]のセクション6.0で説明されるようにMIDCOMフレームワークによって許容されているmiddleboxを物理的に離れさせることであると仮定します。 したがって、この評価の目的のために、SNMPエージェントはMiddleboxに文通します。
While this evaluation is based on the assumption that the SNMP agent corresponds to the middlebox, SNMP does not force such a restriction.
この評価がSNMPエージェントがmiddleboxに文通するという仮定に基づいている間、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.
プロキシは多くのものを多くの人々に言っています。 メッセージを転送するか、またはmiddleboxに方針を分配するのを助けるのに中間的実体を使用することでSNMPを配布することができます、他の候補プロトコルのプロキシ能力と同様です。 プロキシは指定されたMIDCOM必要条件を満たしに構成と展開の複雑さを加えて、必要でないので、プロキシエージェントか中間レベルのマネージャの使用はこの評価で考えられません。 SNMPプロキシ能力に関する詳細をAppendix 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エージェントからMiddleboxまでの要求は実行された使用がMIDCOM MIBモジュールで定義された管理オブジェクトへのアクセスを書くということでしょう。 Middlebox(SNMPエージェント)、管理オブジェクトを変更することによって、要求に関する回答は合図されます。 MIDCOMエージェント(SNMPマネージャ)は、必要なら、対応する管理オブジェクトに読むか、または投票することによって、この情報を受け取ることができます。
1.2. RSIP
1.2. RSIP
The RSIP framework and detailed protocol are defined in RFC 3102 [17] and RFC 3103 [18] respectively.
RSIPフレームワークと詳細なプロトコルはRFC3102[17]とRFC3103[18]でそれぞれ定義されます。
1.2.1. Framework Elements in Common to MIDCOM and RSIP
1.2.1. MIDCOMとRSIPに共通のフレームワーク要素
The following framework elements are common to MIDCOM and RSIP listed by their MIDCOM names, with the RSIP name indicated in parenthesis:
以下のフレームワーク要素はそれらのMIDCOM名によって記載されたMIDCOMとRSIPに共通です、RSIP名が挿入句で示されている状態で:
o Hosts o Applications o Middleboxes (RSIP gateways) o Private domain (private realm)
o o Applications o Middleboxes(RSIPゲートウェイ)o兵士のドメインを接待します。(私設の分野)
Barnes Informational [Page 5] RFC 4097 MIDCOM Protocol Evaluation June 2005
バーンズ情報[5ページ]のRFC4097MIDCOMは評価2005年6月に議定書を作ります。
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 Middlebox通信プロトコル(RSIP)o MIDCOMエージェント登録(ホスト登録)o MIDCOMセッション(RSIPセッション)o MIDCOM Filter(地元の、または、リモートなアドレスとポートナンバー組)
1.2.2. MIDCOM Framework Elements Not Supported by RSIP
1.2.2. RSIPによって支えられなかった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をサポートするために、より一般的で明白な動作パラメタは定義されなければならないでしょう。 地方の、または、リモートなアドレスを指定するRSIP要求とポートナンバー組は動作パラメタを含むように広げられなければならないでしょう、MIDCOM規則で。
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は、middleboxesがそれらにおいて知られている方針に関して要求を承諾するか、または否定すると仮定します。 方針はmiddleboxと政策決定ポイントで共同で決定できました。 そのような共同決断はRSIPフレームワークによって扱われません、そして、それは明確に排除されません。
1.2.3. RSIP Framework Elements Not Supported by MIDCOM
1.2.3. MIDCOMによって支えられなかった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 逆多重化分野: RSIPゲートウェイが入って来るパケットをRSIPホストに発送するのに使用するどんなセットのパケットのヘッダーかペイロード分野。 RSIPは実行するゲートウェイ、およびアプリケーションを制御させます、IPヘッダーフィールド以上に基づく個人的なドメインのホストへのパケットルーティング。
Barnes Informational [Page 6] RFC 4097 MIDCOM Protocol Evaluation June 2005
バーンズ情報[6ページ]のRFC4097MIDCOMは評価2005年6月に議定書を作ります。
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 ホストからmiddleboxはトンネルを堀ります: RSIPは、個人的な分野ホストと公共部門のホストの間で伝えられたデータが私設の分野を通って内側のホストと中央箱の間のトンネルによって移されると仮定します、それが変えられるところと固有のIPベースのコミュニケーションから公共部門のホストまで。
1.2.4. Comparison of MIDCOM and RSIP Frameworks
1.2.4. MIDCOMと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、SMILなどに必要ではありません。 しかしながら、これは、RSIPサーバとトンネリングプロトコルが実装しているコネが個人的な分野ホストであったならmiddlebox、RSIPクライアント、およびトンネリングプロトコルで実装されるのを必要とします。 一般に、ホスト変更は、ホストアプリケーションへの変更なしで作られているか、またはホストアプリケーションエージェントの実装を必要とすることができます。 これはNAT(ネットワークAddress Translation)より重要な利点として見なされます。
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の評価に関する詳細はこのドキュメントのAppendix Bで利用可能です。
1.3. Megaco
1.3. Megaco
1.3.1. Megaco Architectural Model
1.3.1. Megacoの建築モデル
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はマスター奴隷(メディアゲートウェイControllers(MGC)がメディアGateways(MG)の操作を制御するRFC3015[20]で定義されたトランザクション指向のプロトコル)です。 元々、IP Telephonyゲートウェイを制御するように設計されています、それは、アプリケーション認識を持ちながら、アプリケーション気づかないデバイス(メディアゲートウェイ)と知的な実体(メディアゲートウェイController)の間で使用されます。
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. 終了: パケットストリーム終了のソースか流し台が物理的であるか、またははかない場合があり、独身のMGCに関連しているとき行動するMGの上の論理的な実体。
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. 文脈: Terminationsの間のメディアを共有するためのTerminationsの間の協会。 終了を加えることができて、Contextから引き算されて、1Contextから別のContextまで動かすことができます。 TerminationsのContextとすべてが独身のMGCに関連しています。
Barnes Informational [Page 7] RFC 4097 MIDCOM Protocol Evaluation June 2005
バーンズ情報[7ページ]のRFC4097MIDCOMは評価2005年6月に議定書を作ります。
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による複数の仮想のMGsに仕切られて、複数のControllersを許容すると対話するContexts/終了のセットが単一のフィジカル・デバイスの中でばらばらになるということであることができます。
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コマンドは、Contextの中の1Terminationに当てはまって、ユニークな応答を生成します。 コマンドは、Termination識別子をwildcardingすることで与えられたContextのすべてのTerminationsに影響するように、それとなく模写されるかもしれません。 Transaction構造で異なったContextsに扱われた複数のコマンドは分類できます。 同様に、複数のTransactionsをMessageに連結できます。
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. 記述子/特性: Terminationはコマンドと応答に含まれているDescriptorsの1セットで分類されるパラメタかPropertiesを特徴付ける数によって説明されます。
6. Events and signals: A Termination can be programmed to perform
certain actions or to detect certain events and notify the Agent.
6. イベントと信号: ある動作を実行するか、あるイベントを検出して、またはTerminationがエージェントに通知するようにプログラムできます。
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. パッケージ: パッケージは特性、Terminationに関連しているイベントなどのグループです。 パッケージは、プロトコルを広げていると様々なタイプのデバイスが役立つ簡潔な方法かMiddleboxesです。
1.3.2. Comparison of the Megaco and MIDCOM Architectural Frameworks
1.3.2. MegacoとMIDCOMの建築フレームワークの比較
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アーキテクチャでは、メディアゲートウェイコントローラはMIDCOMエージェント(MA)と同様の役割を受けます、そして、メディアゲートウェイはMiddlebox(MB)と同様の役割を受けます。 MegacoモデルとMIDCOMプロトコル要件の1つの主要な違いはMIDCOMが、MIDCOMエージェントがセッションを確立するのを必要とするということです。 ところが、Megaco定義はMG(Middlebox)がMGC(MIDCOMエージェント)とのコミュニケーションを確立するということです。
1.4. Diameter
1.4. 直径
1.4.1. Diameter Architecture
1.4.1. 直径アーキテクチャ
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
直径は、ネットワークアクセサリーのためにAAAをサポートするように設計されています。 それはDiameterノードのネットワークを通して作動することになっています。ネットワークは、ともにそれらの最終的な目的地に向かってメッセージに作用して、発送します。 終点はクライアントかサーバのどちらかとして特徴付けられます。(そのクライアントは、ネットワークアクセスコントロールを実行します)。(サーバは特定の分野を求める認証、承認、および会計要求を扱います)。 中間的ノードはプロキシの、そして、再直接のリレー、および翻訳、通訳のサービスを実行します。 デザイン
Barnes Informational [Page 8] RFC 4097 MIDCOM Protocol Evaluation June 2005
バーンズ情報[8ページ]のRFC4097MIDCOMは評価2005年6月に議定書を作ります。
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.
プロトコルのための要件はburstyメッセージ荷重、サーバ失敗、特定の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.
すべての実装、および拡大でサポートされるRFC3588[24]のベースプロトコルが特定のアプリケーションに注がれたようにプロトコルは設計されています。 メッセージは「属性値ペア(AVPs)」のヘッダーと集合から成ります。それはそれぞれタグ長さの価値の構造物です。 ヘッダーはコマンドコードを入れます。(それは、メッセージと他のAVPがタイプするものに関する処理が存在しなければならないか、または存在しているかもしれないことを決定します)。 AVPsは強くタイプされます。 ベースプロトコル仕様で何人かの基本的、そして、合成タイプを提供しますが、アプリケーション拡大で他のものを加えるかもしれません。 ベースに提供されたタイプのひとりはIPFilterRuleです。(そのIPFilterRuleはMIDCOMが対処するPolicy Rulesを急送できるかもしれません)。
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.
メッセージングは要求答え交換の形を取ります。 いくつかの交換が終了する複数の周遊旅行を取るかもしれません。 プロトコルは輸送とアプリケーションレベルの両方で接続指向です。 さらに、プロトコルは密接にセッションの考えに結ばれます。(セッションは一般的なセッション識別子の使用で交換処理の系列を関係づけます)。 各アプリケーションはそれ自身のセッションの意味論の定義を提供します。 複数のセッションが同時に、開いているかもしれません。
1.4.2. Comparison of Diameter With MIDCOM Architectural Requirements
1.4.2. MIDCOMの建築要件との直径の比較
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エージェントはDiameterクライアントの機能を実行しません、そして、MiddleboxはDiameterサーバの機能をサポートしません。その結果、MIDCOMアプリケーションは2つの新しいタイプの終点をDiameterアーキテクチャに取り入れるでしょう。 そのうえ、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.
総合課税がDiameterがMIDCOMの建築必要条件を満たして、超えているということであるかもしれない、しかしながら、Middleboxがサポートしなければならない関係の数には、接続オリエンテーションは重過ぎるかもしれません。 確かに、伸展性の焦点、オリエンテーションを通信させる要求応答、およびセッションの処理はすべてがMIDCOMが必要とするものによく合っていたということです。 ここにMIDCOMが簡単な二地点間関係に焦点を合わせられるので、Diameterによって提供されたproxyingと推進能力は必要ではありません。 また、ベースプロトコルで定義されたコマンドとAVPsの大部分もMIDCOM要件に余剰です。
Barnes Informational [Page 9] RFC 4097 MIDCOM Protocol Evaluation June 2005
バーンズ情報[9ページ]のRFC4097MIDCOMは評価2005年6月に議定書を作ります。
1.5. COPS
1.5. 巡査
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.
全体的に見て、RFC2748[25]で定義されたCOPSとRFC3084[26]で定義されたCOPS-PRはMIDCOMプロトコル要件にあいさつによる同様のコンプライアンスを持っています。 一般に、本書では、COPSの参照はCOPSとCOPS-PRの両方に適切です。 しかしながら、COPS-PRは、2つの要件に会うために明らかに特定されます。 COPS-PRとCOPSのMIDCOMプロトコルに適用される他の唯一の主要な違いがCOPS MIDCOMのクライアントの特定のオブジェクトよりむしろCOPS-PR MIDCOM PIB属性があるMIDCOM政策ルール属性の記述でしょう。
1.5.1. COPS Protocol Architecture
1.5.1. 巡査はアーキテクチャについて議定書の中で述べます。
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は方針サーバ(方針Decision PointかPDP)とそのクライアント(方針Enforcement PointsかPEPs)の間の為替政策情報に使用できる簡単な質問と応答プロトコルです。 COPSは、簡単で広げることができるプロトコルになるように定義されました。 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はメッセージレベルセキュリティを認証、反復操作による保護、およびメッセージの保全に提供します。 COPSはPEPとPDPの間でIPSEC[22]などのセキュリティのためのプロトコルに存在することの使用を作るか、または認証して、機密保護するTLS[21]をチャンネルに作ることができます。
6. The protocol is stateful in two main aspects:
6. プロトコルは2つの主な局面でstatefulです:
(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からのDecisionsを非同期に生成することができます。
Barnes Informational [Page 10] RFC 4097 MIDCOM Protocol Evaluation June 2005
バーンズ情報[10ページ]のRFC4097MIDCOMは評価2005年6月に議定書を作ります。
(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) 様々なイベント(要求/決定組)からの状態は相互関連しているかもしれません。 サーバは以前に、インストールされて、関連するRequest/決定状態のために新しい質問に異なって反応するかもしれません。
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. プロトコルは、また、サーバがそれでクライアントに設定情報を押すことができるのでstatefulで、それがもう適切でないときに、次に、サーバがクライアントからそのような状態を取り除くのを許容します。
1.5.2. Comparison of COPS and the MIDCOM Framework
1.5.2. 巡査の比較とMIDCOMフレームワーク
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 Client)とMIDCOMエージェントがPDP(COPS Policy Server)として勤めて、Middleboxは役立ちます。 COPSプロトコルモデルとMIDCOMプロトコル要件の1つの主要な違いはMIDCOMが、MIDCOMエージェントがセッションを確立するのを必要とするということです。 ところが、COPS定義はPEP(Middlebox)がPDP(MIDCOMエージェント)とのコミュニケーションを確立するということです。
2. Item Level Compliance Evaluation
2. 項目レベル承諾評価
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 Requirements[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+部分的なCompliance+基本的に、拡張子(例えば、パッケージ、追加パラメタなど)の使用で、条件を満たします。
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は失敗した承諾と等しいです。 条件を満たしません。
2.1. Protocol Machinery
2.1. プロトコル機械
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からのプロトコル機械要件に対して提案されたプロトコルのコンプライアンスについて説明します。 評価を実体化するためにそれぞれのプロトコルの短い記述を提供します。
Barnes Informational [Page 11] RFC 4097 MIDCOM Protocol Evaluation June 2005
バーンズ情報[11ページ]のRFC4097MIDCOMは評価2005年6月に議定書を作ります。
2.1.1. Ability to Establish Association Between Agent and Middlebox.
2.1.1. エージェントとMiddleboxとの仲間を設立する能力。
SNMP: T, RSIP: P+, Megaco: P, Diameter: T, COPS: P
SNMP: T、RSIP: P+、Megaco: P、直径: T、巡査: 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は、セッションがmiddleboxesと、アプリケーションと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.
直径: 範囲の外にこれはありますが、Diameter仕様は同輩を発見するいくつかの方法を述べます。 そうしたので、Diameterノードは輸送接続(TCP、TLS、またはSCTP)を同輩に確立します。 2人の同輩が、次に、互いを特定するCapability Exchange Request/答えメッセージを交換して、それぞれがサポートするDiameterアプリケーションを決定します。
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人の同輩の間の接続が迷子になるなら、Diameterはそれが復職するかもしれない手順を定めます。 接続性の損失がすぐに検出されるのを保証するなら、Diameterは、2人の同輩の間のトラフィックが低いときに、使用されるためにDevice-番犬Request/答えメッセージを提供します。
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
巡査: COPSは要件の方向性部分を達成しません。 COPSの定義で、PEP(Middlebox)はPDP(MIDCOMエージェント)とのコミュニケーションを確立できます。 しかしながら、何もコミュニケーションを確立するのからPDPを明らかに禁じません。
Barnes Informational [Page 12] RFC 4097 MIDCOM Protocol Evaluation June 2005
バーンズ情報[12ページ]のRFC4097MIDCOMは評価2005年6月に議定書を作ります。
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.
気力で。 PEPはそれが未知のPDPによって連絡されるときどんな行動を取ったらよいかを決めるローカルの方針を持つことができました。 ローカルの方針で定義されたこれらの動作は認可された協会の適切な設立を確実にするでしょう。
2.1.2. Agent Can Relate to Multiple Middleboxes
2.1.2. エージェントは複数のMiddleboxesに関連する場合があります。
SNMP: T, RSIP: P, Megaco: T, Diameter: T, COPS: T
SNMP: T、RSIP: P、Megaco: T、直径: T、巡査: T
SNMP: An SNMP manager can communicate simultaneously with several
Middleboxes.
SNMP: SNMPマネージャは同時に、数個のMiddleboxesとコミュニケートできます。
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に数個のMiddleboxesを制御させます。 各メッセージは受取人がソースを決心できるメッセージを送った終点に関する識別子を運びます。
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.
直径: 直径は接続を1人以上の同輩(そして、改良された信頼性のためにこれを奨励する)まで許します。 Diameter接続州のマシンがポートの数が必要としたサポートに重過ぎるかどうかが、議論のための問題です。
COPS: COPS PDPs are designed to communicate with several PEPs.
巡査: COPS PDPsは、数個のPEPsとコミュニケートするように設計されています。
2.1.3. Middlebox Can Relate to Multiple Agents
2.1.3. Middleboxは複数のエージェントに関連する場合があります。
SNMP: T, RSIP: P, Megaco: T, Diameter: T, COPS: T
SNMP: T、RSIP: P、Megaco: T、直径: T、巡査: T
SNMP: An SNMP agent can communicate with several SNMP managers
Simultaneously.
SNMP: SNMPエージェントは数個SNMPマネージャSimultaneouslyとコミュニケートできます。
RSIP: Refer to 2.1.2.
RSIP: .2に2.1を参照してください。
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には、複数のMGCsが同時に同じMGとコミュニケートするのを許容して、VirtualメディアGateways(VMG)の概念があります。 このモデルをMIDCOMに適用するのに、同じmiddlebox(MG)は複数のMIDCOMエージェント(MGCs)との仲間を持つことができるでしょう。
Barnes Informational [Page 13] RFC 4097 MIDCOM Protocol Evaluation June 2005
バーンズ情報[13ページ]のRFC4097MIDCOMは評価2005年6月に議定書を作ります。
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.
直径: 直径は、接続を1人以上の同輩まで許して、改良された信頼性のためにこれを奨励します。 Diameter接続州のマシンがポートの数が必要としたサポートに重過ぎるかどうかが、議論のための問題です。 Diameterのじっと見るのに関する限り、Middleboxとエージェントは左右対称の役割を果たします。
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-PRフレームワークは、PEPにはユニークなPDPが有効な政策コントロールを達成するためにあるはずであると指定します。 COPS-PRプロトコルはPEPが1PDPあたり1つのCOPSクライアントインスタンスを作成することによって複数のPDPsとのコミュニケーションを確立するシナリオを許容するでしょう。
2.1.4. Deterministic Outcome When Multiple Requests are Presented to
the Middlebox Simultaneously
2.1.4. 決定論的なOutcome When Multiple RequestsはMiddlebox SimultaneouslyへのPresentedです。
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: T、RSIP: T、Megaco: T、直径: T、巡査: 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は、これらの相互作用を決定論的にして、リソースアクセス闘争を避けるためにVMGsの概念をサポートします。 各VMGには、独身の所有者がMGCにいます、そして、複数のVMGsに属すTerminationsのセットの間には、オーバラップが全くあるはずがありません。 また、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).
直径: サーバが大いにロードされるようになるとき、直径は、フロー制御を提供するために一部トランスポート・プロトコルに依存します。 それがまた、応用層をそれが忙し過ぎるのを示すために通信させるか、またはスペースからそうする、(直径、も_BUSYとDiameter_OUT_OF_SPACE結果コード)
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州のマシンの作成を許容するでしょう。
Barnes Informational [Page 14] RFC 4097 MIDCOM Protocol Evaluation June 2005
バーンズ情報[14ページ]のRFC4097MIDCOMは評価2005年6月に議定書を作ります。
2.1.5. Known and Stable State
2.1.5. 知られていて安定した状態
SNMP: T, RSIP: T, Megaco: T, Diameter: P, COPS: T
SNMP: T、RSIP: T、Megaco: T、直径: P、巡査: 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: middleboxにセッションを全く立ち上げない、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プロトコルはMiddleboxesとMAの間の連動している州を維持します、したがって、すべての州が両側で知られています。
2.1.6. Middlebox Status Report
2.1.6. Middlebox現状報告
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: T、RSIP: T、Megaco: T、直径: T、巡査: T
SNMP: The status of a middlebox can be reported using asynchronous
communications, or via polling.
SNMP: middleboxの状態が非同期通信を使用することで報告されるか、または世論調査でいることができます。
RSIP: All RSIP client requests have explicit server responses.
Additionally, a client may explicitly request server status using
a QUERY request.
RSIP: すべてのRSIPクライアント要求には、明白なサーバ応答があります。 さらに、クライアントは、QUERY要求を使用することで明らかにサーバ状態を要求するかもしれません。
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.
直径: 直径は多くの応答コードによってサーバがエラー条件を示すことができる全体でサーバの反射している状態を提供します。 Disconnect同輩要求は優雅に同輩との接続を終えるために極端な場合には手段を提供します、断線の理由に関してもう一方の端を知らせて。
Barnes Informational [Page 15] RFC 4097 MIDCOM Protocol Evaluation June 2005
バーンズ情報[15ページ]のRFC4097MIDCOMは評価2005年6月に議定書を作ります。
COPS: The COPS Report message is designed to indicate any
asynchronous conditions/events.
巡査: COPS Reportメッセージは、どんな非同期な状態/イベントも示すように設計されています。
2.1.7. Middlebox Can Generate Unsolicited Messages
2.1.7. Middleboxはお節介なメッセージを生成することができます。
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: T、RSIP: T、Megaco: T、直径: T、巡査: 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サーバは、RSIPホストが結合のすべてを放棄して、RSIPゲートウェイとの関係を終えるのを強制するために求められていない_DE_REGISTER RESPONSEを送るでしょう。 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.
直径: Diameterプロトコル許可証は、トランザクションを溯源するために接続でじっと見ます。 したがって、プロトコルサポートMiddleboxはメッセージを溯源しました。
COPS: The COPS Report message is designed to indicate any
asynchronous conditions/events.
巡査: COPS Reportメッセージは、どんな非同期な状態/イベントも示すように設計されています。
2.1.8. Mutual Authentication
2.1.8. 互いの認証
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: T、RSIP: T、Megaco: T、直径: T、巡査: 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エージェント)の間の左右対称の秘密鍵暗号化をサポートします、その結果、互いの認証をサポートします。 デフォルト認証と暗号化メソッドはRFC3414[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
RSIP: RFC3104[19]で説明されるようにIPSecの上でRSIPを操作することによって、この必要条件を満たすことができます。 RSIPフレームワークは、RSIPホストとゲートウェイとのすべてのコミュニケーションが認証されることを勧めます。 そしてお互いにRSIPホストとゲートウェイを認証するためにそれぞれのRSIPプロトコルパケット、缶のサーブの終わりまでメッセージハッシュの形における認証を追加して、メッセージの保全を提供してください。
Barnes Informational [Page 16] RFC 4097 MIDCOM Protocol Evaluation June 2005
バーンズ情報[16ページ]のRFC4097MIDCOMは評価2005年6月に議定書を作ります。
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プロトコルのために定義される必要があるでしょう。
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.
直径: Diameterベースプロトコルは、メッセージが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を使用できます。
2.1.9. Termination of session by either party
2.1.9. 何れの当事者によるセッションの終了
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: T、RSIP: T、Megaco: T、直径: T、巡査: 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と共にセッションを終えて、次に、REGISTER_FIRST誤りでセッションに関するその後の要求に応じるかもしれません。
Megaco: The Megaco protocol allows both peers to terminate the
association with proper reason code.
Megaco: Megacoプロトコルで、両方の同輩は適切な理由コードとの協会を終えることができます。
Barnes Informational [Page 17] RFC 4097 MIDCOM Protocol Evaluation June 2005
バーンズ情報[17ページ]のRFC4097MIDCOMは評価2005年6月に議定書を作ります。
Diameter: Either peer in a connection may issue a Disconnect-Peer-
Request to end the connection gracefully.
直径: 接続というどちらの同輩も接続を優雅に終わらせるというDisconnect-同輩要求を出すかもしれません。
COPS: COPS allows both the PEP and PDP to terminate a session.
巡査: COPSはPEPと終わるPDPの両方にセッションを許容します。
2.1.10. Indication of Success or Failure
2.1.10. 成否のしるし
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: T、RSIP: T、Megaco: T、直径: T、巡査: 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: それぞれの操作要求には、成否を示すエラー状況を含む対応する応答メッセージがあります。 middleboxがすぐに終了できない複雑な要求のために、対応するMIBモジュールは、また、完全なトランザクションの成否の非同期な通知を提供するように設計されるかもしれない、そして/または、完全なトランザクションの成否を示す投票可能オブジェクトを提供するかもしれません。 例えば、RFC2863[28]でifAdminStatusと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要求が要求がうまくいかなかったなら、要求がうまくいってERROR_RESPONSEであったなら対にされたRSIP応答をもたらします。
Megaco: Megaco defines a special descriptor called an Error
descriptor that contains the error code and an optional
explanatory string.
Megaco: Megacoはエラーコードを含むError記述子と任意の説明しているストリングと呼ばれる特別な記述子を定義します。
Diameter: Every Diameter request is matched by a response, and this
response contains a result code as well as other information.
直径: 応答であらゆるDiameter要求が合われています、そして、この応答は他の情報と同様に結果コードを含んでいます。
COPS: The COPS Report message directly fulfills this requirement.
巡査: COPS Reportメッセージはこの要件を直接実現させます。
2.1.11. Version Interworking
2.1.11. バージョンの織り込むこと
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: T、RSIP: T、Megaco: T、直径: T、巡査: 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の能力交換はuni方向上です。 マネージャは、どのMIBsがサポートされるかを決定するために、middlebox(SNMPエージェント)について質問できます。 さらに、複数のメッセージバージョンが、同時にサポートすることができて、メッセージヘッダーのバージョン番号によって特定されます。
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: バージョンの織り込むのと交渉はプロトコルとどんな拡大パッケージのためにもサポートされます。
Barnes Informational [Page 18] RFC 4097 MIDCOM Protocol Evaluation June 2005
バーンズ情報[18ページ]のRFC4097MIDCOMは評価2005年6月に議定書を作ります。
Diameter: The Capabilities Exchange Request/Answer allows two peers
to determine information about what each supports, including
protocol version and specific applications.
直径: Capabilities Exchange Request/答えで、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サーバとのMIDCOMバージョン番号と能力交渉を運ぶことができます。この能力交渉メカニズムは、COPSクライアントとサーバがサポートしている特徴/能力を伝えるのを許容します。 これはシームレスのバージョンの織り込むことを許すでしょう。
2.1.12. Deterministic Behaviour in the Presence of Overlapping
Rules
2.1.12. 規則を重ね合わせることの面前で決定論的なふるまい
SNMP: T, RSIP: T, Megaco: P, Diameter: T, COPS: T
SNMP: T、RSIP: T、Megaco: P、直径: T、巡査: 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: RulesetsはMIBsで定義されるでしょう。 MIBモジュール定義でrulesetsの優先権、および闘争の解決を定義できます。 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_椚瀬誤りがある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: これによる重なるのからMegacoプロトコル要素を分離するモデルの助けで会われて、Policyが統治するという(Appendix Cを見てください)ことです。 しかしながら、Megacoプロトコル要素のための新しい振舞いは、新しい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.
直径: Middleboxの上にインストールされたPolicy Rulesについてすべてを知らない場合、大規模な意味記述が決定論的な結果を提供している状態で、IPFilterRuleタイプ仕様(たぶんPolicy Rule AVPのタイプとして使用される)は来ます。(個々のエージェントは結果を知ることができません)。 最初の取り組んでいる規則が評価を終えていて、適切な方向への規則はオーダーで評価されます。 各パケットは一度評価されます。 最後の規則が通過されて、規則が全く合っていないなら、パケットは、評価された最後の規則が許可証であったなら下げられて、通過されます。aは否定します。 この要件への適用性に関するIPFilterRule形式と詳細をAppendix 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プロトコルはPEPとPDPとの取引ベースのコミュニケーションを提供します、したがって、middlebox州のマシンが正しく設計されるなら、振舞いは完全に決定論的です。 COPSプロトコル機能は、良い状態がマシンデザインであると奨励して、サポートします。
Barnes Informational [Page 19] RFC 4097 MIDCOM Protocol Evaluation June 2005
バーンズ情報[19ページ]のRFC4097MIDCOMは評価2005年6月に議定書を作ります。
2.2. Protocol Semantics
2.2. プロトコル意味論
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.
プロトコルに対して評価されて、要件のセクション2.2からの意味要件が[1]を記録するとき、このセクションは個々のプロトコルを含みます。 評価を実体化するためにそれぞれのプロトコルの短い記述を提供します。
2.2.1. Extensibility
2.2.1. 伸展性
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: T、RSIP: T、Megaco: T、直径: T、巡査: T
SNMP: Extensibility is a basic feature of the SNMP management
Framework.
SNMP: 伸展性はSNMP管理Frameworkに関する基本的特徴です。
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つの義務的な分野(プロトコルバージョン、メッセージタイプ、およびメッセージ長)とparameterType/長さ/値の3-tuplesの系列から成ります。 新しいメッセージは、メッセージタイプ分野と新しい値を定義することによって、定義されるかもしれません。 新しいパラメータの型は定義されるかもしれません、そして、既存のメッセージは、新しいparameterType値を定義することによって、広げられるかもしれません。 新しいメッセージ、パラメタ、または両方が非後方のコンパチブル方法で加えられるなら、プロトコルバージョン分野の新しい値は定義されるかもしれません。 これが追加で同等の状態で望ましいかもしれない後方である、互換性があります。
Megaco: Megaco is easily extensible through new Packages, which
allow definition of new attributes and behavior of a Termination.
Megaco: Megacoは新しいパッケージを通して容易に広げることができます。パッケージは新しい属性の定義とTerminationの動きを許容します。
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.
直径: 直径は多くの柔軟性を拡大に提供します、必須に分かるか、無視可能であるか理解されるとしてベンダーによって定義されたコマンドとAVPsのための小遣いと各AVPに旗を揚げさせる能力を含んでいて。
COPS: The COPS protocol is extensible, since it was designed to
separate the Protocol from the Policy Control Information.
巡査: それがPolicy Control情報とプロトコルを切り離すように設計されたので、COPSプロトコルは広げることができます。
2.2.2. Support of Multiple Middlebox Types
2.2.2. 複数のMiddleboxタイプのサポート
SNMP: T, RSIP: P+, Megaco: T, Diameter: P+, COPS: T
SNMP: T、RSIP: P+、Megaco: T、直径: P+、巡査: 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は明らかに異なった能力がある異なった装置タイプを管理にサポートします。 まず最初に、基本的なMIB-II[3]からのsysObjectIDと呼ばれる管理オブジェクトは箱の形式を特定します。 変化する能力がある箱がないかどうか、SNMPは対応するMIBsの有用性をチェックできます。
Barnes Informational [Page 20] RFC 4097 MIDCOM Protocol Evaluation June 2005
バーンズ情報[20ページ]のRFC4097MIDCOMは評価2005年6月に議定書を作ります。
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: middleboxesのすべてのタイプがruleset動作が許可証である限り、サポートされます。 他の動作は許可証と他の必要な動作のために値で新しい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は同じインタフェースでこのサポートを提供するためにPolicy Rulesを表す特性を設計するか、または同じセッションにおける複数の終了を使用することによって、複数のMiddleboxにタイプをサポートすることができます、それぞれ1つのタイプの動作を表して。 後者の場合では、グループとしての関連する終了を管理する便利な手段としてMegaco Contextを使用できます。 しかしながら、文脈の終了の間の流れの固有の考えは、無関係であり、捨てられなければならないでしょう。
Diameter: Any necessary additional AVPs or values must be specified
as part of the MIDCOM application extension (see <2.2.8> below).
直径: MIDCOMアプリケーション拡張子の一部としてどんな必要な追加AVPsや値も指定しなければならない、(<を見てください、2.2、.8>、)以下に
COPS: COPS allows a PDP to provide filters and actions to multiple
PEP functions through a single COPS session.
巡査: COPSはPDPに複数のPEP機能にフィルタと動作をただ一つのCOPSセッションで提供させます。
2.2.3. Ruleset Groups
2.2.3. Rulesetグループ
SNMP: T, RSIP: P+, Megaco: T, Diameter: T, COPS: T
SNMP: T、RSIP: P+、Megaco: T、直径: T、巡査: 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は既に方針rulesetsの定義とrulesetsの組分けを可能にするSNMP Policy 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アドレスしか許容しないか、またはアドレスとポートは、ひもIDに割り当てられるために及びます。 RSIPは、必要に応じて新しいものを作成するよりむしろ既存のrulesetを広げるために任意のひもIDパラメタをASSIGN_REQUESTsに加えることによって、rulesetsを実装することができるでしょう。 同様に、無料_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文脈を使用できます。 例えば、それぞれPolicy Ruleの具体化を表して、文脈からwildcarded Subtractをすることによって、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
直径: 同じAVP(例えば、構文と低レベルである意味論がIPFilterRule型定義で定義されるPolicy Rule AVP)の複数のインスタンスが存在しているかもしれないところで直径はメッセージ構文定義を許します。 よりきつい組分けがそうなら
Barnes Informational [Page 21] RFC 4097 MIDCOM Protocol Evaluation June 2005
バーンズ情報[21ページ]のRFC4097MIDCOMは評価2005年6月に議定書を作ります。
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.
必要であることで、DiameterベースタイプのセットはGroupedタイプを含んでいます。 MIDCOMはアプリケーション拡大をDiameterプロトコルと定義するときrulesetグループ必要条件を満たすこれらの能力を利用する方法を選ぶことができます。
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-PR Handle州は、密接に関係づけられた政策目的のセットを関連づけるのに使用されるかもしれません。 Middleboxが追加要件を学ぶとき、Middleboxは、同じくらい下のこれらのリソース要件がIDを扱うと言い足します。(IDは必要な集合を構成します)。
2.2.4. Lifetime Extension
2.2.4. 生涯拡大
SNMP: P+, RSIP: T, Megaco: T, Diameter: T, COPS: P+
SNMP: P+、RSIP: T、Megaco: T、直径: T、巡査: 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オブジェクトを含んでいるPolicy 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アドレス、ポートまたは両方を割り当てるのがされる明白なリース時間を要求するかもしれません。 なにも要求されなかったなら、サーバは、要求されたリース時間を与えるか、または1つを割り当てるかもしれません。 次に、サーバでクライアントの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は対応するTerminationを広げているか、または削除できます)。
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.
直径: セッションのDiameter概念はセッション生涯、据置期間、および生涯拡大を含んでいます。 それはMIDCOM Policy Ruleの生涯とのDiameterセッションを関連づける意味になるかもしれません、その場合、生涯拡大のサポートが既成になります。
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.
巡査: COPSはPDPに求められていない決定をPEPに送らせます。 しかしながら、求められていないイベントは定義される必要があるCOPS MIDCOMの特定のクライアントかMIDCOMの特定のPIBに関連するようになるでしょう。 これで、PDPは既存のrulesetの生涯を広げることができるでしょう。
Barnes Informational [Page 22] RFC 4097 MIDCOM Protocol Evaluation June 2005
バーンズ情報[22ページ]のRFC4097MIDCOMは評価2005年6月に議定書を作ります。
2.2.5. Handling of Mandatory/Optional Nature of Unknown Attributes
2.2.5. 未知の属性の義務的であるか任意の本質の取り扱い
SNMP: T, RSIP: T, Megaco: P+, Diameter: P+, COPS: T
SNMP: T、RSIP: T、Megaco: P+、直径: P+、巡査: 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: 読書操作における未知の属性はResponseメッセージの例外として旗を揚げられますが、読書の残りは成功します。 書いてください。aに、操作(SET要求)を書いてください、すべての属性が以前有効にされる、実行されます。 あれば、未知の属性、失敗して、要求しますいいえが、書く。 未知の属性はResponseメッセージの例外として旗を揚げられます、そして、エラー状況は報告されます。
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実体は応答メッセージでコードをErrorに供給します。 トランザクションで「任意である」とマークされたコマンドが失敗すると、残っているコマンドは続くでしょう。 しかしながら、規定要求事項は新しいパッケージとの定義を必要とする加工特性の規則に対処します。
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定義で可能にされるなら、AVPsの義務的であるか任意の状態のしるしは完全にサポートされます。 指導は全く任意のAVPsのための診断情報の復帰に関して課されません。
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の間の能力と限界の交換に備えます。 また、要求が拒絶されるとき、状況のための明確なエラー処理があります。
2.2.6. Actionable Failure Reasons
2.2.6. 訴訟可能な失敗理由
SNMP: T, RSIP: P+, Megaco: T, Diameter: T, COPS: T
SNMP: T、RSIP: P+、Megaco: T、直径: T、巡査: 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プロトコルは、要請者が彼らの要求を変更することを許可するためにResponseメッセージのエラーコードと例外コードを返します。 誤りと例外は誤りを引き起こした属性を示します、そして、エラーコードは遭遇する誤りの本質を特定します。
If desired, a MIB can be designed to provide additional data about
error conditions either via asynchronous notifications or polled
objects.
望まれているなら、MIBは、非同期な通知か投票されたオブジェクトを通してエラー条件に関する追加データを提供するように設計される場合があります。
Barnes Informational [Page 23] RFC 4097 MIDCOM Protocol Evaluation June 2005
バーンズ情報[23ページ]のRFC4097MIDCOMは評価2005年6月に議定書を作ります。
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が振舞いを変更できる応答メッセージでコードをErrorに供給できます。 Megacoは応答とコマンドの間の相関関係にトランザクション識別子を使用します。 一度より同じトランザクションイドをもう少し受け取るなら、受信実体は静かにメッセージを捨てます、その結果、反射攻撃に対する何らかの保護を提供します。
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クライアント(MIDCOM Middlebox)の特定のエラーコードを含むかもしれません。
2.2.7. Multiple Agents Operating on the Same Ruleset.
2.2.7. 同じRulesetを作動させる複数のエージェント。
SNMP: T, RSIP: P, Megaco: P, Diameter: T, COPS: P
SNMP: T、RSIP: P、Megaco: P、直径: T、巡査: 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フレームワークは同じ管理オブジェクトに取り組んでいる複数のマネージャをサポートします。 ViewベースのAccess Control Model、(VACM、RFC3415[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: Middle Boxの上のMegaco州のマシンがMiddle Box政策ルール管理から衝撃を吸収されるなら、Middle Boxに関するローカルの方針でこの必要条件を満たすことができます。 しかしながら、これはMegacoプロトコルの精神に違反します、その結果、Megacoはこの要件に部分的に言いなりになると考えられます。
Diameter: The Diameter protocol, as currently defined, would allow
multiple agents to operate on the same ruleset.
直径: Diameterプロトコルで、現在定義されているとして、複数のエージェントが同じ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を使用するのは可能です。 リソース闘争が起こると、COPS州のマシンから別々の基本的なリソース管理機能はMiddleboxで仲裁を扱うでしょう。
Barnes Informational [Page 24] RFC 4097 MIDCOM Protocol Evaluation June 2005
バーンズ情報[24ページ]のRFC4097MIDCOMは評価2005年6月に議定書を作ります。
2.2.8. Transport of Filtering Rules
2.2.8. フィルタリング規則の輸送
SNMP: P+, RSIP: P+, Megaco: P+, Diameter: P+, COPS: P+
SNMP: P+、RSIP: P+、Megaco: P+、直径: P+、巡査: 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モジュールの適切な定義でこの必要条件を満たすことができます。 SMI(MIBモジュールを定義するのに使用される言語)は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.
直径: Diameterが有望なIPFilterRuleデータ型を定義する、(見る、2.1、.12、上)、どんな既存のメッセージ(他の必要なMIDCOM属性に伴うa Middleboxまでこれを運ぶもの)もありません。 Diameterの新しいMIDCOMアプリケーション拡張子は定義されなければならないでしょう。
COPS: The COPS protocol can meet this requirement by using a COPS
MIDCOM specific client or a MIDCOM specific PIB.
巡査: COPSプロトコルは、COPS MIDCOMの特定のクライアントかMIDCOMの特定のPIBを使用することによって、この必要条件を満たすことができます。
2.2.9. Mapped Port Parity
2.2.9. 写像しているポートの同等
SNMP: P+, RSIP: P+, Megaco: P+, Diameter: P+, COPS: P+
SNMP: P+、RSIP: P+、Megaco: P+、直径: P+、巡査: 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の特定のパッケージを使用することで容易にMegacoを広げることができます。
Barnes Informational [Page 25] RFC 4097 MIDCOM Protocol Evaluation June 2005
バーンズ情報[25ページ]のRFC4097MIDCOMは評価2005年6月に議定書を作ります。
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型定義の一部ではありません。 むしろ、MIDCOMはなくなった情報を加える他のAVPsと共に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 MIDCOMの特定のクライアントかMIDCOMの特定のPIBを使用することによってこの必要条件を満たすすべての柔軟性があります。
2.2.10. Consecutive Range of Port Numbers
2.2.10. 連続した範囲のポートナンバー
SNMP: P+, RSIP: T, Megaco: P+, Diameter: P+, COPS: P+
SNMP: P+、RSIP: T、Megaco: P+、直径: P+、巡査: 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モジュールの適切な定義でこの必要条件を満たすことができます。 SMI(MIBモジュールを定義するのに使用される言語)は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の特定のパッケージを使用することで容易にMegacoを広げることができます。
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型定義の一部ではありません。 むしろ、MIDCOMはなくなった情報を加える他のAVPsと共に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 MIDCOMの特定のクライアントかMIDCOMの特定のPIBを使用することによってこの必要条件を満たすすべての柔軟性があります。
2.2.11. More Precise Rulesets Contradicting Overlapping Rulesets
2.2.11. Rulesetsを重ね合わせながら反駁するより正確なRulesets
SNMP: P+, RSIP: P+, Megaco: P+, Diameter: T, COPS: P+
SNMP: P+、RSIP: P+、Megaco: P+、直径: T、巡査: 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に加えることができます。 パラメタがTRUEであるなら、結合は既存の結合に重なるかもしれません。 パラメタが不特定であるか、またはFALSEであるなら、結合は既存の結合に重ならないでしょう、その結果、RSIPの現在の定義との後方の互換性を維持します。
Barnes Informational [Page 26] RFC 4097 MIDCOM Protocol Evaluation June 2005
バーンズ情報[26ページ]のRFC4097MIDCOMは評価2005年6月に議定書を作ります。
Megaco: This requirement would be met if the policy in the
Middlebox allows contradictory, overlapping policy rules to be
installed.
Megaco: Middleboxの方針が、相容れなくて、重なっている政策ルールがインストールされるのを許容するなら、この必要条件は満たされるでしょう。
Diameter: Allowed by the IPFilterRule semantics described in
Appendix D.
直径: Appendix 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 MIDCOMの特定のクライアントかMIDCOMの特定のPIBを使用することによってこの必要条件を満たすすべての柔軟性があります。
2.3. General Security Requirements
2.3. 総合証券要件
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からの一般Security要件に対して評価されるように個々のプロトコルを含みます。 評価を実体化するためにそれぞれのプロトコルの短い記述を提供します。
2.3.1. Message Authentication, Confidentiality and Integrity
2.3.1. 通報認証、秘密性、および保全
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: T、RSIP: T、Megaco: T、直径: T、巡査: 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はUserベースのSecurity Modelを含んでいます。(USM、RFC3414[11])。(その[11])は認証、秘密性、および保全を提供するための3つの標準化法を定義します)。 さらに、USMには、メッセージの正当性のためのユニークなプロトコルエンジンIDを含む反射攻撃を防ぐための特定の内蔵のメカニズム、1エンジンあたりのタイマとカウンタ、およびタイムウィンドウがあります。
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: IPSEC[22]かTLS[21]の結合した使用法でMegacoはこれらの機能に備えます。
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には、認証、反復操作による保護、およびメッセージの保全のための裏の意味レベルセキュリティがあります。 また、COPSはTLSかIPSecを使用して、その結果、市場に共同利用した既存のセキュリティー対策は再利用できます。
Barnes Informational [Page 27] RFC 4097 MIDCOM Protocol Evaluation June 2005
バーンズ情報[27ページ]のRFC4097MIDCOMは評価2005年6月に議定書を作ります。
2.3.2. Optional Confidentiality Protection
2.3.2. 任意の秘密性保護
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: T、RSIP: T、Megaco: T、直径: T、巡査: 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はUserベースのSecurity Modelを含んでいます。(Security Modelは、認証、秘密性、および保全を提供するために3つの標準化法を定義して、さらなるメソッドを加えるために開いています)。 任意に使用するメソッドを選ぶことができます。
RSIP: Refer to 2.3.1.
RSIP: .1に2.3を参照してください。
Megaco: Refer to 2.3.1
Megaco: 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の実装サポート、(DiameterアプリケーションにおけるRFC2406[23])は任意ではありません。 IPSECかTLSのどちらかの展開は任意です。
COPS: Refer to 2.3.1.
巡査: .1に2.3を参照してください。
2.3.3. Operate Across Untrusted Domains
2.3.3. 信頼されていないドメインの向こう側に作動してください。
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: T、RSIP: T、Megaco: T、直径: T、巡査: 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のUserベースのSecurity Modelは認証、秘密性、および保全を提供するための3つの標準化法を定義します、そして、さらなるメソッドを加えるのは開いています。 これらのメソッドは信頼されていないドメインの向こう側にしっかりと作動します。
RSIP: Refer to 2.3.1.
RSIP: .1に2.3を参照してください。
Megaco: Refer to 2.3.1.
Megaco: .1に2.3を参照してください。
Diameter: The Diameter specification [24] recommends the use of
TLS [21] across untrusted domains.
直径: Diameter仕様[24]は信頼されていないドメインの向こう側にTLS[21]の使用を推薦します。
COPS: Refer to 2.3.1
巡査: 2.3に.1を参照してください。
2.3.4. Mitigates Replay Attacks on Control Messages
2.3.4. コントロールメッセージで反射攻撃を緩和します。
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: T、RSIP: T、Megaco: T、直径: T、巡査: 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のためのUserベースのSecurity Modelには、メッセージの正当性のための特定のユニークなプロトコルエンジンIDを含む反射攻撃を防ぐためのメカニズム、1エンジンあたりのタイマとカウンタ、および時間で組立の窓があります。
RSIP: Refer to 2.3.1
RSIP: 2.3に.1を参照してください。
Barnes Informational [Page 28] RFC 4097 MIDCOM Protocol Evaluation June 2005
バーンズ情報[28ページ]のRFC4097MIDCOMは評価2005年6月に議定書を作ります。
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.
Megaco: Megacoコマンドと応答はマッチング取引識別子を含んでいます。 複数の回同じトランザクションイドを受け取る受取人はメッセージを捨てて、その結果、反射攻撃に対する何らかの保護を提供するでしょう。 反射攻撃に対するさらに強い保護が必要であるなら、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を参照してください。
3. Conclusions
3. 結論
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.
それぞれのプロトコルのためのFully Compliantの数への尊敬がある総合的な統計、Partially Compliant(P+とP)、およびFailing Compliancy要件はテーブル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
T P+P F----------------------------------------------------------------- 巡査SNMP22 5 0 0RSIP17 7 3 0Megaco19 5 3 0直径21 5 1 0部20 5 2 0
Table 1: Totals across all Requirements
テーブル1: すべてのRequirementsの向こう側の合計
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とそれぞれMIBsとPIBsを使用するCOPS-PRで提供して、プロトコルへの影響を全く拡大に提供しません。 変化について議定書の中で述べて、理解されていなくて、他のDiameter実体で拡大を扱うことができますが、その結果、より高い影響力を持っています直径拡張子が、必要である。 また、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
SNMP管理フレームワークはMIDCOM MIBモジュールの適切なデザインですべての指定されたMIDCOMプロトコル必要条件を満たします。 SNMPは安定して立証された開発ツールがある立証された技術であり、既にNATが構成であるとサポートするために定義された拡大と方針を拠点とする管理を持ちます。 SNMPv3は完全な規格であり、より熟して、他のプロトコルより多くの合法化を中に受けました。
Barnes Informational [Page 29] RFC 4097 MIDCOM Protocol Evaluation June 2005
バーンズ情報[29ページ]のRFC4097MIDCOMは評価2005年6月に議定書を作ります。
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.
評価、大規模な本当の世界ネットワーク(例えば、DOCSISケーブルモデムネットワーク)を経営するために、配布されました。 MIDCOM PDPがMiddleboxの一部であると仮定するので、MIDCOMフレームワークへのSNMPの適用性には、制限があります。
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が許容できないRSIPの結果。
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がいくつかの必要条件を満たすのに新しいTermination/パッケージ定義の形における追加拡大が必要でしょう。 残っている必要条件を満たすために、別々の要素としてMegaco実体から基本的なMiddleboxリソース(例えば、フィルタ、政策ルール)をモデル化すると、そのままなプロトコルの用法は許容されるかもしれません、リソースアクセス制御要件のいくつかを満たして。
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.
Diameter評価は良い総合的なフィットを示しました。 新しいアプリケーション拡大で扱うことができるだろういくつかの部分的に会われた要件が特定されました。 しかしながら、MIDCOMアプリケーションには、Diameterアーキテクチャは重過ぎるかもしれません、そして、明確に、Diameterベースの大部分は必要ではありません。 さらに、Diameterは唯一のプロトコルです、この評価時点で。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プロトコル必要条件の大部分を満たすのを示します、要件2.1.3に会うのが明らかに必要であり、2.2.3であるCOPS-PRで。 1つが完全に満足させるために必要条件を部分的に満たした、2.1、.1、COPSモデルは、PDPがPEPとのコミュニケーションを確立するのを許容する必要があるでしょう。 COPSモデルによって明らかに禁止されていない間、これは追加を必要とするでしょう、ローカルの方針の形で認可された協会の適切な設立を確実にするために。
4. Security Considerations
4. セキュリティ問題
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の特定のSecurity要件に対する比較でカバーされて、要件が[1]を記録して、セクション2.1.8とセクション2.3によって明確に扱われるということです。
Barnes Informational [Page 30] RFC 4097 MIDCOM Protocol Evaluation June 2005
バーンズ情報[30ページ]のRFC4097MIDCOMは評価2005年6月に議定書を作ります。
5. References
5. 参照
5.1. Normative References
5.1. 引用規格
[1] Swale, R., Mart, P., Sijben, P., Brim, S., and M. Shore,
"Middlebox Communications (MIDCOM) Protocol Requirements", RFC
3304, August 2002.
[1] 低湿地、R.、市場、P.、Sijben、P.、縁、S.、およびM.は、「Middleboxコミュニケーション(MIDCOM)プロトコル要件」と支えます、RFC3304、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.、ローゼンバーグ、J.、モリトル、A.、A.Rayhanと、「Middleboxコミュニケーションアーキテクチャとフレームワーク」、RFC3303(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] ローズ、M.、およびK.McCloghrie、「TCP/IPベースのインターネットのNetwork Managementのための管理Information基地:」 「MIB-II」、STD17、RFC1213、1991年3月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[5] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for
Describing SNMP Management Frameworks", STD 62, RFC 3411,
December 2002.
[5] ハリントン、D.、Presuhn、R.、およびB.Wijnen、「SNMP管理フレームワークについて説明するためのアーキテクチャ」、STD62、RFC3411(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.、パーキンス、D.、およびJ.Schoenwaelder、「経営情報バージョン2(SMIv2)の構造」、STD58、RFC2578(1999年4月)。
[7] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual
Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[7]McCloghrieとK.とパーキンス、D.とJ.Schoenwaelder、「SMIv2"、STD58、RFC2579、1999年4月の原文のコンベンション。」
[8] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance
Statements for SMIv2", STD 58, RFC 2580, April 1999.
[8]McCloghrieとK.とパーキンス、D.とJ.Schoenwaelder、「SMIv2"、STD58、RFC2580、1999年4月のための順応声明。」
[9] Presuhn, R. (Ed.), "Transport Mappings for the Simple Network
Management Protocol (SNMP)", STD 62, RFC 3417, December 2002.
[9]Presuhn、R.編、「簡単なネットワーク管理プロトコル(SNMP)のための輸送マッピング」、STD62、RFC3417、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]ケース、J.、ハリントンD.、Presuhn R.、およびB.Wijnen、「メッセージ処理と簡単なネットワークマネージメントのために急いでいるのは(SNMP)について議定書の中で述べます」、STD62、RFC3412、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] ブルーメンソルとU.とB.Wijnen、「Simple Network Managementプロトコル(SNMPv3)のバージョン3のためのユーザベースのSecurity Model(USM)」、STD62、RFC3414、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.編、「簡単なネットワークマネージメントのためのプロトコル操作のバージョン2は(SNMP)について議定書の中で述べます」、STD62、RFC3416、2002年12月。
Barnes Informational [Page 31] RFC 4097 MIDCOM Protocol Evaluation June 2005
バーンズ情報[31ページ]のRFC4097MIDCOMは評価2005年6月に議定書を作ります。
[13] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", STD
62, RFC 3413, December 2002.
[13] レビとD.とマイヤー、P.とB.スチュワート、「SNMPv3アプリケーション」、STD62、RFC3413、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、「簡単なネットワークマネージメントのための視点ベースのアクセス制御モデル(VACM)は(SNMP)について議定書の中で述べます」、STD62、RFC3415、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] ケース、J.、マンディ、R.、パーテイン、D.、およびB.スチュワート、「インターネット標準のネットワークマネージメントフレームワークのバージョン3への序論」、RFC3410(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.、パイ、N.、およびC.ワング、「ネットワークのための管理オブジェクトの定義は翻訳者(NAT)に演説します」、RFC4008、2005年3月。
[17] Borella, M., Lo, J., Grabelsky, D., and G. Montenegro, "Realm
Specific IP: Framework", RFC 3102, October 2001.
[17]Borella、M.、最低気温、J.、Grabelsky、D.、およびG.モンテネグロ、「分野の特定のIP:」 「フレームワーク」、RFC3102、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.、最低気温、J.、およびK.谷口、「分野の特定のIP:」 「プロトコル仕様」、RFC3103、2001年10月。
[19] Montenegro, G. and M. Borella, "RSIP Support for End-to-end
Ipsec", RFC 3104, October 2001.
[19] モンテネグロとG.とM.Borella、「終わりから終わりへのIpsecのRSIPサポート」、RFC3104、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.とグリーン、N.とRayhanとA.とHuitemaとC.とローゼン、B.とJ.Segers、「Megacoはバージョン1インチについて議定書の中で述べます、RFC3015、2001年10月。」
[21] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[21] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[22] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[22] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[23] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload",
RFC 2406, November 1998.
[23] ケントとS.とR.アトキンソン、「セキュリティが有効搭載量であるとカプセル化するIP」、RFC2406、1998年11月。
[24] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
"Diameter Base Protocol", RFC 3588, September 2003.
[24] カルフーンとP.とLoughneyとJ.とGuttmanとE.とゾルン、G.とJ.Arkko、「直径基地のプロトコル」、RFC3588、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]ダラム、D.編、ボイル、J.、コーエン、R.、ハーツォグ、S.、Rajan、R.、およびA.Sastry、「巡査(一般的なオープンポリシーサービス)は議定書を作ります」、RFC2748、2000年1月。
[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] チェン(K.、Seligson、J.、ダラム、D.、ガイ、S.、McCloghrie、K.、ハーツォグ、S.、Reichmeyer、F.、Yavatkar、R.、およびA.スミス)は、「方針の食糧を供給する用法を獲得します」、RFC3084、2001年3月。
Barnes Informational [Page 32] RFC 4097 MIDCOM Protocol Evaluation June 2005
バーンズ情報[32ページ]のRFC4097MIDCOMは評価2005年6月に議定書を作ります。
5.2. Informative References
5.2. 有益な参照
[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アプリケーションレベルゲートウェイ」、RFC2962(2000年10月)。
[28] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB",
RFC 2863, June 2000.
[28]McCloghrieとK.とF.Kastenholz、「インタフェースはMIBを分類する」RFC2863、2000年6月。
6. Acknowledgements
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.
エディタは個々のプロトコル評価貢献のときにジョエル・M.アルペルンによって提供された建設的なフィードバックを承認したがっています。 追加、ドキュメント内容についてのメーリングリスト議論に貢献するためのElwynデイヴィース、クリストファー・マーチン、ボブ・ペンフィールド、スコットBrim、およびマーチンStiemerlingへの感謝で。
Barnes Informational [Page 33] RFC 4097 MIDCOM Protocol Evaluation June 2005
バーンズ情報[33ページ]のRFC4097MIDCOMは評価2005年6月に議定書を作ります。
Appendix A - SNMP Overview
付録A--SNMP概要
The SNMP Management Framework presently consists of five major components:
SNMP Management Frameworkは現在、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 RFC3411[5]で説明された総合的なアーキテクチャ。 RFC3410[15]でSNMP Management Frameworkのための、より詳細な序論と適用性証明を見つけることができます。
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 オブジェクトを説明して、命名するためのメカニズムと管理の目的のためのイベント。 Management情報(SMI)のこのStructureの最新版は、RFC2578[6]、RFC2579[7]、およびRFC2580[8]でSMIv2と呼ばれて、説明されます。
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 経営情報を移すためのメッセージプロトコル。 メッセージプロトコルの最新版は、RFC3412[10]、RFC3414[11]、およびRFC3417[9]でSNMPv3と呼ばれて、説明されます。
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形式の最新版はRFC3416[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 1セットの基礎的応用は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.
管理オブジェクトはManagement Information基地と呼ばれた仮想情報店かMIBを通してアクセスされます。 MIBのオブジェクトは、SMIで定義されたメカニズムを使用することで定義されます。
A.1 SNMPv3 Proxy Forwarding
A.1 SNMPv3プロキシ推進
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プロキシ推進、(RFC3413[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
各実体はユニークなengineID値によって特定されて、ドメイン、そして/または、信頼がドメインであると扱うとき、特にプロキシをサポートします。 SNMPv3メッセージはメッセージセキュリティに使用されるためにデータベースを特定する2engineIDs1、および含まれたデータの源(または、目標)を特定する1つを含んでいます。 そしてメッセージセキュリティが創始者とプロキシの間と、そして、そして、プロキシの間で適用される。
Barnes Informational [Page 34] RFC 4097 MIDCOM Protocol Evaluation June 2005
バーンズ情報[34ページ]のRFC4097MIDCOMは評価2005年6月に議定書を作ります。
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.
終わり目標。 PDUはデータが終わらせる終わりを渡すメッセージに含まれているノードのengineIDを含んでいます、プロキシで、変わりがありません。
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のように、SNMPバージョンドメインに交差していて、SNMPv3やSNMPv1のように、DESやAESと、1ポイントの管理接触をネットワークの部分集合に供給するためにセキュリティー対策ドメインに交差していて、NATデバイスかVPN終点を通って私設のネットワークを経営するのなどように。
A.2 Proxies Versus Application Level Gateways
A.2プロキシ対アプリケーションレベルゲートウェイ
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のためにApplication Level Gatewaysより好まれます。 ALGsはメッセージのヘッダーと内容を通常変更します。 SNMPがトラブルシューティングネットワークのために設計されたプロトコルである、(誤、)、構成。 オペレータが、実際の構成を理解する必要があるので、SNMPデータの中のアドレスに関する翻訳は混乱を引き起こします、オペレータから管理されたデバイスの実際の構成を隠して。 また、ALGsはセキュリティの脆弱性、および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 Proxiesはメッセージヘッダーを変更できます。 これはアドレスに関するアプリケーションレベル翻訳を可能にしている間、ペイロードデータを翻訳すると関連している問題を避けます。
The issues of ALGs versus proxies for SNMP Payload Address Translation are discussed at length in RFC 2962 [27].
十分RFC2962[27]でALGs対SNMP有効搭載量Address Translationのプロキシの問題について議論します。
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はmiddleboxesのために、MIDCOMと共にmiddleboxesでMIDCOMと、アプリケーション修正もエージェントなしでALGs(アプリケーションLayer Gateways)を必要とします。
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ヌルトンネルのサポートを実装することができました。
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
NATヌルトンネルのサポートがホストで実装されるなら、アプリケーションへの変更は全く必要でないでしょうに、そして、どんなアプリケーションエージェントもALGsも必要でないでしょう。 これには、明白な利点があります。 ヌルトンネル、ホストがRSIP / MIDCOMクライアント(または、STUNクライアント)を実装するために持っていて、middleboxが持っているNATに加えて
Barnes Informational [Page 35] RFC 4097 MIDCOM Protocol Evaluation June 2005
バーンズ情報[35ページ]のRFC4097MIDCOMは評価2005年6月に議定書を作ります。
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.
_middleboxを超えたRSIP / MIDCOMサーバ、またはSTUNサーバを実装するためには、利用可能な_でなければならないでしょう。 STUNクライアント/サーバアプローチがmiddleboxesのすべてのタイプで働かないかもしれないことに注意してください。
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ヌルトンネルのサポートがホストで実装されないなら、アプリケーションは変更されなければならないでしょうに、または、アプリケーションエージェントかALGsが実装されなければならないでしょう。 これには、ホストアプリケーションの変更かアプリケーションエージェント、どれがRSIP / MIDCOMクライアントを含むだろうか、そして、middleboxのRSIP/MIDCOMサーバの実装の実装を必要とするだろうというのを除いて、ホストへの必要さ変更でないトンネル(ヌルであるか否かに関係なく)より利点があります。 一方、いくつかの状況で、RSIP / MIDCOMの代わりにSTUNを使用できました。
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サーバがmiddleboxで必要です。 トンネルを堀られて、ホストは、変更される必要がありますが、アプリケーションが必要がありません。 Untunneledされていて、エージェントを加えてはいけないだろう、アプリケーションを変更しなければなりませんが、さもなければ、ホスト変更が全くないでしょう。 トンネリングの利点/損失は、RSIPを考える際に評価される必要があるでしょう。
Barnes Informational [Page 36] RFC 4097 MIDCOM Protocol Evaluation June 2005
バーンズ情報[36ページ]のRFC4097MIDCOMは評価2005年6月に議定書を作ります。
Appendix C - Megaco Modeling Approach
付録C--Megacoモデル化法
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ファイアウォールなどのMiddlebox機能をモデル化するために、新しいMiddlebox Terminationタイプは、Megacoの中で定義される必要があります。 複数のエージェントによる政策ルールオーバラップか変更は必要でないなら、政策ルールがTerminationに同等です(図1を見てください)。 フィルタ、動作、クリエイター生涯などのPolicy規則の様々な成分はTerminationの様々な特性として記述されています。 Virtualメディアゲートウェイ(VMG)概念の使用は同じMBとの複数のMAの無闘争の相互作用を考慮します。
+-------+ +-------+
| MA-1 | | MA-2 |
| | | |
+-------+ |IF2 +-------+
| | |
+-------------|---------|----------|-----------+
| +---------+ | +-------------+ |
IF1 |VMG1 | +--+ | | | +--+ +--+ |VMG2 |IF3
----------| |Tx|-------+ +---|Ty|--|Tz|----------------
| | +--+ | | | +--+ +--+ | |
| ....| | | +-------------+ |
| +---------+ | |
| +---------------------------------
| Middlebox | IF4
+----------------------------------------------+
+-------+ +-------+ | MA-1| | MA-2| | | | | +-------+ |IF2+-------+ | | | +-------------|---------|----------|-----------+ | +---------+ | +-------------+ | IF1|VMG1| +--+ | | | +--+ +--+ |VMG2|IF3----------| |Tx|-------+ +---|タイ|--|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
Tx: 終了xは政策ルールxタイと等しいです: 終了y=Policyはy Tzを統治します: 終了zは政策ルールz MAと等しいです: MIDCOMエージェント、: インタフェース
Figure 1.
図1。
Barnes Informational [Page 37] RFC 4097 MIDCOM Protocol Evaluation June 2005
バーンズ情報[37ページ]のRFC4097MIDCOMは評価2005年6月に議定書を作ります。
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.
それが複数のエージェントを許容するのに必要であるなら、同じMiddleboxリソース(例えば、Policy規則かフィルタ)を操ってください、Terminationから別々に保たれるべき後者の必要性(Policy規則は関連Terminationの特性を操作することによって、MAによって操られます)。 例えば、政策ルール操作を重ね合わせるのが必要であるなら、Terminationはただ一つの政策ルールに関連するでしょうが、政策ルールは1Terminationに関連しているかもしれません。 したがって、Terminationは別のTerminationと政策ルールを共有するか、または別のTerminationのものに部分的に重なる政策ルールを持つことができます。 政策ルールを同じように操るか、または重ね合わせて、2異なったTerminations(図2を見る)を制御して、このモデルは2MAsを許容します。 図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 | |
| +----+------+------+ +------+ |
+----------------------------------------------+
+-------+ +-------+ | MA-1| | MA-2| | | | | +-------+ |IF2+-------+ | | | MB+-------------|---------|----------|-----------+ | +-----------+ | +-------------+ | IF1|VMG1| +--+ | | | +--+ +--+ |VMG2|IF3------------------|タイ|----+ +---|Tx|--|Tz|---------------- | | +--+ | | | +--+ +--+ | | | .... | | | | +--/------\---+ | | +-------|---+ | / \ | | | +----/----------\------------------ | +------+----+------+ +------+ |IF4| |Policy1 Policy2| |方針| | | | | | | | 3 | | | +----+------+------+ +------+ | +----------------------------------------------+
Tx: Termination x
Ty: Termination y
Tz: Termination z
MA: MIDCOM Agent
IF: Interface
MB: Middlebox
Tx: Termination xタイ: 終了y Tz: 終了z MA: MIDCOMエージェント、: MBを連結してください: Middlebox
Figure 2.
図2。
This requires that the Agent and the Middlebox adhere to the following principles:
これは、エージェントとMiddleboxが以下の原則を固く守るのを必要とします:
(1) Only one Termination has read/write access to a filter at any
time.
1Terminationだけがいつでもフィルタへのアクセスを読まれるか、または書くのをさせる(1)。
Barnes Informational [Page 38] RFC 4097 MIDCOM Protocol Evaluation June 2005
バーンズ情報[38ページ]のRFC4097MIDCOMは評価2005年6月に議定書を作ります。
(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) 政策ルールが新しいエージェント(すなわち、方針を作成したものでない)によって変更することにされるのであるとき、Middleboxは、政策決定をして、要求された変更を受け入れるかどうか決めます。 場合では、変更は受け入れて、初期の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:
OctetString AVP基地のFormatからIPFilterRule形式を得ます。 それは、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アドレス(ことによると仮面の)プロトコルSourceと仕向港(リストか範囲)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.
最初の取り組んでいる規則が評価を終えていて、適切な方向への規則はオーダーで評価されます。 各パケットは一度評価されます。 最後の規則が通過されて、規則が全く合っていないなら、パケットは、評価された最後の規則が許可証であったなら下げられて、通過されます。aは否定します。
IPFilterRule filters MUST follow the format:
IPFilterRuleフィルタは形式に続かなければなりません:
action dir proto from src to dst [options]
srcからdstまでの動作dir proto[オプション]
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 An IPプロトコルは指定しました。 "ip"キーワードは、どんなプロトコルも合うことを意味します。
src and dst <address/mask> [ports]
srcとdst<アドレス/マスク>。[ポート]
Barnes Informational [Page 39] RFC 4097 MIDCOM Protocol Evaluation June 2005
バーンズ情報[39ページ]のRFC4097MIDCOMは評価2005年6月に議定書を作ります。
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.
フォーム1.2.3.4/24のマスク幅に従った上のipno/ビットAn 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バージョン、ビットがないかどうかテストするために、ゼロに部分を設定できます。 「いずれ」というキーワードはそうです。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.
マッチの感覚は先行することによって逆にされて、修飾語(!)であって、引き起こさないのによるすべて他のアドレスが、代わりに合わせられると扱うということであるかもしれません。 これはポートナンバーの品揃えに影響しません。
With the TCP, UDP and SCTP protocols, optional
ports may be specified as:
TCP、UDP、およびSCTPプロトコルで、任意のポートは以下として指定されるかもしれません。
{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つ以上のポート仕様を持っている規則に決して合わないでしょう。 見る、合っている断片化しているパケットに関する詳細のためのオプションを破片手榴弾で殺傷してください。
Barnes Informational [Page 40] RFC 4097 MIDCOM Protocol Evaluation June 2005
バーンズ情報[40ページ]のRFC4097MIDCOMは評価2005年6月に議定書を作ります。
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.
パケットが断片であるならMatchを破片手榴弾で殺傷してください。そうすれば、これはデータグラムの最初の断片ではありません。破片手榴弾で殺傷してください。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:
IPヘッダーがコンマを含んでいるなら、ipoptions仕様Matchは仕様で指定されたオプションのリストを切り離しました。 サポートしている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(厳しい送信元経路)、lsrr(ゆるい送信元経路)、rr(パケットルートを記録する)、およびt(タイムスタンプ)。 特定のオプションの欠如は'!'で指示されるかもしれません。
tcpoptions spec
Match if the TCP header contains the comma
separated list of options specified in spec. The
supported TCP options are:
TCPヘッダーがコンマを含んでいるなら、tcpoptions仕様Matchは仕様で指定されたオプションのリストを切り離しました。 サポートしている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)、t(rfc1323タイムスタンプ)、およびcc(rfc1644t/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仕様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.
フィン、syn、rst、psh、ack、およびurg。 特定の旗の欠如は'!'で指示されるかもしれません。 tcpflags仕様を含む規則は非ゼロオフセットを持っている断片化しているパケットに決して合うことができません。 見る、合っている断片化しているパケットに関する詳細のためのオプションを破片手榴弾で殺傷してください。
Barnes Informational [Page 41] RFC 4097 MIDCOM Protocol Evaluation June 2005
バーンズ情報[41ページ]のRFC4097MIDCOMは評価2005年6月に議定書を作ります。
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).
エコー・リプライ(0)、目的地手の届かない(3)、ソース焼き入れ(4)、再直接の(5)、エコー要求(8)、ルータ通知(9)、ルータ懇願(10)、IPヘッダー悪い(12)、タイムスタンプ要求(13)、タイムスタンプ回答(14)、情報要求(15)、情報回答(16)、アドレスマスク要求(17)、およびアドレスマスク回答(18)、生きる時間は(11)を超えていました。
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種類のパケット、すなわち、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.
aを解釈するか、または適用できないアクセスデバイスは、規則がセッションを終えなければならないことを否定します。 許可証規則を解釈するか、または適用できないアクセスデバイスは、より制限している規則を適用するかもしれません。 デバイスが適用するかもしれないアクセスは、供給された規則の前に例えばアクセスデバイス所有者のインフラストラクチャを保護するためにそれ自身の規則を否定します。
The rule syntax is a modified subset of ipfw(8) from FreeBSD, and the ipfw.c code may provide a useful base for implementations.
規則構文は無料OSの一つからの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
ジムRenkel
SNMP:
SNMP:
Juergen Quittek
NEC Europe Ltd.
EMail: quittek@ccrle.nec.de
ユルゲンQuittek NECヨーロッパ株式会社EMail: quittek@ccrle.nec.de
Barnes Informational [Page 42] RFC 4097 MIDCOM Protocol Evaluation June 2005
バーンズ情報[42ページ]のRFC4097MIDCOMは評価2005年6月に議定書を作ります。
David Harrington
Co-chair SNMPv3 WG
EMail: dbh@enterasys.com
デヴィッドハリントンの共同議長SNMPv3 WGはメールします: dbh@enterasys.com
Megaco:
Megaco:
Sanjoy Sen
Sanjoy銭
Cedric Aoun
Nortel
EMail: cedric.aoun@nortel.com
セドリックAounノーテルEMail: cedric.aoun@nortel.com
Tom Taylor
Nortel
EMail: taylor@nortel.com
トム・テイラーノーテルEMail: taylor@nortel.com
Diameter:
直径:
Tom Taylor
Nortel
EMail: taylor@nortel.com
トム・テイラーノーテルEMail: taylor@nortel.com
COPS:
巡査:
Cedric Aoun
Nortel
EMail: cedric.aoun@nortel.com
セドリックAounノーテルEMail: cedric.aoun@nortel.com
Kwok-Ho Chan
Nortel
EMail: khchan@nortel.com
クォック、-、おーい、チェンノーテルEMail: khchan@nortel.com
Louis-Nicolas Hamer
ルイス-ニコラス・ヘーマー
Reinaldo Penno
EMail: rpenno@juniper.net
レイナルドペンノEMail: rpenno@juniper.net
Sanjoy Sen
Sanjoy銭
Author's Address
作者のアドレス
Mary Barnes Nortel 2201 Lakeside Blvd. Richardson, TX USA
メアリバーンズノーテル2201湖畔Blvd. テキサスリチャードソン(米国)
Phone: 1-972-684-5432 EMail: mary.barnes@nortel.com
以下に電話をしてください。 1-972-684-5432 メールしてください: mary.barnes@nortel.com
Barnes Informational [Page 43] RFC 4097 MIDCOM Protocol Evaluation June 2005
バーンズ情報[43ページ]のRFC4097MIDCOMは評価2005年6月に議定書を作ります。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet gement
RFC Editor機能のための基金は現在、インターネットgementによって提供されます。
Barnes Informational [Page 44]
バーンズInformationalです。[44ページ]
一覧
スポンサーリンク
