tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 5189

 
 
 

Middlebox Communication (MIDCOM) Protocol Semantics

Part 2 of 3, p. 18 to 48
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 18 
2.3.  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 List (PRL)
      - Policy Rule Status (PRS)
      - Asynchronous Policy Rule Event (ARE)

   The first three transactions (PRR, PER, RLC) are configuration
   transactions initiated by the agent.  The fourth and fifth (PRL, PRS)
   are monitoring transactions.  The last one (ARE) is an asynchronous
   transaction.  The PRL and PRS transactions do not have any effect on
   the policy rule state machine.

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

Top      Up      ToC       Page 19 
2.3.1.  Configuration Transactions

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

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

   Some cases require knowing in advance which IP address (and port
   number) would be chosen by NAT in a PER transaction.  This
   information is required before sufficient information for performing
   a complete PER transaction is available (see example in 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)

2.3.2.  Establishing Policy Rules

   Both PRR and PER establish a policy rule.  The action within the rule
   is 'reserve' if set by PRR and 'enable' if set by PER.

   The Policy Reserve Rule (PRR) transaction is used to establish an
   address reservation on neither side, one side, or both sides of the
   middlebox, depending on the middlebox configuration.  The transaction
   returns the reserved IP addresses and the optional ranges of port
   numbers to the agent.  No address binding or pinhole configuration is
   performed at the middlebox.  Packet processing at the middlebox
   remains unchanged.

   On pure firewalls, the PRR transaction is successfully processed
   without any reservation, but the state transition of the MIDCOM
   protocol engine is exactly the same as on NATs.

   On a traditional NAT (see [NAT-TRAD]), only an external address is
   reserved; on a twice-NAT, an internal and an external address are
   reserved.  The reservation at a NAT is for required resources, such
   as IP addresses and port numbers, for future use.  How the
   reservation is exactly done depends on the implementation of the NAT.
   In both cases, the reservation concerns either an IP address only or
   a combination of an IP address with a range of port numbers.

   The Policy Enable Rule (PER) transaction is used to establish a
   policy rule that affects packet processing at the middlebox.
   Depending on its input parameters, it may make use of the reservation
   established by a PRR transaction or create a new rule from scratch.

Top      Up      ToC       Page 20 
   On a NAT, the enable action is interpreted as a bind action
   establishing bindings between internal and external addresses.  At a
   firewall, the enable action is interpreted as one or more allow
   actions configuring pinholes.  The number of allow actions depends on
   the parameters of the request and the implementation of the firewall.

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

   The PRR transaction and the PER transaction are described in more
   detail in sections 2.3.8 and 2.3.9 below.

2.3.3.  Maintaining Policy Rules and Policy Rule Groups

   Each policy rule has a middlebox-unique identifier.

   Each policy rule has an owner.  Access control to the policy rule is
   based on ownership (see section 2.1.5).  Ownership of a policy rule
   does not change during lifetime of the policy rule.

   Each policy rule has an individual lifetime.  If the policy rule
   lifetime expires, the policy rule will be terminated at the
   middlebox.  Typically, the middlebox indicates termination of a
   policy rule by an ARE transaction.  A Policy Rule Lifetime Change
   (RLC) transaction may extend the lifetime of the policy rule up to
   the limit specified by the middlebox at session setup.  Also, an RLC
   transaction may be used for shortening a policy rule's lifetime or
   deleting a policy rule by requesting a lifetime of zero.  (Please
   note that policy rule lifetimes may also be modified by the Group
   Lifetime Change (GLC) transaction.)

   Each policy rule is a member of exactly one policy rule group.  Group
   membership does not change during the lifetime of a policy rule.
   Selecting the group is part of the transaction establishing the
   policy rule.  This transaction implicitly creates a new group if the
   agent does not specify one.  The new group identifier is chosen by
   the middlebox.  New members are added to an existing group if the
   agent's request designates one.  A group only exists as long as it
   has member policy rules.  As soon as all policies belonging to the
   group have reached the ends of their lifetimes, the group does not
   exist anymore.

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

Top      Up      ToC       Page 21 
2.3.4.  Policy Events and Asynchronous Notifications

   If a policy rule changes its state or if its remaining lifetime is
   changed in ways other than being decreased by time, then all agents
   that can access this policy rule and that participate in an open
   session with the middlebox are notified by the middlebox.  If the
   state or lifetime change was requested explicitly by a request
   message, then the middlebox notifies the requesting agent by
   returning the corresponding reply.  All other agents that can access
   the policy are notified by a Policy Rule Event Notification (REN)
   message.

   Note that a middlebox can serve multiple agents at the same time in
   different parallel sessions.  Between these agents, the sets of
   policy rules that can be accessed by them may overlap.  For example,
   there might be an agent that authenticates as administrator and that
   can access all policies of all agents.  Or there could be a backup
   agent running a session in parallel to a main agent and
   authenticating itself as the same entity as the main agent.

   In case of a PER, PRR, or RLC transaction, the requesting agent
   receives a PER, PRR, or RLC reply, respectively.  To all other agents
   that can access the created, modified, or terminated policy rule (and
   that participate in an open session with the middlebox), the
   middlebox sends a REN message carrying the policy rule identifier
   (PID) and the remaining lifetime of the policy rule.

   In case of a rule termination by lifetime truncation or other events
   not triggered by an agent, the middlebox sends a REN message to each
   agent that can access the particular policy rule and that
   participates in an open session with the middlebox.  This ensures
   that an agent always knows the most recent state of all policy rules
   it can access.

