tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 3989


Middlebox Communications (MIDCOM) Protocol Semantics

Part 3 of 3, p. 48 to 70
Prev RFC Part


prevText      Top      Up      ToC       Page 48 
3.  Conformance Statements

   A protocol definition complies with the semantics defined in section
   2 if the protocol specification includes all specified transactions
   with all their mandatory parameters.  However, concrete
   implementations of the protocol may support only some of the optional
   transactions, not all of them.  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:

Top      Up      ToC       Page 49 
      - Session Control Transactions
          - Session Establishment (SE)                 mandatory
          - Session Termination (ST)                   mandatory
          - Asynchronous Session Termination (AST)     mandatory

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

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

3.1.  General Implementation Conformance

   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 when interface-specific policy rules are supported.

   A compliant implementation may extend the list of parameters of

   A compliant implementation may replace a single transaction by a set
   of more fine-grained transactions.  In such a case, it must be
   ensured that requirement 2.1.4 (deterministic behavior) and
   requirement 2.1.5 (known and stable state) of [MDC-REQ] are still
   met.  When a single transaction is replaced by a set of multiple
   fine-grained transactions, this set must be equivalent to a single

Top      Up      ToC       Page 50 
   transaction.  Furthermore, this set of transactions must further meet
   the atomicity requirement stated in section 2.1.3.

3.2.  Middlebox Conformance

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

   A middlebox implementation of a MIDCOM protocol supports 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

3.3.  Agent Conformance

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

   An agent implementation of a MIDCOM protocol supports 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.

4.  Transaction Usage Examples

   This section gives two usage examples of the transactions specified
   in Section 2.  The first shows how an agent can explore all policy
   rules and policy rule groups that it may access at a middlebox.  The
   second example shows the configuration of a middlebox in combination
   with the setup of a voice over IP session with the Session Initiation
   Protocol (SIP) [RFC3261].

4.1.  Exploring Policy Rules and Policy Rule Groups

   This example assumes an already established session.  It shows how an
   agent can find out

Top      Up      ToC       Page 51 
      - which groups it may access and who owns these groups,
      - the status and member list of all accessible groups, and
      - the status and properties of all accessible policy rules.

   If there is just a single session, these actions are not needed,
   because the middlebox informs the agent about each state transition
   of any policy rule or policy rule group.  However, after the
   disruption of a session or after an intentional session termination,
   the agent might want to re-establish the session and explore which of
   the groups and policy rules it established are still in place.

   Also, an agent system may fail and another one may take over.  Then
   the new agent system needs to find out what has already been
   configured by the failing system and what still needs to be done.

   A third situation where exploring policy rules and groups is useful
   is the case of an agent with 'administrator' authorization.  This
   agent may access and modify any policy rule or group created by any
   other agent.

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

         agent                                     middlebox
          |                      GL                       |
          |   (agent1,GID1) (agent1,GID2) (agent2,GID3)   |
          |                                               |
          |                   GS GID2                     |
          |    agent1  lifetime  PID1  PID2  PID3  PID4   |
          |                                               |

            Figure 5: Using the GL and the GS transaction

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

