[要約] RFC 5189は、MIDCOMプロトコルのセマンティクスに関する情報を提供します。このRFCの目的は、ミドルボックス間の通信を効率的かつ安全に行うためのプロトコルを定義することです。
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
Middlebox通信（MIDCOM）プロトコルセマンティクス
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（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フレームワーク、ワーキンググループの決定から派生しています。このドキュメントは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ワーキンググループは、MiddleBox通信のためのフレームワーク[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で定義されているセマンティクスに関するMIDCOMプロトコルの定義とMIDCOMプロトコルの実装の適合ステートメントが含まれています。セクション4では、2つの詳細な使用例を示します。最後に、セクション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.
MiddleBox-Unique Middlebox-Unique値は、MiddleBoxのコンテキストでユニークです。このコンテキストには、ミドルボックスが参加するすべてのMIDCOMセッションが含まれます。ミドルボックスユニーク値はMiddleboxによって割り当てられます。
policy rule In general, a policy rule is "a basic building block of a policy-based system. It is the binding of a set of actions to a set of conditions -- where the conditions are evaluated to determine whether the actions are performed" [RFC3198]. In the MIDCOM context, the condition is a specification of a set of packets to which rules are applied. The set of actions always contains just a single element per rule, either action "reserve" or action "enable".
一般に、ポリシールールは「ポリシーベースのシステムの基本的な構成要素です。一連のアクションが一連の条件に拘束されます。条件が評価されて、アクションが実行されるかどうかを判断する」[RFC3198]。MIDCOMのコンテキストでは、条件はルールが適用されるパケットのセットの仕様です。アクションのセットには、常に「アクション」またはアクション「有効」のいずれかのルールごとに単一の要素のみが含まれます。
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.
ポリシーリザーブルール予約措置を含むポリシールール。この規則のポリシー条件は常に真実です。アクションは、Middlebox構成に応じて、Middleboxの側面、片側、または両側には、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.
ポリシーを有効にするルールイネーブルアクションを含むポリシールール。ポリシー条件は、1つ以上の単方向または双方向のパケットフローの記述子で構成されており、ポリシーアクションにより、このフローに属するパケットがミドルボックスを横断することができます。記述子は、オプションでさまざまなポート番号を使用して、プロトコル、フロー方向、および宛先アドレスを識別します。
NAT binding The term NAT binding as used in this document does not necessarily refer to a NAT bind as defined in [NAT-TERM]. A NAT binding in the MIDCOM semantics refers to an abstraction that enables communication between two endpoints through the NAT-type middlebox. An enable action may result in a NAT bind or a NAT session, depending on the request and its parameters.
NATバインドこのドキュメントで使用されているNAT結合という用語は、[NAT-Term]で定義されているようにNATバインドを必ずしも指すものではありません。MIDCOMセマンティクスのNATバインドとは、NATタイプのミドルボックスを介して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.
Transaction-Complianceこのエントリには、「必須」または「オプション」のいずれかが含まれています。詳細については、セクション2.1.8を参照してください。
request-parameters This entry lists all parameters necessary for this request. A description for each parameter is given.
Request-Parametersこのエントリは、このリクエストに必要なすべてのパラメーターをリストします。各パラメーターの説明が指定されています。
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.
Reply-Parameters（成功）このエントリには、事前リクエストに対する肯定的な応答として、ミドルボックスからエージェントに送信されたすべてのパラメーターがリストされています。各パラメーターの説明が指定されています。
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つのパラメーターがあります。返信の送信要求を識別する要求識別子と、障害理由を示すパラメーター。これらのパラメーターは必須であるため、テンプレートにはリストされていません。ただし、テンプレートには、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.
セマンティクスこのエントリは、トランザクションの実際のセマンティクスを説明しています。特に、それは、それぞれトランザクションによって引き起こされる、またはそれぞれの原因となっているミドルボックスのリクエストメッセージの処理と、それぞれトランザクションによって引き起こされるMiddlebox状態の遷移について説明します。
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).
状態の遷移は、エージェントからミドルボックスへの要求メッセージのいずれか、またはMiddleboxでの他のイベントのいずれかによって開始されます。最初のケースでは、ミドルボックスは、実際の状態遷移に関する返信メッセージを送信することにより、エージェントに通知します。2番目に、ミドルボックスは、トランザクションの影響を受けた各エージェントに未承諾の非同期通知メッセージを送信します（ミドルボックスとのオープンセッションに参加している場合）。
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 Sessionsおよび政策規則の確立と終了に関係しており、Middbox Stateの移行に関連しています。
Monitoring transactions are not related to middlebox state transitions. They are used by agents to explore the number, status, and properties of policy rules established at the middlebox.
監視トランザクションは、Middlebox Stateの移行とは関係ありません。エージェントは、ミドルボックスで確立されたポリシールールの数、ステータス、およびプロパティを調査するために使用されます。
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種類のメッセージをサポートしています。種類ごとに、異なるメッセージタイプが存在します。このセマンティクス文書では、メッセージタイプはパラメーターのリストによってのみ定義されます。パラメーターの順序とそのエンコードは、具体的なプロトコル定義に任されています。また、プロトコル定義は、セマンティクスに定義されているパラメーターに含まれる情報がまだ存在する限り、メッセージタイプにさらなるパラメーターを追加するか、いくつかのパラメーターを1つに組み合わせます。
For request messages and positive reply messages, there exists one message type per request transaction. Each reply transaction defines the parameter list of the request message and of the positive (successful) reply message by using the transaction definition template defined in section 1.2.
リクエストメッセージと肯定的な返信メッセージの場合、リクエストトランザクションごとに1つのメッセージタイプが存在します。各返信トランザクションは、セクション1.2で定義されているトランザクション定義テンプレートを使用して、リクエストメッセージのパラメーターリストと肯定的な（成功）応答メッセージのパラメーターリストを定義します。
In case of a failed request transaction, a negative reply message is sent from the middlebox to the agent. This message is the same for all request transactions; it contains the request identifier identifying the request to which the reply is sent and a parameter indicating the failure reason.
リクエストトランザクションが失敗した場合、マイナスボックスからエージェントに否定的な返信メッセージが送信されます。このメッセージは、すべての要求トランザクションで同じです。これには、返信が送信されるリクエストを識別する要求識別子と、障害理由を示すパラメーターが含まれます。
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つの通知メッセージタイプがあります。これらにはすべて、Middlebox-Unique通知識別子が含まれています。
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.
所有権は、ポリシールールとポリシールールグループへのアクセスを決定します。ポリシールールが作成されると、Middlebox-Unique識別子が生成され、さらにトランザクションで識別されます。識別子を超えて、各ポリシールールには所有者がいます。所有者は、ポリシールールを確立した認証エージェントです。ミドルボックスは、ポリシールールの所有者属性を使用して、アクセスを制御します。認証されたエージェントが既存のポリシールールの変更を要求するたびに、MiddleBoxはポリシールールの所有者を決定し、要求エージェントが所有エージェントのポリシールールでトランザクションを実行することを許可されているかどうかを確認します。
All policy rules belonging to the same policy rule group must have the same owner. Therefore, authenticated agents have access either to all members of a policy rule group or to none of them.
同じポリシールールグループに属するすべてのポリシールールは、同じ所有者を持つ必要があります。したがって、認証されたエージェントは、ポリシールールグループのすべてのメンバーまたはそれらのいずれにもアクセスできません。
The middlebox may be configured to allow specific authenticated agents to access and modify policy rules with certain specific owners. Certainly, a reasonable default configuration would let each agent access its own policy rules. Also, it might be good to configure an agent identity to act as administrator, allowing 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機能のリスト、おそらく - アドレス翻訳 - ポート翻訳 - プロトコル翻訳 - 2回NAT-内部IPアドレスワイルドカードサポート - 外部IPアドレスワイルドカードサポート - ポートワイルドカードサポート - サポートIPバージョン内部ネットワーク：IPv4、IPv6、またはその両方 - 外部ネットワークのサポートされたIPバージョン：IPv4、IPv6、またはその両方 - サポートされているオプションのMIDCOMプロトコルトランザクションのリスト - インターフェイス固有のポリシールールのサポート - ポリシールールの永続性：永続的または非非-persistent（ルールは、ミドルボックスがルールを不揮発性メモリに保存できる場合に永続的です。たとえば、ハードディスクまたはフラッシュメモリなど） - ポリシールールまたはポリシールールグループの最大残りの寿命 - ポリシールールのアイドルタイムアウトミドルボックス（このアイドルタイムアウトの時期にデータトラフィックで使用されない予約および有効化されたポリシールールは、ミドルボックスによって自動的に削除されます。ミドルボックスによるポリシールールの削除については、セクション2.3.13、「非同期ポリシールールイベント（非同期ポリシールールイベント）を参照してください。それは）"）。 - 同時ミッドコムセッションの最大数
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プロトコルのパラメーターとして明示的に渡されるわけではありませんが、使用されている基礎となる（安全な）輸送プロトコルによって提供される可能性があります。Middleboxのエージェント識別子はMiddlebox-Uniqueであり、エージェントのミドルボックス識別子はそれぞれエージェントユニークです。
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.
[MDC-REQ]のMIDCOM要件は、以下に指定された一連のトランザクションによって満たされる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サービスを提供するすべてのMiddleboxサービスによって実装する必要があり、認証された各エージェントに提供する必要があります。オプションのトランザクションは、必ずしもミドルボックスで実装する必要はありません。これらのオプションのトランザクションは、特定の認証エージェントにのみ提供される場合があります。ミドルボックスは、エージェントに1つ、複数、すべて、またはオプションのトランザクションを提供できます。エージェントがオプションのリクエストトランザクションを使用することが許可されているかどうかは、このドキュメントではこれ以上指定されていないMiddleboxの承認手順によって決定されます。
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.
最初の2つは、エージェントによって開始された構成トランザクションであり、最後のトランザクションはミドルボックスによって開始された非同期トランザクションです。
transaction-name: session establishment
トランザクション名：セッション設立
transaction-type: configuration
トランザクションタイプ：構成
transaction-compliance: mandatory
Transaction-Compliance：必須
request-parameters:
リクエストパラメーター：
- request identifier: An agent-unique identifier for matching corresponding request and reply at the agent.
- リクエスト識別子：対応するリクエストとエージェントでの返信を一致させるためのエージェントユニーク識別子。
- version: The version of the MIDCOM protocol.
- バージョン：Midcomプロトコルのバージョン。
- middlebox challenge (mc): An authentication challenge token for authentication of the middlebox. As seen below, this is present only in the first iteration of the request.
- Middlebox Challenge（MC）：Middleboxの認証のための認証チャレンジトークン。以下に示すように、これはリクエストの最初の反復にのみ存在します。
- agent authentication (aa): An authentication token authenticating the agent to the middlebox. As seen below, this is updated in the second iteration of the request with material responding to the middlebox challenge.
- エージェント認証（AA）：エージェントをミドルボックスに認証する認証トークン。以下に示すように、これはリクエストの2回目の反復で更新され、Middleboxチャレンジに応答する資料があります。
reply-parameters (success):
Reply-Parameters（成功）：
- request identifier: An identifier matching the identifier request.
- 要求識別子：識別子要求に一致する識別子。
- middlebox authentication (ma): An authentication token authenticating the middlebox to the agent.
- Middlebox Authentication（MA）：エージェントにミドルボックスを認証する認証トークン。
- 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に示すように、2つの後続のセッション確立取引が必要です。
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
Transaction-Compliance：必須
request-parameters:
リクエストパラメーター：
- request identifier: An agent-unique identifier for matching corresponding request and reply at the agent.
- リクエスト識別子：対応するリクエストとエージェントでの返信を一致させるためのエージェントユニーク識別子。
reply-parameters (success only):
Reply-Parameters（成功のみ）：
- request identifier: An identifier matching the identifier of the request.
- 要求識別子：リクエストの識別子に一致する識別子。
semantics:
セマンティクス：
This transaction is used to close the MIDCOM session on behalf of the agent. After session termination, the middlebox keeps all established policy rules until their lifetime expires or until an event occurs that causes the middlebox to terminate them.
このトランザクションは、エージェントに代わってMIDCOMセッションを閉じるために使用されます。セッション終了後、Middleboxは、寿命が切れるまで、またはミドルボックスがそれらを終了させるイベントが発生するまで、すべての確立されたポリシールールを維持します。
The middlebox always generates a successful reply. After sending the reply, the middlebox will not send any further messages to the agent within the current session. It also will not process any further request within this session that it received while processing the session termination request or that it receives later.
ミドルボックスは常に成功した返信を生成します。返信を送信した後、MiddleBoxは現在のセッション内のエージェントにさらなるメッセージを送信しません。また、セッション終了リクエストの処理中や後で受信したときに受け取ったこのセッション内でさらなるリクエストを処理することはありません。
transaction-name: asynchronous session termination
トランザクション名：非同期セッション終了
transaction-type: asynchronous
トランザクションタイプ：非同期
transaction-compliance: mandatory
Transaction-Compliance：必須
notification message type: Session Termination Notification (STN)
通知メッセージタイプ：セッション終了通知（STN）
reply-parameters (success only):
Reply-Parameters（成功のみ）：
- 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つしかないため、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トランザクションが成功すると、状態の移行が州を開くことができます。それ以外の場合は、Noauthを状態に移行します。この状態から、失敗した第2のSEトランザクションが州が閉鎖された状態に戻ります。SEトランザクションが成功すると、トランジションがオープンになります。いつでも、ASTトランザクションまたは接続障害が発生し、状態が閉鎖されるようになる可能性があります。NoauthまたはOpenからのSTトランザクションが成功すると、閉鎖されます。トランザクションのパラメーターを図2で説明します。値mc = 0は、空のミドルボックスチャレンジを表します。
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
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）は、エージェントによって開始された構成トランザクションです。4番目と5番目（PRL、PRS）はトランザクションを監視しています。最後の（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
ポリシールールトランザクションごととRLCは、MIDCOMプロトコルのコアを構成します。どちらも必須であり、それらに役立ちます
- configuring NAT bindings (PER) - configuring firewall pinholes (PER) - extending the lifetime of established policy rules (RLC) - deleting policy rules (RLC)
- NATバインディングの構成（PER） - ファイアウォールピンホールの構成（PER） - 確立されたポリシールール（RLC）の寿命の拡張 - ポリシールールの削除（RLC）
Some cases require knowing in advance which IP address (and port number) would be chosen by NAT in a PER transaction. This information is required before sufficient information for performing a complete PER transaction is available (see example in section 4.2). For supporting such cases, the core transactions are extended by the Policy Reserve Rule (PRR) transaction serving for
一部のケースでは、どのIPアドレス（およびポート番号）がトランザクションごとにNATが選択するかを事前に知る必要があります。この情報は、完全なトランザクションを実行するための十分な情報が利用可能である前に必要です（セクション4.2の例を参照）。そのようなケースをサポートするために、コアトランザクションはポリシーリザーブルール（PRR）トランザクションによって拡張されます
- reserving addresses and port numbers at NATs (PRR)
- NATSでの住所とポート番号の予約（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プロトコルエンジンの状態遷移はNATSとまったく同じです。
On a traditional NAT (see [NAT-TRAD]), only an external address is reserved; on a twice-NAT, an internal and an external address are reserved. The reservation at a NAT is for required resources, such as IP addresses and port numbers, for future use. How the reservation is exactly done depends on the implementation of the NAT. In both cases, the reservation concerns either an IP address only or a combination of an IP address with a range of port numbers.
従来のNAT（[nat-trad]を参照）では、外部アドレスのみが予約されています。2回のネットでは、内部および外部アドレスが予約されています。NATでの予約は、将来の使用のために、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.
各ポリシールールには、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.)
各ポリシールールには、個々の寿命があります。ポリシールールの寿命が切れる場合、ポリシールールはミドルボックスで終了します。通常、ミドルボックスは、as and transactionによるポリシールールの終了を示します。ポリシールールのライフタイム変更（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つを指定した場合、新しいメンバーが既存のグループに追加されます。グループは、メンバーポリシールールを持っている限り存在します。グループに属するすべてのポリシーが生涯の終わりに到達するとすぐに、グループはもう存在しません。
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.
ポリシールールが状態を変更する場合、または残りの寿命が時間に減少する以外に変更された場合、このポリシールールにアクセスし、ミドルボックスでのオープンセッションに参加するすべてのエージェントにミドルボックスが通知されます。状態または生涯の変更が要求メッセージによって明示的に要求された場合、MiddleBoxは、対応する返信を返すことにより要求エージェントに通知します。ポリシーにアクセスできる他のすべてのエージェントは、ポリシールールイベント通知（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.
生涯の切り捨てまたはエージェントによってトリガーされていない他のイベントによるルール終了の場合、MiddleBoxは特定のポリシールールにアクセスし、ミドルボックスとのオープンセッションに参加できる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
さらに、PRの要求メッセージと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はそれらを結合します。ファイアウォールに関しては、従来のNAT：A1はA3と同じ値を持っています。
For a twice-NAT, there are two bindings of address tuples: A1 and A2 are both assigned values by the NAT. The middlebox outside address A2 is bound to the internal endpoint A0, and the middlebox inside address A1 is bound to the external endpoint A3.
2回ナットの場合、アドレスタプルの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」がある場合、MiddleBoxでのパケット処理のためにIPヘッダーのみが考慮されます。つまり、トランスポートヘッダーは考慮されません。プロトコルパラメーターが「任意」である場合、パラメーターポート番号、ポート範囲、およびポートパリティの値は無関係です。ポリシールールでは、トランスポートプロトコルパラメーターの値は、すべてのアドレスタプル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）とポリシーを有効にするルール（PERS）のコンテキストでは異なって使用されています。PRRのコンテキストでは、パラメーターの値は「奇数」、「偶数」、または「any」である場合があります。最初の（最低）予約されたポート番号のパリティを指定します。
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のコンテキストでは、ポートパリティパラメーターは、ミドルボックスに割り当てられたポート番号がそれぞれ対応する内部または外部ポート番号と同じパリティを持つ必要があるかどうかをミドルボックスに示します。これに関連して、パラメーターには値「同じ」または「any」があります。値が「同じ」の場合、A0のポート番号のパリティは、A2のポート番号のパリティと同じでなければならず、A1のポート番号のパリティはポートのパリティと同じでなければなりませんA3の数。ポートパリティパラメーターに値「any」がある場合、ポート番号のパリティに制約はありません。
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の値は、単一のポート番号を指定します。ポート範囲パラメーターは、各アドレスタプルA0、A1、A2、およびA3に対して同じ値を持っている必要があります。
A single policy rule P containing a port range value greater than one is equivalent to a set of policy rules containing a number n of policies P_1, P_2, ..., P_n where n equals the value of the port range parameter. Each policy rule P_1, P_2, ..., P_n has a port range parameter value of 1. Policy rule P_1 contains a set of address tuples A0_1, A1_1, A2_1, and A3_1, each of which contains the first port number of the respective address tuples in P; policy rule P_2 contains a set of address tuples A0_2, A1_2, A2_2, and A3_2, each of which contains the second port number of the respective address tuples in P; and so on.
1より大きいポート範囲値を含む単一のポリシールールPは、ポリシーP_1、P_2、...、P_Nの数を含むポリシールールのセットに相当します。各ポリシールールP_1、P_2、...、P_Nのポート範囲パラメーター値は1です。ポリシールールP_1には、それぞれがそれぞれの最初のポート番号が含まれているA0_1、A1_1、A2_1、およびA3_1のアドレスのセットが含まれています。Pのタプルをアドレスします。ポリシールールP_2には、アドレスのセットが含まれています。タプルA0_2、A1_2、A2_2、およびA3_2が含まれており、それぞれにPのそれぞれのアドレスタプルの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
通常、エージェントは、A0とA3のみの知識、つまりアドレスのタプルのみの知識を持つポリシールールを要求します（セクション2.3.5を参照）。しかし、非常に特別な場合、エージェントは、要求されたポリシールールが拘束されるインターフェイスを選択する必要がある場合があります。一般的に、ミドルボックスは、ポリシールールを予約または有効にするときに、その構成に関する全体的な知識があるため、適切なインターフェイスを選択することに注意しています。インターフェイスを選択したいエージェントの場合、オプションのパラメーターはポリシーリザーブルール（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
Transaction-Type：Configuration Transaction-Compliance：必須
request-parameters:
リクエストパラメーター：
- request identifier: An agent-unique identifier for matching corresponding request and reply at the agent.
- リクエスト識別子：対応するリクエストとエージェントでの返信を一致させるためのエージェントユニーク識別子。
- group identifier: A reference to the group of which the policy reserve rule should be a member. As indicated in section 2.3.3, if this value is not supplied, the middlebox assigns a new group for this policy reserve rule.
- グループ識別子：ポリシーリザーブルールがメンバーである必要があるグループへの参照。セクション2.3.3に示されているように、この値が提供されていない場合、Middleboxはこのポリシーリザーブルールに新しいグループを割り当てます。
- service: The requested NAT service of the middlebox. Allowed values are 'traditional' or 'twice'.
- サービス：ミドルボックスの要求されたNATサービス。許可された値は「従来」または「2回」です。
- 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アドレス：内部通信エンドポイントのIPアドレス（図3のA0）;セクション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.
- 港湾パリティ：予約される最初の（最低）港番号の要求されたパリティ。このパラメーターの許可された値は、「奇数」、「偶数」、および「any」です。セクション2.3.5も参照してください。
- policy rule lifetime: A lifetime proposal to the middlebox for the requested policy rule.
- ポリシールールの寿命：要求されたポリシールールのミドルボックスへの生涯提案。
reply-parameters (success):
Reply-Parameters（成功）：
- request identifier: An identifier matching the identifier of the request.
- 要求識別子：リクエストの識別子に一致する識別子。
- policy rule identifier: A middlebox-unique policy rule identifier. It is assigned by the middlebox and used as policy rule handle in further policy rule transactions, particularly to refer to the policy reserve rule in a subsequent PER transaction.
- ポリシールール識別子：Middlebox-Uniqueポリシールール識別子。これはミドルボックスによって割り当てられ、特にトランザクションごとの後続のポリシーリザーブルールを参照するために、さらなるポリシールールトランザクションでポリシールールハンドルとして使用されます。
- group identifier: A reference to the group of which the policy reserve rule is a member.
- グループ識別子：ポリシーリザーブルールがメンバーであるグループへの参照。
- reserved inside IP address: The reserved IPv4 or IPv6 address on the internal side of the middlebox. For an outbound flow, this will be the destination to which the internal endpoint sends its packets (A1 in Figure 3). For an inbound flow, it will be the apparent source address of the packets as forwarded to the internal endpoint (A0 in Figure 3). The middlebox reserves and reports an internal address only in the case where twice-NAT is in effect. Otherwise, an empty value for the addresses indicates that no internal reservation was made. See also section 2.3.5.
- 内部IPアドレス内：ミドルボックスの内部側の予約済みのIPv4またはIPv6アドレス。アウトバウンドフローの場合、これは内部エンドポイントがパケットを送信する宛先です（図3のA1）。インバウンドフローの場合、内部エンドポイントに転送されるパケットの見かけのソースアドレスになります（図3のA0）。ミドルボックスは、2倍のNATが有効な場合にのみ内部アドレスを予約および報告します。それ以外の場合、アドレスの空の値は、内部予約が行われなかったことを示しています。セクション2.3.5も参照してください。
- reserved inside port number: See section 2.3.5.
- 内部ポート番号：セクション2.3.5を参照してください。
- reserved outside IP address: The reserved IPv4 or IPv6 address on the external side of the middlebox. For an inbound flow, this will be the destination to which the external endpoint sends its packets (A2 in Figure 3). For an outbound flow, it will be the apparent source address of the packets as forwarded to the external endpoint (A3 in Figure 3). If the middlebox is configured as a pure firewall, an empty value for the addresses indicates that no external reservation was made. See also section 2.3.5.
- 予約済みのIPアドレス：ミドルボックスの外側にある予約されたIPv4またはIPv6アドレス。インバウンドフローの場合、これは外部エンドポイントがパケットを送信する宛先です（図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.
- ポリシールールの寿命：ミドルボックスによって付与されたポリシールールの寿命。その後、トランザクションごとにポリシーを有効にするルールにすでに置き換えられていない場合、予約は取り消されます。
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.
リクエストを受信すると、Middleboxは、その構成に基づいて、どのアドレス（およびポート）予約が必要なかを決定します。パケットフィルターサービスのみを提供する場合、予約を実行せず、内外のIPアドレスとポート番号の予約された値の空の値を返します。2回NATに対して構成されている場合、IPアドレスの内側と外側の両方（およびオプションの範囲のポート番号）の両方を予約し、それらを返します。それ以外の場合は、外部のIPアドレス（およびオプションの範囲のポート番号）を予約および返却し、予約された内部アドレスとポート範囲の空の値を返します。
The A0 parameter (inside IP address version, inside IP address, and inside port number) can be used by the middlebox to determine the correct NAT mapping and thus A2 if necessary. Once a PRR transaction has reserved an outside address (A2) for an internal endpoint (A0) at the middlebox, the middlebox must ensure that this reserved A2 is available in any subsequent PER and PRR transactions.
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で定義されているように、インターフェイス固有のポリシールールをサポートするミドルボックスの場合、オプションの内側と外側のインターフェイスパラメーターの両方をリクエストに含める必要があります。これらのパラメーターの存在下で、MiddleBoxは外部インターフェイスパラメーターを使用して、外部アドレスタプル（外側のIPアドレスとポート番号）が予約されているインターフェイスを選択し、内部インターフェイスパラメーターを使用して、内側のアドレスアドレスタプルを選択するインターフェイスパラメーターを選択します。（IPアドレス内とポート番号内）は予約されています。これらのパラメーターの存在がなければ、Middleboxはその内部構成に基づいて特定のインターフェイスを選択します。
If there is a lack of resources, such as available IP addresses, port numbers, or storage for further policy rules, then the reservation fails, and an appropriate failure reply is generated.
利用可能なIPアドレス、ポート番号、またはさらなるポリシールールのためのストレージなどのリソースが不足している場合、予約は失敗し、適切な障害返信が生成されます。
If a non-existing policy rule group was specified, or if an existing policy rule group was specified that is not owned by the requesting agent, then no new policy rule is established, and an appropriate failure reply is generated.
存在しないポリシールールグループが指定された場合、または要求エージェントが所有していない既存のポリシールールグループが指定された場合、新しいポリシールールは確立されず、適切な障害返信が生成されます。
In case of success, this transaction creates a new policy reserve rule. If an already existing policy rule group is specified, then the new policy rule becomes a member of it. If no policy group is specified, a new group is created with the new policy rule as its only member. The middlebox generates a middlebox-unique identifier for the new policy rule. The owner of the new policy rule is the authenticated agent that sent the request. The middlebox chooses a lifetime value that is greater than zero and less than or equal to the minimum of the requested value and the maximum lifetime specified by the middlebox at session startup, i.e.,
成功した場合、この取引は新しいポリシーリザーブルールを作成します。既存のポリシールールグループが指定されている場合、新しいポリシールールがメンバーになります。ポリシーグループが指定されていない場合、新しいポリシールールを唯一のメンバーとして新しいグループが作成されます。ミドルボックスは、新しいポリシールールのミドルボックスユニーク識別子を生成します。新しいポリシールールの所有者は、リクエストを送信した認証されたエージェントです。ミドルボックスは、セッションスタートアップ時にミドルボックスによって指定された要求値の最小値と最小寿命、つまり、つまり、ゼロよりも大きく、等しい寿命以下の生涯値を選択します。
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
where - lt_granted is the lifetime actually granted by the middlebox - lt_requested is the lifetime the agent requested - lt_maximum is the maximum lifetime specified at session setup
ここで-LT_GRANTEDは、MiddleBoxによって実際に付与された寿命です-LT_REQUESTEDはエージェントが要求した寿命です-LT_MAXIMUMはセッションセットアップで指定された最大寿命です
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要求に応じて常にミドルボックスの外部アドレスTuple（A2）を留保します。2回のNAT/NATミドルボックスを組み合わせた特別なケースでは、エージェントはサービスパラメーターの「従来」または「2回」を選択することにより、NATサービスまたは2回NATサービスのみを要求できます。好みのないエージェントが「2回」を選択します。「従来の」値は、従来のNATと2回のナットの両方を提供するミドルボックスで従来のNATサービスを選択するためにのみ使用する必要があります。「2回」の場合、2回のNAT/NATミドルボックスを組み合わせたものはA2とA1を留保します。「伝統的な」ケースは、A2のみの予約のみをもたらします。エージェントは、2回のNAT/NATミドルボックスを組み合わせた特別なケースで、NATのみまたは2回の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.
プロトコル識別子が「任意」の場合、ミドルボックスは内部および/または外部のIPアドレス（ES）のみを使用できます。予約アドレス（ES）はエージェントに返されます。この場合、リクエストパラメーター「ポート範囲」と「ポートパリティ」、および「ポート番号内」と「外部ポート番号」のReplyパラメーターは無関係です。
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）と最初の（最低）予約ポート番号がエージェントに返されます。（これは、ポートをサポートする他のプロトコルまたは同等物にも適用されます。）
After a new policy reserve rule is successfully established and the reply message has been sent to the requesting agent, the middlebox checks whether there are other authenticated agents participating in open sessions, which can access the new policy rule. If the middlebox finds one or more of these agents, then it sends a REN message reporting the new policy rule to each of them.
新しいポリシーリザーブルールが正常に確立され、返信メッセージが要求エージェントに送信された後、Middleboxは、新しいポリシールールにアクセスできるオープンセッションに参加している他の認証エージェントがいるかどうかを確認します。ミドルボックスがこれらのエージェントの1つ以上を見つけた場合、それぞれに新しいポリシールールを報告する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
Transaction-Compliance：必須
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トランザクションによって作成された既存のポリシーリザーブルールへの参照。参照が空になる場合があります。その場合、ミドルボックスは、トランザクションごとにこの内に必要なアドレスとポート番号を割り当てる必要があります。空でない場合、次の要求パラメーターは無関係です：グループ識別子、輸送プロトコル、ポート範囲、ポートパリティ、内部IPバージョン、外部IPバージョン。
- group identifier: A reference to the group of which the policy enable rule should be a member. As indicated in section 2.3.3, if this value is not supplied, the middlebox assigns a new group for this policy reserve rule.
- グループ識別子：ポリシーを有効にするグループへの参照ルールがメンバーである必要があります。セクション2.3.3に示されているように、この値が提供されていない場合、Middleboxはこのポリシーリザーブルールに新しいグループを割り当てます。
- transport protocol: See section 2.3.5.
- 輸送プロトコル：セクション2.3.5を参照してください。
- port range: The number of consecutive port numbers to be reserved; see section 2.3.5.
- ポートレンジ：予約される連続した港番号の数。セクション2.3.5を参照してください。
- port parity: The requested parity of the port number(s) to be mapped. Allowed values of this parameter are 'same' and 'any'. See also section 2.3.5.
- ポートパリティ：マッピングされる港番号の要求されたパリティ。このパラメーターの許可された値は「同じ」および「any」です。セクション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アドレス：内部通信エンドポイントのIPアドレス（図3のA0）;セクション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アドレス：外部通信エンドポイントのIPアドレス（図3のA3）;セクション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):
Reply-Parameters（成功）：
- request identifier: An identifier matching the identifier of the request.
- 要求識別子：リクエストの識別子に一致する識別子。
- policy rule identifier: A middlebox-unique policy rule identifier. It is assigned by the middlebox and used as policy rule handle in further policy rule transactions. If a policy reserve rule identifier was provided in the request, then the returned policy rule identifier has the same value.
- ポリシールール識別子：Middlebox-Uniqueポリシールール識別子。ミドルボックスによって割り当てられ、さらなるポリシールールトランザクションでポリシールールハンドルとして使用されます。リクエストでポリシーリザーブルール識別子が提供された場合、返されたポリシールール識別子は同じ値を持っています。
- group identifier: A reference to the group of which the policy enable rule is a member. If a policy reserve rule identifier was provided in the request, then this parameter identifies the group of which the policy reserve rule was a member.
- グループ識別子：ポリシーを有効にするグループへの参照ルールがメンバーです。リクエストでポリシーリザーブルール識別子が提供された場合、このパラメーターは、ポリシーリザーブルールがメンバーであったグループを識別します。
- inside IP address: The IP address provided at the inside of the middlebox (A1 in Figure 3). In case of a twice-NAT, this parameter will be an internal IP address reserved at the inside of the middlebox. In all other cases, this reply-parameter will be identical with the external IP address passed with the request. If the policy reserve rule identifier parameter was supplied in the request and the respective PRR transaction reserved an inside IP address, then the inside IP address provided in the PER response will be the identical value to that returned by the response to the PRR request. See also section 2.3.5.
- 内部IPアドレス：ミドルボックスの内側で提供されるIPアドレス（図3のA1）。2回のNATの場合、このパラメーターは、ミドルボックスの内側に予約されている内部IPアドレスになります。他のすべての場合において、このReply-Parameterは、リクエストに合格した外部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アドレス：ミドルボックスの外側で提供される外部IPアドレス（図3のA2）。純粋なファイアウォールの場合、このパラメーターは、リクエストで渡された内部IPアドレスと同一になります。他のすべての場合、このReply-Parameterは、ミドルボックスの外側に予約されている外部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
- このグループにメンバーを追加することを許可されていないエージェント - そのようなポリシーリザーブルールはありません - このポリシーリザーブルールを置き換えることを許可されていないエージェント - 既存のポリシールールとの競合（たとえば、同じ内部アドレスポートが異なる外部のアドレスポートにマッピングされていますペア） - 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
エージェントは、エンドポイント（オプションでワイルドカードを含む）と通信方向（インバウンド、アウトバウンド、双方向）を指定する有効な要求を送信します。通信エンドポイントを図3に示します。
1. the agent sending A0 and A3 to the middlebox,
1. A0とA3をミドルボックスに送信するエージェント、
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の間のパケット転送を有効にすること、および/または対応するピンホールを開くことにより、指定された方向に応じて開くことにより、
4. the middlebox returning A1 and A2 to the agent.
4. MiddleboxはA1とA2をエージェントに返します。
In case of a pure packet filtering firewall, the returned address tuples are the same as those in the request: A2=A0 and A1=A3. Each partner uses the other's real address. In case of a traditional NAT, the internal endpoint may use the real address of the external endpoint (A1=A3), but the external endpoint uses an 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）によって提供されるアドレスタプルを使用します。2回NATデバイスの場合、両方のエンドポイントは、通信パートナー（A3！= A1およびA2！= A0）に対処するためにNATが提供するアドレスタプルを使用します。
If a firewall is combined with a NAT or a twice-NAT, the replied address tuples will be the same as for pure traditional NAT or twice-NAT, respectively, but the middlebox will configure its packet filter in addition to the performed NAT bindings. In case of a firewall combined with a traditional NAT, the policy rule may imply more than one enable action for the firewall configuration, as incoming and outgoing packets may use different source-destination pairs.
ファイアウォールがNATまたは2回のネットと組み合わされている場合、返信アドレスタプルはそれぞれ純粋な従来のNATまたは2回のNATと同じですが、ミドルボックスは実行されたNATバインディングに加えてパケットフィルターを構成します。従来のNATと組み合わせたファイアウォールの場合、ポリシールールは、受信および発信パケットが異なるソース照明ペアを使用する可能性があるため、ファイアウォール構成の複数の有効化アクションを暗示する場合があります。
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で定義されているように、インターフェイス固有のポリシールールをサポートするミドルボックスの場合、オプションの内側と外側のインターフェイスパラメーターの両方をリクエストに含める必要があります。これらのパラメーターの存在下で、Middleboxは外部インターフェイスパラメーターを使用して、外側のアドレスタプル（外側のIPアドレスとポート番号）がバインドされているインターフェイスを選択し、内部インターフェイスパラメーターを使用して内側のアドレスアドレスタプルを選択します。（IPアドレス内とポート番号の内部）はバインドされています。これらのパラメーターの存在がなければ、Middleboxはその内部構成に基づいて特定のインターフェイスを選択します。
Checking the Policy Reservation Rule Identifier
ポリシー予約ルール識別子の確認
If the parameter specifying the policy reservation rule identifier is not empty, then the middlebox checks whether the referenced policy rule exists, whether the agent is authorized to replace this policy rule, and whether this policy rule is a policy reserve rule.
ポリシー予約ルール識別子を指定するパラメーターが空でない場合、MiddleBoxは参照されるポリシールールが存在するかどうか、エージェントがこのポリシールールを置き換えることを許可されているかどうか、およびこのポリシールールがポリシーリザーブルールであるかどうかを確認します。
In case of success, this transaction creates a new policy enable rule. If a policy reserve rule was referenced, then the policy reserve rule is terminated without an explicit notification sent to the agent (other than the successful PER reply).
成功した場合、このトランザクションは新しいポリシーを有効にするルールを作成します。ポリシーリザーブルールが参照された場合、ポリシーリザーブルールは、エージェントに送信される明示的な通知なしに終了します（返信ごとに成功したもの以外）。
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を設定します。新しいポリシーを有効にするルールを作成する過程で、Middleboxは、要求されたA0が予約済みのA0に等しいかどうかを確認できます。ミドルボックスは、予約されたA0に等しくない要求されたA0を使用して要求ごとの要求を拒否し、適切な障害メッセージを送信する必要があります。あるいは、リクエストごとにミドルボックスが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.
Transport Protocolパラメーター値が「ANY」の場合、MiddleBoxは指定された外部IPアドレスと指定された内部IPアドレス間の通信を有効にします。通信パートナーがお互いにアドレス指定するために使用されるアドレスは、IPアドレス内およびIPアドレスの外側としてエージェントに返されます。予約識別子が空でない場合、予約が同じ輸送プロトコルタイプを使用した場合、予約されたIPアドレスが使用されます。
For the transport protocol parameter values 'UDP' and 'TCP', the middlebox acts analogously as for 'ANY' but also maps ranges of port numbers, keeping the port parity, if requested.
トランスポートプロトコルパラメーター値「UDP」と「TCP」の場合、ミドルボックスは「任意の」と同様に機能しますが、要求があればポートパリティを維持するために、ポート番号の範囲もマップします。
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)
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は、MiddleBoxによって実際に付与された寿命です-LT_REQUESTEDはエージェントが要求した寿命です-LT_MAXIMUMはセッションセットアップで指定された最大寿命です
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.
障害のいずれの場合も、適切な障害応答が生成されます。トランザクションごとに参照されるポリシーリザーブルールは、トランザクションごとに障害が発生した場合、つまりポリシーリザーブルールが残っている場合は影響を受けません。
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.
新しいポリシーを有効にするルールが正常に確立され、返信メッセージが要求エージェントに送信された後、Middleboxは新しいポリシールールにアクセスできるオープンセッションに参加する他の認証エージェントがいるかどうかを確認します。ミドルボックスがこれらのエージェントの1つ以上を見つけた場合、それぞれに新しいポリシールールを報告するRENメッセージを送信します。
transaction-name: policy rule lifetime change
トランザクション名：ポリシールールのライフタイム変更
transaction-type: configuration
トランザクションタイプ：構成
transaction-compliance: mandatory
Transaction-Compliance：必須
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):
Reply-Parameters（成功）：
- 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.
Middleboxは、最初に指定されたポリシールールが存在するかどうか、およびエージェントがこのポリシールールにアクセスすることを許可されているかどうかを確認します。チェックの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)
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は、MiddleBoxによって実際に付与された寿命です-LT_REQUESTEDはエージェントが要求した寿命です-LT_MAXIMUMはセッションセットアップで指定された最大寿命です
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.
残りのポリシールールのライフタイムが正常に変更され、返信メッセージが要求エージェントに送信された後、Middleboxはポリシールールにアクセスできるオープンセッションに参加している他の認証エージェントがいるかどうかを確認します。ミドルボックスがこれらのエージェントの1つ以上を見つけた場合、それぞれに新しい残りのポリシールールの寿命を報告するRenメッセージを送信します。
transaction-name: policy rule list
トランザクション名：ポリシールールリスト
transaction-type: monitoring
トランザクションタイプ：監視
transaction-compliance: mandatory
Transaction-Compliance：必須
request-parameters:
リクエストパラメーター：
- request identifier: An agent-unique identifier for matching corresponding request and reply at the agent.
- リクエスト識別子：対応するリクエストとエージェントでの返信を一致させるためのエージェントユニーク識別子。
reply-parameters (success):
Reply-Parameters（成功）：
- 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.
Middleboxは最初に、エージェントがこのトランザクションを要求する権限があるかどうかを確認します。チェックが失敗した場合、適切な障害応答が生成されます。それ以外の場合、エージェントがアクセスできるすべてのポリシーのリストが返され、各ポリシーの識別子と所有者が示されます。
This transaction does not have any effect on the policy rule state.
このトランザクションは、ポリシールール状態に影響を与えません。
transaction-name: policy rule status
トランザクション名：ポリシールールステータス
transaction-type: monitoring
トランザクションタイプ：監視
transaction-compliance: mandatory
Transaction-Compliance：必須
request-parameters:
リクエストパラメーター：
- request identifier: An agent-unique identifier for matching corresponding request and reply at the agent.
- リクエスト識別子：対応するリクエストとエージェントでの返信を一致させるためのエージェントユニーク識別子。
- policy rule identifier: The middlebox-unique policy rule identifier.
- ポリシールール識別子：Middlebox-Uniqueポリシールール識別子。
reply-parameters (success):
Reply-Parameters（成功）：
- 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アドレス：内部通信エンドポイントのIPアドレス（図3のA0）;セクション2.3.5を参照してください。
- internal port number: The port number of the internal communication endpoint (A0 in Figure 3); see section 2.3.5.
-
- external IP address: The IP address of the external communication endpoint (A3 in Figure 3); see section 2.3.5.
- 外部IPアドレス：外部通信エンドポイントのIPアドレス（図3のA3）;セクション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の内側に提供される内部IPアドレス（図3のA1）;セクション2.3.5を参照してください。
- inside port number: The internal port number provided at the inside of the NAT (A1 in Figure 3); see section 2.3.5.
- 内部ポート番号：NATの内部で提供される内部ポート番号（図3のA1）。セクション2.3.5を参照してください。
- outside interface (optional): The outside interface at the middlebox; see section 2.3.7.
- 外部インターフェイス（オプション）：ミドルボックスの外部インターフェイス。セクション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アドレス：NATの外側で提供される外部IPアドレス（図3のA2）。セクション2.3.5を参照してください。
- outside port number: The external port number provided at the outside of the NAT (A2 in Figure 3); see section 2.3.5.
-
- 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).
-
- 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
Transaction-Compliance：必須
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）ごとに存在します。当初、すべてのポリシールールはState Pridの未使用であるため、ポリシールールが存在しないか、アクティブではないことを意味します。State Prid Unsedに戻った後、ポリシールール識別子は既存のポリシールールに拘束されなくなり、Middleboxによって再利用される場合があります。
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トランザクションが成功すると、住所予約が確立されている初期の州のプリッドから予約された州への移行が発生します。そこから、状態対応はトランザクションごとに入力できます。このトランザクションは、予約なしで未使用の州のプリッドから直接有効化された状態を入力するためにも使用できます。状態有効化では、内部エンドポイントと外部エンドポイントの間の要求された通信が有効になっています。
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.
予約および有効化された状態は、0を超える要求された寿命で成功したRLCトランザクションによって維持できます。これらの州の両方の州からの遷移は、as transactionによって引き起こされる可能性があります。。
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.
グループには、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のそれぞれのコンプライアンスエントリによって「オプション」と宣言されます。ただし、エージェントがいくつかのリクエストの代わりに1つのリクエストのみを送信する便利さなど、必須のトランザクションのみが利用できない場合は、いくつかの機能を提供します。利用可能。
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トランザクションは、エージェントの破損の場合に特に役立ちます。失敗した役割の役割を引き継ぐエージェントは、これらのトランザクションを使用して、失敗したエージェントによって確立されたポリシーを取得できます。
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
Transaction-Compliance：オプション
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):
Reply-Parameters（成功）：
- 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.
Middleboxは、指定されたグループが存在するかどうか、およびエージェントがこのグループにアクセスすることを許可されているかどうかを最初に確認します。チェックの1つが失敗した場合、適切な障害応答が生成されます。要求された寿命が現在の寿命よりも長い場合、Middleboxはグループの寿命が延長されるかどうかをチェックし、そうでない場合は適切な障害メッセージを生成します。
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)
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は、MiddleBoxによって実際に付与された寿命です-LT_REQUESTEDはエージェントが要求した寿命です-LT_MAXIMUMはセッションセットアップで指定された最大寿命です
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.
残りのポリシールールグループのLifetimeが正常に変更され、返信メッセージが要求エージェントに送信された後、Middleboxはポリシールールグループにアクセスできるオープンセッションに参加する他の認証エージェントがいるかどうかを確認します。ミドルボックスがこれらのエージェントの1つ以上を見つけた場合、それぞれに新しい残りのポリシールールグループのライフタイムを報告するGENメッセージを送信します。
transaction-name: group list
トランザクション名：グループリスト
transaction-type: monitoring
トランザクションタイプ：監視
transaction-compliance: optional
Transaction-Compliance：オプション
request-parameters:
リクエストパラメーター：
- request identifier: An agent-unique identifier for matching corresponding request and reply at the agent.
- リクエスト識別子：対応するリクエストとエージェントでの返信を一致させるためのエージェントユニーク識別子。
reply-parameters (success):
Reply-Parameters（成功）：
- 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.
Middleboxは最初に、エージェントがこのトランザクションを要求する権限があるかどうかを確認します。チェックが失敗した場合、適切な障害応答が生成されます。それ以外の場合、エージェントがアクセスできるすべてのグループのリストが返され、各グループの識別子と所有者を示します。
This transaction does not have any effect on the group state.
このトランザクションは、グループ状態に影響を与えません。
transaction-name: group status
トランザクション名：グループステータス
transaction-type: monitoring
トランザクションタイプ：監視
transaction-compliance: optional
Transaction-Compliance：オプション
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):
Reply-Parameters（成功）：
- 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.
- メンバーリスト：グループのメンバーであるすべてのポリシールールのリスト。ポリシールールは、Middlebox-Uniqueポリシールール識別子によって指定されています。
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.
Middleboxは、指定されたグループが存在するかどうか、およびエージェントがこのグループにアクセスすることを許可されているかどうかを最初に確認します。チェックの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）必須 - ポリシールールライフタイム変更（RLC）必須 - ポリシールールリスト（PRL）必須 - ポリシールールステータス（PRS）必須 - 非同期ポリシールールイベント（必須です
- 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.
MIDCOMプロトコルの準拠の実装は、GLC、GL、GS：次のトランザクションの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.
準拠した実装は、より微細なトランザクションのセットによって単一のトランザクションを置き換える場合があります。そのような場合、[MDC-REQ]の要件2.1.4（決定論的行動）と要件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つの使用例を示します。最初のものは、エージェントがミドルボックスでアクセスする可能性のあるすべてのポリシールールとポリシールールグループをどのように検討できるかを示しています。2番目の例は、セッション開始プロトコル（SIP）[RFC3261]とのVoice Over 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つのポリシールールを調査します。この例は、ミドルボックスが伝統的なナップであると仮定しています。図6は、最初のポリシールールの調査を示しています。ポリシールールステータス（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 |
| |
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に印刷されている「任意の」パラメーターは、ポリシーリザーブルールのポリシールールステータス応答のプレースホルダーとして使用されます。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.
PID2にPRSを適用する（図7）は、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アドレスとポート番号のIDは常に保持されます（図3のA1 = A3）。純粋なファイアウォールの場合、外部のIPアドレスとポート番号は常に内部IPアドレスとポート番号と同じです（図3のA0 = 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に示すように、2つのSIPユーザーエージェントがB2BUAとNAPTを介して互いに通信します。Midcomサーバーはミドルボックスにあります。したがって、MIDCOMプロトコルはB2BUAとMiddleboxの間で実行されます。
+-------------+
| 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
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は、ユーザーBの一般的なSIP URLを知っています。URLはb@example.orgです。ただし、ユーザー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
- IP_AI：ユーザーエージェントの内部IPアドレスA -P_AI：RTPデータを受信するユーザーエージェントAの内部ポート番号P_AE：外部マッピングポートユーザーエージェントA -IP_AE：ミドルボックスの外部IPアドレス-IP_B：ユーザーのIPアドレスエージェントB -P_B：RTPデータを受信するユーザーエージェントBのポート番号-GID：グループ識別子-PID：ポリシールール識別子
The abbreviations of the MIDCOM transactions can be found in the particular section headings.
MIDCOMトランザクションの略語は、特定のセクションの見出しにあります。
In our example, user A tries to call user B. The user agent A sends an INVITE SIP message to the B2BUA (see Figure 10). The SDP part of the particular SIP message relevant for the middlebox configuration is shown in the sequence chart as follows:
この例では、ユーザーAはユーザーBを呼び出そうとします。ユーザーエージェントAは、B2BUAに招待状のSIPメッセージを送信します（図10を参照）。ミドルボックス構成に関連する特定のSIPメッセージのSDP部分は、次のようにシーケンスチャートに表示されます。
SDP: m=..P_AI.. c=IP_AI
SDP：m = .. p_ai .. c = ip_ai
where the m tag is the media tag that contains the receiving UDP port number, and the c tag contains the IP address of the terminal receiving the media stream.
ここで、Mタグは受信UDPポート番号を含むメディアタグであり、Cタグにはメディアストリームを受信する端末のIPアドレスが含まれています。
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に転送される招待メッセージには、パブリックIPアドレスと、ユーザーエージェントBがRTPメディアストリームを送信できるポート番号が含まれている必要があります。B2BUAは、ワイルドカードのIPアドレスとポート番号のユーザーエージェントBを使用したリクエストを使用して、ミドルボックスでポリシーを有効にするルールを要求します。この時点では、ユーザーエージェントBのIPアドレスもポート番号も知られていないため、ユーザーエージェントのアドレスは知られていません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：ワイルドカードアドレスとポート番号を使用して
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に示すように、1回の返信が成功すると、ミドルボックスでNATバインディングが生じます。このバインディングにより、ホストの外部ユーザーエージェントAのプライベートネットワークからのUDPトラフィックがユーザーエージェントAに到達することができます。そのため、ユーザーエージェントBは、招待メッセージを受信した直後にトラフィックの送信を開始できます。、悪意のあるホストなど。
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ワイルドカードはサポートされていない」など、適切な障害理由で要求が拒否されます。それにもかかわらず、B2BUAは、SIP Inviteメッセージを転送するために、Middlebox（The NAPT）で外部のIPアドレスとポート番号を必要とします。
If the IP address of user agent B is still not known (it will be sent by user agent B in the SIP reply message) and IP address wildcarding is not permitted, the B2BUA uses the PRR transaction.
ユーザーエージェントBのIPアドレスがまだ不明である場合（SIP応答メッセージでユーザーエージェントBから送信されます）、IPアドレスWildCardingが許可されていない場合、B2BUAはPRRトランザクションを使用します。
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を使用して2回のネットなしで、外部アドレスのみが予約されています。招待メッセージのSDPペイロードでは、B2BUAはIPアドレスとポート番号のユーザーエージェントAをPRR応答の予約IPアドレスとポートに置き換えます（図12を参照）。SIP Inviteメッセージは、外部アドレスとポート番号を含む変更されたSDPボディを使用してユーザーエージェントBに転送され、ユーザーエージェントBがRTPメディアストリームを送信します。
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データは、ユーザーエージェントBからユーザーエージェントAに流れる可能性があります。PRR（PID1）のPIDを渡すことにより、トランザクションごとに予約を参照します。
For the opposite direction, UDP/RTP data from user agent A to B has to be enabled also. This is done by a second PER transaction with all the necessary parameters (see Figure 13). The request message contains the group identifier (GID1) the middlebox has assigned in the first PER transaction. Therefore, both policy rules have become 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からBへのUDP/RTPデータも有効にする必要があります。これは、必要なすべてのパラメーターを使用して、トランザクションごとに1秒で実行されます（図13を参照）。リクエストメッセージには、ミドルボックスが最初のトランザクションで割り当てたグループ識別子（GID1）が含まれています。したがって、両方のポリシールールが同じグループのメンバーになりました。両方のUDP/RTPストリームを有効にした後、B2BUAは「200 OK」SIPメッセージをユーザーエージェントAに転送して、電話が起動できることを示すことができます。
User Agent B2BUA Middlebox User Agent
A NAPT B
| | | |
| | PER PID1 UDP 1 SAME IN | |
| | IP_AI P_AI IP_B ANY 300s | |
| |*****************************>| |
| |<*****************************| |
| | PER OK GID1 PID1 IP_B ANY | |
| | IP_AE P_AE1 300s | |
| | | |
...media stream from user agent B to A enabled...
| | | |
| | PER GID1 UDP 1 SAME OUT | |
| | IP_AI ANY IP_B P_B 300s | |
| |*****************************>| |
| |<*****************************| |
| | PER OK GID1 PID2 IP_B P_B | |
| | IP_AE P_AE2 300s | |
| | | |
...media streams from both directions enabled...
| | | |
| 200 OK | | |
|<---------------| | |
| SDP:m=..P_B.. | | |
| c=IP_B | | |
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に「さようなら」SIPメッセージを送信します。B2BUAはすべてのSIPメッセージを転送し、その後グループを終了します。（図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.1） - プロトコルセマンティクス要件のコンプライアンス（セクション5.2） - セキュリティ要件のコンプライアンス（セクション5.3）
The requirements are referred to with the number of the section in which they are defined: "requirement x.y.z" refers to the requirement specified in section x.y.z of [MDC-REQ].
要件は、定義されているセクションの数で言及されています。「要件X.Y.Z」は、[MDC-Req]のセクションX.Y.Zで指定された要件を指します。
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は、要求トランザクションは互いに、そしてエージェントの観点から原子的であると述べています。すべてのトランザクションは、現在の安定した明確に定義された状態を離れ、新しい安定した明確な状態を入力するか、現在の安定した明確な状態に残っている状態遷移として明確に定義されています。セクション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.
前のセクションで議論したように、Middleboxは、エージェントが要求したサービスのいずれかに関連するすべての州の移行についてエージェントに明確に通知します。また、エージェントはいつでも、すべてのアクセス可能なポリシールールとポリシールールグループに関する完全なステータス情報を取得できます。したがって、要件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つの後続のセッション確立トランザクションまたはより低いプロトコル層で提供される相互認証を使用します。したがって、要件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 Session Termination notification at any time and then terminate the session. Thus, requirement 2.1.9 is met.
セマンティクスの仕様は、セクション2.2.2の指定されており、エージェントはセッション終了要求を生成してセッション終了を要求し、ミドルボックスがこのリクエストを拒否しない可能性があると述べています。次に、セクション2.2.3では、ミドルボックスが非同期セッション終了通知をいつでも送信し、セッションを終了する可能性があると述べています。したがって、要件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.
ミドルボックスでの状態遷移は、明確に指定され、エージェントに通信されます。要求の部分的な処理によって到達する中間状態はありません。すべてのリクエストは、常に正常にまたは失敗して完全に処理されます。すべての要求トランザクションには、失敗の理由のリストが含まれています。これらの障害理由は、該当する場合、無効なパラメーターの兆候をカバーしています。障害の場合、指定された理由の1つがミドルボックスからエージェントに返されます。したがって、要件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を参照）。したがって、要件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を参照）、およびトランザクションごとにアドレスバインディングまたはピンホールを確立するとき（セクション2.3を参照するときに、ポート番号の連続範囲を要求できます。.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は、「有効」/「許可」や「無効」/「禁止」などの矛盾する政策規則措置がサポートされているという仮定に基づいています。要件文書を完成させた後、ワーキンググループが下した決定に準拠して、「無効」/「禁止」アクションがサポートされていないため、この要件はセマンティクスによって満たされません。
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]を参照）は、セキュリティに関して非常に敏感なポイントです。Middlebox-Externalエンティティからのポリシールールの構成は、ミドルボックスの性質と矛盾するようです。したがって、効果的な手段を使用するために使用する必要があります
- 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.
ワイルドカードの合理的なデフォルトの構成は、ワイルドカードを1つのポート番号のみであり、すべてのIPアドレスをワイルドカードなしで設定する必要があることです。ただし、セキュリティを機能とバランスさせる必要がある場合があります。
The example described in section 4.2 shows how SIP-signaled calls can be served in a secure way without wildcarding IP addresses. But some SIP-signaled applications make use of early media (see section 5.5 of [RFC3398]). To receive early media, the middleboxes need to be configured before the second participant in a session is known. As it is not known, the IP address of the second participant needs to be wildcarded.
セクション4.2で説明した例は、IPアドレスをワイルドカードすることなく、SIPシグナル通話を安全な方法でどのように提供できるかを示しています。しかし、一部のSIPシグナルアプリケーションでは、初期のメディアを使用しています（[RFC3398]のセクション5.5を参照）。初期のメディアを受信するには、セッションの2番目の参加者が既知になる前に、ミドルボックスを構成する必要があります。知られていないため、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.
そのような場合、およびいくつかの場合には、Middleboxオペレーターがセキュリティポリシーの決定を下す必要があります。オペレーターは、たとえばワイルドカード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（STUN）[RFC3489]を介したUDPプロトコルの単純なトラバーサルなどの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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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.、Rosenberg、J.、Molitor、A。、およびA. Rayhan、「Middlebox Communication Architecture and Framework」、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.、Mart、P.、Sijben、P.、Brim、S.、およびM. Shore、「Middlebox Communications（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. Taylor、「Middlebox Communications（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. Holdrege、「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] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.1」、RFC 4346、2006年4月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302] Kent、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロード（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.、Quinn、B.、Herzog、S.、Huynh、A.、Carlson、M.、Perry、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、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] Camarillo、G.、Roach、A.、Peterson、J。、およびL. Ong、「Integrated Services Digital Network（ISDN）ユーザーパーツ（ISUP）セッション開始プロトコル（SIP）マッピング」、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.
[RFC3424] Daigle、L。およびIAB、「ネットワークアドレス翻訳全体の一方的な自己アドレス固定（UNSAF）に関するIABの考慮事項」、RFC 3424、2002年11月。
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003.
[RFC3489] Rosenberg、J.、Weinberger、J.、Huitema、C。、およびR. Mahy、「スタン - ネットワークアドレス翻訳者（NAT）を介したユーザーデータグラムプロトコル（UDP）の単純なトラバーサル」、RFC 3489、2003年3月。
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プロキシサーバーを使用しました。これはRFC 3261の違反でした。これは、SIPプロキシサーバーを連続したユーザーエージェントに置き換えることで修正されました。
2. Clarifications concerning the used set of transaction types have been added.
2. トランザクションタイプの使用済みセットに関する説明が追加されました。
3. Section 3.1, "General Implementation Conformance", now uses key words from RFC 2119.
3. セクション3.1、「一般的な実装の適合性」は、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
Martin Stiemerling Nec Europe Ltd. Kurfuersten-Anlage 36 69115ハイデルベルクドイツ
Phone: +49 6221 4342-113
EMail: stiemerling@nw.neclab.eu
Juergen Quittek NEC Europe Ltd. Kurfuersten-Anlage 36 69115 Heidelberg Germany
Juergen Quittek Nec Europe Ltd. Kurfuersten-Anlage 36 69115ハイデルベルクドイツ
Phone: +49 6221 4342-115
EMail: 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
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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への情報をお問い合わせください。