2.3.5.  Address Tuples

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

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

Top      Up      ToC       Page 22 
   Additionally, the request message of PER and the reply message of PRS
   contain a direction of flow parameter.  This direction of flow
   parameter indicates for UDP and IP the direction of packets
   traversing the middlebox.  For 'inbound', the UDP packets are
   traversing from outside to inside; for 'outbound', from inside to
   outside.  In both cases, the packets can traverse the middlebox only
   unidirectionally.  A bidirectional flow is enabled through
   'bidirectional' as direction of flow parameter.  For TCP, the packet
   flow is always bidirectional, but the direction of the flow parameter
   is defined as

      - inbound: bidirectional TCP packet flow.  First packet, with TCP
        SYN flag set and ACK flag not set, must arrive at the middlebox
        at the outside interface.

      - outbound: bidirectional TCP packet flow.  First packet, with TCP
        SYN flag set and ACK flag not set, must arrive at the middlebox
        at the inside interface.

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

   We refer to the set of these parameters as an address tuple.  An
   address tuple specifies either a communication endpoint at an
   internal or external device or allocated addresses at the middlebox.
   In this document, we distinguish four kinds of address tuples, as
   shown in Figure 3.

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

                   Figure 3: Address Tuples A0 - A3

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

      - A1 - middlebox inside address: Address tuple A1 specifies a
        virtual communication endpoint at the middlebox within the
        internal network.  A1 is the destination address for packets
        passing from the internal endpoint to the middlebox and is the
        source for packets passing from the middlebox to the internal
        endpoint.

Top      Up      ToC       Page 23 
      - A2 - middlebox outside address: Address tuple A2 specifies a
        virtual communication endpoint at the middlebox within the
        external network.  A2 is the destination address for packets
        passing from the external endpoint to the middlebox and is the
        source for packets passing from the middlebox to the external
        endpoint.

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

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

   For a traditional NAT, A2 is given a value different from that of A0,
   but the NAT binds them.  As for the firewall, it is also as it is at
   a traditional NAT: A1 has the same value as A3.

   For a twice-NAT, there are two bindings of address tuples: A1 and A2
   are both assigned values by the NAT.  The middlebox outside address
   A2 is bound to the internal endpoint A0, and the middlebox inside
   address A1 is bound to the external endpoint A3.

2.3.6.  Address Parameter Constraints

   For transaction parameters belonging to an address tuple, some
   constraints exist that are common for all messages using them.
   Therefore, these constraints are summarized in the following and are
   not repeated again when describing the parameters in the transaction
   descriptions are presented.

   The MIDCOM semantics defined in this document specifies the handling
   of IPv4 and IPv6 as network protocols, and of TCP and UDP (over IPv4
   and IPv6) as transport protocols.  The handling of any other
   transport protocol, e.g., Stream Control Transmission Protocol
   (SCTP), is not defined within the semantics but may be supported by
   concrete protocol specifications.

   The IP version parameter has either the value 'IPv4' or 'IPv6'.  In a
   policy rule, the value of the IP version parameter must be the same
   for address tuples A0 and A1, and for A2 and A3.

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

