[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-taylor-midcom-semantics) 00 01 02 03 04 05 06 07 08 RFC 3989

Internet Draft                                            M. Stiemerling
Document: draft-ietf-midcom-semantics-00.txt                  J. Quittek
Expires: April 2003                                      NEC Europe Ltd.
                                                              Tom Taylor
                                                         Nortel Networks

                                                            October 2002



                       MIDCOM Protocol Semantics

                  <draft-ietf-midcom-semantics-00.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.  Internet-Drafts are
   working documents of the Internet Engineering Task Force (IETF), its
   areas, and its working groups.  Note that other groups may also
   distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   Distribution of this document is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.


Abstract

   This memo specifies semantics for a Middlebox Communication (MIDCOM)
   protocol to be used by MIDCOM agents for interacting with
   middleboxes, such as firewalls and 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 a superset of it.  The MIDCOM
   protocol semantics is derived from the MIDCOM requirements, from the
   MIDCOM framework, and from working group decisions.


Stiemerling, Quittek, Taylor                                    [Page 1]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


Table of Contents

   1 Introduction .................................................    3
   1.1 Terminology ................................................    4
   1.2 Transaction Definition Template ............................    5
   2 Semantics Specification ......................................    7
   2.1 General Protocol Design ....................................    7
   2.1.1 Session, Policy Rule, and Policy Rule Group ..............    7
   2.1.2 Atomicity ................................................    8
   2.1.3 Access Control ...........................................    8
   2.1.4 Conformance ..............................................    9
   2.2 Session Control Transactions ...............................    9
   2.2.1 Session Establishment (SE) ...............................    9
   2.2.2 Session Termination (ST) .................................   12
   2.2.3 Asynchronous Session Termination (AST) ...................   13
   2.2.4 Session Termination by Interruption of Connection ........   13
   2.2.5 Session State Machine ....................................   13
   2.3 Policy Rule Group Transactions .............................   14
   2.3.1 Group Establishment (GE) .................................   15
   2.3.2 Group Lifetime Change (GLC) ..............................   16
   2.3.3 Group List (GL) ..........................................   18
   2.3.4 Group Status (GS) ........................................   19
   2.3.5 Asynchronous Group Deletion (AGD) ........................   20
   2.3.6 Group State Machine ......................................   21
   2.4 Policy Rule Transactions ...................................   22
   2.4.1 Policy Reserve Rule (PRR) ................................   23
   2.4.2 Policy Enable Rule (PER) .................................   26
   2.4.3 Policy Rule Lifetime Change (RLC) ........................   31
   2.4.4 Policy Rule Status (PRS) .................................   33
   2.4.5 Asynchronous Policy Rule Deletion (ARD) ..................   36
   2.4.6 Policy Rule State Machine ................................   36
   3 Conformance Statements .......................................   38
   3.1 General Implementation Conformance .........................   38
   3.2 Middlebox Conformance ......................................   39
   3.3 Agent Conformance ..........................................   39
   4 Transaction Usage Examples ...................................   39
   4.1 Exploring Policy Rules and Policy Rule Groups ..............   39
   4.2 Enabling a SIP-Signaled Call ...............................   43
   5 Compliance with MIDCOM Requirements ..........................   47
   5.1 Protocol Machinery Requirements ............................   47
   5.1.1 Authorized Association ...................................   47
   5.1.2 Agent connects to Multiple Middleboxes ...................   47
   5.1.3 Multiple Agents connect to same Middlebox ................   48
   5.1.4 Deterministic Behavior ...................................   48
   5.1.5 Known and Stable State ...................................   48
   5.1.6 Status Report ............................................   49
   5.1.7 Unsolicited Messages (Asynchronous Notifications) ........   49
   5.1.8 Mutual Authentication ....................................   49
   5.1.9 Session Termination by any Party .........................   49
   5.1.10 Request Result ..........................................   49


Stiemerling, Quittek, Taylor                                    [Page 2]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


   5.1.11 Version Interworking ....................................   50
   5.1.12 Deterministic Handling of Overlapping Rules .............   50
   5.2 Protocol Semantics Requirements ............................   50
   5.2.1 Extensible Syntax and Semantics ..........................   50
   5.2.2 Policy Rules for Different Types of Middleboxes ..........   50
   5.2.3 Ruleset Groups ...........................................   50
   5.2.4 Policy Rule Lifetime Extension ...........................   51
   5.2.5 Robust Failure Modes .....................................   51
   5.2.6 Failure Reasons ..........................................   51
   5.2.7 Multiple Agents Manipulating Same Policy Rule ............   51
   5.2.8 Carrying Filtering Rules .................................   51
   5.2.9 Parity of Port Numbers ...................................   51
   5.2.10 Consecutive Range of Port Numbers .......................   51
   5.2.11 Contradicting Overlapping Policy Rules ..................   52
   5.3 Security Requirements ......................................   52
   5.3.1 Authentication, Confidentiality, Integrity ...............   52
   5.3.2 Optional Confidentiality of Control Messages .............   52
   5.3.3 Operation across Un-trusted Domains ......................   52
   5.3.4 Mitigate Replay Attacks ..................................   52
   6 Security Considerations ......................................   52
   7 Acknowledgements .............................................   53
   8 Open Issues ..................................................   53
   9 References ...................................................   54
   10 Authors' Addresses ..........................................   54
   11 Full Copyright Statement ....................................   55


1.  Introduction

   The MIDCOM working group has defined a framework [MDC-FRM] for the
   middle box communication as well as a list of requirements [MDC-REQ].
   But for specifying a concrete protocol, the clear semantics need to
   be defined. The documents mentioned above are not completely
   sufficient for this purpose.  Some required capabilities are not
   mentioned explicitly in the framework or requirements document, but
   are inherent to the problem.

   This memo suggests a semantics for the MIDCOM protocol.  It is fully
   compliant with the requirements listed in [MDC-REQ] and with the
   working group's consensus on semantic issues.

   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 are defined in terms of transactions. Two basic types
   of transactions are used: request-reply transactions and notification
   transactions. For each transaction the semantics is specified by
   describing (1) the parameters of the transaction, (2) the processing


Stiemerling, Quittek, Taylor                                    [Page 3]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


   (of request transactions) at the middlebox, and (3) the state
   transitions at the middlebox caused by the transactions.

   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.  Regardless of such extensions, the semantics below
   provide the minimum necessary subset of what must be implemented.

   The document contains four major sections. Section 2 describes the
   protocol semantics. It is structured in four subsections:

      - General Protocol Issues (Section 2.1)
      - Session Control (Section 2.2)
      - Policy Rule Groups (Section 2.3)
      - Policy Rules (Section 2.4)

   Section 3 contains conformance statements for MIDCOM protocol
   definitions and MIDCOM protocol implementations with respect to the
   semantics defined in Section 2. Section 4 gives two elaborated usage
   examples. Finally, Section 5 explains how the semantics meets the
   MIDCOM requirements.

1.1.  Terminology

   The terminology in this memo follows the definitions given in the
   framework [MDC-FRM] and requirements [MDC-REQ] document.

   In addition the following terms are used:

   request transaction        A request message transfer from the agent
                              and to the middlebox followed by a reply
                              message transfer from the middlebox to the
                              agent.

   notification transaction   An asynchronous message transfer from the
                              middlebox and to the agent.

   agent unique               An agent unique value is unique in the
                              context of the agent.  This context
                              includes all MIDCOM session 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 session the middlebox
                              participates in. A middlebox unique value


Stiemerling, Quittek, Taylor                                    [Page 4]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


                              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."  [RFC3198].  In
                              the MIDCOM context the condition is a
                              specification of a set of packets to which
                              rules are applied. The set of actions
                              always contain 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, one, or both
                              sides of the middlebox, depending on the
                              latter's 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 flows, and the policy
                              action is enabling these flows through the
                              middlebox.  The descriptor identifies the
                              protocol, the flow direction, the source
                              and destination addresses, optionally with
                              a range of port numbers.  The policy
                              action includes reserving IP addresses and
                              optionally port numbers on neither, one,
                              or both sides of the middlebox, depending
                              on what is required for enabling the
                              described flow.  Furthermore the action
                              includes binding the reserved addresses to
                              the flow and enabling packets belonging to
                              the flow to traverse the middlebox.

1.2.  Transaction Definition Template

   In the following sections semantics of the MIDCOM protocol is
   specified per transaction.  A transaction specification contains the
   following entries.  (Parameter entities are only specified if
   applicable.)



