Network Working Group M. Stiemerling
Request for Comments: 5189 J. Quittek
Obsoletes: 3989 NEC
Category: Standards Track T. Taylor
Nortel
March 2008
Middlebox Communication (MIDCOM) Protocol Semantics
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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
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.
この文書は、ファイアウォールやネットワークアドレス変換（NAT）などの中間装置と対話するためのMIDCOMエージェントによって使用されるミドルコミュニケーション（MIDCOM）プロトコルのセマンティクスを指定します。意味論の議論は、具体的な構文やトランスポートプロトコルのいずれかの仕様が含まれていません。しかし、具体的なプロトコルは、それのスーパーセットを指定されたセマンティクスを実装するか、可能性が高いと予想されます。 MIDCOMプロトコル意味論はMIDCOMフレームワークから、及びワーキンググループの意思決定から、MIDCOM要件から導出されます。この文書はRFC 3989を廃止します。
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
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
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]とミドルの通信のための要件[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]に記載されている要件に準拠し、セマンティック問題に関するワーキンググループのコンセンサスです。この文書はRFC 3989を廃止[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.
ワーキンググループ憲章に準拠して、意味論の説明は、パケットフィルタおよびネットワークアドレス変換（NAT）をターゲットに、それはこれらのミドルボックスの動的な構成を必要とするアプリケーションをサポートしています。
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）ミドルにおけるリクエストメッセージの処理。 （3）は、それぞれ、要求トランザクションによって引き起こされるか、または非同期トランザクションによって示さミドルにおける状態遷移を。 （4）状態の変化についてのエージェントに通知するためにエージェントにミドルから送信された応答及び通知メッセージを。
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つのトランザクション・タイプをサポートしており、それがトランザクションパラメータに関する十分に柔軟である任意のプロトコルで実現することができます。異なるプロトコルの異なる実装はさらに、トランザクションを追加および/またはトランザクションのセットに取引及び/又は分割単一取引に他のパラメータを追加することによって、以下に記載する意味論を拡張する必要があるかもしれません。かかわらず、そのような拡張の、以下のセマンティクスが実装されなければならないものの必要最小限のサブセットを提供します。
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）
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部4は、2つの精巧な使用例を与えるセクションで定義された意味論に関してMIDCOMプロトコル定義とMIDCOMプロトコル実装のための適合性ステートメントを含みます。最後に、セクション5は、セマンティクスがMIDCOM要件を満たす方法を説明します。
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.
要求トランザクション要求トランザクションは、要求メッセージミドルにエージェントからの転送、ミドルでのメッセージの処理、エージェントにミドルからの応答メッセージの転送、および他の薬剤のミドルから通知メッセージのオプションの転送から成りトランザクションを要求するものより。要求トランザクションは、ミドルでの状態遷移を引き起こす可能性があります。
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.
コンフィギュレーション・トランザクションは、コンフィギュレーション・トランザクションは、ミドルボックスの状態変化のための要求を含む要求トランザクションです。受け入れた場合、それがミドルでの状態変化を引き起こします。
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.
トランザクションを監視する監視トランザクションは、ミドルから状態情報の要求を含む要求トランザクションです。これは、ミドルでの状態遷移が発生することはありません。
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.
非同期トランザクションは、非同期トランザクションは、エージェントによってトリガされていません。これは、ミドルとのセッションに参加するすべてのエージェントなしで発生する可能性があります。潜在的に、非同期トランザクションが開いているセッションに参加エージェントにミドルからの通知メッセージの転送を含んでいます。通知メッセージは、非同期イベントについて通知する必要がある各エージェントに送信されます。メッセージは、ミドルボックスの状態遷移を示しています。
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.
エージェント固有のエージェントユニークな値は、エージェントの文脈の中でユニークです。この文脈では、エージェントが参加するすべての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.
ミドル固有ミドル固有値は、ミドルボックスのコンテキストにおいて独特です。このコンテキストはミドルが参加するすべてのMIDCOMセッションが含まれています。ミドル、一意の値がミドルで割り当てられます。
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".
一般に、ポリシー・ルールは、ポリシー・ルールは、「ポリシーベースのシステムの基本的なビルディングブロックこれは条件のセットにアクションのセットの結合である。 - 条件は、アクションが実行されているかどうかを決定するために評価されている」であります[RFC3198]。 MIDCOM文脈において、条件は、ルールが適用されるパケットのセットの仕様です。アクションのセットは常に「有効」ルールごとに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.
責任準備金は、引当金のアクションを含むポリシールールを支配します。このルールのポリシー条件は常に真です。アクションは、単にIPアドレスの予約またはIPアドレスの組み合わせとどちら側のポート番号の範囲、一面、又はミドル構成に応じてミドルボックスの両側を、です。
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.
ポリシーが有効アクションを含むポリシールールを支配できます。ポリシー条件は、一つ以上の単方向または双方向のパケットフローの記述で構成され、ポリシーアクションがミドルを横断するこのフローに属するパケットを可能にします。記述子は、必要に応じて、ポート番号の範囲と、プロトコル、流れの方向、及び送信元アドレスと宛先アドレスを識別する。
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-TERM]で定義されるように必ずしもNATバインドを参照していないこの文書で使用される用語NATバインディング結合します。 MIDCOMセマンティクスに結合NATは、NATタイプのミドルボックスを介して2つのエンドポイント間の通信を可能にする抽象化を指します。有効アクションは、要求とそのパラメータに応じて、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", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
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.
トランザクションのこのタイプのための記述名をトランザクション名。
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.
トランザクション遵守このエントリは、「必須」または「オプション」のいずれかが含まれています。詳細については、セクション2.1.8を参照してください。
request-parameters This entry lists all parameters necessary for this request. A description for each parameter is given.
リクエスト・パラメータは、このエントリは、この要求のために必要なすべてのパラメータを示します。各パラメータの説明が与えられます。
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.
返信パラメータ（成功）このエントリは、前の要求に対する肯定応答としてエージェントにミドルから返送されたすべてのパラメータを示します。各パラメータの説明が与えられます。
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 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.
通知メッセージ・タイプは、このエントリは、このトランザクションで使用することができる通知メッセージのタイプを記述する。
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.
セマンティクスこのエントリは、トランザクションの実際の意味を説明しています。特に、それはミドルからの要求メッセージの処理について説明し、ミドル状態遷移は、それぞれ、によって引き起こされるか、またはトランザクションを引き起こします。
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.
意味論仕様は中間装置及び仕様及びプロトコルの実装の単純さの動的な構成を必要とするアプリケーションの適切なサポートとの間のバランスを目的とします。
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.
プロトコルの相互作用は、取引に構造化されています。ミドルボックスの状態は、ステートマシンで記述されています。ステートマシンは、状態と状態遷移によって定義されています。単一のトランザクションが発生することがあり、または複数のステートマシンで状態遷移によって引き起こされるが、ステートマシンあたりのトランザクションあたり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).
状態遷移は、ミドルにエージェントからの要求メッセージによって、またはミドルで他のイベントのいずれかによって開始されています。最初のケースでは、ミドルボックスは、実際の状態遷移に応答メッセージを送信することにより、エージェントに通知します。第二に、ミドルボックスは、（それがミドルボックスとオープンセッションに参加している場合）、トランザクションによって影響を受ける各エージェントに迷惑非同期通知メッセージを送信します。
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.
- エージェントがミドルで状態遷移を要求できるようにする設定取引。
- 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.
- エージェントは、ミドルから状態情報を要求することを可能にするトランザクションを監視。
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プロトコルの機能を提供します。彼らは、彼らが関心の確立と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.
モニタリング取引は、状態遷移をミドルに関連するものではありません。彼らはミドルで確立政策ルールの数、状況、およびプロパティを探索するためにエージェントによって使用されています。
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で詳細に規定されているように、コンフィギュレーション・トランザクションと非同期トランザクションがグループ生涯変化（GLC）の以外は必須です。彼らは、対応のミドルで実装する必要があります。 GLCトランザクション監視トランザクションの一部はオプションです。
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種類をサポートしています。種類ごとに、異なるメッセージタイプが存在します。この意味論の文書では、メッセージタイプのみをパラメータのリストによって定義されています。パラメータとその符号化の順序は、具体的なプロトコル定義に残されています。プロトコル定義は、メッセージタイプに他のパラメータを追加したり、意味論で定義されたパラメータに含まれる情報がまだ存在する限り、一つに複数のパラメータを組み合わせることができます。
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.
失敗した要求トランザクションの場合には、負の応答メッセージをエージェントにミドルから送信されます。このメッセージは、すべての要求トランザクションでも同じです。それは応答が送信された要求と失敗の理由を示すパラメータを識別する要求識別子を含みます。
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.
セッション終了通知（STN）、ポリシールールのイベント通知（REN）、グループイベント通知（GEN）：3つの通知メッセージの種類があります。これらのすべては、ミドル固有の通知識別子を含みます。
STN The Session Termination Notification message additionally contains a single parameter indicating the reason for session termination by the middlebox.
STNザセッション終了通知メッセージはさらに、ミドルによりセッション終了の理由を示す単一のパラメータを含んでいます。
REN The Policy Rule Event Notification message contains the notification identifier, a policy rule identifier, and the remaining policy lifetime.
RENザ・ポリシー・ルール・イベント通知メッセージは、通知識別子、ポリシールール識別子、および残りのポリシーの有効期間が含まれています。
GEN The Group Event Notification message contains the notification identifier, a policy rule group identifier, and the remaining policy rule group lifetime.
GEN当グループイベント通知メッセージは、通知識別子、政策ルールグループ識別子、および残りの政策ルールグループの寿命が含まれています。
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を使用して、ポリシールールのセットに取引を簡素化するために使用することができます。
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).
ミドルでのセッションとポリシールールはステートフルです。その状態は、互いに独立しており、そのステートマシン（セッションごとに1と政策ルールごとに1つ）を分離することができます。セマンティクスが選ばれたため、政策ルールグループの状態を暗黙的にグループに属するすべてのポリシールールの状態によって定義されるように、ポリシールールグループもステートフルですが、ミドルポリシールール・グループの状態を維持する必要はありません（セクションを参照してください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台の分離された状態マシンを使用します。具体的なプロトコルの設計と実装のステートマシンは、おそらくここで紹介するステートマシンよりも複雑になりますのでご注意ください。しかし、プロトコル状態マシンは、この文書のセマンティクス・ステート・マシンのスーパーセットであると予想されます。
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.
すべての要求トランザクションは、互いに対してアトミックです。これは、ミドルでのリクエストの処理が到着またはすでにキューに入れられている別の要求によって中断されないことを意味します。ミドルが同時に異なるセッションで送信された要求を受信したとき、これは特に当てはまります。しかしながら、非同期トランザクションが中断および/または任意の時点で要求の処理を終了してもよいです。
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.
すべての要求トランザクションは、エージェントの観点からアトミックです。完全な要求がミドルに到着する前に、要求の処理が開始されません。中間の状態がミドルで安定でなく、中間の状態がどのエージェントに報告されません。
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つの以上のトランザクションに以下の指定された取引の一部を分割する必要がある場合があります。この理由は、特定のプロトコルまたはより多くの柔軟性のための欲望の制約が含まれる場合があります。一般的には、これが問題になることはありません。しかし、影響を受けたトランザクションの原子性を変えるかもしれないことを考慮すべきです。
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.
所有権は、ポリシールールとポリシールール・グループへのアクセスを決定します。ポリシールールを作成すると、ミドル、一意の識別子は、さらに取引でそれを識別するために生成されます。識別子を超え、各ポリシールールは、所有者を有しています。所有者は、ポリシールールを確立し、認証エージェントです。ミドルは、それへのアクセスを制御するポリシールールの所有者属性を使用しています。認証されたエージェントの要求は既存のポリシールールを変更するたびに、ミドルは政策ルールと要求エージェントが所有するエージェントのポリシールールにトランザクションを実行する権限があるかどうかをチェックの所有者を決定します。
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 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.
ミドルボックスは、特定の認証エージェントはある特定の所有者とポリシールールにアクセスして変更できるように構成されてもよいです。確かに、合理的なデフォルトの設定では、各エージェントには、独自のポリシールールにアクセスできます。また、どのエージェントが所有するすべてのポリシールールの変更を許可する、管理者として行動するエージェントのIDを設定するには良いかもしれません。しかし、ミドルでの認証の構成はMIDCOM意味論とプロトコルの範囲外です。
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:
いくつかの理由のために、セッション確立時にエージェントがミドルの特定の機能について学習していることに有用です。したがって、セクション2.2.1に記載のセッション確立手順は、エージェントにミドルから能力情報の転送を含みます。カバーミドル機能のリストは、次のものが含まれます。
- 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機能の一覧、おそらく含む - アドレス変換 - ポート変換 - プロトコル変換 - 二回-NAT - 内部IPアドレスワイルドカードのサポート - 外部IPアドレスワイルドカードのサポート - ポートのワイルドカードのサポート - サポートされているIPのバージョン（複数可） IPv4の、IPv6の、または両方のインターフェイス固有のポリシールールのサポート - - - サポートされるオプションMIDCOMプロトコルトランザクションのリストポリシールールの持続性： - サポートされているIPのバージョン（複数可）外部ネットワークのIPv4、IPv6の、またはその両方：内部ネットワークのための持続的または非永続（ミドルは、不揮発性メモリにルールを保存することができたときにルールが永続的である、例えば、ハードディスクやフラッシュメモリ） - ポリシールールまたはポリシールールグループの最大残りの寿命 - ポリシールールのアイドルタイムアウトミドルで（予約およびミドルによって自動的に削除され、このアイドルタイムアウトの時間のために任意のデータトラフィックによって使用されていないポリシールールを有効にし、ミドルボックスによって、ポリシールールの削除のために、2.3節をご覧ください。 13、 "非同期・ポリシー・ルール・イベント（ARE）"）。 - 同時MIDCOMセッションの最大数
The list of middlebox capabilities may be extended by a concrete protocol specification with further information useful for the agent.
ミドルボックス機能のリストは、エージェントのために有用なさらなる情報を具体的なプロトコル仕様によって拡張することができます。
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 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プロトコルのパラメータとして明示的に渡されていないが、それらは、使用される基礎となる（固定）トランスポート・プロトコルによって提供されてもよいです。ミドルでのエージェントの識別子がミドル、ユニークであり、エージェントのミドル識別子は、それぞれ、エージェントユニークです。
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要件。しかし、ミドルの実際の実装は、これらすべてのトランザクションをサポートすることを必要とされていません。発表されたサポートされるトランザクションの集合は、異なる認証された薬剤のための異なる場合があります。ミドルは、エージェントが実行を許可されているトランザクションに関するセッション確立の能力交換で認証エージェントに通知します。いくつかの取引は、すべての認証済みのエージェントに提供する必要があります。
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サービスで実装する必要があり、認証されたエージェントのそれぞれに提供されなければならなければなりません。オプション取引は、必ずしもミドルで実装する必要はありません。それは、特定の認証済みのエージェントにこれらのオプション取引を提供することがあります。ミドルは、エージェントに、いくつかの1、すべて、または全くオプション取引を提供することがあります。エージェントは、オプションの要求トランザクションを使用することを許可されているかどうか、さらに、この文書で指定されていないミドルの認証手順によって決定されます。
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セッションがエージェントとミドル間の認証および承認の関連付けです。セッションは、エージェントによって開始され、エージェントやミドルのいずれかによって終了することができます。エージェントとミドルの両方が同時に（異なるエンティティとの）いくつかのセッションに参加することができます。異なるセッションを区別するために、各当事者は、ローカルセッション識別子を使用しています。
All transactions are transmitted within this MIDCOM session.
すべてのトランザクションは、このMIDCOMセッション内で送信されます。
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.
最初の二つは、エージェントによって開始された構成の取引であり、そして最後の一つは、ミドルによって開始された非同期トランザクションです。
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.
- ミドルチャレンジ（MC）：ミドルの認証のための認証チャレンジトークン。以下に見られるように、これが唯一のリクエストの最初の反復で存在します。
- 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）：ミドルにエージェントを認証する認証トークン。以下から分かるように、これは材料がミドルチャレンジに応答して、要求の2回目の反復で更新されます。
reply-parameters (success):
返信のパラメータ（成功）：
- request identifier: An identifier matching the identifier request.
- 要求識別子：識別子の要求に合致する識別子。
- middlebox authentication (ma): An authentication token authenticating the middlebox to the agent.
- ミドル認証（ミリアンペア）：エージェントにミドルを認証する認証トークン。
- 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.
- ミドル能力：ミドルの機能を記述したリスト。ミドル機能のリストについては、セクション2.1.6を参照してください。
failure reason:
失敗の理由：
- authentication failed - no authorization - protocol version of agent and middlebox do not match - lack of resources
- 認証に失敗しました - いいえ承認 - エージェントとミドルのプロトコルバージョンが一致していません - リソースの不足を
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セッションを確立するために使用されます。図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
| |
Figure 1: Mutual Authentication of Agent and Middlebox
図1：エージェントとミドルの相互認証
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].
セッションの確立は、単一のトランザクションを使用することによって簡略化することができます。この場合、サーバのチャレンジとエージェントの課題は、送信者が省略されているか、受信機によって無視され、認証が他の手段によって、例えば、トランスポート層セキュリティ（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.
要求エージェントがMIDCOMセッションを開くことが許可されているかどうか、そのポリシー決定ポイントとミドルをチェックします。そうでない場合は、ミドルは、失敗の理由として「いいえ承認」が負の応答を生成します。認証と承認が成功した場合、セッションが確立され、エージェントがポリシールールとポリシールールグループの取引を要求し始めることができます。
Part of the successful reply is an indication of the middlebox's capabilities.
正常な応答の一部は、ミドルの能力の指標です。
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セッションを閉じるために使用されます。彼らの寿命が切れるまでまたはイベントがそれらを終了するためにミドルを引き起こすことが発生するまでセッション終了後、ミドルは、すべての確立ポリシールールを保持します。
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.
ミドルは、常に正常な応答を生成します。応答を送信した後、ミドルは、現在のセッション内のエージェントに任意の更なるメッセージを送信しません。また、セッション終了要求を処理するか、後で受信しながら、受信したこのセッション内の任意のさらなる要求を処理しません。
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.
- 終了理由：セッションが終了した理由。
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.
ミドルは、いつでもMIDCOMセッションを終了することを決定することができます。実際のセッションを終了する前に、ミドルはSTNのメッセージを生成し、エージェントに送信します。通知を送信した後、ミドルは、それがすでにミドルでキューに入っている場合でも、エージェントによって任意のさらなる要求を処理しません。
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.
彼らの寿命が期限切れになるか、イベントが発生するまでのためにミドルは、それらを終了するまでセッション終了後、ミドルは、すべての確立ポリシールールを保持します。
Unlike in other asynchronous transactions, no more than one notification is sent, because there is only one agent affected by the transaction.
トランザクションによって影響を受ける唯一の薬がありますので他の非同期の取引とは異なり、1つ以下の通知は、送信されません。
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セッションが基盤となるネットワーク接続に基づいている場合、セッションは、この接続の中断によって終了することができます。ミドルはこれを検出した場合、それはすぐにセッションを終了します。確立したポリシールールの効果は非同期セッション終了の場合と同じです。
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.
すべてのセッションは閉じた状態で起動します。相互認証がすでに他の手段によって提供されている場合、成功したSEのトランザクションは、OPENの状態に遷移させることができます。それ以外の場合は、状態NOAUTHへの遷移を引き起こします。この状態から、失敗した二SEトランザクションがCLOSEDの状態に戻ります。成功したSEのトランザクションは、OPENの状態に遷移します。任意の時点で、ASTトランザクションまたは接続不良がCLOSEDの状態への遷移を引き起こして、起こり得ます。 NOAUTHまたはOPENのいずれかから成功したSTの取引もCLOSEDへの復帰を引き起こします。トランザクションのパラメータは、図2で説明されています。 = 0値MCは、空のミドル攻撃を表します。
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 |<---------------+
+----------+
Figure 2: Session State Machine
図2：セッションステートマシン
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） - 非同期政策ルールイベント（ARE）
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）は、エージェントによって開始されたコンフィギュレーション・トランザクションです。第四及び第五（PRL、PRS）トランザクションを監視しています。最後の1（ARE）は、非同期トランザクションです。 PRLおよびPRSトランザクションは政策ルールのステートマシンには影響しません。
Before any transaction can start, a valid MIDCOM session must be established.
すべてのトランザクションを開始する前に、有効なMIDCOMセッションが確立されなければなりません。
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)
- NATバインディング（PER）を構成 - 確立されたポリシールール（RLC）の寿命を延長する - - 削除ポリシールール（RLC）ファイアウォールピンホール（PER）を構成
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の例を参照）が必要です。このようなケースをサポートするために、コアの取引は、サービス提供のための政策リザーブルール（PRR）トランザクションによって拡張されています
- reserving addresses and port numbers at NATs (PRR)
- のNATでアドレスとポート番号を予約する（PRR）
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の両方が政策ルールを確立します。 PRRによって設定され、PERによって設定された場合は、「有効にする」場合は、ルール内のアクションは、「予備」です。
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.
ポリシーリザーブルール（PRR）トランザクションは、ミドル構成に応じて、アドレスどちらの側の予約、片側、またはミドルの両側を確立するために使用されます。トランザクションは、エージェントに予約済みのIPアドレスとポート番号のオプションの範囲を返します。いいえアドレスバインディングやピンホールの構成は、ミドルで実行されません。ミドルでのパケット処理は変わりません。
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プロトコルエンジンの状態遷移は、NATの上と全く同じです。
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]参照）に、唯一の外部アドレスが予約されています。二回-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.
ポリシーの有効化ルール（PER）トランザクションがミドルでパケットの処理に影響を与える政策ルールを確立するために使用されます。その入力パラメータによっては、PRRトランザクションによって確立された予約を利用したり、ゼロから新しいルールを作成することもできます。
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以下でより詳細に記載されています。
Each policy rule has a middlebox-unique identifier.
各ポリシールールは、ミドル、一意の識別子を持っています。
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.)
各ポリシールールは、個々の寿命を持っています。政策ルール寿命が満了した場合、ポリシールールはミドルで終了します。一般的に、ミドルはAREトランザクションによってポリシールールの終了を示します。ポリシールールの有効期間の変更（RLC）トランザクションは、セッションセットアップでミドルで指定された限界まで政策ルールの寿命を延長することができます。また、RLCトランザクションは、ポリシールールの寿命を短くする、またはゼロの寿命を要求することによってポリシールールを削除するために使用することができます。 （そのポリシールールの寿命は、グループ生涯変化（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を指定しない場合、このトランザクションは暗黙のうちに新しいグループを作成します。新しいグループ識別子はミドルで選択されています。エージェントの要求は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.
エージェントは、ポリシールールのステータス（PRS）トランザクションを使用することによって、彼らがアクセスを許可されているすべてのポリシールールの性質や状態を探索することができます。
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.
ポリシールールは、その状態を変更したり、その残りの寿命が以外の方法で変更された場合、時間によって減少している場合、このポリシールールをアクセスし、それがミドルとのオープンセッションに参加することができ、すべてのエージェントは、ミドルで通知されます。状態や寿命の変化が要求メッセージによって明示的に要求された場合には、ミドルは、対応する応答を返すことによって、要求エージェントに通知します。ポリシーにアクセスできる他のすべてのエージェントは、ポリシールールのイベント通知（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.
ミドルボックスは、異なる並列セッションで同時に複数のエージェントを配信することができることに留意されたいです。これらの薬剤の間に、それらによってアクセス可能なポリシールールのセットが重複してもよいです。たとえば、管理者として認証し、それがすべてのエージェントのすべてのポリシーにアクセスすることができ、エージェントがあるかもしれません。またはバックアップエージェント主剤と並行して、セッションを実行し、主剤と同じ実体として自分自身を認証する可能性があります。
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.
PER、PRR、又はRLCトランザクションの場合には、要求側エージェントは、それぞれ、PER、PRR、又はRLC応答を受信します。作成、変更、または終了ポリシールールにアクセスする（かつ、ミドルとオープンセッションに参加する）ことができ、他のすべてのエージェントに、ミドルボックスは、ポリシールール識別子（PID）とポリシーの残り寿命を運ぶRENメッセージを送信します。ルール。
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.
生涯トランケーションまたはエージェントによってトリガされていない他のイベントによってルール終了の場合には、ミドルボックスは、特定のポリシールールにアクセスすることができ、各エージェントにRENメッセージを送信し、それがミドルボックスとオープンセッションに参加します。これは、エージェントが常にそれがアクセスできるすべてのポリシールールの最新の状態を知っていることを保証します。
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アドレスのプレフィックス長 - トランスポートプロトコル - ポート番号 - ポートパリティ - ポート範囲
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のためのミドルを通過するパケットの方向を示しています。 「受信」の場合、UDPパケットは、外部から内部へ横断しています。 「アウトバウンド」の、内側から外側へ。両方の場合において、パケットは一方向のみミドルボックスを通過することができます。双方向の流れは、流れパラメータの方向として「双方向」を介して有効になっています。 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フラグを設定しないと最初のパケットは、外部インターフェイスにミドルボックスに到着しなければなりません。
- 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フラグと、内部インタフェースでミドルに到着しなければなりません。
- 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.
私たちは、アドレス組として、これらのパラメータのセットを参照してください。アドレスタプルは、内部または外部のデバイスまたはミドルに割り当てられたアドレスの通信エンドポイントのいずれかを指定します。図3に示すように、この文書では、我々は、アドレスタプル4種類を区別する。
+----------+ +----------+
| internal | A0 A1 +-----------+ A2 A3 | external |
| endpoint +----------+ middlebox +----------+ endpoint |
+----------+ +-----------+ +----------+
Figure 3: Address Tuples A0 - A3
図3：住所タプル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 - 内部エンドポイント：アドレスタプルA0はミドルに対して、内部ネットワーク内のデバイスの通信エンドポイントを指定します。
- 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 - アドレス内のミドル：住所タプルA1は、内部ネットワーク内のミドルでの仮想通信エンドポイントを指定します。 A1は、ミドルボックス内部エンドポイントから流れるパケットの宛先アドレスと内部エンドポイントにミドルから通過するパケットの送信元です。
- 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 - ミドル外のアドレス：アドレスタプルA2は、外部ネットワーク内のミドルでの仮想通信エンドポイントを指定します。 A2は、ミドルボックスに、外部エンドポイントから通過するパケットの宛先アドレスであり、外部のエンドポイントにミドルから通過するパケットのソースです。
- A3 - external endpoint: Address tuple A3 specifies a communication endpoint of a device within the external network, with respect to the middlebox.
- A3 - 外部エンドポイント：アドレスタプルA3は、ミドルボックスに対して、外部ネットワーク内のデバイスの通信エンドポイントを指定します。
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の場合、A2は、A0とは異なる値が与えられますが、NATは、それらをバインドします。 A1は、A3と同じ値を持っている：それは伝統的なNATであるとして、ファイアウォールとしては、それもあります。
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.
二回-NATの場合は、アドレスの組の2つのバインディングがあります：A1とA2の両方がNATによって値が割り当てられます。アドレスA2外のミドルは、内部エンドポイントA0にバインドされ、アドレスA1内部のミドルは、外部エンドポイントA3にバインドされています。
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.
アドレス組に属するトランザクションパラメータのために、いくつかの制約がそれらを使用するすべてのメッセージのために共通しているものが存在します。したがって、これらの制約は以下に要約されていると説明が提示されているトランザクションのパラメータを記述する際に再び繰り返されていません。
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を超えます）。他のトランスポートプロトコル、例えば、ストリーム制御伝送プロトコル（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の」のいずれかを持っています。ポリシールールでは、IPバージョンパラメータの値は、アドレスタプルA0やA1のため、およびA2とA3で同じでなければなりません。
The value of the IP address parameter must conform with the specified IP version.
IPアドレスパラメータの値は、指定されたIPバージョンに準拠している必要があります。
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.
アドレス組のIPアドレスがワイルドカードすることができます。 IPアドレスのワイルドカードを許可するかしたミドルのローカルポリシーに依存し、それが許される範囲内であるかどうか。また、参照してください6、「セキュリティの考慮事項」。ワイルドカードは、アドレス組のIPアドレスプレフィックス長パラメータで指定されています。 IPアドレスの残りの低い上位ビットがワイルドカードながらプレフィックス長の一般的な使用に伴い、このパラメータは、固定されたIPアドレスの上位桁ビットの数を示します。
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」、または「ANY」のいずれかになります。トランスポートプロトコルパラメータが値を持つ場合「ANY」、ミドルボックスにおけるパケット処理のために考慮される唯一のIPヘッダ - つまりは、トランスポート・ヘッダは考慮されていません。プロトコル・パラメータが「ANY」である場合のパラメータのポート番号、ポート範囲、およびポートパリティの値は無関係です。ポリシールールでは、トランスポートプロトコルパラメータの値は、すべてのアドレスタプル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ポート番号を指定します。値ゼロは、トランスポートプロトコルパラメータで指定されたプロトコルのポートワイルドカードを指定します。ポート番号パラメータが値ゼロを有する場合、ポート範囲パラメータの値は無関係です。トランスポート・プロトコル・パラメータの値に応じて、このパラメータが真にポートを指すことができるか、同等の概念を指すことができます。
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.
ポートパリティパラメータが異なりポリシーリザーブルール（PRRの）のコンテキストで使用し、ポリシールール（の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の文脈では、ポートパリティパラメータは、ミドルボックスに割り当てられたポート番号が、それぞれ対応する内部又は外部のポート番号と同じパリティを有するかどうかをミドルに示します。この文脈において、パラメータは、値「同一の」または「任意」を有しています。値が「同じ」の場合、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 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の値は、1つのポート番号を指定します。ポート範囲パラメータは、各アドレスタプル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は、番号を含むポリシールールのセットにNポリシーP_1、P_2、等価である...、nはポート範囲パラメータの値に等しいP_N。各ポリシールールP_1、P_2、...は、P_N 1.ポリシールールP_1は、それぞれの第1のポート番号が含まれている各々がアドレスタプルA0_1、A1_1、A2_1、およびA3_1のセットを含むのポートレンジパラメータ値を有しますPのアドレスタプル。ポリシールールP_2は、Pの各アドレス組の第2のポート番号を含むそれぞれがアドレスタプルA0_2、A1_2、A2_2、およびA3_2のセットを含みます。等々。
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
通常、薬剤は、（セクション2.3.5を参照）、すなわち、アドレスタプルのみA0とA3の知識を持つポリシールールを要求します。しかし、非常に特殊なケースでは、エージェントは、要求されたポリシールールがバインドされているインタフェースを選択する必要があります。一般的に、ミドルは予約またはポリシールールを有効にする場合、その構成に関する総合的な知識を持っているように、右のインターフェイスの選択について慎重です。インタフェースを選択するエージェントのために、オプションのパラメータは、ポリシーリザーブルール（PRR）と政策ルール（PER）トランザクションを有効に含まれています。これらのパラメータは、と呼ばれています
- inside interface: The selected interface at the inside of the middlebox -- i.e., in the private or protected address realm.
- 内部インターフェイス：ミドルボックスの内部で選択されたインタフェース - プライベートまたは保護されたアドレス領域に、すなわち、。
- outside interface: The selected interface at the outside of the middlebox -- i.e., in the public address realm.
- 外部インタフェース：ミドルボックスの外部で選択されたインターフェース - すなわち、パブリックアドレス領域です。
The Policy Rule Status (PRS) transactions include these optional parameters in their replies when they are supported.
それらがサポートされていたときにポリシールールのステータス（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).
エージェントは、インターフェイス固有のポリシールールは、（セクション2.1.6を参照）ミドル能力を確認することで、ミドルによってサポートされているかどうかをセッション開始時に学ぶことができます。
transaction-name: policy reserve rule
トランザクション名：責任準備金規則
transaction-type: configuration 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に示されているように、この値が供給されない場合、ミドルボックスは、このポリシー準備ルールの新しいグループを割り当てます。
- service: The requested NAT service of the middlebox. Allowed values are 'traditional' or 'twice'.
- サービス：ミドルの要求されたNATサービス。指定可能な値は、「伝統的」または「二度」です。
- internal IP version: Requested IP version at the inside of the middlebox; see section 2.3.5.
- 内部IPバージョン：ミドルの内部で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.
- 内部インターフェイス（オプション）：ミドルボックスの内部の界面。セクション2.3.7を参照してください。
- external IP version: Requested IP version at the outside of the middlebox; see section 2.3.5.
- 外部のIPバージョン：ミドルの外でIPバージョンを要求しました。セクション2.3.5を参照してください。
- outside interface (optional): Interface at the outside of the middlebox; see section 2.3.7.
- 外部インタフェース（オプション）：ミドルボックスの外部にインタフェースとセクション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.
- 政策ルール生涯：要求された政策ルールのためのミドルに生涯提案。
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.
- 政策ルール識別子：ミドル固有のポリシールール識別子。特に後続のPERトランザクションに責任準備金ルールを参照するために、ミドルボックスによって割り当てられ、さらにポリシールールトランザクションにポリシールールハンドルとして使用されます。
- 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.
ミドルボックスの内側に予約IPv4またはIPv6アドレス： - IPアドレスの内部に予約。アウトバウンドフローのために、これは、内部エンドポイントが（図3のA1）、そのパケットを送信する先であろう。内部エンドポイント（図3のA0）に転送するようにインバウンドフローのためには、パケットの見かけの送信元アドレスであろう。ミドル準備金とレポートのみ二回-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.
ミドルボックスの外部側に予約IPv4またはIPv6アドレス： - IPアドレス外予約。インバウンドフローのために、これは外部のエンドポイントが（図3のA2）、そのパケットを送信する先であろう。外部の終点（図3のA3）に転送するようにアウトバウンドフローのために、それはパケットの見かけの送信元アドレスであろう。ミドルボックスは、純粋なファイアウォールとして構成されている場合は、アドレスの空の値は、外部予約がなされなかったことを示しています。また、セクション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.
- 政策ルール生涯：それはPERトランザクションでルールを有効にするポリシーによってすでに交換されていない場合は、予約が取り消されますされた後にmiddleboxによって付与された政策ルール生涯。
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アドレス、トランスポート・タイプ、ポート番号の組み合わせ、およびポート範囲どちら側で、片面、またはミドルボックスの両側を確保するために、このトランザクションタイプを使用することができ。一般的に、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.
要求を受信すると、ミドルは予約が、その構成に基づいて必要とされているどのように多くのアドレス（およびポート）を決定します。それが唯一のパケットフィルタサービスを提供している場合、それは任意の予約を行い、内部に確保し、外部のIPアドレスとポート番号に空の値を返していません。それは二回、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.
A0パラメータ（IPアドレスバージョンの内部には、IPアドレスの内部、およびポート番号内部）は、必要に応じて正しいNATマッピングしたがってA2を決定するミドルボックスで使用することができます。 PRRトランザクションがミドルボックスの内部エンドポイント（A0）のための外部アドレス（A2）を予約した後、ミドルボックスは、この予約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 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.
インターフェイス固有のポリシールールを支持するミドルボックスは、セクション2.3.7で定義されるように、オプションの内部及び外部インタフェースパラメータは、両方の要求に含まれなければならない、あるいはそれらのいずれも含まれるべきです。これらのパラメータの存在下では、ミドルボックスは、インターフェースを選択するために、外部アドレスタプル（外部IPアドレスおよびポート番号）に予約されたインターフェイス、および内部インターフェイスパラメータを選択するために、外部インターフェース・パラメータを使用する内部アドレスタプルで（IPアドレスとポート番号の内部に）予約されています。これらのパラメータが存在しない、ミドルボックスは、その内部の構成に基づいて、特定のインターフェイスを選択します。
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.,
成功した場合には、この取引は、新責任準備金規則を作成します。既存の政策ルールグループが指定されている場合は、新しいポリシールールは、それのメンバーになります。何のポリシーグループが指定されていない場合、新しいグループがその唯一のメンバーとして新しいポリシールールを使用して作成されます。ミドルは、新しいポリシールールのミドル-一意の識別子を生成します。新しいポリシールールの所有者は、要求を送信し、認証済みの薬剤です。ミドルボックスは、すなわち、ゼロより大きく、より少ない又は要求された値の最小値とセッション起動時にミドルボックスによって指定された最大寿命に等しい寿命値を選択します
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
0 <= lt_granted <=最小値（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
実際にミドルによって与えられた寿命lt_grantedされる - - lt_maximumは、セッションセットアップ時に指定した最大寿命である - どこlt_requestedエージェントが要求された寿命があります
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 or twice-NAT service in the special case of a combined twice-NAT/NAT middlebox. A firewall middlebox ignores this parameter.
NAT機能を備えたミドルはいつもPRR要求に応答して、ミドル外部アドレスタプル（A2）を保有しています。組み合わせた二回-NAT / NATミドルの特殊なケースでは、エージェントは、サービスパラメータ「伝統的な」または「二回」を選択することによってのみ、NATサービスや二度NATサービスを要求することができます。任意の好みを持っていないエージェントは「二回」を選択しました。 「伝統的な」値は、伝統的なNATと二回-NATの両方を提供するミドルボックスでは伝統的なNATサービスを選択するために使用する必要があります。 「二回」の場合には、組み合わせた二回-NAT / NATミドル埋蔵A2とA1。 「伝統的な」場合にのみA2の予約になります。エージェントは、常に組み合わせた二回-NAT / NATミドルの特別な場合にのみ、または二回-NATサービスNATを選択するためのPRRトランザクションを使用する必要があります。ファイアウォールのミドルは、このパラメータを無視します。
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.
プロトコル識別子が「ANY」は、内部で利用可能なミドル準備及び/又は外部IPアドレス（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アドレスと指定されたパリティから始まるポート番号の連続した配列のその後組み合わせ、予約され、どちらの側に、片側、またはミドルの両側にある場合、 適切に。 IPアドレス（ES）と連続配列の最初の（最も低い）予約されたポート番号（S）は、エージェントに戻されます。 （これはまた、ポートまたは同等のものをサポートする他のプロトコルにも適用されます。）
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.
新しい責任準備金規則が正常に確立され、応答メッセージは、新しいポリシールールにアクセスすることができます開いているセッションに参加する他の認証されたエージェントが、あるかどうかをチェックし、ミドル、要求元のエージェントに送信されました。後ミドルは、これらの薬剤の一つ以上を検出した場合、それはそれらのそれぞれに新しいポリシールールを報告する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を参照してください。
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, port range, port parity, internal IP version, external IP version.
- 責任準備金規則識別子：PRRトランザクションによって作成された既存の責任準備金規則への参照。参照は、ミドルボックスは、このPERトランザクション内の任意の必要なアドレスとポート番号を割り当てる必要があり、その場合、空であってもよいです。それが空でない場合、次のリクエストパラメータは無関係である：グループ識別子、トランスポートプロトコル、ポート範囲、ポートパリティ、内部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に示されているように、この値が供給されない場合、ミドルボックスは、このポリシー準備ルールの新しいグループを割り当てます。
- 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バージョン：ミドルの内部で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.
- 内部インターフェイス（オプション）：ミドルボックスの内部の界面。セクション2.3.7を参照してください。
- external IP version: Requested IP version at the outside of the middlebox; see section 2.3.5.
- 外部のIPバージョン：ミドルの外で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）のポート番号は、セクション2.3.5を参照します。
- outside interface (optional): Interface at the outside of the middlebox; see section 2.3.7.
- 外部インタフェース（オプション）：ミドルボックスの外部にインタフェースとセクション2.3.7を参照してください。
- policy rule lifetime: A lifetime proposal to the middlebox for the requested policy rule.
- 政策ルール生涯：要求された政策ルールのためのミドルに生涯提案。
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.
- 政策ルール識別子：ミドル固有のポリシールール識別子。これは、ミドルによって割り当てられ、さらに、ポリシールールの取引における政策ルールハンドルとして使用されています。責任準備金規則識別子がリクエストで提供された場合、返されたポリシールール識別子は、同じ値を有します。
- 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.
ミドルボックス（図3のA1）の内部に設けられたIPアドレス： - IPアドレスの内部。二回-NATの場合、このパラメータは、ミドルの内部で予約内部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.
- ポート番号内部：ミドル（図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アドレス（図3のA2）ミドルボックスの外部に設けられた外部IPアドレス。純粋なファイアウォールの場合、このパラメータは、要求に渡された内部IPアドレスと同じになります。他のすべての場合において、この応答パラメータは、ミドルボックスの外部に予約外部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.
- 政策ルール生涯：ミドルによって付与された政策ルールの生涯。
failure reason:
失敗の理由：
- agent not authorized for this transaction
- エージェントは、この取引のために許可されていません
- 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
- このグループにメンバーを追加する権限がありませんエージェント - そのような責任準備金のルール - エージェントは、この責任準備金規則交換する権限がありません - 既存の政策ルールとの競合（例えば、同じ内部アドレス・ポートが別の外ADDRESS-にマッピングされています外部IPのワイルドカードは使用できません - - ポートのペアは） - IPの欠如は、アドレス - ポート番号の欠如 - リソースの不足 - 許可されていない内部IPワイルドカード指定された内部/外部インターフェイスは存在しません - 指定されたサービスのために利用できません指定された内部/外部インターフェイスを - 要求された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.
このトランザクションは、単方向または双方向トラフィックのために、独立してミドルボックスの種類（NAT、NAPT、ファイアウォール、NAT-PT、合成装置）の内部エンドポイントと外部のエンドポイント間の通信を可能にするためにエージェントが使用することができます。
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
エージェントは、（必要に応じてワイルドカードを含む）のエンドポイントを指定する有効リクエストと通信の方向（インバウンド、アウトバウンド、双方向）を送信します。通信エンドポイントはPERトランザクションの基本的な動作をすることによって説明することができる。図3に表示されています
2. the middlebox reserving A1 and A2 or using A1 and A2 from a previous PRR transaction,
2. A1とA2を確保したり、前のPRRトランザクションからA1とA2を使用して、ミドル、
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との間のパケット転送を可能にする、両方の指定された方向に応じて、及び
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 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).
A2 = A0やA1 = A3：純粋なパケットフィルタリングファイアウォールの場合は、返されたアドレスのタプルは、要求と同じです。各パートナーは、相手の本当のアドレスを使用しています。伝統的なNATの場合は、内部エンドポイントは、外部エンドポイント（A1 = A3）の実アドレスを使用することができるが、外部のエンドポイントがNAT（A2！= A0）によって提供されるアドレスタプルを使用しています。二回-NATデバイスの場合は、両方のエンドポイントは、その通信相手に対処するためのNATによって提供されたアドレスのタプルを使用（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または二回-NATと併用されている場合は、答えたアドレスタプルはそれぞれ、純粋な伝統的なNATまたは二回-NATの場合と同じになりますが、ミドルは行わ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で定義されるように、オプションの内部及び外部インタフェースパラメータは、両方の要求に含まれなければならない、あるいはそれらのいずれも含まれるべきです。これらのパラメータの存在下では、ミドルボックスは、インターフェースを選択するために、外部アドレスタプル（外部IPアドレスおよびポート番号）が結合されたインタフェース、および内部インターフェイスパラメータを選択するために、外部インターフェース・パラメータを使用する内部アドレスタプルで（IPアドレスとポート番号の内側に）結合しています。これらのパラメータが存在しない、ミドルボックスは、その内部の構成に基づいて、特定のインターフェイスを選択します。
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.
ポリシー予約ルール識別子を指定するパラメータが空でない場合、参照ポリシールールが存在するかどうか、次にミドルボックスのチェックは、エージェントが許可されているかどうか、このポリシールールを置き換えるには、このポリシールールかどうかポリシー準備ルールがあります。
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に等しいかどうかをチェックすることができます。ミドルボックスは、予約A0に等しくない要求されたA0とPER要求を拒否してもよいし、適切なエラーメッセージを送信しなければなりません。また、ミドルが原因PER要求にA0を変更することがあります。
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.
ミドルは、新しいポリシールールのミドル-一意の識別子を生成します。責任準備金のルールが参照された場合は、責任準備金規則の識別子が再利用されます。
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.
トランスポートプロトコルのパラメータ値が「ANY」である場合には、ミドルボックスは、指定された外部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」の、ミドルは、同様に「ANY」のよう作用するが、要求された場合も、ポートのパリティを維持する、ポート番号の範囲をマップします。
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.
ミドルの構成があるため、利用可能な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.,
ミドルボックスは、すなわち、ゼロより大きく、より少ない又は要求された値の最小値とセッション起動時にミドルボックスによって指定された最大寿命に等しい寿命値を選択します
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
0 <= lt_granted <=最小値（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
実際にミドルによって与えられた寿命lt_grantedされる - - lt_maximumは、セッションセットアップ時に指定した最大寿命である - どこlt_requestedエージェントが要求された寿命があります
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.
新しいポリシーを有効ルールが正常に確立され、応答メッセージは、要求エージェントに送信された後、ミドルのチェックがいるかどうか、新たな政策ルールにアクセスすることができます開いているセッションに参加している他の認証された薬があります。ミドルは、これらの薬剤の一つ以上を検出した場合、それはそれらのそれぞれに新しいポリシールールを報告するRENメッセージを送信します。
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.
- 政策ルール生涯：ミドルによって付与された残りの政策ルールの生涯。
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.
ミドルボックスは、最初に確認指定されたポリシールールが存在するかどうか、エージェントは、このポリシールールにアクセスすることを許可されているかどうか。チェックの1が失敗した場合は、適切な失敗回答が生成されます。要求された寿命が長く、現在のものよりもあれば、ミドルボックスは、ポリシールールの寿命を延長し、それがない場合があり、適切なエラーメッセージを生成することができるかどうかをチェックします。
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.
失敗回答は新しい寿命が受け入れられなかったことを意味し、ポリシールールは変わりません。政策ルールの寿命が何らかの方法で変更された場合の成功の応答はミドルによって生成されます。
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.,
成功の応答は、ポリシールールの新しい寿命が含まれています。ミドルボックスは、すなわち、ゼロより大きく、より少ない又は要求された値の最小値とセッション起動時にミドルボックスによって指定された最大寿命に等しい寿命値を選択します
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
0 <= lt_granted <=最小値（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
実際にミドルによって与えられた寿命lt_grantedされる - - lt_maximumは、セッションセットアップ時に指定した最大寿命である - どこlt_requestedエージェントが要求された寿命があります
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.
ゼロの生涯の成功の応答を送信した後、ミドルは、ポリシールールが存在しない検討していきます。このポリシールール上の任意の更なるトランザクションは、このポリシールールがもはや存在しないことを示す、負の回答になります。
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.
ポリシールールがメンバーであるグループに適用される場合、ポリシールール寿命はまた、グループ生涯変化（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.
残りのポリシールール寿命が正常に変更された応答メッセージを要求エージェントに送信された後、ポリシールールにアクセスすることができるオープンセッションに参加している他の認証されたエージェントがあるかどうかをミドルボックスをチェックします。ミドルは、これらの薬剤の一つ以上を検出した場合、それはそれらのそれぞれに新しい残りの政策ルール寿命を報告するRENメッセージを送信します。
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
- サポートされていないトランザクション - このトランザクションのために許可されていないエージェント
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.
エージェントは、このトランザクションを要求する権限があるかどうかを最初にチェックミドル。チェックが失敗した場合、適切な失敗回答が生成されます。それ以外の場合は、エージェントがアクセスできるすべてのポリシーのリストは、識別子と、各ポリシーの所有者を示す返されます。
This transaction does not have any effect on the policy rule state.
このトランザクションは政策ルールの状態には影響しません。
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.
- 政策ルール識別子：ミドル固有のポリシールール識別子。
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'.
- 政策ルールのアクション：このパラメータは、値「準備」または値「有効にする」のいずれかを持っています。
- 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.
- 方向：ミドルボックスで有効に通信の方向。のみ適用ポリシーにルールを有効にします。
- 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.
- 内部インターフェイス（オプション）：ミドルにおける内部インターフェイス。セクション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アドレスの内部：NAT（図3のA1）の内部に設けられた内部IPアドレス。セクション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.
- 外部インタフェース（オプション）：ミドルボックスで外部インターフェイス。セクション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アドレス（図3のA2）NATの外側に設けられた外部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を参照してください。
- port parity: The parity of the allocated ports.
- ポートパリティ：割り当てられたポートのパリティ。
- service: The selected service in the case of mixed traditional and twice-NAT middlebox (see section 2.3.8).
- サービス：ミックス伝統的な二回-NATミドルの場合は、選択されたサービス（セクション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.
ミドルボックスは、最初に確認指定されたポリシールールが存在するかどうか、エージェントは、このグループへのアクセスを許可されているかどうか。チェックの1が失敗した場合は、適切な失敗回答が生成されます。それ以外の場合は、ポリシールールのすべてのプロパティは、エージェントに返されます。例えば、プロトコル識別子 - 返されるパラメータのいくつかは、ポリシールールのアクション（「予備」または「有効」）に応じて、および他のパラメータに依存して、無関係であってもよいです。
This transaction does not have any effect on the policy rule state.
このトランザクションは政策ルールの状態には影響しません。
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 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).
ミドルはミドルとのオープンセッションに参加し、それは政策ルールにアクセスすることを許可されているすべてのエージェントにRENメッセージを送信します。ミドルポリシールールの有効期間を変更する前に、通知がエージェントに送信されます。寿命の変化は（lt_new <lt_existing）、延びる（lt_new> lt_existing）を短くする、またはポリシールールを終了する任意の他の承認薬および結果によってトリガされてもよい（lt_new = 0）。
The ARE transaction corresponds to the REN message handling described in section 2.3.4 for multiple agents.
AREトランザクションは複数のエージェントはセクション2.3.4で説明した処理RENメッセージに対応します。
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
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、です。 PRID UNUSEDの状態に復帰した後、ポリシールール識別子は、もはや既存のポリシールールにバインドされていないとミドルで再利用することができます。
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.
成功したPRRトランザクションは、アドレス予約が確立された状態RESERVED、未使用初期状態PRIDからの遷移を引き起こします。そこから、状態ENABLEDはPERトランザクションで入力することができます。この取引はまた、予約なしで未使用状態PRIDから直接イネーブル状態に入るために使用することができます。状態では、内部および外部のエンドポイントが有効になっているとの間の要求された通信を可能にしました。
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.
状態は、バック状態PRID使用されていないトランザクションによって、または0の寿命パラメータを使用して成功したRLCトランザクションによって引き起こされる可能性がこれらの状態の両方から0より大きい遷移を予約し、要求された寿命で成功したRLCトランザクションによって維持することができるENABLED 。
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.
RLCのトランザクションによって開始遷移はまた、GLCのトランザクションによって開始することができることに注意してください。
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)
- グループ生涯変化（GLC） - グループリスト（GL） - グループステータス（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.
すべてのエージェントによって開始された要求の取引です。 GLCは、コンフィギュレーション・トランザクションです。 GLとGSグループステート・マシン上の任意の効果を持っていないトランザクションを監視しています。
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.
そのメンバーのリスト：政策ルール・グループは、1つの属性のみを持っています。単一グループのすべてのメンバー方針は同じ認証されたエージェントによって所有されなければなりません。したがって、グループの暗黙的なプロパティがメンバポリシールールの所有者であり、その所有者、です。
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.
グループは、ミドル、一意の識別子を持っています。
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.
ポリシールールグループの取引はしかし、彼らは唯一の要求はなく、いくつかを送信するには、このような薬剤の利便性など、いくつかの機能を、提供部3でそれぞれのコンプライアンスエントリよる「オプション」として宣言されている唯一の必須取引がある場合、それは利用できません利用可能。
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.
グループ生涯変化（GLC）トランザクションを同時にグループのすべてのメンバーにポリシールールの有効期間の変更（RLC）の取引を行っ同等です。成功したGLCトランザクションの結果は、すべてのメンバーのポリシールールは同じ寿命を持っていることです。 RLCトランザクションと同様に、GLCトランザクションがゼロの寿命を要求することによって、すべてのメンバーのポリシールールを削除するために使用することができます。
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).
監視取引グループリスト（GL）とグループステータス（GS）は、ミドルの状態を調査し、そのアクセス権を探索するために、エージェントによって使用することができます。 GLのトランザクションは、他のエージェントが所有するグループを含むエージェントがアクセスできるすべてのグループが一覧表示されます。 GSトランザクションは、個々のグループのステータスを報告し、そのポリシールール識別子によって、このグループのすべてのポリシールールを示します。エージェントは、ポリシールールのステータス（PRS）トランザクションでポリシールール識別子を使用して、個々のポリシールールの状態を探索することができます（セクション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.
GLとGSトランザクションは、エージェントフェイルオーバーの場合に特に有用です。どちらのポリシーを取得するために、これらのトランザクションを使用することができなかった1の役割を引き継ぐエージェントが失敗したエージェントによって確立されています。
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.
グループイベントの通知は、ポリシールールのイベントと同様に生成されます。グループイベントについてエージェントに通知するには、ポリシールールのグループイベント通知（GEN）メッセージタイプが使用されています。 GENメッセージは、エージェント固有の通知識別子、ポリシールールグループ識別子、およびグループの残存寿命を含みます。
transaction-name: group lifetime change
トランザクション名：グループの存続期間の変更
transaction-type: configuration
トランザクション型：コンフィギュレーション
transaction-compliance: optional
トランザクション準拠：オプション
request-parameters:
リクエストパラメータ：
- request identifier: An agent-unique identifier for matching corresponding request and reply at the agent.
- 要求識別子：エージェントに対応する要求と応答を一致させるためのエージェント固有の識別子。
- 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.
- グループの寿命：グループの新しい生涯提案。
reply-parameters (success):
返信のパラメータ（成功）：
- request identifier: An identifier matching the identifier of the request.
- 要求識別子：要求の識別子と一致する識別子。
- group lifetime: The group lifetime granted by the middlebox.
- グループの寿命：ミドルによって付与されたグループの寿命。
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
- トランザクションはサポートされていません - エージェントこのトランザクションのために許可されていない - このグループの存続期間を変更することが許可されていない薬 - そのようなグループ - 寿命を延長することはできません
notification message type: Policy Rule Group Event Notification (GEN)
通知メッセージタイプ：政策ルールグループのイベント通知（GEN）
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 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.
指定されたグループが存在し、エージェントがこのグループにアクセスすることを許可されているかどうかかどうかを最初にチェックミドル。チェックの1が失敗した場合は、適切な失敗回答が生成されます。要求された寿命が長く、現在のものよりもあれば、ミドルボックスは、グループの寿命を延ばすことができるかどうかをチェックし、そうでない可能性がある場合、適切なエラーメッセージを生成します。
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.,
成功の応答はグループのすべてのメンバーのポリシールールの新しい共通寿命が含まれています。ミドルボックスは、ミドルボックスは、その他の機能と一緒にセッションセットアップ時に指定よりも小さいか、あるいは寿命の最小値と最大寿命に等しい新たな寿命、すなわちを選択し、
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
0 <= lt_granted <=最小値（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
実際にミドルによって与えられた寿命lt_grantedされる - - lt_maximumは、セッションセットアップ時に指定した最大寿命である - どこlt_requestedエージェントが要求された寿命があります
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.
残りのポリシールールグループ寿命が正常に変更され、応答メッセージは、要求エージェントに送信された後、ポリシー・ルール・グループにアクセスできるオープンセッションに参加している他の認証エージェントがあるかどうかをミドルボックスをチェックします。ミドルは、これらの薬剤の一つ以上を検出した場合、それはそれらのそれぞれに新しい残りの政策ルールグループの生涯を報告GENメッセージを送信します。
transaction-name: group list
トランザクション名：グループリスト
transaction-type: monitoring
トランザクション・タイプ：モニター
transaction-compliance: optional
トランザクション準拠：オプション
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.
- 要求識別子：要求の識別子と一致する識別子。
- group list: List of all groups that the agent can access. For each listed group, the identifier and the owner are indicated.
- グループリスト：エージェントがアクセスできるすべてのグループのリスト。リストされた各グループのために、識別子と所有者が示されています。
failure reason:
失敗の理由：
- transaction not supported - agent not authorized for this transaction
- サポートされていないトランザクション - このトランザクションのために許可されていないエージェント
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 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.
このトランザクションは、グループの状態には影響しません。
transaction-name: group status
トランザクション名：グループのステータス
transaction-type: monitoring
トランザクション・タイプ：モニター
transaction-compliance: optional
トランザクション準拠：オプション
request-parameters:
リクエストパラメータ：
- 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.
- グループ識別子：ステータス情報が要求されているグループへの参照。
reply-parameters (success):
返信のパラメータ（成功）：
- request identifier: An identifier matching the identifier of the request.
- 要求識別子：要求の識別子と一致する識別子。
- 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.
- グループ寿命：グループの残りの寿命。これは、すべてのメンバーのポリシールールの残りの寿命の最大値です。
- 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.
- メンバーリスト：グループのメンバーであるすべてのポリシールールの一覧。ポリシールールは、そのミドル固有のポリシールール識別子によって指定されています。
failure reason:
失敗の理由：
- transaction not supported - agent not authorized for this transaction - no such group - agent not authorized to list members of this group
- サポートされていないトランザクション - このトランザクションのために許可されていない薬 - いいえ、そのようなグループは - エージェントは、このグループのメンバーを一覧表示する権限がありません
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 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.
指定されたグループが存在し、エージェントがこのグループにアクセスすることを許可されているかどうかかどうかを最初にチェックミドル。チェックの1が失敗した場合は、適切な失敗回答が生成されます。そうでなければ、すべてのグループメンバーのリストは、各グループの識別子を示す返されます。
This transaction does not have any effect on the group state.
このトランザクションは、グループの状態には影響しません。
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.
プロトコル定義は、プロトコル仕様は、すべての必須パラメータで指定されたすべての取引を含む場合セクション2で定義された意味論に準拠します。しかし、ミドルの実際の実装は、これらすべてのトランザクションをサポートすることを必要とされていません。トランザクションは、コンプライアンスのために必要とされるエージェントとミドルのために異なっています。
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.
このセクションでは、意味論に関連したMIDCOMプロトコル実装のための適合性ステートメントが含まれています。適合性は、エージェントおよびミドルボックスのために別々に指定されています。これらの適合性のステートメントは、おそらく、具体的なプロトコル仕様によって拡張されます。しかし、そのような拡張は、それらのすべてがまだ保持するように、以下のステートメントを延長することが期待されます。
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
- セッション制御トランザクション - セッション確立（SE）必須 - セッション終了（ST）必須 - 非同期セッション終了（AST）必須
- 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
- ポリシールールの取引 - 必須ポリシーリザーブルール（PRR） - ポリシールールを有効にします（PER）必須 - 必須ポリシールールのステータス（PRS） - - ポリシールールの有効期間の変更（RLC）必須 - ポリシールールリスト（PRL）必須非同期ポリシールールのイベント必須（ARE）
- Policy Rule Group Transactions - Group Lifetime Change (GLC) optional - Group List (GL) optional - Group Status (GS) optional
- ポリシー・ルール・グループの取引 - オプションのグループ生涯変化（GLC） - グループリスト（GL）オプション - グループステータス（GS）オプション
A compliant implementation of a MIDCOM protocol MUST support all mandatory transactions.
MIDCOMプロトコルの準拠した実装は、すべての必須のトランザクションをサポートしなければなりません。
A compliant implementation of a MIDCOM protocol MAY support none, one, or more of the following transactions: GLC, GL, GS.
GLC、GL、GS：MIDCOMプロトコルの準拠した実装は、以下のトランザクションの1つ、またはそれ以上の何をサポートしていないかもしれません。
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.
MIDCOMプロトコルの準拠した実装が含まれている情報に関する各トランザクションのすべての必須パラメータをサポートしなければなりません。パラメータのセットは限り含まれている情報が維持されるトランザクションごとに再定義することができます。
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.
MIDCOMプロトコルの準拠した実装は、インターフェイス固有のポリシールールの使用をサポートするかもしれません。インターフェイス固有のポリシールールがサポートされている場合のいずれかまたは両方PRR、PER内側オプションと外部インターフェイスパラメータのいずれも、およびPRSは含まなければなりません。
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.
準拠した実装は、よりきめの細かい一連のトランザクションによって単一のトランザクションを交換することができます。このような場合には、要件2.1.4（決定論的挙動）および[MDC-REQ]の要件2.1.5（知られており、安定した状態）がまだ満たされていることを保証しなければなりません。単一のトランザクションが複数のきめ細かなトランザクションの集合で置き換えられる場合は、このセットは、単一のトランザクションと同等でなければなりません。さらに、トランザクションのこのセットは、さらに、セクション2.1.4に記載アトミック要件を満たさなければなりません。
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.
特定の要求トランザクションのすべての可能な正しいメッセージインスタンスを受信して処理することができ、それが受信する任意の正しい要求に対する正しい応答を生成した場合場合MIDCOMプロトコルのミドルボックス実装は、要求トランザクションをサポートします。
A middlebox implementation of a MIDCOM protocol supports an asynchronous transaction if it is able to generate the corresponding notification message properly.
適切に対応する通知メッセージを生成することができる場合MIDCOMプロトコルのミドルボックス実装は、非同期トランザクションをサポートします。
A compliant middlebox implementation of a MIDCOM protocol must inform the agent about the list of supported transactions within the SE transaction.
MIDCOMプロトコルの対応のミドル実装は、SEのトランザクション内でサポートされたトランザクションのリストについてエージェントに通知しなければなりません。
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.
それは適切に対応する要求メッセージを生成することができれば、それは特定の要求にすべての可能な正しい応答を受信して処理できる場合MIDCOMプロトコルのエージェントの実装では、要求トランザクションをサポートします。
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.
それは特定のトランザクションのすべての可能な正しいメッセージインスタンスを受信して処理できる場合MIDCOMプロトコルのエージェント実装は、非同期トランザクションをサポートしています。
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.
MIDCOMプロトコルの準拠したエージェントの実装は、ミドルではサポートされていない任意のオプション取引を使用してはいけません。ミドルは、SEのトランザクション内でサポートされたトランザクションのリストについてエージェントに通知します。
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].
このセクションでは、最初のエージェントが、それがミドルボックスにアクセスすることができるすべてのポリシールールおよびポリシー・ルール・グループを探索する方法を示し部2で指定されたトランザクションの2つの使用例を示します。第二の例では、セッション開始プロトコル（SIP）[RFC3261]とのIPセッションを介して音声の設定と組み合わせてミドルボックスの構成を示しています。
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.
- それはアクセスすることができ、誰がこれらのグループ、所有しているグループ - ステータスとアクセス可能なすべてのグループのメンバーリスト、および - ステータスと、すべてのアクセスポリシールールのプロパティを。
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.
また、エージェントシステムは、失敗する可能性があり、別の一つは引き継ぐことがあります。次に、新しいエージェントシステムはすでに失敗し、システムによって構成され、何がまだ行われる必要があるしているかを調べる必要があります。
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.
ポリシールールとグループを探索することは有益である第3の状況は、「管理者の権限を持つ剤の場合です。このエージェントは、他のエージェントによって作成されたすべてのポリシールールまたはグループにアクセスし、変更することができます。
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.
この要求には、図5に示すように、すべてのエージェントは、おそらく、グループリスト（GL）トランザクションとの探査を開始します、ミドルは、各エージェントの識別子とグループ識別子（GID）を含む、ペアのリストを返します。エージェントは、それがアクセスできる独自のグループや他のエージェントのグループのどれに通知されます。
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
図5：GLとGSのトランザクションの使用
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).
図5では、3つのグループが、エージェントにアクセス可能であり、エージェントがグループの状態（GS）トランザクションを使用して第2のグループの情報を取得します。それは、4つのポリシールール識別子（PID）を含む、この場合には、グループの所有者は、残りの寿命、および会員ポリシールールのリストを受信します。
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:
以下では、エージェントは、これらの4つのポリシールールを探ります。例では、ミドルは、伝統的なNAPTであることを前提としています。図6は、第1のポリシールールの探索を示しています。ポリシールールのステータス（PRS）トランザクションへの応答では、ミドルは常にパラメータの次のリストを返します。
- 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)
- ポリシールールの所有者 - グループ識別子 - ポリシールールアクション（リザーブまたは有効） - プロトコルタイプ - ポート範囲 - 方向 - 内部IPアドレス - 内部ポート番号 - 外部アドレス - 外部ポート番号 - IPアドレス内側ミドル - ポート番号内側ミドル - IPアドレス外側ミドル - ポート番号外側ミドル - IPアドレスバージョン（印刷されない） - ミドルサービス（印刷されない） - 内部と外部インターフェース（オプション、印刷されていません）
agent middlebox | PRS PID1 | |**********************************************>| |<**********************************************| | agent1 GID2 RESERVE UDP 1 "" | | ANY ANY ANY ANY | | ANY ANY IPADR_OUT PORT_OUT1 | | |
エージェント・ミドル| PRS PID1 | | **********************************************> | | <********************************************** | |エージェント1 GID2 RESERVE UDP 1 "" | | ANY ANY ANY ANY | | ANY ANY IPADR_OUT PORT_OUT1 | | |
Figure 6: Status Report for an Outside Reservation
図6：外の予約のためのステータスレポート
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.
図6に印刷された「ANY」パラメータは、ポリシー準備ルールのポリシールールステータス応答のプレースホルダとして使用されます。 PID1との政策ルールは、ミドルの外でのUDPトラフィックの責任準備金規則です。これは予備ルールであるため、方向は空です。まだ関与は内部または外部のアドレスが存在しないように、これらの4つのフィールドが応答でワイルドカードされています。同じことは、内部のミドルアドレスとポート番号を保持しています。応答によって与えられたアドレス情報のみがミドル（IPADR_OUT）のIPアドレスと対応するポート番号（PORT_OUT1）の外側に予約されています。予備のアクションがこれをサポートしていないようIPADR_OUTとPORT_OUT1は、ワイルドカードされない場合があります。
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 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.
（図7）PID2にPRSを適用する第2のポリシールールはポリシーがインバウンドUDPパケットのためのルールを有効であることを示しています。内部宛先は、IPアドレス、プロトコル、およびポート番号について固定されているが、外部ソースのため、ポート番号ワイルドカードれます。ミドルの外にIPアドレスとポート番号は外部の送信者は、それが送信元のパケットに宛先として使用するために必要なものです。ミドルボックスで、宛先アドレスが、最終的な受信機の内部アドレスに置き換えられます。アドレス変換の際に、送信元IPアドレスとパケットの送信元ポート番号は変わりません。これは、外部アドレスと同一である内部アドレスによって示されています。
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
図7：有効インバウンドパケットのステータスレポート
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).
従来のNATは、外部IPアドレスとポート番号と内部IPアドレスとポート番号の識別は常に（A1 =図3のA3）を保持します。純粋なファイアウォールの外部IPアドレスとポート番号は、常に、内部IPアドレスとポート番号（A0 =図3のA2）と同一です。
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
図8：有効送信パケットのためのステータスレポート
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.
図8が示すように、同じホストとの間のアウトバウンドUDP通信を可能にしました。ここでは、すべてのポート番号が知られています。再度、A1 = A3ので、内部の送信者は、元のパケットの宛先などの外部IPアドレスとポート番号を使用します。ファイアウォールで、内部ソースIPアドレスとポート番号は、ミドルボックスの示す外部IPアドレスおよびポート番号で置き換えられています。
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 |
| |
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。アウトバウンドパケットの場合、唯一のソースIPアドレスとポート番号はミドルで置換され、インバウンドパケットのために、唯一の宛先IPアドレスとポート番号が置き換えられます。
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）とミドルとの間の相互作用を示しています。ミドルボックス自体は、従来のネットワークアドレス及びポート変換器（NAPT）であり、図10ザMIDCOM剤に示すように、2つのSIPユーザエージェントは、B2BUAとNAPTを介して互いに通信B2BUAと同じ場所に配置され、そしてMIDCOMサーバがミドルです。したがって、MIDCOMプロトコルは、B2BUAとミドル間を走ります。
+-------------+
| B2BUA |
| for domain ++++
| example.com | +
+-------------+ +
^ ^ +
Private | | + Public Network
Network | | +
+----------+ | | +----+------+ +----------------+
| SIP User |<-+ +->| Middlebox |<------->| SIP User Agent |
| Agent A |<#######>| NAPT |<#######>| B@example.org |
+----------+ +-----------+ +----------------+
<--> SIP signaling <##> RTP traffic ++++ MIDCOM protocol
< - > SIPシグナリング<##> RTPトラフィック++++ MIDCOMプロトコル
Figure 10: Example of a SIP Scenario
図10：SIPシナリオの例
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は、そのプライベートIPアドレスでB2BUAで登録されています。
- 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は、URLがB@example.orgあるユーザBの一般的なSIP URLを知っています。しかし、Bが現在使用しているユーザーのSIPユーザエージェントBの具体的なURLは、知られていません。
- The RTP paths are configured, but not the RTP Control Protocol (RTCP) paths.
- RTP経路が構成さではなく、RTP制御プロトコル（RTCP）経路です。
- The middlebox and the B2BUA share an established MIDCOM session.
- ミドルと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
ユーザエージェントAの内部ポート番号RTPデータを受信するために - P_AE：外部ユーザエージェントAのポート番号マッピングされた - IP_AE：ミドルの外部IPアドレス - IP_B：のIPアドレスを - ： - IP_AI P_AIユーザエージェントAの内部IPアドレスユーザエージェントB - P_B： - ：グループ識別子 - PID：ポリシールール識別子GIDユーザエージェントBのポート番号は、RTPデータを受信します
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は、ユーザエージェントA、ユーザBを呼び出そうと（図10参照）B2BUAにINVITE SIPメッセージを送信します。次のようにミドル構成に関連する特定のSIPメッセージのSDP部分がシーケンス図に示されています。
SDP: m=..P_AI.. c=IP_AI
SDP：M = .. C = IP_AI P_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アドレスを含みます。
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メッセージは、パブリックIPアドレスとユーザエージェントBのRTPメディアストリームを送信することができますするポート番号を含める必要があります。 B2BUAは、ポリシーは、この時点で知られているユーザエージェントBのいずれもIPアドレスやポート番号、ユーザエージェントのアドレスとしてユーザエージェントBのワイルドカードIPアドレスとポート番号とのPER要求にミドルにルールを有効に要求しますBは、ワイルドカードする必要があります。ワイルドカードのIPアドレスとポート番号は、「初期メディア」機能を有効にするが、任意の外部のホストは、ミドルを通じて有効ポート番号でユーザエージェント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 | |
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応答は、NATの結果は、ミドルでの結合します。参加することを意図していなくてもホストを - 他のホスト可能性として、ユーザエージェントBは、INVITEメッセージを受信した後、すぐにトラフィックを送信し始めることができるように、この結合は、ユーザエージェントA.に到達するために、ユーザエージェントAのプライベート・ネットワーク外の任意のホストからのUDPトラフィックを可能にします、任意の悪意のあるホストなど。
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.
ミドルがサポートしていないか、セキュリティ上の理由から、IPアドレスのワイルドカードを許可しない場合は「IPのワイルドカードがサポートされていない」のような、PER要求は、適切な失敗の理由で拒否されます。それにもかかわらず、B2BUAは、SIP INVITEメッセージを転送するために、ミドル（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アドレスワイルドカードが許可されていない、B2BUAはPRRトランザクションを使用します。
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要求を使用して、B2BUAは既にNAT結合又はピンホールを確立することなく、外部IPアドレスとポート番号（図12参照）を要求します。 PRR要求は、サービスパラメータ「TW」を含んでいる - すなわち、MIDCOMエージェントは、デフォルト値を選択します。この構成では、NAPTで二回-NATなしで、外側だけアドレスが予約されています。 INVITEメッセージのSDPペイロードに、B2BUAは、PRR応答から予約されたIPアドレスおよびポートを持つユーザエージェントAのIPアドレスとポート番号を置換する（図12参照）。 SIPのINVITEメッセージをそのユーザエージェントBは、そのRTPメディアストリームを送信するために、外部アドレスとポート番号を含む修飾されたSDP本体とユーザエージェントBに転送されます。
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 |
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「200 OK」応答は、ユーザエージェント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は、ポリシールールを有効（PER）トランザクションとの結合の完全なNATを確立するための十分な情報を持っています。すなわち、コールのUDP / RTPデータはPERトランザクションがPRRのPID（PID1）を通過させることによって予約を参照するユーザエージェントAにユーザエージェントBから流れることができます。
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 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.
ユーザエージェントAと反対方向の、UDP / RTPデータBにも有効にしなければなりません。これは、すべての必要なパラメータ（図13参照）と毎秒トランザクションによって行われます。要求メッセージは、ミドルボックスは、最初のPERトランザクションに割り当てられたグループ識別子（GID1）を含みます。したがって、両方のポリシールールは、同じグループのメンバーとなっています。有効になって両方のUDP / RTPストリームた後、B2BUAは、電話通話が開始できることを示すために、ユーザエージェントAに「200 OK」SIPメッセージを転送することができます。
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 | | |
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は、通話を終了することを決定し、ユーザエージェントA. B2BUA転送し、すべてのSIPメッセージにその「BYE」SIPメッセージを送信し、0秒の要求された残りの寿命を持つ（GLC）トランザクショングループの寿命の変化を利用して、後でグループを終了します（図14参照）。グループの終了は、すべてのメンバーのポリシールールを終了することを含みます。
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...
Figure 14: Termination of Policy Rule Groups
図14：ポリシールールのグループの終了
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.2）への準拠 - - プロトコル機械要件（セクション5.1）に準拠するセキュリティ要件の遵守（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で指定された要件を指します。
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エージェントを有効にします。エージェントは、セクション2.2.1で説明したセッション確立トランザクションの認証メカニズムによって自身を識別する。この認証に基づいて、ミドルは、エージェントがサービスを要求することが許可されるかどうかを判断することができます。したがって、要件2.1.1が満たされています。
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プロトコルは、エージェントが同時に複数のミドルと通信することを可能にします。異なるセッションを分離するための機構の選択は、具体的なプロトコル定義に残されます。これは、セッションを開くには、プロトコルメッセージの明確なマッピングを提供しなければなりません。そして、要件2.1.2が満たされています。
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で指定されているように、MIDCOMプロトコルは、ミドルボックスは、同時に複数のエージェントと通信することを可能にします。異なるセッションを分離するための機構の選択は、具体的なプロトコル定義に残されます。これは、セッションを開くには、プロトコルメッセージの明確なマッピングを提供しなければなりません。そして、要件2.1.3が満たされています。
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は、エージェントの要求の処理は、同じまたは別の薬剤のいずれかの要求によって中断されないことを述べています。これは、要求トランザクション間原子性を提供し、ミドルボックスによって、予期しない動作が生じる競合状態を回避します。
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.
ミドルの振る舞いは、その管理者の観点から予測できることができます。エージェントのビューでは、ミドルの動作は、管理者は、例えば、エージェントはこの変化を観察することができることなく、いつでもエージェントの許可を変更することができるよう、予測不可能です。これにより、ミドルの挙動は、任意の薬剤の観点からは必ずしも決定的ではありません。
As predictability of the middlebox behavior is given for its administrator, requirement 2.1.4 is met.
ミドルの挙動の予測は、その管理者のために与えられているとおり、要件2.1.4が満たされています。
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の状態は、互いに対して、エージェントの観点から原子です。すべてのトランザクションは、明確に、現在の安定した、明確に定義された状態のままにして、新たな安定を入力するかという状態遷移として定義され、明確に定義された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.
また、各状態遷移のためのメッセージは、対応するエージェント、返信または通知のいずれかに送られます。エージェントは、独自にエージェント固有の要求識別子は、この目的のために使用されているので、それは、ミドルに送信された要求の一つに各応答をマッピングすることができます。通知はその定義により自明です。
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
さらに、グループリストのトランザクション（セクション2.4.3）、グループステータスのトランザクション（セクション2.4.4）、ポリシールールの一覧トランザクション（セクション2.3.11）、およびポリシールールのステータストランザクション（セクション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.
そのため、エージェントは正確に（エージェントによって要求されたサービスが影響を受けている限り）ミドルの状態について知らされ、そして要件2.1.5が満たされています。
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.
前節で論じたとおり、ミドルは明確エージェントによって要求されたサービスのいずれかに関連するすべての状態遷移についてエージェントに通知します。また、任意の時点でエージェントがアクセス可能なすべてのポリシールールとポリシールール・グループに関する完全なステータス情報を取得することができます。したがって、要件2.1.6が満たされています。
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.
セマンティクスは、セッション終了通知（STN）メッセージ、ポリシールールのイベント通知（REN）メッセージ、グループイベント通知（GEN）メッセージ（セクション2.1.2を参照）を含むエージェントにミドルから非同期通知メッセージが含まれています。これらの通知は、明示的にエージェントによって要求されなかったポリシールールまたはポリシールールグループの状態のすべての変更を報告しています。したがって、要件2.1.7は、上記指定された意味論によって満たされます。
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で指定されているように、意味論は、二つの後続のセッション確立トランザクションまたは下位プロトコル層上に設けられた相互認証のいずれかを使用してエージェントとミドルの相互認証を必要とします。したがって、要件2.1.8が満たされています。
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でのセマンティクスの仕様の状態はこの要求を拒否しない場合があります。ターンでは、セクション2.2.3は、ミドルは非同期に送信することと述べています
Session Termination notification at any time and then terminate the session. Thus, requirement 2.1.9 is met.
セッション終了のいずれかの時点で通知して、セッションを終了します。したがって、要件2.1.9が満たされています。
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は、エージェントの各要求が成功または失敗のいずれかを示すミドルボックスの応答が続いていることを述べています。したがって、要件2.2.10が満たされています。
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項では、エージェントは、それがセッション中に使用するプロトコルのバージョン番号を指定する必要があると述べています。ミドルはこれを受け入れ、このプロトコルのバージョンに応じて行動するか、それがこのバージョンをサポートしていない場合、セッションを拒否することがあります。セッション・セットアップが拒否された場合、エージェントは別のバージョンで再試行してくださいことがあります。したがって、要件2.2.11が満たされています。
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).
NATを、予備用と競合する可能性があります可能。相反する要求が到着した場合はセクション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.
したがって、重複ルールの存在下でのミドルボックスの挙動が決定論的に予測することができ、必要2.1.12が満たされます。
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は、明示的にプロトコル構文の拡張を要求します。これは、具体的なプロトコル定義によって対処する必要があります。新しいトランザクションが追加される可能性があるため、意味論の仕様は、とにかく拡張可能です。
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節は、セマンティクスは、すべてのミドルタイプに対して同じトランザクションを使用し、同じポリシールールがそれらのすべてに適用することができることと説明しています。したがって、要件2.2.2が満たされています。
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が満たされています。
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が満たされています。
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.
ミドルでの状態遷移が明確に指定され、エージェントに伝達されます。要求の部分的処理によって到達中間の状態はありません。すべての要求は常に正常終了または失敗した、完全に処理されています。すべての要求トランザクションは、失敗の理由のリストが含まれています。これらの失敗の理由は、該当する無効なパラメータの表示をカバーしています。障害が発生した場合に、指定された理由の一つは、エージェントにミドルから返されます。したがって、要件2.2.5が満たされています。
The semantics includes a failure reason parameter in each failure reply. Thus, requirement 2.2.6 is met.
セマンティクスは、各失敗応答における失敗の理由パラメータを含んでいます。したがって、要件2.2.6が満たされています。
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.
ミドルが十分に設定可能である場合には、1つの認証されたエージェントが別のエージェントが所有するポリシールールとグループにアクセスして変更することが許可されるように、その管理者は、それを構成することができます。指定されたセマンティクスがこれを妨げるものではないので、それは要件2.2.7を満たしています。
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で指定されたポリシーの有効化ルールのトランザクションは、5タプルのフィルタリングルールを運ぶことができます。これは、要件2.2.8を満たしています。
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で指定されているように、エージェントはPRRトランザクションとポート番号を予約する際に、ポートのパリティを維持する要求することができる（セクション2.3.8を参照）、PERトランザクションでアドレスバインディングを確立するとき（セクション2.3.9を参照してください）。したがって、要件2.2.9が満たされています。
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.
セクション2.3.6で指定されるように、エージェントは、PRRトランザクションとポート番号を予約するときに、ポート番号の連続した範囲を要求することができる（セクション2.3.8を参照）、PERトランザクションでアドレスバインディングやピンホールを確立するとき（セクション2.3参照0.9）。したがって、要件2.2.10が満たされています。
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は、このような「有効」/「許可」と「無効」/「許可しない」などの矛盾したポリシールールのアクションは、サポートされていることを前提としています。 NO「無効」/「不許可」アクションがサポートされていませんので、要件文書を最終決定した後、ワーキンググループによって行われた決定に準拠して、この要件は、意味論によって満たされていません。
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.
セマンティクスの定義は、セッション確立のトランザクション（セクション2.2.1）のエージェントとミドルの相互認証をサポートしています。そのようなTLSやIPsecなどの基本的なプロトコルの使用は必須です。したがって、要件2.3.1が満たされています。
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を使用することは、エージェントとミドルボックスは、（暗号化なしを含まない）暗号化方式を使用することを可能にします。したがって、要件2.3.2が満たされています。
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が満たされています。
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.
指定されたセマンティクスリプレイ攻撃を軽減し、エージェントとミドルの相互認証を要求することにより、およびTLSやIPsec保護の使用を義務付けることにより、要件2.3.4を満たしています。
Further mitigation can be provided as part of a concrete MIDCOM protocol definition -- for example, by requiring consecutively increasing numbers for request identifiers.
さらに緩和コンクリートMIDCOMプロトコル定義の一部として提供することができる - 例えば、要求識別子の連続して増加する番号を要求することによって。
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
ミドルとエージェントとの間の相互作用は、（[MDC-FRM]参照）セキュリティに関して非常に敏感な点です。ミドル-外部エンティティからポリシールールの設定は、ミドルの本質と矛盾するように見えます。このため、有効な手段が確保するために使用されなければなりません
- mutual authentication between agent and middlebox, - authorization, - message integrity, and - message confidentiality.
- 承認、 - - メッセージの整合性、および - メッセージの機密性物質とミドル、間の相互認証。
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.
セマンティクスがエージェントとミドル間の相互認証を保証するためのメカニズムを定義する（セクション2.2.1を参照）。認証と組み合わせることで、ミドルは、エージェントがミドルでアクションを要求する権限があるかどうかを決定することができます。セマンティクスは、両方のエンティティ間で転送されるデータのメッセージの整合性と機密性を維持するために、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.
そのような過度にワイルドカードポリシールールを開くなどの特定のリスクにワイルドカードIPアドレスとポート番号結果とポリシールールの構成。過度にワイルドカードを使ったポリシールールは、例えば、「任意の」IPアドレスに設定されたIPアドレスを持つA0とA3だろう。すべてのパケットがさらに確認せずにミドルを通過する可能性があるので、ピンホールのこのタイプは、セキュリティ、役に立たないという意味で、ミドルをレンダリングします。ミドルのローカルポリシーは、このようなポリシールールが要求を有効拒否すべきです。
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.
ワイルドカードのための合理的なデフォルト設定では、唯一のポート番号はワイルドカードすることができると、すべての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で説明した例は、SIP-シグナリングコールがワイルドカードIPアドレスなしに安全な方法で配信することができる方法を示しています。しかし、いくつかのSIP-合図のアプリケーションは、（[RFC3398]のセクション5.5を参照）初期メディアを利用します。初期メディアを受信するには、ミドルボックスは、セッション内の2番目の参加が知られる前に設定する必要があります。それは知られていないように、第二の参加者のIPアドレスは、ワイルドカードする必要があります。
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.
このような場合には、いくつかの類似したもので、ミドルのオペレータによってなされるべきセキュリティポリシーの決定があります。それはより多くの機能をサポートしているように、オペレータは、ワイルドカードのIPアドレスを許可することで、例えば、ミドルを設定することができ、またはので、ネットワーク運用は、ワイルドカードのIPアドレスを許可しないことで、例えば、より安全です。
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).
片側自アドレス固定（UNSAF）は、それらが別のエンドポイントに知られていることにより、アドレス（およびポート）を決定または修正しようとするエンドポイントを発信の処理として、[RFC3424]に記載されています。そのようなNATを介してUDPプロトコルの簡易トラバーサル（STUN）[RFC3489]としてUNSAF提案は、NATトラバーサルのための回避策の一般的なクラスとして、ノーミドル通信（MIDCOM）とシナリオのためのソリューションとして考えられています。
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.
この文書は、ミドル通信（MIDCOM）溶液のためのプロトコルのセマンティクスを記述しています。 MIDCOMは、短期的な回避策として意図され、より多くのミドル通信のための長期的なソリューションとしてれていません。 MIDCOMでは、エンドポイントは、割り当て維持、及びミドルにアドレスとポートを削除するには関与しません。ミドルボックスにおけるアドレスとポートの完全な制御がMIDCOMサーバに配置されています。
Therefore, this document addresses the UNSAF considerations in [RFC3424] by proposing a long-term alternative solution.
したがって、この文書は、長期的な代替ソリューションを提案することにより、[RFC3424]でUNSAF考慮事項に対処しています。
We would like to thank all the people contributing to the semantics discussion on the mailing list for a lot of valuable comments.
私たちは、貴重なコメントをたくさんためのメーリングリスト上の意味論の議論に貢献するすべての人々に感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[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、 "ミドル通信アーキテクチャおよびフレームワーク"、RFC 3303、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] Swale、R.、マート、P.、Sijben、P.、つば、S.、およびM.ショア、 "ミドル・コミュニケーションズ（MIDCOM）プロトコル要件"、RFC 3304、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.テイラー、 "ミドル・コミュニケーションズ（MIDCOM）プロトコルのセマンティクス"、RFC 3989、2005年2月。
[NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[NAT-TERM] Srisuresh、P.とM.ホールドレッジ、 "IPネットワークアドレス変換（NAT）用語と考慮事項"、RFC 2663、1999年8月。
[NAT-TRAD] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[NAT-TRAD] Srisuresh、P.とK. Egevang、 "伝統的なIPネットワークアドレス変換（NAT繁体字）"、RFC 3022、2001年1月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.1"、RFC 4346、2006年4月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、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.、フイン、A.、カールソン、M.、ペリー、J.、およびS 。Waldbusser、 "ポリシーベースの管理のための用語"、RFC 3198、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.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[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.オング、 "セッション開始プロトコル（SIP）へのマッピング総合デジタル通信網（ISDN）ユーザ部（ISUP）"、RFC 3398、12月2002。
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
、RFC 3424、2002年11月、 "ネットワークアドレス変換アクロス一方的な自己アドレス固定するためのIABの考慮事項（UNSAF）" [RFC3424] Daigle氏、L.とIAB、。
[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.マーイ、 - 2003年3月、RFC 3489 "STUNネットワークを介して、ユーザーデータグラムプロトコル（UDP）の簡単なトラバーサルは、翻訳者（NATのを）アドレス"。
Appendix A. Changes from
付録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プロキシサーバを使用します。これは、これはバックツーバックユーザエージェントを有するSIPプロキシサーバを置換することによって修正されたRFC 3261に違反しました。
2. Clarifications concerning the used set of transaction types have been added.
トランザクションタイプの使用セット等に関する明確化が追加されました。
3. Section 3.1, "General Implementation Conformance", now uses key words from RFC 2119.
3. 3.1項「一般的な実装適合は、」今、RFC 2119からキーワードを使用しています。
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ヨーロッパ社Kurfürsten-Anlageの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ヨーロッパ社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ロレーヌアベニュー。オタワ、オンタリオカナダK1H 6Z8
Phone: +1 613 763 1496 EMail: tom.taylor@rogers.com
電話：+1 613 763 1496 Eメール：tom.taylor@rogers.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
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リポジトリから。
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に情報を記述してください。