Top      Up      ToC       Page 24 
   The IP address of an address tuple may be wildcarded.  Whether IP
   address wildcarding is allowed or in which range it is allowed
   depends on the local policy of the middlebox; see also section 6,
   "Security Considerations".  Wildcarding is specified by the IP
   address prefix length parameter of an address tuple.  In line with
   the common use of a prefix length, this parameter indicates the
   number of high significant bits of the IP address that are fixed,
   while the remaining low significant bits of the IP address are
   wildcarded.

   The value of the transport protocol parameter can be either 'TCP',
   'UDP', or 'ANY'.  If the transport protocol parameter has the value
   'ANY', only IP headers are considered for packet handling in the
   middlebox -- i.e., the transport header is not considered.  The
   values of the parameters port number, port range, and port parity are
   irrelevant if the protocol parameter is 'ANY'.  In a policy rule, the
   value of the transport protocol parameter must be the same for all
   address tuples A0, A1, A2, and A3.

   The value of the port number parameter is either zero or a positive
   integer.  A positive integer specifies a concrete UDP or TCP port
   number.  The value zero specifies port wildcarding for the protocol
   specified by the transport protocol parameter.  If the port number
   parameter has the value zero, then the value of the port range
   parameter is irrelevant.  Depending on the value of the transport
   protocol parameter, this parameter may truly refer to ports or may
   refer to an equivalent concept.

   The port parity parameter is differently used in the context of
   Policy Reserve Rules (PRRs) and Policy Enable Rules (PERs).  In the
   context of a PRR, the value of the parameter may be 'odd', 'even', or
   'any'.  It specifies the parity of the first (lowest) reserved port
   number.

   In the context of a PER, the port parity parameter indicates to the
   middlebox whether port numbers allocated at the middlebox should have
   the same parity as the corresponding internal or external port
   numbers, respectively.  In this context, the parameter has the value
   'same' or 'any'.  If the value is 'same', then the parity of the port
   number of A0 must be the same as the parity of the port number of A2,
   and the parity of the port number of A1 must be the same as the
   parity of the port number of A3.  If the port parity parameter has
   the value 'any', then there are no constraints on the parity of any
   port number.

   The port range parameter specifies a number of consecutive port
   numbers.  Its value is a positive integer.  Like the port number
   parameter, this parameter defines a set of consecutive port numbers

Top      Up      ToC       Page 25 
   starting with the port number specified by the port number parameter
   as the lowest port number and having as many elements as specified by
   the port range parameter.  A value of 1 specifies a single port
   number.  The port range parameter must have the same value for each
   address tuple A0, A1, A2, and A3.

   A single policy rule P containing a port range value greater than one
   is equivalent to a set of policy rules containing a number n of
   policies P_1, P_2, ..., P_n where n equals the value of the port
   range parameter.  Each policy rule P_1, P_2, ..., P_n has a port
   range parameter value of 1.  Policy rule P_1 contains a set of
   address tuples A0_1, A1_1, A2_1, and A3_1, each of which contains the
   first port number of the respective address tuples in P; policy rule
   P_2 contains a set of address tuples A0_2, A1_2, A2_2, and A3_2, each
   of which contains the second port number of the respective address
   tuples in P; and so on.

2.3.7.  Interface-Specific Policy Rules

   Usually, agents request policy rules with the knowledge of A0 and A3
   only, i.e., the address tuples (see section 2.3.5).  But in very
   special cases, agents may need to select the interfaces to which the
   requested policy rule is bound.  Generally, the middlebox is careful
   about choosing the right interfaces when reserving or enabling a
   policy rule, as it has the overall knowledge about its configuration.
   For agents that want to select the interfaces, optional parameters
   are included in the Policy Reserve Rule (PRR) and Policy Enable Rule
   (PER) transactions.  These parameters are called

      - inside interface: The selected interface at the inside of the
        middlebox -- i.e., in the private or protected address realm.

      - outside interface: The selected interface at the outside of the
        middlebox -- i.e., in the public address realm.

   The Policy Rule Status (PRS) transactions include these optional
   parameters in their replies when they are supported.

   Agents can learn at session startup whether interface-specific policy
   rules are supported by the middlebox, by checking the middlebox
   capabilities (see section 2.1.6).

2.3.8.  Policy Reserve Rule (PRR)

   transaction-name: policy reserve rule

   transaction-type: configuration

Top      Up      ToC       Page 26 
   transaction-compliance: mandatory

   request-parameters:

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

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

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

      - internal IP version: Requested IP version at the inside of the
        middlebox; see section 2.3.5.

      - internal IP address: The IP address of the internal
        communication endpoint (A0 in Figure 3); see section 2.3.5.

      - internal port number: The port number of the internal
        communication endpoint (A0 in Figure 3); see section 2.3.5.

      - inside interface (optional): Interface at the inside of the
        middlebox; see section 2.3.7.

      - external IP version: Requested IP version at the outside of the
        middlebox; see section 2.3.5.

      - outside interface (optional): Interface at the outside of the
        middlebox; see section 2.3.7.

      - transport protocol: See section 2.3.5.

      - port range: The number of consecutive port numbers to be
        reserved; see section 2.3.5.

      - port parity: The requested parity of the first (lowest) port
        number to be reserved; allowed values for this parameter are
        'odd', 'even', and 'any'.  See also section 2.3.5.

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

