tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 3989


Pages: 70
Top     in Index     Prev     Next
 

Middlebox Communications (MIDCOM) Protocol Semantics

Part 1 of 3, p. 1 to 18
None       Next RFC Part

Obsoleted by:    5189


Top       ToC       Page 1 
Network Working Group                                     M. Stiemerling
Request for Comments: 3989                                    J. Quittek
Category: Informational                                              NEC
                                                               T. Taylor
                                                                  Nortel
                                                           February 2005


          Middlebox Communications (MIDCOM) Protocol Semantics

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).

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 Network Address Translators (NATs).  The
   semantics discussion does not include any specification of a concrete
   syntax or a transport protocol.  However, a concrete protocol is
   expected to implement the specified semantics or, more likely, a
   superset of it.  The MIDCOM protocol semantics is derived from the
   MIDCOM requirements, from the MIDCOM framework, and from working
   group decisions.

Table of Contents

   1.  Introduction .................................................  3
       1.1.  Terminology ............................................  4
       1.2.  Transaction Definition Template ........................  6
   2.  Semantics Specification ......................................  7
       2.1.  General Protocol Design ................................  7
             2.1.1.  Protocol Transactions ..........................  8
             2.1.2.  Message Types ..................................  9
             2.1.3.  Session, Policy Rule, and Policy Rule Group ....  9
             2.1.4.  Atomicity ...................................... 10
             2.1.5.  Access Control ................................. 11
             2.1.6.  Middlebox Capabilities ......................... 11
             2.1.7.  Agent and Middlebox Identifiers ................ 12
             2.1.8.  Conformance .................................... 12
       2.2.  Session Control Transactions ........................... 13

Top      ToC       Page 2 
             2.2.1.  Session Establishment (SE) ..................... 13
             2.2.2.  Session Termination (ST) ....................... 15
             2.2.3.  Asynchronous Session Termination (AST) ......... 16
             2.2.4.  Session Termination by Interruption of
                     Connection ..................................... 17
             2.2.5.  Session State Machine .......................... 17
       2.3.  Policy Rule Transactions ............................... 18
             2.3.1.  Configuration Transactions ..................... 19
             2.3.2.  Establishing Policy Rules ...................... 19
             2.3.3.  Maintaining Policy Rules and Policy Rule Groups  20
             2.3.4.  Policy Events and Asynchronous Notifications ... 21
             2.3.5.  Address Tuples ................................. 21
             2.3.6.  Address Parameter Constraints .................. 23
             2.3.7.  Interface-specific Policy Rules ................ 25
             2.3.8.  Policy Reserve Rule (PRR) ...................... 26
             2.3.9.  Policy Enable Rule (PER) ....................... 30
             2.3.10. Policy Rule Lifetime Change (RLC) .............. 36
             2.3.11. Policy Rule List (PRL) ......................... 38
             2.3.12. Policy Rule Status (PRS) ....................... 39
             2.3.13. Asynchronous Policy Rule Event (ARE) ........... 41
             2.3.14. Policy Rule State Machine ...................... 42
       2.4.  Policy Rule Group Transactions ......................... 43
             2.4.1.  Overview ....................................... 43
             2.4.2.  Group Lifetime Change (GLC) .................... 44
             2.4.3.  Group List (GL) ................................ 46
             2.4.4.  Group Status (GS) .............................. 47
   3.  Conformance Statements ....................................... 48
       3.1.  General Implementation Conformance ..................... 49
       3.2.  Middlebox Conformance .................................. 50
       3.3.  Agent Conformance ...................................... 50
   4.  Transaction Usage Examples ................................... 50
       4.1.  Exploring Policy Rules and Policy Rule Groups .......... 50
       4.2.  Enabling a SIP-Signaled Call ........................... 54
   5.  Compliance with MIDCOM Requirements .......................... 59
       5.1.  Protocol Machinery Requirements ........................ 59
             5.1.1.  Authorized Association ......................... 59
             5.1.2.  Agent Connects to Multiple Middleboxes ......... 60
             5.1.3.  Multiple Agents Connect to Same Middlebox ...... 60
             5.1.4.  Deterministic Behavior ......................... 60
             5.1.5.  Known and Stable State ......................... 60
             5.1.6.  Status Report .................................. 61
             5.1.7.  Unsolicited Messages (Asynchronous
                     Notifications).................................. 61
             5.1.8.  Mutual Authentication .......................... 61
             5.1.9.  Session Termination by Any Party ............... 62
             5.1.10. Request Result ................................. 62
             5.1.11. Version Interworking ........................... 62
             5.1.12. Deterministic Handling of Overlapping Rules .... 62