Stiemerling, Quittek, Taylor                                    [Page 5]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


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

   transaction-type
      The transaction type is either 'request' or 'notification'. See
      above for the description of request transaction and notification
      transaction.

   transaction-compliance
      This entry contains either 'mandatory' or 'optional'. For details
      see Section 2.1.4.

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

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

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

   notification parameters
      This entry lists all parameters that are used by the middlebox to
      notify the agent about any asynchronous event. A description for
      each parameter is given.

   semantics
      This entry describes the actual semantics of the transaction.

   As explained in the next section, each request contains a parameter
   identifying the requesting agent, and each reply and each
   notification contains a parameter identifying the middlebox. These
   parameters are not explicitly listed in the description of the
   individual transactions, because they are common to all of them and
   not further referred to in the individual semantics descriptions.
   Also, they are not necessarily passed explicitly as parameters of the
   midcom protocol, but they might be provided by the used underlying
   (secure) transport protocol.








Stiemerling, Quittek, Taylor                                    [Page 6]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


2.  Semantics Specification

2.1.  General Protocol Design

   A major goal of the semantics is finding a good balance between
   proper support of applications that require dynamic configuration of
   middleboxes and simplicity of specification and implementation of the
   protocol.

   The MIDCOM protocol will be subdivided into three phases as specified
   in Section 4 of [MDC-FRM]:
      - session setup phase
      - run-time phase
      - session termination phase

   In all phases two kinds of state transitions may occur at the
   middlebox:  state transitions either are initiated by a request from
   the agent to the middlebox, or they are initiated by some other
   event.  In the first case the middlebox informs the agent by sending
   a reply on the actual state transition, in latter case the middlebox
   sends a notification to the agent.  Requests and replies contain an
   agent unique request identifier that allows the agent to determine to
   which sent request a received reply corresponds.

   To allow both agents and middleboxes to maintain multiple sessions,
   every message contains information identifying its sender.  In the
   actual protocol, this identifying information may be provided by a
   layer below the middlebox control application.  It is not shown
   explicitly in the message descriptions provided below, but should be
   assumed as a semantic requirement.

2.1.1.  Session, Policy Rule, and Policy Rule Group

   An analysis of the requirements showed that three kinds of
   transactions are required: transactions for session control,
   transactions for controlling of policy rules, and transactions for
   controlling 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 one per group
   instead of one per policy rule.

   Requirement analysis also showed that session state, policy rule
   state, and policy rule group state can be separated.  The separation
   simplifies the specification of the semantics as well as a protocol
   implementation. Therefore, the semantics specification is structured
   accordingly and we use three separated state machines to illustrate
   the semantics.  Please note, that state machines of concrete protocol
   designs and implementations will most probably be more complex than
   the state machines presented here.  However, the protocol state
   machines are expected to be a superset of the state machines in this


Stiemerling, Quittek, Taylor                                    [Page 7]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


   document.

2.1.2.  Atomicity

   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 arriving or already queued request. This
   particularly applies when the middlebox concurrently receives
   requests originating in different sessions. However, asynchronous
   notification transactions may interrupt and terminate processing of a
   request at any time.

   All request transactions are atomic from the point of view of the
   agent. 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 close to a minimal set
   that still meets the requirements.  For a real implementation of the
   protocol, it might be required to split some of the transactions
   specified below into two or more transactions of the respective
   protocol.  Reasons for this might be constraints of the particular
   protocol or the desire for more flexibility.  In general this should
   not be a problem. However, it should be considered that this might
   change atomicity of the affected transactions.

2.1.3.  Access Control

   Access to policy rules and policy rule groups is based on ownership.
   When a policy rule or a group is created, a middlebox unique
   identifier is generated for identifying it in further transactions.
   Beyond the identifier, each group has an owner.  The owner is the
   authenticated agent that established the policy rule or group.  The
   middlebox uses the owner attribute of a policy rule or group for
   controlling access to it:  each time an authenticated agent requests
   to modify an existing policy rule or group, the middlebox determines
   the owner of the policy rule or group and checks if the requesting
   agent is authorized to perform transactions on the owning agent's
   policy rules or groups.

   The middlebox may be configured to allow specific authenticated
   agents to access and modify groups with certain specific owners.
   Certainly, a reasonable default configuration would be that each
   agent can access its own groups.  Also, it might be a good idea, to
   have an agent identity configured to act as administrator being
   allowed to modify all policy rules owned by any agent.  Anyway, the
   configuration of authorization is not subject of the MIDCOM protocol
   semantics.


Stiemerling, Quittek, Taylor                                    [Page 8]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


2.1.4.  Conformance

   The MIDCOM requirements in [MDC-REQ] demand certain capabilities of
   the MIDCOM protocol, which are met by the set of transactions
   specified below.  However, an actual implementation of a middlebox
   may support only a subset of these transactions.  Support limitation
   may be different for different authenticated agents.  At session
   establishment, the middlebox informs the authenticated agent by
   capability exchange, which transactions the agent is authorized to
   perform.  Some transactions need to be offered to every authenticated
   agent.

   Each transaction definition below has a conformance entry which
   contains either 'mandatory' or 'optional'.  A mandatory transaction
   needs to be implemented by every middlebox offering MIDCOM service.
   A mandatory request transaction must be offered to each of the
   authenticated agents.  An optional transaction does not necessarily
   need to be implemented by a middlebox.  An implemented optional
   request transaction does not necessarily need to be offered to every
   authenticated agent.  Whether or not 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.

2.2.  Session Control Transactions

   Before any transaction on policy rules or policy rule groups is
   possible, a valid MIDCOM session must be established.  A MIDCOM
   session is an 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.  For
   distinguishing different sessions each party uses local session
   identifiers.

   Session control is supported by three transactions:

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

   The first two are request transactions initiated by the agent, the
   last one is a notification transaction initiated by the middlebox.

2.2.1.  Session Establishment (SE)

   transaction-name: session establishment

   transaction-type: request


Stiemerling, Quittek, Taylor                                    [Page 9]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


   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 authentication 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 to
       authenticate 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.

     - encryption method: an identifier of an encryption method.  Also
       'no encryption' may be specified.

   reply-parameters (success):

     - request identifier:  an identifier matching the identifier
       request.

     - middlebox authentication (ma):  an authentication token to
       authenticate the middlebox to the agent.

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

     - middlebox capabilities: a parameter set describing the
       middlebox's capabilities. The set includes
          - type of the middlebox
            for example: FW, NAT, NATFW, NAPT, NAPTFW, NAT-PT, NAT-PTFW,
            ...)
          - 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
          - policy rule persistency: persistent or not persistent
          - maximum remaining lifetime of a policy rule or policy rule
            group
          - a middlebox unique name of the default policy group for the
            agent (see section 2.3.)


Stiemerling, Quittek, Taylor                                   [Page 10]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


   reply-parameters (failure):

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

     - failure reason: the reason why the session establishment
       transaction failed. The list of possible reasons includes but is
       not restricted to:
          - authentication failed
          - no authorization
          - protocol version of agent and middlebox do not match
          - encryption method not supported
          - 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)              |
                 |-------------------------------------------->|
                 |                                             |
                 | successful reply (with middlebox            |
                 |  authentication ma and agent challenge ac)  |
                 |<--------------------------------------------|
                 |                                             |
                 | session establishment request               |
                 |  (with agent authentication aa)             |
                 |-------------------------------------------->|
                 |                                             |
                 | successful reply                            |
                 |<--------------------------------------------|
                 |                                             |

              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 TLS
      [RFC2246] or IPSEC [RFC2402][RFC2406].

      The middlebox checks with its policy decision point if the
      requesting agent is authorized to open a MIDCOM session.  If not a
      negative reply with 'no authorization' as failure reason is
      generated by the middlebox.  If authentication and authorization


Stiemerling, Quittek, Taylor                                   [Page 11]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


      are successful, the session is established and the agent may start
      with requesting transactions on policy rules and policy rule
      groups.

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

      Editor's note: The list of capabilities to be included needs to be
      further elaborated, taking into account how the agent is expected
      to use this information.

      The agent specifies an encryption method for the session but has
      the option of not using encryption.  The middlebox can accept this
      suggestion or reject it.  In case of rejection, the session
      establishment fails and an appropriate failure reason is indicated
      by the middlebox in the reply message.  Then the agent may try
      session setup again with a different encryption method.