Top      Up      ToC       Page 27 
   reply-parameters (success):

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

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

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

      - reserved inside IP address: The reserved IPv4 or IPv6 address on
        the internal side of the middlebox.  For an outbound flow, this
        will be the destination to which the internal endpoint sends its
        packets (A1 in Figure 3).  For an inbound flow, it will be the
        apparent source address of the packets as forwarded to the
        internal endpoint (A0 in Figure 3).  The middlebox reserves and
        reports an internal address only in the case where twice-NAT is
        in effect.  Otherwise, an empty value for the addresses
        indicates that no internal reservation was made.  See also
        section 2.3.5.

      - reserved inside port number: See section 2.3.5.

      - reserved outside IP address: The reserved IPv4 or IPv6 address
        on the external side of the middlebox.  For an inbound flow,
        this will be the destination to which the external endpoint
        sends its packets (A2 in Figure 3).  For an outbound flow, it
        will be the apparent source address of the packets as forwarded
        to the external endpoint (A3 in Figure 3).  If the middlebox is
        configured as a pure firewall, an empty value for the addresses
        indicates that no external reservation was made.  See also
        section 2.3.5.

      - reserved outside port number: See section 2.3.5.

      - policy rule lifetime: The policy rule lifetime granted by the
        middlebox, after which the reservation will be revoked if it has
        not been replaced already by a policy enable rule in a PER
        transaction.

Top      Up      ToC       Page 28 
   failure reason:

      - agent not authorized for this transaction
      - agent not authorized to add members to this group
      - lack of IP addresses
      - lack of port numbers
      - lack of resources
      - specified inside/outside interface does not exist
      - specified inside/outside interface not available for specified
        service

   notification message type: Policy Rule Event Notification (REN)

   semantics:

      The agent can use this transaction type to reserve an IP address
      or a combination of IP address, transport type, port number, and
      port range at neither side, one side, or both sides of the
      middlebox as required to support the enabling of a flow.
      Typically, the PRR will be used in scenarios where it is required
      to perform such a reservation before sufficient parameters for a
      complete policy enable rule transaction are available.  See
      section 4.2 for an example.

      When receiving the request, the middlebox determines how many
      address (and port) reservations are required based on its
      configuration.  If it provides only packet filter services, it
      does not perform any reservation and returns empty values for the
      reserved inside and outside IP addresses and port numbers.  If it
      is configured for twice-NAT, it reserves both inside and outside
      IP addresses (and an optional range of port numbers) and returns
      them.  Otherwise, it reserves and returns an outside IP address
      (and an optional range of port numbers) and returns empty values
      for the reserved inside address and port range.

      The A0 parameter (inside IP address version, inside IP address,
      and inside port number) can be used by the middlebox to determine
      the correct NAT mapping and thus A2 if necessary.  Once a PRR
      transaction has reserved an outside address (A2) for an internal
      endpoint (A0) at the middlebox, the middlebox must ensure that
      this reserved A2 is available in any subsequent PER and PRR
      transactions.

      For middleboxes supporting interface-specific policy rules, as
      defined in section 2.3.7, the optional inside and outside
      interface parameters must both be included in the request, or
      neither of them should be included.  In the presence of these
      parameters, the middlebox uses the outside interface parameter to

Top      Up      ToC       Page 29 
      select the interface at which the outside address tuple (outside
      IP address and port number) is reserved, and the inside interface
      parameter to select the interface at which the inside address
      tuple (inside IP address and port number) is reserved.  Without
      the presence of these parameters, the middlebox selects the
      particular interfaces based on its internal configuration.

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

      If a non-existing policy rule group was specified, or if an
      existing policy rule group was specified that is not owned by the
      requesting agent, then no new policy rule is established, and an
      appropriate failure reply is generated.

      In case of success, this transaction creates a new policy reserve
      rule.  If an already existing policy rule group is specified, then
      the new policy rule becomes a member of it.  If no policy group is
      specified, a new group is created with the new policy rule as its
      only member.  The middlebox generates a middlebox-unique
      identifier for the new policy rule.  The owner of the new policy
      rule is the authenticated agent that sent the request.  The
      middlebox chooses a lifetime value that is greater than zero and
      less than or equal to the minimum of the requested value and the
      maximum lifetime specified by the middlebox at session startup,
      i.e.,

         0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)

      where
         - lt_granted is the lifetime actually granted by the middlebox
         - lt_requested is the lifetime the agent requested
         - lt_maximum is the maximum lifetime specified at session
           setup

      A middlebox with NAT capability always reserves a middlebox
      external address tuple (A2) in response to a PRR request.  In the
      special case of a combined twice-NAT/NAT middlebox, the agent can
      request only NAT service or twice-NAT service by choosing the
      service parameter 'traditional' or 'twice'.  An agent that does
      not have any preference chooses 'twice'.  The 'traditional' value
      should only be used to select traditional NAT service at
      middleboxes offering both traditional NAT and twice-NAT.  In the
      'twice' case, the combined twice-NAT/NAT middlebox reserves A2 and
      A1; the 'traditional' case results in a reservation of A2 only.
      An agent must always use the PRR transaction for choosing NAT only

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

      If the protocol identifier is 'ANY', then the middlebox reserves
      available inside and/or outside IP address(es) only.  The reserved
      address(es) are returned to the agent.  In this case, the
      request-parameters "port range" and "port parity" as well as the
      reply-parameters "inside port number" and "outside port number"
      are irrelevant.

      If the protocol identifier is 'UDP' or 'TCP', then a combination
      of an IP address and a consecutive sequence of port numbers,
      starting with the specified parity, is reserved, on neither side,
      one side, or both sides of the middlebox, as appropriate.  The IP
      address(es) and the first (lowest) reserved port number(s) of the
      consecutive sequence are returned to the agent.  (This also
      applies to other protocols supporting ports or the equivalent.)

      After a new policy reserve rule is successfully established and
      the reply message has been sent to the requesting agent, the
      middlebox checks whether there are other authenticated agents
      participating in open sessions, which can access the new policy
      rule.  If the middlebox finds one or more of these agents, then it
      sends a REN message reporting the new policy rule to each of them.

   MIDCOM agents use the policy enable rule (PER) transaction to enable
   policy reserve rules that have been established beforehand by a
   policy reserve rule (PRR) transaction.  See also section 2.3.2.