Top      ToC       Page 3 
       5.2.  Protocol Semantics Requirements ........................ 63
             5.2.1.  Extensible Syntax and Semantics ................ 63
             5.2.2.  Policy Rules for Different Types of Middleboxes  63
             5.2.3.  Ruleset Groups ................................. 63
             5.2.4.  Policy Rule Lifetime Extension ................. 63
             5.2.5.  Robust Failure Modes ........................... 63
             5.2.6.  Failure Reasons ................................ 63
             5.2.7.  Multiple Agents Manipulating Same Policy Rule .. 64
             5.2.8.  Carrying Filtering Rules ....................... 64
             5.2.9.  Parity of Port Numbers ......................... 64
             5.2.10. Consecutive Range of Port Numbers .............. 64
             5.2.11. Contradicting Overlapping Policy Rules ......... 64
       5.3.  Security Requirements .................................. 65
             5.3.1.  Authentication, Confidentiality, Integrity ..... 65
             5.3.2.  Optional Confidentiality of Control Messages ... 65
             5.3.3.  Operation across Untrusted Domains ............. 65
             5.3.4.  Mitigate Replay Attacks ........................ 65
   6.  Security Considerations ...................................... 65
   7.  IAB Considerations on UNSAF .................................. 66
   8.  Acknowledgments .............................................. 67
   9.  References ................................................... 67
       9.1.  Normative References ................................... 67
       9.2.  Informative References ................................. 67
   Authors' Addresses ............................................... 69
   Full Copyright Statement ......................................... 70

1.  Introduction

   The MIDCOM working group has defined a framework [MDC-FRM] and a list
   of requirements [MDC-REQ] for middlebox communication.  The next step
   toward a MIDCOM protocol is the specification of protocol semantics
   that is constrained, but not completely implied, by the documents
   mentioned above.

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

