Network Working Group R. P. Swale
Request for Comments: 3304 BTexact Technologies
Category: Informational P. A. Mart
Marconi Communications
P. Sijben
Lucent Technologies
S. Brim
M. Shore
Cisco Systems
August 2002
Middlebox Communications (midcom) Protocol Requirements
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 (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
This document specifies the requirements that the Middlebox Communication (midcom) protocol must satisfy in order to meet the needs of applications wishing to influence the middlebox function. These requirements were developed with a specific focus on network address translation and firewall middleboxes.
この文書では、ミドルコミュニケーション（MIDCOM）プロトコルがミドルの機能に影響を与えることを希望するアプリケーションのニーズを満たすために満たさなければならない要件を指定します。これらの要件は、ネットワークアドレス変換およびファイアウォールミドルボックス上の特定の焦点を当てて開発されました。
This document is one of two developed by the Middlebox Communication (midcom) working group to address the requirements and framework for a protocol between middleboxes and "midcom agents." This document presents midcom requirements; [MCFW] presents the context and framework. [MCFW] also presents terminology and definitions and should be read in tandem with this one.
この文書では、中間装置との間のプロトコルのための要件と枠組み対処するミドルコミュニケーション（MIDCOM）ワーキンググループによって開発された二つのうちの一つである「MIDCOMエージェント」をこの文書では、MIDCOM要件を提示し、 【MCFW]コンテキストおよびフレームワークを提示します。 [MCFW]また、専門用語や定義を提示し、この1と並行して読まれるべきです。
These requirements were developed by examining the midcom framework and extracting requirements, both explicit and implicit, that appeared there.
これらの要件はMIDCOMフレームワークを調べ、そこに現れ明示的および暗黙的の両方の要件を、抽出することによって開発されました。
Each requirement is presented as a statement, followed by brief explanatory material as appropriate. Terminology is defined in [MCFW]. There may be overlap between requirements.
各要件は、必要に応じて簡単な説明資料が続く、文として提示されます。用語は[MCFW]で定義されています。要件間のオーバーラップがあるかもしれません。
The Midcom protocol must enable a Midcom agent requiring the services of a middlebox to establish an authorized association between itself and the middlebox.
MIDCOMプロトコル自体とミドル間承認アソシエーションを確立するために、ミドルのサービスを必要とMIDCOMエージェントを有効にしなければなりません。
This states that the protocol must allow the middlebox to identify an agent requesting services and make a determination as to whether or not the agent will be permitted to do so.
これは、プロトコルはミドルがサービスを要求するエージェントを識別し、エージェントがそうすることを許可するかどうかの判定を行うことができなければならないと述べています。
The Midcom protocol must allow a Midcom agent to communicate with more than one middlebox simultaneously.
MIDCOMプロトコルはMIDCOM剤が同時に複数のミドルと通信することを可能にしなければなりません。
In any but the most simple network, an agent is likely to want to influence the behavior of more than one middlebox. The protocol design must not preclude the ability to do this.
最も単純なネットワークが、いずれにおいても、エージェントは、複数のミドルの行動に影響を与えるようにしたいそうです。プロトコルの設計は、これを行うための能力を排除してはなりません。
The Midcom protocol must allow a middlebox to communicate with more than one Midcom agent simultaneously.
MIDCOMプロトコルは、ミドルボックスは、同時に複数のMIDCOMエージェントと通信することを可能にしなければなりません。
There may be multiple instances of a single application or multiple applications desiring service from a single middlebox, and different agents may represent them. The protocol design must not preclude the ability to do so.
そこ単一ミドルからサービスを希望する単一のアプリケーションの複数のインスタンスまたは複数のアプリケーションであってもよく、異なる薬剤は、それらを表すことができます。プロトコルの設計は、そうする能力を排除してはなりません。
Where a multiplicity of Midcom Agents are interacting with a given middlebox, the Midcom protocol must provide mechanisms ensuring that the overall behavior is deterministic.
MIDCOMエージェントの多重度が所定のミドルと相互作用している場合、MIDCOMプロトコルは、全体的な挙動が決定論的であることを保証するメカニズムを提供しなければなりません。
This states that the protocol must include mechanisms for avoiding race conditions or other situations in which the requests of one agent may influence the results of the requests of other agents in an unpredictable manner.
このプロトコルは、競合状態、または1つのエージェントの要求は予測不可能な方法で他の薬剤の要求の結果に影響を与える可能性がある他の状況を回避するためのメカニズムを含まなければならないと述べています。
The Midcom protocol must enable the middlebox and any associated Midcom agents to establish a known and stable state. This must include the case of power failure, or other failure, where the protocol must ensure that any resources used by a failed element can be released.
MIDCOMプロトコルは既知の安定状態を確立するために、ミドルおよび関連MIDCOMエージェントを有効にする必要があります。これは、プロトコルが失敗した要素によって使用されるリソースを解放することができることを確認する必要があり、電源障害、またはその他の障害が発生した場合を、含んでいなければなりません。
This states that the protocol must provide clear identification for requests and results and that protocol operations must be atomic with respect to the midcom protocol.
このプロトコルはMIDCOMプロトコルに対してアトミックでなければならない要求し、その結果、そのプロトコル操作のための明確な識別を提供しなければならないと述べています。
The middlebox must be able to report its status to a Midcom agent with which it is associated.
ミドルは、それが関連付けられているMIDCOMエージェントにその状況を報告することができなければなりません。
The protocol must support unsolicited messages from middlebox to agent, for reporting conditions detected asynchronously at the middlebox.
プロトコルはミドルで非同期に検出された条件を報告するため、ミドルからエージェントに迷惑メッセージをサポートしている必要があります。
It may be the case that exceptional conditions or other events at the middlebox (resource shortages, intrusion mitigation) will cause the middlebox to close pinholes or release resources without consulting the associated Midcom agent. In that event, the protocol must allow the middlebox to notify the agent.
それは例外的な条件やミドルで他のイベント（リソース不足、侵入の緩和は）ピンホールを閉じたり、関連するMIDCOMエージェントに相談することなくリソースを解放するためにミドルの原因となります場合があり得ます。その場合、プロトコルはミドルがエージェントに通知できるようにする必要があります。
The Midcom protocol must provide for the mutual authentication of Midcom agent and middlebox to one another.
MIDCOMプロトコルは、相互にMIDCOMエージェントとミドルの相互認証のために提供しなければなりません。
In addition for the more obvious need for the Midcom agent to authenticate itself to the middlebox, there are some attacks against the protocol which can be mitigated by having the middlebox authenticate to the agent. See [MCFW].
ミドルに対して自身を認証するためにMIDCOMエージェントのためのより多くの明白な必要性のために加えて、エージェントにミドルの認証を持つことによって緩和することができるプロトコルに対するいくつかの攻撃があります。 [MCFW]を参照してください。
The Midcom protocol must allow either the Midcom agent or the middlebox to terminate the Midcom session between a Midcom Agent and a middlebox. This allows either entity to close the session for maintenance, security, or other reasons.
MIDCOMプロトコルはMIDCOM剤やミドルのいずれかがMIDCOMエージェントとミドルの間MIDCOMセッションを終了できるようにする必要があります。これは、エンティティのいずれかが、メンテナンス、セキュリティ、またはその他の理由でセッションを閉じることができます。
A Midcom agent must be able to determine whether or not a request was successful.
MIDCOMエージェントは、要求が成功したかどうかを決定できなければなりません。
This states that a middlebox must return a success or failure indication to a request made by an agent.
これは、ミドルは、エージェントからの要求に成功または失敗の表示を返さなければならないと述べています。
The Midcom protocol must contain version interworking capabilities to enable subsequent extensions to support different types of middlebox and future requirements of applications not considered at this stage.
MIDCOMプロトコルはミドルと、この段階では考えられないアプリケーションの将来的な要件の異なるタイプをサポートするために、その後の拡張機能を有効にするために、バージョンのインターワーキング機能が含まれている必要があります。
We assume that there will be later revisions of this protocol. The initial version will focus on communication with firewalls and NATs, and it is possible that the protocol will need to be modified, as support for other middlebox types is added. These version interworking capabilities may include (but are not limited to) a protocol version number.
私たちは、このプロトコルの後の改正があることを前提としています。最初のバージョンは、ファイアウォールおよびNATのとの通信に焦点を当て、他のミドルタイプのサポートが追加されるプロトコルは、変更する必要があることが可能です。これらのバージョンのインターワーキング機能は、プロトコルのバージョン番号を含むことができる（これらに限定されません）。
It must be possible to deterministically predict the behavior of the middlebox in the presence of overlapping rules.
決定論的ルールをオーバーラップの存在下で、ミドルの行動を予測することが可能でなければなりません。
The protocol must preclude nondeterministic behavior in the case of overlapping rulesets, e.g. by ensuring that some known precedence is imposed.
プロトコルは、例えば、重複するルールセットの場合に非決定的な動作を排除しなければなりませんいくつかの既知の優先順位が課されていることを確実にすることによって。
The syntax and semantics of the Midcom protocol must be extensible to allow the requirements of future applications to be adopted.
MIDCOMプロトコルの構文とセマンティクスは、将来のアプリケーションの要件を採用することができるように拡張可能でなければなりません。
This is related to, but different from, the requirement for versioning support. As support for additional middlebox types is added there may be a need to add new message types.
これは、サポートをバージョン管理の要件に関連するが異なっています。追加のミドルタイプのサポートが追加されると、新しいメッセージタイプを追加する必要があるかもしれません。
The Midcom protocol must support the ability of an agent to install a ruleset that governs multiple types of middlebox actions (e.g. firewall and NAT).
MIDCOMプロトコルはミドルアクション（例えば、ファイアウォールやNAT）の複数のタイプを支配するルールセットをインストールする薬剤の能力をサポートしている必要があります。
This states that a the protocol must support rules and actions for a variety of types of middleboxes. A Midcom agent ought to be able to have a single Midcom session with a middlebox and use the Midcom interface on the middlebox to interface with different middlebox functions on the same middlebox interface.
これは、プロトコルがミドルボックスの様々なタイプのためのルールとアクションをサポートしなければならないと述べています。 MIDCOMエージェントは、ミドルボックスを持つ単一のMIDCOMセッションを有し、同一のミドル・インターフェース上の異なるミドル機能とインターフェースするミドルにMIDCOMインターフェイスを使用することができるようにするべきです。
The protocol must support the concept of a ruleset group comprising a multiple of individual rulesets to be treated as an aggregate.
プロトコルは、集合体として処理されるべき個々のルールセットの複数を含むルールセットグループの概念をサポートしなければなりません。
Applications using more than one data stream may find it more convenient and more efficient to be able to use single messages to tear down, extend, and manipulate all middlebox rulesets being used by one instance of the application.
それはより便利で、より効率的かもしれません複数のデータストリームを使用するアプリケーションは、取り壊す延び、全てミドルルールセットは、アプリケーションの1つのインスタンスによって使用されている操作する単一のメッセージを使用できるようにします。
The protocol must allow the midcom agent to extend the lifetime of an existing ruleset that otherwise would be deleted by the middlebox.
プロトコルはMIDCOMエージェントは、そうでない場合は、ミドルで削除される既存のルールセットの寿命を延長できるようにする必要があります。
If a peer does not understand an option, it must be clear whether the action required is to proceed without the unknown attribute being taken into account or the request is to be rejected. Where attributes may be ignored if not understood, a means may be provided to inform the client about what has been ignored.
ピアがオプションを理解していない場合は、必要なアクションが不明な属性が考慮されているか、要求が拒否されることなく、続行するかどうかを明確にする必要があります。理解されていない場合は、属性を無視することができる場合には、手段が無視されてきたかについてクライアントに通知するために設けられてもよいです。
This states that failure modes must be robust, providing sufficient information for the agent or middlebox, to be able to accommodate the failure or to retry with a new option that is more likely to succeed.
これは、障害に対応するためにか、成功する可能性が高くなり、新たなオプションを指定して再試行することができるように、エージェントやミドルのための十分な情報を提供し、故障モードは、堅牢でなければならないと述べています。
To enable management systems to interact with the Midcom environment, the protocol must include failure reasons that allow the Midcom Agent behavior to be modified as a result of the information contained in the reason. Failure reasons need to be chosen such that they do not make an attack on security easier.
MIDCOM環境と対話するための管理システムを有効にするには、プロトコルはMIDCOMエージェントの動作が理由に含まれている情報の結果として修正することができるように、障害の理由を含める必要があります。失敗の理由は、彼らがより簡単にセキュリティ上の攻撃をしないように選択する必要があります。
The Midcom protocol must not preclude multiple authorized agents from working on the same ruleset.
MIDCOMプロトコルは、同じルールセットに取り組んでから複数の認可のエージェントを排除してはなりません。
The Midcom protocol must be able to carry filtering rules, including but not limited to the 5-tuple, from the midcom agent to the middlebox.
MIDCOMプロトコルはMIDCOMエージェントからミドルに、5タプルに限定されるものではないが、フィルタリングルールを運ぶことができなければなりません。
By "5-tuple", we refer to the standard <source address, source port, destination address, destination port, transport protocol> tuple. Other filtering elements may be carried, as well.
「5タプル」によって、我々は、標準の<送信元アドレス、送信元ポート、宛先アドレス、宛先ポート、トランスポートプロトコル>タプルを参照してください。他のフィルタ要素は、同様に、実施することができます。
When the middlebox performs a port mapping function, the protocol should allow the Midcom agent to request that the external port number have the same oddity as the internal port.
ミドルボックスは、ポートマッピング機能を行う場合、プロトコルはMIDCOMエージェントは外部ポート番号、内部ポートと同じ奇妙を有することを要求することを可能にするべきです。
This requirement is to support RTP and RTCP [RFC1889] "oddity" requirements.
この要件は、RTPとRTCP [RFC1889]「奇妙」な要件をサポートすることです。
When the middlebox performs a port mapping function, the protocol should allow the Midcom agent to request that a consecutive range of external port numbers be mapped to consecutive internal ports. This requirement is to support RTP and RTCP "sequence" requirements.
ミドルボックスは、ポートマッピング機能を行う場合、プロトコルはMIDCOMエージェントは外部ポート番号の連続した範囲は連続内部ポートにマッピングされることを要求することを可能にするべきです。この要件は、RTPとRTCP「シーケンス」の要件をサポートすることです。
It should be possible to define rulesets that contain a more specific filter spec than an overlapping ruleset. This should allow agents to request actions for the subset that contradict those of the overlapping set.
重複ルールセットよりも多くの特定のフィルタ仕様が含まれているルールセットを定義することが可能です。これは、エージェントが重複セットのものと矛盾するサブセットのためのアクションを要求できるようにする必要があります。
This should allow a Midcom agent to request to a Midcom server controlling a firewall function that a subset of the traffic that would be allowed by the overlapping ruleset be specifically disallowed.
これはMIDCOMエージェントは、重複ルールセットで許されるトラフィックのサブセットが特に禁止するファイアウォール機能を制御MIDCOMサーバに要求できるようにする必要があります。
The Midcom protocol must provide for message authentication, confidentiality, and integrity.
MIDCOMプロトコルは、メッセージ認証、機密性、および整合性のために提供しなければなりません。
The Midcom protocol must allow for optional confidentiality protection of control messages. If provided, the mechanism should allow a choice in the algorithm to be used.
MIDCOMプロトコルは、制御メッセージのオプションの機密性保護のために許可する必要があります。提供されている場合、この機構は、アルゴリズムにおける選択が使用できるようにする必要があります。
The Midcom protocol must operate across un-trusted domains, between the Midcom agent and middlebox in a secure fashion.
MIDCOMプロトコルは、安全な方法でMIDCOM剤とミドル間、非信頼ドメイン間で動作しなければなりません。
The Midcom protocol must define mechanisms to mitigate replay attacks on the control messages.
MIDCOMプロトコルは、制御メッセージのリプレイ攻撃を軽減するためのメカニズムを定義する必要があります。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use other technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 Secretariat.
IETFは、実装に関連するか、そのような権限下で、ライセンスがまたは使用できない場合がありますしている。この文書または範囲に記載されている他の技術を使用することを主張している可能性のある知的財産やその他の権利の有効性または範囲に関していかなる位置を取りません;また、そうした権利を特定するために取り組んできたことを表していないん。スタンダードトラックおよび標準関連文書における権利に関するIETFの手続きの情報は、BCP-11に記載されています。権利の主張のコピーは、出版のために利用可能とライセンスの保証が利用できるようにする、あるいは本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、その注意にこの標準を実践するために必要な場合があり技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 IETF専務に情報を扱ってください。
The security requirements for a midcom protocol are discussed in section 2.3.
MIDCOMプロトコルのセキュリティ要件は、セクション2.3で説明されています。
[MCFW] Srisuresh, S., Kuthan, J., Rosenberg, J., Molitor, A. and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, Date.*
【MCFW] Srisuresh、S.、Kuthan、J.、ローゼンバーグ、J.、モリター、A.及びA. Rayhan、 "ミドル通信アーキテクチャおよびフレームワーク"、RFC 3303、日付*
[RFC1889] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[RFC1889] Schulzrinneと、H.、Casner、S.、フレデリック、R.とV. Jacobson氏、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、RFC 1889、1996年1月。
[RFC2026] Bradner, S. "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026. October 1996.
[RFC2026]ブラドナーの、S. "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026 1996年10月。
Authors' Addresses
著者のアドレス
Richard Swale BTexact Technologies Callisto House Adastral Park Ipswich United Kingdom EMail: richard.swale@bt.com
リチャードSwale BTexactテクノロジーズカリストハウスAdastral公園イプスウィッチイギリスメール：richard.swale@bt.com
Paul Sijben Lucent Technologies EMEA BV Huizen Netherlands EMail: paul.sijben@picopoint.com
ポールSijbenルーセント・テクノロジーズEMEA BVオランダ住宅Eメール：paul.sijben@picopoint.com
Philip Mart Marconi Communications Ltd. Edge Lane Liverpool United Kingdom EMail: philip.mart@marconi.com
フィリップ・マートマルコーニコミュニケーションズ株式会社エッジレーンリバプールイギリスメール：philip.mart@marconi.com
Scott Brim Cisco Systems 146 Honness Lane Ithaca, NY 14850 EMail: sbrim@cisco.com
スコット・ブリムシスコシステムズ146 Honnessレーンイサカ、NY 14850 Eメール：sbrim@cisco.com
Melinda Shore Cisco Systems 809 Hayts Road Ithaca, NY 14850 EMail: mshore@cisco.com
メリンダ・ショアシスコシステムズ809 Hayts道路イサカ、NY 14850 Eメール：mshore@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。