2.2.2.  Session Termination (ST)

   transaction-name: session termination

   transaction-type: request

   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 rule groups and policy rules until their
      lifetime expires or until an event occurs which 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, which it has received while
      it was processing the session termination request, or which it
      receives later.


Stiemerling, Quittek, Taylor                                   [Page 12]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


2.2.3.  Asynchronous Session Termination (AST)

   transaction-name: asynchronous session termination

   transaction-type: notification

   transaction-compliance: mandatory

   notification-parameters:

     - termination reason: The reason why the session is terminated
       without any request from the agent.

   semantics:

      The middlebox may decide at any point in time to terminate a
      MIDCOM session.  Before terminating the actual session the middle
      box generates this notification transaction.  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 rule groups and policy rules until their lifetime expires
      or until an event occurs on which the middlebox terminates them.

2.2.4.  Session Termination by Interruption of Connection

   If a MIDCOM session is based on an underlying network connection,
   then 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 rule groups and policy
   rules is the same as for the Asynchronous Session Termination.

2.2.5.  Session State Machine

   A state machine illustrating the semantics of the session
   transactions is shown in Figure 2.  The used transaction
   abbreviations can be found in the headings of the particular
   transaction section.

   All sessions start in state CLOSED.  A successful SE transaction can
   cause a state transition to state OPEN, if mutual authentication is
   already provided by other means.  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.


Stiemerling, Quittek, Taylor                                   [Page 13]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


                                     mc = middlebox challenge
                  SE/failure         ma = middlebox authentication
                  +-------+          ac = agent challenge
                  |       v          aa = agent authentication
                 +----------+
                 |  CLOSED  |----------------+
                 +----------+                | SE(mc!=0)/
                    |   ^  ^                 |  success(ma,ac)
           SE(mc=0, |   |  | AST             |
            aa=OK)/ |   |  | SE/failure      v
            success |   |  | ST/success +----------+
                    |   |  +------------|  NOAUTH  |
                    |   |               +----------+
                    |   | AST                | SE(mc=0,
                    v   | ST/success         |  aa=OK)/
                 +----------+                |  success
                 |   OPEN   |<---------------+
                 +----------+

                 Figure 2: Session State Machine


2.3.  Policy Rule Group Transactions

   Editor's note: this section may be substantially revised.  See open
   issues, section 8.

   This section describes the semantics for transactions on groups of
   policy rules.  The following transactions are specified:

      - Group Establishment (GE)
      - Group Lifetime Change (GLC)
      - Group List (GL)
      - Group Status (GS)
      - Asynchronous Group Deletion (AGD)

   The first four are request transactions initiated by the agent, the
   last one is a notification transaction initiated by the middlebox.
   The status information transactions (GL and GS) do not have any
   effect on the group state machine.

   Group transactions are redundant in the sense that a transaction on a
   group can be replaced by the corresponding transaction on each member
   of a group (except for the GE transaction).  They can be removed
   easily from the semantics specification without changing the set of
   possible middlebox configurations an agent can request.  Therefore
   all of them are declared as 'optional' by their respective compliance
   entry.

   Before any group request can be processed a valid MIDCOM session must


Stiemerling, Quittek, Taylor                                   [Page 14]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


   have been established.  The establishment of groups is a premise of
   any further policy rule establishment.  However, there is a default
   group which is automatically established by the middlebox for every
   authenticated agent.  This group has unlimited lifetime and cannot be
   controlled by a GE or GLC transaction.  It has to be used by the
   agent if the middlebox does not offer group transactions, but may
   optionally be used by the agent at any time.  It is addressed by a
   fixed group identifier value.

   Each policy rule is member of exactly one group, and membership does
   not change during policy rule lifetime.

   Each group that is not a default group has its individual lifetime.
   If the group lifetime expires, the group and all member policy rules
   will be deleted at the middlebox.  A successful group lifetime change
   (GLC) transaction modifies the remaining lifetime of the group and of
   each policy rule belonging to the group, up to the limit specified by
   the middlebox in its response at session setup.  Also a GLC
   transaction may be used for deleting a group by requesting a lifetime
   of 0.  After a successful GLC transaction, all member policy rules
   have the same lifetime as the group.  Please note that by policy-
   rule-specific transactions, the lifetime of an individual policy rule
   may subsequently be set to values less than the group lifetime, but
   an individual policy rule lifetime may never exceed the group
   lifetime.

   Editor's note: The need for this last constraint was questioned at
   IETF 54.

   The status information transactions GL and GS can be used by the
   agent for exploring the state of the middlebox and for exploring 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 of an individual group and it lists
   all policy rules of this group by their policy rule identifers.  The
   agent can explore the state of the individual policy rules by using
   the policy rule identifiers in a policy rule information transaction
   (see Section 2.4.4).

2.3.1.  Group Establishment (GE)

   transaction-name: group establishment

   transaction-type: request

   transaction-compliance: optional

   request-parameters:



Stiemerling, Quittek, Taylor                                   [Page 15]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


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

     - group lifetime:  a lifetime proposal to the middlebox for the
       requested group.

   reply-parameters (success):

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

     - group identifier:  a middlebox unique group identifier.  It is
       assigned by the middlebox and used as group handle in further
       group transactions and in policy rule transactions adding policy
       rules to the group.

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

   reply-parameters (failure):

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

     - failure reason: the reason why the group establishment was
       rejected.  The list of possible reasons includes but is not
       restricted to:
          - transaction not supported
          - agent not authorized for this transaction
          - lack of resources

   semantics:

      This transaction creates an empty group that initially contains no
      policy rule.  The middlebox generates a middlebox unique
      identifier for the new group and assigns the requesting agent to
      be the group owner.  The remaining lifetime of the group is
      proposed by the agent.  In case of a success reply, the middlebox
      chooses a remaining lifetime value that is greater than zero and
      smaller than or equal to the proposed value.  If the middlebox
      decides not to create a new group, a failure reply is generated
      containing a specification of the reason for failure.

2.3.2.  Group Lifetime Change (GLC)

   transaction-name: group lifetime change

   transaction-type: request

   transaction-compliance: optional


Stiemerling, Quittek, Taylor                                   [Page 16]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


   request-parameters:

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

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

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

   reply-parameters (success):

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

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

   reply-parameters (failure):

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

     - failure reason:  the reason why the lifetime change was rejected.
       The list of possible reasons includes but is not restricted to:
          - transaction not supported
          - agent not authorized for this transaction
          - agent not authorized for changing lifetime of this group
          - no such group
          - this transaction cannot be applied to the default group
          - lifetime cannot be extended

   semantics:

      The agent can use this transaction type to request an extension
      the lifetime of an already established group, to request
      shortening of the life time, or to request group termination which
      includes termination of all member policy rules.  Group
      termination is requested by suggesting a new group lifetime of
      zero.

      The middlebox first checks whether or not the specified group
      exists and whether or not the agent is authorized to access this
      group.  If one of the checks fails, an appropriate failure reply
      is generated.  Also a failure reply is generated if the
      transaction is applied to the agent's default group.  If the
      requested lifetime is longer than the current one, the middlebox
      also checks whether or not the lifetime of the group may be
      extended and generates an appropriate failure message if not.


Stiemerling, Quittek, Taylor                                   [Page 17]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


      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 lifetime of the group. The
      middlebox chooses the lifetime within the interval limited by the
      lifetime of the group at arrival of the request and by the
      suggested lifetime.  The granted remaining lifetime must not
      exceed the maximum lifetime that the middlebox specified at
      session setup together with its other capabilities.

      A changed lifetime is applied to each member of the group.  After
      sending a success reply with a lifetime of zero, the member policy
      rules will be deleted without any further notification to the
      agent, and the middlebox will consider the group and its members
      to be non-existent.  It will not process any further transaction
      on this group or on any of its members.

2.3.3.  Group List (GL)

   transaction-name: group list

   transaction-type: request

   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.

   reply-parameters (failure):

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

     - failure reason:  the reason why the request for listing groups
       was rejected.  The list of possible reasons includes but is not
       restricted to:
          - transaction not supported
          - agent not authorized for this transaction


Stiemerling, Quittek, Taylor                                   [Page 18]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


   semantics:

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

      The middlebox first checks whether or not 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 each group.  The shortest possible list to be replied
      contains just the requesting agent's default group.

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

2.3.4.  Group Status (GS)

   transaction-name: group status

   transaction-type: request

   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.

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

   reply-parameters (failure):