Top      ToC       Page 4 
   at the middlebox caused by the request transactions or indicated by
   the asynchronous transactions, respectively, and (4) the reply and
   notification messages sent from the middlebox to the agent in order
   to inform the agent about the state change.

   The semantics can be implemented by any protocol that supports these
   two transaction types and that is sufficiently flexible concerning
   transaction parameters.  Different implementations for different
   protocols might need to extend the semantics described below by
   adding further transactions and/or adding further parameters to
   transactions and/or splitting single transactions into a set of
   transactions.  Regardless of such extensions, the semantics below
   provides a minimum necessary subset of what must be implemented.

   The remainder of this document is structured as follows.  Section 2
   describes the protocol semantics.  It is structured in four
   subsections:

      - General Protocol Issues (section 2.1)
      - Session Control (section 2.2)
      - Policy Rules (section 2.3)
      - Policy Rule Groups (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 transaction consists of a
                              request message transfer from the agent to
                              the middlebox, processing of the message
                              at the middlebox, a reply message transfer
                              from the middlebox to the agent, and the
                              optional transfer of notification messages
                              from the middlebox to agents other than
                              the one requesting the transaction.  A
                              request transaction might cause a state
                              transition at the middlebox.

Top      ToC       Page 5 
   configuration transaction  A configuration transaction is a request
                              transaction containing a request for state
                              change in the middlebox.  If accepted, it
                              causes a state change at the middlebox.

   monitoring transaction     A monitoring transaction is a request
                              transaction containing a request for state
                              information from the middlebox.  It does
                              not cause a state transition at the
                              middlebox.

   asynchronous transaction   An asynchronous transaction is not
                              triggered by an agent.  It may occur
                              without any agent participating in a
                              session with the middlebox.  Potentially,
                              an asynchronous transaction includes the
                              transfer of notification messages from the
                              middlebox to agents that participate in an
                              open session.  A notification message is
                              sent to each agent that needs to be
                              notified about the asynchronous event.
                              The message indicates the state transition
                              at the middlebox.

   agent-unique               An agent-unique value is unique in the
                              context of the agent.  This context
                              includes all MIDCOM sessions the agent
                              participates in.  An agent-unique value is
                              assigned by the agent.

   middlebox-unique           A middlebox-unique value is unique in the
                              context of the middlebox.  This context
                              includes all MIDCOM sessions the middlebox
                              participates in.  A middlebox-unique value
                              is assigned by the middlebox.

   policy rule                In general, a policy rule is "a basic
                              building block of a policy-based system.
                              It is the binding of a set of actions to a
                              set of conditions -- where the conditions
                              are evaluated to determine whether the
                              actions are performed."  [RFC3198].  In
                              the MIDCOM context the condition is a
                              specification of a set of packets to which
                              rules are applied.  The set of actions
                              always contains just a single element per
                              rule, either action "reserve" or action
                              "enable".

Top      ToC       Page 6 
   policy reserve rule        A policy rule containing a reserve action.
                              The policy condition of this rule is
                              always true.  The action is the
                              reservation of just an IP address or a
                              combination of an IP address and a range
                              of port numbers on neither side, one side,
                              or both sides of the middlebox, depending
                              on the middlebox configuration.

   policy enable rule         A policy rule containing an enable action.
                              The policy condition consists of a
                              descriptor of one or more unidirectional
                              or bidirectional packet flows, and the
                              policy action enables packets belonging to
                              this flow to traverse the middlebox.  The
                              descriptor identifies the protocol, the
                              flow direction, and the source and
                              destination addresses, optionally with a
                              range of port numbers.

   NAT binding                The term NAT binding as used in this
                              document does not necessarily refer to a
                              NAT bind as defined in [NAT-TERM].  A NAT
                              binding in the MIDCOM semantics refers to
                              an abstraction that enables communication
                              between two end points through the NAT-
                              type middlebox.  An enable action may
                              result in a NAT bind or a NAT session,
                              depending on the request and its
                              parameters.

1.2.  Transaction Definition Template

   In the following sections, the semantics of the MIDCOM protocol is
   specified per transaction.  A transaction specification contains the
   following entries.  Parameter entries, failure reason, and
   notification message type are only specified if applicable.

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

   transaction-type
      The transaction type is either 'configuration', 'monitoring', or
      'asynchronous'.  See section 1.1 for a description of transaction
      types.

Top      ToC       Page 7 
   transaction-compliance
      This entry contains either 'mandatory' or 'optional'.  For details
      see section 2.1.8.

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

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

   failure reason
      All negative replies have two parameters: a request identifier
      identifying the request on which the reply is sent and a parameter
      indicating the failure reason.  As these parameters are
      compulsory, they are not listed in the template.  But the template
      contains a list of potential failure reasons that may be indicated
      by the second parameter.  The list is not exhaustive.  A concrete
      protocol specification may extend the list.

   notification message type
      The type of the notification message type that may be used by this
      transaction.

   semantics
      This entry describes the actual semantics of the transaction.
      Particularly, it describes the processing of the request message
      by the middlebox, and middlebox state transitions caused by or
      causing the transaction, respectively.

2.  Semantics Specification

2.1.  General Protocol Design

   The semantics specification aims at a balance between proper support
   of applications that require dynamic configuration of middleboxes and
   simplicity of specification and implementation of the protocol.

   Protocol interactions are structured into transactions.  The state of
   middleboxes is described by state machines.  The state machines are
   defined by states and state transitions.  A single transaction may
   cause or be caused by state transitions in more than one state
   machine, but per state machine there is no more than one transition
   per transaction.

Top      ToC       Page 8 
2.1.1.  Protocol Transactions

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

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

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

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

      - Asynchronous transactions allowing the middlebox to change state
        without a request by an agent.

      - Monitoring transactions allowing the agent to request state
        information from the middlebox.

      - Convenience transactions combining a set of configuration
        transactions.

   Configuration transactions and asynchronous transactions provide the
   basic MIDCOM protocol functionality.  They are related to middlebox
   state transitions, and they concern establishment and termination of
   MIDCOM sessions and of policy rules.

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

   Convenience transactions simplify MIDCOM sessions by combining a set
   of configuration transactions into a single one.  They are not
   necessary for MIDCOM protocol operation.

   As specified in detail in section 3, configuration transactions and
   asynchronous transactions are mandatory.  They must be implemented by
   a compliant middlebox.  All convenience transactions are optional,
   and some of the monitoring transactions are optional.

Top      ToC       Page 9 
2.1.2.  Message Types

   The MIDCOM protocol supports three kinds of messages: request
   messages, reply messages, and notification messages.  For each kind,
   different message types exist.  In this semantics document, message
   types are only defined by the list of parameters.  The order of the
   parameters and their encoding is left to a concrete protocol
   definition.  A protocol definition may also add further parameters to
   a message type or combine several parameters into one, as long as the
   information contained in the parameters defined in the semantics is
   still present.

   For request messages and positive reply messages there exists one
   message type per request transaction.  Each reply transaction defines
   the parameter list of the request message and of the positive
   (successful) reply message by using the transaction definition
   template defined in section 1.2.

   In case of a failed request transaction, a negative reply message is
   sent from the middlebox to the agent.  This message is the same for
   all request transactions; it contains the request identifier
   identifying the request to which the reply is sent and a parameter
   indicating the failure reason.

   There are three notification message types: the Session Termination
   Notification (STN), the Policy Rule Event Notification (REN), and the
   Group Event Notification (GEN).  All of these contain a middlebox-
   unique notification identifier.

   STN   The Session Termination Notification message additionally
         contains a single parameter indicating the reason for session
         termination by the middlebox.

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

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

2.1.3.  Session, Policy Rule, and Policy Rule Group

   All transactions can be further grouped into transactions concerning
   sessions, transactions concerning policy rules, and transactions
   concerning policy rule groups.  Policy rule groups can be used to

Top      ToC       Page 10 
   indicate relationships between policy rules and to simplify
   transactions on a set of policy rules by using a single transaction
   per group instead of one per policy rule.

   Sessions and policy rules at the middlebox are stateful.  Their
   states are independent of each other, and their state machines (one
   per session and one per policy rule) can be separated.  Policy rule
   groups are also stateful, but the middlebox does not need to maintain
   state for policy rule groups, because the semantics were chosen so
   that the policy rule group state is implicitly defined by the state
   of all policy rules belonging to the group (see section 2.4).

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

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

   All request transactions are atomic from the point of view of the
   agent.  The processing of a request does not start before the
   complete request arrives at the middlebox.  No intermediate state is
   stable at the middlebox, and no intermediate state is reported to any
   agent.

   The number of transactions specified in this document is rather
   small.  Again, for simplicity, we reduced it to a minimal set that
   still meets the requirements.  A real implementation of the protocol
   might require splitting some of the transactions specified below into
   two or more transactions of the respective protocol.  Reasons for
   this might include constraints of the particular protocol or the
   desire for more flexibility.  In general this should not be a
   problem.  However, it should be considered that this might change
   atomicity of the affected transactions.

Top      ToC       Page 11 
2.1.5.  Access Control

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

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

   The middlebox may be configured to allow specific authenticated
   agents to access and modify policy rules with certain specific
   owners.  Certainly, a reasonable default configuration would let each
   agent access its own policy rules.  Also, it might be good to
   configure an agent identity to act as administrator, allowing
   modification of all policy rules owned by any agent.  However, the
   configuration of authorization at the middlebox is out of scope of
   the MIDCOM semantics and protocol.

2.1.6.  Middlebox Capabilities

   For several reasons it is useful that at session establishment the
   agent learns about particular capabilities of the middlebox.
   Therefore, the session establishment procedure described in section
   2.2.1 includes a transfer of capability information from the
   middlebox to the agent.  The list of covered middlebox capabilities
   includes the following:

      - Support of firewall function
      - List of supported NAT functions, perhaps including
            - address translation
            - port translation
            - protocol translation
            - twice-NAT
      - Internal IP address wildcard support
      - External IP address wildcard support
      - Port wildcard support
      - Supported IP version(s) for internal network:
        IPv4, IPv6, or both

Top      ToC       Page 12 
      - Supported IP version(s) for external network:
        IPv4, IPv6, or both
      - List of supported optional MIDCOM protocol transactions
      - Optional interface-specific policy rule support: not
        supported or supported
      - Policy rule persistence: persistent or non-persistent
        (a rule is persistent when the middlebox can save the rule to
        a non-volatile memory, e.g., a hard disk or flash memory)
      - Maximum remaining lifetime of a policy rule or policy rule
        group
      - Idle-timeout of policy rules in the middlebox
        (reserved and enabled policy rules not used by any
        data traffic for the time of this idle-timeout are deleted
        automatically by the middlebox; for the deletion of policy
        rules by middleboxes, see section 2.3.13 about Asynchronous
        Policy Rule Event).
      - Maximum number of simultaneous MIDCOM sessions

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

2.1.7.  Agent and Middlebox Identifiers

   To allow both agents and middleboxes to maintain multiple sessions,
   each request message contains a parameter identifying the requesting
   agent, and each reply message and each notification message contains
   a parameter identifying the middlebox.  These parameters are not
   explicitly listed in the description of the individual transactions,
   because they are common to all of them.  They are not further
   referenced in the individual semantics descriptions.  Although, they
   are not necessarily passed explicitly as parameters of the MIDCOM
   protocol, they might be provided by the underlying (secure) transport
   protocol being used.  Agent identifiers at the middlebox are
   middlebox-unique, and middlebox identifiers at the agent are agent-
   unique, respectively.

2.1.8.  Conformance

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

Top      ToC       Page 13 
   Each transaction definition below has a conformance entry that
   contains either 'mandatory' or 'optional'.  A mandatory transaction
   needs to be implemented by every middlebox offering MIDCOM service
   and must be must be offered to each of the authenticated agents.  An
   optional transaction does not necessarily need to be implemented by a
   middlebox; it may offer these optional transactions only to certain
   authenticated agents.  The middlebox may offer one, several, all, or
   no optional transactions to the agents.  Whether an agent is allowed
   to use an optional request transaction is determined by the
   middlebox's authorization procedure, which is not further specified
   by this document.

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 authenticated and authorized association between agent
   and middlebox.  Sessions are initiated by agents and can be
   terminated by either the agent or the middlebox.  Both agent and
   middlebox may participate in several sessions (with different
   entities) at the same time.  To distinguish different sessions, each
   party uses local session identifiers.

   All transactions are transmitted within this MIDCOM session.

   Session control is supported by three transactions:

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

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

2.2.1.  Session Establishment (SE)

   transaction-name: session establishment

   transaction-type: configuration

   transaction-compliance: mandatory

   request-parameters:

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

Top      ToC       Page 14 
      - 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
        authenticating the agent to the middlebox.  As seen below, this
        is updated in the second iteration of the request with material
        responding to the middlebox challenge.

   reply-parameters (success):

      - request identifier: An identifier matching the identifier
        request.

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

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

      - middlebox capabilities: A list describing the middlebox's
        capabilities.  See section 2.1.6 for the list of middlebox
        capabilities.

   failure reason:

      - authentication failed
      - no authorization
      - protocol version of agent and middlebox do not match
      - lack of resources

   semantics:

      This session establishment transaction is used to establish a
      MIDCOM session.  For mutual authentication of both parties two
      subsequent session establishment transactions are required as
      shown in Figure 1.

Top      ToC       Page 15 
             agent                                       middlebox
               | session establishment request               |
               |  (with middlebox challenge mc)              | CLOSED
               |-------------------------------------------->|
               |                                             |
               | successful reply (with middlebox            |
               |  authentication ma and agent challenge ac)  |
               |<--------------------------------------------|
               |                                             | NOAUTH
               | session establishment request               |
               |  (with agent authentication aa)             |
               |-------------------------------------------->|
               |                                             |
               | successful reply                            |
               |<--------------------------------------------|
               |                                             | OPEN
               |                                             |

            Figure 1: Mutual authentication of agent and middlebox

      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 whether the
      requesting agent is authorized to open a MIDCOM session.  If it is
      not, the middlebox generates a negative reply with 'no
      authorization' as failure reason.  If authentication and
      authorization are successful, the session is established, and the
      agent may start with requesting transactions on policy rules and
      policy rule groups.

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

2.2.2.  Session Termination (ST)

   transaction-name: session termination

   transaction-type: configuration

   transaction-compliance: mandatory

   request-parameters:

Top      ToC       Page 16 
      - request identifier: An agent-unique identifier for matching
        corresponding request and reply at the agent.

   reply-parameters (success only):

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

   semantics:

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

      The middlebox always generates a successful reply.  After sending
      the reply, the middlebox will not send any further messages to the
      agent within the current session.  It also will not process any
      further request within this session that it received while
      processing the session termination request, or that it receives
      later.

2.2.3.  Asynchronous Session Termination (AST)

   transaction-name: asynchronous session termination

   transaction-type: asynchronous

   transaction-compliance: mandatory

   notification message type: Session Termination Notification (STN)

   reply-parameters (success only):

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

   semantics:

      The middlebox may decide to terminate a MIDCOM session at any
      time.  Before terminating the actual session the middlebox
      generates a STN message and sends it to the agent.  After sending
      the notification, the middlebox will not process any further
      request by the agent, even if it is already queued at the
      middlebox.

      After session termination, the middlebox keeps all established
      policy rules until their lifetime expires or until an event occurs
      for which the middlebox terminates them.

Top      ToC       Page 17 
      Unlike in other asynchronous transactions, no more than one
      notification is sent, because there is only one agent affected by
      the transaction.

2.2.4.  Session Termination by Interruption of Connection

   If a MIDCOM session is based on an underlying network connection, the
   session can also be terminated by an interruption of this connection.
   If the middlebox detects this, it immediately terminates the session.
   The effect on established policy rules is the same as for the
   Asynchronous Session Termination.

2.2.5.  Session State Machine

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

   All sessions start in state CLOSED.  If mutual authentication is
   already provided by other means, a successful SE transaction can
   cause a state transition to state OPEN.  Otherwise, it causes a
   transition to state NOAUTH.  From this state a failed second SE
   transaction returns to state CLOSED.  A successful SE transaction
   causes a transition to state OPEN.  At any time, an AST transaction
   or a connection failure may occur, causing a transition to state
   CLOSED.  A successful ST transaction from either NOAUTH or OPEN also
   causes a return to CLOSED.  The parameters of the transactions are
   explained in Figure 2; the value mc=0 represents an empty middlebox
   challenge.

Top      ToC       Page 18 
                                   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



(page 18 continued on part 2)

Next RFC Part