Network Working Group P. Srisuresh
Request for Comments: 3303 Kuokoa Networks
Category: Informational J. Kuthan
Fraunhofer Institute FOKUS
J. Rosenberg
dynamicsoft
A. Molitor
Aravox Technologies
A. Rayhan
Ryerson University
August 2002
Middlebox communication architecture and framework
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
抽象
A principal objective of this document is to describe the underlying framework of middlebox communications (MIDCOM) to enable complex applications through the middleboxes, seamlessly using a trusted third party. This document and a companion document on MIDCOM requirements ([REQMTS]) have been created as a precursor to rechartering the MIDCOM working group.
この文書の主な目的は、シームレスに、信頼できるサードパーティを使用して、中間装置を介して複雑なアプリケーションを可能にするために、ミドル通信（MIDCOM）の基礎となるフレームワークを記述することです。この文書とMIDCOM要件（[REQMTS]）上の仲間ドキュメントはMIDCOMワーキンググループをrecharteringへの前駆体として作成されています。
There are a variety of intermediate devices in the Internet today that require application intelligence for their operation. Datagrams pertaining to real-time streaming applications, such as SIP and H.323, and peer-to-peer applications, such as Napster and NetMeeting, cannot be identified by merely examining packet headers. Middleboxes implementing Firewall and Network Address Translator services typically embed application intelligence within the device for their operation. The document specifies an architecture and framework in which trusted third parties can be delegated to assist the middleboxes to perform their operation, without resorting to embedding application intelligence. Doing this will allow a middlebox to continue to provide the services, while keeping the middlebox application agnostic.
その動作のためのアプリケーションインテリジェンスを必要と今日のインターネットにおける中間デバイスの様々なものがあります。そのようなSIPやH.323などのリアルタイムストリーミングアプリケーション、および、そのようなナップスターやNetMeetingなどのピアツーピアアプリケーションに関連するデータグラムは、単にパケットのヘッダを調べることによって識別することができません。ファイアウォールとネットワークアドレス変換サービスを実装するミドルボックスは、典型的には、その操作のための装置内のアプリケーションインテリジェンスを埋め込みます。文書は、信頼できるサードパーティがアプリケーションインテリジェンスを埋め込むに頼ることなく、自分の操作を実行するミドルボックスを支援するために委任することができるアーキテクチャとフレームワークを指定します。これを行うと、ミドルはとらわれないミドルアプリケーションを維持しながら、サービスを提供し続けることができます。
Intermediate devices requiring application intelligence are the subject of this document. These devices are referred to as middleboxes throughout the document. Many of these devices enforce application specific policy based functions such as packet filtering, VPN (Virtual Private Network) tunneling, Intrusion detection, security and so forth. Network Address Translator service, on the other hand, provides routing transparency across address realms (within IPv4 routing network or across V4 and V6 routing realms), independent of applications. Application Level Gateways (ALGs) are used in conjunction with NAT to examine and optionally modify application payload so the end-to-end application behavior remains unchanged for many of the applications traversing NAT middleboxes. There may be other types of services requiring embedding application intelligence in middleboxes for their operation. The discussion scope of this document is however limited to Firewall and NAT services. Nonetheless, the MIDCOM framework is designed to be extensible to support the deployment of new services.
アプリケーションインテリジェンスを必要とする中間デバイスは、本書の主題です。これらのデバイスは、文書全体ミドルボックスと呼ばれています。これらのデバイスの多くは、このような等々パケットフィルタリング、VPN（仮想プライベートネットワーク）トンネリング、侵入検知、セキュリティ、およびなどのアプリケーション固有のポリシーベースの機能を強化します。ネットワークアドレス変換サービスは、一方で、アプリケーションとは独立してアドレスレルム（IPv4ルーティングネットワーク内またはV4およびV6ルーティングレルム横切って）、横切ってルーティング透明性を提供します。アプリケーションレベルゲートウェイ（のALG）が検討し、エンドツーエンドのアプリケーションの動作がNATミドルボックスを横断するアプリケーションの多くは変更されませんので、必要に応じてアプリケーションペイロードを変更するNATと組み合わせて使用されています。その動作のためのミドルボックス内のアプリケーションインテリジェンスを埋め込む必要とするサービスの他のタイプがあるかもしれません。本書の議論の範囲は、しかし、ファイアウォールやNATサービスに限定されています。それにもかかわらず、MIDCOMフレームワークは、新たなサービスの展開をサポートするために拡張できるように設計されています。
Tight coupling of application intelligence with middleboxes makes maintenance of middleboxes hard with the advent of new applications. Built-in application awareness typically requires updates of operating systems with new applications or newer versions of existing applications. Operators requiring support for newer applications will not be able to use third party software/hardware specific to the application and are at the mercy of their middlebox vendor to make the necessary upgrade. Further, embedding intelligence for a large number of application protocols within the same middlebox increases complexity of the middlebox and is likely to be error prone and degrade in performance.
ミドルボックスとアプリケーションインテリジェンスの緊密な結合は、新しいアプリケーションの出現により、ハードミドルボックスのメンテナンスを行います。内蔵アプリケーション認識通常、新しいアプリケーションや既存のアプリケーションの新しいバージョンとオペレーティング・システムの更新が必要です。新しいアプリケーションのサポートを必要とする事業者は、アプリケーションに固有のサードパーティ製のソフトウェア/ハードウェアを使用することができるよう、必要なアップグレードを行うために彼らのミドルベンダーのなすがままにされません。さらに、同じミドルボックス内のアプリケーションプロトコルの多数の知性を埋め込むことミドルの複雑さを増加させ、エラーが発生しやすいことや性能が劣化する可能性があります。
This document describes a framework in which application intelligence can be moved from middleboxes into external MIDCOM agents. The premise of the framework is to devise a MIDCOM protocol that is application independent, so the middleboxes can stay focused on services such as firewall and NAT. The framework document includes some explicit and implied requirements for the MIDCOM protocol. However, it must be noted that these requirements are only a subset. A separate requirements document lists the requirements in detail.
この文書では、アプリケーションインテリジェンスは、外部のMIDCOMエージェントにミドルボックスから移動することが可能なフレームワークを記述しています。フレームワークの前提はアプリケーションに依存しているMIDCOMプロトコルを考案することであるので、ミドルボックスは、ファイアウォールやNATなどのサービスに集中することができます。枠組み文書はMIDCOMプロトコルのためのいくつかの明示的および暗黙の要件が含まれています。しかし、これらの要件は一部のみであることに留意しなければなりません。個別の要件文書を詳細に要件を示します。
MIDCOM agents with application intelligence can assist the middleboxes through the MIDCOM protocol in permitting applications such as FTP, SIP and H.323. The communication between a MIDCOM agent and a middlebox will not be noticeable to the end-hosts that take part in the application, unless one of the end-hosts assumes the role of a MIDCOM agent. Discovery of middleboxes or MIDCOM agents in the path of an application instance is outside the scope of this document. Further, any communication amongst middleboxes is also outside the scope of this document.
アプリケーションインテリジェンスとMIDCOM剤は、FTP、SIPやH.323などのアプリケーションを可能にMIDCOMプロトコルを介して中間装置を支援することができます。 MIDCOMエージェントとミドルとの間の通信は、エンドホストの一つはMIDCOMエージェントの役割を想定していない限り、アプリケーションに参加するエンドホストに顕著ではありません。アプリケーションインスタンスのパスにおける中間装置又はMIDCOM剤の発見は、この文書の範囲外です。さらに、中間装置の間で任意の通信は、この文書の範囲外でもあります。
This document describes the framework in which middlebox communication takes place and the various elements that constitute the framework. Section 2 describes the terms used in the document. Section 3 defines the architectural framework of a middlebox for communication with MIDCOM agents. The remaining sections cover the components of the framework, illustration using sample flows, and operational considerations with the MIDCOM architecture. Section 4 describes the nature of MIDCOM protocol. Section 5 identifies entities that could potentially host the MIDCOM agent function. Section 6 considers the role of Policy server and its function with regard to communicating MIDCOM agent authorization policies. Section 7 is an illustration of SIP flows using a MIDCOM framework in which the MIDCOM agent is co-resident on a SIP proxy server. Section 8 addresses operational considerations in deploying a protocol adhering to the framework described here. Section 9 is an applicability statement, scoping the location of middleboxes. Section 11 outlines security considerations for the middlebox in view of the MIDCOM framework.
この文書では、ミドルボックスの通信およびフレームワークを構成する様々な要素をとるフレームワークを記述する。第2節では、文書内で使用される用語を説明しています。セクション3はMIDCOMエージェントと通信するためのミドルのアーキテクチャフレームワークを定義します。残りのセクションはMIDCOMアーキテクチャとフレームワークのコンポーネント、サンプルフローを用いて説明図、及び動作の考慮を覆います。第4章ではMIDCOMプロトコルの性質を説明しています。第5節では、潜在的にMIDCOMエージェント機能をホストする可能性がありますエンティティを識別します。第6節はMIDCOMエージェントの認可ポリシーを通信に関するポリシーサーバとその機能の役割を検討します。セクション7は、SIPの説明図であるMIDCOMエージェントは、SIPプロキシサーバ上で共存であるMIDCOMフレームワークを使用して流れます。第8章アドレスここで説明するフレームワークに付着したプロトコルを展開における動作の配慮。第9章は、ミドルボックスの場所をスコープ、適用文です。 11節はMIDCOMフレームワークの観点から、ミドルのためのセキュリティの考慮事項について概説します。
Below are the definitions for the terms used throughout the document.
以下は、文書全体で使用される用語の定義があります。
A middlebox function or a middlebox service is an operation or method performed by a network intermediary that may require application specific intelligence for its operation. Policy based packet filtering (a.k.a. firewall), Network address translation (NAT), Intrusion detection, Load balancing, Policy based tunneling and IPsec security are all examples of a middlebox function (or service).
ミドルボックス機能やミドルサービスは、その動作のためのアプリケーション固有のインテリジェンスを必要とするかもしれないネットワーク中継の動作又は方法です。ポリシーベースのパケットフィルタリング（別名、ファイアウォール）、ネットワークアドレス変換（NAT）、侵入検知、負荷分散、ポリシーベースのトンネリングおよびIPsecセキュリティすべてのミドル機能（またはサービス）の例です。
A Middlebox is a network intermediate device that implements one or more of the middlebox services. A NAT middlebox is a middlebox implementing NAT service. A firewall middlebox is a middlebox implementing firewall service.
ミドルはミドルサービスの一つ以上を実装するネットワーク中継装置です。 NATミドルは、NATサービスを実装するミドルです。ファイアウォールミドルは、ファイアウォールサービスを実装するミドルです。
Traditional middleboxes embed application intelligence within the device to support specific application traversal. Middleboxes supporting the MIDCOM protocol will be able to externalize application intelligence into MIDCOM agents. In reality, some of the middleboxes may continue to embed application intelligence for certain applications and depend on MIDCOM protocol and MIDCOM agents for the support of remaining applications.
従来のミドルボックスは、特定のアプリケーショントラバーサルをサポートするために、デバイス内のアプリケーションインテリジェンスを埋め込みます。 MIDCOMプロトコルをサポートするミドルボックスはMIDCOMエージェントにアプリケーションインテリジェンスを外部化することができるようになります。現実には、ミドルボックスの一部は、特定のアプリケーションのためのアプリケーションインテリジェンスを埋め込み、残りのアプリケーションをサポートするためにMIDCOMプロトコルとMIDCOMエージェントに依存し続けることができます。
Firewall is a policy based packet filtering middlebox function, typically used for restricting access to/from specific devices and applications. The policies are often termed Access Control Lists (ACLs).
ファイアウォールは、典型的には、特定のデバイスおよびアプリケーションへの/からのアクセスを制限するために使用されるポリシーベースのパケットフィルタリングミドル機能、です。ポリシーは、多くの場合、アクセス制御リスト（ACL）と呼ばれています。
Network Address Translation is a method by which IP addresses are mapped from one address realm to another, providing transparent routing to end-hosts. Transparent routing here refers to modifying end-node addresses en-route and maintaining state for these updates so that when a datagram leaves one realm and enters another, datagrams pertaining to a session are forwarded to the right end-host in either realm. Refer to [NAT-TERM] for the definition of Transparent routing, various NAT types, and the associated terms in use. Two types of NAT are most common. Basic-NAT, where only an IP address (and the related IP, TCP/UDP checksums) of packets is altered and NAPT (Network Address Port Translation), where both an IP address and a transport layer identifier, such as a TCP/UDP port (and the related IP, TCP/UDP checksums), are altered.
ネットワークアドレス変換は、IPアドレスが、ホストを終了する透明なルーティングを提供する、別のアドレス領域からマッピングされる方法です。ここで、透明ルーティングは専用ルートエンドノードのアドレスを変更すると、データグラム一の領域を出て別のものを入力したときに、セッションに関連するデータグラムは、いずれかの領域に右エンドホストに転送されるように、これらの更新の状態を維持することをいいます。透明ルーティング、様々なNATのタイプ、および使用中の関連する用語の定義については、[NAT-TERM]を参照。 NATの二つのタイプが最も一般的です。パケットの唯一のIPアドレス（および関連するIP、TCP / UDPチェックサム）が変更され、基本NAT、NAPT（ネットワークポート変換アドレス）、ここで、そのようなTCP / UDPなどのIPアドレス及びトランスポート層識別子、両方ポート（および関連するIP、TCP / UDPチェックサム）は、変更されています。
The term NAT in this document is very similar to the IPv4 NAT described in [NAT-TERM], but is extended beyond IPv4 networks to include the IPv4-v6 NAT-PT described in [NAT-PT]. While the IPv4 NAT [NAT-TERM] translates one IPv4 address into another IPv4 address to provide routing between private V4 and external V4 address realms, IPv4-v6 NAT-PT [NAT-PT] translates an IPv4 address into an IPv6 address, and vice versa, to provide routing between a V6 address realm and an external V4 address realm.
この文書における用語のNATは、IPv4 NATは、[NAT-TERM]で説明するのは非常に類似しているが、NAT-PTは、[NAT-PT〕に記載のIPv4-V6を含むようにIPv4ネットワークを越えて拡張されます。 IPv4のNAT [NAT-TERM]はプライベートV4と外部V4アドレスレルム間のルーティングを提供するために別のIPv4アドレスに1つのIPv4アドレスを変換しながら、IPv4にV6のNAT-PT [NAT-PT]は、IPv6アドレスにIPv4アドレスを変換し、そしてその逆、V6アドレス領域と外部V4アドレスレルム間のルーティングを提供します。
Unless specified otherwise, NAT in this document is a middlebox function referring to both IPv4 NAT, as well as IPv4-v6 NAT-PT.
特に断りのない限り、この文書に記載されているNATは、IPv4 NAT、ならびにIPv4にV6のNAT-PTの両方を参照ミドル関数です。
A proxy is an intermediate relay agent between clients and servers of an application, relaying application messages between the two. Proxies use special protocol mechanisms to communicate with proxy clients and relay client data to servers and vice versa. A Proxy terminates sessions with both the client and the server, acting as server to the end-host client and as client to the end-host server.
プロキシは、二つの間のアプリケーションメッセージを中継する、アプリケーションのクライアントとサーバとの間の中間中継エージェントです。プロキシは、プロキシクライアントと通信し、サーバおよびその逆に、クライアントのデータを中継するために、特別なプロトコルメカニズムを使用します。プロキシは、エンドホストクライアントへとエンドホストサーバーへのクライアントとしてサーバーとして動作し、クライアントとサーバーの両方とのセッションを終了します。
Applications such as FTP, SIP, and RTSP use a control session to establish data sessions. These control and data sessions can take divergent paths. While a proxy can intercept both the control and data sessions, it might intercept only the control session. This is often the case with real-time streaming applications such as SIP and RTSP.
このようFTP、SIP、およびRTSPなどのアプリケーションは、データセッションを確立するために、制御セッションを使用します。これらの制御とデータのセッションが発散パスを取ることができます。プロキシは制御およびデータセッションの両方を傍受することができますが、それだけで制御セッションを傍受することがあります。これは、多くの場合、そのようなSIPやRTSPなどのリアルタイムストリーミングアプリケーションの場合です。
Application Level Gateways (ALGs) are entities that possess the application specific intelligence and knowledge of an associated middlebox function. An ALG examines application traffic in transit and assists the middlebox in carrying out its function.
アプリケーションレベルゲートウェイ（のALG）は、関連するミドル関数のアプリケーション固有の知性と知識を持っているエンティティです。 ALGは、輸送中にアプリケーショントラフィックを検査し、その機能を実行するにはミドルを支援します。
An ALG may be a co-resident with a middlebox or reside externally, communicating through a middlebox communication protocol. It interacts with a middlebox to set up state, access control filters, use middlebox state information, modify application specific payload, or perform whatever else is necessary to enable the application to run through the middlebox.
ALGは、ミドルボックスと共存すること又はミドル通信プロトコルを介して通信し、外部に存在することができます。それは、状態を設定するために、ミドルと相互作用し、アクセス制御フィルタ、ミドル状態情報を使用して、アプリケーション固有のペイロードを変更、またはミドルを介して実行するアプリケーションを有効にする必要がある任意の他行います。
ALGs are different from proxies. ALGs are not visible to end-hosts, unlike the proxies which are relay agents terminating sessions with both end-hosts. ALGs do not terminate sessions with either end-host. Instead, ALGs examine, and optionally modify, application payload content to facilitate the flow of application traffic through a middlebox. ALGs are middlebox centric, in that they assist the middleboxes in carrying out their function, whereas, the proxies act as a focal point for application servers, relaying traffic between application clients and servers.
ALGは、プロキシとは異なります。 ALGは、両方のエンドホストとのセッションを終了するリレーエージェントであるプロキシとは異なり、-ホストを終了するには見えません。 ALGは、どちらかのエンドホストとのセッションを終了しません。その代わりに、のALGは、ミドルボックスを介してアプリケーショントラフィックの流れを促進するために調べ、必要に応じて変更し、アプリケーションペイロードコンテンツ。 ALGは、プロキシは、アプリケーション・クライアントとサーバ間のトラフィックを中継する、アプリケーション・サーバのためのフォーカルポイントとして機能、一方でその中で彼らは、その機能を実行するにはミドルボックスを支援する、ミドル中心です。
ALGs are similar to Proxies, in that, both ALGs and proxies facilitate Application specific communication between clients and servers.
ALGは、その中で、のALGとプロキシの両方が、クライアントとサーバとの間のアプリケーション固有の通信を容易にする、プロキシと同様です。
End-hosts are entities that are party to a networked application instance. End-hosts referred to in this document, are specifically those terminating Real-time streaming Voice-over-IP applications, such as SIP and H.323, and peer-to-peer applications such as Napster and NetMeeting.
エンドホストは、ネットワークアプリケーションインスタンスの当事者であるエンティティです。この文書で言及エンドホストは、特にそれらの終了リアルタイムストリーミングなどSIPやH.323などのボイスオーバーIPアプリケーション、および、そのようなナップスターやNetMeetingなどのピアツーピアアプリケーションです。
MIDCOM agents are entities performing ALG functions, logically external to a middlebox. MIDCOM agents possess a combination of application awareness and knowledge of the middlebox function. This combination enables the agents to facilitate traversal of the middlebox by the application's packets. A MIDCOM agent may interact with one or more middleboxes.
MIDCOMエージェントはミドルと論理的に外部のALG機能を実行するエンティティです。 MIDCOMエージェントはミドル機能のアプリケーション意識と知識の組み合わせを持っています。この組み合わせは、アプリケーションのパケットによってミドルの横断を容易にするための薬剤を可能にします。 MIDCOMエージェントは、一つ以上のミドルボックスと相互作用することができます。
Only "In-Path MIDCOM agents" are considered in this document. In-Path MIDCOM agents are agents which are within the path of those datagrams that the agent needs to examine and/or modify in fulfilling its role as a MIDCOM agent. "Within the path" here simply means that the packets in question flow through the node that hosts the agent. The packets may be addressed to the agent node at the IP layer. Alternatively they may not be addressed to the agent node, but may be constrained by other factors to flow through it. In fact, it is immaterial to the MIDCOM protocol which of these is the case. Some examples of In-Path MIDCOM agents are application proxies, gateways, or even end-hosts that are party to the application.
唯一の「インパスMIDCOMエージェントは、」この文書では考慮されています。でパスMIDCOMエージェントは、エージェントがMIDCOMエージェントとしての役割を果たしに検討および/または変更する必要があり、これらのデータグラムのパス内にある薬剤です。 「パスの中で」ここ単に問題のパケットがエージェントをホストするノードに流れることを意味します。パケットはIP層でのエージェントノードにアドレス指定することができます。あるいは、それらは、エージェントノードにアドレス指定されないことがあり、それを通って流れるように他の要因によって制約されてもよいです。実際に、それはそうであるこれらのMIDCOMプロトコルに重要ではありません。インパスのMIDCOMエージェントのいくつかの例は、アプリケーションプロキシ、ゲートウェイ、あるいはアプリケーションの当事者であるエンドホストされています。
Agents not resident on nodes that are within the path of their relevant application flows are referred to as "Out-of-Path (OOP) MIDCOM agents" and are out of the scope of this document.
それらの関連するアプリケーション・フローの経路内にあるノードに常駐していないエージェントは、「アウトオブパス（OOP）MIDCOM剤」と呼ばれ、この文書の範囲外されています。
MIDCOM Policy Decision Point (PDP) is primarily a Policy Decision Point(PDP), as defined in [POL-TERM]; and also acts as a policy repository, holding MIDCOM related policy profiles in order to make authorization decisions. [POL-TERM] defines a PDP as "a logical entity that makes policy decisions for itself or for other network elements that request such decisions"; and a policy repository as "a specific data store that holds policy rules, their conditions and actions, and related policy data".
[POL-TERM]で定義されるようにMIDCOMポリシー決定ポイント（PDP）は、主にポリシー決定ポイント（PDP）です。そしてまた、許可の決定を行うために、MIDCOM関連のポリシープロファイルを保持して、ポリシー・リポジトリとして機能します。 [POL-TERM]「は、それ自体、またはそのような決定を要求する他のネットワーク要素のポリシー決定を行う論理エンティティ」としてPDPを定義します。そして、「ポリシールール、その条件とアクション、および関連するポリシーデータを保持している特定のデータ・ストア」としてポリシー・リポジトリ。
A middlebox and a MIDCOM PDP may communicate further if the MIDCOM PDP's policy changes or if a middlebox needs further information. The MIDCOM PDP may, at anytime, notify the middlebox to terminate authorization for an agent.
ミドルとMIDCOM PDPはMIDCOM PDPのポリシーが変更された場合、またはミドルは、さらに情報が必要な場合、さらに通信することができます。 MIDCOM PDPは、いつでも、エージェントの許可を終了するミドルボックスを通知してもよいです。
The protocol facilitating the communication between a middlebox and MIDCOM PDP need not be part of the MIDCOM protocol. Section 6 in the document addresses the MIDCOM PDP interface and protocol framework independent of the MIDCOM framework.
ミドルとMIDCOM PDPとの間の通信を容易にするプロトコルはMIDCOMプロトコルの一部である必要はありません。文書内のセクション6はMIDCOMフレームワークの独立MIDCOM PDPインタフェースとプロトコルフレームワークに対処します。
Application specific policy data and policy interface between an agent or application endpoint and a MIDCOM PDP is out of bounds for this document. The MIDCOM PDP issues addressed in the document are focused at an aggregate domain level as befitting the middlebox. For example, a SIP MIDCOM agent may choose to query a MIDCOM PDP for the administrative (or corporate) domain to find whether a certain user is allowed to make an outgoing call. This type of application specific policy data, as befitting an end user, is out of bounds for the MIDCOM PDP considered in this document. It is within bounds, however, for the MIDCOM PDP to specify the specific end-user applications (or tuples) for which an agent is permitted to be an ALG.
エージェントまたはアプリケーション・エンドポイントとMIDCOM PDP間のアプリケーション固有のポリシーデータとポリシー・インターフェースは、この文書の範囲外です。文書で対処MIDCOM PDPの問題は、ミドルにふさわしいなどの集計ドメインレベルで集中しています。例えば、SIP MIDCOMエージェントは、特定のユーザーが発信通話を行うことが許可されているかどうかを見つけるために、行政（または企業）のドメインのMIDCOM PDPを照会することもできます。アプリケーション固有のポリシーデータのこのタイプは、エンドユーザにふさわしいように、本文書において考慮MIDCOMのPDP用の範囲外です。 MIDCOM PDPエージェントがALGが許可されている特定のエンドユーザアプリケーション（またはタプル）を指定することは、しかしながら、範囲内です。
The protocol between a MIDCOM agent and a middlebox allows the MIDCOM agent to invoke services of the middlebox and allow the middlebox to delegate application specific processing to the MIDCOM agent. The MIDCOM protocol allows the middlebox to perform its operation with the aid of MIDCOM agents, without resorting to embedding application intelligence. The principal motivation behind architecting this protocol is to enable complex applications through middleboxes, seamlessly using a trusted third party, i.e., a MIDCOM agent.
MIDCOMエージェントとミドル間のプロトコルはMIDCOM剤がミドルのサービスを呼び出すとミドルはMIDCOMエージェントにアプリケーション固有の処理を委譲することを可能にすることを可能にします。 MIDCOMプロトコルは、ミドルボックスは、アプリケーションインテリジェンスを埋め込むに頼ることなく、MIDCOM剤の助けを借りて、その動作を行うことができます。このプロトコルを設計の背後にある主要な動機は、シームレスに、信頼できる第三者、すなわち、MIDCOM剤を用いて、中間装置を介して複雑なアプリケーションを可能にすることです。
This is a protocol yet to be devised.
これはまだ考案するプロトコルです。
A MIDCOM agent registration is defined as the process of provisioning agent profile information with the middlebox or a MIDCOM PDP. MIDCOM agent registration is often a manual operation performed by an operator rather than the agent itself.
MIDCOMエージェント登録がミドル又はMIDCOM PDPとエージェントプロファイル情報をプロビジョニングするプロセスとして定義されます。 MIDCOMエージェントの登録は、多くの場合、オペレータはなく、エージェント自体による手動操作です。
A MIDCOM agent profile may include agent authorization policy (i.e., session tuples for which the agent is authorized to act as ALG), agent-hosting-entity (e.g., Proxy, Gateway, or end-host which hosts the agent), agent accessibility profile (including any host level authentication information), and security profile (for the messages exchanged between the middlebox and the agent).
MIDCOMエージェントプロファイルは、エージェントの承認ポリシーを含むこともできる（すなわち、エージェントはALGとして行動する権限をされているセッションタプル）、エージェント・ホスティング・エンティティ（例えば、エージェントをホストプロキシ、ゲートウェイ、またはエンドホスト）、エージェントアクセシビリティ（任意のホストレベルの認証情報を含む）、プロファイル、セキュリティプロファイル（メッセージのためのミドルとエージェントとの間で交換）。
A MIDCOM session is defined to be a lasting association between a MIDCOM agent and a middlebox. The MIDCOM session is not assumed to imply any specific transport layer protocol. Specifically, this should not be construed as referring to a connection-oriented TCP protocol.
MIDCOMセッションはMIDCOMエージェントとミドル間持続アソシエーションとして定義されます。 MIDCOMセッションは、任意の特定のトランスポート層プロトコルを意味すると想定されていません。具体的には、コネクション型のTCPプロトコルを指すと解釈されるべきではありません。
A filter is packet matching information that identifies a set of packets to be treated a certain way by a middlebox. This definition is consistent with [POL-TERM], which defines a filter as "A set of
フィルタは、ミドルボックスによって特定の方法で処理すべきパケットのセットを識別するパケットマッチング情報です。この定義は、「セットとしてフィルタを定義[POL-TERM]と一致しています
terms and/or criteria used for the purpose of separating or categorizing. This is accomplished via single- or multi-field matching of traffic header and/or payload data".
用語および/または分離または分類の目的のために使用される基準。これは、トラフィックのヘッダ及び/又はペイロードデータ」のシングルまたはマルチフィールドマッチングを介して達成されます。
5-Tuple specification of packets in the case of a firewall and 5- tuple specification of a session in the case of a NAT middlebox function are examples of a filter.
NATミドル関数の場合におけるセッションのファイアウォールおよび5-タプル仕様の場合にはパケットの5タプルの仕様は、フィルタの例です。
Policy action (or Action) is a description of the middlebox treatment/service to be applied to a set of packets. This definition is consistent with [POL-TERM], which defines a policy action as "Definition of what is to be done to enforce a policy rule, when the conditions of the rule are met. Policy actions may result in the execution of one or more operations to affect and/or configure network traffic and network resources".
ポリシーアクション（またはアクション）がミドル処理/サービスの説明は、パケットの集合に適用されます。この定義は、[POL-TERM]と一致して、ルールの条件が満たされた場合、ポリシールールを強制するためにどう処理するかの定義」として、ポリシーアクションを定義している。政策行動は、1の実行をもたらすことができますか、ネットワークトラフィックとネットワークリソースに影響を与え、および/または構成する複数の操作」。
NAT Address-BIND (or Port-BIND in the case of NAPT) and firewall permit/deny action are examples of an Action.
NATアドレス-BIND（またはNAPTの場合はポートBIND）やファイアウォールの許可/拒否アクションは、アクションの例です。
The combination of one or more filters and one or more actions. Packets matching a filter are to be treated as specified by the associated action(s). The Policy rules may also contain auxiliary attributes such as individual rule type, timeout values, creating agent, etc.
1つ以上のフィルタと1つのまたは複数のアクションの組み合わせ。フィルタに一致するパケットは、関連するアクション（複数可）によって指定されるように扱われるべきです。ポリシールールは、個々のルールタイプ、タイムアウト値、エージェントを作成する、等の補助属性をも含んでいてもよいです
Policy rules are communicated through the MIDCOM protocol.
ポリシールールはMIDCOMプロトコルを介して伝達されます。
A middlebox may implement one or more of the middlebox functions selectively on multiple interfaces of the device. There can be a variety of MIDCOM agents interfacing with the middlebox to communicate with one or more of the middlebox functions on an interface. As such, the middlebox communication protocol must allow for selective communication between a specific MIDCOM agent and one or more middlebox functions on the interface. The following diagram identifies a possible layering of the service supported by a middlebox and a list of MIDCOM agents that might interact with it.
ミドルボックスは、選択デバイスの複数のインターフェイスにミドル機能の一つ以上を実施することができます。インターフェイス上のミドルボックスの機能の1つまたは複数と通信するようにミドルとインターフェースMIDCOM剤の種々存在し得ます。このように、ミドル通信プロトコルは、インターフェイス上の特定のMIDCOM剤および1つまたは複数のミドル機能の間の選択の通信を可能にしなければなりません。次の図は、ミドルおよびそれと相互作用する可能性があるMIDCOMエージェントのリストでサポートされているサービスの可能性のあるレイヤーを識別します。
+---------------+ +--------------+
| MIDCOM agent | | MIDCOM agent |
| co-resident on| | co-resident |
| Proxy Server | | on Appl. GW |
+---------------+ +--------------+
^ ^
| | +--------+
MIDCOM | | | MIDCOM |
Protocol | | +-| PDP |
| | / +--------+
+-------------+ | | /
| MIDCOM agent| | | /
| co-resident | | | /
| on End-hosts|<-+ | | /
+-------------+ | | | |
v v v v
+-------------------------------------------+
| Middlebox Communication |Policy |
| Protocol (MIDCOM) Interface |Interface |
+----------+--------+-----------+-----------+
Middlebox | | | | |
Functions | Firewall | NAT | VPN | Intrusion |
| | | tunneling | Detection |
+----------+--------+-----------+-----------+
Middlebox | Middlebox function specific policy rule(s)|
Managed | and other attributes |
Resources | |
+-------------------------------------------+
Figure 1: MIDCOM agents interfacing with a middlebox
図1：ミドルボックスとインタフェースMIDCOM剤
Firewall ACLs, NAT-BINDs, NAT address-maps and Session-state are a few of the middlebox function specific policy rules. A session state may include middlebox function specific attributes, such as timeout values, NAT translation parameters (i.e., NAT-BINDS), and so forth. As Session-state may be shared across middlebox functions, a Session-state may be created by a function, and terminated by a different function. For example, a session-state may be created by the firewall function, but terminated by the NAT function, when a session timer expires.
ファイアウォールのACL、NAT-結合し、NATアドレス・マップおよびセッション状態ミドル機能特定のポリシールールのほんの一部です。セッション状態は、タイムアウト値、等NAT変換パラメータ（即ち、NAT-結合する）、およびASミドル機能固有の属性を含むことができます。セッション状態は、ミドルボックス機能間で共有することができるように、セッション状態は機能によって作成され、異なる関数によって終了することができます。セッションタイマーが満了したとき、例えば、セッション状態は、ファイアウォール機能により作成することができるが、NAT機能により終了します。
Application specific MIDCOM agents (co-resident on the middlebox or external to the middlebox) would examine the IP datagrams and help identify the application the datagram belongs to, and assist the middlebox in performing functions unique to the application and the middlebox service. For example, a MIDCOM agent, assisting a NAT middlebox, might perform payload translations, whereas a MIDCOM agent assisting a firewall middlebox might request the firewall to permit access to application specific, dynamically generated, session traffic.
アプリケーション固有のMIDCOMエージェント（ミドルのミドルや外部の共存）IPデータグラムを調べ、データグラムが属しているアプリケーションを識別するのに役立ち、そしてアプリケーションやミドルサービスに固有の機能を実行するにはミドルを支援します。例えば、MIDCOMエージェント、NATミドルをアシストファイアウォールミドルをアシストMIDCOMエージェントは、動的に生成され、セッショントラフィックを特定のアプリケーションへのアクセスを許可するようにファイアウォールを要求する可能性があるのに対し、ペイロード変換を実行する場合があります。
The MIDCOM protocol between a MIDCOM agent and a middlebox allows the MIDCOM agent to invoke services of the middlebox and allow the middlebox to delegate application specific processing to the MIDCOM agent. The protocol will allow MIDCOM agents to signal the middleboxes, to let complex applications using dynamic port based sessions through them (i.e., middleboxes) seamlessly.
MIDCOMエージェントとミドル間MIDCOMプロトコルはMIDCOM剤がミドルのサービスを呼び出すとミドルはMIDCOMエージェントにアプリケーション固有の処理を委譲することを可能にすることを可能にします。プロトコルはMIDCOMエージェントがシームレスに（即ち、中間装置）それらを介して動的ポートベースのセッションを使用して、複雑なアプリケーションをできるように、中間装置に信号を送ることを可能にします。
It is important to note that an agent and a middlebox can be on the same physical device. In such a case, they may communicate using a MIDCOM protocol message formats, but using a non-IP based transport, such as IPC messaging (or) they may communicate using well-defined API/DLL (or) the application intelligence is fully embedded into the middlebox service (as it is done today in many stateful inspection firewall devices and NAT devices).
エージェントとミドルが同じ物理デバイス上にあることに注意することが重要です。このような場合には、それらはMIDCOMプロトコルメッセージフォーマットを使用して通信することができるが、非IPベースのようなIPCメッセージングなどの輸送、（OR）を使用して、彼らは、アプリケーションインテリジェンスが完全に埋め込まれ、明確に定義されたAPI / DLL（OR）を使用して通信することができます。ミドルサービスに（それは多くのステートフルインスペクションファイアウォールデバイスとNATデバイスで、今日行われているように）。
The MIDCOM protocol will consist of a session setup phase, run-time session phase, and a session termination phase.
MIDCOMプロトコルは、セッション・セットアップ・フェーズ、実行時セッション相、セッション終了フェーズで構成されます。
Session setup must be preceded by registration of the MIDCOM agent with either the middlebox or the MIDCOM PDP. The MIDCOM agent access and authorization profile may either be pre-configured on the middlebox (or) listed on a MIDCOM PDP; the middlebox is configured to consult. MIDCOM shall be a client-server protocol, initiated by the agent.
セッション・セットアップは、ミドルまたはMIDCOM PDPのいずれかでMIDCOMエージェントの登録が先行されなければなりません。 MIDCOMエージェントのアクセス及び許可プロファイルのいずれか（または）MIDCOM PDPに記載されているミドルに予め構成されてもよいです。ミドルは相談するよう構成されています。 MIDCOMエージェントによって開始されたクライアント・サーバ・プロトコル、しなければなりません。
A MIDCOM session may be terminated by either of the parties. A MIDCOM session termination may also be triggered by (a) the middlebox or the agent going out of service and not being available for further MIDCOM operations, or (b) the MIDCOM PDP notifying the middlebox that a particular MIDCOM agent is no longer authorized.
MIDCOMセッションは、当事者のいずれかによって終了することができます。 MIDCOMセッション終了は、（a）は、ミドルまたはエージェントがサービスから出て行くとさらにMIDCOM動作のため利用可能でないことによってトリガすることができる、または（b）MIDCOM PDPは、特定のMIDCOMエージェントがもはや許可されているミドルに通知します。
The MIDCOM protocol data exchanged during run-time is governed principally by the middlebox services the protocol supports. Firewall and NAT middlebox services are considered in this document. Nonetheless, the MIDCOM framework is designed to be extensible to support the deployment of other services as well.
実行時に交換さMIDCOMプロトコルデータは、プロトコルがサポートしているミドルサービスによって主に支配されています。ファイアウォールやNATミドルサービスは、この文書では考慮されています。それにもかかわらず、MIDCOMフレームワークは、他のサービスの展開をサポートするために拡張できるように設計されています。
MIDCOM agents are logical entities which may reside physically on nodes external to a middlebox, possessing a combination of application awareness and knowledge of middlebox function. A MIDCOM agent may communicate with one or more middleboxes. The issues of middleboxes discovering agents, or vice versa, are outside the scope of this document. The focus of the document is the framework in which a MIDCOM agent communicates with a middlebox using MIDCOM protocol, which is yet to be devised. Specifically, the focus is restricted to just the In-Path agents.
MIDCOM剤は、ミドルボックス機能のアプリケーションの意識と知識の組み合わせを有する、ミドルボックスの外部のノードに物理的に常駐することができる論理エンティティです。 MIDCOM剤は、一つ以上の中間装置と通信することができます。薬剤を発見中間装置、またはその逆の問題は、この文書の範囲外です。文書の焦点はMIDCOMエージェントがまだ考案されるMIDCOMプロトコルを使用して、ミドルと通信するフレームワークです。具体的には、焦点はちょうどインパスエージェントに制限されています。
In-Path MIDCOM agents are MIDCOM agents that are located naturally within the message path of the application(s) they are associated with. Bundled session applications, such as H.323, SIP, and RTSP which have separate control and data sessions, may have their sessions take divergent paths. In those scenarios, In-Path MIDCOM agents are those that find themselves in the control path. In a majority of cases, a middlebox will likely require the assistance of a single agent for an application in the control path alone. However, it is possible that a middlebox function, or a specific application traversing the middlebox might require the intervention of more than a single MIDCOM agent for the same application, one for each sub-session of the application.
パスMIDCOM剤は、それらが関連付けられているアプリケーション（複数可）のメッセージ経路内に天然に配置されているMIDCOM剤です。別個の制御とデータセッションを有するようH.323、SIPおよびRTSPなどのバンドルセッション・アプリケーションは、そのセッションが発散経路を取るていてもよいです。これらのシナリオでは、インパスMIDCOMエージェントが制御パスで自分自身を見つけるものです。ほとんどの場合、ミドルは、単独の制御パス内のアプリケーションのための単剤の支援を必要とする可能性があります。しかし、ミドル機能、またはミドルを横断する特定のアプリケーションは、同じアプリケーション、アプリケーションの各サブセッションのための1のための単一のMIDCOMエージェントよりも多くの介入を必要とする可能性があります。
Application Proxies and gateways are a good choice for In-Path MIDCOM agents, as these entities by definition, are in the path of an application between a client and server. In addition to hosting the MIDCOM agent function, these natively in-path application specific entities may also enforce application-specific choices locally, such as dropping messages infected with known viruses, or lacking user authentication. These entities can be interjecting both the control and data sessions. For example, FTP control and Data sessions are interjected by an FTP proxy server.
アプリケーションプロキシやゲートウェイは、定義により、これらのエンティティとして、クライアントとサーバ間のアプリケーションのパスにある、インパスのMIDCOMエージェントに適しています。 MIDCOMエージェント機能をホスティングに加えて、これらのネイティブでパスアプリケーション固有のエンティティはまた、既知のウイルスに感染したメッセージを削除するか、ユーザ認証を欠いているとして、ローカルアプリケーション固有の選択を強制することがあります。これらのエンティティは、制御およびデータセッションの両方をinterjectingすることができます。たとえば、FTPの制御とデータのセッションは、FTPプロキシサーバによってinterjectedされています。
However, proxies may also be interjecting just the control session and not the data sessions, as is the case with real-time streaming applications, such as SIP and RTSP. Note, applications may not always traverse a proxy and some applications may not have a proxy server available.
しかし、プロキシはまた、SIPやRTSPなどのリアルタイムストリーミングアプリケーション、と同様に、データセッションだけで制御セッションをinterjectingしていないことがあります。アプリケーションは常にプロキシを通過しない場合があり、一部のアプリケーションは、プロキシサーバが利用できない可能性があり、注意してください。
SIP proxies and H.323 gatekeepers may be used to host MIDCOM agent functions to control middleboxes implementing firewall and NAT functions. The advantage of using in-path entities, as opposed to creating an entirely new agent, is that the in-path entities already possess application intelligence. You will need to merely enable the use of the MIDCOM protocol to be an effective MIDCOM agent. Figure 2 below illustrates a scenario where the in-path MIDCOM agents interface with the middlebox. Let us say, the MIDCOM PDP has pre-configured the in-path proxies as trusted MIDCOM agents on the middlebox and the packet filter implements a 'default-deny' packet filtering policy. Proxies use their application-awareness knowledge to control the firewall function and selectively permit a certain number of voice stream sessions dynamically using MIDCOM protocol.
SIPプロキシおよびH.323ゲートキーパーは、ファイアウォールおよびNAT機能を実現中間装置を制御するためにMIDCOMエージェント機能をホストするために使用されてもよいです。パス内のエンティティを使用することの利点は、まったく新しいエージェントの作成とは反対に、パス内のエンティティは、すでにアプリケーションインテリジェンスを有することです。あなたは、単に効果的なMIDCOMエージェントであることをMIDCOMプロトコルの使用を有効にする必要があります。図2は、以下にパスMIDCOM剤はミドルとインタフェースシナリオを示します。私たちは言ってみましょう、MIDCOM PDPはミドル上の信頼できるMIDCOM剤として事前に設定したパス内のプロキシを持っており、パケットフィルタは、「デフォルト・拒否」パケットフィルタリングポリシーを実装しています。プロキシは、ファイアウォール機能を制御し、選択的に動的にMIDCOMプロトコルを使用して音声ストリームセッションの特定の数を可能にするために、彼らのアプリケーション意識の知識を使用しています。
In the illustration below, the proxies and the MIDCOM PDP are shown inside a private domain. The intent however, is not to imply that they be inside the private boundary alone. The proxies may also reside external to the domain. The only requirement is that there be a trust relationship with the middlebox.
以下の図では、プロキシとMIDCOM PDPは、プライベートドメインの内部に示されています。その意図は、しかし、彼らは一人でプライベートな境界内にあることを意味するものではありません。プロキシは、ドメインの外部に存在することができます。唯一の要件は、ミドルとの信頼関係が存在することがあります。
+-----------+
| MIDCOM |
| PDP |~~~~~~~~~~~~~|
+-----------+ \
\
+--------+ \
| SIP |___ \
________| Proxy | \ Middlebox \
/ +--------+.. | +--------------------+
| : | MIDCOM | | |
| RTSP +---------+ :..|........| MIDCOM | POLICY |
SIP | ____| RTSP |.....|........| PROTOCOL | INTER- |
| / | Proxy |___ | | INTERFACE | FACE |
| | +---------+ \ \ |--------------------|
| | \ \______| |__SIP
| | \________| |__RTSP
| | ---| FIREWALL |--->--
+-----------+ /---| |---<--
+-----------+| Data streams // +--------------------+
+-----------+||---------->----// |
|end-hosts ||-----------<----- .
+-----------+ (RTP, RTSP data, etc.) |
. Outside the
Within a private domain | private domain
Legend: ---- Application data path datagrams
____ Application control path datagrams
.... Middlebox Communication Protocol (MIDCOM)
~~~~ MIDCOM PDP Interface
|
. private domain Boundary
|
Figure 2: In-Path MIDCOM Agents for middlebox Communication
図2：インパスMIDCOMエージェントミドルのコミュニケーションのために
End-hosts are another variation of In-Path MIDCOM agents. Unlike Proxies, End-hosts are a direct party to the application and possess all the end-to-end application intelligence there is to it. End-hosts presumably terminate both the control and data paths of an application. Unlike other entities hosting MIDCOM agents, end-host is able to process secure datagrams. However, the problem would be one of manageability - upgrading all the end-hosts running a specific application.
エンドホストは、In-パスMIDCOMエージェントの別のバリエーションです。プロキシとは異なり、エンドホストは、アプリケーションへの直接の当事者であり、そこに存在し、すべてのエンド・ツー・エンドのアプリケーションインテリジェンスを持っています。エンドホストは、おそらく制御およびアプリケーションのデータパスの両方を終了します。 MIDCOMエージェントをホストしている他のエンティティとは異なり、エンドホストは、セキュアなデータグラムを処理することができます。特定のアプリケーションを実行しているすべてのエンドホストをアップグレードする - しかし、問題は、管理のものであろう。
The functional decomposition of the MIDCOM architecture assumes the existence of a logical entity, known as MIDCOM PDP, responsible for performing authorization and related provisioning services for the middlebox as depicted in figure 1. The MIDCOM PDP is a logical entity which may reside physically on a middlebox or on a node external to the middlebox. The protocol employed for communication between the middlebox and the MIDCOM PDP is unrelated to the MIDCOM protocol.
図に示すようにMIDCOM PDPは、上に物理的に常駐することができる論理エンティティで1. MIDCOMアーキテクチャの機能的分解は、ミドルボックスの権限と関連するプロビジョニングサービスを実行する責任MIDCOM PDPとして知られている論理エンティティの存在を前提としミドルやミドルへの外部ノードに。ミドルとMIDCOM PDPとの間の通信のために用いたプロトコルはMIDCOMプロトコルとは無関係です。
Agents are registered with a MIDCOM PDP for authorization to invoke services of the middlebox. The MIDCOM PDP maintains a list of agents that are authorized to connect to each of the middleboxes the MIDCOM PDP supports. In the context of the MIDCOM Framework, the MIDCOM PDP does not assist a middlebox in the implementation of the services it provides.
エージェントは、ミドルのサービスを呼び出すための認可のためにMIDCOM PDPに登録されています。 MIDCOM PDPはMIDCOM PDPがサポートするミドルボックスのそれぞれに接続するために許可されているエージェントのリストを維持します。 MIDCOMフレームワークのコンテキストでは、MIDCOM PDPは、それが提供するサービスの実装でミドルを支援しません。
The MIDCOM PDP acts in an advisory capacity to a middlebox, to authorize or terminate authorization for an agent attempting connectivity to the middlebox. The primary objective of a MIDCOM PDP is to communicate agent authorization information, so as to ensure that the security and integrity of a middlebox is not jeopardized. Specifically, the MIDCOM PDP should associate a trust level with each agent attempting to connect to a middlebox and provide a security profile. The MIDCOM PDP should be capable of addressing cases when end-hosts are agents to the middlebox.
MIDCOM PDPは、ミドルボックスへの接続を試みるエージェントの許可を認可または終了する、ミドルに顧問に作用します。 MIDCOM PDPの主な目的は、ミドルのセキュリティと整合性が損なわれないことを保証するように、エージェントの認証情報を通信することです。具体的には、MIDCOM PDPは、ミドルに接続して、セキュリティプロファイルを提供しようとすると、各エージェントとの信頼レベルを関連付ける必要があります。 MIDCOM PDPは、エンドホストがミドルに剤である場合のケースに対処することができなければなりません。
Host authenticity and individual message security are two distinct types of security considerations. Host authentication refers to credentials required of a MIDCOM agent to authenticate itself to the middlebox and vice versa. When authentication fails, the middlebox must not process signaling requests received from the agent that failed authentication. Two-way authentication should be supported. In some cases, the 2-way authentication may be tightly linked to the establishment of keys to protect subsequent traffic. Two-way authentication is often required to prevent various active attacks on the MIDCOM protocol and secure establishment of keying material.
ホストの真正性と個々のメッセージセキュリティは、セキュリティ上の考慮事項の2つのタイプがあります。ホスト認証はミドルとその逆に自分自身を認証するためにMIDCOMエージェントの必要な資格情報を指します。認証が失敗した場合、ミドルは、認証に失敗したエージェントから受信したシグナリング要求を処理してはなりません。双方向認証をサポートする必要があります。いくつかのケースでは、2ウェイ認証はしっかりと、その後のトラフィックを保護するために、キーの確立にリンクすることができます。双方向認証は、多くの場合、MIDCOMプロトコルとキーの安全な設立に関する様々なアクティブな攻撃を防止するために必要とされます。
Security services such as authentication, data integrity, confidentiality and replay protection may be adapted to secure MIDCOM messages in an untrusted domain. Message authentication is the same as data origin authentication and is an affirmation that the sender of the message is who it claims to be. Data integrity refers to the ability to ensure that a message has not been accidentally, maliciously or otherwise altered or destroyed. Confidentiality is the encryption of a message with a key, so that only those in possession of the key can decipher the message content. Lastly, replay protection is a form of sequence integrity, so when an intruder plays back a previously recorded sequence of messages, the receiver of the replay messages will simply drop the replay messages into bit-bucket. Certain applications of the MIDCOM protocol might require support for non-repudiation as an option of the data integrity service. Typically, support for non-repudiation is required for billing, service level agreements, payment orders, and receipts for delivery of service.
認証、データの整合性、機密性、および再生保護などのセキュリティサービスは、信頼されていないドメインでMIDCOMメッセージを確保するために適合させることができます。メッセージ認証は、データ発信元認証と同じで、メッセージの送信者は、それがあることを主張する人であることを肯定です。データの整合性は、メッセージが誤って、故意またはそうでなければ変更または破壊されていないことを確実にする能力を指します。鍵の所有で唯一のものは、メッセージの内容を解読することができるように機密性は、鍵を使用してメッセージの暗号化です。最後に、再生保護は、シーケンスインテグリティの形式なので、侵入者がメッセージの前に記録されたシーケンスを再生する場合、再生メッセージの受信機は、単にビット・バケットにリプレイメッセージをドロップします。 MIDCOMプロトコルの特定のアプリケーションは、データの整合性サービスのオプションとして、否認防止のためのサポートが必要な場合があります。一般的に、否認防止のためのサポートは、サービスの提供の請求、サービスレベル契約、決済注文、および領収書に必要です。
IPsec AH ([IPSEC-AH]) offers data-origin authentication, data integrity and protection from message replay. IPsec ESP ([IPSEC-ESP]) provides data-origin authentication to a lesser degree (same as IPsec AH if the MIDCOM transport protocol turns out to be TCP or UDP), message confidentiality, data integrity and protection from replay. Besides the IPsec based protocols, there are other security options as well. TLS based transport layer security is one option. There are also many application-layer security mechanisms available. Simple Source-address based security is a minimal form of security and should be relied on only in the most trusted environments, where those hosts will not be spoofed.
IPsecのAHは、（[IPSEC-AH]）メッセージのリプレイからデータ起点認証、データの整合性と保護を提供しています。リプレイから、メッセージの機密性、データ完全性及び保護（MIDCOM転送プロトコルがTCPまたはUDPであることが判明した場合にIPsec AHと同じ）のIPsec ESPは、（[IPSEC-ESP]）より少ない程度に、データ発信元認証を提供します。 IPsecのベースのプロトコルだけでなく、同様に他のセキュリティオプションがあります。 TLSベースのトランスポート層セキュリティは一つの選択肢です。利用できる多くのアプリケーション層のセキュリティメカニズムもあります。シンプルなソース・アドレスベースのセキュリティは、セキュリティの最小限の形であり、唯一のそれらのホストが偽装されることはありません最も信頼できる環境に依拠しなければなりません。
The MIDCOM message security shall use existing standards, whenever the existing standards satisfy the requirements. Security shall be specified to minimize the impact on sessions that do not use the security option. Security should be designed to avoid introducing and to minimize the impact of denial of service attacks. Some security mechanisms and algorithms require substantial processing or storage, in which case the security protocols should protect themselves as well as against possible flooding attacks that overwhelm the endpoint (i.e., the middlebox or the agent) with such processing. For connection oriented protocols (such as TCP) using security services, the security protocol should detect premature closure or truncation attacks.
既存の標準が要件を満たしたときにMIDCOMメッセージのセキュリティは、既存の標準を使用しなければなりません。セキュリティは、セキュリティオプションを使用しないセッションへの影響を最小限に抑えるために指定されなければなりません。セキュリティが導入を回避するために、サービス拒否攻撃の影響を最小限にするように設計されなければなりません。いくつかのセキュリティメカニズム及びアルゴリズムは、セキュリティプロトコルは、このような処理で、エンドポイント（即ち、ミドルまたは薬剤）を圧倒する可能フラッディング攻撃ならびにそれ自体を保護する必要があり、その場合、実質的な処理または記憶を必要とします。セキュリティ・サービスを使用して（TCPのような）接続指向のプロトコルでは、セキュリティプロトコルは、早期の閉鎖または切り捨て攻撃を検出する必要があります。
Prior to allowing MIDCOM agents to invoke services of the middlebox, a registration process must take place. Registration is a different process than establishing a MIDCOM session. The former requires provisioning agent profile information with the middlebox or a MIDCOM PDP. Agent registration is often a manual operation performed by an operator rather than the agent itself. Setting up MIDCOM session refers to establishing a MIDCOM transport session and exchanging security credentials between an agent and a middlebox. The transport session uses the registered information for session establishment.
MIDCOMエージェントがミドルのサービスを呼び出すことができるようにする前に、登録プロセスが行われなければなりません。登録はMIDCOMセッションを確立するよりも異なるプロセスです。前者は、ミドル又はMIDCOM PDPとプロビジョニングエージェントプロファイル情報を必要とします。エージェントの登録は、多くの場合、オペレータはなく、エージェント自身による手動操作です。 MIDCOMセッションを設定すると、MIDCOM輸送セッションを確立し、エージェントとミドルの間でセキュリティ資格情報を交換を指します。トランスポート・セッションは、セッション確立のための登録情報を使用しています。
Profile of a MIDCOM agent includes agent authorization policy (i.e., session tuples for which the agent is authorized to act as ALG), agent-hosting-entity (e.g., Proxy, Gateway or end-host which hosts the agent), agent accessibility profile (including any host level authentication information) and security profile (i.e., security requirements for messages exchanged between the middlebox and the agent).
MIDCOMエージェントのプロフィールは、エージェントの承認ポリシーを含み（すなわち、エージェントはALGとして行動する権限をされているセッションタプル）、エージェント・ホスティング・エンティティ（例えば、プロキシ、ゲートウェイまたはエージェントをホストエンドホスト）、エージェントのアクセシビリティプロフィール（任意のホストレベルの認証情報を含む）とセキュリティプロファイル（すなわち、メッセージのセキュリティ要件は、ミドルとエージェント間で交換しました）。
MIDCOM agent profile may be pre-configured on a middlebox. Subsequent to that, the agent may choose to initiate a MIDCOM session prior to any data traffic. For example, MIDCOM agent authorization policy for a middlebox service may be preconfigured by specifying the agent in conjunction with a filter. In the case of a firewall, for example, the ACL tuple may be altered to reflect the optional Agent presence. The revised ACL may look something like the following.
MIDCOMエージェントプロファイルは、ミドルボックスに事前に構成されてもよいです。それに続いて、エージェントは、任意のデータトラフィックに先立ってMIDCOMセッションを開始することもできます。例えば、ミドルサービスのMIDCOMエージェント許可ポリシーは、フィルタと一緒にエージェントを指定することにより、事前設定されてもよいです。ファイアウォールの場合には、例えば、ACLタプルは、オプションのエージェントの存在を反映するように変更されてもよいです。改訂されたACLは、次のようになります。
(<Session-Direction>, <Source-Address>, <Destination-Address>, <IP-Protocol>, <Source-Port>, <Destination-Port>, <Agent>)
（<セッション方向>、<ソース・アドレス>、<宛先アドレス>、<IP-プロトコル>、<ソースポート>、<宛先ポート>、<エージェント>）
The reader should note that this is an illustrative example and not necessarily the actual definition of an ACL tuple. The formal description of the ACL is yet to be devised. Agent accessibility information should also be provisioned. For a MIDCOM agent, accessibility information includes the IP address, trust level, host authentication parameters and message authentication parameters. Once a session is established between a middlebox and a MIDCOM agent, that session should be usable with multiple instances of the application(s), as appropriate. Note, all of this could be captured in an agent profile for ease of management.
読者は、この例示的な例であり、必ずしもACLタプルの実際の定義ことに注意すべきです。 ACLの正式な説明はまだ工夫があります。エージェントのアクセシビリティ情報もプロビジョニングする必要があります。 MIDCOMエージェントの場合、アクセシビリティ情報は、IPアドレス、信頼レベル、ホスト認証パラメータとメッセージ認証パラメータを含んでいます。セッションがミドルとMIDCOMエージェントとの間で確立されると、そのセッションは、必要に応じて、アプリケーション（単数または複数）の複数のインスタンスで使用可能でなければなりません。このすべては、管理を容易にするために、エージェントプロファイルでキャプチャすることができ、注意してください。
The technique described above is necessary for the pre-registration of MIDCOM agents with the middlebox. The middlebox provisioning may remain unchanged, if the middlebox learns of the registered agents through a MIDCOM PDP. In either case, the MIDCOM agent should initiate the session prior to the start of the application. If the agent session is delayed until after the application has started, the agent might be unable to process the control stream to permit the data sessions. When a middlebox notices an incoming MIDCOM session, and the middlebox has no prior profile of the MIDCOM agent, the middlebox will consult its MIDCOM PDP for authenticity, authorization, and trust guidelines for the session.
上述した技術は、ミドルとMIDCOM剤の事前登録が必要です。ミドルボックスはMIDCOM PDPを介して登録されたエージェントの学習する場合ミドルプロビジョニングは、不変のままであってもよいです。いずれの場合においても、MIDCOMエージェントは、アプリケーションの開始前にセッションを開始すべきです。エージェント・セッションは、アプリケーションが起動した後まで延期されている場合は、エージェントは、データセッションを可能にするために、制御ストリームを処理できないことがあります。ミドルは、着信MIDCOMセッションに気付き、そしてミドルはMIDCOMエージェントの事前のプロファイルを持っていない場合は、ミドルは信憑性、認証、およびセッションのための信頼のガイドラインについては、そのMIDCOM PDPを協議します。
In figure 3 below, we consider SIP applications (Refer [SIP]) to illustrate the operation of the MIDCOM protocol. Specifically, the application assumes that a caller, external to a private domain, initiates the call. The middlebox is assumed to be located at the edge of the private domain. A SIP phone (SIP User Agent Client/Server) inside the private domain is capable of receiving calls from external SIP phones. The caller uses a SIP Proxy, node located external to the private domain, as its outbound proxy. No interior proxy is assumed for the callee. Lastly, the external SIP proxy node is designated to host the MIDCOM agent function.
下の図3において、我々は、SIPアプリケーションが（[SIP]を参照）MIDCOMプロトコルの動作を説明するため考えます。具体的には、アプリケーションはプライベートドメインへの外部の発信者は、通話を開始することを前提としています。ミドルは、プライベートドメインの端に位置しているものとします。プライベートドメイン内のSIPフォン（SIPユーザエージェントクライアント/サーバ）が外部のSIP電話機からのコールを受信することが可能です。呼び出し側は、そのアウトバウンドプロキシとして、プライベートドメインの外部に配置SIPプロキシ、ノードを使用しています。いいえ内部プロキシは、呼び出し先のために想定されていません。最後に、外部のSIPプロキシノードはMIDCOMエージェント機能をホストするために指定されています。
Arrows 1 and 8 in the figure below refer to a SIP call setup exchange between the external SIP phone and the SIP proxy. Arrows 4 and 5 refer to a SIP call setup exchange between the SIP proxy and the interior SIP phone, and are assumed to be traversing the middlebox. Arrows 2, 3, 6 and 7 below, between the SIP proxy and the middlebox, refer to MIDCOM communication. Na and Nb represent RTP/RTCP media traffic (Refer [RTP]) path in the external network. Nc and Nd represent media traffic inside the private domain.
以下図中の矢印1,8は、外部SIP電話とSIPプロキシとの間のSIP呼設定交換を指します。矢印4及び5は、SIPプロキシと内部SIP電話機との間のSIP呼設定交換を参照して、ミドルボックスを横断することが想定されます。矢印2、3、6および7以下、SIPプロキシとミドル間、MIDCOMの通信を指します。 NaおよびNbが外部ネットワーク内のパス（[RTP]参照）RTP / RTCPメディアトラフィックを表します。ノースカロライナとNdがプライベートドメイン内のメディアトラフィックを表します。
_________
--->| SIP |<-----\
/ | Proxy | \
| |_________| |
1| |^ ^| 4|
| || || |
|8 2||3 7||6 |5
______________ | || || | _____________
| |<-/ _v|____|v___ \->| |
| External | Na | | Nc | SIP Phone |
| SIP phone |>------->| Middlebox |>------>| within |
| |<-------<|___________|<------<| Pvt. domain|
|____________| Nb Nd |____________|
Figure 3: MIDCOM framework illustration with In-Path SIP Proxy
図3において、パスSIPプロキシとMIDCOMフレームワークイラスト
As for the SIP application, we make the assumption that the middlebox is pre-configured to accept SIP calls into the private SIP phone. Specifically, this would imply that the middlebox implementing firewall service is pre-configured to permit SIP calls (destination
SIPアプリケーション用として、我々はミドルがSIPプライベートSIP電話機を呼び出す受け入れるように事前に設定されていることを前提とします。具体的には、ファイアウォールサービスを実装するミドルボックスは、SIPコール（宛先を許可するように事前に設定されていることを暗示します
TCP or UDP port number set to 5060) into the private phone. Likewise, middlebox implementing NAPT service would have been pre-configured to provide a port binding, to permit incoming SIP calls to be redirected to the specific private SIP phone. I.e., the INVITE from the external caller is not made to the private IP address, but to the NAPT external address.
プライベート電話へのTCPまたは5060に設定UDPポート番号）。同様に、NAPTサービスを実装するミドルは、着信SIPを許可する、結合ポートを提供するために、事前に設定されていたであろう特定のプライベートSIP電話機にリダイレクトされるように呼び出します。すなわち、プライベートIPアドレスに行われていない外部の発信者からのINVITEが、NAPT外部アドレスへ。
The objective of the MIDCOM agent in the following illustration is to merely permit the RTP/RTCP media stream (Refer [RTP]) through the middlebox, when using the MIDCOM protocol architecture outlined in the document. A SIP session typically establishes two RTP/RTCP media streams - one from the callee to the caller and another from the caller to the callee. These media sessions are UDP based and will use dynamic ports. The dynamic ports used for the media stream are specified in the SDP section (Refer [SDP]) of the SIP payload message. The MIDCOM agent will parse the SDP section and use the MIDCOM protocol to (a) open pinholes (i.e., permit RTP/RTCP session tuples) in a middlebox implementing firewall service, or (b) create PORT bindings and appropriately modify the SDP content to permit the RTP/RTCP streams through a middlebox implementing NAT service. The MIDCOM protocol should be sufficiently rich and expressive to support the operations described under the timelines. The examples do not show the timers maintained by the agent to keep the middlebox policy rule(s) from timing out.
次の図でMIDCOM剤の目的は、文書で概説MIDCOMプロトコルアーキテクチャを使用する場合、単にミドル介してRTP / RTCPメディアストリームを（[RTP]を参照）、可能にすることです。被呼者に発呼者に被呼者からの1つ及び発呼者から別の - SIPセッションは、通常、2つのRTP / RTCPメディアストリームを確立します。これらのメディアセッションは、UDPベースであり、動的ポートを使用します。メディアストリームのために使用される動的ポートは、SIPペイロードメッセージの（[SDP]参照）SDPセクションで指定されています。 MIDCOMエージェントは、SDP部分を解析し、（a）のオープンピンホールにMIDCOMプロトコルを使用する（すなわち、RTP / RTCPセッションタプルを許可）、ファイアウォールサービスを実装するミドルで、または（b）PORTバインディングを作成し、適切にSDPの内容を変更しますRTP / RTCPは、NATサービスを実装するミドルを通じてストリームを許可します。 MIDCOMプロトコルは、タイムラインの下に記載された動作をサポートするために十分に豊かな表現力でなければなりません。例はタイムアウトからミドルポリシールール（複数可）を維持するために、エージェントによって維持タイマーを表示しません。
MIDCOM agent Registration and connectivity between the MIDCOM agent and the middlebox are not shown in the interest of restricting the focus of the MIDCOM transactions to enabling the middlebox to let the media stream through. MIDCOM PDP is also not shown in the diagram below or on the timelines for the same reason.
MIDCOMエージェントとミドルの間MIDCOMエージェントの登録との接続は、メディアを通じストリーミングできるようにミドルを有効にするMIDCOMトランザクションの焦点を制限するの関心には示されていません。 MIDCOM PDPは、以下または同様の理由のためにタイムライン上の図に示されていません。
The following subsections illustrate a typical timeline sequence of operations that transpire with the various elements involved in a SIP telephony application path. Each subsection is devoted to a specific instantiation of a middlebox service - NAPT (refer [NAT-TERM], [NAT-TRAD]), firewall and a combination of both NAPT and firewall are considered.
以下のサブセクションでは、SIP電話アプリケーション経路に関与する様々な要素を蒸散操作の典型的なタイムラインのシーケンスを示します。各サブセクションは、ミドルボックスサービスの特定のインスタンスに捧げられる - NAPT（[NAT-TERM]を参照し、[NAT-TRAD]）、ファイアウォール、NAPTとファイアウォールの両方の組み合わせが考えられます。
In the following example, we will assume a middlebox implementing a firewall service. We further assume that the middlebox is pre-configured to permit SIP calls (destination TCP or UDP port number set to 5060) into the private phone. The following timeline illustrates the operations performed by the MIDCOM agent, to permit RTP/RTCP media stream through the middlebox.
次の例では、我々は、ファイアウォールサービスを実装するミドルを仮定します。私たちは、さらにミドルがプライベート電話にSIPコール（先のTCPまたは5060に設定UDPポート番号）を可能にするために、事前に設定されていることを前提としています。次のタイムラインは、ミドルボックスを介してRTP / RTCPメディア・ストリームを許可するために、MIDCOMエージェントによって実行される動作を示します。
The INVITE from the caller (external) is assumed to include the SDP payload. You will note that the MIDCOM agent requests the middlebox to permit the Private-to-external RTP/RTCP flows before the INVITE is relayed to the callee. This is because, in SIP, the calling party must be ready to receive the media when it sends the INVITE with a session description. If the called party (private phone) assumes this and sends "early media" before sending the 200 OK response, the firewall will have blocked these packets without this initial MIDCOM signaling from the agent.
発信者（外部）からINVITEがSDPペイロードを含むものとします。あなたはMIDCOMエージェントが呼び出し先に中継されたINVITE前にプライベート・ツー・外部RTP / RTCPフローを許可するようにミドルを要求していることに注意します。これは、セッション記述でINVITEを送信する場合、SIPに、発呼者がメディアを受信する準備ができなければならないからです。着信側（プライベートの携帯電話は）これを想定しており、200 OK応答を送信する前に、「初期メディア」を送信した場合、ファイアウォールは、エージェントからのシグナリングこの初期MIDCOMことなく、これらのパケットをブロックしています。
SIP Phone SIP Proxy Middlebox SIP Phone
(External) (MIDCOM agent) (FIREWALL (private)
| | Service) |
| | | |
|----INVITE------>| | |
| | | |
|<---100Trying----| | |
| | | |
| Identify end-2-end | |
| parameters (from Caller's | |
| SDP) for the pri-to-Ext | |
| RTP & RTCP sessions. | |
| (RTP1, RTCP1) | |
| | | |
| |+Permit RTP1, RTCP1 +>| |
| |<+RTP1, RTCP1 OKed++++| |
| | | |
| |--------INVITE---------------------->|
| | | |
| |<-----180 Ringing--------------------|
|<--180Ringing----| | |
| |<-------200 OK-----------------------|
| | | |
| Identify end-2-end | |
| parameters (from callee's | |
| SDP) for the Ext-to-Pri | |
| RTP and RTCP sessions. | |
| (RTP2, RTCP2) | |
| | | |
| |+Permit RTP2, RTCP2 +>| |
| |<+RTP2, RTCP2 OKed++++| |
| | | |
|<---200 OK ------| | |
|-------ACK------>| | |
| |-----------ACK---------------------->|
| | | |
|<===================RTP/RTCP==========================>|
| | | |
|-------BYE------>| | |
| |--------------------------BYE------->|
| | | |
| |<----------200 OK--------------------|
| | | |
| |++Cancel permits to | |
| | RTP1, RTCP1, RTP2, | |
| | and RTCP2 +++++++++>| |
| |<+RTP1, RTP2, RTCP1 & | |
| | RTCP2 cancelled ++++| |
| | | |
|<---200 OK-------| | |
| | | |
Legend: ++++ MIDCOM control traffic
---- SIP control traffic
==== RTP/RTCP media traffic
In the following example, we will assume a middlebox implementing NAPT service. We make the assumption that the middlebox is pre-configured to redirect SIP calls to the specific private SIP phone application. I.e., the INVITE from the external caller is not made to the private IP address, but to the NAPT external address. Let us say, the external phone's IP address is Ea, NAPT middlebox external Address is Ma, and the internal SIP phone's private address is Pa. SIP calls to the private SIP phone will arrive as TCP/UDP sessions, with the destination address and port set to Ma and 5060 respectively. The middlebox will redirect these datagrams to the internal SIP phone. The following timeline will illustrate the operations necessary to be performed by the MIDCOM agent to permit the RTP/RTCP media stream through the middlebox.
次の例では、我々は、NAPTサービスを実装するミドルを仮定します。私たちは、ミドルは、SIPをリダイレクトするために事前に設定されていることを前提に、特定のプライベートSIP電話アプリケーションに呼び出しを行います。すなわち、プライベートIPアドレスに行われていない外部の発信者からのINVITEが、NAPT外部アドレスへ。私たちは、NAPTのミドル外部アドレスが馬で、内部SIP電話のプライベートアドレスがPaである、外部電話のIPアドレスはEaのである、としましょう。SIPは、民間のSIP電話機にコールし、宛先アドレスとポートで、TCP / UDPセッションとして到着しますそれぞれ馬と5060に設定します。ミドルは、内部SIP電話機にこれらのデータグラムをリダイレクトします。次のタイムラインは、ミドルボックスを介してRTP / RTCPメディア・ストリームを許可するMIDCOMエージェントによって行うことが必要な操作を例示します。
As with the previous example (section 7.1), the INVITE from the caller (external) is assumed to include the SDP payload. You will note that the MIDCOM agent requests the middlebox to create NAT session descriptors for the private-to-external RTP/RTCP flows before the INVITE is relayed to the private SIP phone (for the same reasons as described in section 7.1). If the called party (private phone) sends "early media" before sending the 200 OK response, the NAPT middlebox will have blocked these packets without the initial MIDCOM signaling from the agent. Also, note that after the 200 OK is received by the proxy from the private phone, the agent requests the middlebox to allocate NAT session descriptors for the external-to-private RTP2 and RTCP2 flows, such that the ports assigned on the Ma for RTP2 and RTCP2 are contiguous. The RTCP stream does not happen with a non-contiguous port. Lastly, you will note that even though each media stream (RTP1, RTCP1, RTP2 and RTCP2) is independent, they are all tied to the single SIP control session, while their NAT session descriptors were being created. Finally, when the agent issues a terminate session bundle command for the SIP session, the middlebox is assumed to delete all associated media stream sessions automagically.
前の例（セクション7.1）のように、発信者（外部）からINVITEがSDPペイロードを含むものとします。あなたはMIDCOMエージェントはプライベート・ツー・外部RTP / RTCPのためのNATセッション記述子を作成するためにミドルを要求する（セクション7.1で説明したのと同じ理由から）プライベートSIPフォンに中継されるINVITE前に流れていることに注意します。着信側（プライベート電話）は200 OK応答を送信する前に、「初期メディア」を送信した場合、NAPTのミドルは、エージェントからの最初のMIDCOMシグナリングせずにこれらのパケットをブロックしています。また、200 OKがプライベート電話からプロキシによって受信された後、エージェントはのためのNATセッション記述子を割り当てるためにミドルを要請することに注意して、外部ツープライベート、RTP2とRTCP2が流れるようにRTP2のために馬に割り当てられたポートそしてRTCP2が連続しています。 RTCPストリームは非連続ポートでは発生しません。最後に、あなたは、各メディアストリーム（RTP1、RTCP1、RTP2およびRTCP2）が独立しているにもかかわらず、彼らのNATセッション記述子が作成されていたが、それらはすべて、単一のSIP制御セッションに結びついていることに注意します。エージェントは、SIPセッションの終了セッションbundleコマンドを発行したときに最後に、ミドルは自動的に、関連するすべてのメディアストリームセッションを削除すると想定されます。
SIP Phone SIP Proxy Middlebox SIP Phone
(External) (MIDCOM agent) (NAPT (Private)
IP Addr:Ea | Service) IP addr:Pa
| | IP addr:Ma |
| | | |
|----INVITE------>| | |
| | | |
|<---100Trying----| | |
| | | |
| |++ Query Port-BIND | |
| | for (Ma, 5060) +++>| |
| |<+ Port-BIND reply | |
| | for (Ma, 5060) ++++| |
| | | |
| |++ Query NAT Session | |
| | Descriptor for | |
| | Ea-to-Pa SIP flow+>| |
| |<+ Ea-to-Pa SIP flow | |
| | Session Descriptor+| |
| | | |
| Determine the Internal | |
| IP address (Pa) | |
| of the callee. | |
| | | |
| Identify UDP port numbers | |
| on Ea (Eport1, Eport1+1) | |
| for pri-to-ext RTP & RTCP | |
| sessions (RTP1, RTCP1) | |
| | | |
| |++Create NAT Session | |
| | descriptors for | |
| | RTP1, RTCP1; Set | |
| | parent session to | |
| | SIP-ctrl session ++>| |
| |<+RTP1, RTCP1 session | |
| | descriptors created+| |
| | | |
| | |..redirected..|
| |--------INVITE--------|------------->|
| | | |
| |<-----180Ringing---------------------|
| | | |
|<--180Ringing----| | |
| |<-------200 OK-----------------------|
| | | |
| Identify UDP port numbers | |
| on Pa (Pport2, Pport2+1) | |
| for ext-to-pri RTP & RTCP | |
| sessions (RTP2, RTCP2) | |
| | | |
| |++Create consecutive | |
| | port BINDs on Ma | |
| | for (Pa, Pport2), | |
| | (Pa, Pport2+1) ++++>| |
| |<+Port BINDs created++| |
| | | |
| |++Create NAT Session | |
| | descriptors for | |
| | RTP2, RTCP2; Set | |
| | parent session to | |
| | SIP-ctrl session ++>| |
| |<+RTP2, RTCP2 session | |
| | descriptors created+| |
| | | |
| Modify the SDP | |
| parameters in "200 OK" | |
| with NAPT PORT-BIND | |
| for the RTP2 port on Ma. | |
| | | |
|<---200 OK ------| | |
| | | |
|-------ACK------>| | |
| | | |
| Modify IP addresses | |
| appropriately in the SIP | |
| header (e.g., To, from, | |
| Via, contact fields) | |
| | |..redirected..|
| |-----------ACK--------|------------->|
| | | |
| | | |
|<===================RTP/RTCP============|=============>|
| | | |
|-------BYE------>| | |
| | | |
| |----------------------|-----BYE----->|
| | | |
| |<----------200 OK--------------------|
| | | |
| |+++Terminate the SIP | |
| | Session bundle +++>| |
| |<++SIP Session bundle | |
| | terminated ++++++++| |
| | | |
|<---200 OK-------| | |
| | | |
Legend: ++++ MIDCOM control traffic
---- SIP control traffic
==== RTP/RTCP media traffic
In the following example, we will assume a middlebox implementing a combination of a firewall and a stateful NAPT service. We make the assumption that the NAPT function is configured to translate the IP and TCP headers of the initial SIP session into the private SIP phone, and the firewall function is configured to permit the initial SIP session.
次の例では、ファイアウォールとステートフルNAPTサービスの組み合わせを実装するミドルを仮定します。私たちは、NAPT機能はプライベートのSIP電話に最初のSIPセッションのIPおよびTCPヘッダを変換するように構成されており、ファイアウォール機能は、初期SIPセッションを許可するように設定されていることを前提とします。
In the following time line, it may be noted that the firewall description is based on packet fields on the wire (ex: as seen on the external interface of the middlebox). In order to ensure correct behavior of the individual services, you will notice that NAT specific MIDCOM operations precede firewall specific operations on the MIDCOM agent. This is noticeable in the time line below when the MIDCOM agent processes the "200 OK" from the private SIP phone. The MIDCOM agent initially requests the NAT service on the middlebox to set up port-BIND and session-descriptors for the media stream in both directions. Subsequent to that, the MIDCOM agent determines the session parameters (i.e., the dynamic UDP ports) for the media stream, as viewed by the external interface and requests the firewall service on the middlebox to permit those sessions through.
（：ミドルボックスの外部インターフェース上で見られるような例）以下のタイムラインでは、ファイアウォールの説明は、ワイヤ上のパケットフィールドに基づいていることに留意されたいです。個々のサービスの正しい動作を確保するためには、NAT、特定のMIDCOM操作はMIDCOMエージェント上のファイアウォールの特定の操作を先行していることがわかります。これはMIDCOMエージェントは、民間のSIP電話から「200 OK」を処理するときに、以下のタイムラインに顕著です。 MIDCOMエージェントは、最初は両方向のメディアストリーム用のポート-BINDおよびセッション・ディスクリプタを設定するためのミドルでNATサービスを要求します。それに続いて、MIDCOMエージェントは、外部インターフェースから見た、メディアストリームのためのセッションパラメータ（すなわち、動的UDPポート）を決定し、これらのセッションを介して可能にするためにミドルにファイアウォールサービスを要求します。
SIP Phone SIP Proxy Middlebox SIP Phone
(External) (MIDCOM agent) (NAPT & (Private)
IP Addr:Ea | firewall IP addr:Pa
| | Services) |
| | IP addr:Ma |
| | | |
|----INVITE------>| | |
| | | |
|<---100Trying----| | |
| | | |
| |++ Query Port-BIND | |
| | for (Ma, 5060) +++>| |
| |<+ Port-BIND reply | |
| | for (Ma, 5060) ++++| |
| | | |
| |++ Query NAT Session | |
| | Descriptor for | |
| | Ea-to-Pa SIP flow+>| |
| |<+ Ea-to-Pa SIP flow | |
| | Session Descriptor+| |
| | | |
| Determine the Internal | |
| IP address (Pa) | |
| of the callee. | |
| | | |
| Identify UDP port numbers | |
| on Ea (Eport1, Eport1+1) | |
| for pri-to-ext RTP & RTCP | |
| sessions (RTP1, RTCP1) | |
| | | |
| |++Create NAT Session | |
| | descriptors for | |
| | RTP1, RTCP1; Set the| |
| | parent session to | |
| | point to SIP flow++>| |
| |<+RTP1, RTCP1 session | |
| | descriptors created+| |
| | | |
| |++Permit RTP1 & RTCP1 | |
| | sessions External to| |
| | middlebox, namely | |
| | Ma to Ea:Eport1, | |
| | Ma to Ea:Eport1+1 | |
| | sessions ++++++++++>| |
| |<+Ma to Ea:Eport1, | |
| | Ma to Ea:Eport1+1 | |
| | sessions OKed ++++++| |
| | | |
| | |..redirected..|
| |--------INVITE--------|------------->|
| | | |
| |<-----180Ringing---------------------|
| | | |
|<--180Ringing----| | |
| |<-------200 OK-----------------------|
| | | |
| Identify UDP port numbers | |
| on Pa (Pport2, Pport2+1) | |
| for ext-to-pri RTP & RTCP | |
| sessions (RTP2, RTCP2) | |
| | | |
| |++Create consecutive | |
| | port BINDs on Ma | |
| | for (Pa, Pport2), | |
| | (Pa, Pport2+1) ++++>| |
| |<+Port BINDs created | |
| | on Ma as (Mport2, | |
| | Mport2+1) ++++++++++| |
| | | |
| |++Create NAT Session | |
| | descriptors for | |
| | RTP2, RTCP2; Set the| |
| | parent session to | |
| | point to SIP flow++>| |
| |<+RTP2, RTCP2 session | |
| | descriptors created+| |
| | | |
| Modify the SDP | |
| parameters in "200 OK" | |
| with NAPT PORT-BIND | |
| for RTP2 port on Ma. | |
| | | |
| |++Permit RTP2 & RTCP2 | |
| | sessions External | |
| | middlebox, namely | |
| | Ea to Ma:Mport2, | |
| | Ea to Ma:Mport2+1 | |
| | sessions ++++++++++>| |
| |<+Ea to Ma:Mport2, | |
| | Ea to Ma:Mport2 | |
| | sessions OKed ++++++| |
| | | |
|<---200 OK ------| | |
| | | |
|-------ACK------>| | |
| | |..redirected..|
| |-----------ACK--------|------------->|
| | | |
| | | |
|<===================RTP/RTCP============|=============>|
| | | |
|-------BYE------>| | |
| | | |
| |----------------------|-----BYE----->|
| | | |
| |<----------200 OK--------------------|
| | | |
| |+++Terminate the SIP | |
| | Session bundle +++>| |
| |<++SIP Session bundle | |
| | terminated ++++++++| |
| | | |
| |++Cancel permits to | |
| | sessions External | |
| | middlebox, namely | |
| | Ma to Ea:Eport1, | |
| | Ma to Ea:Eport1+1 | |
| | Ea to Ma:Mport2, | |
| | Ea to Ma:Mport2+1 | |
| | sessions ++++++++++>| |
| |<+Removed permits to | |
| | sessions listed ++++| |
| | | |
|<---200 OK-------| | |
| | | |
Legend: ++++ MIDCOM control traffic
---- SIP control traffic
==== RTP/RTCP media traffic
A middlebox cannot be assumed to be a simple device implementing just one middlebox function and no more than a couple of interfaces. Middleboxes often combine multiple intermediate functions into the same device and have the ability to provision individual interfaces of the same device with different sets of functions and varied provisioning for the same function across the interfaces.
ミドルは、ただ一つミドル機能を実現する簡単な装置とのインターフェースのいくつ以下であると仮定することはできません。中間装置は、多くの場合、同じデバイスに複数の中間の機能を組み合わせて、インターフェイスで同じ機能のための機能で多様プロビジョニングの異なるセットと同じデバイスの提供個々インターフェイスする能力を有しています。
As such, 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 services on the same middlebox.
このように、MIDCOMエージェントは、ミドルボックスを持つ単一のMIDCOMセッションを有し、同じミドル上の異なるサービスとインターフェースするようにミドルにMIDCOMインターフェイスを使用することができるようにするべきです。
Asynchronous notification by the middlebox to a MIDCOM agent can be useful for events such as Session creation, Session termination, MIDCOM protocol failure, middlebox function failure or any other significant event. Independently, ICMP error codes can also be useful to notify transport layer failures to the agents.
MIDCOMエージェントにミドルによる非同期通知は、セッション生成、セッション終了、MIDCOMプロトコル障害、ミドル機能障害や他の重要なイベントなどのイベントのために有用であり得ます。独立して、ICMPエラーコードはまた、エージェントにトランスポート層の障害を通知することが有用であり得ます。
In addition, periodic notification of various forms of data, such as statistics update, would also be a useful function that would be beneficial to certain types of agents.
加えて、このような統計情報の更新等のデータの様々な形態の周期的な通知は、また、薬剤の特定のタイプに有益であろう有用な機能であろう。
When supporting the MIDCOM protocol, the middlebox is required to allocate dynamic resources, as specified in policy rule(s), upon request from agents. Explicit release of dynamically allocated resources happens when the application session is ended or when a MIDCOM agent requests the middlebox to release the resource.
MIDCOMプロトコルをサポートする場合、ミドルは、エージェントからの要求に応じて、ポリシールール（単数または複数）で指定されるように、動的リソースを割り当てるために必要とされます。アプリケーションセッションが終了したとき、またはMIDCOMエージェントがリソースを解放するミドルを要求したときに動的に割り当てられたリソースの明示的な解放が起こります。
However, the middlebox should be able to recover the dynamically allocated resources, even as the agent that was responsible for the allocation is not alive. Associating a lifetime for these dynamic resources and using a timer to track the lifetime can be a good way to accomplish this.
しかし、ミドルは、割り当てを担当したエージェントが生きなくても同様に、動的に割り当てられたリソースを回復することができるはずです。これらの動的なリソースの有効期間を関連付けると寿命を追跡するためにタイマーを使用すると、これを実現するための良い方法にすることができます。
A middlebox could be implementing a variety of services (e.g. NAT and firewall) in the same box. Some of these services might have inter-dependency on shared resources and sequence of operation. Others may be independent of each other. Generally speaking, the sequence in which these function operations may be performed on datagrams is not within the scope of this document.
ミドルは、同じボックス内のサービス（例えば、NATやファイアウォール）の様々なを実装することができます。これらのサービスの中には、共有リソースと操作の配列に相互依存関係があるかもしれません。その他は、互いに独立していてもよいです。一般的に言えば、これらの機能の操作がデータグラムに実行され得る順序は、この文書の範囲外です。
In the case of a middlebox implementing NAT and firewall services, it is safe to state that the NAT operation on an interface will precede a firewall on the egress and will follow a firewall on the ingress. Further, firewall access control lists, used by a firewall, are assumed to be based on session parameters, as seen on the interface supporting firewall service.
NATやファイアウォールサービスを実装するミドルの場合は、インターフェイス上のNAT操作は、出口でファイアウォールを先行すると侵入でファイアウォールを続くことを述べることは安全です。さらに、ファイアウォールが使用するファイアウォールアクセス制御リストは、ファイアウォールサービスをサポートしているインタフェースに見られるように、セッションパラメータに基づいてされているものとします。
The class of applications the MIDCOM architecture addresses focus around applications that have a combination of, one or more, signaling and data traffic sessions. The signaling may be done out-of-band, using a dedicated stand-alone session or may be done in-band, within a data session. Alternately, signaling may also be done as a combination of both stand-alone and in-band sessions.
アプリケーションのクラスはMIDCOMアーキテクチャアドレスは、一つ以上の組み合わせを持つアプリケーション、シグナリングとデータトラフィックセッションを周りに焦点を当てています。シグナリングは、専用のスタンドアロン・セッションを使用して、アウトオブバンド行ってもよいし、データセッション内で、帯域内で行われてもよいです。代替的に、シグナル伝達はまた、両方のスタンドアロンおよび帯域内のセッションの組合せとして行うことができます。
SIP is an example of an application based on distinct signaling and data sessions. A SIP signaling session is used for call setup between a caller and a callee. A MIDCOM agent may be required to examine/modify SIP payload content to administer the middlebox so as to let the media streams (RTP/RTCP based) through. A MIDCOM agent is not required to intervene in the data traffic.
SIPは、異なるシグナリング及びデータセッションに基づいて、アプリケーションの一例です。 SIPシグナリングセッションは、呼び出し元と呼び出し先の間でコールセットアップのために使用されています。メディアストリームをさせるようにMIDCOM剤を介して（RTP / RTCPベース）/検査ミドルボックスを管理するためにSIPペイロードコンテンツを変更するために必要とされ得ます。 MIDCOMエージェントは、データトラフィックに介入する必要はありません。
Signaling and context specific Header information is sent in-band, within the same data stream for applications such as HTTP embedded applications, sun-RPC (embedding a variety of NFS apps), Oracle transactions (embedding oracle SQL+, MS ODBC, Peoplesoft) etc.
シグナリングおよびコンテキスト固有のヘッダ情報は、このような組み込みアプリケーション、太陽-RPC（NFSアプリケーションの様々な埋め込み）、OracleのトランザクションHTTPのような用途のために同じデータストリーム内、帯域内送信されるなど（MS ODBC、PeopleSoftの、オラクルSQLを埋め込みます+） 。
H.323 is an example of an application that sends signaling in both dedicated stand-alone sessions, as well as in conjunction with data. H.225.0 call signaling traffic traverses middleboxes by virtue of static policy, no MIDCOM control needed. H.225.0 call signaling also negotiates ports for an H.245 TCP stream. A MIDCOM agent is required to examine/modify the contents of the H.245 so that H.245 can traverse it.
H.323は、両方の専用のスタンドアロンセッションにおいて、ならびにデータに関連してシグナリング送信するアプリケーションの一例です。シグナリングトラフィックH.225.0コールは、静的な政策のおかげ、不要MIDCOM制御によるミドルボックスを横断します。 H.225.0コールシグナリングはまた、H.245 TCPストリーム用のポートをネゴシエートします。 MIDCOMエージェントは、H.245がそれを通過できるように、H.245の内容を変更/検討する必要があります。
H.245 traverses the middlebox and also carries Open Logical Channel information for media data. So, the MIDCOM agent is once again required to examine/modify the payload content needs to let the media traffic flow.
H.245はミドルを横断し、また、メディアデータのためのオープン論理チャネルの情報を運びます。だから、MIDCOMエージェントが再びペイロードコンテンツは、メディアトラフィックの流れを聞かせする必要があり、変更/検討する必要があります。
The MIDCOM architecture takes into consideration, supporting applications with independent signaling and data sessions as well as applications that have signaling and data communicated over the same session.
MIDCOMアーキテクチャは、独立したシグナリングとデータセッションを使用するアプリケーションだけでなく、シグナリングと同じセッションで通信されるデータを持つアプリケーションをサポートする、考慮しました。
In the cases where signaling is done on a single stand-alone session, it is desirable to have a MIDCOM agent interpret the signaling stream and program the middlebox (that transits the data stream) so as to let the data traffic through uninterrupted.
シグナリングは、単一のスタンドアロンセッションで行われているケースでは、MIDCOMエージェントは、シグナリング・ストリームを解釈し、中断のない介してデータトラフィックを許可するように（つまり、データ・ストリームを通過する）ミドルをプログラムすることが望ましいです。
Middleboxes may be stationed in a number of topologies. However, the signaling framework outlined in this document may be limited to only those middleboxes that are located in a DMZ (De-Militarized Zone) at the edge of a private domain, connecting to the Internet. Specifically, the assumption is that you have a single middlebox (running NAT or firewall) along the application route. Discovery of a middlebox along an application route is outside the scope of this document. It is conceivable to have middleboxes located between departments within the same domain or inside the service provider's domain and so forth. However, care must be taken to review each individual scenario and determine the applicability on a case-by-case basis.
中間装置は、トポロジの数に駐留することができます。しかしながら、本文書で概説シグナリング・フレームワークは、インターネットに接続して、プライベートドメインのエッジでDMZ（非武装地帯）に配置されているのみ中間装置に限定してもよいです。具体的には、仮定を使用すると、アプリケーションのルートに沿って（NATやファイアウォールを実行している）、単一のミドルを持っているということです。アプリケーションルートに沿ったミドルの発見は、この文書の範囲外です。同じドメイン内またはサービスプロバイダのドメイン内などの部門の間に位置する中間ボックスを持っていることが考えられます。しかし、ケアは、個々のシナリオを検討し、ケースバイケースで適用可能性を決定するために取られなければなりません。
The applicability may also be illustrated as follows. Real-time and streaming applications, such as Voice-Over-IP, and peer-to-peer applications, such as Napster and Netmeeting, require administering firewalls and NAT middleboxes to let their media streams reach hosts inside a private domain. The requirements are in the form of establishing a "pin-hole" to permit a TCP/UDP session (the port parameters of which are dynamically determined) through a firewall or retain an address/port bind in the NAT device to permit sessions to a port. These requirements are met by current generation middleboxes using adhoc methods, such as embedding application intelligence within a middlebox to identify the dynamic session parameters and administering the middlebox internally as appropriate. The objective of the MIDCOM architecture is to create a unified, standard way to exercise this functionality, currently existing in an ad-hoc fashion, in some of the middleboxes.
次のように適用性も示すことができます。このようなナップスターやNetMeetingなどのVoice over IP、およびピアツーピアアプリケーション、などのリアルタイムおよびストリーミングアプリケーションは、そのメディア・ストリームは、プライベートドメイン内のホストに到達させるために投与し、ファイアウォールやNATミドルボックスが必要です。要件は、ファイアウォールを介してTCP / UDPセッション（動的に決定されたポートのパラメータ）を許可またはにセッションを許可するNATデバイスのアドレス/ポートバインドを保持するために、「ピンホール」を確立するための形態であります港。これらの要件は、動的セッションパラメータを識別するために、ミドルボックス内のアプリケーションインテリジェンスを埋め込み、必要に応じて内部ミドル投与としてアドホックな方法を使用して、現在の世代の中間装置によって満たされます。 MIDCOMアーキテクチャの目的は、ミドルボックスの一部では、現在、アドホックな方法で、既存の、この機能を行使するための統一、標準的な方法を作成することです。
By adopting MIDCOM architecture, middleboxes will be able to support newer applications they have not been able to support thus far. MIDCOM architecture does not, and must not in anyway, change the fundamental characteristic of the services supported on the middlebox.
MIDCOMアーキテクチャを採用することにより、ミドルボックスは、彼らがこれまでサポートすることができていない新しいアプリケーションをサポートすることができるようになります。 MIDCOMアーキテクチャはない、ととにかく、ミドルでサポートされるサービスの基本的な特性を変更しないでください。
Typically, organizations shield a majority of their corporate resources (such as end-hosts) from visibility to the external network by the use of a De-Militarized Zone (DMZ) at the domain edge. Only a portion of these hosts are allowed to be accessed by the external world. The remaining hosts and their names are unique to the private domain. Hosts visible to the external world and the authoritative name server that maps their names to network addresses are often configured within a DMZ (De-Militarized Zone) in front of a firewall. Hosts and middleboxes within DMZ are referred to as DMZ nodes.
典型的には、組織はドメインのエッジで非武装地帯（DMZ）を使用することによって外部ネットワークへの視認性から、企業リソース（例えばエンドホストなど）の大部分を遮蔽します。これらのホストの一部のみが外部の世界にアクセスすることが許可されています。残りのホストとその名前はプライベートドメインに固有のものです。外部世界とのネットワーク・アドレスに自分の名前をマップする権威ネームサーバに見えるホストは、多くの場合、ファイアウォールの前にDMZ（非武装地帯）内で設定されています。 DMZ内のホストと中間装置は、DMZノードと呼ばれます。
Figure 4 below illustrates the configuration of a private domain with a DMZ at its edge. Actual configurations may vary. Internal hosts are accessed only by users inside the domain. Middleboxes, located in the DMZ may be accessed by agents inside or outside the domain.
4下図は、そのエッジでDMZプライベートドメインの構成を示す図です。実際の構成は異なる場合があります。内部ホストは、専用のドメイン内のユーザーがアクセスしています。 DMZ内に配置中間装置は、ドメイン内部または外部エージェントによってアクセスされてもよいです。
\ | /
+-----------------------+
|Service Provider Router|
+-----------------------+
WAN |
Stub A .........|\|....
|
+---------------+
| NAT middlebox |
+---------------+
|
| DMZ - Network
------------------------------------------------------------
| | | | |
+--+ +--+ +--+ +--+ +-----------+
|__| |__| |__| |__| | Firewall |
/____\ /____\ /____\ /____\ | middlebox |
DMZ-Host1 DMZ-Host2 ... DMZ-Name DMZ-Web +-----------+
Server Server etc. |
|
Internal Hosts (inside the private domain) |
------------------------------------------------------------
| | | |
+--+ +--+ +--+ +--+
|__| |__| |__| |__|
/____\ /____\ /____\ /____\
Int-Host1 Int-Host2 ..... Int-Hostn Int-Name Server
Figure 4: DMZ network configuration of a private domain.
図4：プライベートドメインのDMZネットワーク構成。
The authors wish to thank Christian Huitema, Joon Maeng, Jon Peterson, Mike Fisk, Matt Holdrege, Melinda Shore, Paul Sijben, Philip Mart, Scott Brim and Richard Swale for their valuable critique, advice and input on an earlier rough version of this document. The authors owe special thanks to Eliot Lear for kick-starting the e-mail discussion on use-case scenarios with a SIP application flow diagram through a middlebox. Much thanks to Bob Penfield, Cedric Aoun, Christopher Martin, Eric Fleischman, George Michaelson, Wanqun Bao, and others in the MIDCOM work group for their very detailed feedback on a variety of topics and adding clarity to the discussion. Last, but not the least, the authors owe much thanks to Mark Duffy, Scott Brim, Melinda Shore and others for their help with terminology definition and discussing the embedded requirements within the framework document.
作者はこのドキュメントの以前のラフバージョンに貴重な批評、アドバイスや入力のためのクリスチャンのHuitema、ジュンMaeng、ジョンピーターソン、マイク・フィスク、マット・ホールドレッジ、メリンダ・ショア、ポールSijben、フィリップ・マート、スコット・ブリムとリチャードSwaleに感謝したいです。著者は、キック始動ミドルを通じてSIPアプリケーションフロー図とユースケースのシナリオ上の電子メールの議論のためのエリオット・リアに特別な感謝を負います。彼らの非常に詳細なさまざまなトピックについてのフィードバックや議論に明確さを追加するためのMIDCOMワークグループでの多くのボブペンフィールド、セドリックアウン、クリストファー・マーティン、エリックFleischman、ジョージ・マイケルソン、Wanqunバオのおかげで、その他。最後に、ではなく、少なくとも、筆者は、用語の定義や枠組み文書内に埋め込まれた要件を議論して彼らの助けのために多くのマーク・ダフィー、スコット・ブリム、メリンダ・ショアのおかげで、他を負います。
Discussed below are security considerations in accessing a middlebox. Without MIDCOM protocol support, the premise of a middlebox operation fundamentally requires the data to be in the clear, as the middlebox needs the ability to inspect and/or modify packet headers and payload. This compromises the confidentiality requirement in some environments. Further, updating transport headers and rewriting application payload data, in some cases, by NAT prevents the use of integrity protection on some data streams traversing NAT middleboxes. Clearly, this can pose a significant security threat to the application in an untrusted transport domain.
ミドルにアクセスする際のセキュリティの考慮事項については後述します。ミドルボックスは、検査および/またはパケットヘッダとペイロードを変更する能力を必要とするようにMIDCOMプロトコルのサポートなしで、ミドル動作の前提は、基本的に、明確にするデータを必要とします。これは、一部の環境で機密性の要件を損ないます。また、搬送ヘッダを更新し、アプリケーションのペイロードデータを書き換えるには、いくつかのケースでは、NATにより、NATミドルボックスを横断するいくつかのデータ・ストリームの完全性保護の使用を防止します。明らかに、これは信頼されていないトランスポート・ドメイン内のアプリケーションに重大なセキュリティ上の脅威をもたらすことができます。
The MIDCOM protocol framework removes the need for a middlebox to inspect or manipulate transport payload. This allows applications to better protect themselves end-to-end with the aid of a trusted MIDCOM agent. This is especially the case when the agent is a resident on the end-host. When an agent has the same end-to-end ability as the end-host to interpret encrypted and integrity protected data, transiting a middlebox can be encrypted and integrity protected. The MIDCOM agent will still be able to interpret the data and simply notify the middlebox of open holes, install NAT table entries, etc. Note, however, the MIDCOM framework does not help with the problem of NAT breaking IPsec since in this case the middlebox still modifies IP and transport headers.
MIDCOMプロトコルフレームワークは、トランスポートペイロードを検査または操作するミドルボックスの必要性を除去します。これにより、アプリケーションはより良い信頼できるMIDCOMエージェントの助けを借りて、エンド・ツー・エンド身を守ることができます。これは、エージェントがエンドホスト上に常駐している場合には特にそうです。エージェントは暗号化されたと完全性保護されたデータを解釈するためのエンドホストと同じエンド・ツー・エンドの能力を持っている場合は、ミドルを通過することは、暗号化と完全性を保護することができます。 MIDCOMエージェントがまだデータを解釈し、単にオープン穴のミドルを通知し、NATテーブルエントリなど注意をインストールすることができます、しかし、MIDCOMフレームワークは、この場合、ミドルで以来、IPsecを壊すNATの問題を解決しませんまだIPと輸送のヘッダーを変更します。
Security between a MIDCOM agent and a middlebox has a number of components. Authorization, authentication, integrity and confidentiality. Authorization refers to whether a particular agent is authorized to signal a middlebox with requests for one or more applications, adhering to a certain policy profile. Failing the authorization process might indicate a resource theft attempt or failure due to administrative and/or credential deficiencies. In either case, the middlebox should take the proper measures to audit/log such attempts and consult its designated MIDCOM PDP for the required action if the middlebox is configured with one. Alternatively, the middlebox may resort to a default service deny policy when a MIDCOM agent fails to prompt the required credentials. Section 6 discusses the middlebox to MIDCOM PDP interactions in view of policy decisions.
MIDCOMエージェントとミドル間の安全保障は、部品の数を持っています。認可、認証、完全性と機密性。許可は、特定のエージェントが特定のポリシープロファイルに付着した、1つ以上のアプリケーションの要求とミドルに信号を送るために許可されているかどうかを指します。承認プロセスを失敗すると、管理および/または資格不足によるリソースの盗難の試みや失敗を示している可能性があります。いずれの場合においても、ミドルボックスは、監査/ような試みを記録し、ミドルボックスは、1つで構成されている場合に必要なアクションのために、その指定されたMIDCOM PDPに相談するための適切な措置をとるべきです。また、ミドルはMIDCOMエージェントが必要な資格情報を要求するように失敗したときにポリシーを拒否するデフォルトのサービスに頼ることがあります。第6節は、政策決定の観点からMIDCOM PDPの相互作用にミドルを説明します。
Authentication refers to confirming the identity of an originator for all datagrams received from the originator. Lack of strong credentials for authentication of MIDCOM messages between an agent and a middlebox can seriously jeopardize the fundamental service rendered by the middlebox. A consequence of not authenticating an agent would be that an attacker could spoof the identity of a "legitimate" agent and open holes in the firewall. Another would be that it could otherwise manipulate the state on a middlebox, creating a denial-of-service attack by closing needed pinholes or filling up a NAT table. A consequence of not authenticating the middlebox to an agent is that an attacker could pose as a middlebox and respond to NAT requests in a manner that would divert data to the attacker. Failing to submit the required/valid credentials, once challenged, may indicate a replay attack, in which case a proper action is required by the middlebox such as auditing, logging, or consulting its designated MIDCOM PDP to reflect such failure. A consequence of not protecting the middlebox against replay attacks would be that a specific pinhole may be reopened or closed by an attacker at will, thereby bombarding end hosts with unwarranted data or causing denial of service.
認証は、発信者から受信したすべてのデータグラムの発信者の身元を確認することをいいます。エージェントとミドルの間MIDCOMメッセージの認証のための強力な資格情報の欠如は深刻なミドルでレンダリングされた基本的なサービスを危うくすることができます。エージェントを認証していないの結果は、攻撃者がファイアウォールで「合法的な」エージェントのアイデンティティとオープン穴を偽装できることでしょう。もう一つは、それ以外に必要なピンホールを閉じたり、NATテーブルを埋めることにより、サービス拒否攻撃を作成し、ミドルで状態を操作できることになります。エージェントにミドルを認証しない結果は、攻撃者がミドルのふりをし、攻撃者にデータをそらすでしょう方法で、NATの要求に応えることができることです。一度挑戦/必要な有効な証明書を、提出しないと、適切なアクションが、このような監査、ロギング、またはこのような障害を反映するために指定されたMIDCOM PDPコンサルティングなどミドルで必要とされる場合には、リプレイ攻撃を示すことができます。リプレイ攻撃ミドルボックスを保護しないの結果は、特定のピンホールがそれによって不当なデータをエンドホストに衝突またはサービスの拒否を引き起こす、意志で攻撃者によって再び開くまたは閉じることができることであろう。
Integrity is required to ensure that a MIDCOM message has not been accidentally or maliciously altered or destroyed. The result of a lack of data integrity enforcement in an untrusted environment could be that an imposter will alter the messages sent by an agent and bring the middlebox to a halt or cause a denial of service for the application the agent is attempting to enable.
完全性はMIDCOMメッセージが偶然または故意変更または破壊されていないことを確認する必要があります。信頼されていない環境でのデータの整合性の施行の欠如の結果は、詐欺師は、エージェントによって送信されたメッセージを変更し、停止にミドルを持参またはエージェントが使用可能にしようとしているアプリケーションのためにサービス拒否を引き起こすことである可能性があります。
Confidentiality of MIDCOM messages ensure that the signaling data is accessible only to the authorized entities. When a middlebox agent is deployed in an untrusted environment, lack of confidentiality will allow an intruder to perform traffic flow analysis and snoop the middlebox. The intruder could cannibalize a lesser secure MIDCOM session and destroy or compromise the middlebox resources he uncovered on other sessions. Needless to say, the least secure MIDCOM session will become the achilles heel and make the middlebox vulnerable to security attacks.
MIDCOMメッセージの機密性は、シグナリングデータのみを許可エンティティにアクセス可能であることを確認してください。ミドル・エージェントは、信頼されていない環境の中で展開されている場合は、機密性の欠如は、侵入者がトラフィックフロー分析を実行し、ミドルをスヌープすることができます。侵入者は少なく、安全なMIDCOMセッションを共食いし、破壊したり、彼が他のセッションで明らかになったミドルリソースを危険にさらす可能性があります。言うまでもなく、最も安全MIDCOMセッションは、アキレス腱になると、セキュリティ攻撃にミドルが脆弱になります。
Lastly, there can be security vulnerability to the applications traversing a middlebox when a resource on a middlebox is controlled by multiple external agents. A middlebox service may be disrupted due to conflicting directives from multiple agents associated with different middlebox functions but applied to the same application session. Care must be taken in the protocol design to ensure that agents for one function do not abruptly step over resources impacting a different function. Alternately, the severity of such manifestations could be lessened when a single MIDCOM agent is responsible for supporting all the middlebox services for an application, due to the reduced complexity and synchronization effort in managing the middlebox resources.
最後に、ミドル上のリソースを複数の外部エージェントによって制御されたときにミドルを横断するアプリケーションにセキュリティ上の脆弱性が存在することができます。ミドルボックスサービスは、異なるミドルボックス機能に関連する複数のエージェントから起因競合指令に破壊が、同じアプリケーションセッションに適用することができます。ケアは一つの機能のための薬剤が突然別の機能に影響を与える資源をステップオーバーしていないことを確実にするためのプロトコルの設計に注意する必要があります。単一MIDCOMエージェントが原因ミドル資源管理における複雑さの低減と同期の努力に、アプリケーションのすべてのミドルサービスをサポートする責任があるとき代わりに、そのような症状の重症度を軽減することができます。
References
リファレンス
[SIP] Rosenberg, J., Shulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., Schooler, E., "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[SIP]ローゼンバーグ、J.、Shulzrinne、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、学生はE.、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[SDP] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[SDP]ハンドリー、M.およびV. Jacobson氏、 "SDP：セッション記述プロトコル"、RFC 2327、1998年4月。
[H.323] ITU-T Recommendation H.323. "Packet-based Multimedia Communications Systems," 1998.
[H.323] ITU-T勧告H.323。 「パケットベースのマルチメディア通信システム、」1998
[RTP] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[RTP] Schulzrinneと、H.、Casner、S.、フレデリック、R.とV. Jacobson氏、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、RFC 1889、1996年1月。
[RTSP] Schulzrinne, H., Rao, A. and R. Lanphier: "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RTSP] Schulzrinneと、H.とラオとA.とR. Lanphier： "リアルタイムストリーミングプロトコル（RTSP）"、RFC 2326、1998年4月。
[FTP] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[FTP]ポステル、J.とJ.レイノルズ、 "ファイル転送プロトコル"、STD 9、RFC 959、1985年10月。
[NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[NAT-TERM] Srisuresh、P.とM.ホールドレッジ、 "IPネットワークアドレス変換（NAT）用語と考慮事項"、RFC 2663、1999年8月。
[NAT-TRAD] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[NAT-TRAD] Srisuresh、P.とK. Egevang、 "伝統的なIPネットワークアドレス変換（NAT繁体字）"、RFC 3022、2001年1月。
[NAT-PT] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[NAT-PT] Tsirtsis、G.とP. Srisuresh、 "ネットワークアドレス変換 - プロトコル変換（NAT-PT）"、RFC 2766、2000年2月。
[IPsec-AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[IPsecの-AH]ケント、S.とR.アトキンソン、 "IP認証ヘッダー"、RFC 2402、1998年11月。
[IPsec-ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[IPsecの-ESP]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 2406は、1998年11月。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[TLS]ダークス、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
[POL-TERM] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S. Waldbusser, "Terminology for Policy-Based Management", RFC 3198, November 2001.
[POL-TERM] Westerinen、A.、Schnizlein、J.、Strassner、J.、Scherling、M.、クイン、B.、ヘルツォーク、S.、フイン、A.、カールソン、M.、ペリー、J.及びS. Waldbusser、 "ポリシーベースの管理のための用語"、RFC 3198、2001年11月。
[REQMTS] Swale, R. P., Mart, P. A., Sijben, P., Brim, S. and M. Shore, "Middlebox Communications (midcom) Protocol Requirements", RFC 3304, August 2002.
【REQMTS] Swale、R. P.、マート、P. A.、Sijben、P.、ブリム、S.及びM.ショア、 "ミドル・コミュニケーションズ（MIDCOM）プロトコル要件"、RFC 3304、2002年8月。
Authors' Addresses
著者のアドレス
Pyda Srisuresh Kuokoa Networks, Inc. 475 Potrero Ave. Sunnyvale, CA 94085 EMail: srisuresh@yahoo.com
Pyda Srisuresh Kuokoaネットワークス株式会社475ポトレロアベニュー。サニーベール、CA 94085 Eメール：srisuresh@yahoo.com
Jiri Kuthan Fraunhofer Institute FOKUS Kaiserin-Augusta-Allee 31 D-10589 Berlin, Germany EMail: kuthan@fokus.fhg.de
智異Kuthanフラウンホーファー研究所FOKUSカイザリンオーガスタダレ31 D-10589ベルリン、ドイツEメール：kuthan@fokus.fhg.de
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936 U.S.A. EMail: jdrosen@dynamicsoft.com
ジョナサン・ローゼンバーグdynamicsoft 72イーグルロックアベニューまず階イーストハノーバー、NJ 07936 U.S.A.メール：jdrosen@dynamicsoft.com
Andrew Molitor Aravox technologies 4201 Lexington Avenue North, Suite 1105 Arden Hills, MN 55126 U.S.A. voice: (651) 256-2700 EMail: amolitor@visi.com
アンドリュー・モリターAravox技術4201レキシントンアベニュー北、スイート1105アーデンヒル、MN 55126 U.S.A.声：（651）256から2700 Eメール：amolitor@visi.com
Abdallah Rayhan WINCORE Lab Electrical and Computer Engineering Ryerson University 350 Victoria Street Toronto, ON M5B 2K3 EMail: rayhan@ee.ryerson.ca, ar_rayhan@yahoo.ca
M5B 2K3メールにアブダラRayhan WINCOREラボ電気・コンピュータ工学ライアソン大学350ビクトリアストリートトロント、：rayhan@ee.ryerson.ca、ar_rayhan@yahoo.ca
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機能のための基金は現在、インターネット協会によって提供されます。