Stiemerling, Quittek, Taylor                                   [Page 19]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


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

     - failure reason:  the reason why the request for a status report
       was rejected.  The list of possible reasons includes but is not
       restricted to:
          - transaction not supported
          - agent not authorized for this transaction
          - no such group
          - agent not authorized for listing 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
      failover) or for special agents (for example an administrating
      agent that can access all groups) this transaction can be helpful.

      The middlebox first checks whether or not the specified group
      exists and whether or not 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. If the list of member
      policy rules is empty, a successful reply is returned containing
      an empty list.

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

2.3.5.  Asynchronous Group Deletion (AGD)

   transaction-name: asynchronous group deletion

   transaction-type: notification

   transaction-compliance: optional

   notification-parameters:

     - group identifier:  a reference to the group that will be deleted.

     - deletion reason:  the reason why the middlebox is deleting the
       group including all member policy rules.

   semantics:

      The middlebox may decide at any point in time to delete a group.
      Particularly, this transaction is triggered by lifetime expiration
      of the group.  Among other events that may cause this transaction
      are changes in the policy decision point.


Stiemerling, Quittek, Taylor                                   [Page 20]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


      If this notification is generated, it is sent to all agents that
      are in an open session with the middlebox and that are authorized
      to access the group.  The notification is sent to the agents when
      the middlebox deletes the group and its member policy rules.  The
      member policy rules will be deleted without any further
      notification to the agents.  After sending the notification, the
      middlebox will consider the group and all its members to be non-
      existent.  It will not process any further transaction on the
      group or on any of its members.

2.3.6.  Group State Machine

   A state machine illustrating the semantics of the transactions on
   groups is shown in Figure 3.  The used transaction abbreviations can
   be found in the headings of the particular transaction section.


                             GE/failure
                             +--------+
                             |        v
                            +----------+
                            |   GID    |
                            |  UNUSED  |
                            +----------+
                               |    ^
                    GE/success |    | GLC(lt=0)/success
                               |    | AGD
                               v    |
                            +----------+
                            |   GID    |
                            |  INUSE   |
                            +----------+
                             |        ^
                             +--------+
                             GLC(lt>0)/
                              success            lt = lifetime
                             GLC/failure

                     Figure 3: Group State Machine


   This state machine exists per group identifier (GID).  Initially, all
   groups except the default group are in state GID UNUSED, which means
   that the group does not exist.  A successful GE transaction causes a
   transition to state GID INUSE.  From there the state returns to GID
   UNUSED with a successful GLC transaction requesting a lifetime of
   zero and with an AGD transaction.  After returning to state GID
   UNUSED, the group identifier is no longer bound to an existing group
   and may be re-used by the middlebox.  The default group is in the
   state GID INUSE from the time the session is established until the


Stiemerling, Quittek, Taylor                                   [Page 21]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


   last member policy rule expires or the session is terminated,
   whichever is later.

2.4.  Policy Rule Transactions

   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 Status (PRS)
      - Asynchronous Policy Rule Deletion (ARD)

   The first four are request transactions initiated by the agent, the
   last one is a notification transaction initiated by the middlebox.
   The status information transaction (PRS) does not have any effect on
   the policy rule state machine.

   Policy Rule transactions PER and RLC constitute the core of the
   MIDCOM protocol.  Both are mandatory. They serve for

      - configuring NAT bindings (PER)
      - configuring firewall pinholes (PER)
      - extending the lifetime of established policy rules (RLC)
      - deleting policy rules (RLC)

   In some cases it is required to know in advance which IP address (and
   port number) would be chosen by NAT in a PER transaction.  This
   information is required before sufficient information for performing
   a complete PER transaction is available (see example in Section 4.2).
   For supporting such cases, the core transactions are extended by the
   Policy Reserve Rule (PRR) transaction serving for

      - reserving addresses and port numbers at NATs (PRR)

   A policy rule contains either a reserve action (established by PRR
   transaction) or an enable action (established by PER transaction).

   The Policy Reserve Rule (PRR) transaction is used to establish an
   address reservation on neither, one, or both sides of the middlebox,
   depending on the latter's 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 installed
   without any reservation, but the state transition of the midcom
   protocol engine is exactly the same as on NATs.


Stiemerling, Quittek, Taylor                                   [Page 22]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


   On a traditional NAT, just an external address is reserved; on a
   twice-NAT, an internal and an external addresses are reserved. In
   both cases the reservation concerns either an IP address 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 has an effect on packet treatment 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.

   On a NAT, the enable action is interpreted as as 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.

   The PRR transaction and the PER transaction are described in more
   detail in Sections 2.4.1. and 2.4.2. below.

   When a policy rule is established, it immediately becomes a member of
   one of the groups the agent may access.  Each policy rule is member
   of exactly one group, and membership does not change during policy
   rule lifetime. If an agent does not need to group policy rules, it
   may just use its default group and create all policy rules as members
   of this group.

   Each policy rule has its individual lifetime.  If the policy rule
   lifetime expires, the policy rule will be deleted at the middlebox.
   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 a RLC transaction may be used for
   deleting a policy rule by requesting a lifetime of 0.  Please note
   that policy rule lifetimes may also be modified by the group lifetime
   change transaction, as described above.

   The agent can explore the status of any policy rule by using the
   Policy Rule Status (PRS) transaction.

2.4.1.  Policy Reserve Rule (PRR)

   transaction-name: policy reserve rule

   transaction-type: request

   transaction-compliance: optional

   request-parameters:

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


Stiemerling, Quittek, Taylor                                   [Page 23]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


     - group identifier:  a reference to the group of which the policy
       reserve rule should be a member.

     - protocol identifier:  identifies the protocol for which a
       reservation is requested.  Examples are 'IPv4', 'IPv6', 'UDPv4',
       'UDPv6', 'TCPv4' and 'TCPv6'.

     - port range:  the number of consecutive port numbers to be
       reserved.  Depending on the protocol identified by the previous
       parameter, this parameter may be irrelevant, may truly refer to
       ports, or may refer to an equivalent concept.

     - port parity:  the requested parity of the first (lowest) port
       number to be reserved. Allowed values of this parameter are
       'odd', 'even', and 'any'.

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

   reply-parameters (success):

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

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

     - 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 4).  For an inbound flow, this will be the
       apparent source address of the packets as forwarded to the
       internal endpoint.  The middlebox reserves and reports an
       internal address only in the case where twice-NAT is in effect.
       Otherwise, the value of this reply parameter indicates that no
       internal reservation was made.

     - reserved inside port number:  The reserved port number at the
       internal side of the middlebox.  In case of a port range greater
       than 1, it is the lowest port number of a consecutive sequence of
       reserved port numbers.  The relevance and meaning of this
       parameter depend on the protocol and on whether or not an inside
       reservation was made.

     - 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 4).  For an outbound flow, this will be the


Stiemerling, Quittek, Taylor                                   [Page 24]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


       apparent source address of the packets as forwarded to the
       external endpoint.  If the middlebox is configured as a pure
       firewall, the value of this reply parameter indicates that no
       external reservation was made.

     - reserved outside port number:  The reserved port number at the
       external side of the middlebox.  In case of a port range greater
       than 1, it is the lowest port number of a consecutive sequence of
       reserved port numbers.  The relevance and meaning of this
       parameter depend on the protocol and on whether or not an outside
       reservation was made.

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

   reply-parameters (failure):

     - an identifier matching the identifier of the request.

     - failure reason:  the reason why the reserve request was rejected.
       The list of possible reasons includes but is not restricted to:
          - agent not authorized for this transaction
          - agent not authorized for adding members to this group
          - no such group
          - lack of IP addresses
          - lack of port numbers
          - lack of resources

   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, one, or both sides of the middlebox as
      required to support the enabling of a flow.  Typically the PRR
      will be used in scenarios where it is required to perform such a
      reservation before sufficient parameters for a complete policy
      enable rule transaction are available.  See section 4.2 for an
      example.

      The middlebox first checks whether or not the specified group
      exists and whether or not the agent is authorized to add members
      to this group.  If one of the checks fails, an appropriate failure
      reply is generated.

      The middlebox then determines how many address (and port)
      reservations are required based on its configuration.  If it
      provides only firewall services, it does not perform any
      reservation and just returns empty values for the reserved insode


