[要約] RFC 3304は、中間ボックス通信（midcom）プロトコルの要件を定義しており、中間ボックス間の通信を効率的に行うためのガイドラインを提供しています。このRFCの目的は、中間ボックス通信の標準化と相互運用性の向上を促進することです。
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
Middlebox Communications（MIDCOM）プロトコル要件
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（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.
このドキュメントは、Middleboxコミュニケーション（MIDCOM）プロトコルが、Middlebox機能に影響を与えたいアプリケーションのニーズを満たすために満たさなければならない要件を指定します。これらの要件は、ネットワークアドレスの変換とファイアウォールミドルボックスに特に焦点を当てて開発されました。
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.
このドキュメントは、Middleboxコミュニケーション（MIDCOM）ワーキンググループによって開発された2つのうちの1つで、Middleboxと「Midcomエージェント」の間のプロトコルの要件とフレームワークに対処します。このドキュメントには、Midcomの要件が示されています。[MCFW]は、コンテキストとフレームワークを提示します。[MCFW]も用語と定義を提示し、これと並行して読む必要があります。
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]で定義されています。要件間に重複がある場合があります。
2.1.1.
2.1.1。
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.
これは、プロトコルにより、ミドルボックスがサービスを要求するエージェントを識別し、エージェントがそうすることが許可されるかどうかを決定することを許可する必要があると述べています。
2.1.2.
2.1.2。
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.
最も単純なネットワーク以外の場合、エージェントは複数のミドルボックスの動作に影響を与えたいと考えています。プロトコル設計は、これを行う能力を排除してはなりません。
2.1.3.
2.1.3。
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.
単一のマイルドボックスからサービスを希望する単一のアプリケーションまたは複数のアプリケーションの複数のインスタンスがあり、異なるエージェントがそれらを表す場合があります。プロトコル設計は、そうする能力を排除してはなりません。
2.1.4.
2.1.4。
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.
これは、プロトコルには、あるエージェントの要求が他のエージェントの要求の結果に予測不可能な方法で影響を与える可能性がある人種条件やその他の状況を回避するためのメカニズムを含める必要があると述べています。
2.1.5.
2.1.5。
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プロトコルに関してアトミックでなければならないことを示しています。
2.1.6.
2.1.6。
The middlebox must be able to report its status to a Midcom agent with which it is associated.
ミドルボックスは、そのステータスを関連付けられているMIDCOMエージェントに報告できる必要があります。
2.1.7.
2.1.7。
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.
Middleboxでの例外的な条件またはその他のイベント（リソース不足、侵入緩和）により、関連するMidcomエージェントに相談することなく、ミドルボックスがピンホールを閉じたり、リソースをリリースしたりする可能性があります。その場合、プロトコルはミドルボックスにエージェントに通知できるようにする必要があります。
2.1.8.
2.1.8。
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]を参照してください。
2.1.9.
2.1.9。
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セッションを終了することを許可する必要があります。これにより、エンティティがメンテナンス、セキュリティ、またはその他の理由でセッションを閉じることができます。
2.1.10.
2.1.10。
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.
これは、ミドルボックスがエージェントのリクエストに成功または失敗の兆候を返す必要があると述べています。
2.1.11.
2.1.11。
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との通信に焦点を当て、他のミドルボックスタイプのサポートが追加されているため、プロトコルを変更する必要がある可能性があります。これらのバージョンインターワーキング機能には、プロトコルバージョン番号が含まれる（ただし、これらに限定されない）ことがあります。
2.1.12.
2.1.12。
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.
プロトコルは、重複するルールセットの場合、非決定的行動を排除する必要があります。既知の優先順位が課されるようにすることにより。
2.2.1.
2.2.1。
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.
これは、バージョン化サポートの要件に関連していますが、異なります。追加のミドルボックスタイプのサポートが追加されるため、新しいメッセージタイプを追加する必要がある場合があります。
2.2.2.
2.2.2。
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セッションを1つ持ち、MidcomインターフェイスをMidcomインターフェイスを使用して、同じミドルボックスインターフェイス上の異なるミドルボックス関数とのインターフェースを使用できるはずです。
2.2.3.
2.2.3。
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つのインスタンスで使用されているすべてのミドルボックスルールセットを取り壊し、拡張し、操作できるようにする方が便利で効率的であることがわかります。
2.2.4.
2.2.4。
The protocol must allow the midcom agent to extend the lifetime of an existing ruleset that otherwise would be deleted by the middlebox.
このプロトコルは、MIDCOMエージェントが、そうでなければミドルボックスによって削除される既存のルールセットの寿命を延長できるようにする必要があります。
2.2.5.
2.2.5。
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.
これは、障害モードが堅牢であり、エージェントまたはミドルボックスに十分な情報を提供し、障害に対応したり、成功する可能性が高い新しいオプションで再試行できるようにする必要があると述べています。
2.2.6.
2.2.6。
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エージェントの動作を変更できる障害理由を含める必要があります。セキュリティへの攻撃を容易にしないように、失敗の理由を選択する必要があります。
2.2.7.
2.2.7。
The Midcom protocol must not preclude multiple authorized agents from working on the same ruleset.
MIDCOMプロトコルは、複数の認定エージェントが同じルールセットに取り組むことを妨げてはなりません。
2.2.8.
2.2.8。
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-Tuple」とは、標準の<ソースアドレス、ソースポート、宛先アドレス、宛先ポート、トランスポートプロトコル>タプルを参照します。他のフィルタリング要素も運ばれる場合があります。
2.2.9.
2.2.9。
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]「奇妙な」要件をサポートすることです。
2.2.10.
2.2.10。
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の「シーケンス」要件をサポートすることです。
2.2.11.
2.2.11。
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サーバーに要求することができます。
2.3.1.
2.3.1。
The Midcom protocol must provide for message authentication, confidentiality, and integrity.
MIDCOMプロトコルは、メッセージ認証、機密性、および完全性を提供する必要があります。
2.3.2.
2.3.2。
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プロトコルは、制御メッセージのオプションの機密保護を許可する必要があります。提供されている場合、メカニズムはアルゴリズムの選択を使用できるようにする必要があります。
2.3.3.
2.3.3。
The Midcom protocol must operate across un-trusted domains, between the Midcom agent and middlebox in a secure fashion.
MIDCOMプロトコルは、MIDCOMエージェントとミドルボックスの間で、安全な方法で、信頼されていないドメイン全体で動作する必要があります。
2.3.4.
2.3.4。
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.、Rosenberg、J.、Molitor、A。and A. Rayhan、「Middlebox Communication Architecture and Framework」、RFC 3303、date。*
[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.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、RFC 1889、1996年1月。
[RFC2026] Bradner, S. "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026. October 1996.
[RFC2026] Bradner、S。
Authors' Addresses
著者のアドレス
Richard Swale BTexact Technologies Callisto House Adastral Park Ipswich United Kingdom EMail: richard.swale@bt.com
リチャード・スウォールBtexactテクノロジーズカリストハウスアダストラルパークイプスウィッチイギリスメールメール：richard.swale@bt.com
Paul Sijben Lucent Technologies EMEA BV Huizen Netherlands EMail: paul.sijben@picopoint.com
Paul Sijben Lucent Technologies EMEA BV HUIZEN OTHERLANDSメール：paul.sijben@picopoint.com
Philip Mart Marconi Communications Ltd. Edge Lane Liverpool United Kingdom EMail: philip.mart@marconi.com
Philip Mart Marconi Communications Ltd. Edge Lane Liverpool United Kingdom Email：Philip.mart@marconi.com
Scott Brim Cisco Systems 146 Honness Lane Ithaca, NY 14850 EMail: sbrim@cisco.com
Scott Brim Cisco Systems 146 Honness Lane Ithaca、NY 14850メール：sbrim@cisco.com
Melinda Shore Cisco Systems 809 Hayts Road Ithaca, NY 14850 EMail: mshore@cisco.com
Melinda Shore Cisco Systems 809 Hayts Road Ithaca、NY 14850メール：mshore@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。