<pre>Network Working Group                                     M. Stiemerling
Request for Comments: 5189                                    J. Quittek
Obsoletes: <a href="./rfc3989">3989</a>                                                      NEC
Category: Standards Track                                      T. Taylor
                                                                  Nortel
                                                              March 2008


          <span class="h1">Middlebox Communication (MIDCOM) Protocol Semantics</span>

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.

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 <a href="./rfc3989">RFC 3989</a>.






















<span class="grey">Stiemerling, et al.         Standards Track                     [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


Table of Contents

   <a href="#section-1">1</a>. Introduction ....................................................<a href="#page-4">4</a>
      <a href="#section-1.1">1.1</a>. Terminology ................................................<a href="#page-5">5</a>
      <a href="#section-1.2">1.2</a>. Transaction Definition Template ............................<a href="#page-7">7</a>
   <a href="#section-2">2</a>. Semantics Specification .........................................<a href="#page-8">8</a>
      <a href="#section-2.1">2.1</a>. General Protocol Design ....................................<a href="#page-8">8</a>
           <a href="#section-2.1.1">2.1.1</a>. Protocol Transactions ...............................<a href="#page-8">8</a>
           <a href="#section-2.1.2">2.1.2</a>. Message Types .......................................<a href="#page-9">9</a>
           <a href="#section-2.1.3">2.1.3</a>. Session, Policy Rule, and Policy Rule Group ........<a href="#page-10">10</a>
           <a href="#section-2.1.4">2.1.4</a>. Atomicity ..........................................<a href="#page-11">11</a>
           <a href="#section-2.1.5">2.1.5</a>. Access Control .....................................<a href="#page-11">11</a>
           <a href="#section-2.1.6">2.1.6</a>. Middlebox Capabilities .............................<a href="#page-12">12</a>
           <a href="#section-2.1.7">2.1.7</a>. Agent and Middlebox Identifiers ....................<a href="#page-12">12</a>
           <a href="#section-2.1.8">2.1.8</a>. Conformance ........................................<a href="#page-13">13</a>
      <a href="#section-2.2">2.2</a>. Session Control Transactions ..............................<a href="#page-13">13</a>
           <a href="#section-2.2.1">2.2.1</a>. Session Establishment (SE) .........................<a href="#page-14">14</a>
           <a href="#section-2.2.2">2.2.2</a>. Session Termination (ST) ...........................<a href="#page-16">16</a>
           <a href="#section-2.2.3">2.2.3</a>. Asynchronous Session Termination (AST) .............<a href="#page-16">16</a>
           <a href="#section-2.2.4">2.2.4</a>. Session Termination by Interruption of Connection ..17
           <a href="#section-2.2.5">2.2.5</a>. Session State Machine ..............................<a href="#page-17">17</a>
      <a href="#section-2.3">2.3</a>. Policy Rule Transactions ..................................<a href="#page-18">18</a>
           <a href="#section-2.3.1">2.3.1</a>. Configuration Transactions .........................<a href="#page-19">19</a>
           <a href="#section-2.3.2">2.3.2</a>. Establishing Policy Rules ..........................<a href="#page-19">19</a>
           <a href="#section-2.3.3">2.3.3</a>. Maintaining Policy Rules and Policy Rule Groups ....<a href="#page-20">20</a>
           <a href="#section-2.3.4">2.3.4</a>. Policy Events and Asynchronous Notifications .......<a href="#page-21">21</a>
           <a href="#section-2.3.5">2.3.5</a>. Address Tuples .....................................<a href="#page-21">21</a>
           <a href="#section-2.3.6">2.3.6</a>. Address Parameter Constraints ......................<a href="#page-23">23</a>
           <a href="#section-2.3.7">2.3.7</a>. Interface-Specific Policy Rules ....................<a href="#page-25">25</a>
           <a href="#section-2.3.8">2.3.8</a>. Policy Reserve Rule (PRR) ..........................<a href="#page-25">25</a>
           <a href="#section-2.3.9">2.3.9</a>. Policy Enable Rule (PER) ...........................<a href="#page-30">30</a>
           <a href="#section-2.3.10">2.3.10</a>. Policy Rule Lifetime Change (RLC) .................<a href="#page-36">36</a>
           <a href="#section-2.3.11">2.3.11</a>. Policy Rule List (PRL) ............................<a href="#page-38">38</a>
           <a href="#section-2.3.12">2.3.12</a>. Policy Rule Status (PRS) ..........................<a href="#page-39">39</a>
           <a href="#section-2.3.13">2.3.13</a>. Asynchronous Policy Rule Event (ARE) ..............<a href="#page-41">41</a>
           <a href="#section-2.3.14">2.3.14</a>. Policy Rule State Machine .........................<a href="#page-42">42</a>
      <a href="#section-2.4">2.4</a>. Policy Rule Group Transactions ............................<a href="#page-43">43</a>
           <a href="#section-2.4.1">2.4.1</a>. Overview ...........................................<a href="#page-43">43</a>
           <a href="#section-2.4.2">2.4.2</a>. Group Lifetime Change (GLC) ........................<a href="#page-44">44</a>
           <a href="#section-2.4.3">2.4.3</a>. Group List (GL) ....................................<a href="#page-46">46</a>
           <a href="#section-2.4.4">2.4.4</a>. Group Status (GS) ..................................<a href="#page-47">47</a>
   <a href="#section-3">3</a>. Conformance Statements .........................................<a href="#page-48">48</a>
      <a href="#section-3.1">3.1</a>. General Implementation Conformance ........................<a href="#page-49">49</a>
      <a href="#section-3.2">3.2</a>. Middlebox Conformance .....................................<a href="#page-50">50</a>
      <a href="#section-3.3">3.3</a>. Agent Conformance .........................................<a href="#page-50">50</a>
   <a href="#section-4">4</a>. Transaction Usage Examples .....................................<a href="#page-50">50</a>
      <a href="#section-4.1">4.1</a>. Exploring Policy Rules and Policy Rule Groups .............<a href="#page-50">50</a>
      <a href="#section-4.2">4.2</a>. Enabling a SIP-Signaled Call ..............................<a href="#page-54">54</a>



<span class="grey">Stiemerling, et al.         Standards Track                     [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


   <a href="#section-5">5</a>. Compliance with MIDCOM Requirements ............................<a href="#page-59">59</a>
      <a href="#section-5.1">5.1</a>. Protocol Machinery Requirements ...........................<a href="#page-59">59</a>
           <a href="#section-5.1.1">5.1.1</a>. Authorized Association .............................<a href="#page-59">59</a>
           <a href="#section-5.1.2">5.1.2</a>. Agent Connects to Multiple Middleboxes .............<a href="#page-60">60</a>
           <a href="#section-5.1.3">5.1.3</a>. Multiple Agents Connect to Same Middlebox ..........<a href="#page-60">60</a>
           <a href="#section-5.1.4">5.1.4</a>. Deterministic Behavior .............................<a href="#page-60">60</a>
           <a href="#section-5.1.5">5.1.5</a>. Known and Stable State .............................<a href="#page-60">60</a>
           <a href="#section-5.1.6">5.1.6</a>. Status Report ......................................<a href="#page-61">61</a>
           <a href="#section-5.1.7">5.1.7</a>. Unsolicited Messages (Asynchronous Notifications) ..61
           <a href="#section-5.1.8">5.1.8</a>. Mutual Authentication ..............................<a href="#page-61">61</a>
           <a href="#section-5.1.9">5.1.9</a>. Session Termination by Any Party ...................<a href="#page-61">61</a>
           <a href="#section-5.1.10">5.1.10</a>. Request Result ....................................<a href="#page-62">62</a>
           <a href="#section-5.1.11">5.1.11</a>. Version Interworking ..............................<a href="#page-62">62</a>
           <a href="#section-5.1.12">5.1.12</a>. Deterministic Handling of Overlapping Rules .......<a href="#page-62">62</a>
      <a href="#section-5.2">5.2</a>. Protocol Semantics Requirements ...........................<a href="#page-62">62</a>
           <a href="#section-5.2.1">5.2.1</a>. Extensible Syntax and Semantics ....................<a href="#page-62">62</a>
           <a href="#section-5.2.2">5.2.2</a>. Policy Rules for Different Types of Middleboxes ....<a href="#page-63">63</a>
           <a href="#section-5.2.3">5.2.3</a>. Ruleset Groups .....................................<a href="#page-63">63</a>
           <a href="#section-5.2.4">5.2.4</a>. Policy Rule Lifetime Extension .....................<a href="#page-63">63</a>
           <a href="#section-5.2.5">5.2.5</a>. Robust Failure Modes ...............................<a href="#page-63">63</a>
           <a href="#section-5.2.6">5.2.6</a>. Failure Reasons ....................................<a href="#page-63">63</a>
           <a href="#section-5.2.7">5.2.7</a>. Multiple Agents Manipulating Same Policy Rule ......<a href="#page-63">63</a>
           <a href="#section-5.2.8">5.2.8</a>. Carrying Filtering Rules ...........................<a href="#page-64">64</a>
           <a href="#section-5.2.9">5.2.9</a>. Parity of Port Numbers .............................<a href="#page-64">64</a>
           <a href="#section-5.2.10">5.2.10</a>. Consecutive Range of Port Numbers .................<a href="#page-64">64</a>
           <a href="#section-5.2.11">5.2.11</a>. Contradicting Overlapping Policy Rules ............<a href="#page-64">64</a>
      <a href="#section-5.3">5.3</a>. Security Requirements .....................................<a href="#page-64">64</a>
           <a href="#section-5.3.1">5.3.1</a>. Authentication, Confidentiality, Integrity .........<a href="#page-64">64</a>
           <a href="#section-5.3.2">5.3.2</a>. Optional Confidentiality of Control Messages .......<a href="#page-64">64</a>
           <a href="#section-5.3.3">5.3.3</a>. Operation across Untrusted Domains .................<a href="#page-65">65</a>
           <a href="#section-5.3.4">5.3.4</a>. Mitigate Replay Attacks ............................<a href="#page-65">65</a>
   <a href="#section-6">6</a>. Security Considerations ........................................<a href="#page-65">65</a>
   <a href="#section-7">7</a>. IAB Considerations on UNSAF ....................................<a href="#page-66">66</a>
   <a href="#section-8">8</a>. Acknowledgements ...............................................<a href="#page-66">66</a>
   <a href="#section-9">9</a>. References .....................................................<a href="#page-67">67</a>
      <a href="#section-9.1">9.1</a>. Normative References ......................................<a href="#page-67">67</a>
      <a href="#section-9.2">9.2</a>. Informative References ....................................<a href="#page-67">67</a>
   <a href="#appendix-A">Appendix A</a>. Changes from <a href="./rfc3989">RFC 3989</a> .................................<a href="#page-69">69</a>













<span class="grey">Stiemerling, et al.         Standards Track                     [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   The MIDCOM working group has defined a framework [<a href="#ref-MDC-FRM" title="&quot;Middlebox communication architecture and framework&quot;">MDC-FRM</a>] and a list
   of requirements [<a href="#ref-MDC-REQ" title="&quot;Middlebox Communications (midcom) Protocol Requirements&quot;">MDC-REQ</a>] 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.

   This memo suggests a semantics for the MIDCOM protocol.  It is fully
   compliant with the requirements listed in [<a href="#ref-MDC-REQ" title="&quot;Middlebox Communications (midcom) Protocol Requirements&quot;">MDC-REQ</a>] and with the
   working group's consensus on semantic issues.  This document
   obsoletes <a href="./rfc3989">RFC 3989</a> [<a href="#ref-MDC-SEM" title="&quot;Middlebox Communications (MIDCOM) Protocol Semantics&quot;">MDC-SEM</a>].

   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.

   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.

   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.

   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.

   The remainder of this document is structured as follows.  <a href="#section-2">Section 2</a>
   describes the protocol semantics.  It is structured in four
   subsections:

      - General Protocol Design (<a href="#section-2.1">section 2.1</a>)
      - Session Control (<a href="#section-2.2">section 2.2</a>)
      - Policy Rules (<a href="#section-2.3">section 2.3</a>)
      - Policy Rule Groups (<a href="#section-2.4">section 2.4</a>)



<span class="grey">Stiemerling, et al.         Standards Track                     [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


   <a href="#section-3">Section 3</a> contains conformance statements for MIDCOM protocol
   definitions and MIDCOM protocol implementations with respect to the
   semantics defined in <a href="#section-2">section 2</a>.  <a href="#section-4">Section 4</a> gives two elaborated usage
   examples.  Finally, <a href="#section-5">section 5</a> explains how the semantics meets the
   MIDCOM requirements.

<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>.  Terminology</span>

   The terminology in this memo follows the definitions given in the
   framework [<a href="#ref-MDC-FRM" title="&quot;Middlebox communication architecture and framework&quot;">MDC-FRM</a>] and requirements [<a href="#ref-MDC-REQ" title="&quot;Middlebox Communications (midcom) Protocol Requirements&quot;">MDC-REQ</a>] document.

   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.




<span class="grey">Stiemerling, et al.         Standards Track                     [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


   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.

   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.

   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"  [<a href="./rfc3198" title="&quot;Terminology for Policy-Based Management&quot;">RFC3198</a>].  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".

   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.

   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.







<span class="grey">Stiemerling, et al.         Standards Track                     [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


   NAT binding                The term NAT binding as used in this
                              document does not necessarily refer to a
                              NAT bind as defined in [<a href="#ref-NAT-TERM" title="&quot;IP Network Address Translator (NAT) Terminology and Considerations&quot;">NAT-TERM</a>].  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.

   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 <a href="./rfc2119">RFC 2119</a> [<a href="./rfc2119" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">RFC2119</a>].

<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>.  Transaction Definition Template</span>

   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.

   transaction-name
      A description name for this type of transaction.

   transaction-type
      The transaction type is either 'configuration', 'monitoring', or
      'asynchronous'.  See <a href="#section-1.1">section 1.1</a> for a description of transaction
      types.

   transaction-compliance
      This entry contains either 'mandatory' or 'optional'.  For
      details, see <a href="#section-2.1.8">section 2.1.8</a>.

   request-parameters
      This entry lists all parameters necessary for this request.  A
      description for each parameter is given.

   reply-parameters (success)
      This entry lists all parameters sent back from the middlebox to
      the agent as positive response to the prior request.  A
      description for each parameter is given.

   failure reason
      All negative replies have two parameters: a request identifier
      identifying the request on which the reply is sent and a parameter
      indicating the failure reason.  As these parameters are
      compulsory, they are not listed in the template.  But the template




<span class="grey">Stiemerling, et al.         Standards Track                     [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


      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.

   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.

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Semantics Specification</span>

<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>.  General Protocol Design</span>

   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.

<span class="h4"><a class="selflink" id="section-2.1.1" href="#section-2.1.1">2.1.1</a>.  Protocol Transactions</span>

   State transitions are initiated either by a request message from the
   agent to the middlebox or by some other event at the middlebox.  In
   the first case, the middlebox informs the agent by sending a reply
   message on the actual state transition; in the second, the middlebox
   sends an unsolicited asynchronous notification message to each agent
   affected by the transaction (if it participates in an open session
   with the middlebox).

   Request and reply messages contain an agent-unique request identifier
   that allows the agent to determine to which sent request a received
   reply corresponds.

   An analysis of the requirements showed that three kinds of
   transactions are required:

      - Configuration transactions allowing the agent to request state
        transitions at the middlebox.



<span class="grey">Stiemerling, et al.         Standards Track                     [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


      - 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.

   Monitoring transactions are not related to middlebox state
   transitions.  They are used by agents to explore the number, status,
   and properties of policy rules established at the middlebox.

   As specified in detail in <a href="#section-3">section 3</a>, 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.

<span class="h4"><a class="selflink" id="section-2.1.2" href="#section-2.1.2">2.1.2</a>.  Message Types</span>

   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.

   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 <a href="#section-1.2">section 1.2</a>.

   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.







<span class="grey">Stiemerling, et al.         Standards Track                     [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


   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   The Session Termination Notification message additionally
         contains a single parameter indicating the reason for session
         termination by the middlebox.

   REN   The Policy Rule Event Notification message contains the
         notification identifier, a policy rule identifier, and the
         remaining policy lifetime.

   GEN   The Group Event Notification message contains the notification
         identifier, a policy rule group identifier, and the remaining
         policy rule group lifetime.

<span class="h4"><a class="selflink" id="section-2.1.3" href="#section-2.1.3">2.1.3</a>.  Session, Policy Rule, and Policy Rule Group</span>

   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.

   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 <a href="#section-2.4">section 2.4</a>).

   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.









<span class="grey">Stiemerling, et al.         Standards Track                    [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


<span class="h4"><a class="selflink" id="section-2.1.4" href="#section-2.1.4">2.1.4</a>.  Atomicity</span>

   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.

<span class="h4"><a class="selflink" id="section-2.1.5" href="#section-2.1.5">2.1.5</a>.  Access Control</span>

   Ownership determines access to policy rules and policy rule groups.
   When a policy rule is created, a middlebox-unique identifier is
   generated to identify it in further transactions.  Beyond the
   identifier, each policy rule has an owner.  The owner is the
   authenticated agent that established the policy rule.  The middlebox
   uses the owner attribute of a policy rule to control access to it;
   each time an authenticated agent requests to modify an existing
   policy rule, the middlebox determines the owner of the policy rule
   and checks whether the requesting agent is authorized to perform
   transactions on the owning agent's policy rules.

   All policy rules belonging to the same policy rule group must have
   the same owner.  Therefore, authenticated agents have access either
   to all members of a policy rule group or to none of them.

   The middlebox may be configured to allow specific authenticated
   agents to access and modify policy rules with certain specific
   owners.  Certainly, a reasonable default configuration would let each
   agent access its own policy rules.  Also, it might be good to
   configure an agent identity to act as administrator, allowing



<span class="grey">Stiemerling, et al.         Standards Track                    [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


   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.

<span class="h4"><a class="selflink" id="section-2.1.6" href="#section-2.1.6">2.1.6</a>.  Middlebox Capabilities</span>

   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 <a href="#section-2.2.1">section</a>
   <a href="#section-2.2.1">2.2.1</a> includes a transfer of capability information from the
   middlebox to the agent.  The list of covered middlebox capabilities
   includes the following:

      - 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 <a href="#section-2.3.13">section</a>
        <a href="#section-2.3.13">2.3.13</a>, "Asynchronous Policy Rule Event (ARE)").
      - Maximum number of simultaneous MIDCOM sessions

   The list of middlebox capabilities may be extended by a concrete
   protocol specification with further information useful for the agent.

<span class="h4"><a class="selflink" id="section-2.1.7" href="#section-2.1.7">2.1.7</a>.  Agent and Middlebox Identifiers</span>

   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



<span class="grey">Stiemerling, et al.         Standards Track                    [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


   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.

<span class="h4"><a class="selflink" id="section-2.1.8" href="#section-2.1.8">2.1.8</a>.  Conformance</span>

   The MIDCOM requirements in [<a href="#ref-MDC-REQ" title="&quot;Middlebox Communications (midcom) Protocol Requirements&quot;">MDC-REQ</a>] 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.

   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.

<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>.  Session Control Transactions</span>

   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.

   All transactions are transmitted within this MIDCOM session.






<span class="grey">Stiemerling, et al.         Standards Track                    [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


   Session control is supported by three transactions:

      - Session Establishment (SE)
      - Session Termination (ST)
      - Asynchronous Session Termination (AST)

   The first two are configuration transactions initiated by the agent,
   and the last one is an asynchronous transaction initiated by the
   middlebox.

<span class="h4"><a class="selflink" id="section-2.2.1" href="#section-2.2.1">2.2.1</a>.  Session Establishment (SE)</span>

   transaction-name: session establishment

   transaction-type: configuration

   transaction-compliance: mandatory

   request-parameters:

      - request identifier: An agent-unique identifier for matching
        corresponding request and reply at the agent.

      - version: The version of the MIDCOM protocol.

      - 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.

      - 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.

   reply-parameters (success):

      - request identifier: An identifier matching the identifier
        request.

      - middlebox authentication (ma): An authentication token
        authenticating the middlebox to the agent.

      - agent challenge (ac): An authentication challenge token for the
        agent authentication.

      - middlebox capabilities: A list describing the middlebox's
        capabilities.  See <a href="#section-2.1.6">section 2.1.6</a> for the list of middlebox
        capabilities.



<span class="grey">Stiemerling, et al.         Standards Track                    [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


   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.

             agent                                       middlebox
               | session establishment request               |
               |  (with middlebox challenge mc)              | CLOSED
               |--------------------------------------------&gt;|
               |                                             |
               | successful reply (with middlebox            |
               |  authentication ma and agent challenge ac)  |
               |&lt;--------------------------------------------|
               |                                             | NOAUTH
               | session establishment request               |
               |  (with agent authentication aa)             |
               |--------------------------------------------&gt;|
               |                                             |
               | successful reply                            |
               |&lt;--------------------------------------------|
               |                                             | OPEN
               |                                             |

            Figure 1: Mutual Authentication of Agent and Middlebox

      Session establishment may be simplified by using only a single
      transaction.  In this case, server challenge and agent challenge
      are omitted by the sender or ignored by the receiver, and
      authentication must be provided by other means, for example, by
      Transport Layer Security (TLS) [<a href="./rfc4346" title="&quot;The Transport Layer Security (TLS) Protocol Version 1.1&quot;">RFC4346</a>] or IPsec
      [<a href="./rfc4302" title="&quot;IP Authentication Header&quot;">RFC4302</a>][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.



<span class="grey">Stiemerling, et al.         Standards Track                    [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


      Part of the successful reply is an indication of the middlebox's
      capabilities.

<span class="h4"><a class="selflink" id="section-2.2.2" href="#section-2.2.2">2.2.2</a>.  Session Termination (ST)</span>

   transaction-name: session termination

   transaction-type: configuration

   transaction-compliance: mandatory

   request-parameters:

      - request identifier: An agent-unique identifier for matching
        corresponding request and reply at the agent.

   reply-parameters (success only):

      - request identifier: An identifier matching the identifier of the
        request.

   semantics:

      This transaction is used to close the MIDCOM session on behalf of
      the agent.  After session termination, the middlebox keeps all
      established policy rules until their lifetime expires or until an
      event occurs that causes the middlebox to terminate them.

      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.

<span class="h4"><a class="selflink" id="section-2.2.3" href="#section-2.2.3">2.2.3</a>.  Asynchronous Session Termination (AST)</span>

   transaction-name: asynchronous session termination

   transaction-type: asynchronous

   transaction-compliance: mandatory

   notification message type: Session Termination Notification (STN)

   reply-parameters (success only):

      - termination reason: The reason why the session is terminated.



<span class="grey">Stiemerling, et al.         Standards Track                    [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


   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.

      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.

<span class="h4"><a class="selflink" id="section-2.2.4" href="#section-2.2.4">2.2.4</a>.  Session Termination by Interruption of Connection</span>

   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.

<span class="h4"><a class="selflink" id="section-2.2.5" href="#section-2.2.5">2.2.5</a>.  Session State Machine</span>

   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.

   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.








<span class="grey">Stiemerling, et al.         Standards Track                    [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


                                   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   |&lt;---------------+
               +----------+

               Figure 2: Session State Machine

<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>.  Policy Rule Transactions</span>

   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)

   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.

   Before any transaction can start, a valid MIDCOM session must be
   established.










<span class="grey">Stiemerling, et al.         Standards Track                    [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


<span class="h4"><a class="selflink" id="section-2.3.1" href="#section-2.3.1">2.3.1</a>.  Configuration Transactions</span>

   Policy rule transactions PER and RLC constitute the core of the
   MIDCOM protocol.  Both are mandatory, and they serve for

      - configuring NAT bindings (PER)
      - configuring firewall pinholes (PER)
      - extending the lifetime of established policy rules (RLC)
      - deleting policy rules (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 <a href="#section-4.2">section 4.2</a>).
   For supporting such cases, the core transactions are extended by the
   Policy Reserve Rule (PRR) transaction serving for

      - reserving addresses and port numbers at NATs (PRR)

<span class="h4"><a class="selflink" id="section-2.3.2" href="#section-2.3.2">2.3.2</a>.  Establishing Policy Rules</span>

   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.

   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.

   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.

   On a traditional NAT (see [<a href="#ref-NAT-TRAD" title="&quot;Traditional IP Network Address Translator (Traditional NAT)&quot;">NAT-TRAD</a>]), 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.

   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.



<span class="grey">Stiemerling, et al.         Standards Track                    [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


   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.

   On a combined NAT/firewall, the enable action is interpreted as a
   combination of bind and allow actions.

   The PRR transaction and the PER transaction are described in more
   detail in sections <a href="#section-2.3.8">2.3.8</a> and <a href="#section-2.3.9">2.3.9</a> below.

<span class="h4"><a class="selflink" id="section-2.3.3" href="#section-2.3.3">2.3.3</a>.  Maintaining Policy Rules and Policy Rule Groups</span>

   Each policy rule has a middlebox-unique identifier.

   Each policy rule has an owner.  Access control to the policy rule is
   based on ownership (see <a href="#section-2.1.5">section 2.1.5</a>).  Ownership of a policy rule
   does not change during lifetime of the policy rule.

   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.)

   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.

   Agents can explore the properties and status of all policy rules they
   are allowed to access by using the Policy Rule Status (PRS)
   transaction.






<span class="grey">Stiemerling, et al.         Standards Track                    [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


<span class="h4"><a class="selflink" id="section-2.3.4" href="#section-2.3.4">2.3.4</a>.  Policy Events and Asynchronous Notifications</span>

   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.

   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.

   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.

<span class="h4"><a class="selflink" id="section-2.3.5" href="#section-2.3.5">2.3.5</a>.  Address Tuples</span>

   Request and reply messages of the PRR, PER, and PRS transactions
   contain address specifications for IP and transport addresses.  These
   parameters include

      - IP version
      - IP address
      - IP address prefix length
      - transport protocol
      - port number
      - port parity
      - port range




<span class="grey">Stiemerling, et al.         Standards Track                    [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


   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

      - 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.

      - 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.

      - bidirectional: bidirectional TCP packet flow.  First packet,
        with TCP SYN flag set and ACK flag not set, may arrive at inside
        or outside interface.

   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.

       +----------+                                 +----------+
       | internal | A0    A1 +-----------+ A2    A3 | external |
       | endpoint +----------+ middlebox +----------+ endpoint |
       +----------+          +-----------+          +----------+

                   Figure 3: Address Tuples A0 - A3

      - A0 - internal endpoint: Address tuple A0 specifies a
        communication endpoint of a device within the internal network,
        with respect to the middlebox.

      - 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.





<span class="grey">Stiemerling, et al.         Standards Track                    [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


      - 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.

      - A3 - external endpoint: Address tuple A3 specifies a
        communication endpoint of a device within the external network,
        with respect to the middlebox.

   For a firewall, the inside and outside endpoints are identical to the
   corresponding external or internal endpoints, respectively.  In this
   case, the installed policy rule sets the same value in A2 as in A0
   (A0=A2) and sets the same value in A1 as in A3 (A1=A3).

   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.

   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.

<span class="h4"><a class="selflink" id="section-2.3.6" href="#section-2.3.6">2.3.6</a>.  Address Parameter Constraints</span>

   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.

   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.

   The value of the IP address parameter must conform with the specified
   IP version.





<span class="grey">Stiemerling, et al.         Standards Track                    [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


   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 <a href="#section-6">section 6</a>,
   "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.

   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.

   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.

   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.

   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.

   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



<span class="grey">Stiemerling, et al.         Standards Track                    [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


   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.

   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.

<span class="h4"><a class="selflink" id="section-2.3.7" href="#section-2.3.7">2.3.7</a>.  Interface-Specific Policy Rules</span>

   Usually, agents request policy rules with the knowledge of A0 and A3
   only, i.e., the address tuples (see <a href="#section-2.3.5">section 2.3.5</a>).  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

      - 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.

   Agents can learn at session startup whether interface-specific policy
   rules are supported by the middlebox, by checking the middlebox
   capabilities (see <a href="#section-2.1.6">section 2.1.6</a>).

<span class="h4"><a class="selflink" id="section-2.3.8" href="#section-2.3.8">2.3.8</a>.  Policy Reserve Rule (PRR)</span>

   transaction-name: policy reserve rule

   transaction-type: configuration




<span class="grey">Stiemerling, et al.         Standards Track                    [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


   transaction-compliance: mandatory

   request-parameters:

      - request identifier: An agent-unique identifier for matching
        corresponding request and reply at the agent.

      - group identifier: A reference to the group of which the policy
        reserve rule should be a member.  As indicated in <a href="#section-2.3.3">section 2.3.3</a>,
        if this value is not supplied, the middlebox assigns a new group
        for this policy reserve rule.

      - service: The requested NAT service of the middlebox.  Allowed
        values are 'traditional' or 'twice'.

      - internal IP version: Requested IP version at the inside of the
        middlebox; see <a href="#section-2.3.5">section 2.3.5</a>.

      - internal IP address: The IP address of the internal
        communication endpoint (A0 in Figure 3); see <a href="#section-2.3.5">section 2.3.5</a>.

      - internal port number: The port number of the internal
        communication endpoint (A0 in Figure 3); see <a href="#section-2.3.5">section 2.3.5</a>.

      - inside interface (optional): Interface at the inside of the
        middlebox; see <a href="#section-2.3.7">section 2.3.7</a>.

      - external IP version: Requested IP version at the outside of the
        middlebox; see <a href="#section-2.3.5">section 2.3.5</a>.

      - outside interface (optional): Interface at the outside of the
        middlebox; see <a href="#section-2.3.7">section 2.3.7</a>.

      - transport protocol: See <a href="#section-2.3.5">section 2.3.5</a>.

      - port range: The number of consecutive port numbers to be
        reserved; see <a href="#section-2.3.5">section 2.3.5</a>.

      - 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 <a href="#section-2.3.5">section 2.3.5</a>.

      - policy rule lifetime: A lifetime proposal to the middlebox for
        the requested policy rule.







<span class="grey">Stiemerling, et al.         Standards Track                    [Page 26]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-27" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


   reply-parameters (success):

      - request identifier: An identifier matching the identifier of the
        request.

      - policy rule identifier: A middlebox-unique policy rule
        identifier.  It is assigned by the middlebox and used as policy
        rule handle in further policy rule transactions, particularly to
        refer to the policy reserve rule in a subsequent PER
        transaction.

      - 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
        <a href="#section-2.3.5">section 2.3.5</a>.

      - reserved inside port number: See <a href="#section-2.3.5">section 2.3.5</a>.

      - 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
        <a href="#section-2.3.5">section 2.3.5</a>.

      - reserved outside port number: See <a href="#section-2.3.5">section 2.3.5</a>.

      - 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.








<span class="grey">Stiemerling, et al.         Standards Track                    [Page 27]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-28" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


   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

   notification message type: Policy Rule Event Notification (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
      <a href="#section-4.2">section 4.2</a> for an example.

      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.

      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.

      For middleboxes supporting interface-specific policy rules, as
      defined in <a href="#section-2.3.7">section 2.3.7</a>, 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



<span class="grey">Stiemerling, et al.         Standards Track                    [Page 28]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-29" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


      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.

      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.

      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;= lt_granted &lt;= 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

      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




<span class="grey">Stiemerling, et al.         Standards Track                    [Page 29]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-30" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


      or twice-NAT service in the special case of a combined twice-
      NAT/NAT middlebox.  A firewall middlebox ignores this parameter.

      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.

      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.)

      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.

   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 <a href="#section-2.3.2">section 2.3.2</a>.

<span class="h4"><a class="selflink" id="section-2.3.9" href="#section-2.3.9">2.3.9</a>.  Policy Enable Rule (PER)</span>

   transaction-name: policy enable rule

   transaction-type: configuration

   transaction-compliance: mandatory

   request-parameters:

      - request identifier: An agent-unique identifier for matching
        corresponding request and reply at the agent.

      - policy reserve rule identifier: A reference to an already
        existing policy reserve rule created by a PRR transaction.  The
        reference may be empty, in which case the middlebox must assign
        any necessary addresses and port numbers within this PER
        transaction.  If it is not empty, then the following request
        parameters are irrelevant: group identifier, transport protocol,



<span class="grey">Stiemerling, et al.         Standards Track                    [Page 30]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-31" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


        port range, port parity, internal IP version, external IP
        version.

      - group identifier: A reference to the group of which the policy
        enable rule should be a member.  As indicated in <a href="#section-2.3.3">section 2.3.3</a>,
        if this value is not supplied, the middlebox assigns a new group
        for this policy reserve rule.

      - transport protocol: See <a href="#section-2.3.5">section 2.3.5</a>.

      - port range: The number of consecutive port numbers to be
        reserved; see <a href="#section-2.3.5">section 2.3.5</a>.

      - port parity: The requested parity of the port number(s) to be
        mapped.  Allowed values of this parameter are 'same' and 'any'.
        See also <a href="#section-2.3.5">section 2.3.5</a>.

      - 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 <a href="#section-2.3.5">section 2.3.5</a>.

      - internal IP address: The IP address of the internal
        communication endpoint (A0 in Figure 3); see <a href="#section-2.3.5">section 2.3.5</a>.

      - internal port number: The port number of the internal
        communication endpoint (A0 in Figure 3); see <a href="#section-2.3.5">section 2.3.5</a>.

      - inside interface (optional): Interface at the inside of the
        middlebox; see <a href="#section-2.3.7">section 2.3.7</a>.

      - external IP version: Requested IP version at the outside of the
        middlebox; see <a href="#section-2.3.5">section 2.3.5</a>.

      - external IP address: The IP address of the external
        communication endpoint (A3 in Figure 3); see <a href="#section-2.3.5">section 2.3.5</a>.

      - external port number: The port number of the external
        communication endpoint (A3 in Figure 3), see <a href="#section-2.3.5">section 2.3.5</a>.

      - outside interface (optional): Interface at the outside of the
        middlebox; see <a href="#section-2.3.7">section 2.3.7</a>.

      - policy rule lifetime: A lifetime proposal to the middlebox for
        the requested policy rule.




<span class="grey">Stiemerling, et al.         Standards Track                    [Page 31]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-32" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


   reply-parameters (success):

      - request identifier: An identifier matching the identifier of the
        request.

      - policy rule identifier: A middlebox-unique policy rule
        identifier.  It is assigned by the middlebox and used as policy
        rule handle in further policy rule transactions.  If a policy
        reserve rule identifier was provided in the request, then the
        returned policy rule identifier has the same value.

      - group identifier: A reference to the group of which the policy
        enable rule is a member.  If a policy reserve rule identifier
        was provided in the request, then this parameter identifies the
        group of which the policy reserve rule was a member.

      - inside IP address: The IP address provided at the inside of the
        middlebox (A1 in Figure 3).  In case of a twice-NAT, this
        parameter will be an internal IP address reserved at the inside
        of the middlebox.  In all other cases, this reply-parameter will
        be identical with the external IP address passed with the
        request.  If the policy reserve rule identifier parameter was
        supplied in the request and the respective PRR transaction
        reserved an inside IP address, then the inside IP address
        provided in the PER response will be the identical value to that
        returned by the response to the PRR request.  See also <a href="#section-2.3.5">section</a>
        <a href="#section-2.3.5">2.3.5</a>.

      - inside port number: The internal port number provided at the
        inside of the middlebox (A1 in Figure 3);  see also <a href="#section-2.3.5">section</a>
        <a href="#section-2.3.5">2.3.5</a>.

      - 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 <a href="#section-2.3.5">section 2.3.5</a>.

      - outside port number: The external port number provided at the
        outside of the NAT (A2 in Figure 3); see <a href="#section-2.3.5">section 2.3.5</a>..

      - policy rule lifetime: The policy rule lifetime granted by the
        middlebox.

   failure reason:

      - agent not authorized for this transaction



<span class="grey">Stiemerling, et al.         Standards Track                    [Page 32]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-33" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


      - 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

   notification message type: Policy Rule Event Notification (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.

      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

         1. the agent sending A0 and A3 to the middlebox,

         2. the middlebox reserving A1 and A2 or using A1 and A2 from a
            previous PRR transaction,

         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

         4. the middlebox returning A1 and A2 to the agent.

      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



<span class="grey">Stiemerling, et al.         Standards Track                    [Page 33]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-34" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


      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).

      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.

      For middleboxes supporting interface-specific policy rules, as
      defined in <a href="#section-2.3.7">section 2.3.7</a>, 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.

      Checking the Policy Reservation Rule Identifier

         If the parameter specifying the policy reservation rule
         identifier is not empty, then the middlebox checks whether the
         referenced policy rule exists, whether the agent is authorized
         to replace this policy rule, and whether this policy rule is a
         policy reserve rule.

         In case of success, this transaction creates a new policy
         enable rule.  If a policy reserve rule was referenced, then the
         policy reserve rule is terminated without an explicit
         notification sent to the agent (other than the successful PER
         reply).

         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.





<span class="grey">Stiemerling, et al.         Standards Track                    [Page 34]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-35" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


         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.

      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.

      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.

      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.,




<span class="grey">Stiemerling, et al.         Standards Track                    [Page 35]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-36" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


         0 &lt;= lt_granted &lt;= 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

   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.

<span class="h4"><a class="selflink" id="section-2.3.10" href="#section-2.3.10">2.3.10</a>.  Policy Rule Lifetime Change (RLC)</span>

   transaction-name: policy rule lifetime change

   transaction-type: configuration

   transaction-compliance: mandatory

   request-parameters:

      - request identifier: An agent-unique identifier for matching
        corresponding request and reply at the agent.

      - policy rule identifier: Identifying the policy rule for which
        the lifetime is requested to be changed.  This may identify
        either a policy reserve rule or a policy enable rule.

      - policy rule lifetime: The new lifetime proposal for the policy
        rule.

   reply-parameters (success):

      - request identifier: An identifier matching the identifier of the
        request.

      - policy rule lifetime: The remaining policy rule lifetime granted
        by the middlebox.





<span class="grey">Stiemerling, et al.         Standards Track                    [Page 36]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-37" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


   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)

   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.

      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;= lt_granted &lt;= 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

   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.





<span class="grey">Stiemerling, et al.         Standards Track                    [Page 37]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-38" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


   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.

   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.

<span class="h4"><a class="selflink" id="section-2.3.11" href="#section-2.3.11">2.3.11</a>.  Policy Rule List (PRL)</span>

   transaction-name: policy rule list

   transaction-type: monitoring

   transaction-compliance: mandatory

   request-parameters:

      - request identifier: An agent-unique identifier for matching
        corresponding request and reply at the agent.

   reply-parameters (success):

      - request identifier: An identifier matching the identifier of the
        request.

      - policy list: List of policy rule identifiers of all policy rules
        that the agent can access.

   failure reason:

      - transaction not supported
      - agent not authorized for this transaction














<span class="grey">Stiemerling, et al.         Standards Track                    [Page 38]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-39" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


   semantics:

      The agent can use this transaction type to list all policies that
      it can access.  Usually, the agent has this information already,
      but in special cases (for example, after an agent fail-over) or
      for special agents (for example, an administrating agent that can
      access all policies) this transaction can be helpful.

      The middlebox first checks whether the agent is authorized to
      request this transaction.  If the check fails, an appropriate
      failure reply is generated.  Otherwise, a list of all policies the
      agent can access is returned indicating the identifier and the
      owner of each policy.

      This transaction does not have any effect on the policy rule
      state.

<span class="h4"><a class="selflink" id="section-2.3.12" href="#section-2.3.12">2.3.12</a>.  Policy Rule Status (PRS)</span>

   transaction-name: policy rule status

   transaction-type: monitoring

   transaction-compliance: mandatory

   request-parameters:

      - request identifier: An agent-unique identifier for matching
        corresponding request and reply at the agent.

      - policy rule identifier: The middlebox-unique policy rule
        identifier.

   reply-parameters (success):

      - request identifier: An identifier matching the identifier of the
        request.

      - policy rule owner: An identifier of the agent owning this policy
        rule.

      - group identifier: A reference to the group of which the policy
        rule is a member.

      - policy rule action: This parameter has either the value
        'reserve' or the value 'enable'.





<span class="grey">Stiemerling, et al.         Standards Track                    [Page 39]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-40" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


      - transport protocol: Identifies the protocol for which a
        reservation is requested; see <a href="#section-2.3.5">section 2.3.5</a>.

      - port range: The number of consecutive port numbers; see <a href="#section-2.3.5">section</a>
        <a href="#section-2.3.5">2.3.5</a>.

      - 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).

      - external IP address version: The version of the external IP
        address (IP version of A3 in Figure 3).

      - internal IP address: The IP address of the internal
        communication endpoint (A0 in Figure 3); see <a href="#section-2.3.5">section 2.3.5</a>.

      - internal port number: The port number of the internal
        communication endpoint (A0 in Figure 3); see <a href="#section-2.3.5">section 2.3.5</a>.

      - external IP address: The IP address of the external
        communication endpoint (A3 in Figure 3); see <a href="#section-2.3.5">section 2.3.5</a>.

      - external port number: The port number of the external
        communication endpoint (A3 in Figure 3); see <a href="#section-2.3.5">section 2.3.5</a>.

      - inside interface (optional): The inside interface at the
        middlebox; see <a href="#section-2.3.7">section 2.3.7</a>.

      - inside IP address: The internal IP address provided at the
        inside of the NAT (A1 in Figure 3); see <a href="#section-2.3.5">section 2.3.5</a>.

      - inside port number: The internal port number provided at the
        inside of the NAT (A1 in Figure 3); see <a href="#section-2.3.5">section 2.3.5</a>.

      - outside interface (optional): The outside interface at the
        middlebox; see <a href="#section-2.3.7">section 2.3.7</a>.

      - outside IP address: The external IP address provided at the
        outside of the NAT (A2 in Figure 3); see <a href="#section-2.3.5">section 2.3.5</a>.

      - outside port number: The external port number provided at the
        outside of the NAT (A2 in Figure 3); see <a href="#section-2.3.5">section 2.3.5</a>.

      - port parity: The parity of the allocated ports.





<span class="grey">Stiemerling, et al.         Standards Track                    [Page 40]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-41" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


      - service: The selected service in the case of mixed traditional
        and twice-NAT middlebox (see <a href="#section-2.3.8">section 2.3.8</a>).

      - 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.

      This transaction does not have any effect on the policy rule
      state.

<span class="h4"><a class="selflink" id="section-2.3.13" href="#section-2.3.13">2.3.13</a>.  Asynchronous Policy Rule Event (ARE)</span>

   transaction-name: asynchronous policy rule event

   transaction-type: asynchronous

   transaction-compliance: mandatory

   notification message type: Policy Rule Event Notification (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




<span class="grey">Stiemerling, et al.         Standards Track                    [Page 41]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-42" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


      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; lt_existing), extending
      (lt_new &gt; lt_existing), or terminating the policy rule
      (lt_new = 0).

   The ARE transaction corresponds to the REN message handling described
   in <a href="#section-2.3.4">section 2.3.4</a> for multiple agents.

<span class="h4"><a class="selflink" id="section-2.3.14" href="#section-2.3.14">2.3.14</a>.  Policy Rule State Machine</span>

   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.

                         PRR/success   +---------------+
                     +-----------------+  PRID UNUSED  |&lt;-+
           +----+    |                 +---------------+  |
           |    |    |                   ^   |            |
           |    v    v                   |   |            |
           |  +-------------+    ARE     |   | PER/       | ARE
           |  |   RESERVED  +------------+   | success    | RLC(lt=0)/
           |  +-+----+------+  RLC(lt=0)/    |            |  success
           |    |    |          success      |            |
           +----+    |                       v            |
         RLC(lt&gt;0)/  | PER/success     +---------------+  |
          success    +----------------&gt;|    ENABLED    +--+
                                       +-+-------------+
                                         |           ^
             lt = lifetime               +-----------+
                                       RLC(lt&gt;0)/success

                   Figure 4: Policy Rule State Machine

   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.




<span class="grey">Stiemerling, et al.         Standards Track                    [Page 42]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-43" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


   A successful PRR transaction causes a transition from the initial
   state PRID UNUSED to the state RESERVED, where an address reservation
   is established.  From there, state ENABLED can be entered by a PER
   transaction.  This transaction can also be used for entering state
   ENABLED directly from state PRID UNUSED without a reservation.  In
   state ENABLED, the requested communication between the internal and
   the external endpoint is enabled.

   The states RESERVED and ENABLED can be maintained by successful RLC
   transactions with a requested lifetime greater than 0.  Transitions
   from both of these states back to state PRID UNUSED can be caused by
   an ARE transaction or by a successful RLC transaction with a lifetime
   parameter of 0.

   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.

<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>.  Policy Rule Group Transactions</span>

   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)

   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.

<span class="h4"><a class="selflink" id="section-2.4.1" href="#section-2.4.1">2.4.1</a>.  Overview</span>

   A policy rule group has only one attribute: the list of its members.
   All member policies of a single group must be owned by the same
   authenticated agent.  Therefore, an implicit property of a group is
   its owner, which is the owner of the member policy rules.

   A group is implicitly created when its first member policy rule is
   established.  A group is implicitly terminated when the last
   remaining member policy rule is terminated.  Consequently, the
   lifetime of a group is the maximum of the lifetimes of all member
   policy rules.

   A group has a middlebox-unique identifier.





<span class="grey">Stiemerling, et al.         Standards Track                    [Page 43]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-44" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


   Policy rule group transactions are declared as 'optional' by their
   respective compliance entry in <a href="#section-3">section 3</a>.  However, they provide some
   functionalities, such as convenience for the agent in sending only
   one request instead of several, that is not available if only
   mandatory transactions are available.

   The Group Lifetime Change (GLC) transaction is equivalent to
   simultaneously performed Policy Rule Lifetime Change (RLC)
   transactions on all members of the group.  The result of a successful
   GLC transaction is that all member policy rules have the same
   lifetime.  As with the RLC transaction, the GLC transaction can be
   used to delete all member policy rules by requesting a lifetime of
   zero.

   The 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 <a href="#section-2.3.12">section 2.3.12</a>).

   The GL and GS transactions are particularly helpful in case of an
   agent fail-over.  The agent taking over the role of a failed one can
   use these transactions to retrieve whichever policies have been
   established by the failed agent.

   Notifications on group events are generated analogously to policy
   rule events.  To notify agents about group events, the Policy Rule
   Group Event Notification (GEN) message type is used.  GEN messages
   contain an agent-unique notification identifier, the policy rule
   group identifier, and the remaining lifetime of the group.

<span class="h4"><a class="selflink" id="section-2.4.2" href="#section-2.4.2">2.4.2</a>.  Group Lifetime Change (GLC)</span>

   transaction-name: group lifetime change

   transaction-type: configuration

   transaction-compliance: optional

   request-parameters:

      - request identifier: An agent-unique identifier for matching
        corresponding request and reply at the agent.




<span class="grey">Stiemerling, et al.         Standards Track                    [Page 44]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-45" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


      - group identifier: A reference to the group for which the
        lifetime is requested to be changed.

      - group lifetime: The new lifetime proposal for the group.

   reply-parameters (success):

      - request identifier: An identifier matching the identifier of the
        request.

      - group lifetime: The group lifetime granted by the middlebox.

   failure reason:

      - transaction not supported
      - agent not authorized for this transaction
      - agent not authorized to change lifetime of this group
      - no such group
      - lifetime cannot be extended

   notification message type: Policy Rule Group Event Notification (GEN)

   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.

      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.,



<span class="grey">Stiemerling, et al.         Standards Track                    [Page 45]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-46" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


         0 &lt;= lt_granted &lt;= 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

   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.

<span class="h4"><a class="selflink" id="section-2.4.3" href="#section-2.4.3">2.4.3</a>.  Group List (GL)</span>

   transaction-name: group list

   transaction-type: monitoring

   transaction-compliance: optional

   request-parameters:

      - request identifier: An agent-unique identifier for matching
        corresponding request and reply at the agent.

   reply-parameters (success):

      - request identifier: An identifier matching the identifier of the
        request.

      - group list: List of all groups that the agent can access.  For
        each listed group, the identifier and the owner are indicated.

   failure reason:

      - transaction not supported
      - agent not authorized for this transaction



<span class="grey">Stiemerling, et al.         Standards Track                    [Page 46]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-47" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


   semantics:

      The agent can use this transaction type to list all groups that it
      can access.  Usually, the agent has this information already, but
      in special cases (for example, after an agent fail-over) or for
      special agents (for example, an administrating agent that can
      access all groups) this transaction can be helpful.

      The middlebox first checks whether the agent is authorized to
      request this transaction.  If the check fails, an appropriate
      failure reply is generated.  Otherwise a list of all groups the
      agent can access is returned indicating the identifier and the
      owner of each group.

      This transaction does not have any effect on the group state.

<span class="h4"><a class="selflink" id="section-2.4.4" href="#section-2.4.4">2.4.4</a>.  Group Status (GS)</span>

   transaction-name: group status

   transaction-type: monitoring

   transaction-compliance: optional

   request-parameters:

      - request identifier: An agent-unique identifier for matching
        corresponding request and reply at the agent.

      - group identifier: A reference to the group for which status
        information is requested.

   reply-parameters (success):

      - request identifier: An identifier matching the identifier of the
        request.

      - group owner: An identifier of the agent owning this policy rule
        group.

      - group lifetime: The remaining lifetime of the group.  This is
        the maximum of the remaining lifetimes of all members' policy
        rules.

      - member list: List of all policy rules that are members of the
        group.  The policy rules are specified by their middlebox-unique
        policy rule identifier.




<span class="grey">Stiemerling, et al.         Standards Track                    [Page 47]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-48" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


   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.

      This transaction does not have any effect on the group state.

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Conformance Statements</span>

   A protocol definition complies with the semantics defined in <a href="#section-2">section</a>
   <a href="#section-2">2</a> if the protocol specification includes all specified transactions
   with all their mandatory parameters.  However, it is not required
   that an actual implementation of a middlebox supports all these
   transactions.  Which transactions are required for compliance is
   different for agent and middlebox.

   This section contains conformance statements for MIDCOM protocol
   implementations related to the semantics.  Conformance is specified
   differently for agents and middleboxes.  These conformance statements
   will probably be extended by a concrete protocol specification.
   However, such an extension is expected to extend the statements below
   in such a way that all of them still hold.

   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





<span class="grey">Stiemerling, et al.         Standards Track                    [Page 48]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-49" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


      - Policy Rule Transactions
          - Policy Reserve Rule (PRR)                  mandatory
          - Policy Enable Rule (PER)                   mandatory
          - Policy Rule Lifetime Change (RLC)          mandatory
          - Policy Rule List  (PRL)                    mandatory
          - Policy Rule Status (PRS)                   mandatory
          - Asynchronous Policy Rule Event (ARE)       mandatory

      - Policy Rule Group Transactions
          - Group Lifetime Change (GLC)                optional
          - Group List (GL)                            optional
          - Group Status (GS)                          optional

<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  General Implementation Conformance</span>

   A compliant implementation of a MIDCOM protocol MUST support all
   mandatory transactions.

   A compliant implementation of a MIDCOM protocol MAY support none,
   one, or more of the following transactions: GLC, GL, GS.

   A compliant implementation MAY extend the protocol semantics by
   further transactions.

   A compliant implementation of a MIDCOM protocol MUST support all
   mandatory parameters of each transaction concerning the information
   contained.  The set of parameters can be redefined per transaction as
   long as the contained information is maintained.

   A compliant implementation of a MIDCOM protocol MAY support the use
   of interface-specific policy rules.  Either both or neither of the
   optional inside and outside interface parameters in PRR, PER, and PRS
   MUST be included if interface-specific policy rules are supported.

   A compliant implementation MAY extend the list of parameters of
   transactions.

   A compliant implementation MAY 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 [<a href="#ref-MDC-REQ" title="&quot;Middlebox Communications (midcom) Protocol Requirements&quot;">MDC-REQ</a>] 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 <a href="#section-2.1.4">section 2.1.4</a>.






<span class="grey">Stiemerling, et al.         Standards Track                    [Page 49]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-50" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  Middlebox Conformance</span>

   A middlebox implementation of a MIDCOM protocol supports a request
   transaction if it is able to receive and process all possible correct
   message instances of the particular request transaction and if it
   generates a correct reply for any correct request it receives.

   A middlebox implementation of a MIDCOM protocol supports an
   asynchronous transaction if it is able to generate the corresponding
   notification message properly.

   A compliant middlebox implementation of a MIDCOM protocol must inform
   the agent about the list of supported transactions within the SE
   transaction.

<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>.  Agent Conformance</span>

   An agent implementation of a MIDCOM protocol supports a request
   transaction if it can generate the corresponding request message
   properly and if it can receive and process all possible correct
   replies to the particular request.

   An agent implementation of a MIDCOM protocol supports an asynchronous
   transaction if it can receive and process all possible correct
   message instances of the particular transaction.

   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.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Transaction Usage Examples</span>

   This section gives two usage examples of the transactions specified
   in <a href="#section-2">section 2</a>.  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) [<a href="./rfc3261" title="&quot;SIP: Session Initiation Protocol&quot;">RFC3261</a>].

<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>.  Exploring Policy Rules and Policy Rule Groups</span>

   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.



<span class="grey">Stiemerling, et al.         Standards Track                    [Page 50]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-51" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


   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.

   All agents will probably start their exploration with the Group List
   (GL) transaction, as shown in Figure 5.  On this request, the
   middlebox returns a list of pairs, each containing an agent
   identifier and a group identifier (GID).  The agent is informed which
   of its own groups and which other agents' groups it may access.

         agent                                     middlebox
          |                      GL                       |
          |**********************************************&gt;|
          |&lt;**********************************************|
          |   (agent1,GID1) (agent1,GID2) (agent2,GID3)   |
          |                                               |
          |                   GS GID2                     |
          |**********************************************&gt;|
          |&lt;**********************************************|
          |    agent1  lifetime  PID1  PID2  PID3  PID4   |
          |                                               |

            Figure 5: Using the GL and the GS Transactions

   In Figure 5, three groups are accessible to the agent, and the agent
   retrieves information about the second group by using the Group
   Status (GS) transaction.  It receives the owner of the group, the
   remaining lifetime, and the list of member policy rules, in this case
   containing four policy rule identifiers (PIDs).

   In 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:




<span class="grey">Stiemerling, et al.         Standards Track                    [Page 51]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-52" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


      - policy rule owner
      - group identifier
      - policy rule action (reserve or enable)
      - protocol type
      - port range
      - direction
      - internal IP address
      - internal port number
      - external address
      - external port number
      - middlebox inside IP address
      - middlebox inside port number
      - middlebox outside IP address
      - middlebox outside port number
      - IP address versions (not printed)
      - middlebox service (not printed)
      - inside and outside interface (optional, not printed)

         agent                                     middlebox
          |                   PRS PID1                    |
          |**********************************************&gt;|
          |&lt;**********************************************|
          |  agent1    GID2    RESERVE    UDP    1   ""   |
          | ANY         ANY         ANY         ANY       |
          | ANY         ANY         IPADR_OUT   PORT_OUT1 |
          |                                               |

          Figure 6: Status Report for an Outside Reservation

   The 'ANY' parameter printed in Figure 6 is used as a placeholder in
   policy rule status replies for policy reserve rules.  The policy rule
   with PID1 is a policy reserve rule for UDP traffic at the outside of
   the middlebox.  Since this is a reserve rule, direction is empty.  As
   there is no internal or external address involved yet, these four
   fields are wildcarded in the reply.  The same holds for the inside
   middlebox address and port number.  The only address information
   given by the reply is the reserved outside IP address of the
   middlebox (IPADR_OUT) and the corresponding port number (PORT_OUT1).
   Note that IPADR_OUT and PORT_OUT1 may not be wildcarded, as the
   reserve action does not support this.

   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



<span class="grey">Stiemerling, et al.         Standards Track                    [Page 52]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-53" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


   the internal address of the final receiver.  During address
   translation, the source IP address and the source port numbers of the
   packets remain unchanged.  This is indicated by the inside address,
   which is identical to the external address.

         agent                                     middlebox
          |                   PRS PID2                    |
          |**********************************************&gt;|
          |&lt;**********************************************|
          |       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

   For traditional NATs, the identity of the inside IP address and port
   number with the external IP address and port number always holds
   (A1=A3 in Figure 3).  For a pure firewall, the outside IP address and
   port number are always identical with the internal IP address and
   port number (A0=A2 in Figure 3).

         agent                                     middlebox
          |                   PRS PID3                    |
          |**********************************************&gt;|
          |&lt;**********************************************|
          |       agent1  GID2  ENABLE  UDP  1  OUT       |
          | IPADR_INT   PORT_INT2   IPADR_EXT   PORT_EXT1 |
          | IPADR_EXT   PORT_EXT1   IPADR_OUT   PORT_OUT3 |
          |                                               |

         Figure 8: Status Report for Enabled Outbound Packets

   Figure 8 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.












<span class="grey">Stiemerling, et al.         Standards Track                    [Page 53]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-54" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


         agent                                     middlebox
          |                   PRS PID4                    |
          |**********************************************&gt;|
          |&lt;**********************************************|
          |       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

   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.

<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>.  Enabling a SIP-Signaled Call</span>

   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       |
               | for domain  ++++
               | example.com |  +
               +-------------+  +
                    ^   ^       +
        Private     |   |       +     Public Network
        Network     |   |       +
      +----------+  |   |  +----+------+         +----------------+
      | SIP User |&lt;-+   +-&gt;| Middlebox |&lt;-------&gt;| SIP User Agent |
      | Agent A  |&lt;#######&gt;|   NAPT    |&lt;#######&gt;| B@example.org  |
      +----------+         +-----------+         +----------------+


      &lt;--&gt; SIP signaling
      &lt;##&gt; RTP traffic
      ++++ MIDCOM protocol

                   Figure 10: Example of a SIP Scenario





<span class="grey">Stiemerling, et al.         Standards Track                    [Page 54]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-55" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


   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.

      - The SIP user agent A, located inside the private network, is
        registered at the B2BUA with its private IP address.

      - 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.

      - The RTP paths are configured, but not the RTP Control Protocol
        (RTCP) paths.

      - The middlebox and the B2BUA share an established MIDCOM session.

      - Some parameters are omitted, such as the request identifier
        (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

   The abbreviations of the MIDCOM transactions can be found in the
   particular section headings.

   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:

      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.





<span class="grey">Stiemerling, et al.         Standards Track                    [Page 55]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-56" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


   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.

   User Agent      B2BUA                       Middlebox   User Agent
    A                                             NAPT             B
    |                |                              |              |
    | INVITE         |                              |              |
    | B@example.org  |                              |              |
    | SDP:m=..P_AI.. |                              |              |
    |     c=IP_AI    |                              |              |
    |---------------&gt;|                              |              |
    |                |                              |              |
    |                |  PER PID1 UDP 1 EVEN IN      |              |
    |                |   IP_AI P_AI ANY ANY 300s    |              |
    |                |*****************************&gt;|              |
    |                |&lt;*****************************|              |
    |                |    PER OK GID1 PID1 ANY ANY  |              |
    |                |       IP_AE P_AE1 300s       |              |

             Figure 11: PER with Wildcard Address and Port Number

   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.

   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.

   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.





<span class="grey">Stiemerling, et al.         Standards Track                    [Page 56]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-57" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


   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.

   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|              |
    |                |*****************************&gt;|              |
    |                |&lt;*****************************|              |
    |                | PRR OK PID1 GID1 EMPTY       |              |
    |                |  IP_AE/P_AE 300s             |              |
    |                |                              |              |
    |                | INVITE B@example.org SDP:m=..P_AE.. c=IP_AE |
    |                |--------------------------------------------&gt;|
    |                |&lt;--------------------------------------------|
    |                |       200 OK  SDP:m=..P_B.. c=IP_B          |

           Figure 12: Address Reservation with PRR Transaction

   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.

   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).

   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





<span class="grey">Stiemerling, et al.         Standards Track                    [Page 57]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-58" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


   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.

   User Agent      B2BUA                       Middlebox   User Agent
    A                                             NAPT             B
    |                |                              |              |
    |                |  PER PID1 UDP 1 SAME IN      |              |
    |                |   IP_AI P_AI IP_B ANY 300s   |              |
    |                |*****************************&gt;|              |
    |                |&lt;*****************************|              |
    |                |    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   |              |
    |                |*****************************&gt;|              |
    |                |&lt;*****************************|              |
    |                |   PER OK GID1 PID2 IP_B P_B  |              |
    |                |       IP_AE P_AE2 300s       |              |
    |                |                              |              |
             ...media streams from both directions enabled...
    |                |                              |              |
    |    200 OK      |                              |              |
    |&lt;---------------|                              |              |
    | SDP:m=..P_B..  |                              |              |
    |     c=IP_B     |                              |              |

          Figure 13: Policy Rule Establishment for UDP Flows

   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.













<span class="grey">Stiemerling, et al.         Standards Track                    [Page 58]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-59" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


   User Agent      B2BUA                       Middlebox   User Agent
    A                                             NAPT             B
    |                |                              |              |
    |     BYE        |                     BYE                     |
    |&lt;---------------|&lt;--------------------------------------------|
    |                |                              |              |
    |    200 OK      |                   200 OK                    |
    |---------------&gt;|--------------------------------------------&gt;|
    |                |                              |              |
    |                |         GLC GID1 0s          |              |
    |                |*****************************&gt;|              |
    |                |&lt;*****************************|              |
    |                |         GLC OK 0s            |              |
    |                |                              |              |
       ...both NAT bindings for the media streams are removed...

               Figure 14: Termination of Policy Rule Groups

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Compliance with MIDCOM Requirements</span>

   This section explains the compliance of the specified semantics with
   the MIDCOM requirements.  It is structured according to [<a href="#ref-MDC-REQ" title="&quot;Middlebox Communications (midcom) Protocol Requirements&quot;">MDC-REQ</a>]:

      - Compliance with Protocol Machinery Requirements (<a href="#section-5.1">section 5.1</a>)
      - Compliance with Protocol Semantics Requirements (<a href="#section-5.2">section 5.2</a>)
      - Compliance with Security Requirements (<a href="#section-5.3">section 5.3</a>)

   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 [<a href="#ref-MDC-REQ" title="&quot;Middlebox Communications (midcom) Protocol Requirements&quot;">MDC-REQ</a>].

<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>.  Protocol Machinery Requirements</span>

<span class="h4"><a class="selflink" id="section-5.1.1" href="#section-5.1.1">5.1.1</a>.  Authorized Association</span>

   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 <a href="#section-2.2.1">section 2.2.1</a>.  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.









<span class="grey">Stiemerling, et al.         Standards Track                    [Page 59]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-60" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


<span class="h4"><a class="selflink" id="section-5.1.2" href="#section-5.1.2">5.1.2</a>.  Agent Connects to Multiple Middleboxes</span>

   As specified in <a href="#section-2.2">section 2.2</a>, 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.

<span class="h4"><a class="selflink" id="section-5.1.3" href="#section-5.1.3">5.1.3</a>.  Multiple Agents Connect to Same Middlebox</span>

   As specified in <a href="#section-2.2">section 2.2</a>, 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.

<span class="h4"><a class="selflink" id="section-5.1.4" href="#section-5.1.4">5.1.4</a>.  Deterministic Behavior</span>

   <a href="#section-2.1.2">Section 2.1.2</a> 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.

   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.

<span class="h4"><a class="selflink" id="section-5.1.5" href="#section-5.1.5">5.1.5</a>.  Known and Stable State</span>

   <a href="#section-2.1">Section 2.1</a> 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.  <a href="#section-2.1">Section 2.1</a> clearly demands that intermediate states are not
   stable and are not reported to any agent.

   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.



<span class="grey">Stiemerling, et al.         Standards Track                    [Page 60]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-61" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


   Furthermore, the Group List transaction (<a href="#section-2.4.3">section 2.4.3</a>), the Group
   Status transaction (<a href="#section-2.4.4">section 2.4.4</a>), the Policy Rule List transaction
   (<a href="#section-2.3.11">section 2.3.11</a>), and the Policy Rule Status transaction (<a href="#section-2.3.12">section</a>
   <a href="#section-2.3.12">2.3.12</a>) allow the agent at any time during a session to retrieve
   information about

      - 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.

<span class="h4"><a class="selflink" id="section-5.1.6" href="#section-5.1.6">5.1.6</a>.  Status Report</span>

   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.

<span class="h4"><a class="selflink" id="section-5.1.7" href="#section-5.1.7">5.1.7</a>.  Unsolicited Messages (Asynchronous Notifications)</span>

   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 <a href="#section-2.1.2">section</a>
   <a href="#section-2.1.2">2.1.2</a>).  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.

<span class="h4"><a class="selflink" id="section-5.1.8" href="#section-5.1.8">5.1.8</a>.  Mutual Authentication</span>

   As specified in <a href="#section-2.2.1">section 2.2.1</a>, 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.

<span class="h4"><a class="selflink" id="section-5.1.9" href="#section-5.1.9">5.1.9</a>.  Session Termination by Any Party</span>

   The semantics specification states in <a href="#section-2.2.2">section 2.2.2</a> that the agent
   may request session termination by generating the Session Termination
   request and that the middlebox may not reject this request.  In turn,
   <a href="#section-2.2.3">section 2.2.3</a> states that the middlebox may send the Asynchronous




<span class="grey">Stiemerling, et al.         Standards Track                    [Page 61]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-62" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


   Session Termination notification at any time and then terminate the
   session.  Thus, requirement 2.1.9 is met.

<span class="h4"><a class="selflink" id="section-5.1.10" href="#section-5.1.10">5.1.10</a>.  Request Result</span>

   <a href="#section-2.1">Section 2.1</a> 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.

<span class="h4"><a class="selflink" id="section-5.1.11" href="#section-5.1.11">5.1.11</a>.  Version Interworking</span>

   <a href="#section-2.2.1">Section 2.2.1</a> 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.

<span class="h4"><a class="selflink" id="section-5.1.12" href="#section-5.1.12">5.1.12</a>.  Deterministic Handling of Overlapping Rules</span>

   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 <a href="#section-2.3.2">section 2.3.2</a> (assuming the required
   authorization is given).

   For NATs, reserve and enable may conflict.  If a conflicting request
   arrives, it is rejected, as stated in <a href="#section-2.3.2">section 2.3.2</a>.  If an
   overlapping request arrives that does not conflict with those it
   overlaps, it is accepted (assuming the required authorization is
   given).

   Therefore, the behavior of the middlebox in the presence of
   overlapping rules can be predicted deterministically, and requirement
   2.1.12 is met.

<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>.  Protocol Semantics Requirements</span>

<span class="h4"><a class="selflink" id="section-5.2.1" href="#section-5.2.1">5.2.1</a>.  Extensible Syntax and Semantics</span>

   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.







<span class="grey">Stiemerling, et al.         Standards Track                    [Page 62]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-63" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


<span class="h4"><a class="selflink" id="section-5.2.2" href="#section-5.2.2">5.2.2</a>.  Policy Rules for Different Types of Middleboxes</span>

   <a href="#section-2.3">Section 2.3</a> 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.

<span class="h4"><a class="selflink" id="section-5.2.3" href="#section-5.2.3">5.2.3</a>.  Ruleset Groups</span>

   The semantics explicitly supports grouping of policy rules and
   transactions on policy rule groups, as described in <a href="#section-2.4">section 2.4</a>.  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.

<span class="h4"><a class="selflink" id="section-5.2.4" href="#section-5.2.4">5.2.4</a>.  Policy Rule Lifetime Extension</span>

   The semantics includes a transaction for explicit lifetime extension
   of policy rules, as described in <a href="#section-2.3.3">section 2.3.3</a>.  Thus, requirement
   2.2.4 is met.

<span class="h4"><a class="selflink" id="section-5.2.5" href="#section-5.2.5">5.2.5</a>.  Robust Failure Modes</span>

   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.

<span class="h4"><a class="selflink" id="section-5.2.6" href="#section-5.2.6">5.2.6</a>.  Failure Reasons</span>

   The semantics includes a failure reason parameter in each failure
   reply.  Thus, requirement 2.2.6 is met.

<span class="h4"><a class="selflink" id="section-5.2.7" href="#section-5.2.7">5.2.7</a>.  Multiple Agents Manipulating Same Policy Rule</span>

   As specified in sections <a href="#section-2.3">2.3</a> and <a href="#section-2.4">2.4</a>, 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.

   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.



<span class="grey">Stiemerling, et al.         Standards Track                    [Page 63]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-64" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


<span class="h4"><a class="selflink" id="section-5.2.8" href="#section-5.2.8">5.2.8</a>.  Carrying Filtering Rules</span>

   The Policy Enable Rule transaction specified in <a href="#section-2.3.8">section 2.3.8</a> can
   carry 5-tuple filtering rules.  This meets requirement 2.2.8.

<span class="h4"><a class="selflink" id="section-5.2.9" href="#section-5.2.9">5.2.9</a>.  Parity of Port Numbers</span>

   As specified in <a href="#section-2.3.6">section 2.3.6</a>, the agent is able to request keeping
   the port parity when reserving port numbers with the PRR transaction
   (see <a href="#section-2.3.8">section 2.3.8</a>) and when establishing address bindings with the
   PER transaction (see <a href="#section-2.3.9">section 2.3.9</a>).  Thus, requirement 2.2.9 is met.

<span class="h4"><a class="selflink" id="section-5.2.10" href="#section-5.2.10">5.2.10</a>.  Consecutive Range of Port Numbers</span>

   As specified in <a href="#section-2.3.6">section 2.3.6</a>, the agent is able to request a
   consecutive range of port numbers when reserving port numbers with
   the PRR transaction (see <a href="#section-2.3.8">section 2.3.8</a>) and when establishing address
   bindings or pinholes with the PER transaction (see <a href="#section-2.3.9">section 2.3.9</a>).
   Thus, requirement 2.2.10 is met.

<span class="h4"><a class="selflink" id="section-5.2.11" href="#section-5.2.11">5.2.11</a>.  Contradicting Overlapping Policy Rules</span>

   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.

<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>.  Security Requirements</span>

<span class="h4"><a class="selflink" id="section-5.3.1" href="#section-5.3.1">5.3.1</a>.  Authentication, Confidentiality, Integrity</span>

   The semantics definition supports mutual authentication of agent and
   middlebox in the Session Establishment transaction (<a href="#section-2.2.1">section 2.2.1</a>).
   The use of an underlying protocol such as TLS or IPsec is mandatory.
   Thus, requirement 2.3.1 is met.

<span class="h4"><a class="selflink" id="section-5.3.2" href="#section-5.3.2">5.3.2</a>.  Optional Confidentiality of Control Messages</span>

   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.








<span class="grey">Stiemerling, et al.         Standards Track                    [Page 64]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-65" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


<span class="h4"><a class="selflink" id="section-5.3.3" href="#section-5.3.3">5.3.3</a>.  Operation across Untrusted Domains</span>

   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.

<span class="h4"><a class="selflink" id="section-5.3.4" href="#section-5.3.4">5.3.4</a>.  Mitigate Replay Attacks</span>

   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.

   Further mitigation can be provided as part of a concrete MIDCOM
   protocol definition -- for example, by requiring consecutively
   increasing numbers for request identifiers.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Security Considerations</span>

   The interaction between a middlebox and an agent (see [<a href="#ref-MDC-FRM" title="&quot;Middlebox communication architecture and framework&quot;">MDC-FRM</a>]) 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

      - 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 <a href="#section-2.2.1">section 2.2.1</a>).  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.

   For the TLS and IPsec use, both sides must use securely configured
   credentials for authentication and authorization.

   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.



<span class="grey">Stiemerling, et al.         Standards Track                    [Page 65]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-66" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


   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.

   The example described in <a href="#section-4.2">section 4.2</a> 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 <a href="./rfc3398#section-5.5">section&nbsp;5.5 of
   [RFC3398]</a>).  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.

   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.

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  IAB Considerations on UNSAF</span>

   UNilateral Self-Address Fixing (UNSAF) is described in [<a href="./rfc3424" title="&quot;IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation&quot;">RFC3424</a>] 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) [<a href="./rfc3489" title="&quot;STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)&quot;">RFC3489</a>], are considered as a general class of
   workarounds for NAT traversal and as solutions for scenarios with no
   middlebox communication (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.

   Therefore, this document addresses the UNSAF considerations in
   [<a href="./rfc3424" title="&quot;IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation&quot;">RFC3424</a>] by proposing a long-term alternative solution.

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  Acknowledgements</span>

   We would like to thank all the people contributing to the semantics
   discussion on the mailing list for a lot of valuable comments.






<span class="grey">Stiemerling, et al.         Standards Track                    [Page 66]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-67" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.  References</span>

<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>.  Normative References</span>

   [<a id="ref-RFC2119">RFC2119</a>]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.

<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>.  Informative References</span>

   [<a id="ref-MDC-FRM">MDC-FRM</a>]   Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A.,
               and A. Rayhan, "Middlebox communication architecture and
               framework", <a href="./rfc3303">RFC 3303</a>, August 2002.

   [<a id="ref-MDC-REQ">MDC-REQ</a>]   Swale, R., Mart, P., Sijben, P., Brim, S., and M. Shore,
               "Middlebox Communications (midcom) Protocol
               Requirements", <a href="./rfc3304">RFC 3304</a>, August 2002.

   [<a id="ref-MDC-SEM">MDC-SEM</a>]   Stiemerling, M., Quittek, J., and T. Taylor, "Middlebox
               Communications (MIDCOM) Protocol Semantics", <a href="./rfc3989">RFC 3989</a>,
               February 2005.

   [<a id="ref-NAT-TERM">NAT-TERM</a>]  Srisuresh, P. and M. Holdrege, "IP Network Address
               Translator (NAT) Terminology and Considerations", <a href="./rfc2663">RFC</a>
               <a href="./rfc2663">2663</a>, August 1999.

   [<a id="ref-NAT-TRAD">NAT-TRAD</a>]  Srisuresh, P. and K. Egevang, "Traditional IP Network
               Address Translator (Traditional NAT)", <a href="./rfc3022">RFC 3022</a>, January
               2001.

   [<a id="ref-RFC4346">RFC4346</a>]   Dierks, T. and E. Rescorla, "The Transport Layer Security
               (TLS) Protocol Version 1.1", <a href="./rfc4346">RFC 4346</a>, April 2006.

   [<a id="ref-RFC4302">RFC4302</a>]   Kent, S., "IP Authentication Header", <a href="./rfc4302">RFC 4302</a>, December
               2005.

   [<a id="ref-RFC4303">RFC4303</a>]   Kent, S., "IP Encapsulating Security Payload (ESP)", <a href="./rfc4303">RFC</a>
               <a href="./rfc4303">4303</a>, December 2005.

   [<a id="ref-RFC3198">RFC3198</a>]   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", <a href="./rfc3198">RFC 3198</a>, November 2001.

   [<a id="ref-RFC3261">RFC3261</a>]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
               A., Peterson, J., Sparks, R., Handley, M., and E.
               Schooler, "SIP:  Session Initiation Protocol", <a href="./rfc3261">RFC 3261</a>,
               June 2002.




<span class="grey">Stiemerling, et al.         Standards Track                    [Page 67]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-68" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


   [<a id="ref-RFC3398">RFC3398</a>]   Camarillo, G., Roach, A., Peterson, J., and L. Ong,
               "Integrated Services Digital Network (ISDN) User Part
               (ISUP) to Session Initiation Protocol (SIP) Mapping", <a href="./rfc3398">RFC</a>
               <a href="./rfc3398">3398</a>, December 2002.

   [<a id="ref-RFC3424">RFC3424</a>]   Daigle, L. and IAB, "IAB Considerations for UNilateral
               Self-Address Fixing (UNSAF) Across Network Address
               Translation", <a href="./rfc3424">RFC 3424</a>, November 2002.

   [<a id="ref-RFC3489">RFC3489</a>]   Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
               "STUN - Simple Traversal of User Datagram Protocol (UDP)
               Through Network Address Translators (NATs)", <a href="./rfc3489">RFC 3489</a>,
               March 2003.






































<span class="grey">Stiemerling, et al.         Standards Track                    [Page 68]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-69" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>.  Changes from <a href="./rfc3989">RFC 3989</a></span>

   1. The example in <a href="#section-4.2">section 4.2</a> used a SIP proxy server modifying the
      body of a SIP message.  This was a violation of <a href="./rfc3261">RFC 3261</a>.  This
      has been fixed by replacing the SIP proxy server with a back-to-
      back user agent.

   2. Clarifications concerning the used set of transaction types have
      been added.

   3. <a href="#section-3.1">Section 3.1</a>, "General Implementation Conformance", now uses key
      words from <a href="./rfc2119">RFC 2119</a>.

   4. Minor editorial changes have been made and references have been
      updated.

Authors' Addresses

   Martin Stiemerling
   NEC Europe Ltd.
   Kurfuersten-Anlage 36
   69115 Heidelberg
   Germany

   Phone: +49 6221 4342-113
   EMail: stiemerling@nw.neclab.eu


   Juergen Quittek
   NEC Europe Ltd.
   Kurfuersten-Anlage 36
   69115 Heidelberg
   Germany

   Phone: +49 6221 4342-115
   EMail: quittek@nw.neclab.eu


   Tom Taylor
   Nortel
   1852 Lorraine Ave.
   Ottawa, Ontario
   Canada  K1H 6Z8

   Phone: +1 613 763 1496
   EMail: tom.taylor@rogers.com





<span class="grey">Stiemerling, et al.         Standards Track                    [Page 69]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-70" ></span>
<span class="grey"><a href="./rfc5189">RFC 5189</a>               MIDCOM Protocol Semantics              March 2008</span>


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
   retain all their rights.

   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.

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 <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.

   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
   <a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.

   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.












Stiemerling, et al.         Standards Track                    [Page 70]
</pre>