Stiemerling, Quittek, Taylor                                   [Page 25]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


      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.

      In case of success, this transaction creates a new policy rule
      that becomes a member of the specified group.  The middlebox
      generates a middlebox unique identifier for the new policy rule.
      The owner of the new policy rule is the owner of the group.  The
      middlebox chooses a lifetime value that is greater than zero and
      smaller than or equal to the minimum of the proposed value and the
      maximum lifetime specified by the middlebox at session setup.

      If the protocol identifier is 'IP', 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 and 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, one,
      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.)

      If the reservation fails because of lack of resources, such as
      available IP addresses, port numbers, or storage for further
      policy rules, then an appropriate failure reply is generated.

2.4.2.  Policy Enable Rule (PER)

   transaction-name: policy enable rule

   transaction-type: request

   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
       enable rule should be a member.  If a policy reserve rule
       identifier (see next parameter) has been provided, this parameter
       is irrelevant.


Stiemerling, Quittek, Taylor                                   [Page 26]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


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

     - protocol identifier:  identifies the protocol for which a
       reservation is requested.  Examples are 'IPv6', 'UDPv4', and
       'TCPv6'.  If a policy reserve rule identifier has been provided,
       this parameter is irrelevant.

     - port range:  the number of consecutive port numbers to be
       reserved.  This parameter may be irrelevant, depending on the
       protocol identifier. If a policy reserve rule identifier has been
       provided, this parameter is irrelevant.

     - port parity:  the requested parity of the port number(s) to be
       mapped.  Allowed values of this parameter are 'same' and 'any'.
       If a policy reserve rule identifier has been provided, this
       parameter is irrelevant.

     - direction of flow: this parameter specifies the direction of
       enabled communication, either 'inbound', 'outbound', or 'bi-
       directional'.

     - internal IP address:  the IP address of the internal
       communication endpoint (A0 in Fig. 4).  The address may be
       wildcarded, for example by carrying a network mask.  Wildcarding
       is not allowed if a non-empty policy reserve rule identifier has
       been supplied (the PRR transaction reserves only one IP address).

     - internal port number:  the port number of the internal
       communication endpoint (A0 in Fig. 4). The port number may be
       wildcarded.  Wildcarding is not allowed if a policy reserve rule
       identifier has been supplied, or if the port range parameter has
       a value greater than 0.  This parameter may be irrelevant,
       depending on the protocol identifier.

     - external IP address:  the IP address of the external
       communication endpoint (A3 in Fig. 4).  The address may be
       wildcarded, for example by carrying a network mask.  Wildcarding
       is not allowed if the middlebox performs twice-NAT and a non-
       empty policy reserve rule identifier has been supplied.

     - external port number:  the port number of the external
       communication endpoint (A3 in Fig. 4). The port number may be
       wildcarded.  Wildcarding is not allowed in the following cases:
       if the middlebox performs twice-NAT and a policy reserve rule
       identifier has been supplied, in other cases where a policy
       reserve rule identifier has been supplied and the port range


Stiemerling, Quittek, Taylor                                   [Page 27]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


       parameter in the original PRR request was greater than 0, or if
       the port range parameter is greater than 0 in this request.  This
       parameter may be irrelevant, depending on the protocol
       identifier.

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

   reply-parameters (success):

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

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

     - inside IP address:  the IP address provided at the inside of the
       middlebox (A1 in Fig. 4).  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 if 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.  If the port range parameter value
       specified in the in the PER request or - if a policy reserve rule
       identifier parameter was supplied - in the respective PRR request
       was greater than zero, that number of ports is bound for each
       individual address.  The address may be wildcarded, for example
       by carrying a network mask.  The semantics of such wildcarding is
       that consecutive inside IP addresses correspond to consecutive
       external endpoint addresses (i.e. inside IP addresses are
       substitutes for external endpoint addresses, whether as
       intermediate sources of incoming packets or as intermediate
       destinations of outgoing ones.) Please note, that in absence of a
       twice-NAT the substitution is trivial, because inside addresses
       are identical to the external endpoint addresses.

     - inside port number:  the internal port number provided at the
       inside of the middlebox (A1 in Fig. 4).  In case of a port range
       greater than 1, it is the lowest port number of a consecutive
       sequence of mapped port numbers. In absence of a twice-NAT, the
       inside port number is identical to the external endpoint port
       number.  In the case of a port range equal to 0, the port number
       may be wildcarded.  The semantics of wildcarding are that
       consecutive inside port numbers correspond to consecutive port


Stiemerling, Quittek, Taylor                                   [Page 28]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


       numbers specified in the external port number parameter.  This
       parameter may be irrelevant, depending on the protocol identifier
       of the PER or the preceding PRR request.

     - outside IP address:  the external IP address provided at the
       outside of the middlebox (A2 in Fig. 4).  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.  The address may be wildcarded, for
       example by carrying a network mask.  By reasoning similar to that
       for inside addresses, consecutive outside IP addresses correspond
       to consecutive internal endpoint addresses.  If the port range
       parameter in the PER or preceding PRR request is greater than
       zero, that number of ports is bound for each individual address.

     - outside port number:  the external port number provided at the
       outside of the NAT (A2 in Fig. 4). In case of a port range
       greater than 1, it is the lowest port number of a consecutive
       sequence of mapped port numbers. In case of a pure firewall, the
       outside port number is identical to the internal endpoint port
       number.  In the case of a port range equal to 0, the port number
       may be wildcarded.  The semantics of wildcarding are that
       consecutive outside port numbers correspond to consecutive port
       numbers specified in the internal port number parameter. This
       parameter may be irrelevant, depending on the protocol identifier
       of the PER or the preceding PRR request.

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

   reply-parameters (failure):

     - an identifier matching the identifier of the request.

     - failure reason:  the reason why the policy enable rule was
       rejected.  The list of possible reasons includes but is not
       restricted to:
          - agent not authorized for this transaction
          - no such group
          - agent not authorized for adding members to this group
          - no such policy reserve rule
          - agent not authorized for replacing 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


Stiemerling, Quittek, Taylor                                   [Page 29]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


   semantics:

      This transactions can be used by an agent for enabling
      communication between an internal endpoint and an external
      endpoint independent of the type of middlebox (NAT, NAPT,
      firewall, NAT-PT, combined devices, ... ) for uni-directional or
      bi-directional traffic.

      The agent sends an enable request specifying the endpoints
      (optionally including wildcards) and the direction of
      communication (inbound, outbound, bi-directional).  The
      communication endpoints are displayed in Figure 4.  They are
      addressed by the address tuples A0 and A3, respectively.  An
      address tuple includes a protocol identifier, an IP address, and
      optionally a port number and a port number range. The middlebox
      replies to the enable request with a pair of communication address
      tuples A1 and A2 to be used by the partners for addressing each
      other.


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

                Policy Enable Rule (PER) Transaction:
                  agent -> middlebox: A0, A3, direction
                  middlebox -> agent: A1, A2 (in case of success)

           Figure 4: Communication endpoints in the PER transaction

      In case of a pure packet filtering firewall, the returned address
      tuples are the same as the ones in the request: A2=A0 and A1=A3.
      Each partner uses the other one's real address.  In case of a
      traditional NAT the internal endpoint may use the real address of
      the external endpoint (A1=A3), but the external endpoint uses an
      address tuple provided by the NAT (A2!=A0).  In case of a twice-
      NAT device, both endpoints uses 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, more than one
      enable action might be required for the firewall configuration,
      because incoming and outgoing packets may use different source-
      destination pairs.

      If the reservation identifier is not empty, then the middlebox


Stiemerling, Quittek, Taylor                                   [Page 30]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


      checks whether or not the reference policy rule exists and whether
      or not the agent is authorized to replace this policy rule. If
      reservation identifier is empty, then the middlebox checks whether
      or not the specified group exists and whether or not the agent is
      authorized to add members to this group.  If a check fails, an
      appropriate failure reply is generated.

      In case of success, this transaction creates a new policy enable
      rule that becomes a member of the specified group.  If a policy
      reserve rule was referenced, then the identifier of the policy
      reserve rule will be used for the new policy enable rule.
      Thereby, the original policy reserve rule will be replaced by the
      new policy enable rule.  Otherwise, the middlebox generates a
      middlebox unique identifier for the new policy rule.  The owner of
      the new policy rule is the owner of the group.  The middlebox
      chooses a lifetime value that is greater than zero and smaller
      than or equal to the proposed value and that is smaller than or
      equal to the maximum lifetime specified at session setup.

      If the protocol identifier is 'IP', 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 in order 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 protocol type, then the reserved IP address is used
      either as inside or as outside IP address (depending on the
      reservation).

      For the protocol identifiers 'UDP', 'TCP' and 'SCTP' the middlebox
      acts analogously to 'IP' with additionally mapping ranges of port
      numbers and 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.  Also it may fail because of a
      conflict with an already established policy rule.  In case of a
      conflict,  the first come first serve mechanism is applied.
      Already 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.

      In each case of failure, an appropriate failure reply is
      generated.