2.3.9.  Policy Enable Rule (PER)

   transaction-name: policy enable rule

   transaction-type: configuration

   transaction-compliance: mandatory

   request-parameters:

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

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

Top      Up      ToC       Page 31 
        port range, port parity, internal IP version, external IP
        version.

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

      - transport protocol: See section 2.3.5.

      - port range: The number of consecutive port numbers to be
        reserved; see section 2.3.5.

      - port parity: The requested parity of the port number(s) to be
        mapped.  Allowed values of this parameter are 'same' and 'any'.
        See also section 2.3.5.

      - direction of flow: This parameter specifies the direction of
        enabled communication, either 'inbound', 'outbound', or
        'bidirectional'.

      - internal IP version: Requested IP version at the inside of the
        middlebox; see section 2.3.5.

      - internal IP address: The IP address of the internal
        communication endpoint (A0 in Figure 3); see section 2.3.5.

      - internal port number: The port number of the internal
        communication endpoint (A0 in Figure 3); see section 2.3.5.

      - inside interface (optional): Interface at the inside of the
        middlebox; see section 2.3.7.

      - external IP version: Requested IP version at the outside of the
        middlebox; see section 2.3.5.

      - external IP address: The IP address of the external
        communication endpoint (A3 in Figure 3); see section 2.3.5.

      - external port number: The port number of the external
        communication endpoint (A3 in Figure 3), see section 2.3.5.

      - outside interface (optional): Interface at the outside of the
        middlebox; see section 2.3.7.

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

Top      Up      ToC       Page 32 
   reply-parameters (success):

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

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

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

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

      - inside port number: The internal port number provided at the
        inside of the middlebox (A1 in Figure 3);  see also section
        2.3.5.

      - outside IP address: The external IP address provided at the
        outside of the middlebox (A2 in Figure 3).  In case of a pure
        firewall, this parameter will be identical with the internal IP
        address passed with the request.  In all other cases, this
        reply-parameter will be an external IP address reserved at the
        outside of the middlebox.  See also section 2.3.5.

      - outside port number: The external port number provided at the
        outside of the NAT (A2 in Figure 3); see section 2.3.5..

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

   failure reason:

      - agent not authorized for this transaction

Top      Up      ToC       Page 33 
      - agent not authorized to add members to this group
      - no such policy reserve rule
      - agent not authorized to replace this policy reserve rule
      - conflict with already existing policy rule (e.g., the same
        internal address-port is being mapped to different outside
        address-port pairs)
      - lack of IP addresses
      - lack of port numbers
      - lack of resources
      - no internal IP wildcarding allowed
      - no external IP wildcarding allowed
      - specified inside/outside interface does not exist
      - specified inside/outside interface not available for specified
        service
      - reserved A0 to requested A0 mismatch

   notification message type: Policy Rule Event Notification (REN)

   semantics:

      This transaction can be used by an agent to enable communication
      between an internal endpoint and an external endpoint
      independently of the type of middlebox (NAT, NAPT, firewall, NAT-
      PT, combined devices), for unidirectional or bidirectional
      traffic.

      The agent sends an enable request specifying the endpoints
      (optionally including wildcards) and the direction of
      communication (inbound, outbound, bidirectional).  The
      communication endpoints are displayed in Figure 3.  The basic
      operation of the PER transaction can be described by

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

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

         3. the middlebox enabling packet transfer between A0 and A3 by
            binding A0-A2 and A1-A3 and/or by opening the corresponding
            pinholes, both according to the specified direction, and

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

      In case of a pure packet filtering firewall, the returned address
      tuples are the same as those in the request: A2=A0 and A1=A3.
      Each partner uses the other's real address.  In case of a
      traditional NAT, the internal endpoint may use the real address of
      the external endpoint (A1=A3), but the external endpoint uses an