Top      Up      ToC       Page 52 
   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:

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

         agent                                     middlebox
          |                   PRS PID1                    |
          |  agent1    GID2    RESERVE    UDP    1   ""   |
          | ANY         ANY         ANY         ANY       |
          | ANY         ANY         IPADR_OUT   PORT_OUT1 |
          |                                               |

          Figure 6: Status report for an outside reservation

   The 'ANY' parameter printed in Figure 6 is used as a placeholder in
   policy rules 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 (IPADDR_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.

Top      Up      ToC       Page 53 
   Applying PRS to PID2 (Figure 7) shows that the second policy rule is
   a policy enable rule for inbound UDP packets.  The internal
   destination is fixed concerning IP address, protocol, and port
   number, but for the external source, the port number is wildcarded.
   The outside IP address and port number of the middlebox are what the
   external sender needs to use as destination in the original packet it
   sends.  At the middlebox, the destination address is replaced with
   the internal address of the final receiver.  During address
   translation, the source IP address and the source port numbers of the
   packets remain unchanged.  This is indicated by the inside address,
   which is identical to the external address.

         agent                                     middlebox
          |                   PRS PID2                    |
          |       agent1  GID2  ENABLE  UDP  1  IN        |
          | IPADR_INT   PORT_INT1   IPADR_EXT   ANY       |
          | IPADR_EXT   ANY         IPADR_OUT   PORT_OUT2 |
          |                                               |

         Figure 7: Status report for enabled inbound packets

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

         agent                                     middlebox
          |                   PRS PID3                    |
          |       agent1  GID2  ENABLE  UDP  1  OUT       |
          |                                               |

         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.

Top      Up      ToC       Page 54 
         agent                                     middlebox
          |                   PRS PID4                    |
          |       agent1  GID2  ENABLE  TCP  1  BI        |
          |                                               |

        Figure 9: Status report for bi-directional TCP traffic

   Finally, Figure 9 shows the status report for enabled bi-directional
   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.

4.2.  Enabling a SIP-Signaled Call

   This elaborated transaction usage example shows the interaction
   between a SIP proxy 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 SIP proxy and NAPT,
   as shown in Figure 10.  The MIDCOM agent is co-located with the SIP
   proxy, and the MIDCOM server is at the middlebox.  Thus, the MIDCOM
   protocol runs between the SIP proxy and middlebox.

               | SIP Proxy   |
               | for domain  ++++
               | |  +
               +-------------+  +
                    ^   ^       +
        Private     |   |       +     Public Network
        Network     |   |       +
      +----------+  |   |  +----+------+         +----------------+
      | SIP User |<-+   +->| Middlebox |<------->| SIP User Agent |
      | Agent A  |<#######>|   NAPT    |<#######>|  |
      +----------+         +-----------+         +----------------+

      <--> SIP Signaling
      <##> RTP Traffic
      ++++ MIDCOM protocol

                   Figure 10: Example of a SIP Scenario

Top      Up      ToC       Page 55 
   For the sequence charts below, we make these assumptions:

      - The NAPT is statically configured to forward SIP signaling from
        the outside to the SIP proxy server -- i.e., traffic to the
        NAPT's external IP address and port 5060 is forwarded to the
        internal SIP proxy.

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

      - User A knows the general SIP URL of user B.  The URL is  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 RTCP paths.

      - The middlebox and the SIP server share an established MIDCOM

      - Some parameters are omitted, such as the request identifier

   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 SIP proxy server (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..

   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.

Top      Up      ToC       Page 56 
   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 SIP proxy 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
   enables the 'early media' capability but results in some insecurity,
   as any outside host can reach user agent A on the enabled port number
   through the middlebox.

   User Agent       SIP                        Middlebox   User Agent
    A              Proxy                          NAPT             B
    |                |                              |              |
    | INIVTE         |                              |              |
    |  |                              |              |
    | SDP:m=..P_AI.. |                              |              |
    |     c=IP_AI    |                              |              |
    |--------------->|                              |              |
    |                |                              |              |
    |                |  PER PID1 UDP 1 EVEN IN      |              |
    |                |   IP_AI P_AI ANY ANY 300s    |              |
    |                |*****************************>|              |
    |                |<*****************************|              |
    |                |    PER OK GID1 PID1 ANY ANY  |              |
    |                |       IP_AE P_AE1 300s       |              |

             Figure 11: PER with wildcard address and port number

   A successful PER reply, as shown in Figure 11, results in an 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 SIP proxy server 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 SIP proxy server uses the PRR transaction.

Top      Up      ToC       Page 57 
   By using the PRR request, the SIP proxy 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 SIP proxy server replaces the IP address and port number
   of user agent A with the reserved IP address and port from 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       SIP                        Middlebox   User Agent
    A              Proxy                          NAPT             B
    |                |                              |              |
       ...PER in Figure 11 has failed, continuing with PRR ...
    |                |                              |              |
    |                |PRR tw v4 v4 A UDP 1 EVEN 300s|              |
    |                |*****************************>|              |
    |                |<*****************************|              |
    |                | PRR OK PID1 GID1 EMPTY       |              |
    |                |  IP_AE/P_AE 300s             |              |
    |                |                              |              |
    |                | INVITE SDP:m=..P_AE.. c=IP_AE |
    |                |-------------------------------------------->|
    |                |<--------------------------------------------|
    |                |       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 SIP proxy server 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

Top      Up      ToC       Page 58 
   members of the same group.  After having enabled both UDP/RTP
   streams, the SIP proxy can forward the '200 OK' SIP message to user
   agent A to indicate that the telephone call can start.

   User Agent       SIP                        Middlebox   User Agent
    A              Proxy                          NAPT             B
    |                |                              |              |
    |                |  PER PID1 UDP 1 SAME IN      |              |
    |                |   IP_AI P_AI IP_B ANY 300s   |              |
    |                |*****************************>|              |
    |                |<*****************************|              |
    |                |    PER OK GID1 PID1 IP_B ANY |              |
    |                |       IP_AE P_AE1 300s       |              |
    |                |                              |              |
   stream from user agent B to A enabled...
    |                |                              |              |
    |                |  PER GID1 UDP 1 SAME OUT     |              |
    |                |    IP_AI ANY IP_B P_B 300s   |              |
    |                |*****************************>|              |
    |                |<*****************************|              |
    |                |   PER OK GID1 PID2 IP_B P_B  |              |
    |                |       IP_AE P_AE2 300s       |              |
    |                |                              |              |
    streams from both directions enabled...
    |                |                              |              |
    |    200 OK      |                              |              |
    |<---------------|                              |              |
    | 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 SIP proxy 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.

Top      Up      ToC       Page 59 
   User Agent       SIP                        Middlebox   User Agent
    A              Proxy                          NAPT             B
    |                |                              |              |
    |     BYE        |                     BYE                     |
    |                |                              |              |
    |    200 OK      |                   200 OK                    |
    |                |                              |              |
    |                |         GLC GID1 0s          |              |
    |                |*****************************>|              |
    |                |<*****************************|              |
    |                |         GLC OK 0s            |              |
    |                |                              |              |
       ...both NAT bindings for the media streams are removed...

               Figure 14: Termination of policy rule groups

5.  Compliance with MIDCOM Requirements

   This section explains the compliance of the specified semantics with
   the MIDCOM requirements.  It is structured according to [MDC-REQ]:

      - Compliance with Protocol Machinery Requirements (section 5.1)
      - Compliance with Protocol Semantics Requirements (section 5.2)
      - Compliance with Security Requirements (section 5.3)

   The requirements are referred to with the number of the section in
   which they are defined: "requirement x.y.z" refers to the requirement
   specified in section x.y.z of [MDC-REQ].

5.1.  Protocol Machinery Requirements

5.1.1.  Authorized Association

   The specified semantics enables a MIDCOM agent to establish an
   authorized association between itself and the middlebox.  The agent
   identifies itself by the authentication mechanism of the Session
   Establishment transaction described in section 2.2.1.  Based on this
   authentication, the middlebox can determine whether or not the agent
   will be permitted to request a service.  Thus, requirement 2.1.1 is

Top      Up      ToC       Page 60 
5.1.2.  Agent Connects to Multiple Middleboxes

   As specified in section 2.2, the MIDCOM protocol allows the agent to
   communicate with more than one middlebox simultaneously.  The
   selection of a mechanism for separating different sessions is left to
   the concrete protocol definition.  It must provide a clear mapping of
   protocol messages to open sessions.  Then requirement 2.1.2 is met.

5.1.3.  Multiple Agents Connect to same Middlebox

   As specified in section 2.2, the MIDCOM protocol allows the middlebox
   to communicate with more than one agent simultaneously.  The
   selection of a mechanism for separating different sessions is left to
   the concrete protocol definition.  It must provide a clear mapping of
   protocol messages to open sessions.  Then requirement 2.1.3 is met.

5.1.4.  Deterministic Behavior

   Section 2.1.2 states that the processing of a request of an agent may
   not be interrupted by any request of the same or another agent.  This
   provides atomicity among request transactions and avoids race
   conditions resulting in unpredictable behavior by the middlebox.

   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.

5.1.5.  Known and Stable State

   Section 2.1 states that request transactions are atomic with respect
   to each other and from the point of view of an agent.  All
   transactions are clearly defined as state transitions that either
   leave the current stable, well-defined state and enter a new stable,
   well-defined one or that remain in the current stable, well-defined
   state.  Section 2.1 clearly demands that intermediate states are not
   stable and are not reported to any agent.

   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

Top      Up      ToC       Page 61 
   middlebox, because agent-unique request identifiers are used for this
   purpose.  Notifications are self-explanatory by their definition.

   Furthermore, the Group List transaction (section 2.4.3), the Group
   Status transaction (section 2.4.4), the Policy Rule List transaction
   (section 2.3.11), and the Policy Rule Status transaction (section
   2.3.12) allow the agent at any time during a session to retrieve
   information about

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

5.1.6.  Status Report

   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.

5.1.7.  Unsolicited Messages (Asynchronous Notifications)

   The semantics includes asynchronous notifications messages from the
   middlebox to the agent, including the Session Termination
   Notification message, the Policy Rule Event Notification (REN)
   message, and the Group Event Notification (GEN) message (see section
   2.1.2).  These notifications report every change of state of policy
   rules or policy rule groups that was not explicitly requested by the
   agent.  Thus, requirement 2.1.7 is met by the semantics specified

5.1.8.  Mutual Authentication

   As specified in section 2.2.1, the semantics requires mutual
   authentication of agent and middlebox, by using either two subsequent
   Session Establishment transactions or mutual authentication provided
   on a lower protocol layer.  Thus, requirement 2.1.8 is met.

Top      Up      ToC       Page 62 
5.1.9.  Session Termination by Any Party

   The semantics specification states in section 2.2.2 that the agent
   may request session termination by generating the Session Termination
   request and that the middlebox may not reject this request.  In turn,
   section 2.2.3 states that the middlebox may send the Asynchronous
   Session Termination notification at any time and then terminate the
   session.  Thus, requirement 2.1.9 is met.

5.1.10.  Request Result

   Section 2.1 states that each request of an agent is followed by a
   reply of the middlebox indicating either success or failure.  Thus,
   requirement 2.2.10 is met.

5.1.11.  Version Interworking

   Section 2.2.1 states that the agent needs to specify the protocol
   version number that it will use during the session.  The middlebox
   may accept this and act according to this protocol version or may
   reject the session if it does not support this version.  If the
   session setup is rejected, the agent may try again with another
   version.  Thus, requirement 2.2.11 is met.

5.1.12.  Deterministic Handling of Overlapping Rules

   The only policy rule actions specified are 'reserve' and 'enable'.
   For firewalls, overlapping enable actions or reserve actions do not
   create any conflict, so a firewall will always accept overlapping
   rules as specified in section 2.3.2 (assuming the required
   authorization is given).

   For NATs, reserve and enable may conflict.  If a conflicting request
   arrives, it is rejected, as stated in section 2.3.2.  If an
   overlapping request arrives that does not conflict with those it
   overlaps, it is accepted (assuming the required authorization is

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

Top      Up      ToC       Page 63 
5.2.  Protocol Semantics Requirements

5.2.1.  Extensible Syntax and Semantics

   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.

5.2.2.  Policy Rules for Different Types of Middleboxes

   Section 2.3 explains that the semantics uses identical transactions
   for all middlebox types and that the same policy rule can be applied
   to all of them.  Thus, requirement 2.2.2 is met.

5.2.3.  Ruleset Groups

   The semantics explicitly supports grouping of policy rules and
   transactions on policy rule groups, as described in section 2.4.  The
   group transactions can be used for lifetime extension and termination
   of all policy rules that are members of the particular group.  Thus,
   requirement 2.2.3 is met.

5.2.4.  Policy Rule Lifetime Extension

   The semantics includes a transaction for explicit lifetime extension
   of policy rules, as described in section 2.3.3.  Thus, requirement
   2.2.4 is met.

5.2.5.  Robust Failure Modes

   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.

5.2.6.  Failure Reasons

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

Top      Up      ToC       Page 64 
5.2.7.  Multiple Agents Manipulating Same Policy Rule

   As specified in sections 2.3 and 2.4, each installed policy rule and
   policy rule group has an owner, which is the authenticated agent that
   created the policy rule or group, respectively.  The authenticated
   identity is input to authorize access to policy rules and groups.

   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

5.2.8.  Carrying Filtering Rules

   The Policy Enable Rule transaction specified in section 2.3.8 can
   carry 5-tuple filtering rules.  This meets requirement 2.2.8.

5.2.9.  Parity of Port Numbers

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

5.2.10.  Consecutive Range of Port Numbers

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

5.2.11.  Contradicting Overlapping Policy Rules

   Requirement 2.2.11 is based on the assumption that contradictory
   policy rule actions, such as 'enable'/'allow' and
   'disable'/'disallows' 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.

Top      Up      ToC       Page 65 
5.3.  Security Requirements

5.3.1.  Authentication, Confidentiality, Integrity

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

5.3.2.  Optional Confidentiality of Control Messages

   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.

5.3.3.  Operation across Untrusted Domains

   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.

5.3.4.  Mitigate Replay Attacks

   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.

6.  Security Considerations

   The interaction between a middlebox and an agent (see [MDC-FRM]) is a
   very sensitive point with respect to security.  The configuration of
   policy rules from a middlebox-external entity appears to contradict
   the nature of a middlebox.  Therefore, effective means have to be
   used to ensure

      - mutual authentication between agent and middlebox,
      - authorization,
      - message integrity, and
      - message confidentiality.

   The semantics defines a mechanism to ensure mutual authentication
   between agent and middlebox (see section 2.2.1).  In combination with
   the authentication, the middlebox is able to decide whether an agent
   is authorized to request an action at the middlebox.  The semantics

Top      Up      ToC       Page 66 
   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.

   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 section 4.2 shows how SIP-signaled calls can
   be served in a secure way without wildcarding IP addresses.  But some
   SIP-signaled applications make use of early media (see section 5.5 of
   [RFC3398]).  To receive early media, the middleboxes need to be
   configured before the second participant in a session is known.  As
   it is not known, the IP address of the second participant needs to be

   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

7.  IAB Considerations on UNSAF

   UNilateral Self-Address Fixing (UNSAF) is described in [RFC3424] as a
   process at originating endpoints that attempt to determine or fix the
   address (and port) by which they are known to another endpoint.
   UNSAF proposals, such as STUN [RFC3489] 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

Top      Up      ToC       Page 67 
   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
   [RFC3424] by proposing a long-term alternative solution.

8.  Acknowledgements

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

9.  References

9.1.  Normative References

   [MDC-FRM]   Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A.,
               and A. Rayhan, "Middlebox communication architecture and
               framework", RFC 3303, August 2002.

   [MDC-REQ]   Swale, R., Mart, P., Sijben, P., Brim, S., and M. Shore,
               "Middlebox Communications (midcom) Protocol
               Requirements", RFC 3304, August 2002.

   [NAT-TERM]  Srisuresh, P. and M. Holdrege, "IP Network Address
               Translator (NAT) Terminology and Considerations", RFC
               2663, August 1999.

   [NAT-TRAD]  Srisuresh, P. and K. Egevang, "Traditional IP Network
               Address Translator (Traditional NAT)", RFC 3022, January

9.2.  Informative References

   [RFC2246]   Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
               RFC 2246, January 1999.

   [RFC2402]   Kent, S. and R. Atkinson, "IP Authentication Header", RFC
               2402, November 1998.

   [RFC2406]   Kent, S. and R. Atkinson, "IP Encapsulating Security
               Payload (ESP)", RFC 2406, November 1998.

   [RFC3198]   Westerinen, A., Schnizlein, J., Strassner, J., Scherling,
               M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry,
               J., and S. Waldbusser, "Terminology for Policy-Based
               Management", RFC 3198, November 2001.

Top      Up      ToC       Page 68 
   [RFC3261]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
               A., Peterson, J., Sparks, R., Handley, M., and E.
               Schooler, "SIP:  Session Initiation Protocol", RFC 3261,
               June 2002.

   [RFC3398]   Camarillo, G., Roach, A., Peterson, J., and L. Ong,
               "Integrated Services Digital Network (ISDN) User Part
               (ISUP) to Session Initiation Protocol (SIP) Mapping", RFC
               3398, December 2002.

   [RFC3424]   Daigle, L. and IAB, "IAB Considerations for UNilateral
               Self-Address Fixing (UNSAF) Across Network Address
               Translation", RFC 3424, November 2002.

   [RFC3489]   Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
               "STUN - Simple Traversal of User Datagram Protocol (UDP)
               Through Network Address Translators (NATs)", RFC 3489,
               March 2003.

Top      Up      ToC       Page 69 
Authors' Addresses

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

   Phone: +49 6221 90511-13

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

   Phone: +49 6221 90511-15

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

   Phone: +1 613 763 1496

Top      Up      ToC       Page 70 
Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

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 IETF's procedures with respect to rights in IETF Documents can
   be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   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-


   Funding for the RFC Editor function is currently provided by the
   Internet Society.