2.4.3.  Policy Rule Lifetime Change (RLC)

   transaction-name: policy rule lifetime change


Stiemerling, Quittek, Taylor                                   [Page 31]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


   transaction-type: request

   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.

   reply-parameters (failure):

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

     - failure reason:  the reason why the lifetime change was rejected.
       The list of possible reasons includes but is not restricted to:
          - agent not authorized for this transaction
          - agent not authorized for changing lifetime of this policy
            rule
          - no such policy rule
          - lifetime cannot be extended

   semantics:

      The agent can use this transaction type to request an extension
      the lifetime of an already established policy rule, to request
      shortening of the life time, or to request policy rule
      termination. Policy rule termination is requested by suggesting a
      new policy rule lifetime of zero.

      The middlebox first checks whether or not the specified policy
      rule exists and whether or not 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 or not


Stiemerling, Quittek, Taylor                                   [Page 32]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


      the lifetime of the policy rule may be extended and generates an
      appropriate failure message if not.

      A failure reply implies that the lifetime of 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 the lifetime within the interval limited by
      the lifetime of the policy rule at arrival of the request and by
      the suggested lifetime.  The granted remaining lifetime must not
      exceed the maximum lifetime that the middlebox specified at
      session setup together with its other capabilities.  It also must
      not exceed the lifetime of the group of which the policy rule is a
      member.

      Editor's comment: the use of group lifetimes as constraints on
      individual policy rule lifetimes was considered to be not
      necessary in IETF 54 discussion.

      After sending a success reply with a lifetime of zero, the
      middlebox will consider the policy rule to be non-existent.  It
      will not process any further transaction on this policy rule.

      Please note, that policy rule lifetime may also be changed by the
      Group Lifetime Change (AGD) transaction if applied to the group of
      which the policy rule is a member.

2.4.4.  Policy Rule Status (PRS)

   transaction-name: policy rule status

   transaction-type: request

   transaction-compliance: optional

   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.



Stiemerling, Quittek, Taylor                                   [Page 33]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


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

     - protocol identifier:  identifies the protocol for which a
       reservation is requested.  Examples are 'IP', 'UDP', and 'TCP'.

     - port range:  the number of consecutive ports numbers.  This
       parameter may be irrelevant, depending on the protocol identifier
       (previous parameter).

     - direction: the direction of the communication enabled by the
       middlebox. The value of this parameter is either 'inbound',
       'outbound', or 'bi-directional'.  It will be empty for a policy
       reserve rule.

     - internal IP address:  the IP address of the internal
       communication endpoint (A0 in Fig. 4).  The address may be
       wildcarded, for example by carrying a network mask.  It will be
       empty for a policy reserve rule.

     - internal port number:  the port number of the internal
       communication endpoint (A0 in Fig. 4). The port number may be
       wildcarded.  This parameter may be irrelevant, depending on the
       protocol identifier (specified above).  It will be empty for a
       policy reserve rule.

     - external IP address:  the IP address of the external
       communication endpoint (A3 in Fig. 4).  The address may be
       wildcarded, for example by carrying a network mask.  It will be
       empty for a policy reserve rule.

     - external port number:  the port number of the external
       communication endpoint (A3 in Fig. 4). The port number may be
       wildcarded.  This parameter may be irrelevant, depending on the
       protocol identifier specified above.  It will be empty for a
       policy reserve rule.

     - inside IP address number:  the internal IP address provided at
       the inside of the NAT (A1 in Fig. 4).  The address may be
       wildcarded, for example by carrying a network mask.  For a policy
       reserve rule, the value of this reply parameter will indicate
       that no internal reservation was made, unless the middlebox is
       configured for twice-NAT, .


Stiemerling, Quittek, Taylor                                   [Page 34]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


     - inside port number:  the internal port number provided at the
       inside of the NAT (A1 in Fig. 4). In case of a port range greater
       than 1, it is the lowest port number of a consecutive sequence of
       mapped port numbers. The port number may be wildcarded.  The
       relevance and meaning of this parameter depend on the protocol
       identifier specified above and on whether or not for a policy
       reserve rule an inside reservation was made.

     - outside IP address number:  the external IP address provided at
       the outside of the NAT (A2 in Fig. 4).  The address may be
       wildcarded, for example by carrying a network mask.

     - outside port number:  the external port number provided at the
       outside of the NAT (A2 in Fig. 4). In case of a port range
       greater than 1, it is the lowest port number of a consecutive
       sequence of mapped port numbers. The port number may be
       wildcarded.  This parameter may be irrelevant, depending on the
       protocol identifier specified above.

     - policy rule lifetime:  the remaining lifetime of the policy rule.

   reply-parameters (failure):

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

     - failure reason:  the reason why the request for a status report
       was rejected.  The list of possible reasons includes but is not
       restricted to:
          - transaction not supported
          - agent not authorized for this transaction
          - no such policy rule
          - agent not authorized for accessing 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 failover) or for
      special agents (for example an administrating agent that can
      access all policy rules) this optional transaction can be helpful.

      The middlebox first checks whether or not the specified policy
      rule exists and whether or not 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.


Stiemerling, Quittek, Taylor                                   [Page 35]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


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

2.4.5.  Asynchronous Policy Rule Deletion (ARD)

   transaction-name: asynchronous policy rule deletion

   transaction-type: notification

   transaction-compliance: mandatory

   notification-parameters:

     - policy rule identifier:  the policy rule that will be deleted.

     - deletion reason:  the reason why the middlebox will delete the
       policy rule.

   semantics:

      The middlebox may decide at any point in time to delete a policy
      rule.  Particularly, this transaction is triggered by lifetime
      expiration of the policy rule.  Among other events that may cause
      this transaction are changes in the policy rule decision point.

      If this notification is generated, it is sent to all agents that
      are 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 deletes the policy rule.  After sending the
      notification, the middlebox will consider the policy rule to be
      non-existent.  It will not process any further transaction on the
      policy rule.

      Please note that asynchronous policy rule termination may also be
      indicated by an Asynchronous Group Deletion (AGD) transaction
      without an individual ARD for each member of the group.

2.4.6.  Policy Rule State Machine

   The state machine for the policy rule transactions is shown in Figure
   5 with all possible state transitions. You'll find the used
   transaction abbreviations in the headings of the particular
   transaction section.








Stiemerling, Quittek, Taylor                                   [Page 36]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


                                         PRR/failure
                                         PER/failure
                                        +-----------+
                                        |           v
                        PRR/success   +-+-------------+
                    +-----------------+  PRID UNUSED  |<-+
          +----+    |                 +---------------+  |
          |    |    |                   ^   |            |
          |    v    v        ARD        |   |            |
          |  +-------------+ PER/failure|   | PER/       | ARD
          |  |   RESERVED  +------------+   | success    | RLC(lt=0)/
          |  +-+----+------+ RLC(lt=0)/     |            |  success
          |    |    |         success       |            |
          +----+    |                       v            |
        RLC(lt>0)/  | PER/success     +---------------+  |
         success    +---------------->|    ENABLED    +--+
        RLC/failure                   +-+-------------+
                                        |           ^
                                        +-----------+
            lt = lifetime               RLC(lt>0)/success
                                        RLC/failure

                  Figure 5: 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 RULE UNUSED, the policy rule identifier is no
   longer bound to an existing policy rule and may be re-used by the
   middlebox.

   A successful PRR transaction causes a transition from the initial
   state PRID UNSUSED to 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 a 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 ARD transaction or by a successful RLC transaction with a lifetime
   parameter of 0.  Additionally, a failed PER transaction causes a
   transition from state RESERVED to PRID UNUSED.

   Please note, transitions initiated by ARD transactions may also be
   initiated by AGD transactions.  Analogously, transitions initiated by
   RLC transactions may also be initiated by GLC transactions.