Top      Up      ToC       Page 34 
      address tuple provided by the NAT (A2!=A0).  In case of a twice-
      NAT device, both endpoints use address tuples provided by the NAT
      for addressing their communication partner (A3!=A1 and A2!=A0).

      If a firewall is combined with a NAT or a twice-NAT, the replied
      address tuples will be the same as for pure traditional NAT or
      twice-NAT, respectively, but the middlebox will configure its
      packet filter in addition to the performed NAT bindings.  In case
      of a firewall combined with a traditional NAT, the policy rule may
      imply more than one enable action for the firewall configuration,
      as incoming and outgoing packets may use different source-
      destination pairs.

      For middleboxes supporting interface-specific policy rules, as
      defined in section 2.3.7, the optional inside and outside
      interface parameters must both be included in the request, or
      neither of them should be included.  In the presence of these
      parameters, the middlebox uses the outside interface parameter to
      select the interface at which the outside address tuple (outside
      IP address and port number) is bound, and the inside interface
      parameter to select the interface at which the inside address
      tuple (inside IP address and port number) is bound.  Without the
      presence of these parameters, the middlebox selects the particular
      interfaces based on its internal configuration.

      Checking the Policy Reservation Rule Identifier

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

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

         The PRR transaction sets the internal endpoint A0 during the
         reservation process.  In the process of creating a new policy
         enable rule, the middlebox may check whether the requested A0
         is equal to the reserved A0.  The middlebox may reject a PER
         request with a requested A0 not equal to the reserved A0 and
         must then send an appropriate failure message.  Alternatively,
         the middlebox may change A0 due to the PER request.

Top      Up      ToC       Page 35 
         The middlebox generates a middlebox-unique identifier for the
         new policy rule.  If a policy reserve rule was referenced, then
         the identifier of the policy reserve rule is reused.

         The owner of the new policy rule is the authenticated agent
         that sent the request.

      Checking the Policy Rule Group Identifier

         If no policy reserve rule was specified, then the policy rule
         group parameter is checked.  If a non-existing policy rule
         group is specified, or if an existing policy rule group is
         specified that is not owned by the requesting agent, then no
         new policy rule is established, and an appropriate failure
         reply is generated.

         If an already existing policy rule group is specified, then the
         new policy rule becomes a member.  If no policy group is
         specified, then a new group is created with the new policy rule
         as its only member.

      If the transport protocol parameter value is 'ANY', then the
      middlebox enables communication between the specified external IP
      address and the specified internal IP address.  The addresses to
      be used by the communication partners to address each other are
      returned to the agent as inside IP address and outside IP address.
      If the reservation identifier is not empty and if the reservation
      used the same transport protocol type, then the reserved IP
      addresses are used.

      For the transport protocol parameter values 'UDP' and 'TCP', the
      middlebox acts analogously as for 'ANY' but also maps ranges of
      port numbers, keeping the port parity, if requested.

      The configuration of the middlebox may fail because of lack of
      resources, such as available IP addresses, port numbers, or
      storage for further policy rules.  It may also fail because of a
      conflict with an established policy rule.  In case of a conflict,
      the first-come first-served mechanism is applied.  Existing policy
      rules remain unchanged and arriving new ones are rejected.
      However, in case of a non-conflicting overlap of policy rules
      (including identical policy rules), all policy rules are accepted.

      The middlebox chooses a lifetime value that is greater than zero
      and less than or equal to the minimum of the requested value and
      the maximum lifetime specified by the middlebox at session
      startup, i.e.,

Top      Up      ToC       Page 36 
         0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)

      where
       - lt_granted is the lifetime actually granted by the middlebox
       - lt_requested is the lifetime the agent requested
       - lt_maximum is the maximum lifetime specified at session setup

   In each case of failure, an appropriate failure reply is generated.
   The policy reserve rule that is referenced in the PER transaction is
   not affected in case of a failure within the PER transaction -- i.e.,
   the policy reserve rule remains.

   After a new policy enable rule is successfully established and the
   reply message has been sent to the requesting agent, the middlebox
   checks whether there are other authenticated agents participating in
   open sessions that can access the new policy rule.  If the middlebox
   finds one or more of these agents, then it sends a REN message
   reporting the new policy rule to each of them.

2.3.10.  Policy Rule Lifetime Change (RLC)

   transaction-name: policy rule lifetime change

   transaction-type: configuration

   transaction-compliance: mandatory

   request-parameters:

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

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

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

   reply-parameters (success):

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

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

Top      Up      ToC       Page 37 
   failure reason:

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

   notification message type: Policy Rule Event Notification (REN)

   semantics:

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

      The middlebox first checks whether the specified policy rule
      exists and whether the agent is authorized to access this policy
      rule.  If one of the checks fails, an appropriate failure reply is
      generated.  If the requested lifetime is longer than the current
      one, the middlebox also checks whether the lifetime of the policy
      rule may be extended and generates an appropriate failure message
      if it may not.

      A failure reply implies that the new lifetime was not accepted,
      and the policy rule remains unchanged.  A success reply is
      generated by the middlebox if the lifetime of the policy rule was
      changed in any way.

      The success reply contains the new lifetime of the policy rule.
      The middlebox chooses a lifetime value that is greater than zero
      and less than or equal to the minimum of the requested value and
      the maximum lifetime specified by the middlebox at session
      startup, i.e.,

         0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)

      where
       - lt_granted is the lifetime actually granted by the middlebox
       - lt_requested is the lifetime the agent requested
       - lt_maximum is the maximum lifetime specified at session setup

   After sending a success reply with a lifetime of zero, the middlebox
   will consider the policy rule non-existent.  Any further transaction
   on this policy rule results in a negative reply, indicating that this
   policy rule does not exist anymore.

