RFC5189 日本語訳
5189 Middlebox Communication (MIDCOM) Protocol Semantics. M.Stiemerling, J. Quittek, T. Taylor. March 2008. (Format: TXT=161167 bytes) (Obsoletes RFC3989) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Stiemerling Request for Comments: 5189 J. Quittek Obsoletes: 3989 NEC Category: Standards Track T. Taylor Nortel March 2008
Stiemerlingがコメントのために要求するワーキンググループM.をネットワークでつないでください: 5189J.Quittekは以下を時代遅れにします。 3989年のNECカテゴリ: 2008年の標準化過程T.テイラーのノーテルの行進
Middlebox Communication (MIDCOM) Protocol Semantics
Middleboxコミュニケーション(MIDCOM)プロトコル意味論
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This document specifies semantics for a Middlebox Communication (MIDCOM) protocol to be used by MIDCOM agents for interacting with middleboxes such as firewalls and Network Address Translators (NATs). The semantics discussion does not include any specification of a concrete syntax or a transport protocol. However, a concrete protocol is expected to implement the specified semantics or, more likely, a superset of it. The MIDCOM protocol semantics is derived from the MIDCOM requirements, from the MIDCOM framework, and from working group decisions. This document obsoletes RFC 3989.
Middlebox Communication(MIDCOM)プロトコルがファイアウォールやNetwork Address Translators(NATs)などのmiddleboxesと対話するのにMIDCOMエージェントによって使用されるように、このドキュメントは意味論を指定します。 意味論議論は具象構文かトランスポート・プロトコルの少しの仕様も含んでいません。 しかしながら、具体的なプロトコルが指定された意味論かおそらくそれのスーパーセットを実装すると予想されます。 MIDCOM要件からMIDCOMフレームワークと、ワーキンググループ決定からMIDCOMプロトコル意味論を得ます。 このドキュメントはRFC3989を時代遅れにします。
Stiemerling, et al. Standards Track [Page 1] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[1ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
Table of Contents
目次
1. Introduction ....................................................4 1.1. Terminology ................................................5 1.2. Transaction Definition Template ............................7 2. Semantics Specification .........................................8 2.1. General Protocol Design ....................................8 2.1.1. Protocol Transactions ...............................8 2.1.2. Message Types .......................................9 2.1.3. Session, Policy Rule, and Policy Rule Group ........10 2.1.4. Atomicity ..........................................11 2.1.5. Access Control .....................................11 2.1.6. Middlebox Capabilities .............................12 2.1.7. Agent and Middlebox Identifiers ....................12 2.1.8. Conformance ........................................13 2.2. Session Control Transactions ..............................13 2.2.1. Session Establishment (SE) .........................14 2.2.2. Session Termination (ST) ...........................16 2.2.3. Asynchronous Session Termination (AST) .............16 2.2.4. Session Termination by Interruption of Connection ..17 2.2.5. Session State Machine ..............................17 2.3. Policy Rule Transactions ..................................18 2.3.1. Configuration Transactions .........................19 2.3.2. Establishing Policy Rules ..........................19 2.3.3. Maintaining Policy Rules and Policy Rule Groups ....20 2.3.4. Policy Events and Asynchronous Notifications .......21 2.3.5. Address Tuples .....................................21 2.3.6. Address Parameter Constraints ......................23 2.3.7. Interface-Specific Policy Rules ....................25 2.3.8. Policy Reserve Rule (PRR) ..........................25 2.3.9. Policy Enable Rule (PER) ...........................30 2.3.10. Policy Rule Lifetime Change (RLC) .................36 2.3.11. Policy Rule List (PRL) ............................38 2.3.12. Policy Rule Status (PRS) ..........................39 2.3.13. Asynchronous Policy Rule Event (ARE) ..............41 2.3.14. Policy Rule State Machine .........................42 2.4. Policy Rule Group Transactions ............................43 2.4.1. Overview ...........................................43 2.4.2. Group Lifetime Change (GLC) ........................44 2.4.3. Group List (GL) ....................................46 2.4.4. Group Status (GS) ..................................47 3. Conformance Statements .........................................48 3.1. General Implementation Conformance ........................49 3.2. Middlebox Conformance .....................................50 3.3. Agent Conformance .........................................50 4. Transaction Usage Examples .....................................50 4.1. Exploring Policy Rules and Policy Rule Groups .............50 4.2. Enabling a SIP-Signaled Call ..............................54
1. 序論…4 1.1. 用語…5 1.2. トランザクション定義テンプレート…7 2. 意味論仕様…8 2.1. 一般プロトコルデザイン…8 2.1.1. トランザクションについて議定書の中で述べてください…8 2.1.2. メッセージタイプ…9 2.1.3. セッション、政策ルール、および政策ルールは分類されます…10 2.1.4. 最小単位…11 2.1.5. コントロールにアクセスしてください…11 2.1.6. Middlebox能力…12 2.1.7. エージェントとMiddlebox識別子…12 2.1.8. 順応…13 2.2. セッション制御トランザクション…13 2.2.1. セッション設立(SE)…14 2.2.2. セッション終了(ST)…16 2.2.3. 非同期なセッション終了(AST)…16 2.2.4. 接続の中断によるセッション終了。17 2.2.5. セッション州のマシン…17 2.3. 政策ルールトランザクション…18 2.3.1. 構成トランザクション…19 2.3.2. 制定方針は統治されます…19 2.3.3. 政策ルールと政策ルールを維持するのは分類されます…20 2.3.4. 方針イベントと非同期な通知…21 2.3.5. Tuplesを扱ってください…21 2.3.6. パラメタ規制を扱ってください…23 2.3.7. インタフェース特有の方針は統治されます…25 2.3.8. 責任準備金規則(PRR)…25 2.3.9. 方針は規則(PER)を可能にします…30 2.3.10. 政策ルール生涯変化(RLC)…36 2.3.11. 政策ルールリスト(PRL)…38 2.3.12. 政策ルール状態(PRS)…39 2.3.13. 非同期な政策ルールイベント(あります)…41 2.3.14. 政策ルール州のマシン…42 2.4. 政策ルールグループトランザクション…43 2.4.1. 概要…43 2.4.2. 生涯変化(GLC)を分類してください…44 2.4.3. リスト(GL)を分類してください…46 2.4.4. 状態(GS)を分類してください…47 3. 順応声明…48 3.1. 一般実装順応…49 3.2. Middlebox順応…50 3.3. エージェント順応…50 4. トランザクション使用例…50 4.1. 政策ルールと政策ルールを探るのは分類されます…50 4.2. 一口で合図された呼び出しを可能にします…54
Stiemerling, et al. Standards Track [Page 2] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[2ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
5. Compliance with MIDCOM Requirements ............................59 5.1. Protocol Machinery Requirements ...........................59 5.1.1. Authorized Association .............................59 5.1.2. Agent Connects to Multiple Middleboxes .............60 5.1.3. Multiple Agents Connect to Same Middlebox ..........60 5.1.4. Deterministic Behavior .............................60 5.1.5. Known and Stable State .............................60 5.1.6. Status Report ......................................61 5.1.7. Unsolicited Messages (Asynchronous Notifications) ..61 5.1.8. Mutual Authentication ..............................61 5.1.9. Session Termination by Any Party ...................61 5.1.10. Request Result ....................................62 5.1.11. Version Interworking ..............................62 5.1.12. Deterministic Handling of Overlapping Rules .......62 5.2. Protocol Semantics Requirements ...........................62 5.2.1. Extensible Syntax and Semantics ....................62 5.2.2. Policy Rules for Different Types of Middleboxes ....63 5.2.3. Ruleset Groups .....................................63 5.2.4. Policy Rule Lifetime Extension .....................63 5.2.5. Robust Failure Modes ...............................63 5.2.6. Failure Reasons ....................................63 5.2.7. Multiple Agents Manipulating Same Policy Rule ......63 5.2.8. Carrying Filtering Rules ...........................64 5.2.9. Parity of Port Numbers .............................64 5.2.10. Consecutive Range of Port Numbers .................64 5.2.11. Contradicting Overlapping Policy Rules ............64 5.3. Security Requirements .....................................64 5.3.1. Authentication, Confidentiality, Integrity .........64 5.3.2. Optional Confidentiality of Control Messages .......64 5.3.3. Operation across Untrusted Domains .................65 5.3.4. Mitigate Replay Attacks ............................65 6. Security Considerations ........................................65 7. IAB Considerations on UNSAF ....................................66 8. Acknowledgements ...............................................66 9. References .....................................................67 9.1. Normative References ......................................67 9.2. Informative References ....................................67 Appendix A. Changes from RFC 3989 .................................69
5. MIDCOM要件への承諾…59 5.1. 機械要件について議定書の中で述べてください…59 5.1.1. 協会を認可します…59 5.1.2. エージェントは複数のMiddleboxesに接続します…60 5.1.3. 複数のエージェントが同じMiddleboxに接続します…60 5.1.4. 決定論的な振舞い…60 5.1.5. 知られていて安定した状態…60 5.1.6. 現状報告…61 5.1.7. お節介なメッセージ(非同期な通知)。61 5.1.8. 互いの認証…61 5.1.9. どんなパーティによるセッション終了…61 5.1.10. 結果を要求してください…62 5.1.11. バージョンの織り込むこと…62 5.1.12. 重なることの決定論的な取り扱いは統治されます…62 5.2. 意味論要件について議定書の中で述べてください…62 5.2.1. 広げることができる構文と意味論…62 5.2.2. 方針はMiddleboxesの異なったタイプのために統治されます…63 5.2.3. Rulesetは分類します…63 5.2.4. 政策ルール生涯拡大…63 5.2.5. 強健な故障モード…63 5.2.6. 失敗は推論します…63 5.2.7. 同じ方針を操る複数のエージェントが判決を下します…63 5.2.8. フィルタリングを運ぶのは統治されます…64 5.2.9. ポートナンバーの同等…64 5.2.10. 連続した範囲のポートナンバー…64 5.2.11. 方針を重ね合わせながら反駁するのは統治されます…64 5.3. セキュリティ要件…64 5.3.1. 認証、秘密性、保全…64 5.3.2. コントロールメッセージの任意の秘密性…64 5.3.3. 信頼されていないドメイン中の操作…65 5.3.4. 反射攻撃を緩和してください…65 6. セキュリティ問題…65 7. UNSAFの上のIAB問題…66 8. 承認…66 9. 参照…67 9.1. 標準の参照…67 9.2. 有益な参照…67 付録A.はRFC3989から変化します…69
Stiemerling, et al. Standards Track [Page 3] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[3ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
1. Introduction
1. 序論
The MIDCOM working group has defined a framework [MDC-FRM] and a list of requirements [MDC-REQ] for middlebox communication. The next step toward a MIDCOM protocol is the specification of protocol semantics that is constrained, but not completely implied, by the documents mentioned above.
MIDCOMワーキンググループはフレームワーク[MDC-FRM]とmiddleboxコミュニケーションのための要件のリスト[MDC-REQ]を定義しました。 MIDCOMプロトコルに向かった次のステップは抑制されますが、完全に含意されるというわけではないプロトコル意味論の仕様です、前記のようにドキュメントで。
This memo suggests a semantics for the MIDCOM protocol. It is fully compliant with the requirements listed in [MDC-REQ] and with the working group's consensus on semantic issues. This document obsoletes RFC 3989 [MDC-SEM].
このメモはMIDCOMプロトコルのために意味論を示します。 それは[MDC-REQ]にリストアップされている要件と意味問題に関するワーキンググループのコンセンサスによって完全に言いなりになっています。 このドキュメントはRFC3989[MDC-SEM]を時代遅れにします。
In conformance with the working group charter, the semantics description is targeted at packet filters and Network Address Translators (NATs), and it supports applications that require dynamic configuration of these middleboxes.
ワーキンググループ特許による順応では、意味論記述はパケットフィルタとNetwork Address Translators(NATs)をターゲットにします、そして、それはこれらのmiddleboxesの動的設定を必要とするアプリケーションをサポートします。
The semantics is defined in terms of transactions. Two basic types of transactions are used: request transactions and asynchronous transactions. Further, we distinguish two concrete types of request transactions: configuration transactions and monitoring transactions.
意味論はトランザクションで定義されます。 2人の基本型のトランザクションは使用されています: トランザクションと非同期なトランザクションを要求してください。 さらに、私たちは2つの具体的なタイプの要求トランザクションを区別します: 構成トランザクションとモニターしているトランザクション。
For each transaction, the semantics is specified by describing (1) the parameters of the transaction; (2) the processing of request messages at the middlebox; (3) the state transitions at the middlebox caused by the request transactions or indicated by the asynchronous transactions, respectively; and (4) the reply and notification messages sent from the middlebox to the agent in order to inform the agent about the state change.
各トランザクションとして、意味論は(1) トランザクションのパラメタについて説明することによって、指定されます。 (2) middleboxの要求メッセージの処理。 (3) 状態は要求トランザクションによって引き起こされるか、または非同期なトランザクションによってそれぞれ示されたmiddleboxで移行します。 (4) そして、回答と通知メッセージは、州の変化に関してエージェントに知らせるためにmiddleboxからエージェントまで発信しました。
The semantics can be implemented by any protocol that supports these two transaction types and that is sufficiently flexible concerning transaction parameters. Different implementations for different protocols might need to extend the semantics described below by adding further transactions and/or adding further parameters to transactions and/or splitting single transactions into a set of transactions. Regardless of such extensions, the semantics below provides a minimum necessary subset of what must be implemented.
どんなこれらの2つのトランザクションタイプをサポートしている、トランザクションパラメタに関して十分フレキシブルなプロトコルも意味論を実装することができます。 異なったプロトコルのための異なった実装は、以下でさらなるトランザクションを加える、さらなるパラメタをトランザクションに加える、そして/または、単一取引を1セットのトランザクションに分けることによって説明された意味論について敷衍する必要があるかもしれません。 そのような拡大にかかわらず、以下の意味論は実装しなければならないことに関する最小の必要な部分集合を提供します。
The remainder of this document is structured as follows. Section 2 describes the protocol semantics. It is structured in four subsections:
このドキュメントの残りは以下の通り構造化されます。 セクション2はプロトコル意味論について説明します。 それは4つの小区分で構造化されます:
- General Protocol Design (section 2.1) - Session Control (section 2.2) - Policy Rules (section 2.3) - Policy Rule Groups (section 2.4)
- 一般プロトコルデザイン(セクション2.1)--セッション制御(セクション2.2)--政策ルール(セクション2.3)--政策ルールグループ(セクション2.4)
Stiemerling, et al. Standards Track [Page 4] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[4ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
Section 3 contains conformance statements for MIDCOM protocol definitions and MIDCOM protocol implementations with respect to the semantics defined in section 2. Section 4 gives two elaborated usage examples. Finally, section 5 explains how the semantics meets the MIDCOM requirements.
セクション3はセクション2で定義された意味論に関してMIDCOMプロトコル定義とMIDCOMプロトコル実装のための順応声明を含みます。 セクション4は2つの練られた使用例を与えます。 最終的に、セクション5は意味論がどうMIDCOM必要条件を満たすかを説明します。
1.1. Terminology
1.1. 用語
The terminology in this memo follows the definitions given in the framework [MDC-FRM] and requirements [MDC-REQ] document.
このメモによる用語はフレームワーク[MDC-FRM]と要件[MDC-REQ]ドキュメントで与えられた定義に続きます。
In addition, the following terms are used:
さらに、次の期間は使用されています:
request transaction A request transaction consists of a request message transfer from the agent to the middlebox, processing of the message at the middlebox, a reply message transfer from the middlebox to the agent, and the optional transfer of notification messages from the middlebox to agents other than the one requesting the transaction. A request transaction might cause a state transition at the middlebox.
トランザクションA要求トランザクションがエージェントからmiddleboxまでの要求メッセージ転送、middleboxのメッセージの処理、middleboxからエージェントまでの回答メッセージ転送、およびトランザクションを要求するもの以外の通知メッセージの任意のmiddleboxからエージェントまでの転送から成るよう要求してください。 要求トランザクションはmiddleboxで状態遷移を引き起こすかもしれません。
configuration transaction A configuration transaction is a request transaction containing a request for state change in the middlebox. If accepted, it causes a state change at the middlebox.
構成トランザクションA構成トランザクションはmiddleboxに州の変化を求める要求を含む要求トランザクションです。 受け入れるなら、それはmiddleboxで州の変化を引き起こします。
monitoring transaction A monitoring transaction is a request transaction containing a request for state information from the middlebox. It does not cause a state transition at the middlebox.
モニターしているトランザクションAモニターしているトランザクションはmiddleboxからの州の情報に関する要求を含む要求トランザクションです。 それはmiddleboxで状態遷移を引き起こしません。
asynchronous transaction An asynchronous transaction is not triggered by an agent. It may occur without any agent participating in a session with the middlebox. Potentially, an asynchronous transaction includes the transfer of notification messages from the middlebox to agents that participate in an open session. A notification message is sent to each agent that needs to be notified about the asynchronous event. The message indicates the state transition at the middlebox.
非同期なトランザクションAn非同期なトランザクションはエージェントによって引き起こされません。 どんなエージェントもmiddleboxで会議に参加しないで、それは起こるかもしれません。 潜在的に、非同期なトランザクションは通知メッセージのmiddleboxから公開審議に参加するエージェントまでの転送を含んでいます。 非同期的なイベントに関して通知される必要がある各エージェントに通知メッセージを送ります。 メッセージはmiddleboxで状態遷移を示します。
Stiemerling, et al. Standards Track [Page 5] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[5ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
agent-unique An agent-unique value is unique in the context of the agent. This context includes all MIDCOM sessions the agent participates in. An agent-unique value is assigned by the agent.
エージェントユニークなAnエージェントユニークな値はエージェントの文脈でユニークです。 この文脈はエージェントが参加するすべてのMIDCOMセッションを含んでいます。 エージェントユニークな値はエージェントによって割り当てられます。
middlebox-unique A middlebox-unique value is unique in the context of the middlebox. This context includes all MIDCOM sessions the middlebox participates in. A middlebox-unique value is assigned by the middlebox.
middleboxユニークなA middleboxユニークな値はmiddleboxの文脈でユニークです。 この文脈はmiddleboxが参加するすべてのMIDCOMセッションを含んでいます。 middleboxユニークな値はmiddleboxによって割り当てられます。
policy rule In general, a policy rule is "a basic building block of a policy-based system. It is the binding of a set of actions to a set of conditions -- where the conditions are evaluated to determine whether the actions are performed" [RFC3198]. In the MIDCOM context, the condition is a specification of a set of packets to which rules are applied. The set of actions always contains just a single element per rule, either action "reserve" or action "enable".
政策ルールIn一般、政策ルールは「方針ベースのシステムの基本的なブロック」です。 「それは状態が動作が実行されるかどうか決定するために評価されるところの1セットの状態への1セットの機能の結合[RFC3198]です」。 MIDCOM文脈では、状態は規則が適用されている1セットのパケットの仕様です。 動作のセットはいつもまさしく動作「蓄え」か動作「可能にどちらか」という規則あたり1つのただ一つの要素を含んでいます。
policy reserve rule A policy rule containing a reserve action. The policy condition of this rule is always true. The action is the reservation of just an IP address or a combination of an IP address and a range of port numbers on neither side, one side, or both sides of the middlebox, depending on the middlebox configuration.
蓄えの動作を含む責任準備金規則A政策ルール。 この規則の方針状態はいつも本当です。 動作は、まさしくIPアドレスの予約かどちらの側のIPアドレスとさまざまなポートナンバー、半面、またはmiddleboxの両側の組み合わせです、middlebox構成によって。
policy enable rule A policy rule containing an enable action. The policy condition consists of a descriptor of one or more unidirectional or bidirectional packet flows, and the policy action enables packets belonging to this flow to traverse the middlebox. The descriptor identifies the protocol, the flow direction, and the source and destination addresses, optionally with a range of port numbers.
方針が規則A政策ルール含有を可能にする、動作を可能にしてください。 方針状態は1回以上の単方向か双方向のパケット流れに関する記述子から成ります、そして、政策的措置はこの流れに属すパケットがmiddleboxを横断するのを可能にします。 記述子はさまざまなポートナンバーで任意にプロトコル、流れ方向、ソース、および送付先アドレスを特定します。
Stiemerling, et al. Standards Track [Page 6] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[6ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
NAT binding The term NAT binding as used in this document does not necessarily refer to a NAT bind as defined in [NAT-TERM]. A NAT binding in the MIDCOM semantics refers to an abstraction that enables communication between two endpoints through the NAT-type middlebox. An enable action may result in a NAT bind or a NAT session, depending on the request and its parameters.
使用されるように付く用語NATを縛るNATは必ず本書では[NAT-TERM]で定義されるNATひもについて言及するというわけではありません。 MIDCOM意味論で付くNATはNATタイプmiddleboxで2つの終点のコミュニケーションを可能にする抽象化について言及します。 a NATひもかNATセッションのときになるかもしれなくて、要求とそのパラメタによって、動作を可能にしてください。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
1.2. Transaction Definition Template
1.2. トランザクション定義テンプレート
In the following sections, the semantics of the MIDCOM protocol is specified per transaction. A transaction specification contains the following entries. Parameter entries, failure reason, and notification message type are only specified if applicable.
以下のセクションでは、MIDCOMプロトコルの意味論はトランザクション単位で指定されます。 トランザクション仕様は以下のエントリーを含んでいます。 指定されているだけですが、パラメタエントリー、失敗理由、および通知メッセージタイプは適切です。
transaction-name A description name for this type of transaction.
このタイプのトランザクションのためのトランザクション名のA記述名。
transaction-type The transaction type is either 'configuration', 'monitoring', or 'asynchronous'. See section 1.1 for a description of transaction types.
トランザクションがタイプするトランザクションタイプは'モニターしている'か、'非同期な'どちらかの'構成'です。 トランザクションタイプの記述に関してセクション1.1を見てください。
transaction-compliance This entry contains either 'mandatory' or 'optional'. For details, see section 2.1.8.
トランザクションコンプライアンスThisエントリーは'義務的である'か'任意'の状態でどちらかを含んでいます。 詳細に関しては、セクション2.1.8を見てください。
request-parameters This entry lists all parameters necessary for this request. A description for each parameter is given.
要求パラメタThisエントリーはこの要求に必要なすべてのパラメタをリストアップします。 各パラメタのための記述を与えます。
reply-parameters (success) This entry lists all parameters sent back from the middlebox to the agent as positive response to the prior request. A description for each parameter is given.
先の要求へのこのエントリーがmiddleboxからエージェントまで返送されたすべてのパラメタをリストアップする回答パラメタ(成功)積極的な応答。 各パラメタのための記述を与えます。
failure reason All negative replies have two parameters: a request identifier identifying the request on which the reply is sent and a parameter indicating the failure reason. As these parameters are compulsory, they are not listed in the template. But the template
All否定的な返事には2つのパラメタがある失敗理由: 回答が送られる要求を特定する要求識別子と失敗を示すパラメタは推論します。 これらのパラメタが強制的であるときに、それらはテンプレートに記載されません。 しかし、テンプレート
Stiemerling, et al. Standards Track [Page 7] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[7ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
contains a list of potential failure reasons that may be indicated by the second parameter. The list is not exhaustive. A concrete protocol specification may extend the list.
2番目のパラメタによって示されるかもしれない起こりうる失敗理由のリストを含んでいます。 リストは徹底的ではありません。 具体的なプロトコル仕様はリストを広げるかもしれません。
notification message type This entry describes the notification message type that may be used by this transaction.
通知メッセージタイプThisエントリーはこのトランザクションによって使用されるかもしれない通知メッセージタイプについて説明します。
semantics This entry describes the actual semantics of the transaction. Particularly, it describes the processing of the request message by the middlebox, and middlebox state transitions caused by or causing the transaction, respectively.
意味論Thisエントリーはトランザクションの実際の意味論について説明します。 特に、それはmiddlebox、およびそれぞれトランザクションを引き起こされるか、または引き起こすmiddlebox状態遷移による要求メッセージの処理について説明します。
2. Semantics Specification
2. 意味論仕様
2.1. General Protocol Design
2.1. 一般プロトコルデザイン
The semantics specification aims at a balance between proper support of applications that require dynamic configuration of middleboxes and simplicity of specification and implementation of the protocol.
意味論仕様は動的設定にmiddleboxesを要求するアプリケーションの適切なサポートと、仕様の簡単さとプロトコルの実装の間のバランスを目的とします。
Protocol interactions are structured into transactions. The state of middleboxes is described by state machines. The state machines are defined by states and state transitions. A single transaction may cause or be caused by state transitions in more than one state machine, but per state machine there is no more than one transition per transaction.
プロトコル相互作用はトランザクションに構造化されます。 middleboxesの状態は州のマシンによって説明されます。 州のマシンは州と状態遷移で定義されます。 単一取引が引き起こされるかもしれないか、1台以上の州のマシンで状態遷移で引き起こされますが、または1トランザクションあたり1つ未満の変遷が州のマシン単位であります。
2.1.1. Protocol Transactions
2.1.1. プロトコルトランザクション
State transitions are initiated either by a request message from the agent to the middlebox or by some other event at the middlebox. In the first case, the middlebox informs the agent by sending a reply message on the actual state transition; in the second, the middlebox sends an unsolicited asynchronous notification message to each agent affected by the transaction (if it participates in an open session with the middlebox).
状態遷移はエージェントからmiddleboxまでの要求メッセージかmiddleboxのある他のイベントによって開始されます。 前者の場合、middleboxは実際の状態遷移に応答メッセージを送ることによって、エージェントに知らせます。 2番目では、middleboxはトランザクションで影響を受ける各エージェントに求められていない非同期な通知メッセージを送ります(middleboxで公開審議に参加するなら)。
Request and reply messages contain an agent-unique request identifier that allows the agent to determine to which sent request a received reply corresponds.
要求と応答メッセージはエージェントが容認された回答がどれが要求を送ったかと対応するかを決心できるエージェントユニークな要求識別子を含んでいます。
An analysis of the requirements showed that three kinds of transactions are required:
要件の分析は、3種類のトランザクションが必要であることを示しました:
- Configuration transactions allowing the agent to request state transitions at the middlebox.
- エージェントがmiddleboxで状態遷移を要求できる構成トランザクション。
Stiemerling, et al. Standards Track [Page 8] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[8ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
- Asynchronous transactions allowing the reporting of state changes that have not been requested by the agent.
- エージェントによって要求されていない州の変化の報告を許す非同期なトランザクション。
- Monitoring transactions allowing the agent to request state information from the middlebox.
- エージェントがmiddleboxから州の情報を要求できるトランザクションをモニターします。
Configuration transactions and asynchronous transactions provide the basic MIDCOM protocol functionality. They are related to middlebox state transitions, and they concern establishment and termination of MIDCOM sessions and of policy rules.
構成トランザクションと非同期なトランザクションは基本のMIDCOMプロトコルの機能性を提供します。 それらはmiddlebox状態遷移に関連します、そして、MIDCOMセッションと政策ルールの設立と終了に、関係があります。
Monitoring transactions are not related to middlebox state transitions. They are used by agents to explore the number, status, and properties of policy rules established at the middlebox.
モニターしているトランザクションはmiddlebox状態遷移に関連しません。 それらは、middleboxで確立された政策ルールの数、状態、および特性を探るのにエージェントによって使用されます。
As specified in detail in section 3, configuration transactions and asynchronous transactions are mandatory except of the Group Lifetime Change (GLC). They must be implemented by a compliant middlebox. The GLC transaction and some of the monitoring transactions are optional.
セクション3で詳細に指定されるように、Group Lifetime Change(GLC)を除いて、構成トランザクションと非同期なトランザクションは義務的です。 言いなりになっているmiddleboxはそれらを実装しなければなりません。 GLCトランザクションとモニターしているトランザクションのいくつかが任意です。
2.1.2. Message Types
2.1.2. メッセージタイプ
The MIDCOM protocol supports three kinds of messages: request messages, reply messages, and notification messages. For each kind, different message types exist. In this semantics document, message types are only defined by the list of parameters. The order of the parameters and their encoding are left to a concrete protocol definition. A protocol definition may also add further parameters to a message type or combine several parameters into one, as long as the information contained in the parameters defined in the semantics is still present.
MIDCOMプロトコルは3種類のメッセージをサポートします: メッセージ、応答メッセージ、および通知メッセージを要求してください。 各種類のために、異なったメッセージタイプは存在しています。 この意味論ドキュメントでは、メッセージタイプはパラメタのリストによって定義されるだけです。 パラメタの注文とそれらのコード化は具体的なプロトコル定義に残されます。 また、プロトコル定義は、メッセージへのパラメタがいくつかのパラメタを1つにタイプするか、または結合するとさらに言い足すかもしれません、意味論で定義されたパラメタに含まれた情報がまだ存在している限り。
For request messages and positive reply messages, there exists one message type per request transaction. Each reply transaction defines the parameter list of the request message and of the positive (successful) reply message by using the transaction definition template defined in section 1.2.
要求メッセージと積極的な応答メッセージのために、要求トランザクションあたり1つのメッセージタイプが存在しています。 それぞれの回答トランザクションは、セクション1.2で定義されたトランザクション定義テンプレートを使用することによって、要求メッセージと積極的な(うまくいっている)応答メッセージに関するパラメータ・リストを定義します。
In case of a failed request transaction, a negative reply message is sent from the middlebox to the agent. This message is the same for all request transactions; it contains the request identifier identifying the request to which the reply is sent and a parameter indicating the failure reason.
失敗した要求トランザクションの場合には、否定的な返事メッセージをmiddleboxからエージェントに送ります。 すべての要求トランザクションに、このメッセージは同じです。 それは回答が送られる要求を特定する要求識別子と失敗理由を示すパラメタを含んでいます。
Stiemerling, et al. Standards Track [Page 9] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[9ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
There are three notification message types: the Session Termination Notification (STN), the Policy Rule Event Notification (REN), and the Group Event Notification (GEN). All of these contain a middlebox- unique notification identifier.
3つの通知メッセージタイプがあります: セッション終了通知(STN)、政策ルールイベント通知(REN)、およびグループイベント通知(情報を得ます)。 これらはすべて、middleboxのユニークな通知識別子を含んでいます。
STN The Session Termination Notification message additionally contains a single parameter indicating the reason for session termination by the middlebox.
Session Termination Notificationがさらに、通信させるSTNはmiddleboxによるセッション終了の理由を示すただ一つのパラメタを含んでいます。
REN The Policy Rule Event Notification message contains the notification identifier, a policy rule identifier, and the remaining policy lifetime.
Policy Rule Event Notificationが通信させるRENは通知識別子、政策ルール識別子、および残っている方針生涯を含んでいます。
GEN The Group Event Notification message contains the notification identifier, a policy rule group identifier, and the remaining policy rule group lifetime.
Group Event Notificationが通信させるGENは識別子、政策ルールグループ識別子、および残っている政策ルールが生涯を分類するという通知を含んでいます。
2.1.3. Session, Policy Rule, and Policy Rule Group
2.1.3. セッション、政策ルール、および政策ルールは分類されます。
All transactions can be further grouped into transactions concerning sessions, transactions concerning policy rules, and transactions concerning policy rule groups. Policy rule groups can be used to indicate relationships between policy rules and to simplify transactions on a set of policy rules by using a single transaction per group instead of one per policy rule.
さらにすべてのトランザクションをセッションに関するトランザクション、政策ルールに関するトランザクション、および政策ルールグループに関するトランザクションに分類できます。 政策ルールの間の関係を示して、政策ルールのセットで1の代わりに1政策ルールあたりのグループあたり1つの単一取引を使用することによってトランザクションを簡素化するのに政策ルールグループを使用できます。
Sessions and policy rules at the middlebox are stateful. Their states are independent of each other, and their state machines (one per session and one per policy rule) can be separated. Policy rule groups are also stateful, but the middlebox does not need to maintain state for policy rule groups, because the semantics was chosen so that the policy rule group state is implicitly defined by the state of all policy rules belonging to the group (see section 2.4).
middleboxのセッションと政策ルールはstatefulです。 それらの州は互いから独立しています、そして、それらの州のマシン(1セッションあたり1つと1政策ルールあたり1つ)は切り離すことができます。 また、政策ルールグループもstatefulですが、middleboxは政策ルールグループのために状態を維持する必要はありません、意味論が選ばれたので政策ルールグループ状態がすべての政策ルールがグループに属す州によってそれとなく定義されるので(セクション2.4を見てください)。
The separation of session state and policy rule state simplifies the specification of the semantics as well as a protocol implementation. Therefore, the semantics specification is structured accordingly and we use two separated state machines to illustrate the semantics. Please note that state machines of concrete protocol designs and implementations will probably be more complex than the state machines presented here. However, the protocol state machines are expected to be a superset of the semantics state machines in this document.
セッション州と政策ルール状態の分離はプロトコル実装と同様に意味論の仕様を簡素化します。 したがって、意味論仕様はそれに従って、構造化されます、そして、私たちは意味論を例証するのに2台の切り離された州のマシンを使用します。 具体的なプロトコルデザインと実装の州のマシンはたぶんここで贈られた州のマシンより複雑でしょう。 しかしながら、プロトコル州のマシンは本書では意味論州のマシンのスーパーセットであると予想されます。
Stiemerling, et al. Standards Track [Page 10] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[10ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
2.1.4. Atomicity
2.1.4. 最小単位
All request transactions are atomic with respect to each other. This means that processing of a request at the middlebox is never interrupted by another request arriving or already queued. This particularly applies when the middlebox concurrently receives requests originating in different sessions. However, asynchronous transactions may interrupt and/or terminate processing of a request at any time.
すべての要求トランザクションが互いに関して原子です。 これは、middleboxでの要求の処理が別の要求到着で決して中断されないか、または既に列に並ばせられることを意味します。 middleboxが同時に異なったセッションのときに起因する要求を受け取るとき、これは特に適用されます。 しかしながら、非同期なトランザクションは、いつでも、要求の処理を中断する、そして/または、終えるかもしれません。
All request transactions are atomic from the point of view of the agent. The processing of a request does not start before the complete request arrives at the middlebox. No intermediate state is stable at the middlebox, and no intermediate state is reported to any agent.
すべての要求トランザクションがエージェントの観点から原子です。 完全な要求がmiddleboxに到着する前に要求の処理は始まりません。 どんな中間的状態もmiddleboxで安定していません、そして、どんな中間的状態もどんなエージェントにも報告されません。
The number of transactions specified in this document is rather small. Again, for simplicity, we reduced it to a minimal set that still meets the requirements. A real implementation of the protocol might require splitting some of the transactions specified below into two or more transactions of the respective protocol. Reasons for this might include constraints of the particular protocol or the desire for more flexibility. In general, this should not be a problem. However, it should be considered that this might change atomicity of the affected transactions.
本書では指定されたトランザクションの数はかなり少ないです。 一方、簡単さのために、私たちはそれをまだ条件を満たしている極小集合に変えました。 プロトコルの本当の実装は、いくつかを分けるのを以下でそれぞれのプロトコルの2つ以上のトランザクションに指定されたトランザクションを要求するかもしれません。 この理由は特定のプロトコルの規制か、より多くの柔軟性に関する願望を含むかもしれません。 一般に、これは問題であるべきではありません。 しかしながら、これが影響を受けるトランザクションの最小単位を変えるかもしれないと考えられるべきです。
2.1.5. Access Control
2.1.5. アクセス制御
Ownership determines access to policy rules and policy rule groups. When a policy rule is created, a middlebox-unique identifier is generated to identify it in further transactions. Beyond the identifier, each policy rule has an owner. The owner is the authenticated agent that established the policy rule. The middlebox uses the owner attribute of a policy rule to control access to it; each time an authenticated agent requests to modify an existing policy rule, the middlebox determines the owner of the policy rule and checks whether the requesting agent is authorized to perform transactions on the owning agent's policy rules.
所有権は政策ルールと政策ルールグループへのアクセスを決定します。 政策ルールが作成されるとき、middleboxユニークな識別子は、さらなるトランザクションでそれを特定するために生成されます。 識別子を超えて、各政策ルールには、所有者がいます。 所有者は政策ルールを確立した認証されたエージェントです。 middleboxはそれへのアクセスを制御するのに政策ルールの所有者属性を使用します。 認証されたエージェントが、既存の政策ルールを変更するために、middleboxが政策ルールの所有者を決定するよう要求して、要求しているエージェントが所有であることにトランザクションを実行するのに権限を与えられるかどうかチェックするたびにエージェントの方針は統治されます。
All policy rules belonging to the same policy rule group must have the same owner. Therefore, authenticated agents have access either to all members of a policy rule group or to none of them.
同じ政策ルールグループに属すすべての政策ルールには、同じ所有者がいなければなりません。 したがって、認証されたエージェントは政策ルールグループのすべてのメンバー、または、彼らのどれかにアクセスを持っていません。
The middlebox may be configured to allow specific authenticated agents to access and modify policy rules with certain specific owners. Certainly, a reasonable default configuration would let each agent access its own policy rules. Also, it might be good to configure an agent identity to act as administrator, allowing
middleboxは、特定の認証されたエージェントが確信している特定の所有者と共に政策ルールにアクセスして、変更するのを許容するために構成されるかもしれません。 確かに、妥当なデフォルト設定で、各エージェントはそれ自身の政策ルールにアクセスできるでしょう。 また、管理者、許容として機能するエージェントのアイデンティティを構成するのも良いかもしれません。
Stiemerling, et al. Standards Track [Page 11] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[11ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
modification of all policy rules owned by any agent. However, the configuration of authorization at the middlebox is out of scope of the MIDCOM semantics and protocol.
どんなエージェントによっても所有されていたすべての政策ルールの変更。 しかしながら、MIDCOM意味論とプロトコルの範囲の外にmiddleboxの承認の構成があります。
2.1.6. Middlebox Capabilities
2.1.6. Middlebox能力
For several reasons, it is useful that at session establishment the agent learns about particular capabilities of the middlebox. Therefore, the session establishment procedure described in section 2.2.1 includes a transfer of capability information from the middlebox to the agent. The list of covered middlebox capabilities includes the following:
いくつかの理由に、セッション設立では、エージェントが特定の能力に関してmiddleboxを学ぶのは、役に立ちます。 したがって、セクション2.2.1で説明されたセッション設立手順は能力情報のmiddleboxからエージェントまでの転送を含んでいます。 カバーされたmiddlebox能力のリストは以下を含んでいます:
- Support of firewall function - List of supported NAT functions, perhaps including - address translation - port translation - protocol translation - twice-NAT - Internal IP address wildcard support - External IP address wildcard support - Port wildcard support - Supported IP version(s) for internal network: IPv4, IPv6, or both - Supported IP version(s) for external network: IPv4, IPv6, or both - List of supported optional MIDCOM protocol transactions - Support for interface-specific policy rules - Policy rule persistence: persistent or non-persistent (a rule is persistent when the middlebox can save the rule to a non- volatile memory, e.g., a hard disk or flash memory) - Maximum remaining lifetime of a policy rule or policy rule group - Idle-timeout of policy rules in the middlebox (reserved and enabled policy rules not used by any data traffic for the time of this idle-timeout are deleted automatically by the middlebox; for the deletion of policy rules by middleboxes, see section 2.3.13, "Asynchronous Policy Rule Event (ARE)"). - Maximum number of simultaneous MIDCOM sessions
- ファイアウォール機能のサポート--サポートしているNAT機能のリスト、恐らく包含(アドレス変換)は翻訳--プロトコル変換--2倍NAT--内部のIPアドレスワイルドカードサポート--内部のネットワークのためのIPバージョンであるとサポートされた外部のIPアドレスワイルドカードサポート(ポートワイルドカードサポート)を移植します: IPv4、IPv6、または両方--外部のネットワークのためのサポートしているIPバージョン: IPv4、IPv6、または両方--サポートしている任意のMIDCOMプロトコルトランザクションのリスト--インタフェース特有の方針規則のサポート--Policyは固執を統治します: 中の政策ルールの永続的であるか非永続的な(middleboxが例えば、非揮発性メモリー、ハードディスクまたはフラッシュメモリに規則を保存できるとき、規則は永続的です)(政策ルールか政策ルールグループの最大の残っている生涯)アイドルタイムアウト; middlebox(このアイドルタイムアウトの時間のどんなデータ通信量でも使用されない予約されて可能にされた政策ルールはmiddleboxによって自動的に削除されます; middleboxesによる政策ルールの削除に関して、セクション2.3.13、「非同期な政策ルールイベント(ある)」を見てください)。 - 最大数の同時のMIDCOMセッション
The list of middlebox capabilities may be extended by a concrete protocol specification with further information useful for the agent.
middlebox能力のリストはエージェントの役に立つ詳細で具体的なプロトコル仕様で広げられるかもしれません。
2.1.7. Agent and Middlebox Identifiers
2.1.7. エージェントとMiddlebox識別子
To allow both agents and middleboxes to maintain multiple sessions, each request message contains a parameter identifying the requesting agent, and each reply message and each notification message contains a parameter identifying the middlebox. These parameters are not
エージェントとmiddleboxesの両方が複数のセッションを維持するのを許容するために、各要求メッセージは要求しているエージェントを特定するパラメタを含んでいます、そして、各応答メッセージと各通知メッセージはmiddleboxを特定するパラメタを含んでいます。 これらのパラメタはそうではありません。
Stiemerling, et al. Standards Track [Page 12] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[12ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
explicitly listed in the description of the individual transactions, because they are common to all of them. They are not further referenced in the individual semantics descriptions. Although they are not necessarily passed explicitly as parameters of the MIDCOM protocol, they might be provided by the underlying (secure) transport protocol being used. Agent identifiers at the middlebox are middlebox-unique, and middlebox identifiers at the agent are agent- unique, respectively.
それらがそれらのすべてに共通であるので、個々のトランザクションの記述で明らかに記載されています。 それらは個々の意味論記述でさらに参照をつけられません。 MIDCOMのパラメタが議定書を作るのに応じて、必ず明らかにそれらを通過するというわけではありませんが、使用される基本的な(安全な)トランスポート・プロトコルはそれらを提供するかもしれません。 middleboxのエージェント識別子はmiddleboxユニークです、そして、エージェントのmiddlebox識別子はエージェントそれぞれユニークです。
2.1.8. Conformance
2.1.8. 順応
The MIDCOM requirements in [MDC-REQ] demand capabilities of the MIDCOM protocol that are met by the set of transactions specified below. However, it is not required that an actual implementation of a middlebox supports all these transactions. The set of announced supported transactions may be different for different authenticated agents. The middlebox informs the authenticated agent with the capability exchange at session establishment about the transactions that the agent is authorized to perform. Some transactions need to be offered to every authenticated agent.
トランザクションのセットによって満たされるMIDCOMプロトコルの[MDC-REQ]要求能力におけるMIDCOM要件は以下で指定しました。 しかしながら、middleboxの実際の実装がこれらのすべてのトランザクションをサポートするのが必要ではありません。 異なった認証されたエージェントにとって、発表されたサポートしているトランザクションのセットは異なっているかもしれません。 能力交換がトランザクションに関するセッション設立にある状態で、middleboxは、エージェントが働くのに権限を与えられることを認証されたエージェントに知らせます。 いくつかのトランザクションが、すべての認証されたエージェントに提供される必要があります。
Each transaction definition below has a conformance entry that contains either 'mandatory' or 'optional'. A mandatory transaction needs to be implemented by every middlebox offering MIDCOM service and must be must be offered to each of the authenticated agents. An optional transaction does not necessarily need to be implemented by a middlebox; it may offer these optional transactions only to certain authenticated agents. The middlebox may offer one, several, all, or no optional transactions to the agents. Whether an agent is allowed to use an optional request transaction is determined by the middlebox's authorization procedure, which is not further specified by this document.
以下でのそれぞれのトランザクション定義には、'義務的である'か'任意'の状態でどちらかを含む順応エントリーがあります。 義務的なトランザクションは、サービスをMIDCOMに提供しながらあらゆるmiddleboxによって実装されるのが必要であり、あるに違いありません。認証されたエージェントの各人に提供しなければなりません。 任意のトランザクションは、必ずmiddleboxによって実装される必要があるというわけではありません。 それはこれらの任意のトランザクションを確信している認証されたエージェントだけに提供するかもしれません。 すべてを提供しますが、middleboxは1、数個、どんな任意のトランザクションもエージェントに提供しないかもしれません。 エージェントが任意の要求トランザクションを使用できるかどうかがmiddleboxの承認手順で決定します。(それは、このドキュメントによってさらに指定されません)。
2.2. Session Control Transactions
2.2. セッション制御トランザクション
Before any transaction on policy rules or policy rule groups is possible, a valid MIDCOM session must be established. A MIDCOM session is an authenticated and authorized association between agent and middlebox. Sessions are initiated by agents and can be terminated by either the agent or the middlebox. Both agent and middlebox may participate in several sessions (with different entities) at the same time. To distinguish different sessions, each party uses local session identifiers.
政策ルールか政策ルールグループに関するどんなトランザクションも可能になる前に、有効なMIDCOMセッションを確立しなければなりません。 MIDCOMセッションはエージェントとmiddleboxとの認証されて認可された仲間です。 セッションをエージェントが開始して、エージェントかmiddleboxのどちらかが終えることができます。 エージェントとmiddleboxの両方が同時に、いくつかのセッション(異なった実体がある)のときに関与するかもしれません。 異なったセッションを区別するために、各当事者はローカルのセッション識別子を使用します。
All transactions are transmitted within this MIDCOM session.
すべてのトランザクションがこのMIDCOMセッション中に伝えられます。
Stiemerling, et al. Standards Track [Page 13] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[13ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
Session control is supported by three transactions:
セッション制御は3つのトランザクションで後押しされています:
- Session Establishment (SE) - Session Termination (ST) - Asynchronous Session Termination (AST)
- セッション設立(SE)--セッション終了(ST)--非同期なセッション終了(AST)
The first two are configuration transactions initiated by the agent, and the last one is an asynchronous transaction initiated by the middlebox.
最初の2はエージェントによって開始された構成トランザクションです、そして、最後の1つはmiddleboxによって開始された非同期なトランザクションです。
2.2.1. Session Establishment (SE)
2.2.1. セッション設立(SE)
transaction-name: session establishment
トランザクション名: セッション設立
transaction-type: configuration
トランザクションタイプ: 構成
transaction-compliance: mandatory
トランザクションコンプライアンス: 義務的
request-parameters:
要求パラメタ:
- request identifier: An agent-unique identifier for matching corresponding request and reply at the agent.
- 識別子を要求してください: エージェントで対応する要求と回答に合うためのエージェントユニークな識別子。
- version: The version of the MIDCOM protocol.
- バージョン: MIDCOMプロトコルのバージョン。
- middlebox challenge (mc): An authentication challenge token for authentication of the middlebox. As seen below, this is present only in the first iteration of the request.
- middlebox挑戦(mc): middleboxの認証のための認証挑戦トークン。 以下が見られるように、これは要求の最初の繰り返しだけで存在しています。
- agent authentication (aa): An authentication token authenticating the agent to the middlebox. As seen below, this is updated in the second iteration of the request with material responding to the middlebox challenge.
- エージェント認証(aa): middleboxのエージェントを認証する認証トークン。 以下が見られるように、材料がmiddlebox挑戦に応じていて、要求の2番目の繰り返しでこれをアップデートします。
reply-parameters (success):
回答パラメタ(成功):
- request identifier: An identifier matching the identifier request.
- 識別子を要求してください: 識別子要求に合っている識別子。
- middlebox authentication (ma): An authentication token authenticating the middlebox to the agent.
- middlebox認証(ma): エージェントにmiddleboxを認証する認証トークン。
- agent challenge (ac): An authentication challenge token for the agent authentication.
- エージェント挑戦(ac): エージェント認証のための認証挑戦トークン。
- middlebox capabilities: A list describing the middlebox's capabilities. See section 2.1.6 for the list of middlebox capabilities.
- middlebox能力: middleboxの能力について説明するリスト。 middlebox能力のリストに関してセクション2.1.6を見てください。
Stiemerling, et al. Standards Track [Page 14] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[14ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
failure reason:
失敗理由:
- authentication failed - no authorization - protocol version of agent and middlebox do not match - lack of resources
- マッチではなく、エージェントとmiddleboxの失敗した(承認がない)プロトコルバージョンがそうする認証--財源不足
semantics:
意味論:
This session establishment transaction is used to establish a MIDCOM session. For mutual authentication of both parties, two subsequent session establishment transactions are required as shown in Figure 1.
このセッション設立トランザクションは、MIDCOMセッションを証明するのに使用されます。 双方の互いの認証において、2つのその後のセッション設立トランザクションが図1に示されるように必要です。
agent middlebox | session establishment request | | (with middlebox challenge mc) | CLOSED |-------------------------------------------->| | | | successful reply (with middlebox | | authentication ma and agent challenge ac) | |<--------------------------------------------| | | NOAUTH | session establishment request | | (with agent authentication aa) | |-------------------------------------------->| | | | successful reply | |<--------------------------------------------| | | OPEN | |
エージェントmiddlebox| セッション設立要求| | (middlebox挑戦mcがある) | 閉じられます。|-------------------------------------------->| | | | うまくいっている回答(middlebox| | 認証maとエージェント挑戦acと)| |<--------------------------------------------| | | NOAUTH| セッション設立要求| | (エージェント認証aaと) | |-------------------------------------------->| | | | うまくいっている回答| |<--------------------------------------------| | | 戸外| |
Figure 1: Mutual Authentication of Agent and Middlebox
図1: エージェントとMiddleboxの互いの認証
Session establishment may be simplified by using only a single transaction. In this case, server challenge and agent challenge are omitted by the sender or ignored by the receiver, and authentication must be provided by other means, for example, by Transport Layer Security (TLS) [RFC4346] or IPsec [RFC4302][RFC4303].
セッション設立は、単一取引だけを使用することによって、簡素化されるかもしれません。 この場合、サーバ挑戦とエージェント挑戦は、送付者によって省略されるか、または受信機によって無視されます、そして、例えば、Transport Layer Security(TLS)[RFC4346]かIPsec[RFC4302][RFC4303]が他の手段で認証を提供しなければなりません。
The middlebox checks with its policy decision point whether the requesting agent is authorized to open a MIDCOM session. If it is not, the middlebox generates a negative reply with 'no authorization' as the failure reason. If authentication and authorization are successful, the session is established, and the agent may start with requesting transactions on policy rules and policy rule groups.
middleboxは、要求しているエージェントがMIDCOMセッションを開くのに権限を与えられるかどうか政策決定ポイントに問い合わせます。 それがそうでないなら、middleboxは失敗理由として'承認がありません'で否定的な返事を生成します。 認証と承認がうまくいくなら、セッションは確立されます、そして、エージェントは政策ルールでトランザクションを要求して、政策ルールグループから始まるかもしれません。
Stiemerling, et al. Standards Track [Page 15] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[15ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
Part of the successful reply is an indication of the middlebox's capabilities.
うまくいっている回答の一部がmiddleboxの能力のしるしです。
2.2.2. Session Termination (ST)
2.2.2. セッション終了(ST)
transaction-name: session termination
トランザクション名: セッション終了
transaction-type: configuration
トランザクションタイプ: 構成
transaction-compliance: mandatory
トランザクションコンプライアンス: 義務的
request-parameters:
要求パラメタ:
- request identifier: An agent-unique identifier for matching corresponding request and reply at the agent.
- 識別子を要求してください: エージェントで対応する要求と回答に合うためのエージェントユニークな識別子。
reply-parameters (success only):
回答パラメタ(成功専用):
- request identifier: An identifier matching the identifier of the request.
- 識別子を要求してください: 要求に関する識別子に合っている識別子。
semantics:
意味論:
This transaction is used to close the MIDCOM session on behalf of the agent. After session termination, the middlebox keeps all established policy rules until their lifetime expires or until an event occurs that causes the middlebox to terminate them.
このトランザクションは、エージェントを代表してMIDCOMセッションを終えるのに使用されます。 セッション終了の後に、彼らの寿命が期限が切れるか、またはmiddleboxがそれらを終えるイベントが起こるまで、middleboxは、すべての既定方針が規則であることを保ちます。
The middlebox always generates a successful reply. After sending the reply, the middlebox will not send any further messages to the agent within the current session. It also will not process any further request within this session that it received while processing the session termination request or that it receives later.
middleboxはいつもうまくいっている回答を生成します。 回答を送った後に、middleboxは現在のセッション中にどんなさらなるメッセージもエージェントに送らないでしょう。 また、それはこのセッション中のセッション終了要求を処理している間受信したか、または後で受信するというどんなさらなる要求も処理しないでしょう。
2.2.3. Asynchronous Session Termination (AST)
2.2.3. 非同期なセッション終了(AST)
transaction-name: asynchronous session termination
トランザクション名: 非同期なセッション終了
transaction-type: asynchronous
トランザクションタイプ: 非同期
transaction-compliance: mandatory
トランザクションコンプライアンス: 義務的
notification message type: Session Termination Notification (STN)
通知メッセージタイプ: セッション終了通知(STN)
reply-parameters (success only):
回答パラメタ(成功専用):
- termination reason: The reason why the session is terminated.
- 退職理由: セッションが終えられる理由。
Stiemerling, et al. Standards Track [Page 16] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[16ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
semantics:
意味論:
The middlebox may decide to terminate a MIDCOM session at any time. Before terminating the actual session, the middlebox generates an STN message and sends it to the agent. After sending the notification, the middlebox will not process any further request by the agent, even if it is already queued at the middlebox.
middleboxは、いつでもMIDCOMセッションを終えると決めるかもしれません。 実際のセッションを終える前に、middleboxはSTNメッセージを生成して、それをエージェントに送ります。 通知を送った後に、middleboxはエージェントによるどんなさらなる要求も処理しないでしょう、それがmiddleboxに既に列に並ばせられても。
After session termination, the middlebox keeps all established policy rules until their lifetime expires or until an event occurs for which the middlebox terminates them.
セッション終了の後に、彼らの寿命が期限が切れるか、またはmiddleboxがそれらを終えるイベントが起こるまで、middleboxは、すべての既定方針が規則であることを保ちます。
Unlike in other asynchronous transactions, no more than one notification is sent, because there is only one agent affected by the transaction.
他の非同期なトランザクションなどと異なって、1つ未満の通知を送ります、トランザクションで影響を受ける1人のエージェントしかいないので。
2.2.4. Session Termination by Interruption of Connection
2.2.4. 接続の中断によるセッション終了
If a MIDCOM session is based on an underlying network connection, the session can also be terminated by an interruption of this connection. If the middlebox detects this, it immediately terminates the session. The effect on established policy rules is the same as for the Asynchronous Session Termination.
また、MIDCOMセッションが基本的なネットワーク接続に基づいているなら、この接続の中断でセッションを終えることができます。 middleboxがこれを検出するなら、それはすぐに、セッションを終えます。 既定方針規則への効果はAsynchronous Session Terminationのように同じです。
2.2.5. Session State Machine
2.2.5. セッション州のマシン
A state machine illustrating the semantics of the session transactions is shown in Figure 2. The transaction abbreviations used can be found in the headings of the particular transaction section.
セッショントランザクションの意味論を例証する州のマシンは図2で見せられます。 特定の取引部に関する見出しで略語が使用したトランザクションを見つけることができます。
All sessions start in state CLOSED. If mutual authentication is already provided by other means, a successful SE transaction can cause a state transition to state OPEN. Otherwise, it causes a transition to state NOAUTH. From this state, a failed second SE transaction returns to state CLOSED. A successful SE transaction causes a transition to state OPEN. At any time, an AST transaction or a connection failure may occur, causing a transition to state CLOSED. A successful ST transaction from either NOAUTH or OPEN also causes a return to CLOSED. The parameters of the transactions are explained in Figure 2; the value mc=0 represents an empty middlebox challenge.
すべてのセッションが州のCLOSEDで始まります。 他の手段で既に互いの認証を提供するなら、うまくいっているSEトランザクションで、状態遷移はオープンを述べることができます。 さもなければ、それで、変遷はNOAUTHを述べます。 この状態から、2番目の失敗したSEトランザクションは戻って、CLOSEDを述べます。 うまくいっているSEトランザクションで、変遷はオープンを述べます。 いつでも、変遷がCLOSEDを述べることを引き起こして、ASTトランザクションか接続失敗が起こるかもしれません。 また、NOAUTHかオープンのどちらかからのうまくいっているSTトランザクションはCLOSEDへのリターンを引き起こします。 トランザクションのパラメタは図2で説明されます。 値のmc=0は空のmiddlebox挑戦を表します。
Stiemerling, et al. Standards Track [Page 17] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[17ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
mc = middlebox challenge SE/failure ma = middlebox authentication +-------+ ac = agent challenge | v aa = agent authentication +----------+ | CLOSED |----------------+ +----------+ | SE(mc!=0)/ | ^ ^ | success(ma,ac) SE(mc=0, | | | AST | aa=OK)/ | | | SE/failure v success | | | ST/success +----------+ | | +------------| NOAUTH | | | +----------+ | | AST | SE(mc=0, v | ST/success | aa=OK)/ +----------+ | success | OPEN |<---------------+ +----------+
middlebox挑戦のSE/故障mc=maはmiddlebox認証+と等しいです。-------エージェント+ ac=挑戦| エージェントaa=認証+に対して----------+ | 閉じられます。|----------------+ +----------+ | SE(mc!=0)/| ^ ^ | 成功(ma、ac)SE(mcは| | | 0、ASTと等しいです| aaはOKと等しい)/| | | SE/失敗対成功| | | /第成功+----------+ | | +------------| NOAUTH| | | +----------+ | | AST| SE(mcは0、vと等しいです| ST/成功| aaはOKと等しい)/+----------+ | 成功| 戸外| <、-、-、-、-、-、-、-、-、-、-、-、-、-、--+ +----------+
Figure 2: Session State Machine
図2: セッション州のマシン
2.3. Policy Rule Transactions
2.3. 政策ルールトランザクション
This section describes the semantics for transactions on policy rules. The following transactions are specified:
このセクションはトランザクションのために政策ルールで意味論について説明します。 以下のトランザクションは指定されます:
- Policy Reserve Rule (PRR) - Policy Enable Rule (PER) - Policy Rule Lifetime Change (RLC) - Policy Rule List (PRL) - Policy Rule Status (PRS) - Asynchronous Policy Rule Event (ARE)
- 責任準備金規則(PRR)--方針は規則(PER)--政策ルール生涯変化(RLC)--政策ルールリスト(PRL)--政策ルール状態(PRS)--非同期な政策ルールイベントを可能にします。(あります)
The first three transactions (PRR, PER, RLC) are configuration transactions initiated by the agent. The fourth and fifth (PRL, PRS) are monitoring transactions. The last one (ARE) is an asynchronous transaction. The PRL and PRS transactions do not have any effect on the policy rule state machine.
最初の3つのトランザクション(PRR、PER、RLC)がエージェントによって開始された構成トランザクションです。 4番目と5(PRL、PRS)番目はトランザクションをモニターしています。 最後の1つ(ある)は非同期なトランザクションです。 PRLとPRSトランザクションは政策ルール州のマシンにどんな影響も与えません。
Before any transaction can start, a valid MIDCOM session must be established.
どんなトランザクションも始まることができる前に、有効なMIDCOMセッションを確立しなければなりません。
Stiemerling, et al. Standards Track [Page 18] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[18ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
2.3.1. Configuration Transactions
2.3.1. 構成トランザクション
Policy rule transactions PER and RLC constitute the core of the MIDCOM protocol. Both are mandatory, and they serve for
政策ルールトランザクションのPERとRLCはMIDCOMプロトコルのコアを構成します。 両方が義務的です、そして、それらは役立ちます。
- configuring NAT bindings (PER) - configuring firewall pinholes (PER) - extending the lifetime of established policy rules (RLC) - deleting policy rules (RLC)
- 政策ルールを削除して、既定方針規則(RLC)の生涯を広げていて、ファイアウォールピンホール(PER)を構成して、NAT結合(PER)を構成します。(RLC)
Some cases require knowing in advance which IP address (and port number) would be chosen by NAT in a PER transaction. This information is required before sufficient information for performing a complete PER transaction is available (see example in section 4.2). For supporting such cases, the core transactions are extended by the Policy Reserve Rule (PRR) transaction serving for
いくつかのケースが、あらかじめどのIPアドレス(数を移植する)がPERトランザクションにおけるNATによって選ばれているかを知っているのを必要とします。 完全なPERトランザクションを実行するための十分な情報が利用可能になる(セクション4.2の例を見てください)前にこの情報が必要です。 そのような場合をサポートするのにおいて、コアトランザクションはPolicy Reserve Rule(PRR)トランザクション給仕で広げられます。
- reserving addresses and port numbers at NATs (PRR)
- NATsでアドレスとポートナンバーを予約します。(PRR)
2.3.2. Establishing Policy Rules
2.3.2. 制定方針規則
Both PRR and PER establish a policy rule. The action within the rule is 'reserve' if set by PRR and 'enable' if set by PER.
PRRとPERの両方が政策ルールを確立します。 PERによって設定されるならPRRと'可能にすること'によって設定されるなら、規則の中の動作は'蓄え'です。
The Policy Reserve Rule (PRR) transaction is used to establish an address reservation on neither side, one side, or both sides of the middlebox, depending on the middlebox configuration. The transaction returns the reserved IP addresses and the optional ranges of port numbers to the agent. No address binding or pinhole configuration is performed at the middlebox. Packet processing at the middlebox remains unchanged.
Policy Reserve Rule(PRR)トランザクションはどちらの側でのアドレスの予約、半面、またはmiddleboxの両側を証明するのに使用されます、middlebox構成によって。 トランザクションは予約されたIPアドレスと任意の範囲のポートナンバーをエージェントに返します。 どんなアドレス結合もピンホール構成もmiddleboxで実行されません。 middleboxでのパケット処理は変わりがありません。
On pure firewalls, the PRR transaction is successfully processed without any reservation, but the state transition of the MIDCOM protocol engine is exactly the same as on NATs.
純粋なファイアウォールに、PRRトランザクションは少しも予約なしで首尾よく処理されますが、MIDCOMプロトコルエンジンの状態遷移はまさにNATsと同じです。
On a traditional NAT (see [NAT-TRAD]), only an external address is reserved; on a twice-NAT, an internal and an external address are reserved. The reservation at a NAT is for required resources, such as IP addresses and port numbers, for future use. How the reservation is exactly done depends on the implementation of the NAT. In both cases, the reservation concerns either an IP address only or a combination of an IP address with a range of port numbers.
伝統的なNAT([NAT-TRAD]を見る)では、外部アドレスだけが予約されています。 2倍NATでは、内部のアドレスと外部のアドレスは予約されています。 NATにおける予約はIPアドレスやポートナンバーなどの必要なリソース、今後の使用のためのものです。 予約がまさにどう完了しているかはNATの実装によります。 どちらの場合も、予約はさまざまなポートナンバーでIPアドレスのIPアドレスだけか組み合わせのどちらかように関係があります。
The Policy Enable Rule (PER) transaction is used to establish a policy rule that affects packet processing at the middlebox. Depending on its input parameters, it may make use of the reservation established by a PRR transaction or create a new rule from scratch.
Policy Enable Rule(PER)トランザクションは、middleboxでパケット処理に影響する政策ルールを証明するのに使用されます。 入力パラメタによって、それは、PRRトランザクションによって確立された予約を利用するか、または最初から、新しい規則を作成するかもしれません。
Stiemerling, et al. Standards Track [Page 19] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[19ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
On a NAT, the enable action is interpreted as a bind action establishing bindings between internal and external addresses. At a firewall, the enable action is interpreted as one or more allow actions configuring pinholes. The number of allow actions depends on the parameters of the request and the implementation of the firewall.
動作を可能にしてください。NATに関して解釈する、ひもの動作として、内部の、そして、外部のアドレスの間の結合を確立しながら、解釈されます。 動作を可能にしてください。ファイアウォールで解釈する、1つ以上がピンホールを構成する動作を許容して、解釈されます。 動作を許容してください。数、要求のパラメタとファイアウォールの実装に依存します。
On a combined NAT/firewall, the enable action is interpreted as a combination of bind and allow actions.
結合したNAT/ファイアウォールに関して可能にする、動作はひもの組み合わせを解釈して、動作を許容することです。
The PRR transaction and the PER transaction are described in more detail in sections 2.3.8 and 2.3.9 below.
PRRトランザクションとPERトランザクションはその他の詳細コネセクション2.3.8と2.3.9未満で説明されます。
2.3.3. Maintaining Policy Rules and Policy Rule Groups
2.3.3. 政策ルールと政策ルールグループを維持します。
Each policy rule has a middlebox-unique identifier.
各政策ルールには、middleboxユニークな識別子があります。
Each policy rule has an owner. Access control to the policy rule is based on ownership (see section 2.1.5). Ownership of a policy rule does not change during lifetime of the policy rule.
各政策ルールには、所有者がいます。 政策ルールへのアクセスコントロールは所有権に基づいています(セクション2.1.5を見てください)。 政策ルールの所有権は政策ルールの生涯変化しません。
Each policy rule has an individual lifetime. If the policy rule lifetime expires, the policy rule will be terminated at the middlebox. Typically, the middlebox indicates termination of a policy rule by an ARE transaction. A Policy Rule Lifetime Change (RLC) transaction may extend the lifetime of the policy rule up to the limit specified by the middlebox at session setup. Also, an RLC transaction may be used for shortening a policy rule's lifetime or deleting a policy rule by requesting a lifetime of zero. (Please note that policy rule lifetimes may also be modified by the Group Lifetime Change (GLC) transaction.)
各政策ルールには、個々の寿命があります。 政策ルール寿命が期限が切れると、政策ルールはmiddleboxで終えられるでしょう。 通常、middleboxが政策ルールの終了を示す、トランザクションはそうです。 Policy Rule Lifetime Change(RLC)トランザクションは政策ルールの生涯をセッションセットアップでmiddleboxによって指定された限界まで広げるかもしれません。 また、RLCトランザクションは、方針規則を短くするのに使用されているのが、生涯ということであるかもしれませんかゼロの生涯を要求することによって、政策ルールを削除しています。 (また、政策ルール寿命はGroup Lifetime Change(GLC)トランザクションによって変更されるかもしれません。)
Each policy rule is a member of exactly one policy rule group. Group membership does not change during the lifetime of a policy rule. Selecting the group is part of the transaction establishing the policy rule. This transaction implicitly creates a new group if the agent does not specify one. The new group identifier is chosen by the middlebox. New members are added to an existing group if the agent's request designates one. A group only exists as long as it has member policy rules. As soon as all policies belonging to the group have reached the ends of their lifetimes, the group does not exist anymore.
各政策ルールはまさに1つの政策ルールグループのメンバーです。 グループ会員資格は政策ルールの生涯変化しません。 グループを選択するのは、政策ルールを確立するトランザクションの一部です。 エージェントが1つを指定しないなら、このトランザクションはそれとなく新しいグループを創設します。 新しいグループ識別子はmiddleboxによって選ばれています。 エージェントの要求が1つを指定するなら、新しいメンバーは既存のグループに追加されます。 それにメンバー政策ルールがある限り、グループは存在するだけです。 グループに属すすべての方針が彼らの生涯の端に達するとすぐに、グループはそれ以上存在しません。
Agents can explore the properties and status of all policy rules they are allowed to access by using the Policy Rule Status (PRS) transaction.
エージェントはPolicy Rule Status(PRS)トランザクションを使用することによってそれらがアクセスできるすべての政策ルールの特性と状態を探ることができます。
Stiemerling, et al. Standards Track [Page 20] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[20ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
2.3.4. Policy Events and Asynchronous Notifications
2.3.4. 方針イベントと非同期な通知
If a policy rule changes its state or if its remaining lifetime is changed in ways other than being decreased by time, then all agents that can access this policy rule and that participate in an open session with the middlebox are notified by the middlebox. If the state or lifetime change was requested explicitly by a request message, then the middlebox notifies the requesting agent by returning the corresponding reply. All other agents that can access the policy are notified by a Policy Rule Event Notification (REN) message.
政策ルールが状態を変えるか、または時間までに減少するのを除いた方法で残っている生涯を変えるなら、middleboxはこの政策ルールにアクセスできて、middleboxで公開審議に参加するすべてのエージェントに通知します。 状態か生涯変化が要求メッセージによって明らかに要求されたなら、対応する回答を返すことによって、middleboxは要求しているエージェントに通知します。 方針にアクセスできる他のすべてのエージェントがPolicy Rule Event Notification(REN)メッセージによって通知されます。
Note that a middlebox can serve multiple agents at the same time in different parallel sessions. Between these agents, the sets of policy rules that can be accessed by them may overlap. For example, there might be an agent that authenticates as administrator and that can access all policies of all agents. Or there could be a backup agent running a session in parallel to a main agent and authenticating itself as the same entity as the main agent.
middleboxが異なった平行なセッションのときに同時に複数のエージェントに役立つことができることに注意してください。 これらのエージェントの間では、それらがアクセスできる政策ルールのセットは重なるかもしれません。 例えば、管理者とそれがすべてのエージェントのすべての方針にアクセスできるので、それが認証するエージェントがいるかもしれません。 または、主なエージェントとそれ自体を認証するのに会議を運営するバックアップエージェントが主なエージェントと同じ実体として平行にいるかもしれません。
In case of a PER, PRR, or RLC transaction, the requesting agent receives a PER, PRR, or RLC reply, respectively. To all other agents that can access the created, modified, or terminated policy rule (and that participate in an open session with the middlebox), the middlebox sends a REN message carrying the policy rule identifier (PID) and the remaining lifetime of the policy rule.
PRR、PER、PRR、またはRLCトランザクションの場合には、要求しているエージェントがPERを受け取るか、またはRLCはそれぞれ返答します。 作成されたか、変更されたか、終えられた政策ルール(それはmiddleboxで公開審議に参加する)にアクセスできる他のすべてのエージェントに、middleboxはRENメッセージに政策ルール識別子(PID)と政策ルールの残っている生涯を運ばせます。
In case of a rule termination by lifetime truncation or other events not triggered by an agent, the middlebox sends a REN message to each agent that can access the particular policy rule and that participates in an open session with the middlebox. This ensures that an agent always knows the most recent state of all policy rules it can access.
エージェントによって引き起こされなかった生涯トランケーションか他のイベントによる規則終了の場合には、middleboxは特定の政策ルールにアクセスできて、middleboxで公開審議に参加する各エージェントにRENメッセージを送ります。 これが、エージェントがいつもそれがそうすることができるすべての政策ルールの最新の事情を知っているのを確実にする、アクセサリー
2.3.5. Address Tuples
2.3.5. アドレスTuples
Request and reply messages of the PRR, PER, and PRS transactions contain address specifications for IP and transport addresses. These parameters include
PRR、PER、およびPRSトランザクションに関する要求と応答メッセージはIPのためのアドレス指定と輸送アドレスを含んでいます。 パラメタが含むこれら
- IP version - IP address - IP address prefix length - transport protocol - port number - port parity - port range
- IPバージョン--IPアドレス--IPアドレス接頭語の長さ--トランスポート・プロトコル--ポートナンバー--ポートの同等--ポート範囲
Stiemerling, et al. Standards Track [Page 21] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[21ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
Additionally, the request message of PER and the reply message of PRS contain a direction of flow parameter. This direction of flow parameter indicates for UDP and IP the direction of packets traversing the middlebox. For 'inbound', the UDP packets are traversing from outside to inside; for 'outbound', from inside to outside. In both cases, the packets can traverse the middlebox only unidirectionally. A bidirectional flow is enabled through 'bidirectional' as direction of flow parameter. For TCP, the packet flow is always bidirectional, but the direction of the flow parameter is defined as
さらに、PERに関する要求メッセージとPRSに関する応答メッセージは流れパラメタの方向を含んでいます。 流れパラメタのこの方向はUDPとIPのためにmiddleboxを横断するパケットの方向を示します。 '本国行き'に関しては、UDPパケットは外部から内部まで横断される予定です。 内部から外部までの'外国行き'のために。 どちらの場合も、パケットは単方向だけ、middleboxを横断できます。 双方向の流れは流れパラメタの方向としての'双方向'を通って可能にされます。 TCPに関しては、パケット流動はいつも双方向ですが、流れパラメタの方向は定義されます。
- inbound: bidirectional TCP packet flow. First packet, with TCP SYN flag set and ACK flag not set, must arrive at the middlebox at the outside interface.
- 本国行き: 双方向のTCPパケット流動。 TCP SYN旗がセットして、ACK旗が設定されていなく、最初のパケットは外のインタフェースのmiddleboxに到着しなければなりません。
- outbound: bidirectional TCP packet flow. First packet, with TCP SYN flag set and ACK flag not set, must arrive at the middlebox at the inside interface.
- 外国行き: 双方向のTCPパケット流動。 TCP SYN旗がセットして、ACK旗が設定されていなく、最初のパケットは内面のインタフェースのmiddleboxに到着しなければなりません。
- bidirectional: bidirectional TCP packet flow. First packet, with TCP SYN flag set and ACK flag not set, may arrive at inside or outside interface.
- 双方向: 双方向のTCPパケット流動。 TCP SYN旗がセットして、ACK旗が設定されていなく、最初のパケットは内部において、または、インタフェースの外で到着するかもしれません。
We refer to the set of these parameters as an address tuple. An address tuple specifies either a communication endpoint at an internal or external device or allocated addresses at the middlebox. In this document, we distinguish four kinds of address tuples, as shown in Figure 3.
私たちはこれらのパラメタのセットをアドレスtupleと呼びます。 アドレスtupleはmiddleboxで内部の、または、外部のデバイスか割り当てられた住所のコミュニケーション終点を指定します。 本書では、私たちは図3に示されるように4種類のアドレスtuplesを区別します。
+----------+ +----------+ | internal | A0 A1 +-----------+ A2 A3 | external | | endpoint +----------+ middlebox +----------+ endpoint | +----------+ +-----------+ +----------+
+----------+ +----------+ | 内部| A0 A1+-----------+ A2 A3| 外部| | 終点+----------+ middlebox+----------+ 終点| +----------+ +-----------+ +----------+
Figure 3: Address Tuples A0 - A3
図3: アドレスTuples A0--A3
- A0 - internal endpoint: Address tuple A0 specifies a communication endpoint of a device within the internal network, with respect to the middlebox.
- A0--インターナル終点: アドレスtuple A0は内部のネットワークの中でmiddleboxに関してデバイスのコミュニケーション終点を指定します。
- A1 - middlebox inside address: Address tuple A1 specifies a virtual communication endpoint at the middlebox within the internal network. A1 is the destination address for packets passing from the internal endpoint to the middlebox and is the source for packets passing from the middlebox to the internal endpoint.
- A1--middleboxインサイドアドレス: アドレスtuple A1は内部のネットワークの中でmiddleboxで仮想のコミュニケーション終点を指定します。 A1はパケットのための内部の終点からmiddleboxまで終わる送付先アドレスであり、パケットのためのmiddleboxから内部の終点まで通るソースです。
Stiemerling, et al. Standards Track [Page 22] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[22ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
- A2 - middlebox outside address: Address tuple A2 specifies a virtual communication endpoint at the middlebox within the external network. A2 is the destination address for packets passing from the external endpoint to the middlebox and is the source for packets passing from the middlebox to the external endpoint.
- A2--middlebox外部アドレス: アドレスtuple A2は外部のネットワークの中でmiddleboxで仮想のコミュニケーション終点を指定します。 A2はパケットのための外部の終点からmiddleboxまで終わる送付先アドレスであり、パケットのためのmiddleboxから外部の終点まで通るソースです。
- A3 - external endpoint: Address tuple A3 specifies a communication endpoint of a device within the external network, with respect to the middlebox.
- A3--外部終点: アドレスtuple A3は外部のネットワークの中でmiddleboxに関してデバイスのコミュニケーション終点を指定します。
For a firewall, the inside and outside endpoints are identical to the corresponding external or internal endpoints, respectively. In this case, the installed policy rule sets the same value in A2 as in A0 (A0=A2) and sets the same value in A1 as in A3 (A1=A3).
ファイアウォールにおいて、内外面の終点は対応する外部の、または、内部の終点とそれぞれ同じです。 この場合、インストールされた政策ルールは、A0(A0=A2)のように同じ値をA2にはめ込んで、A3(A1=A3)のように同じ値をA1にはめ込みます。
For a traditional NAT, A2 is given a value different from that of A0, but the NAT binds them. As for the firewall, it is also as it is at a traditional NAT: A1 has the same value as A3.
伝統的なNATにおいて、A0についてそれと異なった値をA2に与えますが、NATはそれらを縛ります。 また、ファイアウォールに関して、伝統的なNATにあるとき、それは以下の通りです。 A1には、A3と同じ値があります。
For a twice-NAT, there are two bindings of address tuples: A1 and A2 are both assigned values by the NAT. The middlebox outside address A2 is bound to the internal endpoint A0, and the middlebox inside address A1 is bound to the external endpoint A3.
2倍NATのために、アドレスtuplesの2つの結合があります: A1とA2はNATによる両方の割り当てられた値です。 アドレスA2の外のmiddleboxは内部の終点A0に縛られます、そして、middleboxインサイドアドレスA1は外部の終点A3に縛られます。
2.3.6. Address Parameter Constraints
2.3.6. アドレスパラメタ規制
For transaction parameters belonging to an address tuple, some constraints exist that are common for all messages using them. Therefore, these constraints are summarized in the following and are not repeated again when describing the parameters in the transaction descriptions are presented.
アドレスtupleに属すトランザクションパラメタに関しては、いくつかのすべてのメッセージに、それらを使用することで一般的な規制が存在しています。 したがって、これらの規制は、以下にまとめられて、説明するとき、再び繰り返されないで、トランザクション記述におけるパラメタが提示されるということです。
The MIDCOM semantics defined in this document specifies the handling of IPv4 and IPv6 as network protocols, and of TCP and UDP (over IPv4 and IPv6) as transport protocols. The handling of any other transport protocol, e.g., Stream Control Transmission Protocol (SCTP), is not defined within the semantics but may be supported by concrete protocol specifications.
本書では定義されたMIDCOM意味論はトランスポート・プロトコルとしてネットワーク・プロトコルとしてのIPv4とIPv6、TCP、およびUDP(IPv4とIPv6の上の)の取り扱いを指定します。 いかなる他のトランスポート・プロトコルの取り扱い(例えば、Stream Control Transmissionプロトコル(SCTP))も、意味論の中で定義されませんが、具体的なプロトコル仕様でサポートされるかもしれません。
The IP version parameter has either the value 'IPv4' or 'IPv6'. In a policy rule, the value of the IP version parameter must be the same for address tuples A0 and A1, and for A2 and A3.
IPバージョンパラメタには、値の'IPv4'か'IPv6'のどちらかがあります。 政策ルールで、アドレスtuples A0とA1、A2、およびA3に、IPバージョンパラメタの値は同じであるに違いありません。
The value of the IP address parameter must conform with the specified IP version.
IPアドレスパラメタの値は指定されたIPバージョンに従わなければなりません。
Stiemerling, et al. Standards Track [Page 23] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[23ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
The IP address of an address tuple may be wildcarded. Whether IP address wildcarding is allowed or in which range it is allowed depends on the local policy of the middlebox; see also section 6, "Security Considerations". Wildcarding is specified by the IP address prefix length parameter of an address tuple. In line with the common use of a prefix length, this parameter indicates the number of high significant bits of the IP address that are fixed, while the remaining low significant bits of the IP address are wildcarded.
アドレスtupleのIPアドレスはwildcardedされるかもしれません。 IPアドレスwildcardingが許容されているかどうか、またはそれがどの範囲で許容されているかがmiddleboxのローカルの方針によります。 セクション6も、「セキュリティ問題」を見てください。 WildcardingはアドレスtupleのIPアドレス接頭語長さのパラメタによって指定されます。 接頭語の長さの一般の使用に沿って、このパラメタは固定IPアドレスの高い重要なビットの数を示します、IPアドレスの残っている低重要なビットがwildcardedされますが。
The value of the transport protocol parameter can be either 'TCP', 'UDP', or 'ANY'. If the transport protocol parameter has the value 'ANY', only IP headers are considered for packet handling in the middlebox -- i.e., the transport header is not considered. The values of the parameters port number, port range, and port parity are irrelevant if the protocol parameter is 'ANY'. In a policy rule, the value of the transport protocol parameter must be the same for all address tuples A0, A1, A2, and A3.
トランスポート・プロトコルパラメタの値は、'TCP'、'UDP'か'いずれも'のどちらかであることができます。 値が'少しも'トランスポート・プロトコルパラメタにあるなら、IPヘッダーだけがmiddleboxのパケット取り扱いのために考えられます--すなわち、輸送ヘッダーは考えられません。 パラメタポートナンバー、ポート範囲、およびポートの同等の値はプロトコルパラメタが'いずれか'であるなら無関係です。 政策ルールで、すべてのアドレスのtuples A0、A1、A2、およびA3に、トランスポート・プロトコルパラメタの値は同じであるに違いありません。
The value of the port number parameter is either zero or a positive integer. A positive integer specifies a concrete UDP or TCP port number. The value zero specifies port wildcarding for the protocol specified by the transport protocol parameter. If the port number parameter has the value zero, then the value of the port range parameter is irrelevant. Depending on the value of the transport protocol parameter, this parameter may truly refer to ports or may refer to an equivalent concept.
ポートナンバーパラメタの値は、ゼロか正の整数のどちらかです。 正の整数はコンクリートのUDPかTCPポートナンバーを指定します。 値ゼロはトランスポート・プロトコルパラメタによって指定されたプロトコルのためにwildcardingされるポートを指定します。 ポートナンバーパラメタに値ゼロがあるなら、ポート範囲パラメタの値は無関係です。 トランスポート・プロトコルパラメタの値によって、このパラメタは、本当に、ポートについて言及するか、または同等な概念を示すかもしれません。
The port parity parameter is differently used in the context of Policy Reserve Rules (PRRs) and Policy Enable Rules (PERs). In the context of a PRR, the value of the parameter may be 'odd', 'even', or 'any'. It specifies the parity of the first (lowest) reserved port number.
ポートパリティパラメタはPolicy Reserve Rules(PRRs)とPolicy Enable Rules(PER)の文脈で異なって使用されます。 PRRの文脈では、パラメタの値は、'変で'、'同等であるかもしれません'か、'いくらか'。 それは最初に(最も低い)の予約されたポートナンバーの同等を指定します。
In the context of a PER, the port parity parameter indicates to the middlebox whether port numbers allocated at the middlebox should have the same parity as the corresponding internal or external port numbers, respectively. In this context, the parameter has the value 'same' or 'any'. If the value is 'same', then the parity of the port number of A0 must be the same as the parity of the port number of A2, and the parity of the port number of A1 must be the same as the parity of the port number of A3. If the port parity parameter has the value 'any', then there are no constraints on the parity of any port number.
PERの文脈では、ポートパリティパラメタは、middleboxに割り当てられたポートナンバーがそれぞれ対応する内部の、または、外部のポートナンバーと同じ同等を持つべきであるかどうかをmiddleboxに示します。 このような関係においては、パラメタは'同じ'に値を持っているか、'いくらか'。 値が'同じである'なら、A0のポートナンバーの同等はA2のポートナンバーの同等と同じであるに違いありません、そして、A1のポートナンバーの同等はA3のポートナンバーの同等と同じであるに違いありません。 ポートパリティパラメタに値があるなら、'いくらか'規制が全くどんなポートナンバーの同等にもありません。
The port range parameter specifies a number of consecutive port numbers. Its value is a positive integer. Like the port number parameter, this parameter defines a set of consecutive port numbers
ポート範囲パラメタは多くの連続したポートナンバーを指定します。 値は正の整数です。 ポートナンバーパラメタのように、このパラメタは1セットの連続したポートナンバーを定義します。
Stiemerling, et al. Standards Track [Page 24] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[24ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
starting with the port number specified by the port number parameter as the lowest port number and having as many elements as specified by the port range parameter. A value of 1 specifies a single port number. The port range parameter must have the same value for each address tuple A0, A1, A2, and A3.
最も低いポートナンバーとしてポートナンバーパラメタによって指定されたポートナンバーから始まって、ポート範囲パラメタによって指定されるのと同じくらい多くの要素を持っています。 1の値はただ一つのポートナンバーを指定します。 ポート範囲パラメタには、各アドレスのtuple A0、A1、A2、およびA3のための同じ値がなければなりません。
A single policy rule P containing a port range value greater than one is equivalent to a set of policy rules containing a number n of policies P_1, P_2, ..., P_n where n equals the value of the port range parameter. Each policy rule P_1, P_2, ..., P_n has a port range parameter value of 1. Policy rule P_1 contains a set of address tuples A0_1, A1_1, A2_1, and A3_1, each of which contains the first port number of the respective address tuples in P; policy rule P_2 contains a set of address tuples A0_2, A1_2, A2_2, and A3_2, each of which contains the second port number of the respective address tuples in P; and so on.
ポート範囲価値1以上を含むただ一つの政策ルールPは方針P_1、P_2のNo.nを含む1セットの政策ルールに同等です…, nがポート範囲パラメタの値と等しいP。 各政策ルールP_1、P_2…, Pには、1のポート範囲パラメタ価値があります。 政策ルールP_1は1セットのアドレスtuples A0_1、A1_1、A2_1、およびA3_1を含んでいます。それはそれぞれPにおける、それぞれのアドレスtuplesの最初のポートナンバーを含みます。 政策ルールP_2は1セットのアドレスtuples A0_2、A1_2、A2_2、およびA3_2を含んでいます。それはそれぞれPにおける、それぞれのアドレスtuplesの2番目のポートナンバーを含みます。 など。
2.3.7. Interface-Specific Policy Rules
2.3.7. インタフェース特有の方針規則
Usually, agents request policy rules with the knowledge of A0 and A3 only, i.e., the address tuples (see section 2.3.5). But in very special cases, agents may need to select the interfaces to which the requested policy rule is bound. Generally, the middlebox is careful about choosing the right interfaces when reserving or enabling a policy rule, as it has the overall knowledge about its configuration. For agents that want to select the interfaces, optional parameters are included in the Policy Reserve Rule (PRR) and Policy Enable Rule (PER) transactions. These parameters are called
通常、エージェントはA0とすなわち、A3だけ、アドレスtuplesに関する知識で政策ルールを要求します(セクション2.3.5を見てください)。 しかし、非常に特別な場合では、エージェントは、要求された政策ルールが制限されているインタフェースを選択する必要があるかもしれません。 政策ルールを予約するか、または可能にするとき、一般に、middleboxは正しいインタフェースを選ぶことに関して慎重です、それに構成に関する総合的な知識があるとき。 インタフェースを選択したがっているエージェントに関しては、任意のパラメタはPolicy Reserve Rule(PRR)とPolicy Enable Rule(PER)トランザクションに含まれています。 これらのパラメタは呼ばれます。
- inside interface: The selected interface at the inside of the middlebox -- i.e., in the private or protected address realm.
- 中では、連結してください: すなわち、middleboxの内部、個人的であるか保護されたアドレス分野の選択されたインタフェース。
- outside interface: The selected interface at the outside of the middlebox -- i.e., in the public address realm.
- 外では、連結してください: middleboxの外部の選択されたインタフェース--すなわち、公衆では、分野に演説してください。
The Policy Rule Status (PRS) transactions include these optional parameters in their replies when they are supported.
それらがサポートされるとき、Policy Rule Status(PRS)トランザクションは彼らの回答にこれらの任意のパラメタを含んでいます。
Agents can learn at session startup whether interface-specific policy rules are supported by the middlebox, by checking the middlebox capabilities (see section 2.1.6).
エージェントは、セッション始動でインタフェース特有の方針規則がmiddleboxによってサポートされるかどうか学ぶことができます、middlebox能力をチェックすることによって(セクション2.1.6を見てください)。
2.3.8. Policy Reserve Rule (PRR)
2.3.8. 責任準備金規則(PRR)
transaction-name: policy reserve rule
トランザクション名: 責任準備金規則
transaction-type: configuration
トランザクションタイプ: 構成
Stiemerling, et al. Standards Track [Page 25] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[25ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
transaction-compliance: mandatory
トランザクションコンプライアンス: 義務的
request-parameters:
要求パラメタ:
- request identifier: An agent-unique identifier for matching corresponding request and reply at the agent.
- 識別子を要求してください: エージェントで対応する要求と回答に合うためのエージェントユニークな識別子。
- group identifier: A reference to the group of which the policy reserve rule should be a member. As indicated in section 2.3.3, if this value is not supplied, the middlebox assigns a new group for this policy reserve rule.
- 識別子を分類してください: 責任準備金規則がメンバーであるべきであるグループの参照。 セクション2.3.3にみられるように、この値が供給されないなら、middleboxはこの責任準備金規則のために新しいグループを割り当てます。
- service: The requested NAT service of the middlebox. Allowed values are 'traditional' or 'twice'.
- サービス: middleboxの要求されたNATサービス。 許容値は'伝統的である'か、'二度'。
- internal IP version: Requested IP version at the inside of the middlebox; see section 2.3.5.
- 内部のIPバージョン: middleboxの内部の要求されたIPバージョン。 セクション2.3.5を見てください。
- internal IP address: The IP address of the internal communication endpoint (A0 in Figure 3); see section 2.3.5.
- 内部のIPアドレス: 内部のコミュニケーション終点(図3のA0)のIPアドレス。 セクション2.3.5を見てください。
- internal port number: The port number of the internal communication endpoint (A0 in Figure 3); see section 2.3.5.
- 内部のポートナンバー: 内部のコミュニケーション終点(図3のA0)のポートナンバー。 セクション2.3.5を見てください。
- inside interface (optional): Interface at the inside of the middlebox; see section 2.3.7.
- 中では、連結してください(任意の): middleboxの内部で連結してください。 セクション2.3.7を見てください。
- external IP version: Requested IP version at the outside of the middlebox; see section 2.3.5.
- 外部のIPバージョン: middleboxの外部の要求されたIPバージョン。 セクション2.3.5を見てください。
- outside interface (optional): Interface at the outside of the middlebox; see section 2.3.7.
- 外では、連結してください(任意の): middleboxの外部で連結してください。 セクション2.3.7を見てください。
- transport protocol: See section 2.3.5.
- トランスポート・プロトコル: セクション2.3.5を見てください。
- port range: The number of consecutive port numbers to be reserved; see section 2.3.5.
- 範囲を移植してください: 予約されるべき連続したポートナンバーの数。 セクション2.3.5を見てください。
- port parity: The requested parity of the first (lowest) port number to be reserved; allowed values for this parameter are 'odd', 'even', and 'any'. See also section 2.3.5.
- 同等を移植してください: 予約されるべき最初(最も低い)のポートナンバーの要求された同等。 このパラメタのための許容値は、'変で'、'同等です'、そして、'いくらか'。 また、セクション2.3.5を見てください。
- policy rule lifetime: A lifetime proposal to the middlebox for the requested policy rule.
- 政策ルール生涯: 要求された政策ルールのためのmiddleboxへの生涯提案。
Stiemerling, et al. Standards Track [Page 26] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[26ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
reply-parameters (success):
回答パラメタ(成功):
- request identifier: An identifier matching the identifier of the request.
- 識別子を要求してください: 要求に関する識別子に合っている識別子。
- policy rule identifier: A middlebox-unique policy rule identifier. It is assigned by the middlebox and used as policy rule handle in further policy rule transactions, particularly to refer to the policy reserve rule in a subsequent PER transaction.
- 政策ルール識別子: middleboxユニークな政策ルール識別子。 それは、特にその後のPERトランザクションにおける責任準備金規則を示すのにさらなる政策ルールトランザクションにmiddleboxによって割り当てられて、政策ルールハンドルとして使用されます。
- group identifier: A reference to the group of which the policy reserve rule is a member.
- 識別子を分類してください: 責任準備金規則がメンバーであるグループの参照。
- reserved inside IP address: The reserved IPv4 or IPv6 address on the internal side of the middlebox. For an outbound flow, this will be the destination to which the internal endpoint sends its packets (A1 in Figure 3). For an inbound flow, it will be the apparent source address of the packets as forwarded to the internal endpoint (A0 in Figure 3). The middlebox reserves and reports an internal address only in the case where twice-NAT is in effect. Otherwise, an empty value for the addresses indicates that no internal reservation was made. See also section 2.3.5.
- 予約された内面のIPアドレス: middleboxの内部の側面の上の予約されたIPv4かIPv6アドレス。 外国行きの流れのために、これは内部の終点がパケット(図3のA1)を送る目的地になるでしょう。 本国行きの流れのために、それは内部の終点(図3のA0)に送るようにパケットの仮想点音源アドレスになるでしょう。 middleboxは2倍NATが有効である場合だけで内部のアドレスを予約して、報告します。 さもなければ、アドレスのための空の値は、どんな内部の予約もしなかったのを示します。 また、セクション2.3.5を見てください。
- reserved inside port number: See section 2.3.5.
- 予約された内面のポートナンバー: セクション2.3.5を見てください。
- reserved outside IP address: The reserved IPv4 or IPv6 address on the external side of the middlebox. For an inbound flow, this will be the destination to which the external endpoint sends its packets (A2 in Figure 3). For an outbound flow, it will be the apparent source address of the packets as forwarded to the external endpoint (A3 in Figure 3). If the middlebox is configured as a pure firewall, an empty value for the addresses indicates that no external reservation was made. See also section 2.3.5.
- 予約された外のIPアドレス: middleboxの外部の側面の上の予約されたIPv4かIPv6アドレス。 本国行きの流れのために、これは外部の終点がパケット(図3のA2)を送る目的地になるでしょう。 外国行きの流れのために、それは外部の終点(図3のA3)に送るようにパケットの仮想点音源アドレスになるでしょう。 middleboxが純粋なファイアウォールとして構成されるなら、アドレスのための空の値は、どんな外部の予約もしなかったのを示します。 また、セクション2.3.5を見てください。
- reserved outside port number: See section 2.3.5.
- 予約された外のポートナンバー: セクション2.3.5を見てください。
- policy rule lifetime: The policy rule lifetime granted by the middlebox, after which the reservation will be revoked if it has not been replaced already by a policy enable rule in a PER transaction.
- 政策ルール生涯: それが既に方針に取り替えられていないなら、寿命が予約が取り消されるmiddleboxで与えた政策ルールはPERトランザクションにおける規則を可能にします。
Stiemerling, et al. Standards Track [Page 27] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[27ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
failure reason:
失敗理由:
- agent not authorized for this transaction - agent not authorized to add members to this group - lack of IP addresses - lack of port numbers - lack of resources - specified inside/outside interface does not exist - specified inside/outside interface not available for specified service
- このグループ--IPアドレスの不足--ポートナンバー--財源不足--指定された内部/外部の不足へのメンバーが連結すると言い足すのは権限を与えられなかったエージェントが存在しないというこのトランザクションのために権限を与えられなかったエージェントが指定されたサービスに利用可能でない内面の、または、外のインタフェースを指定しました。
notification message type: Policy Rule Event Notification (REN)
通知メッセージタイプ: 政策ルールイベント通知(REN)
semantics:
意味論:
The agent can use this transaction type to reserve an IP address or a combination of IP address, transport type, port number, and port range at neither side, one side, or both sides of the middlebox as required to support the enabling of a flow. Typically, the PRR will be used in scenarios where it is required to perform such a reservation before sufficient parameters for a complete policy enable rule transaction are available. See section 4.2 for an example.
エージェントがIPアドレスを予約するのにこのトランザクションタイプを使用できますか、またはIPアドレスの組み合わせ、輸送タイプ、ポートナンバー、およびポートは、流れを可能にすることをサポートするために必要に応じてどちらの側、半面かmiddleboxの両側で及びます。 通常、PRRはそれが完全な方針が規則トランザクションを可能にするので十分なパラメタが利用可能になる前にそのような予約を実行するのに必要であるシナリオで使用されるでしょう。 例に関してセクション4.2を見てください。
When receiving the request, the middlebox determines how many address (and port) reservations are required based on its configuration. If it provides only packet filter services, it does not perform any reservation and returns empty values for the reserved inside and outside IP addresses and port numbers. If it is configured for twice-NAT, it reserves both inside and outside IP addresses (and an optional range of port numbers) and returns them. Otherwise, it reserves and returns an outside IP address (and an optional range of port numbers) and returns empty values for the reserved inside address and port range.
要求を受け取るとき、middleboxは、いくつのアドレス(そして、ポート)の予約が構成に基づいて必要であるかを決定します。 パケットフィルタサービスだけを提供するなら、それは、内外面の予約されたIPアドレスとポートナンバーのためにどんな予約も実行しないで、空の値を返します。 2倍NATのために構成されるなら、それは、ともに内外面のIPアドレス(そして、任意の範囲のポートナンバー)を予約して、それらを返します。 さもなければ、外のIPアドレス(そして、任意の範囲のポートナンバー)を予約して、返します、そして、リターンは予約されたインサイドアドレスとポート範囲への値を空にします。
The A0 parameter (inside IP address version, inside IP address, and inside port number) can be used by the middlebox to determine the correct NAT mapping and thus A2 if necessary. Once a PRR transaction has reserved an outside address (A2) for an internal endpoint (A0) at the middlebox, the middlebox must ensure that this reserved A2 is available in any subsequent PER and PRR transactions.
middleboxは、必要なら、正しいNATマッピングとその結果A2を決定するのに、A0パラメタ(IPアドレスバージョン、IPアドレス、およびポートナンバーにおける)を使用できます。 PRRトランザクションがmiddleboxでいったん、内部の終点への外のアドレス(A2)(A0)を予約すると、middleboxは、この予約されたA2がどんなその後のPERとPRRトランザクションでも利用可能であることを確実にしなければなりません。
For middleboxes supporting interface-specific policy rules, as defined in section 2.3.7, the optional inside and outside interface parameters must both be included in the request, or neither of them should be included. In the presence of these parameters, the middlebox uses the outside interface parameter to
セクション2.3.7で定義されるようにインタフェース特有の方針規則をサポートするmiddleboxesに関しては要求にともに内外面の任意のインタフェース・パラメータを含むべきであってはいけない、さもなければ、それらのどちらも含むべきではありません。 これらのパラメタ、外部がパラメタを連結するmiddlebox用途があるとき
Stiemerling, et al. Standards Track [Page 28] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[28ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
select the interface at which the outside address tuple (outside IP address and port number) is reserved, and the inside interface parameter to select the interface at which the inside address tuple (inside IP address and port number) is reserved. Without the presence of these parameters, the middlebox selects the particular interfaces based on its internal configuration.
外のアドレスtuple(IPアドレスとポートナンバーの外における)が予約されているインタフェース、および内面のインタフェース・パラメータを選択して、インサイドアドレスtuple(IPアドレスとポートナンバーにおける)が予約されているインタフェースを選択してください。 これらのパラメタの存在がなければ、middleboxは内部の構成に基づく特定のインタフェースを選択します。
If there is a lack of resources, such as available IP addresses, port numbers, or storage for further policy rules, then the reservation fails, and an appropriate failure reply is generated.
次に、予約は失敗します、そして、利用可能なIPアドレスなどの財源不足があれば、さらなる政策ルールのために数、またはストレージを移植してください、そして、適切な失敗回答は発生しています。
If a non-existing policy rule group was specified, or if an existing policy rule group was specified that is not owned by the requesting agent, then no new policy rule is established, and an appropriate failure reply is generated.
非既存の政策ルールグループが指定されたか、または要求しているエージェントによって所有されていない既存の政策ルールグループが指定されたなら、新しい政策規則は全く確立されません、そして、適切な失敗回答は発生しています。
In case of success, this transaction creates a new policy reserve rule. If an already existing policy rule group is specified, then the new policy rule becomes a member of it. If no policy group is specified, a new group is created with the new policy rule as its only member. The middlebox generates a middlebox-unique identifier for the new policy rule. The owner of the new policy rule is the authenticated agent that sent the request. The middlebox chooses a lifetime value that is greater than zero and less than or equal to the minimum of the requested value and the maximum lifetime specified by the middlebox at session startup, i.e.,
成功の場合には、このトランザクションは新しい政策蓄えの規則を作成します。 既に既存の政策ルールグループが指定されるなら、新しい政策規則はそれのメンバーになります。 方針グループが全く指定されないなら、新しいグループは唯一のメンバーとして新しい政策規則で創設されます。 middleboxは新しい政策規則のためのmiddleboxユニークな識別子を生成します。 新しい政策規則の所有者は要求を送った認証されたエージェントです。 middleboxはすなわち、ゼロと要求された値と最大の生涯の、より最小限がセッション始動でmiddleboxで指定したより大きい生涯値を選びます。
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
0 <はMINIMUMと等しいのを_を<に与えるltと等しいです。(_が要求したlt、lt_最大)
where - lt_granted is the lifetime actually granted by the middlebox - lt_requested is the lifetime the agent requested - lt_maximum is the maximum lifetime specified at session setup
どこ--_が与えたltは実際にmiddleboxによって与えられた生涯です--_が要求したltはエージェントが要求した生涯です--lt_最大はセッションセットアップで指定された最大の生涯であるか。
A middlebox with NAT capability always reserves a middlebox external address tuple (A2) in response to a PRR request. In the special case of a combined twice-NAT/NAT middlebox, the agent can request only NAT service or twice-NAT service by choosing the service parameter 'traditional' or 'twice'. An agent that does not have any preference chooses 'twice'. The 'traditional' value should only be used to select traditional NAT service at middleboxes offering both traditional NAT and twice-NAT. In the 'twice' case, the combined twice-NAT/NAT middlebox reserves A2 and A1; the 'traditional' case results in a reservation of A2 only. An agent must always use the PRR transaction for choosing NAT only
NAT能力があるmiddleboxはいつもPRR要求に対応してmiddlebox外部アドレスtuple(A2)を予約します。 結合した2倍NAT/NAT middleboxの特別な場合では、エージェントは'伝統的に'サービスパラメタを選ぶことによって、NATサービスか2倍NATサービスしか要求できませんか、'二度'。 少しの好みも持っていないエージェントは'二度'選びます。 '伝統的な'値は、伝統的なNATと2倍NATの両方を提供するmiddleboxesで伝統的なNATサービスを選択するのに使用されるだけであるべきです。 '2倍'場合では、結合した2倍NAT/NAT middleboxはA2とA1を予約します。 '伝統的な'ケースはA2だけの予約をもたらします。 エージェントは、NATだけを選ぶのにいつもPRRトランザクションを使用しなければなりません。
Stiemerling, et al. Standards Track [Page 29] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[29ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
or twice-NAT service in the special case of a combined twice- NAT/NAT middlebox. A firewall middlebox ignores this parameter.
または、aの特別な場合における2倍NATサービスは2倍NAT/NAT middleboxを結合しました。 ファイアウォールmiddleboxはこのパラメタを無視します。
If the protocol identifier is 'ANY', then the middlebox reserves available inside and/or outside IP address(es) only. The reserved address(es) are returned to the agent. In this case, the request-parameters "port range" and "port parity" as well as the reply-parameters "inside port number" and "outside port number" are irrelevant.
プロトコル識別子が'いずれか'であるなら、IP IPの外で利用可能なmiddlebox蓄えは(es)だけ、を扱います。 予約されたアドレス(es)をエージェントに返します。 この場合、回答パラメタ「ポートナンバー」と「ポートナンバー」と同様に「範囲を移植し」て、「同等を移植する」という要求パラメタは無関係です。
If the protocol identifier is 'UDP' or 'TCP', then a combination of an IP address and a consecutive sequence of port numbers, starting with the specified parity, is reserved, on neither side, one side, or both sides of the middlebox, as appropriate. The IP address(es) and the first (lowest) reserved port number(s) of the consecutive sequence are returned to the agent. (This also applies to other protocols supporting ports or the equivalent.)
プロトコル識別子が'UDP'か'TCP'であるなら、指定された同等から始まって、IPアドレスの組み合わせとポートナンバーの連続した系列はどちらの側、半面かmiddleboxの両側に控えられます、適宜。 連続した系列のIPアドレス(es)と最初に(最も低い)の予約されたポートナンバーはエージェントに返されます。 (また、これはポートを支える他のプロトコルか同等物に適用されます。)
After a new policy reserve rule is successfully established and the reply message has been sent to the requesting agent, the middlebox checks whether there are other authenticated agents participating in open sessions, which can access the new policy rule. If the middlebox finds one or more of these agents, then it sends a REN message reporting the new policy rule to each of them.
首尾よく新しい政策蓄えの規則を確立して、要求しているエージェントに応答メッセージを送った後に、middleboxは、新しい政策規則にアクセスできる公開審議に参加する他の認証されたエージェントがいるかどうかチェックします。 middleboxがこれらのエージェントのより多くのひとりを見つけるなら、それで、RENメッセージは新しい政策規則をそれぞれの彼らに報告します。
MIDCOM agents use the policy enable rule (PER) transaction to enable policy reserve rules that have been established beforehand by a policy reserve rule (PRR) transaction. See also section 2.3.2.
方針が可能にするMIDCOMエージェント使用は、あらかじめ責任準備金規則(PRR)トランザクションによって確立された責任準備金規則を可能にするために(PER)トランザクションを統治します。 また、セクション2.3.2を見てください。
2.3.9. Policy Enable Rule (PER)
2.3.9. 方針は規則を可能にします。(PER)
transaction-name: policy enable rule
トランザクション名: 方針は規則を可能にします。
transaction-type: configuration
トランザクションタイプ: 構成
transaction-compliance: mandatory
トランザクションコンプライアンス: 義務的
request-parameters:
要求パラメタ:
- request identifier: An agent-unique identifier for matching corresponding request and reply at the agent.
- 識別子を要求してください: エージェントで対応する要求と回答に合うためのエージェントユニークな識別子。
- policy reserve rule identifier: A reference to an already existing policy reserve rule created by a PRR transaction. The reference may be empty, in which case the middlebox must assign any necessary addresses and port numbers within this PER transaction. If it is not empty, then the following request parameters are irrelevant: group identifier, transport protocol,
- 責任準備金規則識別子: PRRトランザクションによって作成された既に既存の責任準備金規則の参照。 参照が空であるかもしれない、その場合、middleboxはこのPERトランザクションの中でどんな必要なアドレスとポートナンバーも割り当てなければなりません。 それが空でないなら、以下は、パラメタが無関係であるよう要求します: 識別子、トランスポート・プロトコルを分類してください。
Stiemerling, et al. Standards Track [Page 30] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[30ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
port range, port parity, internal IP version, external IP version.
ポート範囲、ポートの同等、内部のIPバージョン、外部のIPバージョン。
- group identifier: A reference to the group of which the policy enable rule should be a member. As indicated in section 2.3.3, if this value is not supplied, the middlebox assigns a new group for this policy reserve rule.
- 識別子を分類してください: 方針が規則を可能にするグループの参照はメンバーであるべきです。 セクション2.3.3にみられるように、この値が供給されないなら、middleboxはこの責任準備金規則のために新しいグループを割り当てます。
- transport protocol: See section 2.3.5.
- トランスポート・プロトコル: セクション2.3.5を見てください。
- port range: The number of consecutive port numbers to be reserved; see section 2.3.5.
- 範囲を移植してください: 予約されるべき連続したポートナンバーの数。 セクション2.3.5を見てください。
- port parity: The requested parity of the port number(s) to be mapped. Allowed values of this parameter are 'same' and 'any'. See also section 2.3.5.
- 同等を移植してください: 写像するべきポートナンバーの要求された同等。 このパラメタの許容値は'同じです'、そして、'いくらか'。 また、セクション2.3.5を見てください。
- direction of flow: This parameter specifies the direction of enabled communication, either 'inbound', 'outbound', or 'bidirectional'.
- 流れの方向: このパラメタは'本国行き'と、'外国行き'の、または、'双方向'の可能にされたコミュニケーションの方向を指定します。
- internal IP version: Requested IP version at the inside of the middlebox; see section 2.3.5.
- 内部のIPバージョン: middleboxの内部の要求されたIPバージョン。 セクション2.3.5を見てください。
- internal IP address: The IP address of the internal communication endpoint (A0 in Figure 3); see section 2.3.5.
- 内部のIPアドレス: 内部のコミュニケーション終点(図3のA0)のIPアドレス。 セクション2.3.5を見てください。
- internal port number: The port number of the internal communication endpoint (A0 in Figure 3); see section 2.3.5.
- 内部のポートナンバー: 内部のコミュニケーション終点(図3のA0)のポートナンバー。 セクション2.3.5を見てください。
- inside interface (optional): Interface at the inside of the middlebox; see section 2.3.7.
- 中では、連結してください(任意の): middleboxの内部で連結してください。 セクション2.3.7を見てください。
- external IP version: Requested IP version at the outside of the middlebox; see section 2.3.5.
- 外部のIPバージョン: middleboxの外部の要求されたIPバージョン。 セクション2.3.5を見てください。
- external IP address: The IP address of the external communication endpoint (A3 in Figure 3); see section 2.3.5.
- 外部のIPアドレス: 外部コミュニケーション終点(図3のA3)のIPアドレス。 セクション2.3.5を見てください。
- external port number: The port number of the external communication endpoint (A3 in Figure 3), see section 2.3.5.
- 外部のポートナンバー: 外部コミュニケーション終点(図3のA3)の数を移植してください、そして、.5にセクション2.3を見てください。
- outside interface (optional): Interface at the outside of the middlebox; see section 2.3.7.
- 外では、連結してください(任意の): middleboxの外部で連結してください。 セクション2.3.7を見てください。
- policy rule lifetime: A lifetime proposal to the middlebox for the requested policy rule.
- 政策ルール生涯: 要求された政策ルールのためのmiddleboxへの生涯提案。
Stiemerling, et al. Standards Track [Page 31] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[31ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
reply-parameters (success):
回答パラメタ(成功):
- request identifier: An identifier matching the identifier of the request.
- 識別子を要求してください: 要求に関する識別子に合っている識別子。
- policy rule identifier: A middlebox-unique policy rule identifier. It is assigned by the middlebox and used as policy rule handle in further policy rule transactions. If a policy reserve rule identifier was provided in the request, then the returned policy rule identifier has the same value.
- 政策ルール識別子: middleboxユニークな政策ルール識別子。 それは、さらなる政策ルールトランザクションにmiddleboxによって割り当てられて、政策ルールハンドルとして使用されます。 責任準備金規則識別子を要求に提供したなら、返された政策ルール識別子には、同じ値があります。
- group identifier: A reference to the group of which the policy enable rule is a member. If a policy reserve rule identifier was provided in the request, then this parameter identifies the group of which the policy reserve rule was a member.
- 識別子を分類してください: 方針が規則を可能にするグループの参照はメンバーです。 責任準備金規則識別子を要求に提供したなら、このパラメタは責任準備金規則がメンバーであったグループを特定します。
- inside IP address: The IP address provided at the inside of the middlebox (A1 in Figure 3). In case of a twice-NAT, this parameter will be an internal IP address reserved at the inside of the middlebox. In all other cases, this reply-parameter will be identical with the external IP address passed with the request. If the policy reserve rule identifier parameter was supplied in the request and the respective PRR transaction reserved an inside IP address, then the inside IP address provided in the PER response will be the identical value to that returned by the response to the PRR request. See also section 2.3.5.
- 内面のIPアドレス: IPアドレスはmiddlebox(図3のA1)の内部で提供されました。 2倍NATの場合には、このパラメタはmiddleboxの内部で予約された内部のIPアドレスになるでしょう。 他のすべての場合では、この回答パラメタは要求で通過される外部のIPアドレスと同じになるでしょう。 要求で責任準備金規則識別子パラメタを提供して、それぞれのPRRトランザクションが内面のIPアドレスを予約したなら、PER応答に提供された内面のIPアドレスはPRR要求への応答で返されたそれへの同じ値になるでしょう。 また、セクション2.3.5を見てください。
- inside port number: The internal port number provided at the inside of the middlebox (A1 in Figure 3); see also section 2.3.5.
- 内面のポートナンバー: 内部のポートナンバーはmiddlebox(図3のA1)の内部で提供されました。 また、セクション2.3.5を見てください。
- outside IP address: The external IP address provided at the outside of the middlebox (A2 in Figure 3). In case of a pure firewall, this parameter will be identical with the internal IP address passed with the request. In all other cases, this reply-parameter will be an external IP address reserved at the outside of the middlebox. See also section 2.3.5.
- 外のIPアドレス: 外部のIPアドレスはmiddlebox(図3のA2)の外部で提供されました。 純粋なファイアウォールの場合には、このパラメタは要求で通過される内部のIPアドレスと同じになるでしょう。 他のすべての場合では、この回答パラメタはmiddleboxの外部で予約された外部のIPアドレスになるでしょう。 また、セクション2.3.5を見てください。
- outside port number: The external port number provided at the outside of the NAT (A2 in Figure 3); see section 2.3.5..
- 外のポートナンバー: 外部のポートナンバーはNAT(図3のA2)の外部で提供されました。 セクション2.3.5を見てください。
- policy rule lifetime: The policy rule lifetime granted by the middlebox.
- 政策ルール生涯: middleboxによって与えられた政策ルール生涯。
failure reason:
失敗理由:
- agent not authorized for this transaction
- このトランザクションのために権限を与えられなかったエージェント
Stiemerling, et al. Standards Track [Page 32] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[32ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
- agent not authorized to add members to this group - no such policy reserve rule - agent not authorized to replace this policy reserve rule - conflict with already existing policy rule (e.g., the same internal address-port is being mapped to different outside address-port pairs) - lack of IP addresses - lack of port numbers - lack of resources - no internal IP wildcarding allowed - no external IP wildcarding allowed - specified inside/outside interface does not exist - specified inside/outside interface not available for specified service - reserved A0 to requested A0 mismatch
- このグループにメンバーを追加するのは権限を与えられなかったエージェント--そのような責任準備金規則でない--この責任準備金規則を置き換えるのは権限を与えられなかったエージェント--既に既存の政策ルール(例えば同じ内部のアドレス港は異なった外部のアドレス港の組に写像されている)との闘争--IPの不足; 指定された内面の、または、外のインタフェースが存在していないという外部のIP wildcardingでないのが許容したアドレス(内部のIP wildcardingでないのが許容したポートナンバー(財源不足)の不足)は指定されたサービスに利用可能でない内面の、または、外のインタフェースを指定しました--要求されたA0ミスマッチへのA0を予約します。
notification message type: Policy Rule Event Notification (REN)
通知メッセージタイプ: 政策ルールイベント通知(REN)
semantics:
意味論:
This transaction can be used by an agent to enable communication between an internal endpoint and an external endpoint independently of the type of middlebox (NAT, NAPT, firewall, NAT- PT, combined devices), for unidirectional or bidirectional traffic.
エージェントはmiddleboxのタイプの如何にかかわらず内部の終点と外部の終点とのコミュニケーションを可能にするのにこのトランザクションを使用できます(NAT、NAPT、ファイアウォール(太平洋標準時のNAT)はデバイスを結合しました)、単方向か双方向のトラフィックのために。
The agent sends an enable request specifying the endpoints (optionally including wildcards) and the direction of communication (inbound, outbound, bidirectional). The communication endpoints are displayed in Figure 3. The basic operation of the PER transaction can be described by
エージェントが発信する、終点(任意に、ワイルドカードを含んでいる)とコミュニケーションの方向(本国行きの、そして、外国行きの、そして、双方向の)を指定する要求を可能にしてください。 図3にコミュニケーション終点を表示します。 トランザクションについて説明できるPERの基本的な操作
1. the agent sending A0 and A3 to the middlebox,
1. middleboxへのエージェント送付A0とA3
2. the middlebox reserving A1 and A2 or using A1 and A2 from a previous PRR transaction,
2. 前のPRRトランザクションからA1とA2を予約するか、またはA1とA2を使用するmiddlebox
3. the middlebox enabling packet transfer between A0 and A3 by binding A0-A2 and A1-A3 and/or by opening the corresponding pinholes, both according to the specified direction, and
そして3. 拘束力があるA0-A2とA1-A3対応するピンホールを開くことによってA0とA3の間のパケット転送を可能にするmiddlebox、指定された方向に従った両方。
4. the middlebox returning A1 and A2 to the agent.
4. エージェントへのmiddleboxの戻っているA1とA2。
In case of a pure packet filtering firewall, the returned address tuples are the same as those in the request: A2=A0 and A1=A3. Each partner uses the other's real address. In case of a traditional NAT, the internal endpoint may use the real address of the external endpoint (A1=A3), but the external endpoint uses an
純粋なパケットフィルタリングファイアウォールの場合には、返されたアドレスtuplesは要求におけるそれらと同じです: A2=A0とA1=A3。 各パートナーはもう片方の本当のアドレスを使用します。 伝統的なNATの場合には、内部の終点はしかし、外部の終点(A1=A3)、外部の終点用途の本当のアドレスを使用するかもしれません。
Stiemerling, et al. Standards Track [Page 33] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[33ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
address tuple provided by the NAT (A2!=A0). In case of a twice- NAT device, both endpoints use address tuples provided by the NAT for addressing their communication partner (A3!=A1 and A2!=A0).
アドレスtupleはNATによって提供されました(A2!はA0と等しいです)。 NATデバイス、使用がNATによってそれらのコミュニケーションを扱うのに提供されたtuplesを扱う両方の終点の2倍パートナー(A3!はA1と等しいです、そして、A2!はA0と等しい)の場合に。
If a firewall is combined with a NAT or a twice-NAT, the replied address tuples will be the same as for pure traditional NAT or twice-NAT, respectively, but the middlebox will configure its packet filter in addition to the performed NAT bindings. In case of a firewall combined with a traditional NAT, the policy rule may imply more than one enable action for the firewall configuration, as incoming and outgoing packets may use different source- destination pairs.
ファイアウォールがNATか2倍NATに結合されると、返答したアドレスtuplesは純粋な伝統的なNATや2倍NATのようにそれぞれ同じになるでしょうが、middleboxは実行されたNAT結合に加えてパケットフィルタを構成するでしょう。 伝統的なNATに結合されたファイアウォールの場合には、政策ルールは、1以上がファイアウォール構成のための動作を可能にするのを含意するかもしれません、送受信のパケットが異なったソース目的地組を使用するとき。
For middleboxes supporting interface-specific policy rules, as defined in section 2.3.7, the optional inside and outside interface parameters must both be included in the request, or neither of them should be included. In the presence of these parameters, the middlebox uses the outside interface parameter to select the interface at which the outside address tuple (outside IP address and port number) is bound, and the inside interface parameter to select the interface at which the inside address tuple (inside IP address and port number) is bound. Without the presence of these parameters, the middlebox selects the particular interfaces based on its internal configuration.
セクション2.3.7で定義されるようにインタフェース特有の方針規則をサポートするmiddleboxesに関しては要求にともに内外面の任意のインタフェース・パラメータを含むべきであってはいけない、さもなければ、それらのどちらも含むべきではありません。 これらのパラメタがあるとき、middleboxはインタフェースを選択する外のアドレスtuple(IPアドレスとポートナンバーの外における)が制限されている外のインタフェース・パラメータ、およびインタフェースを選択するインサイドアドレスtuple(IPアドレスとポートナンバーにおける)が制限されている内面のインタフェース・パラメータを使用します。 これらのパラメタの存在がなければ、middleboxは内部の構成に基づく特定のインタフェースを選択します。
Checking the Policy Reservation Rule Identifier
方針予約規則識別子をチェックします。
If the parameter specifying the policy reservation rule identifier is not empty, then the middlebox checks whether the referenced policy rule exists, whether the agent is authorized to replace this policy rule, and whether this policy rule is a policy reserve rule.
方針予約規則識別子を指定するパラメタが空でないなら、middleboxは、参照をつけられた政策ルールが存在するかどうかチェックします、エージェントがこの政策ルールを置き換えるのに権限を与えられて、この政策ルールが責任準備金規則であるか否かに関係なく。
In case of success, this transaction creates a new policy enable rule. If a policy reserve rule was referenced, then the policy reserve rule is terminated without an explicit notification sent to the agent (other than the successful PER reply).
成功の場合にこのトランザクションは新しく取り決めます。規則を可能にしてください。 責任準備金規則が参照をつけられたなら、責任準備金規則はエージェント(うまくいっているPER回答を除いた)に送られた明白な通知なしで終えられます。
The PRR transaction sets the internal endpoint A0 during the reservation process. In the process of creating a new policy enable rule, the middlebox may check whether the requested A0 is equal to the reserved A0. The middlebox may reject a PER request with a requested A0 not equal to the reserved A0 and must then send an appropriate failure message. Alternatively, the middlebox may change A0 due to the PER request.
PRRトランザクションは予約プロセスの間、内部の終点A0を設定します。 新しく取り決めることの途中に、規則を可能にしてください、と要求されたA0が予約されたA0と等しいか否かに関係なく、middleboxはチェックするかもしれません。 middleboxは予約されたA0と等しくない要求されたA0とのPER要求を拒絶するかもしれません、そして、その時は適切な失敗メッセージを送らなければなりませんか? あるいはまた、middleboxはPER要求のためA0を変えるかもしれません。
Stiemerling, et al. Standards Track [Page 34] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[34ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
The middlebox generates a middlebox-unique identifier for the new policy rule. If a policy reserve rule was referenced, then the identifier of the policy reserve rule is reused.
middleboxは新しい政策規則のためのmiddleboxユニークな識別子を生成します。 責任準備金規則が参照をつけられたなら、責任準備金規則に関する識別子は再利用されます。
The owner of the new policy rule is the authenticated agent that sent the request.
新しい政策規則の所有者は要求を送った認証されたエージェントです。
Checking the Policy Rule Group Identifier
政策ルールグループ識別子をチェックします。
If no policy reserve rule was specified, then the policy rule group parameter is checked. If a non-existing policy rule group is specified, or if an existing policy rule group is specified that is not owned by the requesting agent, then no new policy rule is established, and an appropriate failure reply is generated.
責任準備金規則が全く指定されなかったなら、政策ルールグループパラメタはチェックされます。 非既存の政策ルールグループが指定されるか、または要求しているエージェントによって所有されていない既存の政策ルールグループが指定されるなら、新しい政策規則は全く確立されません、そして、適切な失敗回答は発生しています。
If an already existing policy rule group is specified, then the new policy rule becomes a member. If no policy group is specified, then a new group is created with the new policy rule as its only member.
既に既存の政策ルールグループが指定されるなら、新しい政策規則はメンバーになります。 方針グループが全く指定されないなら、新しいグループは唯一のメンバーとして新しい政策規則で創設されます。
If the transport protocol parameter value is 'ANY', then the middlebox enables communication between the specified external IP address and the specified internal IP address. The addresses to be used by the communication partners to address each other are returned to the agent as inside IP address and outside IP address. If the reservation identifier is not empty and if the reservation used the same transport protocol type, then the reserved IP addresses are used.
トランスポート・プロトコルパラメタ価値が'いずれか'であるなら、middleboxは指定された外部のIPアドレスと指定された内部のIPアドレスとのコミュニケーションを可能にします。 IPアドレスの中と、そして、IPアドレスの外ように互いに演説するのにコミュニケーションパートナーによって使用されるべきアドレスをエージェントに返します。 予約識別子が空でなく、予約が同じトランスポート・プロトコルタイプを使用したなら、予約されたIPアドレスは使用されています。
For the transport protocol parameter values 'UDP' and 'TCP', the middlebox acts analogously as for 'ANY' but also maps ranges of port numbers, keeping the port parity, if requested.
トランスポート・プロトコルパラメタ値の'UDP'と'TCP'のために、middleboxは類似して'いずれも'のように行動しますが、ポートナンバーの範囲をまた写像します、ポートの同等を保って、要求されるなら。
The configuration of the middlebox may fail because of lack of resources, such as available IP addresses, port numbers, or storage for further policy rules. It may also fail because of a conflict with an established policy rule. In case of a conflict, the first-come first-served mechanism is applied. Existing policy rules remain unchanged and arriving new ones are rejected. However, in case of a non-conflicting overlap of policy rules (including identical policy rules), all policy rules are accepted.
middleboxの構成は財源不足で失敗するかもしれません、さらなる政策ルールのための利用可能なIPアドレス、ポートナンバー、またはストレージなどのように。 また、それは既定方針規則との闘争で失敗するかもしれません。 闘争の場合には、先着順のメカニズムは適用されています。 既存の政策ルールは変わりがありません、そして、新しい状態で到着して、ものは拒絶されます。 しかしながら、政策ルール(同じ政策ルールを含んでいる)の非闘争オーバラップの場合に、すべての政策ルールを受け入れます。
The middlebox chooses a lifetime value that is greater than zero and less than or equal to the minimum of the requested value and the maximum lifetime specified by the middlebox at session startup, i.e.,
middleboxはすなわち、ゼロと要求された値と最大の生涯の、より最小限がセッション始動でmiddleboxで指定したより大きい生涯値を選びます。
Stiemerling, et al. Standards Track [Page 35] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[35ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
0 <はMINIMUMと等しいのを_を<に与えるltと等しいです。(_が要求したlt、lt_最大)
where - lt_granted is the lifetime actually granted by the middlebox - lt_requested is the lifetime the agent requested - lt_maximum is the maximum lifetime specified at session setup
どこ--_が与えたltは実際にmiddleboxによって与えられた生涯です--_が要求したltはエージェントが要求した生涯です--lt_最大はセッションセットアップで指定された最大の生涯であるか。
In each case of failure, an appropriate failure reply is generated. The policy reserve rule that is referenced in the PER transaction is not affected in case of a failure within the PER transaction -- i.e., the policy reserve rule remains.
失敗の各場合では、適切な失敗回答は発生しています。 PERトランザクションで参照をつけられる責任準備金規則はPERトランザクションの中の失敗の場合に影響を受けません--すなわち、責任準備金規則は残っています。
After a new policy enable rule is successfully established and the reply message has been sent to the requesting agent, the middlebox checks whether there are other authenticated agents participating in open sessions that can access the new policy rule. If the middlebox finds one or more of these agents, then it sends a REN message reporting the new policy rule to each of them.
a後新しい政策が可能にする、首尾よく規則を確立します、そして、要求しているエージェントに応答メッセージを送りました、と新しい政策規則にアクセスできる公開審議に参加する認証されたエージェントが別にいるか否かに関係なく、middleboxはチェックします。 middleboxがこれらのエージェントのより多くのひとりを見つけるなら、それで、RENメッセージは新しい政策規則をそれぞれの彼らに報告します。
2.3.10. Policy Rule Lifetime Change (RLC)
2.3.10. 政策ルール生涯変化(RLC)
transaction-name: policy rule lifetime change
トランザクション名: 政策ルール生涯変化
transaction-type: configuration
トランザクションタイプ: 構成
transaction-compliance: mandatory
トランザクションコンプライアンス: 義務的
request-parameters:
要求パラメタ:
- request identifier: An agent-unique identifier for matching corresponding request and reply at the agent.
- 識別子を要求してください: エージェントで対応する要求と回答に合うためのエージェントユニークな識別子。
- policy rule identifier: Identifying the policy rule for which the lifetime is requested to be changed. This may identify either a policy reserve rule or a policy enable rule.
- 政策ルール識別子: 寿命が変えられるよう要求されている政策ルールを特定します。 これが責任準備金規則を特定するかもしれませんか、または方針は規則を可能にします。
- policy rule lifetime: The new lifetime proposal for the policy rule.
- 政策ルール生涯: 政策ルールのための新しい生涯提案。
reply-parameters (success):
回答パラメタ(成功):
- request identifier: An identifier matching the identifier of the request.
- 識別子を要求してください: 要求に関する識別子に合っている識別子。
- policy rule lifetime: The remaining policy rule lifetime granted by the middlebox.
- 政策ルール生涯: middleboxによって与えられた残っている政策ルール生涯。
Stiemerling, et al. Standards Track [Page 36] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[36ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
failure reason:
失敗理由:
- agent not authorized for this transaction - agent not authorized to change lifetime of this policy rule - no such policy rule - lifetime cannot be extended
- このトランザクションのために権限を与えられなかったエージェント--この政策ルールの生涯を変えるのは権限を与えられなかったエージェント--そのような政策ルールでない--生涯を広げることができません。
notification message type: Policy Rule Event Notification (REN)
通知メッセージタイプ: 政策ルールイベント通知(REN)
semantics:
意味論:
The agent can use this transaction type to request the extension of an established policy rule's lifetime, the shortening of the lifetime, or policy rule termination. Policy rule termination is requested by suggesting a new policy rule lifetime of zero.
エージェントは既定方針規則の生涯の拡大、生涯の短縮を要求するこのトランザクションタイプか政策ルール終了を使用できます。 政策ルール終了は、ゼロの新しい政策ルール生涯を示すことによって、要求されています。
The middlebox first checks whether the specified policy rule exists and whether the agent is authorized to access this policy rule. If one of the checks fails, an appropriate failure reply is generated. If the requested lifetime is longer than the current one, the middlebox also checks whether the lifetime of the policy rule may be extended and generates an appropriate failure message if it may not.
middleboxは最初に、特約保険証券規則が存在しているかどうかと、エージェントがこの政策ルールにアクセスするのに権限を与えられるかどうかチェックします。 チェックの1つが失敗するなら、適切な失敗回答は発生しています。 middleboxはまた、政策ルールの寿命が広げられるかもしれないかどうかチェックして、要求された寿命が現在のものより長く、生成しないかもしれないなら、適切な失敗メッセージを生成します。
A failure reply implies that the new lifetime was not accepted, and the policy rule remains unchanged. A success reply is generated by the middlebox if the lifetime of the policy rule was changed in any way.
失敗回答は、新しい寿命が受け入れられなかったのを含意します、そして、政策ルールは変わりがありません。 何らかの方法で政策ルールの生涯を変えたなら、middleboxは成功回答を生成します。
The success reply contains the new lifetime of the policy rule. The middlebox chooses a lifetime value that is greater than zero and less than or equal to the minimum of the requested value and the maximum lifetime specified by the middlebox at session startup, i.e.,
成功回答は政策ルールの新しい生涯を含んでいます。 middleboxはすなわち、ゼロと要求された値と最大の生涯の、より最小限がセッション始動でmiddleboxで指定したより大きい生涯値を選びます。
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
0 <はMINIMUMと等しいのを_を<に与えるltと等しいです。(_が要求したlt、lt_最大)
where - lt_granted is the lifetime actually granted by the middlebox - lt_requested is the lifetime the agent requested - lt_maximum is the maximum lifetime specified at session setup
どこ--_が与えたltは実際にmiddleboxによって与えられた生涯です--_が要求したltはエージェントが要求した生涯です--lt_最大はセッションセットアップで指定された最大の生涯であるか。
After sending a success reply with a lifetime of zero, the middlebox will consider the policy rule non-existent. Any further transaction on this policy rule results in a negative reply, indicating that this policy rule does not exist anymore.
ゼロの生涯がある成功回答を送った後に、middleboxは、政策ルールが実在しないと考えるでしょう。 この政策ルールに関するどんなさらなるトランザクションも否定的な返事をもたらします、この政策ルールがそれ以上存在しないのを示して。
Stiemerling, et al. Standards Track [Page 37] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[37ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
Note that policy rule lifetime may also be changed by the Group Lifetime Change (GLC) transaction, if applied to the group of which the policy rule is a member.
また、政策ルール寿命がGroup Lifetime Change(GLC)トランザクションによって変えられるかもしれないことに注意してください、政策ルールがメンバーであるグループに適用されるなら。
After the remaining policy rule lifetime was successfully changed and the reply message has been sent to the requesting agent, the middlebox checks whether there are other authenticated agents participating in open sessions that can access the policy rule. If the middlebox finds one or more of these agents, then it sends a REN message reporting the new remaining policy rule lifetime to each of them.
首尾よく残っている政策ルール生涯を変えて、要求しているエージェントに応答メッセージを送った後に、middleboxは、政策ルールにアクセスできる公開審議に参加する他の認証されたエージェントがいるかどうかチェックします。 middleboxがこれらのエージェントのより多くのひとりを見つけるなら、それで、RENメッセージは新しい残っている政策ルール生涯をそれぞれの彼らに報告します。
2.3.11. Policy Rule List (PRL)
2.3.11. 政策ルールリスト(PRL)
transaction-name: policy rule list
トランザクション名: 政策ルールリスト
transaction-type: monitoring
トランザクションタイプ: モニターであること
transaction-compliance: mandatory
トランザクションコンプライアンス: 義務的
request-parameters:
要求パラメタ:
- request identifier: An agent-unique identifier for matching corresponding request and reply at the agent.
- 識別子を要求してください: エージェントで対応する要求と回答に合うためのエージェントユニークな識別子。
reply-parameters (success):
回答パラメタ(成功):
- request identifier: An identifier matching the identifier of the request.
- 識別子を要求してください: 要求に関する識別子に合っている識別子。
- policy list: List of policy rule identifiers of all policy rules that the agent can access.
- 方針リスト: すべての方針に関する政策ルール識別子のリストが、エージェントがそうすることができると裁決する、アクセサリー
failure reason:
失敗理由:
- transaction not supported - agent not authorized for this transaction
- サポートされなかったトランザクション--このトランザクションのために権限を与えられなかったエージェント
Stiemerling, et al. Standards Track [Page 38] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[38ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
semantics:
意味論:
The agent can use this transaction type to list all policies that it can access. Usually, the agent has this information already, but in special cases (for example, after an agent fail-over) or for special agents (for example, an administrating agent that can access all policies) this transaction can be helpful.
エージェントがそれが記載できるすべての方針を記載するのにこのトランザクションタイプを使用できる、アクセサリー 通常、エージェントには、この情報が既にありますが、特別なケース(例えばエージェントフェイルオーバーの後に)か特別なエージェント(例えば、すべての方針にアクセスできる管財のエージェント)にとって、このトランザクションは役立っている場合があります。
The middlebox first checks whether the agent is authorized to request this transaction. If the check fails, an appropriate failure reply is generated. Otherwise, a list of all policies the agent can access is returned indicating the identifier and the owner of each policy.
middleboxは、最初に、エージェントがこのトランザクションを要求するのに権限を与えられるかどうかチェックします。 チェックが失敗するなら、適切な失敗回答は発生しています。 さもなければ、それぞれの方針の識別子と所有者を示しながら、エージェントがアクセスできるすべての方針のリストを返します。
This transaction does not have any effect on the policy rule state.
このトランザクションは政策ルール状態にどんな影響も与えません。
2.3.12. Policy Rule Status (PRS)
2.3.12. 政策ルール状態(PRS)
transaction-name: policy rule status
トランザクション名: 政策ルール状態
transaction-type: monitoring
トランザクションタイプ: モニターであること
transaction-compliance: mandatory
トランザクションコンプライアンス: 義務的
request-parameters:
要求パラメタ:
- request identifier: An agent-unique identifier for matching corresponding request and reply at the agent.
- 識別子を要求してください: エージェントで対応する要求と回答に合うためのエージェントユニークな識別子。
- policy rule identifier: The middlebox-unique policy rule identifier.
- 政策ルール識別子: middleboxユニークな政策ルール識別子。
reply-parameters (success):
回答パラメタ(成功):
- request identifier: An identifier matching the identifier of the request.
- 識別子を要求してください: 要求に関する識別子に合っている識別子。
- policy rule owner: An identifier of the agent owning this policy rule.
- 政策ルール所有者: この政策ルールを所有しているエージェントの識別子。
- group identifier: A reference to the group of which the policy rule is a member.
- 識別子を分類してください: 政策ルールがメンバーであるグループの参照。
- policy rule action: This parameter has either the value 'reserve' or the value 'enable'.
- 政策ルール動作: このパラメタには、値の'蓄え'か値の'可能にどちらか'があります。
Stiemerling, et al. Standards Track [Page 39] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[39ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
- transport protocol: Identifies the protocol for which a reservation is requested; see section 2.3.5.
- トランスポート・プロトコル: 予約が要求されているプロトコルを特定します。 セクション2.3.5を見てください。
- port range: The number of consecutive port numbers; see section 2.3.5.
- 範囲を移植してください: 連続したポートナンバーの数。 セクション2.3.5を見てください。
- direction: The direction of the communication enabled by the middlebox. Applicable only to policy enable rules.
- 方向: middleboxによって可能にされたコミュニケーションの方向。 適切である、方針だけに、規則を可能にしてください。
- internal IP address version: The version of the internal IP address (IP version of A0 in Figure 3).
- 内部のIPアドレスバージョン: 内部のIPアドレス(図3のA0のIPバージョン)のバージョン。
- external IP address version: The version of the external IP address (IP version of A3 in Figure 3).
- 外部のIPアドレスバージョン: 外部のIPアドレス(図3のA3のIPバージョン)のバージョン。
- internal IP address: The IP address of the internal communication endpoint (A0 in Figure 3); see section 2.3.5.
- 内部のIPアドレス: 内部のコミュニケーション終点(図3のA0)のIPアドレス。 セクション2.3.5を見てください。
- internal port number: The port number of the internal communication endpoint (A0 in Figure 3); see section 2.3.5.
- 内部のポートナンバー: 内部のコミュニケーション終点(図3のA0)のポートナンバー。 セクション2.3.5を見てください。
- external IP address: The IP address of the external communication endpoint (A3 in Figure 3); see section 2.3.5.
- 外部のIPアドレス: 外部コミュニケーション終点(図3のA3)のIPアドレス。 セクション2.3.5を見てください。
- external port number: The port number of the external communication endpoint (A3 in Figure 3); see section 2.3.5.
- 外部のポートナンバー: 外部コミュニケーション終点(図3のA3)のポートナンバー。 セクション2.3.5を見てください。
- inside interface (optional): The inside interface at the middlebox; see section 2.3.7.
- 中では、連結してください(任意の): middleboxの内面のインタフェース。 セクション2.3.7を見てください。
- inside IP address: The internal IP address provided at the inside of the NAT (A1 in Figure 3); see section 2.3.5.
- 内面のIPアドレス: 内部のIPアドレスはNAT(図3のA1)の内部で提供されました。 セクション2.3.5を見てください。
- inside port number: The internal port number provided at the inside of the NAT (A1 in Figure 3); see section 2.3.5.
- 内面のポートナンバー: 内部のポートナンバーはNAT(図3のA1)の内部で提供されました。 セクション2.3.5を見てください。
- outside interface (optional): The outside interface at the middlebox; see section 2.3.7.
- 外では、連結してください(任意の): middleboxの外のインタフェース。 セクション2.3.7を見てください。
- outside IP address: The external IP address provided at the outside of the NAT (A2 in Figure 3); see section 2.3.5.
- 外のIPアドレス: 外部のIPアドレスはNAT(図3のA2)の外部で提供されました。 セクション2.3.5を見てください。
- outside port number: The external port number provided at the outside of the NAT (A2 in Figure 3); see section 2.3.5.
- 外のポートナンバー: 外部のポートナンバーはNAT(図3のA2)の外部で提供されました。 セクション2.3.5を見てください。
- port parity: The parity of the allocated ports.
- 同等を移植してください: 割り当てられたポートの同等。
Stiemerling, et al. Standards Track [Page 40] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[40ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
- service: The selected service in the case of mixed traditional and twice-NAT middlebox (see section 2.3.8).
- サービス: 選択は中で伝統的に混ぜられることのケースを調整します、そして、2倍NATはmiddleboxされます(セクション2.3.8を見てください)。
- policy rule lifetime: The remaining lifetime of the policy rule.
- 政策ルール生涯: 政策ルールの残っている生涯。
failure reason:
失敗理由:
- transaction not supported - agent not authorized for this transaction - no such policy rule - agent not authorized to access this policy rule
- サポートされなかったトランザクション--このトランザクション--そのような政策ルールでない--この政策ルールにアクセスするのは権限を与えられなかったエージェントのために権限を与えられなかったエージェント
semantics:
意味論:
The agent can use this transaction type to list all properties of a policy rule. Usually, the agent has this information already, but in special cases (for example, after an agent fail-over) or for special agents (for example, an administrating agent that can access all policy rules) this transaction can be helpful.
エージェントは、政策ルールのすべての特性を記載するのにこのトランザクションタイプを使用できます。 通常、エージェントには、この情報が既にありますが、特別なケース(例えばエージェントフェイルオーバーの後に)か特別なエージェント(例えば、すべての方針にアクセスできる管財のエージェントは判決を下します)にとって、このトランザクションは役立っている場合があります。
The middlebox first checks whether the specified policy rule exists and whether the agent is authorized to access this group. If one of the checks fails, an appropriate failure reply is generated. Otherwise, all properties of the policy rule are returned to the agent. Some of the returned parameters may be irrelevant, depending on the policy rule action ('reserve' or 'enable') and depending on other parameters -- for example, the protocol identifier.
middleboxは最初に、特約保険証券規則が存在しているかどうかと、エージェントがこのグループにアクセスするのに権限を与えられるかどうかチェックします。 チェックの1つが失敗するなら、適切な失敗回答は発生しています。 さもなければ、政策ルールのすべての資産をエージェントに返します。 返されたパラメタのいくつかが無関係であるかもしれません、政策ルール動作('予約する'か、または'可能にする')によって、他のパラメタによって--例えば、プロトコル識別子。
This transaction does not have any effect on the policy rule state.
このトランザクションは政策ルール状態にどんな影響も与えません。
2.3.13. Asynchronous Policy Rule Event (ARE)
2.3.13. 非同期な政策ルールイベント(あります)
transaction-name: asynchronous policy rule event
トランザクション名: 非同期な政策ルールイベント
transaction-type: asynchronous
トランザクションタイプ: 非同期
transaction-compliance: mandatory
トランザクションコンプライアンス: 義務的
notification message type: Policy Rule Event Notification (REN)
通知メッセージタイプ: 政策ルールイベント通知(REN)
semantics:
意味論:
The middlebox may decide at any point in time to terminate a policy rule. This transaction is triggered most frequently by lifetime expiration of the policy rule. Among other events that
middleboxは、時間内にの任意な点で政策ルールを終えると決めるかもしれません。 このトランザクションは政策ルールの生涯満了で最も頻繁に引き起こされます。 他のイベント、それ
Stiemerling, et al. Standards Track [Page 41] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[41ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
may cause this transaction are changes in the policy rule decision point.
引き起こすかもしれません。このトランザクションは政策ルール決定ポイントの変化です。
The middlebox sends a REN message to all agents that participate in an open session with the middlebox and that are authorized to access the policy rule. The notification is sent to the agents before the middlebox changes the policy rule's lifetime. The change of lifetime may be triggered by any other authorized agent and results in shortening (lt_new < lt_existing), extending (lt_new > lt_existing), or terminating the policy rule (lt_new = 0).
middleboxはmiddleboxで公開審議に参加して、政策ルールにアクセスするのに権限を与えられるすべてのエージェントにRENメッセージを送ります。 middleboxが政策ルールの生涯を変える前に通知をエージェントに送ります。 生涯の変化はいかなる他の委任代理人と結果によっても(ltの_の新しい<lt_存在)を短くする際に引き起こされるかもしれません、政策ルール(_の新しいlt=0)を広げているか(ltの_の新しい>lt_存在)、または終えて。
The ARE transaction corresponds to the REN message handling described in section 2.3.4 for multiple agents.
トランザクションは複数のエージェントのためにセクション2.3.4で説明されたRENメッセージハンドリングに対応しています。
2.3.14. Policy Rule State Machine
2.3.14. 政策ルール州のマシン
The state machine for the policy rule transactions is shown in Figure 4 with all possible state transitions. The used transaction abbreviations may be found in the headings of the particular transaction section.
政策ルールトランザクションのための州のマシンはすべてが可能の図4に状態が移行するのが示されます。 中古のトランザクション略語は特定の取引部に関する見出しで見つけられるかもしれません。
PRR/success +---------------+ +-----------------+ PRID UNUSED |<-+ +----+ | +---------------+ | | | | ^ | | | v v | | | | +-------------+ ARE | | PER/ | ARE | | RESERVED +------------+ | success | RLC(lt=0)/ | +-+----+------+ RLC(lt=0)/ | | success | | | success | | +----+ | v | RLC(lt>0)/ | PER/success +---------------+ | success +---------------->| ENABLED +--+ +-+-------------+ | ^ lt = lifetime +-----------+ RLC(lt>0)/success
PRR/成功+---------------+ +-----------------+、PRID未使用| <、-+ +----+ | +---------------+ | | | | ^ | | | vに対して| | | | +-------------+はそうです。| | /単位で| あります。| | 予約された+------------+ | 成功| RLC(lt=0)/| +-+----+------+ RLC(lt=0)/| | 成功| | | 成功| | +----+ | v| RLC(lt>0)/| /成功+単位で---------------+ | 成功+---------------->| +を可能にします--、+ ++-------------+ | ^lt=生涯+-----------+ RLC(lt>0)/成功
Figure 4: Policy Rule State Machine
図4: 政策ルール州のマシン
This state machine exists per policy rule identifier (PRID). Initially, all policy rules are in state PRID UNUSED, which means that the policy rule does not exist or is not active. After returning to state PRID UNUSED, the policy rule identifier is no longer bound to an existing policy rule and may be reused by the middlebox.
この州のマシンは政策ルール識別子(PRID)単位で存在しています。 初めは、すべての政策ルールが州のPRID UNUSEDにあります。(PRID UNUSEDは政策ルールが存在していないか、またはアクティブでないことを意味します)。 戻って、PRID UNUSEDを述べた後に、政策ルール識別子は、もう既存の政策ルールに縛られないで、middleboxによって再利用されるかもしれません。
Stiemerling, et al. Standards Track [Page 42] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling, et al. Standards Track [Page 42] RFC 5189 MIDCOM Protocol Semantics March 2008
A successful PRR transaction causes a transition from the initial state PRID UNUSED to the state RESERVED, where an address reservation is established. From there, state ENABLED can be entered by a PER transaction. This transaction can also be used for entering state ENABLED directly from state PRID UNUSED without a reservation. In state ENABLED, the requested communication between the internal and the external endpoint is enabled.
A successful PRR transaction causes a transition from the initial state PRID UNUSED to the state RESERVED, where an address reservation is established. From there, state ENABLED can be entered by a PER transaction. This transaction can also be used for entering state ENABLED directly from state PRID UNUSED without a reservation. In state ENABLED, the requested communication between the internal and the external endpoint is enabled.
The states RESERVED and ENABLED can be maintained by successful RLC transactions with a requested lifetime greater than 0. Transitions from both of these states back to state PRID UNUSED can be caused by an ARE transaction or by a successful RLC transaction with a lifetime parameter of 0.
The states RESERVED and ENABLED can be maintained by successful RLC transactions with a requested lifetime greater than 0. Transitions from both of these states back to state PRID UNUSED can be caused by an ARE transaction or by a successful RLC transaction with a lifetime parameter of 0.
A failed request transaction does not change state at the middlebox.
A failed request transaction does not change state at the middlebox.
Note that transitions initiated by RLC transactions may also be initiated by GLC transactions.
Note that transitions initiated by RLC transactions may also be initiated by GLC transactions.
2.4. Policy Rule Group Transactions
2.4. Policy Rule Group Transactions
This section describes the semantics for transactions on groups of policy rules. These transactions are specified as follows:
This section describes the semantics for transactions on groups of policy rules. These transactions are specified as follows:
- Group Lifetime Change (GLC) - Group List (GL) - Group Status (GS)
- Group Lifetime Change (GLC) - Group List (GL) - Group Status (GS)
All are request transactions initiated by the agent. GLC is a configuration transaction. GL and GS are monitoring transactions that do not have any effect on the group state machine.
All are request transactions initiated by the agent. GLC is a configuration transaction. GL and GS are monitoring transactions that do not have any effect on the group state machine.
2.4.1. Overview
2.4.1. Overview
A policy rule group has only one attribute: the list of its members. All member policies of a single group must be owned by the same authenticated agent. Therefore, an implicit property of a group is its owner, which is the owner of the member policy rules.
A policy rule group has only one attribute: the list of its members. All member policies of a single group must be owned by the same authenticated agent. Therefore, an implicit property of a group is its owner, which is the owner of the member policy rules.
A group is implicitly created when its first member policy rule is established. A group is implicitly terminated when the last remaining member policy rule is terminated. Consequently, the lifetime of a group is the maximum of the lifetimes of all member policy rules.
A group is implicitly created when its first member policy rule is established. A group is implicitly terminated when the last remaining member policy rule is terminated. Consequently, the lifetime of a group is the maximum of the lifetimes of all member policy rules.
A group has a middlebox-unique identifier.
A group has a middlebox-unique identifier.
Stiemerling, et al. Standards Track [Page 43] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling, et al. Standards Track [Page 43] RFC 5189 MIDCOM Protocol Semantics March 2008
Policy rule group transactions are declared as 'optional' by their respective compliance entry in section 3. However, they provide some functionalities, such as convenience for the agent in sending only one request instead of several, that is not available if only mandatory transactions are available.
Policy rule group transactions are declared as 'optional' by their respective compliance entry in section 3. However, they provide some functionalities, such as convenience for the agent in sending only one request instead of several, that is not available if only mandatory transactions are available.
The Group Lifetime Change (GLC) transaction is equivalent to simultaneously performed Policy Rule Lifetime Change (RLC) transactions on all members of the group. The result of a successful GLC transaction is that all member policy rules have the same lifetime. As with the RLC transaction, the GLC transaction can be used to delete all member policy rules by requesting a lifetime of zero.
The Group Lifetime Change (GLC) transaction is equivalent to simultaneously performed Policy Rule Lifetime Change (RLC) transactions on all members of the group. The result of a successful GLC transaction is that all member policy rules have the same lifetime. As with the RLC transaction, the GLC transaction can be used to delete all member policy rules by requesting a lifetime of zero.
The monitoring transactions Group List (GL) and Group Status (GS) can be used by the agent to explore the state of the middlebox and to explore its access rights. The GL transaction lists all groups that the agent may access, including groups owned by other agents. The GS transaction reports the status on an individual group and lists all policy rules of this group by their policy rule identifiers. The agent can explore the state of the individual policy rules by using the policy rule identifiers in a policy rule status (PRS) transaction (see section 2.3.12).
The monitoring transactions Group List (GL) and Group Status (GS) can be used by the agent to explore the state of the middlebox and to explore its access rights. The GL transaction lists all groups that the agent may access, including groups owned by other agents. The GS transaction reports the status on an individual group and lists all policy rules of this group by their policy rule identifiers. The agent can explore the state of the individual policy rules by using the policy rule identifiers in a policy rule status (PRS) transaction (see section 2.3.12).
The GL and GS transactions are particularly helpful in case of an agent fail-over. The agent taking over the role of a failed one can use these transactions to retrieve whichever policies have been established by the failed agent.
The GL and GS transactions are particularly helpful in case of an agent fail-over. The agent taking over the role of a failed one can use these transactions to retrieve whichever policies have been established by the failed agent.
Notifications on group events are generated analogously to policy rule events. To notify agents about group events, the Policy Rule Group Event Notification (GEN) message type is used. GEN messages contain an agent-unique notification identifier, the policy rule group identifier, and the remaining lifetime of the group.
Notifications on group events are generated analogously to policy rule events. To notify agents about group events, the Policy Rule Group Event Notification (GEN) message type is used. GEN messages contain an agent-unique notification identifier, the policy rule group identifier, and the remaining lifetime of the group.
2.4.2. Group Lifetime Change (GLC)
2.4.2. Group Lifetime Change (GLC)
transaction-name: group lifetime change
transaction-name: group lifetime change
transaction-type: configuration
transaction-type: configuration
transaction-compliance: optional
transaction-compliance: optional
request-parameters:
request-parameters:
- request identifier: An agent-unique identifier for matching corresponding request and reply at the agent.
- request identifier: An agent-unique identifier for matching corresponding request and reply at the agent.
Stiemerling, et al. Standards Track [Page 44] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling, et al. Standards Track [Page 44] RFC 5189 MIDCOM Protocol Semantics March 2008
- group identifier: A reference to the group for which the lifetime is requested to be changed.
- group identifier: A reference to the group for which the lifetime is requested to be changed.
- group lifetime: The new lifetime proposal for the group.
- group lifetime: The new lifetime proposal for the group.
reply-parameters (success):
reply-parameters (success):
- request identifier: An identifier matching the identifier of the request.
- request identifier: An identifier matching the identifier of the request.
- group lifetime: The group lifetime granted by the middlebox.
- group lifetime: The group lifetime granted by the middlebox.
failure reason:
failure reason:
- transaction not supported - agent not authorized for this transaction - agent not authorized to change lifetime of this group - no such group - lifetime cannot be extended
- transaction not supported - agent not authorized for this transaction - agent not authorized to change lifetime of this group - no such group - lifetime cannot be extended
notification message type: Policy Rule Group Event Notification (GEN)
notification message type: Policy Rule Group Event Notification (GEN)
semantics:
semantics:
The agent can use this transaction type to request an extension of the lifetime of all members of a policy rule group, to request shortening the lifetime of all members, or to request termination of all member policies (which implies termination of the group). Termination is requested by suggesting a new group lifetime of zero.
The agent can use this transaction type to request an extension of the lifetime of all members of a policy rule group, to request shortening the lifetime of all members, or to request termination of all member policies (which implies termination of the group). Termination is requested by suggesting a new group lifetime of zero.
The middlebox first checks whether the specified group exists and whether the agent is authorized to access this group. If one of the checks fails, an appropriate failure reply is generated. If the requested lifetime is longer than the current one, the middlebox also checks whether the lifetime of the group may be extended and generates an appropriate failure message if it may not.
The middlebox first checks whether the specified group exists and whether the agent is authorized to access this group. If one of the checks fails, an appropriate failure reply is generated. If the requested lifetime is longer than the current one, the middlebox also checks whether the lifetime of the group may be extended and generates an appropriate failure message if it may not.
A failure reply implies that the lifetime of the group remains unchanged. A success reply is generated by the middlebox if the lifetime of the group was changed in any way.
A failure reply implies that the lifetime of the group remains unchanged. A success reply is generated by the middlebox if the lifetime of the group was changed in any way.
The success reply contains the new common lifetime of all member policy rules of the group. The middlebox chooses the new lifetime less than or equal to the minimum of the requested lifetime and the maximum lifetime that the middlebox specified at session setup along with its other capabilities, i.e.,
The success reply contains the new common lifetime of all member policy rules of the group. The middlebox chooses the new lifetime less than or equal to the minimum of the requested lifetime and the maximum lifetime that the middlebox specified at session setup along with its other capabilities, i.e.,
Stiemerling, et al. Standards Track [Page 45] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling, et al. Standards Track [Page 45] RFC 5189 MIDCOM Protocol Semantics March 2008
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
where - lt_granted is the lifetime actually granted by the middlebox - lt_requested is the lifetime the agent requested - lt_maximum is the maximum lifetime specified at session setup
where - lt_granted is the lifetime actually granted by the middlebox - lt_requested is the lifetime the agent requested - lt_maximum is the maximum lifetime specified at session setup
After sending a success reply with a lifetime of zero, the middlebox will terminate the member policy rules without any further notification to the agent, and will consider the group and all of its members non-existent. Any further transaction on this policy rule group or on any of its members results in a negative reply, indicating that this group or policy rule, respectively, does not exist anymore.
After sending a success reply with a lifetime of zero, the middlebox will terminate the member policy rules without any further notification to the agent, and will consider the group and all of its members non-existent. Any further transaction on this policy rule group or on any of its members results in a negative reply, indicating that this group or policy rule, respectively, does not exist anymore.
After the remaining policy rule group lifetime is successfully changed and the reply message has been sent to the requesting agent, the middlebox checks whether there are other authenticated agents participating in open sessions that can access the policy rule group. If the middlebox finds one or more of these agents, it sends a GEN message reporting the new remaining policy rule group lifetime to each of them.
After the remaining policy rule group lifetime is successfully changed and the reply message has been sent to the requesting agent, the middlebox checks whether there are other authenticated agents participating in open sessions that can access the policy rule group. If the middlebox finds one or more of these agents, it sends a GEN message reporting the new remaining policy rule group lifetime to each of them.
2.4.3. Group List (GL)
2.4.3. Group List (GL)
transaction-name: group list
transaction-name: group list
transaction-type: monitoring
transaction-type: monitoring
transaction-compliance: optional
transaction-compliance: optional
request-parameters:
request-parameters:
- request identifier: An agent-unique identifier for matching corresponding request and reply at the agent.
- request identifier: An agent-unique identifier for matching corresponding request and reply at the agent.
reply-parameters (success):
reply-parameters (success):
- request identifier: An identifier matching the identifier of the request.
- request identifier: An identifier matching the identifier of the request.
- group list: List of all groups that the agent can access. For each listed group, the identifier and the owner are indicated.
- group list: List of all groups that the agent can access. For each listed group, the identifier and the owner are indicated.
failure reason:
failure reason:
- transaction not supported - agent not authorized for this transaction
- transaction not supported - agent not authorized for this transaction
Stiemerling, et al. Standards Track [Page 46] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling, et al. Standards Track [Page 46] RFC 5189 MIDCOM Protocol Semantics March 2008
semantics:
semantics:
The agent can use this transaction type to list all groups that it can access. Usually, the agent has this information already, but in special cases (for example, after an agent fail-over) or for special agents (for example, an administrating agent that can access all groups) this transaction can be helpful.
The agent can use this transaction type to list all groups that it can access. Usually, the agent has this information already, but in special cases (for example, after an agent fail-over) or for special agents (for example, an administrating agent that can access all groups) this transaction can be helpful.
The middlebox first checks whether the agent is authorized to request this transaction. If the check fails, an appropriate failure reply is generated. Otherwise a list of all groups the agent can access is returned indicating the identifier and the owner of each group.
The middlebox first checks whether the agent is authorized to request this transaction. If the check fails, an appropriate failure reply is generated. Otherwise a list of all groups the agent can access is returned indicating the identifier and the owner of each group.
This transaction does not have any effect on the group state.
This transaction does not have any effect on the group state.
2.4.4. Group Status (GS)
2.4.4. Group Status (GS)
transaction-name: group status
transaction-name: group status
transaction-type: monitoring
transaction-type: monitoring
transaction-compliance: optional
transaction-compliance: optional
request-parameters:
request-parameters:
- request identifier: An agent-unique identifier for matching corresponding request and reply at the agent.
- request identifier: An agent-unique identifier for matching corresponding request and reply at the agent.
- group identifier: A reference to the group for which status information is requested.
- group identifier: A reference to the group for which status information is requested.
reply-parameters (success):
reply-parameters (success):
- request identifier: An identifier matching the identifier of the request.
- request identifier: An identifier matching the identifier of the request.
- group owner: An identifier of the agent owning this policy rule group.
- group owner: An identifier of the agent owning this policy rule group.
- group lifetime: The remaining lifetime of the group. This is the maximum of the remaining lifetimes of all members' policy rules.
- group lifetime: The remaining lifetime of the group. This is the maximum of the remaining lifetimes of all members' policy rules.
- member list: List of all policy rules that are members of the group. The policy rules are specified by their middlebox-unique policy rule identifier.
- member list: List of all policy rules that are members of the group. The policy rules are specified by their middlebox-unique policy rule identifier.
Stiemerling, et al. Standards Track [Page 47] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling, et al. Standards Track [Page 47] RFC 5189 MIDCOM Protocol Semantics March 2008
failure reason:
failure reason:
- transaction not supported - agent not authorized for this transaction - no such group - agent not authorized to list members of this group
- transaction not supported - agent not authorized for this transaction - no such group - agent not authorized to list members of this group
semantics:
semantics:
The agent can use this transaction type to list all member policy rules of a group. Usually, the agent has this information already, but in special cases (for example, after an agent fail- over) or for special agents (for example, an administrating agent that can access all groups) this transaction can be helpful.
The agent can use this transaction type to list all member policy rules of a group. Usually, the agent has this information already, but in special cases (for example, after an agent fail- over) or for special agents (for example, an administrating agent that can access all groups) this transaction can be helpful.
The middlebox first checks whether the specified group exists and whether the agent is authorized to access this group. If one of the checks fails, an appropriate failure reply is generated. Otherwise, a list of all group members is returned indicating the identifier of each group.
The middlebox first checks whether the specified group exists and whether the agent is authorized to access this group. If one of the checks fails, an appropriate failure reply is generated. Otherwise, a list of all group members is returned indicating the identifier of each group.
This transaction does not have any effect on the group state.
This transaction does not have any effect on the group state.
3. Conformance Statements
3. Conformance Statements
A protocol definition complies with the semantics defined in section 2 if the protocol specification includes all specified transactions with all their mandatory parameters. However, it is not required that an actual implementation of a middlebox supports all these transactions. Which transactions are required for compliance is different for agent and middlebox.
A protocol definition complies with the semantics defined in section 2 if the protocol specification includes all specified transactions with all their mandatory parameters. However, it is not required that an actual implementation of a middlebox supports all these transactions. Which transactions are required for compliance is different for agent and middlebox.
This section contains conformance statements for MIDCOM protocol implementations related to the semantics. Conformance is specified differently for agents and middleboxes. These conformance statements will probably be extended by a concrete protocol specification. However, such an extension is expected to extend the statements below in such a way that all of them still hold.
This section contains conformance statements for MIDCOM protocol implementations related to the semantics. Conformance is specified differently for agents and middleboxes. These conformance statements will probably be extended by a concrete protocol specification. However, such an extension is expected to extend the statements below in such a way that all of them still hold.
The following list shows the transaction-compliance property of all transactions as specified in the previous section:
The following list shows the transaction-compliance property of all transactions as specified in the previous section:
- Session Control Transactions - Session Establishment (SE) mandatory - Session Termination (ST) mandatory - Asynchronous Session Termination (AST) mandatory
- Session Control Transactions - Session Establishment (SE) mandatory - Session Termination (ST) mandatory - Asynchronous Session Termination (AST) mandatory
Stiemerling, et al. Standards Track [Page 48] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling, et al. Standards Track [Page 48] RFC 5189 MIDCOM Protocol Semantics March 2008
- Policy Rule Transactions - Policy Reserve Rule (PRR) mandatory - Policy Enable Rule (PER) mandatory - Policy Rule Lifetime Change (RLC) mandatory - Policy Rule List (PRL) mandatory - Policy Rule Status (PRS) mandatory - Asynchronous Policy Rule Event (ARE) mandatory
- Policy Rule Transactions - Policy Reserve Rule (PRR) mandatory - Policy Enable Rule (PER) mandatory - Policy Rule Lifetime Change (RLC) mandatory - Policy Rule List (PRL) mandatory - Policy Rule Status (PRS) mandatory - Asynchronous Policy Rule Event (ARE) mandatory
- Policy Rule Group Transactions - Group Lifetime Change (GLC) optional - Group List (GL) optional - Group Status (GS) optional
- Policy Rule Group Transactions - Group Lifetime Change (GLC) optional - Group List (GL) optional - Group Status (GS) optional
3.1. General Implementation Conformance
3.1. General Implementation Conformance
A compliant implementation of a MIDCOM protocol MUST support all mandatory transactions.
A compliant implementation of a MIDCOM protocol MUST support all mandatory transactions.
A compliant implementation of a MIDCOM protocol MAY support none, one, or more of the following transactions: GLC, GL, GS.
A compliant implementation of a MIDCOM protocol MAY support none, one, or more of the following transactions: GLC, GL, GS.
A compliant implementation MAY extend the protocol semantics by further transactions.
A compliant implementation MAY extend the protocol semantics by further transactions.
A compliant implementation of a MIDCOM protocol MUST support all mandatory parameters of each transaction concerning the information contained. The set of parameters can be redefined per transaction as long as the contained information is maintained.
A compliant implementation of a MIDCOM protocol MUST support all mandatory parameters of each transaction concerning the information contained. The set of parameters can be redefined per transaction as long as the contained information is maintained.
A compliant implementation of a MIDCOM protocol MAY support the use of interface-specific policy rules. Either both or neither of the optional inside and outside interface parameters in PRR, PER, and PRS MUST be included if interface-specific policy rules are supported.
A compliant implementation of a MIDCOM protocol MAY support the use of interface-specific policy rules. Either both or neither of the optional inside and outside interface parameters in PRR, PER, and PRS MUST be included if interface-specific policy rules are supported.
A compliant implementation MAY extend the list of parameters of transactions.
A compliant implementation MAY extend the list of parameters of transactions.
A compliant implementation MAY replace a single transaction by a set of more fine-grained transactions. In such a case, it MUST be ensured that requirement 2.1.4 (deterministic behavior) and requirement 2.1.5 (known and stable state) of [MDC-REQ] are still met. When a single transaction is replaced by a set of multiple fine-grained transactions, this set MUST be equivalent to a single transaction. Furthermore, this set of transactions MUST further meet the atomicity requirement stated in section 2.1.4.
A compliant implementation MAY replace a single transaction by a set of more fine-grained transactions. In such a case, it MUST be ensured that requirement 2.1.4 (deterministic behavior) and requirement 2.1.5 (known and stable state) of [MDC-REQ] are still met. When a single transaction is replaced by a set of multiple fine-grained transactions, this set MUST be equivalent to a single transaction. Furthermore, this set of transactions MUST further meet the atomicity requirement stated in section 2.1.4.
Stiemerling, et al. Standards Track [Page 49] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling, et al. Standards Track [Page 49] RFC 5189 MIDCOM Protocol Semantics March 2008
3.2. Middlebox Conformance
3.2. Middlebox Conformance
A middlebox implementation of a MIDCOM protocol supports a request transaction if it is able to receive and process all possible correct message instances of the particular request transaction and if it generates a correct reply for any correct request it receives.
A middlebox implementation of a MIDCOM protocol supports a request transaction if it is able to receive and process all possible correct message instances of the particular request transaction and if it generates a correct reply for any correct request it receives.
A middlebox implementation of a MIDCOM protocol supports an asynchronous transaction if it is able to generate the corresponding notification message properly.
A middlebox implementation of a MIDCOM protocol supports an asynchronous transaction if it is able to generate the corresponding notification message properly.
A compliant middlebox implementation of a MIDCOM protocol must inform the agent about the list of supported transactions within the SE transaction.
A compliant middlebox implementation of a MIDCOM protocol must inform the agent about the list of supported transactions within the SE transaction.
3.3. Agent Conformance
3.3. Agent Conformance
An agent implementation of a MIDCOM protocol supports a request transaction if it can generate the corresponding request message properly and if it can receive and process all possible correct replies to the particular request.
An agent implementation of a MIDCOM protocol supports a request transaction if it can generate the corresponding request message properly and if it can receive and process all possible correct replies to the particular request.
An agent implementation of a MIDCOM protocol supports an asynchronous transaction if it can receive and process all possible correct message instances of the particular transaction.
An agent implementation of a MIDCOM protocol supports an asynchronous transaction if it can receive and process all possible correct message instances of the particular transaction.
A compliant agent implementation of a MIDCOM protocol must not use any optional transaction that is not supported by the middlebox. The middlebox informs the agent about the list of supported transactions within the SE transaction.
A compliant agent implementation of a MIDCOM protocol must not use any optional transaction that is not supported by the middlebox. The middlebox informs the agent about the list of supported transactions within the SE transaction.
4. Transaction Usage Examples
4. Transaction Usage Examples
This section gives two usage examples of the transactions specified in section 2. The first shows how an agent can explore all policy rules and policy rule groups that it may access at a middlebox. The second example shows the configuration of a middlebox in combination with the setup of a voice over IP session with the Session Initiation Protocol (SIP) [RFC3261].
This section gives two usage examples of the transactions specified in section 2. The first shows how an agent can explore all policy rules and policy rule groups that it may access at a middlebox. The second example shows the configuration of a middlebox in combination with the setup of a voice over IP session with the Session Initiation Protocol (SIP) [RFC3261].
4.1. Exploring Policy Rules and Policy Rule Groups
4.1. Exploring Policy Rules and Policy Rule Groups
This example assumes an already established session. It shows how an agent can find out
This example assumes an already established session. It shows how an agent can find out
- which groups it may access and who owns these groups, - the status and member list of all accessible groups, and - the status and properties of all accessible policy rules.
- which groups it may access and who owns these groups, - the status and member list of all accessible groups, and - the status and properties of all accessible policy rules.
Stiemerling, et al. Standards Track [Page 50] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling, et al. Standards Track [Page 50] RFC 5189 MIDCOM Protocol Semantics March 2008
If there is just a single session, these actions are not needed, because the middlebox informs the agent about each state transition of any policy rule or policy rule group. However, after the disruption of a session or after an intentional session termination, the agent might want to re-establish the session and explore which of the groups and policy rules it established are still in place.
If there is just a single session, these actions are not needed, because the middlebox informs the agent about each state transition of any policy rule or policy rule group. However, after the disruption of a session or after an intentional session termination, the agent might want to re-establish the session and explore which of the groups and policy rules it established are still in place.
Also, an agent system may fail and another one may take over. Then the new agent system needs to find out what has already been configured by the failing system and what still needs to be done.
Also, an agent system may fail and another one may take over. Then the new agent system needs to find out what has already been configured by the failing system and what still needs to be done.
A third situation where exploring policy rules and groups is useful is the case of an agent with 'administrator' authorization. This agent may access and modify any policy rule or group created by any other agent.
A third situation where exploring policy rules and groups is useful is the case of an agent with 'administrator' authorization. This agent may access and modify any policy rule or group created by any other agent.
All agents will probably start their exploration with the Group List (GL) transaction, as shown in Figure 5. On this request, the middlebox returns a list of pairs, each containing an agent identifier and a group identifier (GID). The agent is informed which of its own groups and which other agents' groups it may access.
All agents will probably start their exploration with the Group List (GL) transaction, as shown in Figure 5. On this request, the middlebox returns a list of pairs, each containing an agent identifier and a group identifier (GID). The agent is informed which of its own groups and which other agents' groups it may access.
agent middlebox | GL | |**********************************************>| |<**********************************************| | (agent1,GID1) (agent1,GID2) (agent2,GID3) | | | | GS GID2 | |**********************************************>| |<**********************************************| | agent1 lifetime PID1 PID2 PID3 PID4 | | |
agent middlebox | GL | |**********************************************>| |<**********************************************| | (agent1,GID1) (agent1,GID2) (agent2,GID3) | | | | GS GID2 | |**********************************************>| |<**********************************************| | agent1 lifetime PID1 PID2 PID3 PID4 | | |
Figure 5: Using the GL and the GS Transactions
Figure 5: Using the GL and the GS Transactions
In Figure 5, three groups are accessible to the agent, and the agent retrieves information about the second group by using the Group Status (GS) transaction. It receives the owner of the group, the remaining lifetime, and the list of member policy rules, in this case containing four policy rule identifiers (PIDs).
In Figure 5, three groups are accessible to the agent, and the agent retrieves information about the second group by using the Group Status (GS) transaction. It receives the owner of the group, the remaining lifetime, and the list of member policy rules, in this case containing four policy rule identifiers (PIDs).
In the following, the agent explores these four policy rules. The example assumes that the middlebox is a traditional NAPT. Figure 6 shows the exploration of the first policy rule. In reply to a Policy Rule Status (PRS) transaction, the middlebox always returns the following list of parameters:
In the following, the agent explores these four policy rules. The example assumes that the middlebox is a traditional NAPT. Figure 6 shows the exploration of the first policy rule. In reply to a Policy Rule Status (PRS) transaction, the middlebox always returns the following list of parameters:
Stiemerling, et al. Standards Track [Page 51] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling, et al. Standards Track [Page 51] RFC 5189 MIDCOM Protocol Semantics March 2008
- policy rule owner - group identifier - policy rule action (reserve or enable) - protocol type - port range - direction - internal IP address - internal port number - external address - external port number - middlebox inside IP address - middlebox inside port number - middlebox outside IP address - middlebox outside port number - IP address versions (not printed) - middlebox service (not printed) - inside and outside interface (optional, not printed)
- policy rule owner - group identifier - policy rule action (reserve or enable) - protocol type - port range - direction - internal IP address - internal port number - external address - external port number - middlebox inside IP address - middlebox inside port number - middlebox outside IP address - middlebox outside port number - IP address versions (not printed) - middlebox service (not printed) - inside and outside interface (optional, not printed)
agent middlebox | PRS PID1 | |**********************************************>| |<**********************************************| | agent1 GID2 RESERVE UDP 1 "" | | ANY ANY ANY ANY | | ANY ANY IPADR_OUT PORT_OUT1 | | |
agent middlebox | PRS PID1 | |**********************************************>| |<**********************************************| | agent1 GID2 RESERVE UDP 1 "" | | ANY ANY ANY ANY | | ANY ANY IPADR_OUT PORT_OUT1 | | |
Figure 6: Status Report for an Outside Reservation
Figure 6: Status Report for an Outside Reservation
The 'ANY' parameter printed in Figure 6 is used as a placeholder in policy rule status replies for policy reserve rules. The policy rule with PID1 is a policy reserve rule for UDP traffic at the outside of the middlebox. Since this is a reserve rule, direction is empty. As there is no internal or external address involved yet, these four fields are wildcarded in the reply. The same holds for the inside middlebox address and port number. The only address information given by the reply is the reserved outside IP address of the middlebox (IPADR_OUT) and the corresponding port number (PORT_OUT1). Note that IPADR_OUT and PORT_OUT1 may not be wildcarded, as the reserve action does not support this.
The 'ANY' parameter printed in Figure 6 is used as a placeholder in policy rule status replies for policy reserve rules. The policy rule with PID1 is a policy reserve rule for UDP traffic at the outside of the middlebox. Since this is a reserve rule, direction is empty. As there is no internal or external address involved yet, these four fields are wildcarded in the reply. The same holds for the inside middlebox address and port number. The only address information given by the reply is the reserved outside IP address of the middlebox (IPADR_OUT) and the corresponding port number (PORT_OUT1). Note that IPADR_OUT and PORT_OUT1 may not be wildcarded, as the reserve action does not support this.
Applying PRS to PID2 (Figure 7) shows that the second policy rule is a policy enable rule for inbound UDP packets. The internal destination is fixed concerning IP address, protocol, and port number, but for the external source, the port number is wildcarded. The outside IP address and port number of the middlebox are what the external sender needs to use as destination in the original packet it sends. At the middlebox, the destination address is replaced with
Applying PRS to PID2 (Figure 7) shows that the second policy rule is a policy enable rule for inbound UDP packets. The internal destination is fixed concerning IP address, protocol, and port number, but for the external source, the port number is wildcarded. The outside IP address and port number of the middlebox are what the external sender needs to use as destination in the original packet it sends. At the middlebox, the destination address is replaced with
Stiemerling, et al. Standards Track [Page 52] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling, et al. Standards Track [Page 52] RFC 5189 MIDCOM Protocol Semantics March 2008
the internal address of the final receiver. During address translation, the source IP address and the source port numbers of the packets remain unchanged. This is indicated by the inside address, which is identical to the external address.
the internal address of the final receiver. During address translation, the source IP address and the source port numbers of the packets remain unchanged. This is indicated by the inside address, which is identical to the external address.
agent middlebox | PRS PID2 | |**********************************************>| |<**********************************************| | agent1 GID2 ENABLE UDP 1 IN | | IPADR_INT PORT_INT1 IPADR_EXT ANY | | IPADR_EXT ANY IPADR_OUT PORT_OUT2 | | |
agent middlebox | PRS PID2 | |**********************************************>| |<**********************************************| | agent1 GID2 ENABLE UDP 1 IN | | IPADR_INT PORT_INT1 IPADR_EXT ANY | | IPADR_EXT ANY IPADR_OUT PORT_OUT2 | | |
Figure 7: Status Report for Enabled Inbound Packets
Figure 7: Status Report for Enabled Inbound Packets
For traditional NATs, the identity of the inside IP address and port number with the external IP address and port number always holds (A1=A3 in Figure 3). For a pure firewall, the outside IP address and port number are always identical with the internal IP address and port number (A0=A2 in Figure 3).
For traditional NATs, the identity of the inside IP address and port number with the external IP address and port number always holds (A1=A3 in Figure 3). For a pure firewall, the outside IP address and port number are always identical with the internal IP address and port number (A0=A2 in Figure 3).
agent middlebox | PRS PID3 | |**********************************************>| |<**********************************************| | agent1 GID2 ENABLE UDP 1 OUT | | IPADR_INT PORT_INT2 IPADR_EXT PORT_EXT1 | | IPADR_EXT PORT_EXT1 IPADR_OUT PORT_OUT3 | | |
agent middlebox | PRS PID3 | |**********************************************>| |<**********************************************| | agent1 GID2 ENABLE UDP 1 OUT | | IPADR_INT PORT_INT2 IPADR_EXT PORT_EXT1 | | IPADR_EXT PORT_EXT1 IPADR_OUT PORT_OUT3 | | |
Figure 8: Status Report for Enabled Outbound Packets
Figure 8: Status Report for Enabled Outbound Packets
Figure 8 shows enabled outbound UDP communication between the same host. Here all port numbers are known. Since again A1=A3, the internal sender uses the external IP address and port number as destination in the original packets. At the firewall, the internal source IP address and port number are replaced by the shown outside IP address and port number of the middlebox.
Figure 8 shows enabled outbound UDP communication between the same host. Here all port numbers are known. Since again A1=A3, the internal sender uses the external IP address and port number as destination in the original packets. At the firewall, the internal source IP address and port number are replaced by the shown outside IP address and port number of the middlebox.
Stiemerling, et al. Standards Track [Page 53] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling, et al. Standards Track [Page 53] RFC 5189 MIDCOM Protocol Semantics March 2008
agent middlebox | PRS PID4 | |**********************************************>| |<**********************************************| | agent1 GID2 ENABLE TCP 1 BI | | IPADR_INT PORT_INT3 IPADR_EXT PORT_EXT2 | | IPADR_EXT PORT_EXT2 IPADR_OUT PORT_OUT4 | | |
エージェントmiddlebox| PRS PID4| |**********************************************>| |<**********************************************| | agent1 GID2 ENABLE TCP1BI| | _IPADR_INTポートINT3 IPADR_EXTポート_EXT2| | _IPADR_EXTのポート_EXT2 IPADRの_の出ているポートOUT4| | |
Figure 9: Status Report for Bidirectional TCP Traffic
図9: 双方向のTCPトラフィックのための現状報告
Finally, Figure 9 shows the status report for enabled bidirectional TCP traffic. Note that, still, A1=A3. For outbound packets, only the source IP address and port number are replaced at the middlebox, and for inbound packets, only the destination IP address and port number are replaced.
最終的に、図9は可能にされた双方向のTCPトラフィックのための現状報告を示しています。 その、それでもA1=A3に注意してください。 外国行きのパケットに関しては、middleboxでソースIPアドレスとポートナンバーだけを取り替えます、そして、本国行きのパケットに関して、送付先IPアドレスとポートナンバーだけを取り替えます。
4.2. Enabling a SIP-Signaled Call
4.2. 一口で合図された呼び出しを可能にします。
This elaborated transaction usage example shows the interaction between a back-to-back user agent (B2BUA) and a middlebox. The middlebox itself is a traditional Network Address and Port Translator (NAPT), and two SIP user agents communicate with each other via the B2BUA and a NAPT, as shown in Figure 10. The MIDCOM agent is co- located with the B2BUA, and the MIDCOM server is at the middlebox. Thus, the MIDCOM protocol runs between the B2BUA and the middlebox.
この練られたトランザクション使用例は背中合わせのユーザエージェント(B2BUA)とmiddleboxとの相互作用を示しています。 middlebox自身は伝統的なNetwork AddressとPort Translator(NAPT)です、そして、2人のSIPユーザエージェントがB2BUAとNAPTを通して互いにコミュニケートします、図10に示されるように。 MIDCOMエージェントはB2BUAと共に共同見つけられています、そして、MIDCOMサーバがmiddleboxにあります。 したがって、MIDCOMプロトコルはB2BUAとmiddleboxの間で稼働しています。
+-------------+ | B2BUA | | for domain ++++ | example.com | + +-------------+ + ^ ^ + Private | | + Public Network Network | | + +----------+ | | +----+------+ +----------------+ | SIP User |<-+ +->| Middlebox |<------->| SIP User Agent | | Agent A |<#######>| NAPT |<#######>| B@example.org | +----------+ +-----------+ +----------------+
+-------------+ | B2BUA| | ドメイン++++のために| example.com| + +-------------+ + ^ ^ + Private | | + 公衆通信回線ネットワーク| | + +----------+ | | +----+------+ +----------------+ | 一口ユーザ| <、-+ +->| Middlebox| <、-、-、-、-、-、--、>| 一口ユーザエージェント| | エージェントA|<#######>| NAPT|<#######>| B@example.org | +----------+ +-----------+ +----------------+
<--> SIP signaling <##> RTP traffic ++++ MIDCOM protocol
<--SIPが議定書を作ると+ + + + <##>RTPトラフィックMIDCOMに合図する>。
Figure 10: Example of a SIP Scenario
図10: 一口シナリオに関する例
Stiemerling, et al. Standards Track [Page 54] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[54ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
For the sequence charts below, we make these assumptions:
以下の系列チャートに関しては、私たちはこれらの仮定をします:
- The NAPT is statically configured to forward SIP signaling from the outside to the B2BUA -- i.e., traffic to the NAPT's external IP address and port 5060 is forwarded to the internal B2BUA.
- NAPTは外部からB2BUAまでシグナリングをSIPに送るために静的に構成されます--すなわち、NAPTの外部のIPアドレスとポート5060へのトラフィックを内部のB2BUAに送ります。
- The SIP user agent A, located inside the private network, is registered at the B2BUA with its private IP address.
- 私設のネットワークの中に位置したSIPユーザエージェントAはB2BUAにプライベートIPアドレスに登録されます。
- User A knows the general SIP URL of user B. The URL is B@example.org. However, the concrete URL of the SIP user agent B, which user B currently uses, is not known.
- ユーザAはユーザB.について一般的なSIP URLを知っています。URLは B@example.org です。 しかしながら、SIPユーザエージェントBの具体的なURLは知られていません。(ユーザBは現在、そのエージェントを使用します)。
- The RTP paths are configured, but not the RTP Control Protocol (RTCP) paths.
- RTP経路が構成されますが、RTP Controlプロトコル(RTCP)経路は構成されません。
- The middlebox and the B2BUA share an established MIDCOM session.
- middleboxとB2BUAは確立したMIDCOMセッションを共有します。
- Some parameters are omitted, such as the request identifier (RID).
- いくつかのパラメタが要求識別子(RID)などのように省略されます。
Furthermore, the following abbreviations are used:
その上、以下の略語は使用されています:
- IP_AI: Internal IP address of user agent A - P_AI: Internal port number of user agent A to receive RTP data - P_AE: External mapped port number of user agent A - IP_AE: External IP address of the middlebox - IP_B: IP address of user agent B - P_B: Port number of user agent B to receive RTP data - GID: Group identifier - PID: Policy rule identifier
- IP_AI: ユーザエージェントAの内部のIPアドレス--P_AI: RTPデータを受け取るユーザエージェントAの内部のポートナンバー--_P AE: ユーザエージェントAの外部の写像しているポートナンバー--_IP AE: middleboxの外部のIPアドレス--IP_B: ユーザエージェントBのIPアドレス--P_B: ユーザエージェントBの数を移植して、RTPデータを受け取ってください--、GID: 識別子を分類してください--、PID: 政策ルール識別子
The abbreviations of the MIDCOM transactions can be found in the particular section headings.
特定のセクション見出しでMIDCOMトランザクションの略語を見つけることができます。
In our example, user A tries to call user B. The user agent A sends an INVITE SIP message to the B2BUA (see Figure 10). The SDP part of the particular SIP message relevant for the middlebox configuration is shown in the sequence chart as follows:
私たちの例では、ユーザAは、ユーザB.をB2BUAにAがINVITE SIPメッセージを送るユーザエージェントと呼ぼうとします(図10を見てください)。 middlebox構成において、関連している特定のSIPメッセージのSDP部分は以下の系列チャートで見せられます:
SDP: m=..P_AI.. c=IP_AI
SDP: m=。P_AI cはIP_AIと等しいです。
where the m tag is the media tag that contains the receiving UDP port number, and the c tag contains the IP address of the terminal receiving the media stream.
mタグが受信を含むメディアタグであるところに、UDPは数を移植します、そして、cタグはメディアストリームを受ける端末のIPアドレスを含んでいます。
Stiemerling, et al. Standards Track [Page 55] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[55ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
The INVITE message forwarded to user agent B must contain a public IP address and a port number to which user agent B can send its RTP media stream. The B2BUA requests a policy enable rule at the middlebox with a PER request with the wildcarded IP address and port number of user agent B. As neither the IP address nor port numbers of user agent B are known at this point, the address of user agent B must be wildcarded. The wildcarded IP address and port number enable the 'early media' capability but result in some insecurity, as any outside host can reach user agent A on the enabled port number through the middlebox.
ユーザエージェントBに転送されたINVITEメッセージはユーザエージェントBがRTPメディアストリームを送ることができる公共のIPアドレスとポートナンバーを含まなければなりません。 方針が可能にするB2BUA要求は、ユーザエージェントB.Asのwildcarded IPアドレスとポートナンバーがあるPER要求があるmiddleboxでIPアドレスもユーザエージェントBのポートナンバーもここに知られていないと裁決して、ユーザエージェントBのアドレスをwildcardedしなければなりません。 wildcarded IPアドレスとポートナンバーは何らかの不安定における'早めのメディア'能力にもかかわらず、結果を可能にします、どんな外部のホストもmiddleboxを通して可能にされたポートナンバーのユーザエージェントAに連絡できるとき。
User Agent B2BUA Middlebox User Agent A NAPT B | | | | | INVITE | | | | B@example.org | | | | SDP:m=..P_AI.. | | | | c=IP_AI | | | |--------------->| | | | | | | | | PER PID1 UDP 1 EVEN IN | | | | IP_AI P_AI ANY ANY 300s | | | |*****************************>| | | |<*****************************| | | | PER OK GID1 PID1 ANY ANY | | | | IP_AE P_AE1 300s | |
ユーザエージェントのB2BUA MiddleboxユーザエージェントはNAPT Bです。| | | | | 招待| | | | B@example.org | | | | SDP: m=。P_AI。 | | | | cはIP_AIと等しいです。| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、|、|、|、|、| 中のさえPID1 UDP1単位で| | | | IP_AI P_AI、いずれ、もどんな300| | | |*****************************>|、|、| |<*****************************| | | | PERは少しも少しもGID1 PID1を承認します。| | | | IP_AE P_AE1 300s| |
Figure 11: PER with Wildcard Address and Port Number
図11: ワイルドカードアドレスとポートナンバーがあるPER
A successful PER reply, as shown in Figure 11, results in a NAT binding at the middlebox. This binding enables UDP traffic from any host outside user agent A's private network to reach user agent A. So user agent B could start sending traffic immediately after receiving the INVITE message, as could any other host -- even hosts that are not intended to participate, such as any malicious host.
図11に示されるうまくいっているPER回答はmiddleboxで付くNATをもたらします。 この結合は、ユーザエージェントAの私設のネットワークの外におけるどんなホストからのUDPトラフィックもSoユーザエージェントBがINVITEメッセージを受け取る直後トラフィックを送り始めることができたユーザエージェントA.に届くのを可能にします、いかなる他のホストであることができたことのようにも--どんな悪意があるホストなどのようにも参加することを意図しないホストさえ。
If the middlebox does not support or does not permit IP address wildcarding for security reasons, the PER request will be rejected with an appropriate failure reason, like 'IP wildcarding not supported'. Nevertheless, the B2BUA needs an outside IP address and port number at the middlebox (the NAPT) in order to forward the SIP INVITE message.
middleboxがどんなサポートもしないか、または安全保障上の理由でIPアドレスwildcardingを可能にしないと、PER要求は適切な失敗理由で拒絶されるでしょう、'サポートされなかったIP wildcarding'のように。 それにもかかわらず、B2BUAは、SIP INVITEメッセージを転送するためにmiddlebox(NAPT)で外のIPアドレスとポートナンバーを必要とします。
If the IP address of user agent B is still not known (it will be sent by user agent B in the SIP reply message) and IP address wildcarding is not permitted, the B2BUA uses the PRR transaction.
ユーザエージェントBのIPアドレスがまだ知られていなくて(それはSIP応答メッセージのユーザエージェントBによって送られるでしょう)、またIPアドレスwildcardingが受入れられないなら、B2BUAはPRRトランザクションを使用します。
Stiemerling, et al. Standards Track [Page 56] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[56ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
By using the PRR request, the B2BUA requests an outside IP address and port number (see Figure 12) without already establishing a NAT binding or pin hole. The PRR request contains the service parameter 'tw' -- i.e., the MIDCOM agent chooses the default value. In this configuration, with NAPT and without a twice-NAT, only an outside address is reserved. In the SDP payload of the INVITE message, the B2BUA replaces the IP address and port number of user agent A with the reserved IP address and port from the PRR reply (see Figure 12). The SIP INVITE message is forwarded to user agent B with a modified SDP body containing the outside address and port number, to which user agent B will send its RTP media stream.
PRR要求を使用することによって、既にNAT結合かピンホールを確立しないで、B2BUAは外のIPアドレスとポートナンバー(図12を見る)を要求します。 PRR要求は'tw'というサービスパラメタを含んでいます--すなわち、MIDCOMエージェントはデフォルト値を選びます。 この構成、NAPT、および2倍NATがなければ、外のアドレスだけが予約されています。 INVITEメッセージのSDPペイロードでは、B2BUAはユーザエージェントAのIPアドレスとポートナンバーをPRR回答から予約されたIPアドレスとポートに置き換えます(図12を見てください)。 変更されたSDPボディーがユーザエージェントBがRTPメディアストリームを送る外のアドレスとポートナンバーを含んでいるユーザエージェントBにSIP INVITEメッセージを転送します。
User Agent B2BUA Middlebox User Agent A NAPT B | | | | ...PER in Figure 11 has failed, continuing with PRR ... | | | | | |PRR tw v4 v4 A UDP 1 EVEN 300s| | | |*****************************>| | | |<*****************************| | | | PRR OK PID1 GID1 EMPTY | | | | IP_AE/P_AE 300s | | | | | | | | INVITE B@example.org SDP:m=..P_AE.. c=IP_AE | | |-------------------------------------------->| | |<--------------------------------------------| | | 200 OK SDP:m=..P_B.. c=IP_B |
ユーザエージェントのB2BUA MiddleboxユーザエージェントはNAPT Bです。| | | | ...PRRを続行して、図11のPERは失敗しました… | | | | | |PRR tw v4 v4A UDP1EVEN300s| | | |*****************************>|、|、| |<*****************************| | | | PRR OK PID1 GID1は空になります。| | | | IP_AE/P_AE300s| | | | | | | | B@example.org SDPを招待してください: m=。P_AE.. cはIP_AEと等しいです。| | |-------------------------------------------->| | |<--------------------------------------------| | | 200はSDPを承認します: m=。P_B. cはIP_Bと等しいです。|
Figure 12: Address Reservation with PRR Transaction
図12: PRRトランザクションとのアドレス予約
This SIP '200 OK' reply contains the IP address and port number at which user agent B will receive a media stream. The IP address is assumed to be equal to the IP address from which user agent B will send its media stream.
このSIP'200OK'回答はユーザエージェントBがメディアストリームを受けるIPアドレスとポートナンバーを含んでいます。 IPアドレスがユーザエージェントBがメディアストリームを送るIPアドレスと等しいと思われます。
Now, the B2BUA has sufficient information for establishing the complete NAT binding with a policy enable rule (PER) transaction; i.e., the UDP/RTP data of the call can flow from user agent B to user agent A. The PER transaction references the reservation by passing the PID of the PRR (PID1).
今、B2BUAは方針で拘束力がある完全なNATを確立するための十分な情報に規則(PER)トランザクションを可能にさせます。 すなわち、呼び出しに関するUDP/RTPデータはユーザエージェントBからユーザエージェントA.まで流れることができます。PERトランザクションは、PRR(PID1)のPIDを渡すことによって、予約に参照をつけます。
For the opposite direction, UDP/RTP data from user agent A to B has to be enabled also. This is done by a second PER transaction with all the necessary parameters (see Figure 13). The request message contains the group identifier (GID1) the middlebox has assigned in the first PER transaction. Therefore, both policy rules have become
また、逆方向に関しては、ユーザエージェントAからBまでのUDP/RTPデータは可能にされなければなりません。 2番目のPERトランザクションはすべての必要なパラメタでこれをします(図13を見てください)。 要求メッセージはmiddleboxが最初のPERトランザクションで割り当てたグループ識別子(GID1)を含んでいます。 したがって、両方の政策ルールはなりました。
Stiemerling, et al. Standards Track [Page 57] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[57ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
members of the same group. After having enabled both UDP/RTP streams, the B2BUA can forward the '200 OK' SIP message to user agent A to indicate that the telephone call can start.
同じくらいのメンバーは分類します。 両方のUDP/RTPストリームを可能にした後に、B2BUAは、通話が始まることができるのを示すために'200OK'SIPメッセージをユーザエージェントAに転送できます。
User Agent B2BUA Middlebox User Agent A NAPT B | | | | | | PER PID1 UDP 1 SAME IN | | | | IP_AI P_AI IP_B ANY 300s | | | |*****************************>| | | |<*****************************| | | | PER OK GID1 PID1 IP_B ANY | | | | IP_AE P_AE1 300s | | | | | | ...media stream from user agent B to A enabled... | | | | | | PER GID1 UDP 1 SAME OUT | | | | IP_AI ANY IP_B P_B 300s | | | |*****************************>| | | |<*****************************| | | | PER OK GID1 PID2 IP_B P_B | | | | IP_AE P_AE2 300s | | | | | | ...media streams from both directions enabled... | | | | | 200 OK | | | |<---------------| | | | SDP:m=..P_B.. | | | | c=IP_B | | |
ユーザエージェントのB2BUA MiddleboxユーザエージェントはNAPT Bです。| | | | | | PID1 UDP1の同じIN単位で| | | | IP_AI P_AI IP_Bはあらゆる300です。| | | |*****************************>|、|、| |<*****************************| | | | PERは少しもGID1 PID1IP_Bを承認します。| | | | IP_AE P_AE1 300s| | | | | | ...メディアはBからAが可能にしたユーザエージェントから流れます… | | | | | | 外で同じGID1 UDP1単位で| | | | IP_AIはあらゆるIP_B P_B300sです。| | | |*****************************>|、|、| |<*****************************| | | | OK GID1 PID2IP_B P_B単位で| | | | IP_AE P_AE2 300s| | | | | | ...可能にされた両方の方向からのメディアストリーム… | | | | | 200 OK| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| SDP: m=。P_B.。 | | | | cはIP_Bと等しいです。| | |
Figure 13: Policy Rule Establishment for UDP Flows
図13: UDPのための政策ルール設立は流れます。
User agent B decides to terminate the call and sends its 'BYE' SIP message to user agent A. The B2BUA forwards all SIP messages and terminates the group afterwards, using a group lifetime change (GLC) transaction with a requested remaining lifetime of 0 seconds (see Figure 14). Termination of the group includes terminating all member policy rules.
ユーザエージェントBは、呼び出しを終えると決めて、B2BUAがすべてのSIPメッセージを転送するユーザエージェントA.に'BYE'SIPメッセージを送って、その後グループを終えます、0秒の要求された残っている生涯があるグループ生涯変化(GLC)トランザクションを使用して(図14を見てください)。 グループの終了は、すべてのメンバー政策ルールを終えるのを含んでいます。
Stiemerling, et al. Standards Track [Page 58] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[58ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
User Agent B2BUA Middlebox User Agent A NAPT B | | | | | BYE | BYE | |<---------------|<--------------------------------------------| | | | | | 200 OK | 200 OK | |--------------->|-------------------------------------------->| | | | | | | GLC GID1 0s | | | |*****************************>| | | |<*****************************| | | | GLC OK 0s | | | | | | ...both NAT bindings for the media streams are removed...
ユーザエージェントのB2BUA MiddleboxユーザエージェントはNAPT Bです。| | | | | さようなら| さようなら| |<---------------|<--------------------------------------------| | | | | | 200 OK| 200 OK| |--------------->|-------------------------------------------->| | | | | | | GLC GID1 0s| | | |*****************************>|、|、| |<*****************************| | | | GLC OK0s| | | | | | ...メディアストリームのための両方のNAT結合を取り除きます…
Figure 14: Termination of Policy Rule Groups
図14: 政策ルールグループの終了
5. Compliance with MIDCOM Requirements
5. MIDCOM要件への承諾
This section explains the compliance of the specified semantics with the MIDCOM requirements. It is structured according to [MDC-REQ]:
このセクションはMIDCOM要件への指定された意味論のコンプライアンスについて説明します。 [MDC-REQ]に従って、それは構造化されます:
- Compliance with Protocol Machinery Requirements (section 5.1) - Compliance with Protocol Semantics Requirements (section 5.2) - Compliance with Security Requirements (section 5.3)
- プロトコル機械要件(セクション5.1)への承諾--プロトコル意味論要件(セクション5.2)への承諾--セキュリティ要件への承諾(セクション5.3)
The requirements are referred to with the number of the section in which they are defined: "requirement x.y.z" refers to the requirement specified in section x.y.z of [MDC-REQ].
それらが定義されるセクションの数で要件は言及されます: 「要件x.y.z」は[MDC-REQ]のセクションx.y.zの規定された要件を示します。
5.1. Protocol Machinery Requirements
5.1. プロトコル機械要件
5.1.1. Authorized Association
5.1.1. 認可された協会
The specified semantics enables a MIDCOM agent to establish an authorized association between itself and the middlebox. The agent identifies itself by the authentication mechanism of the Session Establishment transaction described in section 2.2.1. Based on this authentication, the middlebox can determine whether or not the agent will be permitted to request a service. Thus, requirement 2.1.1 is met.
指定された意味論は、MIDCOMエージェントがそれ自体とmiddleboxとの認可された協会を設立するのを可能にします。 エージェントはセクション2.2.1で説明されたSession特権階級トランザクションの認証機構で身元を明らかにします。 この認証に基づいて、middleboxは、エージェントがサービスを要求することが許可されるかどうか決定できます。 したがって、要件2.1.1は会われます。
Stiemerling, et al. Standards Track [Page 59] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[59ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
5.1.2. Agent Connects to Multiple Middleboxes
5.1.2. エージェントは複数のMiddleboxesに接続します。
As specified in section 2.2, the MIDCOM protocol allows the agent to communicate with more than one middlebox simultaneously. The selection of a mechanism for separating different sessions is left to the concrete protocol definition. It must provide a clear mapping of protocol messages to open sessions. Then requirement 2.1.2 is met.
セクション2.2で指定されるように、エージェントは同時に、MIDCOMプロトコルで1middleboxとコミュニケートできます。 異なったセッションを切り離すためのメカニズムの選択は具体的なプロトコル定義に残されます。 それはプロトコルメッセージの明確なマッピングを公開審議に提供しなければなりません。 そして、要件2.1.2は会われます。
5.1.3. Multiple Agents Connect to Same Middlebox
5.1.3. 複数のエージェントが同じMiddleboxに接続します。
As specified in section 2.2, the MIDCOM protocol allows the middlebox to communicate with more than one agent simultaneously. The selection of a mechanism for separating different sessions is left to the concrete protocol definition. It must provide a clear mapping of protocol messages to open sessions. Then requirement 2.1.3 is met.
セクション2.2で指定されるように、middleboxは同時に、MIDCOMプロトコルで1人以上のエージェントとコミュニケートできます。 異なったセッションを切り離すためのメカニズムの選択は具体的なプロトコル定義に残されます。 それはプロトコルメッセージの明確なマッピングを公開審議に提供しなければなりません。 そして、要件2.1.3は会われます。
5.1.4. Deterministic Behavior
5.1.4. 決定論的な振舞い
Section 2.1.2 states that the processing of a request of an agent may not be interrupted by any request of the same or another agent. This provides atomicity among request transactions and avoids race conditions resulting in unpredictable behavior by the middlebox.
セクション2.1 .2 エージェントの要求の処理が同じくらいのどんな要求か別のエージェントによっても中断されないかもしれないと述べます。 これは、要求トランザクションに最小単位を提供して、middleboxで予測できない振舞いをもたらす競合条件を避けます。
The behavior of the middlebox can only be predictable in the view of its administrators. In the view of an agent, the middlebox behavior is unpredictable, as the administrator can, for example, modify the authorization of the agent at any time without the agent being able to observe this change. Consequently, the behavior of the middlebox is not necessarily deterministic from the point of view of any agent.
middleboxの動きは管理者の視点だけで予測できる場合があります。 エージェントの視点では、middleboxの振舞いは予測できません、例えば、管理者がいつでもこの変化を観測できるエージェントなしでエージェントの承認を変更できるとき。 その結果、middleboxの動きは必ずどんなエージェントの観点からも決定論的であるというわけではありません。
As predictability of the middlebox behavior is given for its administrator, requirement 2.1.4 is met.
振舞いが与えられているmiddleboxの予見性として、管理者、要件2.1.4は会われます。
5.1.5. Known and Stable State
5.1.5. 知られていて安定した状態
Section 2.1 states that request transactions are atomic with respect to each other and from the point of view of an agent. All transactions are clearly defined as state transitions that either leave the current stable, well-defined state and enter a new stable, well-defined one or that remain in the current stable, well-defined state. Section 2.1 clearly demands that intermediate states are not stable and are not reported to any agent.
セクション2.1は、要求トランザクションが互いとエージェントの観点から原子であると述べます。 すべてのトランザクションが明確に現在の安定して、明確な状態を出て、新しい安定して、明確なものに入るか、または現在の安定して、明確な州に残っている状態遷移と定義されます。 セクション2.1は、中間的州が安定していないのを明確に要求して、どんなエージェントにも報告されません。
Furthermore, for each state transition a message is sent to the corresponding agent, either a reply or a notification. The agent can uniquely map each reply to one of the requests that it sent to the middlebox, because agent-unique request identifiers are used for this purpose. Notifications are self-explanatory by their definition.
その上、各状態遷移において、対応するエージェント(回答か通知のどちらか)にメッセージを送ります。 エージェントは唯一middleboxに発信したという要求の1つに各回答を写像できます、エージェントユニークな要求識別子がこのために使用されるので。 通知は彼らの定義で自明です。
Stiemerling, et al. Standards Track [Page 60] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[60ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
Furthermore, the Group List transaction (section 2.4.3), the Group Status transaction (section 2.4.4), the Policy Rule List transaction (section 2.3.11), and the Policy Rule Status transaction (section 2.3.12) allow the agent at any time during a session to retrieve information about
その上、Group Listトランザクション(セクション2.4.3)、Group Statusトランザクション(セクション2.4.4)、Policy Rule Listトランザクション(セクション2.3.11)、およびPolicy Rule Statusトランザクション(セクション2.3.12)はいつでも、情報を検索するセッションの間、エージェントを許容します。
- all policy rule groups it may access, - the status and member policy rules of all accessible groups, - all policy rules it may access, and - the status of all accessible policy rules.
- そして、それがアクセスするかもしれない政策ルールグループ--すべての理解できるグループの状態とメンバー政策ルール--すべてのすべての方針が、アクセスするかもしれないと裁決する、--すべてのアクセスしやすい方針の状態は統治されます。
Therefore, the agent is precisely informed about the state of the middlebox (as far as the services requested by the agent are affected), and requirement 2.1.5 is met.
したがって、エージェントにmiddlebox(エージェントによって要求されたサービスが影響を受ける限り)、および要件状態に関して正確に知らされる、2.1、.5、会われます。
5.1.6. Status Report
5.1.6. 現状報告
As argued in the previous section, the middlebox unambiguously informs the agent about every state transition related to any of the services requested by the agent. Also, at any time the agent can retrieve full status information about all accessible policy rules and policy rule groups. Thus, requirement 2.1.6 is met.
前項で論争されるように、middleboxはエージェントによって要求されたサービスのいずれにも関連するあらゆる状態遷移に関して明白にエージェントに知らせます。 また、いつでも、エージェントはすべてのアクセスしやすい政策ルールと政策ルールグループの完全な状態情報を検索できます。 したがって、要件2.1.6は会われます。
5.1.7. Unsolicited Messages (Asynchronous Notifications)
5.1.7. お節介なメッセージ(非同期な通知)
The semantics includes asynchronous notifications messages from the middlebox to the agent, including the Session Termination Notification (STN) message, the Policy Rule Event Notification (REN) message, and the Group Event Notification (GEN) message (see section 2.1.2). These notifications report every change of state of policy rules or policy rule groups that was not explicitly requested by the agent. Thus, requirement 2.1.7 is met by the semantics specified above.
意味論はmiddleboxからエージェントまでの非同期な通知メッセージを含んでいます、Session Termination Notification(STN)メッセージ、Policy Rule Event Notification(REN)メッセージ、およびGroup Event Notification(GEN)メッセージを含んでいて(セクション2.1.2を見てください)。 これらの通知はエージェントによって明らかに要求されなかった政策ルールか政策ルールグループの状態のあらゆる変化を報告します。 したがって、要件2.1.7は上で指定された意味論によって会われます。
5.1.8. Mutual Authentication
5.1.8. 互いの認証
As specified in section 2.2.1, the semantics requires mutual authentication of agent and middlebox, by using either two subsequent Session Establishment transactions or mutual authentication provided on a lower protocol layer. Thus, requirement 2.1.8 is met.
セクション2.2.1で指定されるように、意味論はエージェントとmiddleboxの互いの認証を必要とします、2つのその後のSession特権階級トランザクションか低級プロトコル層で提供された互いの認証のどちらかを使用することによって。 したがって、要件2.1.8は会われます。
5.1.9. Session Termination by Any Party
5.1.9. どんなパーティによるセッション終了
The semantics specification states in section 2.2.2 that the agent may request session termination by generating the Session Termination request and that the middlebox may not reject this request. In turn, section 2.2.3 states that the middlebox may send the Asynchronous
意味論仕様は、セクション2.2.2でエージェントがSession Termination要求を生成することによってセッション終了を要求するかもしれなくて、middleboxがこの要求を拒絶しないかもしれないと述べます。 順番に、セクション2.2.3は、middleboxがAsynchronousを送るかもしれないと述べます。
Stiemerling, et al. Standards Track [Page 61] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[61ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
Session Termination notification at any time and then terminate the session. Thus, requirement 2.1.9 is met.
いつでもセッションTermination通知とその時はセッションを終えます。 したがって、要件2.1.9は会われます。
5.1.10. Request Result
5.1.10. 結果を要求してください。
Section 2.1 states that each request of an agent is followed by a reply of the middlebox indicating either success or failure. Thus, requirement 2.2.10 is met.
セクション2.1は、成功か失敗のどちらかを示すmiddleboxの回答がエージェントの各要求のあとに続くと述べます。 したがって、要件2.2.10は会われます。
5.1.11. Version Interworking
5.1.11. バージョンの織り込むこと
Section 2.2.1 states that the agent needs to specify the protocol version number that it will use during the session. The middlebox may accept this and act according to this protocol version or may reject the session if it does not support this version. If the session setup is rejected, the agent may try again with another version. Thus, requirement 2.2.11 is met.
セクション2.2 .1 エージェントが、それがセッションの間に使用するプロトコルバージョン番号を指定する必要であると述べます。 このバージョンをサポートしないなら、middleboxはこれを受け入れて、このプロトコルバージョンによると、行動するか、またはセッションを拒絶するかもしれません。 セッションセットアップが拒絶されるなら、エージェントは別のバージョンで再試行するかもしれません。 したがって、要件2.2.11は会われます。
5.1.12. Deterministic Handling of Overlapping Rules
5.1.12. 重なることの決定論的な取り扱いは統治されます。
The only policy rule actions specified are 'reserve' and 'enable'. For firewalls, overlapping enable actions or reserve actions do not create any conflict, so a firewall will always accept overlapping rules as specified in section 2.3.2 (assuming the required authorization is given).
指定された唯一の政策ルール動作が、'蓄え'と'可能にする'です。 ファイアウォールに、重なって、動作を可能にしてください。さもないと、蓄えの動作が少しの闘争も引き起こさないので、ファイアウォールは、いつも規則を重ね合わせるのがセクション2.3.2で指定されていると受け入れるでしょう(必要な承認を仮定するのを与えます)。
For NATs, reserve and enable may conflict. If a conflicting request arrives, it is rejected, as stated in section 2.3.2. If an overlapping request arrives that does not conflict with those it overlaps, it is accepted (assuming the required authorization is given).
NATs、予約して、可能にする、闘争するかもしれません。 闘争要求が到着するなら、それはセクション2.3.2で述べられているように拒絶されます。 ものと衝突しない重なっている要求が到着するなら、重なって、それを受け入れます(必要な承認を仮定するのを与えます)。
Therefore, the behavior of the middlebox in the presence of overlapping rules can be predicted deterministically, and requirement 2.1.12 is met.
したがって、決定論的に規則を重ね合わせることの面前でmiddleboxの動きを予測できる、要件、2.1、.12、会われます。
5.2. Protocol Semantics Requirements
5.2. プロトコル意味論要件
5.2.1. Extensible Syntax and Semantics
5.2.1. 広げることができる構文と意味論
Requirement 2.2.1 explicitly requests extensibility of protocol syntax. This needs to be addressed by the concrete protocol definition. The semantics specification is extensible anyway, because new transactions may be added.
要件2.2.1は明らかにプロトコル構文の伸展性を要求します。 これは、具体的なプロトコル定義で扱われる必要があります。 新しいトランザクションが加えられるかもしれないので、意味論仕様はとにかく広げることができます。
Stiemerling, et al. Standards Track [Page 62] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[62ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
5.2.2. Policy Rules for Different Types of Middleboxes
5.2.2. Middleboxesの異なったタイプのための政策ルール
Section 2.3 explains that the semantics uses identical transactions for all middlebox types and that the same policy rule can be applied to all of them. Thus, requirement 2.2.2 is met.
セクション2.3は意味論がすべてのmiddleboxタイプに同じトランザクションを使用して、彼らのすべてに同じ政策ルールは当てはまることができると説明します。 したがって、要件2.2.2は会われます。
5.2.3. Ruleset Groups
5.2.3. Rulesetグループ
The semantics explicitly supports grouping of policy rules and transactions on policy rule groups, as described in section 2.4. The group transactions can be used for lifetime extension and termination of all policy rules that are members of the particular group. Thus, requirement 2.2.3 is met.
意味論はセクション2.4で説明されるように政策ルールグループで明らかに政策ルールとトランザクションの組分けをサポートします。 特定のグループのメンバーであるすべての政策ルールの生涯拡大と終了にグループトランザクションを使用できます。 したがって、要件2.2.3は会われます。
5.2.4. Policy Rule Lifetime Extension
5.2.4. 政策ルール生涯拡大
The semantics includes a transaction for explicit lifetime extension of policy rules, as described in section 2.3.3. Thus, requirement 2.2.4 is met.
意味論はセクション2.3.3で説明されるように政策ルールの明白な生涯拡大のためのトランザクションを含んでいます。 したがって、要件2.2.4は会われます。
5.2.5. Robust Failure Modes
5.2.5. 強健な故障モード
The state transitions at the middlebox are clearly specified and communicated to the agent. There is no intermediate state reached by a partial processing of a request. All requests are always processed completely, either successfully or unsuccessfully. All request transactions include a list of failure reasons. These failure reasons cover indication of invalid parameters where applicable. In case of failure, one of the specified reasons is returned from the middlebox to the agent. Thus, requirement 2.2.5 is met.
middleboxの状態遷移は、明確に指定されて、エージェントに伝えられます。 要求の部分的な処理で達するどんな中間的状態もありません。 すべての要求がいつも処理されて完全で、首尾よいか失敗した。 すべての要求トランザクションが失敗理由のリストを含んでいます。 これらの失敗理由は無効のパラメタのしるしを適切であるところにカバーしています。 失敗の場合には、middleboxからエージェントまで指定された理由の1つを返します。 したがって、要件2.2.5は会われます。
5.2.6. Failure Reasons
5.2.6. 失敗理由
The semantics includes a failure reason parameter in each failure reply. Thus, requirement 2.2.6 is met.
意味論はそれぞれの失敗回答に失敗理由パラメタを含んでいます。 したがって、要件2.2.6は会われます。
5.2.7. Multiple Agents Manipulating Same Policy Rule
5.2.7. 同じ政策ルールを操る複数のエージェント
As specified in sections 2.3 and 2.4, each installed policy rule and policy rule group has an owner, which is the authenticated agent that created the policy rule or group, respectively. The authenticated identity is input to authorize access to policy rules and groups.
セクション2.3と2.4で指定されるように、各インストールされた政策ルールと方針は、グループには政策ルールを作成した認証されたエージェントである所有者がいると裁決するか、またはそれぞれ分類されます。 認証されたアイデンティティは、政策ルールとグループへのアクセスを認可するために入力されます。
If the middlebox is sufficiently configurable, its administrator can configure it so that one authenticated agent is authorized to access and modify policy rules and groups owned by another agent. Because specified semantics does not preclude this, it meets requirement 2.2.7.
middleboxが十分構成可能であるなら、管理者がそれを構成できるので、別のエージェントによって所有されていた政策ルールとグループをアクセスして、1人の認証されたエージェントが変更するのに権限を与えられます。 指定された意味論がこれを排除しないので、それは要件2.2.7に会います。
Stiemerling, et al. Standards Track [Page 63] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[63ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
5.2.8. Carrying Filtering Rules
5.2.8. 規則をフィルターにかけながら、運びます。
The Policy Enable Rule transaction specified in section 2.3.8 can carry 5-tuple filtering rules. This meets requirement 2.2.8.
セクション2.3.8で指定されたPolicy Enable Ruleトランザクションは規則をフィルターにかける5-tupleを運ぶことができます。 これは要件2.2.8に会います。
5.2.9. Parity of Port Numbers
5.2.9. ポートナンバーの同等
As specified in section 2.3.6, the agent is able to request keeping the port parity when reserving port numbers with the PRR transaction (see section 2.3.8) and when establishing address bindings with the PER transaction (see section 2.3.9). Thus, requirement 2.2.9 is met.
セクション2.3.6で指定されるように、エージェントはPERトランザクションでアドレス結合を確立しながら、PRRトランザクション(セクション2.3.8を見る)でポートナンバーを予約するときポートの同等を保って、いつを要求できるか(セクション2.3.9を見てください)。 したがって、要件2.2.9は会われます。
5.2.10. Consecutive Range of Port Numbers
5.2.10. 連続した範囲のポートナンバー
As specified in section 2.3.6, the agent is able to request a consecutive range of port numbers when reserving port numbers with the PRR transaction (see section 2.3.8) and when establishing address bindings or pinholes with the PER transaction (see section 2.3.9). Thus, requirement 2.2.10 is met.
PRRトランザクションでポートナンバーを予約するとき、セクション2.3.6で指定されていて、エージェントが連続した範囲のポートナンバーを要求できて(セクション2.3.8を見てください)、PERトランザクションでアドレス結合かピンホールを確立する(セクション2.3.9を見ます)時。 したがって、要件2.2.10は会われます。
5.2.11. Contradicting Overlapping Policy Rules
5.2.11. 政策ルールを重ね合わせながら、反駁します。
Requirement 2.2.11 is based on the assumption that contradictory policy rule actions, such as 'enable'/'allow' and 'disable'/'disallow', are supported. In conformance with decisions made by the working group after finalizing the requirements document, this requirement is not met by the semantics because no 'disable'/'disallow' action is supported.
要件、2.2、.11、相容れない政策ルール動き(/が'禁じる'であると'可能にする'か、'許容し'て、または'無効にする')がサポートされるという仮定に基づいています。 要件ドキュメントを成立させるこの必要条件は満たされなかった後までに決定がワーキンググループによってされている順応では、いいえが動作を'無効にする'か、または'禁じる'ので、意味論はサポートされます。
5.3. Security Requirements
5.3. セキュリティ要件
5.3.1. Authentication, Confidentiality, Integrity
5.3.1. 認証、秘密性、保全
The semantics definition supports mutual authentication of agent and middlebox in the Session Establishment transaction (section 2.2.1). The use of an underlying protocol such as TLS or IPsec is mandatory. Thus, requirement 2.3.1 is met.
意味論定義はSession特権階級トランザクション(セクション2.2.1)でエージェントとmiddleboxの互いの認証をサポートします。 TLSかIPsecなどの基本的なプロトコルの使用は義務的です。 したがって、要件2.3.1は会われます。
5.3.2. Optional Confidentiality of Control Messages
5.3.2. コントロールメッセージの任意の秘密性
The use of IPsec or TLS allows agent and middlebox to use an encryption method (including no encryption). Thus, requirement 2.3.2 is met.
IPsecかTLSの使用で、エージェントとmiddleboxは暗号化メソッドを使用できます(暗号化を全く含んでいなくて)。 したがって、要件2.3.2は会われます。
Stiemerling, et al. Standards Track [Page 64] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[64ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
5.3.3. Operation across Untrusted Domains
5.3.3. 信頼されていないドメイン中の操作
Operation across untrusted domains is supported by mutual authentication and by the use of TLS or IPsec protection. Thus, requirement 2.3.3 is met.
信頼されていないドメイン中の操作は互いの認証とTLSかIPsec保護の使用でサポートされます。 したがって、要件2.3.3は会われます。
5.3.4. Mitigate Replay Attacks
5.3.4. 反射攻撃を緩和してください。
The specified semantics mitigates replay attacks and meets requirement 2.3.4 by requiring mutual authentication of agent and middlebox, and by mandating the use of TLS or IPsec protection.
指定された意味論が反射攻撃を緩和して、必要条件を満たす、2.3、.4、エージェントとmiddleboxの互いの認証を必要として、TLSかIPsec保護の使用を強制することによって。
Further mitigation can be provided as part of a concrete MIDCOM protocol definition -- for example, by requiring consecutively increasing numbers for request identifiers.
例えば連続して要求識別子の数を増強するのを必要とすることによって、具体的なMIDCOMプロトコル定義の一部としてさらなる緩和を提供できます。
6. Security Considerations
6. セキュリティ問題
The interaction between a middlebox and an agent (see [MDC-FRM]) is a very sensitive point with respect to security. The configuration of policy rules from a middlebox-external entity appears to contradict the nature of a middlebox. Therefore, effective means have to be used to ensure
middleboxとエージェント([MDC-FRM]を見る)との相互作用はセキュリティに関する非常に敏感なポイントです。 middlebox-外部実体からの政策ルールの構成はmiddleboxの自然に矛盾するように見えます。 したがって、効果的な手段は確実にするのにおいて使用されていなければなりません。
- mutual authentication between agent and middlebox, - authorization, - message integrity, and - message confidentiality.
- そして、エージェントとmiddleboxの間の互いの認証--承認--メッセージの保全、--メッセージ秘密性。
The semantics defines a mechanism to ensure mutual authentication between agent and middlebox (see section 2.2.1). In combination with the authentication, the middlebox is able to decide whether an agent is authorized to request an action at the middlebox. The semantics relies on underlying protocols, such as TLS or IPsec, to maintain message integrity and confidentiality of the transferred data between both entities.
意味論は、エージェントとmiddleboxの間の互いの認証を確実にするためにメカニズムを定義します(セクション2.2.1を見てください)。 認証と組み合わせて、middleboxは、エージェントがmiddleboxで動作を要求するのに権限を与えられるかどうか決めることができます。 意味論は、両方の実体の間のわたっているデータのメッセージの保全と秘密性を維持するためにTLSかIPsecなどの基本的なプロトコルを当てにします。
For the TLS and IPsec use, both sides must use securely configured credentials for authentication and authorization.
TLSとIPsec使用のために、両側は認証と承認のためのしっかりと構成された資格証明書を使用しなければなりません。
The configuration of policy rules with wildcarded IP addresses and port numbers results in certain risks, such as opening overly wildcarded policy rules. An excessively wildcarded policy rule would be A0 and A3 with IP address set to 'any' IP address, for instance. This type of pinhole would render the middlebox, in the sense of security, useless, as any packet could traverse the middlebox without further checking. The local policy of the middlebox should reject such policy rule enable requests.
wildcarded IPアドレスとポートナンバーがある政策ルールの構成は特定のリスクをもたらします、初めのひどくwildcardedされた政策ルールなどのように。 過度にwildcardedされた政策ルールはA0でしょう、そして、IPアドレスがあるA3は例えば、'any'のIPアドレスにセットしました。 このタイプのピンホールはmiddleboxをレンダリングするでしょう、安心感で、役に立ちません、どんなパケットもさらにチェックしないでmiddleboxを横断できたとき。 middleboxのローカルの方針がそのような方針を拒絶するべきであるので、規則は要求を可能にします。
Stiemerling, et al. Standards Track [Page 65] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[65ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
A reasonable default configuration for wildcarding would be that only one port number may be wildcarded and all IP addresses must be set without wildcarding. However, there are some cases where security needs to be balanced with functionality.
wildcardingするための妥当なデフォルト設定は1つのポートナンバーだけをwildcardedしてもよくて、wildcardingしないですべてのIPアドレスを設定しなければならないということでしょう。 しかしながら、いくつかのケースがセキュリティが機能性とバランスをとる必要があるところにあります。
The example described in section 4.2 shows how SIP-signaled calls can be served in a secure way without wildcarding IP addresses. But some SIP-signaled applications make use of early media (see section 5.5 of [RFC3398]). To receive early media, the middleboxes need to be configured before the second participant in a session is known. As it is not known, the IP address of the second participant needs to be wildcarded.
セクション4.2で説明された例はどう安全な方法でIPアドレスをwildcardingしないでSIPによって合図された呼び出しに役立つことができるかを示しています。 しかし、いくつかのSIPによって合図されたアプリケーションが早めのメディアを利用します([RFC3398]のセクション5.5を見てください)。 早めのメディアを受け取るために、middleboxesは、セッションの2番目の関係者が知られている前に構成される必要があります。 それが知られていないように、2番目の関係者のIPアドレスは、wildcardedされる必要があります。
In such cases and in several similar ones, there is a security policy decision to be made by the middlebox operator. The operator can configure the middlebox so that it supports more functionality, for example, by allowing wildcarded IP addresses, or so that network operation is more secure, for example, by disallowing wildcarded IP addresses.
そのような場合といくつかの同様のものには、middleboxオペレータによって作られているという安全保障政策決定があります。 例えば、オペレータがmiddleboxを構成できるので、wildcarded IPアドレスを許容することによって、より多くの機能性をサポートするか、またはしたがって、例えば、そのネットワーク操作はwildcarded IPアドレスを禁じることによって、より安全です。
7. IAB Considerations on UNSAF
7. UNSAFの上のIAB問題
UNilateral Self-Address Fixing (UNSAF) is described in [RFC3424] as a process at originating endpoints that attempt to determine or fix the address (and port) by which they are known to another endpoint. UNSAF proposals, such as Simple Traversal of the UDP Protocol through NAT (STUN) [RFC3489], are considered as a general class of workarounds for NAT traversal and as solutions for scenarios with no middlebox communication (MIDCOM).
UNilateral Self-アドレスFixing(UNSAF)は[RFC3424]でそれらが別の終点に知られているアドレス(そして、ポート)を決定するか、または修理するのを試みる終点を溯源するのにプロセスと説明されます。 NAT(STUN)[RFC3489]を通したUDPプロトコルのSimple TraversalなどのUNSAF提案はmiddleboxコミュニケーション(MIDCOM)のないシナリオのためのNAT縦断と解答としての一般的なクラスの回避策であるとみなされます。
This document describes the protocol semantics for such a middlebox communication (MIDCOM) solution. MIDCOM is not intended as a short- term workaround, but more as a long-term solution for middlebox communication. In MIDCOM, endpoints are not involved in allocating, maintaining, and deleting addresses and ports at the middlebox. The full control of addresses and ports at the middlebox is located at the MIDCOM server.
このドキュメントはそのようなmiddleboxコミュニケーション(MIDCOM)解決のためにプロトコル意味論について説明します。 MIDCOMは短い用語回避策として意図するのではなく、さらにmiddleboxコミュニケーションの長期的な解決法として意図します。 MIDCOMでは、終点はmiddleboxでアドレスとポートを割り当てて、維持して、削除するのにかかわりません。 middleboxのアドレスとポートの完全なコントロールはMIDCOMサーバで位置しています。
Therefore, this document addresses the UNSAF considerations in [RFC3424] by proposing a long-term alternative solution.
したがって、このドキュメントは、長期の代替のソリューションを提案することによって、[RFC3424]のUNSAF問題を扱います。
8. Acknowledgements
8. 承認
We would like to thank all the people contributing to the semantics discussion on the mailing list for a lot of valuable comments.
多くの貴重なコメントのためのメーリングリストについての意味論議論に貢献するすべての人々に感謝申し上げます。
Stiemerling, et al. Standards Track [Page 66] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[66ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
9.2. Informative References
9.2. 有益な参照
[MDC-FRM] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002.
そして、[MDC-FRM]Srisuresh、P.、Kuthan、J.、ローゼンバーグ、J.、モリトル、A.、A.Rayhanと、「Middlebox通信アーキテクチャとフレームワーク」、RFC3303(2002年8月)
[MDC-REQ] Swale, R., Mart, P., Sijben, P., Brim, S., and M. Shore, "Middlebox Communications (midcom) Protocol Requirements", RFC 3304, August 2002.
[MDC-REQ]低湿地、R.、市場、P.、Sijben、P.、縁、S.、およびM.は、「Middleboxコミュニケーション(midcom)プロトコル要件」と支えます、RFC3304、2002年8月。
[MDC-SEM] Stiemerling, M., Quittek, J., and T. Taylor, "Middlebox Communications (MIDCOM) Protocol Semantics", RFC 3989, February 2005.
[MDC-SEM] Stiemerling、M.、Quittek、J.、およびT.テイラー、「Middleboxコミュニケーション(MIDCOM)プロトコル意味論」、RFC3989、2005年2月。
[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月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346] Dierks、T.、およびE.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302] ケント、S.、「IP認証ヘッダー」、RFC4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S.、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC4303、2005年12月。
[RFC3198] 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.
[RFC3198] Westerinen、A.、Schnizlein、J.、Strassner、J.、Scherling、M.、クイン、B.、ハーツォグ、S.、Huynh、A.、カールソン、M.、ペリー、J.、およびS.Waldbusser、「方針を拠点とする管理のための用語」、RFC3198(2001年11月)。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
Stiemerling, et al. Standards Track [Page 67] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[67ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
[RFC3398] Camarillo, G., Roach, A., Peterson, J., and L. Ong, "Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping", RFC 3398, December 2002.
[RFC3398]キャマリロ(G.、ローチ、A.、ピーターソン、J.、およびL.オング)は、「サービスディジタル通信網(ISDN)ユーザ部分(ISUP)をセッション開始プロトコル(一口)マッピングと統合しました」、RFC3398、2002年12月。
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
[RFC3424] DaigleとL.とIAB、「一方的な自己アドレスのためのネットワークアドレス変換の向こう側に(UNSAF)を修理するIAB問題」、RFC3424、2002年11月。
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003.
[RFC3489] ローゼンバーグ、J.、ワインバーガー、J.、Huitema、C.、およびR.マーイ、「気絶させてください--ネットワークアドレス変換機構(NATs)を通したユーザー・データグラム・プロトコル(UDP)の簡単な縦断」、RFC3489、2003年3月。
Stiemerling, et al. Standards Track [Page 68] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[68ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
Appendix A. Changes from RFC 3989
RFC3989からの付録A.変化
1. The example in section 4.2 used a SIP proxy server modifying the body of a SIP message. This was a violation of RFC 3261. This has been fixed by replacing the SIP proxy server with a back-to- back user agent.
1. セクション4.2の例はSIPメッセージのボディーを変更するSIPプロキシサーバを使用しました。 これはRFC3261の違反でした。 これは、SIPプロキシサーバを後部から戻っているユーザへのエージェントに取り替えることによって、修理されました。
2. Clarifications concerning the used set of transaction types have been added.
2. 中古のトランザクションタイプに関する明確化は加えられます。
3. Section 3.1, "General Implementation Conformance", now uses key words from RFC 2119.
3. 「一般実装順応」というセクション3.1は現在、RFC2119からのキーワードを使用します。
4. Minor editorial changes have been made and references have been updated.
4. 小さい方の編集の変更を行いました、そして、参照をアップデートしました。
Authors' Addresses
作者のアドレス
Martin Stiemerling NEC Europe Ltd. Kurfuersten-Anlage 36 69115 Heidelberg Germany
マーチンStiemerling NECヨーロッパLtd.Kurfuersten-原基36 69115ハイデルベルグドイツ
Phone: +49 6221 4342-113 EMail: stiemerling@nw.neclab.eu
以下に電話をしてください。 +49 6221 4342-113 メールしてください: stiemerling@nw.neclab.eu
Juergen Quittek NEC Europe Ltd. Kurfuersten-Anlage 36 69115 Heidelberg Germany
ユルゲンQuittek NECヨーロッパLtd.Kurfuersten-原基36 69115ハイデルベルグドイツ
Phone: +49 6221 4342-115 EMail: quittek@nw.neclab.eu
以下に電話をしてください。 +49 6221 4342-115 メールしてください: quittek@nw.neclab.eu
Tom Taylor Nortel 1852 Lorraine Ave. Ottawa, Ontario Canada K1H 6Z8
トム・テイラーノーテル1852ロレーヌAve。 オンタリオオタワ(カナダ)K1H 6Z8
Phone: +1 613 763 1496 EMail: tom.taylor@rogers.com
以下に電話をしてください。 +1 1496年の613 763メール: tom.taylor@rogers.com
Stiemerling, et al. Standards Track [Page 69] RFC 5189 MIDCOM Protocol Semantics March 2008
Stiemerling、他 標準化過程[69ページ]RFC5189MIDCOMは2008年の意味論行進のときに議定書を作ります。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Stiemerling, et al. Standards Track [Page 70]
Stiemerling、他 標準化過程[70ページ]
一覧
スポンサーリンク