Stiemerling, Quittek, Taylor                                   [Page 37]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


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 parameters.  However, concrete implementations of the
   protocol may not support some of the optional transactions.  Which
   transactions are required for compliancy 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.  Most probably these
   conformance statements will be extended by a concrete protocol
   specification.  However, such an extension is expected to extend the
   statements below in 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

     - Policy Rule Group Transactions
         - Group Establishment (GE)                optional
         - Group Lifetime Change (GLC)             optional
         - Group List (GL)                         optional
         - Group Status (GS)                       optional
         - Asynchronous Group Deletion (AGD)       optional

     - Policy Rule Transactions
         - Policy Reserve Rule (PRR)               optional
         - Policy Enable Rule (PER)                mandatory
         - Policy Rule Lifetime Change (RLC)       mandatory
         - Policy Rule Status (PRS)                optional
         - Asynchronous Policy Rule Deletion (ARD) mandatory

3.1.  General Implementation Conformance

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

   A compliant implementation of a MIDCOM protocol must support either
   the entire set of the group transactions GE, GLC, and AGD, or none of
   them.

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


Stiemerling, Quittek, Taylor                                   [Page 38]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


3.2.  Middlebox Conformance

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

   A middlebox implementation of a MIDCOM protocol supports a
   notification transaction if it is able to 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.

3.3.  Agent Conformance

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

   An agent implementation of a MIDCOM protocol supports a notification
   transaction if it is able to 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.  First it is shown, how an agent can explore all policy
   rules and policy rule groups, which it may access at a middlebox.
   Then the middlebox configuration for enabling a SIP-signaled call is
   demonstrated.

4.1.  Exploring Policy Rules and Policy Rule Groups

   This example precludes 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
      - the status and properties of all accessible policy rules

   If there is just a single session, there is no need for any of these


Stiemerling, Quittek, Taylor                                   [Page 39]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


   actions, 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 takes over.  Then the
   other one need 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 any policy rule or group created by any other agent
   and modify them.

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


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

               Figure 6: Using the GL and the GS transaction

   In Figure 6 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 the middlebox to be a traditional NAPT. Figure 7
   shows the exploration of the first policy rule.  As reply to a Policy
   Rule Status (PRS) transaction, the middlebox always returns the
   following list of parameters:

      - policy rule owner


Stiemerling, Quittek, Taylor                                   [Page 40]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


      - group identifier
      - policy rule action (reserve or enable)
      - protocol type
      - port range
      - direction
      - internal IP address
      - internal port number
      - external address
      - external port number
      - NAT inside IP address
      - NAT inside port number
      - NAT outside IP address
      - NAT outside port number


            agent                                     middlebox
             |                   PRS PID1                    |
             |**********************************************>|
             |<**********************************************|
             |    agent1    GID2    RESERVE    UDP    1      |
             | ANY         ANY         ANY         ANY       |
             | ANY         ANY         IPADR_OUT   PORT_OUT1 |
             |                                               |

             Figure 7: Status report for an outside reservation

   The policy rule with PID1 is a policy reserve rule for UDP traffic at
   the outside of the middlebox.  Since there is no internal or external
   address involved yet, these four fields are wildcarded in the reply.
   The same holds for the inside NAT address and port number.  The only
   address information given by the reply is the reserved outside IP
   address of the NAT (IPADDR_OUT) and the corresponding port number
   (PORT_OUT1).  Note, that IPADR_OUT and PORT_OUT1 may not be
   wildcarded, because the reserve action does not support this.

   Applying PRS to PID2 (Figure 8) shows that the second policy rule is
   an 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 the ones 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.





Stiemerling, Quittek, Taylor                                   [Page 41]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


            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 8: 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 4).  For a pure firewall, also the outside IP
   address and port number are always identical with the internal IP
   address and port number (A0=A2 in Figure 4).


            agent                                     middlebox
             |                   PRS PID3                    |
             |**********************************************>|
             |<**********************************************|
             |       agent1  GID2  ENABLE  UDP  1  OUT       |
             | IPADR_INT   PORT_INT2   IPADR_EXT   PORT_EXT1 |
             | IPADR_EXT   PORT_EXT1   IPADR_OUT   PORT_OUT3 |
             |                                               |

            Figure 9: Status report for enabled outbound packets

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


            agent                                     middlebox
             |                   PRS PID4                    |
             |**********************************************>|
             |<**********************************************|
             |       agent1  GID2  ENABLE  TCP  1  BI        |
             |  IPADR_INT   PORT_INT3  IPADR_EXT   PORT_EXT2 |
             |  IPADR_EXT   PORT_EXT2  IPADR_OUT   PORT_OUT4 |
             |                                               |

          Figure 10: Status report for bi-directional TCP traffic

   Finally, Figure 10 shows the status report for enabled bi-directional
   TCP traffic. Please note that still A1=A3: For outbound packets, only


Stiemerling, Quittek, Taylor                                   [Page 42]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


   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 NAPT and two user agents communicate with each other via
   the SIP proxy and NAPT as shown in figure 11.


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


          <--> SIP Signalling
          <##> RTP Traffic

                       Figure 11: Example SIP Scenario


   For the below sequence charts we make these assumptions:

     - The NAPT is statically configured to forward SIP signalling 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 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 B@b.de.
       However, the concrete URL of the SIP User Agent B, which user B
       currently uses, is not known.

     - Only the RTP paths are configured, but not the RTCP paths.

     - The middlebox and the SIP server share an already established
       MIDCOM session.


Stiemerling, Quittek, Taylor                                   [Page 43]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


   Furthermore these 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.  Therefore, the user
   agent A sends an INVITE SIP message to the SIP proxy server (see
   Figure 13).  The SDP part of the particular SIP message that is
   relevant for the middlebox configuration is shown in the sequence
   chart as:

       SDP: m=..P_AI..
            c=IP_AI

   where the m tag is the media tag which contains the receiving UDP
   port number and the c tag contains the IP address of the terminal
   receiving the media stream.

   On receiving the SIP INVITE message, the SIP proxy server allocates a
   group for this call with the group establishment (GE) transaction.
   All following policy rules for this call will be bound to this group.

   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. Therefore, the SIP proxy server needs an outside IP
   address and port number at the middlebox (the NAPT) to be available
   for this purpose.  However, since the IP address of user agent B is
   not known yet (it will be sent by user agent B in the reply message),
   the proxy server cannot just request an address binding.  Instead it
   just reserves an outside IP address and port number with the policy
   reserve rule (PRR).

   The PRR reply delivers the reserved IP address and port number. Now
   the SIP proxy server replaces in the SDP payload of the INVITE
   message the IP address and port number of user agent A by the
   reserved address and port (see Figure 12).  Then 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.



Stiemerling, Quittek, Taylor                                   [Page 44]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


   User Agent       SIP                        Middlebox   User Agent
    A              Proxy                          NAPT             B
    |                |                              |              |
    | INIVTE B@B.DE  |                              |              |
    | SDP:m=..P_AI.. |                              |              |
    |     c=IP_AI    |                              |              |
    |--------------->|           GE 600s            |              |
    |                |*****************************>|              |
    |                |<*****************************|              |
    |                |      GE OK GID 600s          |              |
    |                |                              |              |
    |                |   PRR GID UDP 1 EVEN 300s    |              |
    |                |*****************************>|              |
    |                |<*****************************|              |
    |                | PRR OK PID1 IP_MB/P_AE 300s  |              |
    |                |                              |              |
    |                | INVITE B@B.DE   SDP:m=..P_AE.. c=IP_MB      |
    |                |-------------------------------------------->|
    |                |<--------------------------------------------|
    |                |       200 OK  SDP:m=..P_B.. c=IP_B          |


           Figure 12: Group establishment and rule reservation

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













Stiemerling, Quittek, Taylor                                   [Page 45]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


   User Agent       SIP                        Middlebox   User Agent
    A              Proxy                          NAPT             B
    |                |                              |              |
    |                |  PER GID PID1 UDP 1 EVEN IN  |              |
    |                |   IP_AI P_AI IP_B ANY 300s   |              |
    |                |*****************************>|              |
    |                |<*****************************|              |
    |                |    PER OK PID1 NONE NONE     |              |
    |                |       IP_MB P_AE1 300s       |              |
    |                |                              |              |
            ...media stream from user agent B to A enabled...
    |                |                              |              |
    |                |  PER GID PID2 UDP 1 EVEN OUT |              |
    |                |    IP_AI ANY IP_B P_B 300s   |              |
    |                |*****************************>|              |
    |                |<*****************************|              |
    |                |    PER OK PID2 NONE NONE     |              |
    |                |       IP_MB P_AE2 300s       |              |
    |                |                              |              |
             ...media streams from both directions enabled...
    |                |                              |              |
    |    200 OK      |                              |              |
    |<---------------|                              |              |
    | SDP:m=..P_B..  |                              |              |
    |     c=IP_B     |                              |              |

          Figure 13: Policy rule establishment for UDP flows

   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
   deletes the group afterwards using a group lifetime change (GLC)
   transaction with a requested remaining lifetime of 0 seconds (see
   Figure 14). Deletion of the group includes deleting all member policy
   rules.

