Top      Up      ToC       Page 38 
   Note that policy rule lifetime may also be changed by the Group
   Lifetime Change (GLC) transaction, if applied to the group of which
   the policy rule is a member.

   After the remaining policy rule lifetime was successfully changed and
   the reply message has been sent to the requesting agent, the
   middlebox checks whether there are other authenticated agents
   participating in open sessions that can access the policy rule.  If
   the middlebox finds one or more of these agents, then it sends a REN
   message reporting the new remaining policy rule lifetime to each of
   them.

2.3.11.  Policy Rule List (PRL)

   transaction-name: policy rule list

   transaction-type: monitoring

   transaction-compliance: mandatory

   request-parameters:

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

   reply-parameters (success):

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

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

   failure reason:

      - transaction not supported
      - agent not authorized for this transaction

Top      Up      ToC       Page 39 
   semantics:

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

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

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

2.3.12.  Policy Rule Status (PRS)

   transaction-name: policy rule status

   transaction-type: monitoring

   transaction-compliance: mandatory

   request-parameters:

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

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

   reply-parameters (success):

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

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

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

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

Top      Up      ToC       Page 40 
      - transport protocol: Identifies the protocol for which a
        reservation is requested; see section 2.3.5.

      - port range: The number of consecutive port numbers; see section
        2.3.5.

      - direction: The direction of the communication enabled by the
        middlebox.  Applicable only to policy enable rules.

      - internal IP address version: The version of the internal IP
        address (IP version of A0 in Figure 3).

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

      - internal IP address: The IP address of the internal
        communication endpoint (A0 in Figure 3); see section 2.3.5.

      - internal port number: The port number of the internal
        communication endpoint (A0 in Figure 3); see section 2.3.5.

      - external IP address: The IP address of the external
        communication endpoint (A3 in Figure 3); see section 2.3.5.

      - external port number: The port number of the external
        communication endpoint (A3 in Figure 3); see section 2.3.5.

      - inside interface (optional): The inside interface at the
        middlebox; see section 2.3.7.

      - inside IP address: The internal IP address provided at the
        inside of the NAT (A1 in Figure 3); see section 2.3.5.

      - inside port number: The internal port number provided at the
        inside of the NAT (A1 in Figure 3); see section 2.3.5.

      - outside interface (optional): The outside interface at the
        middlebox; see section 2.3.7.

      - outside IP address: The external IP address provided at the
        outside of the NAT (A2 in Figure 3); see section 2.3.5.

      - outside port number: The external port number provided at the
        outside of the NAT (A2 in Figure 3); see section 2.3.5.

      - port parity: The parity of the allocated ports.

Top      Up      ToC       Page 41 
      - service: The selected service in the case of mixed traditional
        and twice-NAT middlebox (see section 2.3.8).

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

   failure reason:

      - transaction not supported
      - agent not authorized for this transaction
      - no such policy rule
      - agent not authorized to access this policy rule

   semantics:

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

      The middlebox first checks whether the specified policy rule
      exists and whether the agent is authorized to access this group.
      If one of the checks fails, an appropriate failure reply is
      generated.  Otherwise, all properties of the policy rule are
      returned to the agent.  Some of the returned parameters may be
      irrelevant, depending on the policy rule action ('reserve' or
      'enable') and depending on other parameters -- for example, the
      protocol identifier.

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

2.3.13.  Asynchronous Policy Rule Event (ARE)

   transaction-name: asynchronous policy rule event

   transaction-type: asynchronous

   transaction-compliance: mandatory

   notification message type: Policy Rule Event Notification (REN)

   semantics:

      The middlebox may decide at any point in time to terminate a
      policy rule.  This transaction is triggered most frequently by
      lifetime expiration of the policy rule.  Among other events that

Top      Up      ToC       Page 42 
      may cause this transaction are changes in the policy rule decision
      point.

      The middlebox sends a REN message to all agents that participate
      in an open session with the middlebox and that are authorized to
      access the policy rule.  The notification is sent to the agents
      before the middlebox changes the policy rule's lifetime.  The
      change of lifetime may be triggered by any other authorized agent
      and results in shortening (lt_new < lt_existing), extending
      (lt_new > lt_existing), or terminating the policy rule
      (lt_new = 0).

   The ARE transaction corresponds to the REN message handling described
   in section 2.3.4 for multiple agents.

