RFC3303 日本語訳
3303 Middlebox communication architecture and framework. P. Srisuresh,J. Kuthan, J. Rosenberg, A. Molitor, A. Rayhan. August 2002. (Format: TXT=91209 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
Srisureshがコメントのために要求するワーキンググループP.をネットワークでつないでください: 3303Kuokoaはカテゴリをネットワークでつなぎます: 情報のJ.のAravox Technologies A.Rayhanライアソン大学KuthanフラウンホーファーInstitute FOKUS J.ローゼンバーグdynamicsoft A.モリトル2002年8月
Middlebox communication architecture and framework
Middlebox通信アーキテクチャとフレームワーク
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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.
このドキュメントの主要な目的はmiddleboxesを通した複雑なアプリケーションを可能にするためにmiddleboxコミュニケーション(MIDCOM)の基本的なフレームワークについて説明することです、シームレスに信頼できる第三者機関を使用して。 MIDCOM要件([REQMTS])のこのドキュメントと仲間ドキュメントは先駆としてMIDCOMワーキンググループが「再-特許」であるのに作成されました。
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などのピアツーピアアプリケーションに関係するデータグラムは特定できません。 FirewallとNetwork Address Translatorがサービスであると実装するMiddleboxesが彼らの操作のためのデバイスの中にアプリケーション知性を通常埋め込みます。 ドキュメントはmiddleboxesが彼らの操作を実行するのを補助するのを信頼できる第三者機関を代表として派遣することができるアーキテクチャとフレームワークを指定します、アプリケーション知性を埋め込むのに再ソートしないで。 これをするのに、middleboxは、middleboxアプリケーションを不可知論者に保管する間、サービスを提供し続けることができるでしょう。
Srisuresh, et al. Informational [Page 1] RFC 3303 MIDCOM Architecture and Framework August 2002
Srisuresh、他 情報[1ページ]のRFC3303MIDCOMアーキテクチャとフレームワーク2002年8月
1. Introduction
1. 序論
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.
アプリケーション知性を必要とする中間的デバイスはこのドキュメントの対象です。 これらのデバイスはドキュメント中にmiddleboxesと呼ばれます。 これらのデバイスの多くがパケットフィルタリング、VPN(仮想の兵士のNetwork)トンネリング、Intrusion検出、セキュリティなどなどのアプリケーション特定保険証券に基づいている機能を実施します。 他方では、ネットワークAddress Translatorサービスはアドレス分野(IPv4ルーティングネットワークかV4とV6ルーティング分野の向こう側の)の向こう側にルーティング透明を提供します、アプリケーションの如何にかかわらず。 アプリケーションLevel Gateways(ALGs)が調べるNATに関連して使用されて、任意にアプリケーションペイロードを変更するので、終わりから終わりへのアプリケーション振舞いはNAT middleboxesを横断するアプリケーションの多くのために変わりがありません。 彼らの操作のためにアプリケーション知性をmiddleboxesに埋め込むのを必要とする他のタイプのサービスがあるかもしれません。 しかしながら、このドキュメントの議論範囲はFirewallと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.
middleboxesがあるアプリケーション知性の密結合で、middleboxesのメインテナンスは新しいアプリケーションの到来が困難になります。 内蔵のアプリケーション認識は新しいアプリケーションによるオペレーティングシステムのアップデートか既存のアプリケーションの、より新しいバージョンを通常必要とします。 より新しいアプリケーションに支持を要するオペレータは、アプリケーションに特定の第三者ソフトウェア/ハードウェアを使用できないで、必要なアップグレードをするように、それらのmiddleboxベンダーの思うままにいます。 さらに、同じmiddleboxの中の多くのアプリケーション・プロトコルのために知性を埋め込むのは、middleboxの複雑さを増強して、誤り傾向があって、性能で退行しそうです。
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.
このドキュメントはアプリケーション知性をmiddleboxesから外部のMIDCOMエージェントに動かすことができるフレームワークについて説明します。 フレームワークの前提がアプリケーション独立者であるMIDCOMプロトコルについて工夫することになっているので、middleboxesはファイアウォールや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
アプリケーション知性があるMIDCOMエージェントはFTPや、SIPやH.323などのアプリケーションを可能にするのにMIDCOMプロトコルを通したmiddleboxesを助けることができます。 MIDCOMエージェントとmiddleboxとのコミュニケーションはアプリケーションに参加する終わりホストにとってめぼしくならないでしょう、終わりホストのひとりがMIDCOMエージェントの役割を引き受けない場合。 中のmiddleboxesかMIDCOMエージェントの発見
Srisuresh, et al. Informational [Page 2] RFC 3303 MIDCOM Architecture and Framework August 2002
Srisuresh、他 情報[2ページ]のRFC3303MIDCOMアーキテクチャとフレームワーク2002年8月
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.
このドキュメントの範囲の外にアプリケーションインスタンスの経路があります。 さらに、このドキュメントの範囲の外にもmiddleboxesの中のどんなコミュニケーションもあります。
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.
このドキュメントはmiddleboxコミュニケーションが行われるフレームワークとフレームワークを構成する様々な要素について説明します。 セクション2はドキュメントで使用される用語について説明します。 セクション3はMIDCOMエージェントとのコミュニケーションのためにmiddleboxの建築フレームワークを定義します。 残っているセクションはMIDCOMアーキテクチャでフレームワーク、サンプル流れを使用するイラスト、および操作上の問題の成分をカバーします。 セクション4はMIDCOMプロトコルの本質について説明します。 セクション5は潜在的にMIDCOMエージェント機能を接待できた実体を特定します。 セクション6は、MIDCOMエージェント承認方針を伝えることに関してPolicyの役割がサーバとその機能であると考えます。 セクション7はSIPプロキシサーバでMIDCOMエージェントがコレジデントであるMIDCOMフレームワークを使用するSIP流れのイラストです。セクション8は、展開における操作上の問題がここで説明されたフレームワークを固く守るプロトコルであると扱います。 middleboxesの位置を見て、セクション9は適用性証明です。 セクション11はmiddleboxのためにMIDCOMフレームワークから見てセキュリティ問題について概説します。
2. Terminology
2. 用語
Below are the definitions for the terms used throughout the document.
以下に、定義がドキュメント中で使用される期間、あります。
2.1. Middlebox function/service
2.1. Middlebox機能/サービス
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).
middlebox機能かmiddleboxサービスが、操作のためにアプリケーションの特定の知性を必要とするかもしれないネットワーク仲介者によって実行された操作かメソッドです。 Policyはトンネリングを基礎づけました、そして、方針はパケットフィルタリング(通称ファイアウォール)を基礎づけました、Networkアドレス変換(NAT)、Intrusion検出、Loadバランスをとること、IPsecセキュリティはすべてmiddlebox機能(または、サービス)に関する例です。
2.2. Middlebox
2.2. Middlebox
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.
Middleboxはmiddleboxサービスのネットワーク中間的な1つを実装するデバイスか以上です。 NAT middleboxはNATがサービスであると実装するmiddleboxです。 ファイアウォールmiddleboxはファイアウォールサービスを実装するmiddleboxです。
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は、特定のアプリケーションが縦断であるとサポートするためにデバイスの中にアプリケーション知性を埋め込みます。 MIDCOMプロトコルをサポートするMiddleboxesはMIDCOMエージェントにアプリケーション知性を外面化できるでしょう。 ほんとうはいくつか
Srisuresh, et al. Informational [Page 3] RFC 3303 MIDCOM Architecture and Framework August 2002
Srisuresh、他 情報[3ページ]のRFC3303MIDCOMアーキテクチャとフレームワーク2002年8月
middleboxes may continue to embed application intelligence for certain applications and depend on MIDCOM protocol and MIDCOM agents for the support of remaining applications.
middleboxesはアプリケーションのままで残るサポートのためにあるアプリケーションのためにアプリケーション知性を埋め込んで、MIDCOMプロトコルとMIDCOMエージェントに頼り続けるかもしれません。
2.3. Firewall
2.3. ファイアウォール
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).
ファイアウォールは特定のデバイスとアプリケーションからの/へのアクセスを制限するのに通常使用される方針に基づいているパケットフィルタリングmiddlebox機能です。 方針はしばしばAccess Control Lists(ACLs)と呼ばれます。
2.4. NAT
2.4. NAT
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.
ネットワークAddress TranslationはIPアドレスが1つのアドレス分野から別の分野まで写像されるメソッドです、見え透いたルーティングを終わりホストに提供して。 ここでの見え透いたルーティングが途中で、エンドノードアドレスを変更して、これらのアップデートのために状態を維持するのを示すので、データグラムが1つの分野を出て、別のものに入るとき、どちらの分野でも正しい終わりホストにセッションに関するデータグラムを送ります。 使用中のTransparentルーティングの定義、様々なNATタイプ、および関連用語について[NAT-TERM]を参照してください。 2つのタイプのNATは最も一般的です。 IPアドレスとa TCP/UDPなどのトランスポート層識別子の両方が移植する基本的なNATとパケットのIPアドレス(そして、関連IP、TCP/UDPチェックサム)だけがどこで変更されるか、そして、NAPT(ネットワークAddress Port Translation)、どこ、(関連する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は、本書では[NAT-TERM]で説明されたIPv4NATと非常に同様ですが、[太平洋標準時のNAT]で説明された太平洋標準時のIPv4-v6NATを含むようにIPv4ネットワークを超えて広げられます。 IPv4NAT[NAT-TERM]は個人的なV4と外部のV4アドレス分野の間にルーティングを供給するために1つのIPv4アドレスを別のIPv4アドレスに翻訳しますが、太平洋標準時のIPv4-v6NAT[太平洋標準時のNAT]は、V6アドレス分野と外部のV4アドレス分野の間にルーティングを提供するために逆もまた同様にIPv4アドレスをIPv6アドレスに翻訳します。
Unless specified otherwise, NAT in this document is a middlebox function referring to both IPv4 NAT, as well as IPv4-v6 NAT-PT.
別の方法で指定されない場合、NATは本書では両方のIPv4NATについて言及するmiddlebox機能です、太平洋標準時のIPv4-v6NATと同様に。
2.5. Proxy
2.5. プロキシ
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.
2つの間のアプリケーションメッセージをリレーして、プロキシはアプリケーションのクライアントとサーバの間の中間的中継エージェントです。 プロキシは、プロキシクライアントとリレークライアントデータで逆もまた同様にサーバに伝えるのに特別なプロトコルメカニズムを使用します。 Proxyは終わりホストクライアントと終わりホストサーバへのクライアントとしてクライアントとサーバの両方とのセッション、サーバとしての芝居を終えます。
Srisuresh, et al. Informational [Page 4] RFC 3303 MIDCOM Architecture and Framework August 2002
Srisuresh、他 情報[4ページ]のRFC3303MIDCOMアーキテクチャとフレームワーク2002年8月
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などのリアルタイムのストリーミング・アプリケーションがあるそうです。
2.6. ALG
2.6. ALG
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.
アプリケーションLevel Gateways(ALGs)は関連middlebox機能に関するアプリケーションの特定の知性と知識がある実体です。 ALGはアプリケーション通過運送を調べて、機能を行うのにmiddleboxを助けます。
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.
middlebox通信プロトコルを通って交信して、ALGはmiddleboxをもっているコレジデントであるか外部的に住むかもしれません。 アプリケーションがmiddleboxを貫くのを可能にするのに必要であっても、他のことなら何でもそれは、状態を設立するか、コントロール・フィルタにアクセスするか、middlebox州の情報を使用するか、アプリケーションの特定のペイロードを変更するか、または働くためにmiddleboxと対話します。
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.
ALGsはプロキシと異なっています。 両方の終わりホストとのセッションを終えるそうするプロキシと異なってホストを終わらせている中継エージェントにとって、ALGsは目に見えません。 ALGsはどちらかの終わりホストとのセッションを終えません。 代わりに、ALGsは、middleboxを通したアプリケーショントラフィックの流れを容易にするようにアプリケーションペイロード内容を調べて、任意に変更します。 彼らが彼らの機能を行うのにmiddleboxesを助けますが、プロキシがアプリケーション・サーバーのための焦点として務めるので、ALGsはmiddlebox中心です、アプリケーションクライアントとサーバの間のトラフィックをリレーして。
ALGs are similar to Proxies, in that, both ALGs and proxies facilitate Application specific communication between clients and servers.
ALGsがProxiesと同様である、それでは、ALGsとプロキシの両方がクライアントとサーバとのApplicationの特定のコミュニケーションを容易にします。
2.7. End-Hosts
2.7. 終わりホスト
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などのレアル-時間のストリーミングのVoice-over-IPアプリケーション、およびナップスターやNetMeetingなどのピアツーピアアプリケーションを終えていますか?
2.8. MIDCOM Agents
2.8. MIDCOMエージェント
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
MIDCOMエージェントはmiddleboxへの論理的に外部のALG機能を実行する実体です。 MIDCOMエージェントには、アプリケーション認識の組み合わせとmiddlebox機能に関する知識があります。 これ
Srisuresh, et al. Informational [Page 5] RFC 3303 MIDCOM Architecture and Framework August 2002
Srisuresh、他 情報[5ページ]のRFC3303MIDCOMアーキテクチャとフレームワーク2002年8月
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.
組み合わせは、エージェントがアプリケーションのパケットでmiddleboxの縦断を容易にするのを可能にします。 MIDCOMエージェントは1middleboxesと対話するかもしれません。
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プロトコルに重要でないです。 In-経路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エージェント」と呼ばれて、このドキュメントの範囲の外にいます。
2.9. MIDCOM PDP
2.9. MIDCOM PDP
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".
MIDCOM Policy Decision Point(PDP)は[POL-TERM]で定義されるように主としてPolicy Decision Point(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.
middleboxとMIDCOM PDPは、MIDCOM PDPの方針が変化するかどうか、またはmiddleboxが詳細を必要とするかどうかさらに伝えるかもしれません。 いつでも、MIDCOM PDPは、middleboxがエージェントのための承認を終えるように通知するかもしれません。
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.
middleboxと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
アプリケーション特定保険証券データと方針はエージェントかアプリケーション終点の間で連結します、そして、MIDCOM PDPはこのドキュメントのために区域外にあります。 ドキュメントで扱われたMIDCOM PDP問題はmiddleboxに適するとして集合ドメインレベルで焦点を合わせられます。 例えば、SIP MIDCOMエージェントは、確信しているユーザが発信電話をすることができるかどうか管理の、そして、(法人)のドメインによってわかるようにMIDCOM PDPについて質問するのを選ぶかもしれません。 このタイプの適用
Srisuresh, et al. Informational [Page 6] RFC 3303 MIDCOM Architecture and Framework August 2002
Srisuresh、他 情報[6ページ]のRFC3303MIDCOMアーキテクチャとフレームワーク2002年8月
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のために区域外にあります。 しかしながら、領域の中にそれはエージェントがALGであることを許可されている特定のエンドユーザアプリケーション(または、tuples)を指定するMIDCOM PDPのためにあります。
2.10. Middlebox Communication (MIDCOM) protocol
2.10. Middlebox Communication(MIDCOM)プロトコル
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エージェントとmiddleboxの間のプロトコルで、MIDCOMエージェントをmiddleboxのサービスを呼び出して、middleboxがアプリケーションの特定の処理をMIDCOMエージェントへ代表として派遣するのを許容します。 middleboxはMIDCOMプロトコルでMIDCOMエージェントの援助で操作を実行できます、アプリケーション知性を埋め込むのに再ソートしないで。 このプロトコルをarchitectingする後ろの主要な動機はmiddleboxesを通した複雑なアプリケーションを可能にすることです、シームレスに、信頼できる第三者機関(すなわち、MIDCOMエージェント)を使用して
This is a protocol yet to be devised.
これはまだ工夫されるべきプロトコルです。
2.11. MIDCOM agent registration
2.11. MIDCOMエージェント登録
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エージェント登録はmiddleboxがあるエージェントプロフィール情報か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として機能するのに権限を与えられるセッションtuples)、実体を接待するエージェント(エージェントを接待する例えば、Proxy、ゲートウェイ、または終わりホスト)、エージェントアクセシビリティプロフィール(どんなホストレベル認証情報も含んでいる)、およびセキュリティが輪郭を描く(middleboxとエージェントの間で交換されたメッセージのために)エージェント承認方針を含むかもしれません。
2.12. MIDCOM session
2.12. MIDCOMセッション
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エージェントとmiddleboxとの永久の仲間になるように定義されます。 MIDCOMセッションがどんな特定のトランスポート層プロトコルも含意すると思われません。 明確に、接続指向のTCPプロトコルを示すのにこれを理解するべきではありません。
2.13. Filter
2.13. フィルタ
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
フィルタはmiddleboxによって、ある方法で扱われるように1セットのパケットを特定するパケットの合っている情報です。 この定義は[POL-TERM]と一致しています。(それは、「セットされたA」とフィルタを定義します)。
Srisuresh, et al. Informational [Page 7] RFC 3303 MIDCOM Architecture and Framework August 2002
Srisuresh、他 情報[7ページ]のRFC3303MIDCOMアーキテクチャとフレームワーク2002年8月
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.
ファイアウォールの場合におけるパケットの5-Tuple仕様とNAT middlebox機能の場合におけるセッションの5tuple仕様はフィルタに関する例です。
2.14. Policy action (or) Action
2.14. 政策的措置(or)動作
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".
政策的措置(または、Action)は1セットのパケットに適用されるべきmiddlebox処理/サービスの記述です。 この定義は[POL-TERM]と一致しています。(それは、「規則に関する条件を満たすとき、政策ルールを実施するために何をすることになっていたらよいかに関する定義」と政策的措置を定義します)。 「政策的措置は、影響する1つ以上の操作の実行をもたらす、そして/または、ネットワークトラフィックとネットワーク資源を構成するかもしれません。」
NAT Address-BIND (or Port-BIND in the case of NAPT) and firewall permit/deny action are examples of an Action.
Address-BIND(または、NAPTの場合におけるPort-BIND)とファイアウォールが動作を可能にするか、または否定するNATはActionに関する例です。
2.15. Policy rule(s)
2.15. 政策ルール(s)
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規則は独特の規則タイプ、タイムアウト値、エージェントを創造などなどの補助の属性を含むかもしれません。
Policy rules are communicated through the MIDCOM protocol.
政策ルールはMIDCOMプロトコルを通して伝えられます。
3.0 Architectural framework for middleboxes
3.0 middleboxesのための建築フレームワーク
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.
middleboxはデバイスの複数のインタフェースで選択的にmiddlebox機能の1つ以上を実装するかもしれません。 インタフェースでmiddlebox機能の1つ以上とコミュニケートするためにmiddleboxに連結するさまざまなMIDCOMエージェントがいることができます。 そういうものとして、middlebox通信プロトコルはインタフェースでの特定のMIDCOMエージェントと複数のmiddlebox機能との選択しているコミュニケーションを考慮しなければなりません。 以下のダイヤグラムは可能なmiddleboxによってサポートされたサービスのレイヤリングとそれと対話するかもしれないMIDCOMエージェントのリストを特定します。
Srisuresh, et al. Informational [Page 8] RFC 3303 MIDCOM Architecture and Framework August 2002
Srisuresh、他 情報[8ページ]のRFC3303MIDCOMアーキテクチャとフレームワーク2002年8月
+---------------+ +--------------+
| 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 | |
+-------------------------------------------+
+---------------+ +--------------+ | MIDCOMエージェント| | MIDCOMエージェント| | コレジデント、オン| | コレジデント| | Proxyサーバ| | Applに関して。 GW| +---------------+ +--------------+ ^ ^ | | +--------+ MIDCOM| | | MIDCOM| プロトコル| | +-| PDP| | | / +--------+ +-------------+ | | / | MIDCOMエージェント| | | / | コレジデント| | | / | 終わりホストに関して| <、-+ | | / +-------------+ | | | | v v対+に-------------------------------------------+ | Middleboxコミュニケーション|方針| | プロトコル(MIDCOM)インタフェース|インタフェース| +----------+--------+-----------+-----------+ Middlebox| | | | | 機能| ファイアウォール| NAT| VPN| 侵入| | | | トンネリング| 検出| +----------+--------+-----------+-----------+ Middlebox| Middlebox機能特定保険証券規則| 管理されます。| そして、他の属性| リソース| | +-------------------------------------------+
Figure 1: MIDCOM agents interfacing with a middlebox
図1: middleboxに連結する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.
ファイアウォールACLs、NAT-BINDs、NATアドレス地図、およびSession-状態はmiddlebox機能特定保険証券規則のいくつかです。 セッション州はmiddleboxの機能の特定の属性を含めるかもしれません、タイムアウト値、NAT翻訳パラメタ(すなわち、NAT-BINDS)などなどのように。 Session-状態がmiddlebox機能の向こう側に共有されるとき、Session-状態は、機能によって創設されて、異なった機能によって終えられるかもしれません。 例えば、セッション状態は、ファイアウォール機能によって作成されますが、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
アプリケーションの特定のMIDCOMエージェント(middleboxへのmiddleboxか外部のコレジデント)は、IPデータグラムを調べて、データグラムが属すアプリケーションを特定するのを助けて、アプリケーションとmiddleboxサービスにユニークな実行機能にmiddleboxを助けるでしょう。 例えば、ところが、NAT middleboxを補助して、MIDCOMエージェントがペイロード翻訳を実行するかもしれない、MIDCOMエージェント
Srisuresh, et al. Informational [Page 9] RFC 3303 MIDCOM Architecture and Framework August 2002
Srisuresh、他 情報[9ページ]のRFC3303MIDCOMアーキテクチャとフレームワーク2002年8月
assisting a firewall middlebox might request the firewall to permit access to application specific, dynamically generated, session traffic.
ファイアウォールを補助して、middleboxは、特定の、そして、ダイナミックに生成しているセッショントラフィックをアプリケーションへのアクセスに可能にするようファイアウォールに要求するかもしれません。
4. MIDCOM Protocol
4. 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エージェントとmiddleboxの間のMIDCOMプロトコルで、MIDCOMエージェントをmiddleboxのサービスを呼び出して、middleboxがアプリケーションの特定の処理をMIDCOMエージェントへ代表として派遣するのを許容します。 プロトコルで、MIDCOMエージェントは、middleboxesに合図して、シームレスにそれら(すなわち、middleboxes)を通したダイナミックなポートベースのセッションを使用することで複雑なアプリケーションをさせるでしょう。
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).
エージェントとmiddleboxが同じフィジカル・デバイスであることができることに注意するのは重要です。 ベースの非IPを使用するだけであるなら輸送される彼らが明確なAPI/DLL (or)を使用することで彼らが伝えるかもしれない(or)を通信させるIPCなどのようにMIDCOMプロトコルメッセージ・フォーマットを使用することでコミュニケートするかもしれないそのような場合では、アプリケーション知性はmiddleboxサービスに完全に埋め込まれています(今日多くのステートフルインスペクションファイアウォールデバイスと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.
middleboxかMIDCOM PDPのどちらかとのMIDCOMエージェントの登録でセッションセットアップに先行しなければなりません。 MIDCOMエージェントアクセスと承認プロフィールはMIDCOM PDPに記載されたmiddlebox (or)であらかじめ設定されるかもしれません。 middleboxは、相談するために構成されます。 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セッションはパーティーのどちらかによって終えられるかもしれません。 また、(a) middleboxか使われなくなるようになるエージェントが引き起こされるかもしれない、特定のMIDCOMエージェントがもう権限を与えられないようにmiddleboxに通知する一層の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プロトコルデータは主にプロトコルがサポートするmiddleboxサービスで支配されます。 ファイアウォールとNAT middleboxサービスは本書では考えられます。 それにもかかわらず、MIDCOMフレームワークは、また、他のサービスの展開をサポートするのにおいて広げることができるように設計されています。
Srisuresh, et al. Informational [Page 10] RFC 3303 MIDCOM Architecture and Framework August 2002
Srisuresh、他 情報[10ページ]のRFC3303MIDCOMアーキテクチャとフレームワーク2002年8月
5.0. MIDCOM Agents
5.0. 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エージェントはmiddleboxへの外部のノードの上に物理的にあるかもしれない論理的な実体です、アプリケーション認識の組み合わせとmiddlebox機能に関する知識を持っていて。 MIDCOMエージェントは1middleboxesとコミュニケートするかもしれません。 逆もまた同様にエージェントを発見するmiddleboxesの問題はこのドキュメントの範囲の外のそうです。 ドキュメントの焦点はMIDCOMエージェントがmiddleboxとまだ工夫されていないことであるMIDCOMプロトコルを使用することでコミュニケートするフレームワークです。 明確に、焦点はまさしくIn-経路エージェントに制限されます。
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)で、彼らのセッションは分岐している経路を取るかもしれません。 それらのシナリオでは、In-経路MIDCOMエージェントは気付くとコントロール経路にいるものです。 多くの場合、middleboxはコントロール経路のアプリケーションのためにおそらく単独で独身のエージェントの支援を必要とするでしょう。 しかしながら、middleboxを横断するのがそうするかもしれないmiddlebox機能、または特定のアプリケーションが同じアプリケーションのために独身のMIDCOMエージェント以上の介入を必要とするのは、可能です、アプリケーションのそれぞれのサブセッションあたり1つ。
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.
アプリケーションProxiesとゲートウェイはIn-経路MIDCOMエージェントにとって、良い選択です、クライアントとサーバの間のアプリケーションの経路で定義上これらの実体がそうように。また、MIDCOMエージェント機能を接待することに加えて、経路のこれらのネイティブのアプリケーション特定の実体は局所的にアプリケーション特有の選択を実施するかもしれません、知られているウイルス、または欠いているユーザー認証に感染しているメッセージを下げるのなどように。 これらの実体はコントロールとデータセッションの両方を挿入できます。 例えば、FTPプロキシサーバはFTPコントロールとDataセッションを挿入します。
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のように。 注意、アプリケーションはいつもプロキシを横断するかもしれないというわけではありません、そして、いくつかのアプリケーションには、利用可能なプロキシサーバがないかもしれません。
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
SIPプロキシとH.323門番は、ファイアウォールとNATが機能であると実装するmiddleboxesを制御するためにホストMIDCOMエージェント機能に慣れるかもしれません。 完全に新しいエージェントを創造することと対照的に経路の実体を使用する利点は経路の実体にはアプリケーション知性が既にあるということです。 あなたは、MIDCOMプロトコルの使用が有能なMIDCOMエージェントであることを単に可能にする必要があるでしょう。 以下の図2がシナリオどこ経路MIDCOMを例証するか、エージェント
Srisuresh, et al. Informational [Page 11] RFC 3303 MIDCOM Architecture and Framework August 2002
Srisuresh、他 情報[11ページ]のRFC3303MIDCOMアーキテクチャとフレームワーク2002年8月
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.
middleboxに連結してください。 言おう、middleboxの上の信じられたMIDCOMエージェントとパケットフィルタ道具a'が'パケットフィルタリング方針をデフォルトで否定するとき、MIDCOM PDPは経路のプロキシをあらかじめ構成しました。 プロキシは、ファイアウォール機能を制御して、選択的にダイナミックに、ある数の声のストリームセッションを可能にするのに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は個人的なドメインの中で見せられます。 しかしながら、意図、それらが個人的な境界だけの中でそうであることを含意することになっていません。 また、プロキシはそのドメインに外部であることの形で住むかもしれません。 信頼がmiddleboxとの関係であったなら、唯一の要件がそこのそれです。
+-----------+
| 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
+-----------+ | MIDCOM| | PDP|~~~~~~~~~~~~~| +-----------+ \ \ +--------+ \ | 一口|___ \ ________| プロキシ| \Middlebox\/+--------+.. | +--------------------+ | : | MIDCOM| | | | RTSP+---------+ :..|........| MIDCOM| 方針| 一口| ____| RTSP|.....|........| プロトコル| 相互| | / | プロキシ|___ | | インタフェース| 表面| | | +---------+ \ \ |--------------------| | | \ \______| |__一口| | \________| |__RTSP| | ---| ファイアウォール|、-、-->-- +-----------+ /---| |、-、--<-- +-----------+| データ・ストリーム//+--------------------+ +-----------+|、|、-、-、-、-、-、-、-、-、--、>、-、-、--// | |終わりホスト|、|、-、-、-、-、-、-、-、-、-、--、<、-、-、-、-- . +-----------+ (RTP、RTSPデータなど) | . Withinのa個人的なドメインの外で| 個人的なドメイン
Legend: ---- Application data path datagrams
____ Application control path datagrams
.... Middlebox Communication Protocol (MIDCOM)
~~~~ MIDCOM PDP Interface
|
. private domain Boundary
|
伝説: ---- アプリケーションデータ経路データグラム____ アプリケーション制御経路データグラム… Middlebox通信プロトコル(MIDCOM)~~~~ MIDCOM PDPインタフェース| . 個人的なドメインBoundary|
Figure 2: In-Path MIDCOM Agents for middlebox Communication
図2: 経路のmiddlebox CommunicationのMIDCOMエージェント
Srisuresh, et al. Informational [Page 12] RFC 3303 MIDCOM Architecture and Framework August 2002
Srisuresh、他 情報[12ページ]のRFC3303MIDCOMアーキテクチャとフレームワーク2002年8月
5.1. End-hosts as In-Path MIDCOM agents
5.1. In-経路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エージェントの別の変化です。 Proxiesと異なって、End-ホストは、アプリケーションへのダイレクトパーティーであり、終わりから終わりへのアプリケーションそれにはあるすべての知性を持っています。 おそらく、終わりのホストはコントロールとアプリケーションのデータ経路の両方を終えます。 MIDCOMエージェントを接待して、他の実体と異なって、終わりホストは安全なデータグラムを処理できます。しかしながら、問題が1であるだろう、管理可能性--特定のアプリケーションを実行しながら、すべての終わりホストをアップグレードさせます。
6.0. MIDCOM PDP functions
6.0. MIDCOM PDP機能
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アーキテクチャの機能的な分解は、middleboxのために図1に表現されるようにサービスに食糧を供給しながら、MIDCOM PDPとして知られている論理的な実体の存在に承認を実行するのに原因となって関連していると仮定します。 MIDCOM PDPはmiddleboxの上、または、middleboxへの外部のノードの上に物理的にあるかもしれない論理的な実体です。 middleboxと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.
承認がmiddleboxのサービスを呼び出すように、エージェントはMIDCOM PDPに登録されます。 MIDCOM PDPはMIDCOM PDPサポートをそれぞれのmiddleboxesに接続するのに権限を与えられるエージェントのリストを維持します。 MIDCOM Frameworkの文脈では、MIDCOM PDPはそれが提供するサービスの実装にmiddleboxを助けません。
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は、middleboxに接続性を試みるエージェントのための承認を認可するか、または終えるために顧問の資格でmiddleboxに行動します。 MIDCOM PDPの主目的はエージェント承認情報を伝えることです、middleboxのセキュリティと保全が危険にさらされないのを確実にするために。 明確に、MIDCOM PDPはmiddleboxに接続して、セキュリティプロフィールを供給するのを試みる各エージェントに、信頼レベルを関連づけるはずです。 終わりホストがmiddleboxのエージェントであるときに、MIDCOM PDPはケースを扱うことができるべきです。
6.1. Authentication, Integrity and Confidentiality
6.1. 認証、保全、および秘密性
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
ホストの信憑性と個々のメッセージセキュリティは2つの異なったタイプのセキュリティ問題です。 ホスト認証は資格証明書がmiddleboxにそれ自体を認証するのがMIDCOMエージェントに必要であり、逆もまた同様ですと言及します。 認証が失敗すると、middleboxは認証に失敗したエージェントから受け取られたシグナリング要求を処理してはいけません。 両用認証はサポートされるべきです。 いくつかの場合、2ウェイ認証はしっかりリンクされるかもしれません。
Srisuresh, et al. Informational [Page 13] RFC 3303 MIDCOM Architecture and Framework August 2002
Srisuresh、他 情報[13ページ]のRFC3303MIDCOMアーキテクチャとフレームワーク2002年8月
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.
その後のトラフィックを保護するキーの設立。 両用認証が、合わせることの材料の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])はメッセージ再生からデータ発生源認証、データ保全、および保護を提供します。 再生からの超能力([IPSEC超能力])が、より少ない度合いへのデータ発生源認証を供給するIPsec(TCPかUDPになるようにMIDCOMがプロトコルを輸送するならIPsec AHが判明するのと同じ)、メッセージ秘密性、データ保全、および保護。 IPsecのベースのプロトコル以外に、また、他のセキュリティオプションがあります。 TLSのベースのトランスポート層セキュリティは1つのオプションです。 また、利用可能な多くの応用層セキュリティー対策があります。 ベースの簡単なSource-アドレスセキュリティは、最小量のフォームの保証であり、最も信じられた環境だけで当てにされるべきです。そこでは、それらのホストが偽造されないでしょう。
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メッセージセキュリティは既存の規格を使用するものとします。 セキュリティは、セキュリティオプションを使用しないセッションのときに影響を最小にするために指定されるものとします。 セキュリティは、導入するのを避けて、サービス不能攻撃の影響を最小にするように設計されるべきです。 いくつかのセキュリティー対策とアルゴリズムがかなりの処理かストレージを必要とします、その場合、また、セキュリティプロトコルはそのような処理で終点(すなわち、middleboxかエージェント)を圧倒する可能なフラッディング攻撃に対比して我が身をかばうべきです。 接続指向のプロトコル(TCPなどの)使用セキュリティー・サービスのために、セキュリティプロトコルは時期尚早な閉鎖かトランケーション攻撃を検出するべきです。
Srisuresh, et al. Informational [Page 14] RFC 3303 MIDCOM Architecture and Framework August 2002
Srisuresh、他 情報[14ページ]のRFC3303MIDCOMアーキテクチャとフレームワーク2002年8月
6.2. Registration and deregistration of MIDCOM agents
6.2. MIDCOMエージェントの登録と反登録
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エージェントがmiddleboxのサービスを呼び出すのを許容する前に、登録手続は行われなければなりません。 登録はMIDCOMセッションを確立するより異なったプロセスです。 前者は、middleboxかMIDCOM PDPと共にエージェントプロフィール情報に食糧を供給するのを必要とします。 しばしばエージェント登録はエージェント自身よりむしろオペレータによって実行された手動です。 MIDCOMセッションをセットアップすると、MIDCOM輸送セッションを確立して、エージェントとmiddleboxの間でセキュリティー証明書を交換するのは示されます。 輸送セッションはセッション設立に登録された情報を使用します。
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として機能するのに権限を与えられるセッションtuples)、実体を接待するエージェント(エージェントを接待する例えば、Proxy、ゲートウェイまたは終わりホスト)、エージェントアクセシビリティプロフィール(どんなホストレベル認証情報も含んでいる)、およびセキュリティが輪郭を描くエージェント承認方針(すなわち、middleboxとエージェントの間で交換されたメッセージのためのセキュリティ要件)を含んでいます。
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エージェントプロフィールはmiddleboxであらかじめ設定されるかもしれません。 それにその後であり、エージェントは、どんなデータ通信量の前にもMIDCOMセッションを開始するのを選ぶかもしれません。 例えば、middleboxサービスのためのMIDCOMエージェント承認方針は、フィルタに関連してエージェントを指定することによって、あらかじめ設定されるかもしれません。 ファイアウォールの場合では、例えば、ACL tupleは、任意のエージェント存在を反映するために変更されるかもしれません。 改訂された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 tupleに関する説明に役立つ実例であることに注意するべきです。 ACLの形式的記述はまだ工夫されていないことです。 また、エージェントアクセシビリティ情報は食糧を供給されるべきです。 MIDCOMエージェントに関しては、アクセシビリティ情報はIPアドレス、信頼レベル、ホスト認証パラメタ、および通報認証パラメタを含んでいます。 セッションがmiddleboxと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
上で説明されたテクニックがmiddleboxとのMIDCOMエージェントのプレ登録に必要です。 middleboxがMIDCOM PDPを通して登録されたエージェントを知っているなら、middleboxの食糧を供給することは変わりがないかもしれません。 どちらの場合ではも、MIDCOMエージェントはアプリケーションの始まりの前にセッションを開始するべきです。 アプリケーションが始まった後までエージェントセッションが遅らせられるなら
Srisuresh, et al. Informational [Page 15] RFC 3303 MIDCOM Architecture and Framework August 2002
Srisuresh、他 情報[15ページ]のRFC3303MIDCOMアーキテクチャとフレームワーク2002年8月
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.
エージェントは、データセッションを可能にするために制御ストリームを処理できないかもしれません。 middleboxが入って来るMIDCOMセッションに気付いて、middleboxがMIDCOMエージェントのどんな先のプロフィールも持っていないとき、middleboxはセッションのための信憑性、承認、および信頼ガイドラインのためにMIDCOM PDPに相談するでしょう。
7.0. MIDCOM Framework Illustration using an In-Path agent
7.0. In-経路エージェントを使用するMIDCOM Framework Illustration
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.
中では、以下では、私たちがSIPアプリケーション([SIP]を参照する)であると考える3が、MIDCOMプロトコルの操作を例証するために計算します。 明確に、アプリケーションは、個人的なドメインに外部であることの訪問者が呼び出しを開始すると仮定します。 middleboxが個人的なドメインの縁に位置すると思われます。 個人的なドメインの中の(SIP UserエージェントClient/サーバ)が受け止めることができるSIP電話は外部のSIP電話から呼びます。 訪問者はSIP Proxy、外国行きのプロキシとして個人的なドメインに外部であることの形で見つけられたノードを使用します。 どんな内部のプロキシも訪問される人のために思われません。 最後に、外部の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呼び出しセットアップ交換を呼んで、middleboxを横断していると思われます。 以下のアロウズ2、3、6、および7はSIPプロキシとmiddleboxの間にMIDCOMコミュニケーションを示します。 NaとNbは外部のネットワークでRTP/RTCPメディアトラフィック([RTP]を参照する)経路を表します。 Ncと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 |____________|
_________ --->| 一口| <、-、-、-、--\ / | プロキシ| \ | |_________| | 1| |^ ^| 4| | || || | |8 2||3 7||6 |5 ______________ | || || | _____________ | | <、-/|____|v___ \->|、|、| 外部| Na| | Nc| SIP電話| | SIP電話| >、-、-、-、-、-、--、>| Middlebox| >、-、-、-、-、--、>| 中| | | <、-、-、-、-、-、--、<|___________| <、-、-、-、-、--、<| Pvtドメイン| |____________| 第Nb|____________|
Figure 3: MIDCOM framework illustration with In-Path SIP Proxy
図3: In-経路SIP Proxyがある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アプリケーションに関して、私たちはmiddleboxが個人的なSIP電話にSIP呼び出しを受け入れるためにあらかじめ設定されるという仮定をします。 明確に、これが、ファイアウォールサービスを実装するmiddleboxが呼び出しをSIPに可能にするためにあらかじめ設定されるのを含意するだろう、(目的地
Srisuresh, et al. Informational [Page 16] RFC 3303 MIDCOM Architecture and Framework August 2002
Srisuresh、他 情報[16ページ]のRFC3303MIDCOMアーキテクチャとフレームワーク2002年8月
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かUDPポートナンバーが個人的な電話への5060に)セットしました。 同様に、NAPTがサービスであると実装するmiddleboxは、特定の個人的なSIP電話に向け直されるという入って来るSIP要求を可能にするために固まるポートを提供するためにあらかじめ構成されたでしょう。 すなわち、外部の訪問者からのINVITEはプライベートIPアドレスに作られているのではなく、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プロトコルアーキテクチャを使用するとき、middleboxを通して単に、RTP/RTCPメディアストリーム([RTP]を参照する)を可能にすることです。 SIPセッションは2つのRTP/RTCPメディアストリームを通常確立します--訪問者から訪問される人への訪問される人から訪問者と別のものまでの1。 これらのメディアセッションは、基づくUDPであり、ダイナミックなポートを使用するでしょう。 メディアストリームに使用されるダイナミックなポートはSIPペイロードメッセージのSDP部([SDP]を参照する)で指定されます。 (b) PORT結合を作成してください、そして、MIDCOMエージェントが、ファイアウォールサービスを実装するmiddleboxで(a) 開いているピンホール(すなわち、RTP/RTCPセッションtuplesを可能にする)にSDP部を分析して、MIDCOMプロトコルを使用するだろうか、または適切にSDP内容を変更して、NATがサービスであると実装するmiddleboxを通してRTP/RTCPストリームを可能にしてください。 MIDCOMプロトコルは、スケジュールの下で説明された操作をサポートするために十分豊かであって、表現しているべきです。 例は、middlebox方針を保つためにエージェントによって維持されたタイマがタイミングからの(s)を除外するのを示しません。
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エージェントとmiddleboxの間のMIDCOMエージェントRegistrationと接続性はmiddleboxがメディアストリームを通すのを可能にするのに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電話アプリケーション経路に伴われる状態で蒸散する操作の典型的なスケジュール系列を例証します。 各小区分は特定のmiddleboxサービスの具体化にささげられます--NAPTとファイアウォールの両方のNAPT([NAT-TERM]、[NAT TRAD]を参照する)、ファイアウォール、および組み合わせは考えられます。
7.1. Timeline flow - Middlebox implementing firewall service
7.1. スケジュール流動--ファイアウォールサービスを実装するMiddlebox
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.
以下の例では、私たちはファイアウォールがサービスであると実装するmiddleboxを仮定するつもりです。 私たちは、個人的な電話への要求(目的地TCPかUDPポートナンバーが5060にセットした)をSIPに可能にするためにmiddleboxがあらかじめ構成されているとさらに思います。 以下のスケジュールはmiddleboxを通してRTP/RTCPメディアストリームを可能にするためにMIDCOMエージェントによって実行された操作を例証します。
Srisuresh, et al. Informational [Page 17] RFC 3303 MIDCOM Architecture and Framework August 2002
Srisuresh、他 情報[17ページ]のRFC3303MIDCOMアーキテクチャとフレームワーク2002年8月
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流れを可能にするようmiddleboxに要求することに注意するでしょう。 これはセッション記述と共にINVITEを送るとき、起呼側がSIPにメディアを受け取る準備ができているに違いないからです。 被呼者(個人的な電話)がこれを仮定して、200OK応答を送る前に「早めのメディア」を送るなら、ファイアウォールはエージェントからこの初期の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==========================>|
SIP電話SIP Proxy Middlebox SIP電話(外部の)(MIDCOMエージェント)(FIREWALL(個人的な)| | サービス)| | | | | |----招待------>|、|、|、|、|、|、| | <、-、--100Trying----| | | | | | | | 2が終わらせる終わりを特定してください。| | | priからExtのためのパラメタ(Callerのもの| | | SDPからの)| | | RTP&RTCPセッション。 | | | (RTP1、RTCP1) | | | | | | | |+ 許可証RTP1、RTCP1+>|、|、| |<+RTP1、RTCP1は+ + + +を承認しました。| | | | | | | |--------招待---------------------->|、|、|、|、|、| | <、-、-、-、--180 鳴ること--------------------| | <--180Ringing----| | | | | <、-、-、-、-、-、--200 OK-----------------------| | | | | | 2が終わらせる終わりを特定してください。| | | ExtからPriのためのパラメタ(訪問される人のもの| | | SDPからの)| | | RTPとRTCPセッション。 | | | (RTP2、RTCP2) | | | | | | | |+ 許可証RTP2、RTCP2+>|、|、| |<+RTP2、RTCP2は+ + + +を承認しました。| | | | | | | <、-、--200 OK------| | | |-------ACK------>|、|、|、| |-----------ACK---------------------->|、|、|、|、| |<==========RTP/RTCP==========================>|
Srisuresh, et al. Informational [Page 18] RFC 3303 MIDCOM Architecture and Framework August 2002
Srisuresh、他 情報[18ページ]のRFC3303MIDCOMアーキテクチャとフレームワーク2002年8月
| | | |
|-------BYE------>| | |
| |--------------------------BYE------->|
| | | |
| |<----------200 OK--------------------|
| | | |
| |++Cancel permits to | |
| | RTP1, RTCP1, RTP2, | |
| | and RTCP2 +++++++++>| |
| |<+RTP1, RTP2, RTCP1 & | |
| | RTCP2 cancelled ++++| |
| | | |
|<---200 OK-------| | |
| | | |
| | | | |-------さようなら------>|、|、|、| |--------------------------さようなら------->|、|、|、|、|、| | <、-、-、-、-、-、-、-、-、--200 OK--------------------| | | | | | |+ キャンセルが可能にする+| | | | RTP1、RTCP1、RTP2| | | | そして、RTCP2+++++++++>|、|、| |<+RTP1、RTP2、RTCP1| | | | RTCP2は+ + + +を取り消しました。| | | | | | | <、-、--200 OK-------| | | | | | |
Legend: ++++ MIDCOM control traffic
---- SIP control traffic
==== RTP/RTCP media traffic
伝説: + + + + MIDCOMコントロール交通---- SIPコントロール交通==== RTP/RTCPメディア交通
7.2. Timeline flow - Middlebox implementing NAPT service
7.2. スケジュール流動--NAPTサービスを実行するMiddlebox
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サービスを実行するmiddleboxを仮定するつもりです。 私たちは、特定の個人的なSIP電話アプリケーションにSIP呼び出しを向け直すために、middleboxがあらかじめ構成されているという仮定をします。 すなわち、外部の訪問者からのINVITEはプライベートIPアドレスに作られているのではなく、NAPT外部アドレスに作られています。 外部の電話のIPアドレスはEaです、そして、NAPT middleboxの外部のAddressはマです、そして、言わせてください、そして、内部のSIP電話のプライベート・アドレスはペンシルベニア州です。 個人的なSIP電話へのSIP呼び出しはTCP/UDPセッションとして到着するでしょう、アドレスとポートがそれぞれマと5060に設定する目的地で。 middleboxは内部のSIP電話にこれらのデータグラムを向け直すでしょう。 middleboxを通した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
前の例(セクション7.1)のように、訪問者(外部の)からのINVITEがSDPペイロードを含んでいると思われます。 あなたは、MIDCOMエージェントが、INVITEが個人的なSIP電話(セクション7.1で説明される同じ理由による)にリレーされる前の外部に個人的なRTP/RTCP流れのためのNATセッション記述子を作成するようmiddleboxに要求することに注意するでしょう。 200OK応答を送る前に被呼者(個人的な電話)が「早めのメディア」を送るなら、NAPT middleboxはエージェントから初期のMIDCOMシグナリングなしでこれらのパケットを妨げてしまうでしょう。 また、200OKがプロキシによって個人的な電話から受け取られた後にエージェントがNATセッション外部から兵卒への記述子にRTP2を割り当てて、流れをRTCP2に割り当てるようmiddleboxに要求することに注意してください、RTP2とRTCP2のためにマで割り当てられたポートが隣接であるように。 RTCPの流れは起こりません。
Srisuresh, et al. Informational [Page 19] RFC 3303 MIDCOM Architecture and Framework August 2002
Srisuresh、他 情報[19ページ]のRFC3303MIDCOM構造と枠組みの2002年8月
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.
非隣接のポートで。 最後に、あなたは、それぞれのメディアの流れ(RTP1、RTCP1、RTP2、およびRTCP2)が独立していますが、それらがただ一つのSIPコントロールセッションにすべて結ばれることに注意するでしょう、それらのNATセッション記述子が作成されていた間。 エージェント問題aがSIPセッションのためのセッションバンドル命令を終えるとき、最終的に、middleboxがすべての関連メディアの流れのセッションautomagicallyを削除すると思われます。
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--------|------------->|
| | | |
SIP電話SIP Proxy Middlebox SIP電話(外部の)(MIDCOMエージェント)(NAPTの(個人的)のIP Addr:Ea|サービス)IP addr: Pa| | IP addr: マ| | | | | |----招待------>|、|、|、|、|、|、| | <、-、--100Trying----| | | | | | | | |+ + 質問ポートひも| | | | + + (マ、5060)+のために>|、|、| |ポート<+BIND回答| | | | + + + (マ、5060)+のために| | | | | | | |+ + 質問NATセッション| | | | 記述子| | | | EaからPa SIPへの流動+>|、|、| |Eaから<+Pa SIPへの流動| | | | セッション記述子+| | | | | | | 内部を決定してください。| | | IPアドレス(Pa)| | | 訪問される人について。 | | | | | | | UDPポートナンバーを特定してください。| | | Ea(Eport1、Eport1+1)に関して| | | priからext RTPとRTCPのために| | | セッション(RTP1、RTCP1)| | | | | | | |+ +はNATセッションを作成します。| | | | 記述子| | | | RTP1、RTCP1。 セットします。| | | | セッションの親代わりとなります。| | | | SIP-ctrlセッション++>|、|、| |<+RTP1、RTCP1セッション| | | | 記述子は+を作成しました。| | | | | | | | |..向け直される。| | |--------招待--------|、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、|
Srisuresh, et al. Informational [Page 20] RFC 3303 MIDCOM Architecture and Framework August 2002
Srisuresh、他 情報[20ページ]のRFC3303MIDCOM構造と枠組みの2002年8月
| |<-----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--------------------|
| | <、-、-、-、--180Ringing---------------------| | | | | | <--180Ringing----| | | | | <、-、-、-、-、-、--200 OK-----------------------| | | | | | UDPポートナンバーを特定してください。| | | Pa(Pport2、Pport2+1)に関して| | | extからpri RTPとRTCPのために| | | セッション(RTP2、RTCP2)| | | | | | | |+が連続しているのに作成する+| | | | BINDsをマに移植してください。| | | | (Pa、Pport2)のために| | | | (Pa、Pport2+1) ++++>|、|、| |<+ポートBINDsは+ +を作成しました。| | | | | | | |+ +はNATセッションを作成します。| | | | 記述子| | | | RTP2、RTCP2。 セットします。| | | | セッションの親代わりとなります。| | | | SIP-ctrlセッション++>|、|、| |<+RTP2、RTCP2セッション| | | | 記述子は+を作成しました。| | | | | | | SDPを変更してください。| | | 「200OK」のパラメタ| | | NAPTポートひもで| | | マの上のRTP2ポートに。 | | | | | | | <、-、--200 OK------| | | | | | | |-------ACK------>|、|、|、|、|、|、|、| IPアドレスを変更してください。| | | 適切にSIPで| | | を通してヘッダー、(例えば、To、|、|、|、接触分野)| | | | |..向け直される。| | |-----------ACK--------|、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、|、|、|、|、| |<==========RTP/RTCP============|=============>|、|、|、|、| |-------さようなら------>|、|、|、|、|、|、|、| |----------------------|-----さようなら----->|、|、|、|、|、| | <、-、-、-、-、-、-、-、-、--200 OK--------------------|
Srisuresh, et al. Informational [Page 21] RFC 3303 MIDCOM Architecture and Framework August 2002
Srisuresh、他 情報[21ページ]のRFC3303MIDCOM構造と枠組みの2002年8月
| | | |
| |+++Terminate the SIP | |
| | Session bundle +++>| |
| |<++SIP Session bundle | |
| | terminated ++++++++| |
| | | |
|<---200 OK-------| | |
| | | |
| | | | | |+ + +は一口を終えます。| | | | セッションバンドル+++>|、|、| |<++SIP Sessionバンドル| | | | 終えられた++++++++| | | | | | | <、-、--200 OK-------| | | | | | |
Legend: ++++ MIDCOM control traffic
---- SIP control traffic
==== RTP/RTCP media traffic
伝説: + + + + MIDCOMコントロール交通---- SIPコントロール交通==== RTP/RTCPメディア交通
7.3. Timeline flow - Middlebox implementing NAPT and firewall
7.3. スケジュール流動--NAPTとファイアウォールを実行するMiddlebox
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.
以下の例では、私たちは、ファイアウォールの組み合わせを実行するmiddleboxとstateful NAPTがサービスであると思うつもりです。 私たちはNAPT機能がIPを翻訳するために構成されるという仮定とTCPを個人的なSIP電話への初期のSIPセッションのヘッダーにします、そして、ファイアウォール機能は、初期の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.
以下のタイムラインでは、ファイアウォール記述がワイヤのパケット分野に基づいていることに(例えば、middleboxの外部のインタフェースで見られるように)注意されるかもしれません。 正しい個々にサービスの振舞いを確実にするために、あなたは、NATの特定のMIDCOM操作がMIDCOMエージェントにおけるファイアウォールの特定の操作に先行するのに気付くでしょう。 これはMIDCOMエージェントが個人的な一口電話から「200OK」を処理する時の下のタイムラインでめぼしいです。 MIDCOMエージェントは、初めは、メディアの流れのためのポート-BINDとセッション記述子を両方の方向にセットアップするようmiddleboxにおけるNATサービスに要求します。 それにその後です、MIDCOMエージェントは外部のインタフェースによって見られるようにメディアの流れのためのセッションパラメタ(すなわち、ダイナミックなUDPポート)を決心して、それらのセッションの通るのを許すようmiddleboxにおけるファイアウォールサービスに要求します。
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) +++>| |
SIP電話SIP Proxy Middlebox SIP電話(外部の)(MIDCOMエージェント)(NAPTと(個人的な)IP Addr:Ea|ファイアウォールIP addr: Pa| | サービス)| | | IP addr: マ| | | | | |----招待------>|、|、|、|、|、|、| | <、-、--100Trying----| | | | | | | | |+ + 質問ポートひも| | | | + + (マ、5060)+のために>|、|
Srisuresh, et al. Informational [Page 22] RFC 3303 MIDCOM Architecture and Framework August 2002
Srisuresh、他 情報[22ページ]のRFC3303MIDCOM構造と枠組みの2002年8月
| |<+ 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) | |
| |ポート<+BIND回答| | | | + + + (マ、5060)+のために| | | | | | | |+ + 質問NATセッション| | | | 記述子| | | | EaからPa SIPへの流動+>|、|、| |Eaから<+Pa SIPへの流動| | | | セッション記述子+| | | | | | | 内部を決定してください。| | | IPアドレス(Pa)| | | 訪問される人について。 | | | | | | | UDPポートナンバーを特定してください。| | | Ea(Eport1、Eport1+1)に関して| | | priからext RTPとRTCPのために| | | セッション(RTP1、RTCP1)| | | | | | | |+ +はNATセッションを作成します。| | | | 記述子| | | | RTP1、RTCP1。 セット| | | | セッションの親代わりとなります。| | | | SIP流れ++を示してください。>|、|、| |<+RTP1、RTCP1セッション| | | | 記述子は+を作成しました。| | | | | | | |+ + 許可証RTP1&RTCP1| | | | セッションExternal| | | | すなわち、middlebox| | | | Eaへのマ: Eport1| | | | Eaへのマ: Eport1+1| | | | セッション++++++++++>|、|、| |Eaへの<+マ: Eport1| | | | Eaへのマ: Eport1+1| | | | セッションは+ + + + + +を承認しました。| | | | | | | | |..向け直される。| | |--------招待--------|、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、|、| | <、-、-、-、--180Ringing---------------------| | | | | | <--180Ringing----| | | | | <、-、-、-、-、-、--200 OK-----------------------| | | | | | UDPポートナンバーを特定してください。| | | Pa(Pport2、Pport2+1)に関して| | | extからpri RTPとRTCPのために| | | セッション(RTP2、RTCP2)| |
Srisuresh, et al. Informational [Page 23] RFC 3303 MIDCOM Architecture and Framework August 2002
Srisuresh、他 情報[23ページ]のRFC3303MIDCOM構造と枠組みの2002年8月
| | | |
| |++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 | |
| | | | | |+が連続しているのに作成する+| | | | BINDsをマに移植してください。| | | | (Pa、Pport2)のために| | | | (Pa、Pport2+1) ++++>|、|、| |BINDsが作成した<+ポート| | | | + + + + + + + + + (| | | | Mport2、Mport2+1)+としてのマに関して| | | | | | | |+ +はNATセッションを作成します。| | | | 記述子| | | | RTP2、RTCP2。 セット| | | | セッションの親代わりとなります。| | | | SIP流れ++を示してください。>|、|、| |<+RTP2、RTCP2セッション| | | | 記述子は+を作成しました。| | | | | | | SDPを変更してください。| | | 「200OK」のパラメタ| | | NAPTポートひもで| | | マの上のRTP2ポートに。 | | | | | | | |+ + 許可証RTP2&RTCP2| | | | セッションExternal| | | | すなわち、middlebox| | | | マへのEa: Mport2| | | | マへのEa: Mport2+1| | | | セッション++++++++++>|、|、| |マへの<+Ea: Mport2| | | | マへのEa: Mport2| | | | セッションは+ + + + + +を承認しました。| | | | | | | <、-、--200 OK------| | | | | | | |-------ACK------>|、|、|、|、| |..向け直される。| | |-----------ACK--------|、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、|、|、|、|、| |<==========RTP/RTCP============|=============>|、|、|、|、| |-------さようなら------>|、|、|、|、|、|、|、| |----------------------|-----さようなら----->|、|、|、|、|、| | <、-、-、-、-、-、-、-、-、--200 OK--------------------| | | | | | |+ + +は一口を終えます。| |
Srisuresh, et al. Informational [Page 24] RFC 3303 MIDCOM Architecture and Framework August 2002
Srisuresh、他 情報[24ページ]のRFC3303MIDCOM構造と枠組みの2002年8月
| | 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-------| | |
| | | |
| | セッションバンドル+++>|、|、| |<++SIP Sessionバンドル| | | | 終えられた++++++++| | | | | | | |+ キャンセルが可能にする+| | | | セッションExternal| | | | すなわち、middlebox| | | | Eaへのマ: Eport1| | | | Eaへのマ: Eport1+1| | | | マへのEa: Mport2| | | | マへのEa: Mport2+1| | | | セッション++++++++++>|、|、| |+が許可証を取り外した<。| | | | セッションは+ + + +を記載しました。| | | | | | | <、-、--200 OK-------| | | | | | |
Legend: ++++ MIDCOM control traffic
---- SIP control traffic
==== RTP/RTCP media traffic
伝説: + + + + MIDCOMコントロール交通---- SIPコントロール交通==== RTP/RTCPメディア交通
8.0. Operational considerations
8.0. 操作上の問題
8.1. Multiple MIDCOM sessions between agents and middlebox
8.1. エージェントとmiddleboxとの複数のMIDCOMセッション
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.
インタフェースのちょうど1つのmiddlebox機能とカップルだけを実行する簡単な装置であるとmiddleboxを思うことができません。 Middleboxesは同じ機能のための異なったセットの機能と様々な食糧を供給すると共にインタフェースの向こう側にしばしば複数の中間的機能を同じ装置に結合して、同じ装置の支給の個々のインタフェースに能力を持っています。
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エージェントは、middleboxでただ一つのMIDCOMセッションを過して、同じmiddleboxにおける異なったサービスに連結するのにmiddleboxでMIDCOMインタフェースを使用できるべきです。
8.2. Asynchronous notification to MIDCOM agents
8.2. 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エージェントへのmiddleboxによる非同期な通知はSession創造、Session終了、MIDCOMプロトコルの故障、middlebox機能の故障またはいかなる他の重大な行事などの出来事も役に立つ場合があります。 また、独自に、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.
また、さらに、様々なフォームに関する統計アップデートなどのデータの周期的な通知はあるタイプのエージェントにとって、有益な役に立つ機能でしょう。
Srisuresh, et al. Informational [Page 25] RFC 3303 MIDCOM Architecture and Framework August 2002
Srisuresh、他 情報[25ページ]のRFC3303MIDCOM構造と枠組みの2002年8月
8.3. Timers on middlebox considered useful
8.3. 役に立つと考えられたmiddleboxの上のタイマ
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プロトコルをサポートするとき、middleboxはダイナミックなリソースを割り当てなければなりません、政策ルールで指定されるように、エージェントからの要求に関して。 アプリケーションセッションが終わるか、またはMIDCOMエージェントが、リソースを発表するようmiddleboxに要求するとき、ダイナミックに割り当てられたリソースの明白なリリースは起こります。
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.
しかしながら、middleboxはダイナミックに割り当てられたリソースを回復するはずであることができます、配分に責任があるエージェントが生きないときさえ。 交際して、これらのダイナミックなリソースと生涯を追跡するのにタイマを使用するための寿命はこれを達成する早道であるかもしれません。
8.4. Middleboxes supporting multiple services
8.4. 複数のサービスを支持するMiddleboxes
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.
middleboxは同じ状態で、さまざまなサービス(例えば、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とファイアウォールサービスを実行するmiddleboxの場合では、インタフェースにおけるNAT操作が出口でファイアウォールに先行して、イングレスでファイアウォールに従うと述べるのは安全です。 さらに、ファイアウォールによって使用されるファイアウォールアクセスコントロールリストによってセッションパラメタに基礎づけられると思われます、ファイアウォールサービスを支持するインタフェースで見られるように。
8.5. Signaling and Data traffic
8.5. シグナリングとData交通
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構造が記述するアプリケーションのクラスはそれが組み合わせを持っているアプリケーション、1以上、シグナリング、およびデータ通信量およそセッションで集中します。 シグナリングは、ひたむきなスタンドアロンのセッションを使用して、バンドの外でするかもしれないか、されたコネバンドであるかもしれません、データセッション以内に。 また、交互に、スタンドアロンのものと同様にバンドのセッションの組み合わせとしてシグナリングをするかもしれません。
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)をさせるためにmiddleboxを管理して、満足しているSIPペイロードを調べるか、または変更するのに必要であるかもしれません。 MIDCOMエージェントは、データ通信量を干渉するのに必要ではありません。
Srisuresh, et al. Informational [Page 26] RFC 3303 MIDCOM Architecture and Framework August 2002
Srisuresh、他 情報[26ページ]のRFC3303MIDCOM構造と枠組みの2002年8月
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.
HTTPなどのアプリケーションのための同じデータ・ストリームの中のバンドの埋め込まれたアプリケーション、オラクルの取引(神託SQL+、MS ODBC、Peoplesoftを埋め込む)太陽-RPC(さまざまなNFSアプリケーションを埋め込む)などをシグナリングと文脈の特定のHeader情報に送ります。
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は、シグナリングをいいえと静的な方針によるトラフィック横断middleboxes、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はmiddleboxを横断して、また、メディアデータのためのオープンLogical Channel情報を運びます。 それで、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エージェントがシグナリングストリームを解釈して、middleboxをプログラムするのを持っているのは、とぎれないことを通したデータ通信量をさせるために望ましいです(それはデータ・ストリームを通過します)。
9. Applicability Statement
9. 適用性証明
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.
Middleboxesは多くのtopologiesに配置されるかもしれません。 しかしながら、本書では概説されたシグナリングフレームワークは個人的なドメインの縁のDMZ(反-Militarized Zone)に位置しているそれらのmiddleboxesだけに制限されるかもしれません、インターネットに接続して。 明確に、仮定はあなたがアプリケーションルートに沿って単一のmiddlebox(実行しているNATかファイアウォール)を持っているということです。 このドキュメントの範囲の外にアプリケーションルートに沿ったmiddleboxの発見があります。 部の間に同じドメイン以内かサービスプロバイダーのドメインなどの中においてmiddleboxesを位置させているのは想像できます。 しかしながら、それぞれの個々のシナリオを批評して、ケースバイケースで適用性を決定するために注意しなければなりません。
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
また、適用性は以下の通り例証されるかもしれません。 Voice過剰IPや、ピアツーピアアプリケーションなどのナップスターやNetmeetingなどのリアルタイムでストリーミングの応用は、彼らのメディアストリームを個人的なドメインの中でホストに届かせるようにファイアウォールとNAT middleboxesを管理するのを必要とします。 要件がフォームにあります。
Srisuresh, et al. Informational [Page 27] RFC 3303 MIDCOM Architecture and Framework August 2002
Srisuresh、他 情報[27ページ]のRFC3303MIDCOMアーキテクチャとフレームワーク2002年8月
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.
ファイアウォールを通してTCP/UDPセッション(それのパラメタがダイナミックに決定するポート)を可能にするか、またはNATデバイスで許可証セッションまでアドレス/ポートひもをポートに保有するために「ピンホール」を設立します。 これらの必要条件は現代middleboxesまでにadhocメソッドを使用することで満たされます、ダイナミックなセッションパラメタを特定するためにmiddleboxの中でアプリケーション知性を埋め込んで、内部的に適宜middleboxを管理するのなどように。 MIDCOMアーキテクチャの目的はこの機能性を運動させる統一されて、標準の方法を作成することです、現在臨時のファッションで存在して、いくらかのmiddleboxesで。
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アーキテクチャを採用することによって、middleboxesはそれらがこれまでのところサポートすることができなかったより新しいアプリケーションをサポートすることができるでしょう。 MIDCOMアーキテクチャがそうしない、必須である、middleboxでサポートされて、中ではなく、とにかく、基本的なサービスの特性を変えてください。
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.
通常、組織はドメイン縁のDeによって軍国化されたZone(DMZ)の使用でそれらの企業の諸資源(終わりホストなどの)の大部分を目に見えることから外部のネットワークまで保護します。 外界はこれらのホストの一部だけがアクセスできます。 残っているホストと彼らの名前は個人的なドメインにユニークです。 外界に目に見えるホストと彼らの名前をネットワーク・アドレスに写像する正式のネームサーバはファイアウォールのDMZ(反-Militarized Zone)の中でしばしば構成されます。 DMZの中のホストとmiddleboxesは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がある個人的なドメインの構成が縁で例証します。 実際の構成は異なるかもしれません。 内部のホストはドメインの中で単にユーザによってアクセスされます。 Middleboxes、DMZに位置して、エージェント内部からアクセスされるかもしれないか、またはドメインは外部がアクセスされます。
Srisuresh, et al. Informational [Page 28] RFC 3303 MIDCOM Architecture and Framework August 2002
Srisuresh、他 情報[28ページ]のRFC3303MIDCOMアーキテクチャとフレームワーク2002年8月
\ | /
+-----------------------+
|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
\ | / +-----------------------+ |サービスプロバイダールータ| +-----------------------+ WAN| Aを引き抜いてください… …|\|.... | +---------------+ | NAT middlebox| +---------------+ | | 非武装地帯--ネットワーク------------------------------------------------------------ | | | | | +--+ +--+ +--+ +--+ +-----------+ |__| |__| |__| |__| | ファイアウォール| /____\ /____\ /____\ /____\ | middlebox| 非武装地帯-Host1非武装地帯-Host2… 非武装地帯ウェブを+と非武装地帯で命名してください。-----------+ サーバサーバなど | | 内部のHosts(個人的なドメインの中の)| ------------------------------------------------------------ | | | | +--+ +--+ +--+ +--+ |__| |__| |__| |__| /____\ /____\ /____\ /____\Int-Host1 Int-Host2… Int-Hostn Int-ネームサーバ
Figure 4: DMZ network configuration of a private domain.
図4: DMZは個人的なドメインの構成をネットワークでつなぎます。
10. Acknowledgements
10. 承認
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、Joon Maeng、ジョン・ピーターソン、マイク・フィスク、マットHoldrege、メリンダShore、ポールSijben、フィリップMart、スコットBrim、およびリチャードSwaleに感謝したがっています。 middleboxを通してSIPアプリケーションフローチャートからメール議論をケースを使用しているシナリオに始めて、作者はキックにエリオットリアから特別な感謝を借りています。 ボブ・ペンフィールドのおかげで非常に、MIDCOM仕事におけるセドリックAoun、クリストファー・マーチン、エリック・フライシュマン、ジョージMichaelson、Wanqunバオ、および他のものは、さまざまな話題の彼らの非常に詳細なフィードバックと議論に明快を加えるために分類します。 最も最少でないのにもかかわらず、最後に、作者は彼らの助けを求めてフレームワークドキュメントの中に用語定義と埋め込まれた要件について議論するのにマーク・ダフィー、スコットBrim、メリンダShore、および他のものから多くの感謝を借りています。
Srisuresh, et al. Informational [Page 29] RFC 3303 MIDCOM Architecture and Framework August 2002
Srisuresh、他 情報[29ページ]のRFC3303MIDCOMアーキテクチャとフレームワーク2002年8月
11. Security Considerations
11. セキュリティ問題
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.
以下で議論しているのは、middleboxにアクセスすることにおいてセキュリティ問題です。 MIDCOMプロトコルサポートがなければ、middlebox操作の前提は、データが明確にあるのを基本的に必要とします、middleboxがパケットのヘッダーとペイロードを点検する、そして/または、変更する能力を必要とするとき。 これはいくつかの環境における機密保持の要求事項に感染します。 さらに、いくつかの場合、NATで輸送ヘッダーをアップデートして、アプリケーションペイロードデータを書き直すのは、いくつかのデータ・ストリームの保全保護の使用がNAT middleboxesを横断するのを防ぎます。 明確に、これは信頼されていない輸送ドメインのアプリケーションへの重要な軍事的脅威を引き起こすことができます。
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プロトコルフレームワークはmiddleboxが輸送ペイロードを点検するか、または操作する必要性を取り除きます。 これで、アプリケーションは信じられたMIDCOMの援助がある終わりから終わりへのエージェントをよりよく自分たちで保護できます。 エージェントが終わりホストの上の居住者であるときに、これは特にそうです。 エージェントには終わりから終わりへの暗号化されていた状態で解釈する終わりホストと同じ能力があって、保全がデータを保護したとき、middleboxを通過するのは暗号化できます、そして、保全は保護されました。 MIDCOMエージェントは、データを解釈して、開いている穴について単にmiddleboxに通知して、まだNATテーブル項目をインストールできるでしょうなど。 しかしながら、middleboxがこの場合まだIPと輸送ヘッダーを変更しているのでNATの問題がIPsecを壊していてMIDCOMフレームワークが助けないことに注意してください。
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エージェントとmiddleboxの間のセキュリティに、多くのコンポーネントがあります。 承認、認証、保全、および秘密性。 特定代理人が1つ以上のアプリケーションを求める要求でmiddleboxに合図するのに権限を与えられるかどうか承認は示します、ある方針プロフィールを固く守って。 承認プロセスに失敗すると、リソース窃盗試みか失敗が管理の、そして/または、資格証明の欠乏のため示されるかもしれません。 どちらの場合ではも、middleboxが1によって構成されるなら、middleboxはそのような試みを監査するか、または登録して、必要な動作のために指定されたMIDCOM PDPに相談する適切な対策を実施するはずです。 あるいはまた、middleboxは、必要な資格証明書をうながすためにデフォルトサービスが、MIDCOMエージェントがそうしない方針を否定する再ソートするかもしれません。 セクション6は政策決定から見てMIDCOM PDP相互作用にmiddleboxについて論じます。
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
認証は創始者から受け取られたすべてのデータグラムのために創始者のアイデンティティを確認するのを示します。 エージェントとmiddleboxの間のMIDCOMメッセージの認証のための強い資格証明書の不足は真剣にmiddleboxによってレンダリングされた基本的なサービスを危険にさらすことができます。 エージェントを認証しない結果は攻撃者がファイアウォールの「正統」のエージェントと開いている穴のアイデンティティを偽造することができたということでしょう。 別のものはそうでしょう。
Srisuresh, et al. Informational [Page 30] RFC 3303 MIDCOM Architecture and Framework August 2002
Srisuresh、他 情報[30ページ]のRFC3303MIDCOMアーキテクチャとフレームワーク2002年8月
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.
そうでなければ、サービス不能攻撃を作成するmiddleboxで閉鎖で状態を操るかもしれないのがNATテーブルにピンホールか充填を必要としました。 エージェントにmiddleboxを認証しない結果は攻撃者がデータを攻撃者に紛らす方法でmiddleboxのふりをして、NAT要求に応じることができるだろうということです。 必要であるか有効な資格証明書を提出しないと、一度挑戦された反射攻撃は示されるかもしれません、その場合、適切な動きが、そのような失敗を反映するために指定されたMIDCOM PDPに監査するか、登録するか、または相談などなどのmiddleboxによって必要とされます。 反射攻撃に対してmiddleboxを保護しない結果は特定のピンホールが攻撃者によって自由自在に再開するか、または閉じられるかもしれないということでしょう、その結果、終わりのホストに保証のないデータを砲撃するか、またはサービスの否定を引き起こして。
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メッセージが偶然か陰湿に変更もされませんし、無効にされてもいないのを保証するのに必要です。 信頼されていない環境における、資料不足保全実施の結果は詐欺師がエージェントが可能にするのを試みているアプリケーションのためにエージェントによって送られたメッセージを変更して、middleboxを止めるか、またはサービスの否定を引き起こすということであるかもしれません。
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メッセージの秘密性はシグナリングデータが確実に権限のある機関だけにアクセス可能になるようにします。 middleboxエージェントが信頼されていない環境で配布されるとき、秘密性の不足で、侵入者は、トラフィックフロー分析を実行して、middleboxについて詮索するでしょう。 侵入者は、彼が他のセッションのときに暴露したmiddleboxリソースをより少ない安全なMIDCOMセッションの肉を食って、無効にするか、または感染することができました。 言うまでもなく、最も安全でないMIDCOMセッションは、achillesかかとになって、middleboxはセキュリティー攻撃に被害を受け易くなるでしょう。
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.
最後に、アプリケーションへのmiddleboxに関するリソースが複数の外部物質によって制御されるときmiddleboxを横断するセキュリティの脆弱性があることができます。 middleboxサービスは、複数のエージェントからの指示が異なったmiddlebox機能に関連づけた闘争のため混乱させられますが、同じアプリケーションセッションに適用されるかもしれません。 1つの機能のためのエージェントが突然にリソースをまたがないのを保証するために異なった機能に影響を与えながら、プロトコルデザインで注意しなければなりません。 独身のMIDCOMエージェントはアプリケーションのためのすべてのmiddleboxサービスをサポートするのに責任があるとき、交互に、そのような顕現の厳しさを少なくすることができました、middleboxリソースを管理することにおける減少している複雑さと同期取り組みのため。
Srisuresh, et al. Informational [Page 31] RFC 3303 MIDCOM Architecture and Framework August 2002
Srisuresh、他 情報[31ページ]のRFC3303MIDCOMアーキテクチャとフレームワーク2002年8月
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.
[一口] ローゼンバーグ、J.、Shulzrinne(H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパーク、R.ハンドレー、M.、学生、E.)は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[SDP] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[SDP] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、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.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、RFC1889、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)」、1998年4月のRFC2326。
[FTP] Postel, J. and J. Reynolds, "File Transfer Protocol", STD
9, RFC 959, October 1985.
[FTP] ポステルとJ.とJ.レイノルズ、「ファイル転送プロトコル」、STD9、RFC959、1985年10月。
[NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC
2663, August 1999.
Srisuresh、P.、M.Holdrege、および「IPネットワークアドレス変換機構(NAT)用語と問題」という[ナット-用語]、RFC2663、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)」、RFC3022、2001年1月。
[NAT-PT] Tsirtsis, G. and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC 2766,
February 2000.
[太平洋標準時のNAT]TsirtsisとG.とP.Srisuresh、「アドレス変換をネットワークでつないでください--翻訳(太平洋標準時のNAT)について議定書の中で述べる」、RFC2766、2000年2月。
[IPsec-AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.
[IPsec、-、ああ、]、ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、1998年11月。
[IPsec-ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[IPsec-超能力] ケントとS.とR.アトキンソン、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC2406、1998年11月。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[TLS] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[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.
WesterinenとA.とSchnizleinとJ.とStrassnerとJ.とScherlingとM.とクインとB.とハーツォグとS.とHuynhとA.とカールソンとM.とペリーとJ.とS.Waldbusser、「方針を拠点とする管理のための用語」という[POL用語]、RFC3198(2001年11月)。
Srisuresh, et al. Informational [Page 32] RFC 3303 MIDCOM Architecture and Framework August 2002
Srisuresh、他 情報[32ページ]のRFC3303MIDCOMアーキテクチャとフレームワーク2002年8月
[REQMTS] Swale, R. P., Mart, P. A., Sijben, P., Brim, S. and M.
Shore, "Middlebox Communications (midcom) Protocol
Requirements", RFC 3304, August 2002.
[REQMTS]低湿地、R.P.、市場、P.A.、Sijben、P.、縁、S.、およびM.は、「Middleboxコミュニケーション(midcom)プロトコル要件」と支えます、RFC3304、2002年8月。
Authors' Addresses
作者のアドレス
Pyda Srisuresh Kuokoa Networks, Inc. 475 Potrero Ave. Sunnyvale, CA 94085 EMail: srisuresh@yahoo.com
Pyda Srisuresh KuokoaはInc.475Potrero Aveをネットワークでつなぎます。 サニーベル、カリフォルニア 94085はメールされます: srisuresh@yahoo.com
Jiri Kuthan Fraunhofer Institute FOKUS Kaiserin-Augusta-Allee 31 D-10589 Berlin, Germany EMail: kuthan@fokus.fhg.de
ジリKuthanフラウンホーファー研究所FOKUS皇后オーガスタ並木道31D-10589ベルリン(ドイツ)メール: kuthan@fokus.fhg.de
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936 U.S.A. EMail: jdrosen@dynamicsoft.com
ジョナサンローゼンバーグdynamicsoft72Eagle Rock AvenueのFirst Floorの東ハノーバー王家、ニュージャージー07936米国EMail: 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レキシントンのアベニューの北部、Suite1105アーデンの森ヒル(ミネソタ)55126米国声: (651) 256-2700 メールしてください: 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メールのAbdallah Rayhan WINCORE研究室電気とコンピュータ工学ライアソン大学350ヴィクトリア・ストリートトロント: rayhan@ee.ryerson.ca 、ar_rayhan@yahoo.ca
Srisuresh, et al. Informational [Page 33] RFC 3303 MIDCOM Architecture and Framework August 2002
Srisuresh、他 情報[33ページ]のRFC3303MIDCOMアーキテクチャとフレームワーク2002年8月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Srisuresh, et al. Informational [Page 34]
Srisuresh、他 情報[34ページ]
一覧
スポンサーリンク