Stiemerling, Quittek, Taylor                                   [Page 46]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


   User Agent       SIP                        Middlebox   User Agent
    A              Proxy                          NAPT             B
    |                |                              |              |
    |     BYE        |                     BYE                     |
    |<---------------|<--------------------------------------------|
    |                |                              |              |
    |    200 OK      |                   200 OK                    |
    |--------------->|-------------------------------------------->|
    |                |                              |              |
    |                |         GLC GID 0s           |              |
    |                |*****************************>|              |
    |                |<*****************************|              |
    |                |         GLC OK 0s            |              |
    |                |                              |              |
       ...both NAT bindings for the media streams are removed...

                Figure 14: Deletion 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 using the section number they are
   defined in: "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 enable 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 make a determination as to whether
   or not the agent will be permitted to request a service.  Thus,
   requirement 2.1.1 is met.

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


Stiemerling, Quittek, Taylor                                   [Page 47]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


   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 processing a request of an agent may not
   be interrupted by any request of the same or another agent.  This
   provides atomicity among request transactions.  This avoids race
   conditions resulting in an unpredictable behavior of the middlebox.

   Anyway, 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, because the administrator can, for example
   at any time modify the authorization of the agent 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.

   Since 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.2 states that request transactions are atomic with
   respect to each other and from the point of view of an agent.  All
   transactions are defined clearly as state transitions that either
   leave the current stable and well defined state and enter a new
   stable and well defined one or that remain in the current stable and
   well defined state.  Section 2.1 clearly demands that intermediate
   states are not stable and 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 request agent unique request identifiers are used
   for this purpose.  Notifications are self-explanatory by their
   definition.

   Furthermore, the Group List transaction (Section 2.3.3), the Group
   Status transaction (Section 2.3.4), and the Policy Rule Status
   transaction (Section 2.4.4) allows the agent at any time during a
   session to retrieve information about


Stiemerling, Quittek, Taylor                                   [Page 48]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


      - all policy rule groups it may access,
      - the status and member policy rules of all accessible groups,
      - 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 the agent can at any time
   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 include asynchronous notifications from the middlebox
   to the agent, including Asynchronous Session Termination (Section
   2.2.3), Asynchronous Group Deletion (Section 2.3.5), and Asynchronous
   Policy Rule Deletion (Section 2.4.5).  These notifications report
   every change of state, that was not explicitly requested by the
   agent.  Thus, requirement 2.1.7 is met by the semantics specified
   above.

5.1.8.  Mutual Authentication

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

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,
   Session 2.2.3 states that the agent 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 of failure.  Thus,
   requirement 2.2.10 is met.




Stiemerling, Quittek, Taylor                                   [Page 49]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


5.1.11.  Version Interworking

   Section 2.2.1 states that the agent need to specify the protocol
   version number which it is going to use during the session.  The
   middlebox may accept this and act according to this protocol version
   or reject the session if it does not support this version.  If the
   session setup gets 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 Sections 2.4.1 and 2.4.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 Sections 2.4.1 and 2.4.2.  If
   an overlapping request arrives that does not conflict with the ones
   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.

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 transaction may be added.

5.2.2.  Policy Rules for Different Types of Middleboxes

   Section 2.4 explains that the semantics use 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.3.  The
   group transactions can be used for lifetime extension and deletion of
   all policy rules being member of the particular group.  Thus,
   requirement 2.2.3 is met.


Stiemerling, Quittek, Taylor                                   [Page 50]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


5.2.4.  Policy Rule Lifetime Extension

   The semantics include a transaction for explicit lifetime extension
   of policy rules, as described in Section 2.4.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 successful or unsuccessful.  All request
   transaction 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 include a failure reason parameter in each failure
   reply. Thus requirement 2.2.6 is met.

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 authorization of access to policy rules and
   groups.

   If the middlebox is sufficiently configurable, its administrator can
   configure it such 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.

5.2.8.  Carrying Filtering Rules

   The Policy Enable Rule transaction specified in Section 2.4.2 can
   carry 5-tuple filtering rules.  It meets requirement 2.2.8.

5.2.9.  Parity of Port Numbers

   As specified in Section 2.4.2, the agent is able to request to keep
   the port Parity.  Thus requirement 2.2.9 is met.

5.2.10.  Consecutive Range of Port Numbers

   The Policy Enable Rule transaction (PER, Section 2.4.2) allows the
   agent to specify a range of consecutive port numbers to be mapped.


Stiemerling, Quittek, Taylor                                   [Page 51]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


   This can be used for mapping a consecutive range of external port
   numbers to consecutive internal ports.  Thus requirement 2.2.10 is
   met.

5.2.11.  Contradicting Overlapping Policy Rules

   requirement 2.2.11 is based on the assumption that contradicting
   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 not
   'disable'/'disallow' action is supported.

5.3.  Security Requirements

5.3.1.  Authentication, Confidentiality, Integrity

   The semantics definition support mutual authentication of agent and
   middlebox and the selection of an encryption method in the Session
   Establishment transaction (Section 2.2.1).  Encryption can be used
   for achieving confidentiality of messages as well as for ensuring
   integrity.  Thus requirement 2.3.1 is met.

5.3.2.  Optional Confidentiality of Control Messages

   The Session Establishment transaction (Section 2.2.1) allows the
   agent to suggest an encryption method (including 'no encryption').
   Thus requirement 2.3.2 is met.

5.3.3.  Operation across Un-trusted Domains

   Operation across un-trusted domains is supported by mutual
   authentication and by encryption.  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 supporting message encryption.  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 is (see [MDC-FRM]) a
   very sensitive point with respect to security. The configuration of
   policy rules from a middlebox external entity appears to be
   contradicting the nature of a middlebox. Therefore, effective means


Stiemerling, Quittek, Taylor                                   [Page 52]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


   have to be used to ensure:
      - mutual authentication between agent and middlebox
      - authorization
      - message integrity
      - message confidentiality

   The semantics define 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 or not. The
   semantics rely on underlying protocols, like TLS or IPSEC, to keep
   the message integrity and confidentiality of the transferred data
   between both entities.


7.  Acknowledgements

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


8.  Open Issues

   Here is the list of open issues and to do issues:

     - Revise group design. Potential modifications include removing
       timers, switching to implicit group creation, removing GE
       transactions, removing default group, removing AGD transaction.

     - Further elaborate the capability information sent from the
       middlebox to the agent at session setup.  What further capability
       information should be sent?

     - Should there be separate parameters for IP protocol version and
       transport protocol in the PRR request?

     - Is there a need to support enabling ICMP, IGMP, RSVP, ...?

     - In case of a failure of the SE transaction because the encryption
       method suggested by the agent is not supported by the middlebox:
       Should the middlebox reply with a list of supported encryption
       methods?

     - Further elaborate section on security considerations.







Stiemerling, Quittek, Taylor                                   [Page 53]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


9.  References

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

[MDC-REQ]   Swale, R.P., Mart, P.A., Sijben, P., Brimm, S., Shore, M.,
            "Middlebox Control (MIDCOM) Protocol Architecture and
            Requirements", RFC 3304, August 2002

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

[RFC3198]   Westerinen, A. et al., "Terminology for Policy-Based
            Management", RFC 3198, November 2001.

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

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

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


10.  Authors' Addresses

     Martin Stiemerling
     NEC Europe Ltd.
     Network Laboratories
     Adenauerplatz 6
     69115 Heidelberg
     Germany

     Phone: +49 6221 90511-13
     Email: stiemerling@ccrle.nec.de


     Juergen Quittek
     NEC Europe Ltd.
     Network Laboratories
     Adenauerplatz 6
     69115 Heidelberg
     Germany

     Phone: +49 6221 90511-15
     EMail: quittek@ccrle.nec.de



Stiemerling, Quittek, Taylor                                   [Page 54]

Internet-Draft         MIDCOM Protocol Semantics            October 2002


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

     Phone: +1 613 736 0961
     Email: taylor@nortelnetworks.com


11.  Full Copyright Statement

   Copyright (C) The Internet Society (2002). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the  purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.














Stiemerling, Quittek, Taylor                                   [Page 55]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/