2.3.14.  Policy Rule State Machine

   The state machine for the policy rule transactions is shown in Figure
   4 with all possible state transitions.  The used transaction
   abbreviations may be found in the headings of the particular
   transaction section.

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

                   Figure 4: Policy Rule State Machine

   This state machine exists per policy rule identifier (PRID).
   Initially, all policy rules are in state PRID UNUSED, which means
   that the policy rule does not exist or is not active.  After
   returning to state PRID UNUSED, the policy rule identifier is no
   longer bound to an existing policy rule and may be reused by the
   middlebox.

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

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

   A failed request transaction does not change state at the middlebox.

   Note that transitions initiated by RLC transactions may also be
   initiated by GLC transactions.

2.4.  Policy Rule Group Transactions

   This section describes the semantics for transactions on groups of
   policy rules.  These transactions are specified as follows:

      - Group Lifetime Change (GLC)
      - Group List (GL)
      - Group Status (GS)

   All are request transactions initiated by the agent.  GLC is a
   configuration transaction.  GL and GS are monitoring transactions
   that do not have any effect on the group state machine.

2.4.1.  Overview

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

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

   A group has a middlebox-unique identifier.

Top      Up      ToC       Page 44 
   Policy rule group transactions are declared as 'optional' by their
   respective compliance entry in section 3.  However, they provide some
   functionalities, such as convenience for the agent in sending only
   one request instead of several, that is not available if only
   mandatory transactions are available.

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

   The monitoring transactions Group List (GL) and Group Status (GS) can
   be used by the agent to explore the state of the middlebox and to
   explore its access rights.  The GL transaction lists all groups that
   the agent may access, including groups owned by other agents.  The GS
   transaction reports the status on an individual group and lists all
   policy rules of this group by their policy rule identifiers.  The
   agent can explore the state of the individual policy rules by using
   the policy rule identifiers in a policy rule status (PRS) transaction
   (see section 2.3.12).

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

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

2.4.2.  Group Lifetime Change (GLC)

   transaction-name: group lifetime change

   transaction-type: configuration

   transaction-compliance: optional

   request-parameters:

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

Top      Up      ToC       Page 45 
      - group identifier: A reference to the group for which the
        lifetime is requested to be changed.

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

   reply-parameters (success):

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

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

   failure reason:

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

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

   semantics:

      The agent can use this transaction type to request an extension of
      the lifetime of all members of a policy rule group, to request
      shortening the lifetime of all members, or to request termination
      of all member policies (which implies termination of the group).
      Termination is requested by suggesting a new group lifetime of
      zero.

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

      A failure reply implies that the lifetime of the group remains
      unchanged.  A success reply is generated by the middlebox if the
      lifetime of the group was changed in any way.

      The success reply contains the new common lifetime of all member
      policy rules of the group.  The middlebox chooses the new lifetime
      less than or equal to the minimum of the requested lifetime and
      the maximum lifetime that the middlebox specified at session setup
      along with its other capabilities, i.e.,

Top      Up      ToC       Page 46 
         0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)

      where
       - lt_granted is the lifetime actually granted by the middlebox
       - lt_requested is the lifetime the agent requested
       - lt_maximum is the maximum lifetime specified at session setup

   After sending a success reply with a lifetime of zero, the middlebox
   will terminate the member policy rules without any further
   notification to the agent, and will consider the group and all of its
   members non-existent.  Any further transaction on this policy rule
   group or on any of its members results in a negative reply,
   indicating that this group or policy rule, respectively, does not
   exist anymore.

   After the remaining policy rule group lifetime is successfully
   changed and the reply message has been sent to the requesting agent,
   the middlebox checks whether there are other authenticated agents
   participating in open sessions that can access the policy rule group.
   If the middlebox finds one or more of these agents, it sends a GEN
   message reporting the new remaining policy rule group lifetime to
   each of them.

2.4.3.  Group List (GL)

   transaction-name: group list

   transaction-type: monitoring

   transaction-compliance: optional

   request-parameters:

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

   reply-parameters (success):

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

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

   failure reason:

      - transaction not supported
      - agent not authorized for this transaction

Top      Up      ToC       Page 47 
   semantics:

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

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

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

2.4.4.  Group Status (GS)

   transaction-name: group status

   transaction-type: monitoring

   transaction-compliance: optional

   request-parameters:

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

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

   reply-parameters (success):

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

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

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

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

Top      Up      ToC       Page 48 
   failure reason:

      - transaction not supported
      - agent not authorized for this transaction
      - no such group
      - agent not authorized to list members of this group

   semantics:

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

      The middlebox first checks whether the specified group exists and
      whether the agent is authorized to access this group.  If one of
      the checks fails, an appropriate failure reply is generated.
      Otherwise, a list of all group members is returned indicating the
      identifier of each group.

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



(page 48 continued on part 3)

Next RFC Part