tech-invite   World Map     

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

RFC 4540

 
 
 

NEC's Simple Middlebox Configuration (SIMCO) Protocol Version 3.0

Part 2 of 3, p. 19 to 45
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 19 
5.  SIMCO Message Formats

   In the following, the formats of the different SIMCO message types
   are defined.  The definitions are grouped into protocol error
   messages, session control messages, and policy rule control messages.

5.1.  Protocol Error Replies and Notifications

   When processing a received message, the middlebox might run into
   message processing problems before it can identify whether the
   message concerns session control or policy rule control.  Also, it
   might not be possible to determine the message type, or it might
   detect a wrong message format.  In these cases, the Badly Formed
   Message (BFM) notification or one of the following negative replies
   is sent:

      0x0401  :  BFM notification
      0x0310  :  wrong basic request message type
      0x0311  :  wrong request message sub-type
      0x0312  :  badly formed request

5.1.1.  BFM Notification

   The Badly Formed Message (BFM) notification message is sent from the
   middlebox to the agent after a message was received that does not
   comply to the SIMCO message format definition.  The BFM notification
   has no attributes and contains the SIMCO header only.

                      +--------------------------+
                      | SIMCO header             |
                      +--------------------------+

                  Figure 15: BFM notification structure

5.1.2.  Protocol Error Negative Replies

   Protocol error negative replies are sent from the middlebox to the
   agent if a message cannot be clearly interpreted, as it does not
   comply with any defined message format.  Protocol error negative
   replies include 'wrong basic request message type' (0x0310), 'wrong
   request message sub-type' (0x0311), and 'badly formed request'
   (0x0312).  These replies have no attributes.  They consist of the
   SIMCO header only.

Top      Up      ToC       Page 20 
                      +--------------------------+
                      | SIMCO header             |
                      +--------------------------+

           Figure 16: Protocol error negative reply structure

5.2.  Session Control Messages

   Session control messages include the following list of message types
   (composed of basic type and sub-type):

      0x0101  :  SE request
      0x0102  :  SA request
      0x0103  :  ST request
      0x0201  :  SE positive reply
      0x0202  :  SA positive reply
      0x0203  :  ST positive reply
      0x0310  :  negative reply: wrong basic request message type
      0x0311  :  negative reply: wrong request message sub-type
      0x0312  :  negative reply: badly formed request
      0x0320  :  negative reply: request not applicable
      0x0321  :  negative reply: lack of resources
      0x0322  :  negative reply: protocol version mismatch
      0x0323  :  negative reply: authentication failed
      0x0324  :  negative reply: no authorization
      0x0325  :  negative reply: transport protocol problem
      0x0326  :  negative reply: security of underlying protocol layers
                                 insufficient
      0x0401  :  BFM notification
      0x0402  :  AST notification

5.2.1.  SE Request

   The Session Establishment (SE) request message is sent from the agent
   to the middlebox to request establishment of a session.  The SE
   request message contains one or two attributes: a mandatory SIMCO
   version number attribute and an optional authentication challenge
   attribute requesting that the middlebox authenticate itself.

                      +--------------------------+
                      | SIMCO header             |
                      +--------------------------+
                      | SIMCO protocol version   |
                      +--------------------------+
                      | authentication challenge | optional
                      +--------------------------+

                   Figure 17: Structure of SE request

Top      Up      ToC       Page 21 
5.2.2.  SE Positive Reply

   The Session Establishment (SE) reply message indicates completion of
   session establishment.  It contains a single mandatory attribute: the
   middlebox capabilities attribute.

                      +--------------------------+
                      | SIMCO header             |
                      +--------------------------+
                      | middlebox capabilities   |
                      +--------------------------+

                Figure 18: Structure of SE positive reply

5.2.3.  SA Positive Reply

   If the agent requested middlebox authentication, or if the middlebox
   wants the agent to authenticate itself, then the middlebox replies on
   the SE request with a Session Authentication (SA) reply message
   instead of an SE reply message.  The SA reply message contains two
   optional attributes, but at least one of them needs to be present.
   The first one is an authentication challenge attribute requesting
   that the agent authenticate itself.  The second one is an
   authentication token attribute authenticating the middlebox as the
   reply to an authentication request by the agent.

                      +--------------------------+
                      | SIMCO header             |
                      +--------------------------+
                      | authentication challenge | optional
                      +--------------------------+
                      | authentication token     | optional
                      +--------------------------+

                Figure 19: Structure of SA positive reply

5.2.4.  SA Request

   The Session Authentication (SA) request message is sent from the
   agent to the middlebox after an initial SE request was answered by an
   SA reply.  The SE request message contains one optional attribute: an
   authentication token attribute authenticating the agent as the
   response to an authentication challenge sent by the middlebox in an
   SA reply.

Top      Up      ToC       Page 22 
                      +--------------------------+
                      | SIMCO header             |
                      +--------------------------+
                      | authentication token     | optional
                      +--------------------------+

                   Figure 20: Structure of SA request

5.2.5.  ST Request and ST Positive Reply

   The Session Termination (ST) request message is sent from the agent
   to the middlebox to request termination of a session.  The ST
   positive reply is returned, acknowledging the session termination.
   Both messages have no attributes and contain the SIMCO header only.

                      +--------------------------+
                      | SIMCO header             |
                      +--------------------------+

           Figure 21: Structure of ST request and positive reply

5.2.6.  SE Negative Replies

   There are nine different negative reply messages that can be sent
   from a middlebox to the agent if the middlebox rejects an SE request.
   Three of them are protocol error negative replies (0x031X) already
   covered in Section 4.1.2.

   The remaining six negative replies are specific to session
   establishment.  One of them, the 'protocol version mismatch' negative
   reply (0x0322), contains a single attribute: the protocol version
   attribute.

                      +--------------------------+
                      | SIMCO header             |
                      +--------------------------+
                      | SIMCO protocol version   |
                      +--------------------------+

                Figure 22a: Structure of SE negative replies

   The remaining three replies include 'request not applicable'
   (0x0320), 'lack of resources' (0x0321), 'authentication failed'
   (0x0323), 'no authorization' (0x0324), 'transport protocol problem'
   (0x0325), and 'security of underlying protocol layers insufficient'
   (0x0326).  They consist of the SIMCO header only.

Top      Up      ToC       Page 23 
                      +--------------------------+
                      | SIMCO header             |
                      +--------------------------+

                Figure 22b: Structure of SE negative replies

5.2.7.  AST Notification

   The Asynchronous Session Termination (AST) notification message is
   sent from the middlebox to the agent, if the middlebox wants to
   terminate a SIMCO session.  It has no attributes and contains the
   SIMCO header only.

                      +--------------------------+
                      | SIMCO header             |
                      +--------------------------+

                Figure 22a: Structure of AST notifications

5.3.  Policy Rule Control Messages

   Policy Rule control messages include the following list of message
   types (composed of basic type and sub-type):

   0x0111  :  PRR request
   0x0112  :  PER request
   0x0113  :  PEA request
   0x0114  :  PDR request
   0x0115  :  PLC request
   0x0121  :  PRS request
   0x0122  :  PRL request
   0x0211  :  PRR positive reply
   0x0212  :  PER positive reply
   0x0214  :  PDR positive reply
   0x0215  :  PLC positive reply
   0x0216  :  PRD positive reply
   0x0221  :  PRS positive reply
   0x0223  :  PES positive reply
   0x0224  :  PDS positive reply
   0x0222  :  PRL positive reply
   0x0310  :  negative reply: wrong basic request message type
   0x0311  :  negative reply: wrong request message sub-type
   0x0312  :  negative reply: badly formed request
   0x0340  :  negative reply: transaction not supported
   0x0341  :  negative reply: agent not authorized for this transaction
   0x0342  :  negative reply: no resources available for this
                              transaction
   0x0343  :  negative reply: specified policy rule does not exist

Top      Up      ToC       Page 24 
   0x0344  :  negative reply: specified policy rule group does not exist
   0x0345  :  negative reply: not authorized for accessing this policy
   0x0346  :  negative reply: not authorized for accessing specified
                              group
   0x0347  :  negative reply: requested address space not available
   0x0348  :  negative reply: lack of IP addresses
   0x0349  :  negative reply: lack of port numbers
   0x034A  :  negative reply: middlebox configuration failed
   0x034B  :  negative reply: inconsistent request
   0x034C  :  negative reply: requested wildcarding not supported
   0x034D  :  negative reply: protocol type doesn't match
   0x034E  :  negative reply: NAT mode not supported
   0x034F  :  negative reply: IP version mismatch
   0x0350  :  negative reply: conflict with existing rule
   0x0351  :  negative reply: not authorized to change lifetime
   0x0352  :  negative reply: lifetime can't be extended
   0x0353  :  negative reply: illegal IP Address
   0x0354  :  negative reply: protocol type not supported
   0x0355  :  negative reply: illegal port number
   0x0356  :  negative reply: illegal NOSP
   0x0357  :  negative reply: already enable PID
   0x0358  :  negative reply: parity doesn't match
   0x0401  :  negative reply: BFM notification
   0x0403  :  negative reply: ARE notification

5.3.1.  Policy Events and Asynchronous Notifications

   SIMCO maintains an owner attribute for each policy rule at the
   middlebox.  Depending on the configuration of the middlebox, several
   agents may access the same policy rule; see also [RFC3989], Sections
   2.1.5 and 2.3.4.

   To keep all agents synchronized about the state of their policy
   rules, SIMCO generates Asynchronous Rule Event (ARE) notifications.
   When an agent is reserving or enabling a policy rule, the middlebox
   sends an ARE to all agents that are authorized to access this policy
   rule.  The middlebox sends an ARE to all agents authorized to access
   this policy rule when the rule lifetime is modified or if the rule is
   deleted.

5.3.2.  PRR Request

   The Policy Reserve Rule (PRR) request message is sent from the agent
   to the middlebox to request reservation of an IP address (and
   potentially also a range of port numbers) at the middlebox.  Besides
   the SIMCO header, the request message contains two or three
   attributes.  The first one is the PRR parameter set attribute
   specifying all parameters of the request except the requested policy

Top      Up      ToC       Page 25 
   rule lifetime and the group identifier.  The missing parameters are
   covered by the following two attributes.  The last attribute, the
   group identifier, is optional.

                      +--------------------------+
                      | SIMCO header             |
                      +--------------------------+
                      | PRR parameter set        |
                      +--------------------------+
                      | policy rule lifetime     |
                      +--------------------------+
                      | group identifier         | optional
                      +--------------------------+

                   Figure 23: Structure of PRR request

5.3.3.  PER Request

   The Policy Enable Rule (PER) request message is sent from the agent
   to the middlebox to request enabling of data communication between an
   internal and an external address.  Besides the SIMCO header, the
   request message contains four or five attributes.  The first one is
   the PER parameter set attribute specifying all parameters of the
   request except the internal address, the external address, the
   requested policy rule lifetime, and the group identifier.  The
   missing parameters are covered by the following four attributes.  Two
   address tuple parameters specify internal and external address
   tuples.  Much like the PRR request, the last two attributes specify
   the requested lifetime and group identifier.  The group identifier
   attribute is optional.

                      +--------------------------+
                      | SIMCO header             |
                      +--------------------------+
                      | PER parameter set        |
                      +--------------------------+
                      | address tuple (internal) |
                      +--------------------------+
                      | address tuple (external) |
                      +--------------------------+
                      | policy rule lifetime     |
                      +--------------------------+
                      | group identifier         | optional
                      +--------------------------+

                   Figure 24: Structure of PER request

Top      Up      ToC       Page 26 
5.3.4.  PEA Request

   The Policy Enable rule After reservation (PEA) request message is
   sent from the agent to the middlebox to request enabling of data
   communication between an internal and an external address.  It is
   similar to the PER request.  There is just one difference.  The
   optional group identifier attribute of the PER request is replaced by
   a mandatory policy rule identifier attribute referencing an already
   established policy reserve rule established by a PRR transaction.

                      +--------------------------+
                      | SIMCO header             |
                      +--------------------------+
                      | PER parameter set        |
                      +--------------------------+
                      | address tuple (internal) |
                      +--------------------------+
                      | address tuple (external) |
                      +--------------------------+
                      | policy rule lifetime     |
                      +--------------------------+
                      | policy rule identifier   |
                      +--------------------------+

                   Figure 25: Structure of PEA request

   The group identifier attribute is not included in the PEA request,
   since the group membership of the policy enable rule is inherited of
   the policy reserve rule.

5.3.5.  PLC Request

   The Policy Rule Lifetime Change (PLC) request message is sent from
   the agent to the middlebox to request a change of the remaining
   policy lifetime.  Besides the SIMCO header, the request message
   contains two attributes specifying the policy rule to which the
   change should be applied and specifying the requested remaining
   lifetime.

                      +--------------------------+
                      | SIMCO header             |
                      +--------------------------+
                      | policy rule identifier   |
                      +--------------------------+
                      | policy rule lifetime     |
                      +--------------------------+

                   Figure 26: Structure of PLC request

Top      Up      ToC       Page 27 
5.3.6.  PRS Request

   The Policy Rule Status (PRS) request message is sent from the agent
   to the middlebox to request a report on the status of a specified
   policy rule.  Besides the SIMCO header, the request message contains
   just one attribute specifying the policy rule for which the report is
   requested.

                      +--------------------------+
                      | SIMCO header             |
                      +--------------------------+
                      | policy rule identifier   |
                      +--------------------------+

                   Figure 27: Structure of PRS request

5.3.7.  PRL Request

   The Policy Rule List (PRL) request message is sent from the agent to
   the middlebox to request a list of all policy rules accessible to the
   agent.  The message consists of the SIMCO header only.

                      +--------------------------+
                      | SIMCO header             |
                      +--------------------------+

                   Figure 28: Structure of PRL request

5.3.8.  PDR Request

   The Policy Disable Rule (PDR) request message is sent from the agent
   to the middlebox to request a disable rule.  The message consists of
   the SIMCO header, an internal address tuple, an external address
   tuple, and a lifetime attribute.

                      +--------------------------+
                      | SIMCO header             |
                      +--------------------------+
                      | address tuple (internal) |
                      +--------------------------+
                      | address tuple (external) |
                      +--------------------------+
                      | policy rule lifetime     |
                      +--------------------------+

                   Figure 29: Structure of PDR request

Top      Up      ToC       Page 28 
5.3.9.  PRR Positive Reply

   The Policy Reserve Rule (PRR) positive reply is sent after successful
   reservation of an address at the inside or outside of the middlebox.
   The message contains four mandatory attributes and an optional
   attribute: the policy rule identifier of the new policy reserve rule,
   the corresponding group identifier, the remaining lifetime of the
   policy rule, the reserved outside address tuple, and the optional
   reserved inside address tuple.  The reserved inside address tuple is
   only returned when the middlebox is of type twice-NAT.

                      +--------------------------+
                      | SIMCO header             |
                      +--------------------------+
                      | policy rule identifier   |
                      +--------------------------+
                      | group identifier         |
                      +--------------------------+
                      | policy rule lifetime     |
                      +--------------------------+
                      | address tuple (outside)  |
                      +--------------------------+
                      | address tuple (inside)   | optional
                      +--------------------------+

               Figure 30: Structure of PRR positive reply

5.3.10.  PER Positive Reply

   The Policy Enable Rule (PER) positive reply is sent after the
   middlebox successfully enables data transfer between an internal and
   an external address (by using a PER or PEA request message).  The
   message contains five attributes: the policy rule identifier of the
   new policy enable rule, the corresponding group identifier, the
   remaining lifetime of the policy rule, the address tuple at the
   outside of the middlebox, and the address tuple at the inside of the
   middlebox.

Top      Up      ToC       Page 29 
                      +--------------------------+
                      | SIMCO header             |
                      +--------------------------+
                      | policy rule identifier   |
                      +--------------------------+
                      | group identifier         |
                      +--------------------------+
                      | policy rule lifetime     |
                      +--------------------------+
                      | address tuple (outside)  |
                      +--------------------------+
                      | address tuple (inside)   |
                      +--------------------------+

               Figure 31: Structure of PER positive reply

5.3.11.  PLC Positive Reply

   The Policy Lifetime Change (PLC) positive reply is sent after the
   middlebox changes the lifetime of a policy rule to a positive (non-
   zero) value.  The message contains just a single attribute: the
   remaining lifetime of the policy rule.

                      +--------------------------+
                      | SIMCO header             |
                      +--------------------------+
                      | policy rule lifetime     |
                      +--------------------------+

               Figure 32: Structure of PLC positive reply

5.3.12.  PRD Positive Reply

   The Policy Rule Deleted (PRD) positive reply is sent after the
   middlebox changes the remaining lifetime of a policy rule to zero,
   which means that it terminates the policy rule.  The message consists
   of the SIMCO header only.

                      +--------------------------+
                      | SIMCO header             |
                      +--------------------------+

               Figure 33: Structure of PRD positive reply

Top      Up      ToC       Page 30 
5.3.13.  PRS Positive Reply

   The Policy Reserve Rule Status (PRS) positive reply is used for
   reporting the status of a policy reserve rule.  The message format is
   identical with the format of the PRR positive reply except that it
   contains, in addition, a policy rule owner attribute.

                      +--------------------------+
                      | SIMCO header             |
                      +--------------------------+
                      | policy rule identifier   |
                      +--------------------------+
                      | group identifier         |
                      +--------------------------+
                      | policy rule lifetime     |
                      +--------------------------+
                      | address tuple (outside)  |
                      +--------------------------+
                      | address tuple (inside)   | optional
                      +--------------------------+
                      | policy rule owner        |
                      +--------------------------+

               Figure 34: Structure of PRS positive reply

Top      Up      ToC       Page 31 
5.3.14.  PES Positive Reply

   The Policy Enable Rule Status (PES) positive reply is used for
   reporting the status of a policy enable rule.

                      +--------------------------+
                      | SIMCO header             |
                      +--------------------------+
                      | policy rule identifier   |
                      +--------------------------+
                      | group identifier         |
                      +--------------------------+
                      | PER parameter set        |
                      +--------------------------+
                      | address tuple (internal) |
                      +--------------------------+
                      | address tuple (inside)   |
                      +--------------------------+
                      | address tuple (outside)  |
                      +--------------------------+
                      | address tuple (external) |
                      +--------------------------+
                      | policy rule lifetime     |
                      +--------------------------+
                      | policy rule owner        |
                      +--------------------------+

               Figure 35: Structure of PES positive reply

Top      Up      ToC       Page 32 
5.3.15.  PDS Positive Reply

   The Policy Disable Rule Status (PDS) positive reply is used for
   reporting the status of a policy disable rule.  The message contains
   five attributes:  the policy rule identifier, the internal and
   external address tuples, the policy disable rule lifetime, and the
   policy rule owner.

                      +--------------------------+
                      | SIMCO header             |
                      +--------------------------+
                      | policy rule identifier   |
                      +--------------------------+
                      | address tuple (internal) |
                      +--------------------------+
                      | address tuple (external) |
                      +--------------------------+
                      | policy rule lifetime     |
                      +--------------------------+
                      | policy rule owner        |
                      +--------------------------+

               Figure 36: Structure of PDS positive reply

3.5.16.  PRL Positive Reply

   The Policy Rule List (PRL) positive reply is used for reporting the
   list of all established policy rules.  The number of attributes of
   this message is variable.  The message contains one policy rule
   identifier attribute per established policy rule.

                      +--------------------------+
                      | SIMCO header             |
                      +--------------------------+
                      | policy rule identifier   |
                      +--------------------------+
                      | policy rule identifier   |
                      +--------------------------+
                      |                          |
                                . . .
                      |                          |
                      +--------------------------+
                      | policy rule identifier   |
                      +--------------------------+

               Figure 37: Structure of PRL positive reply

Top      Up      ToC       Page 33 
5.3.17.  PDR Positive Replies

   The Policy Disable Rule (PDR) positive reply is sent after the
   middlebox successfully enables the policy disable rule and removal of
   conflicting policy rules.  The message contains two attributes: the
   policy rule identifier of the new policy disable rule, and the
   remaining lifetime of the policy rule.

                      +--------------------------+
                      | SIMCO header             |
                      +--------------------------+
                      | policy rule identifier   |
                      +--------------------------+
                      | policy rule lifetime     |
                      +--------------------------+

                 Figure 38: Structure of PDR positive reply

5.3.18.  Policy Rule Control Negative Replies

   Session establishment negative replies are sent from the middlebox to
   the agent if a middlebox rejects a policy rule control request.
   Beyond protocol error replies, a number of policy rule control-
   specific negative reply messages that can be sent.  They are listed
   at the beginning of Section 5.3.  They all have no attributes.  They
   consist of the SIMCO header only.

                      +--------------------------+
                      | SIMCO header             |
                      +--------------------------+

       Figure 39: Structure of Policy rule control negative replies

5.3.19.  ARE Notification

   The Asynchronous Policy Rule Event (ARE) notification message is sent
   from the middlebox to the agent.  All agents participating in an open
   SIMCO session that are authorized to access this policy rule and are
   not explicitly requesting an action (i.e., reserving, enabling, and
   changing lifetime) receive such an ARE notification, when:

     - a policy rule is deleted (lifetime attribute = 0)

     - a policy rule is reserved (lifetime attribute = lifetime)

     - a policy rule is enabled (lifetime attribute = lifetime)

     - a policy rule's lifetime changed (lifetime attribute = lifetime)

Top      Up      ToC       Page 34 
   Besides the SIMCO header, the request message contains two attributes
   specifying the policy rule that is concerned and the current
   lifetime.

                      +--------------------------+
                      | SIMCO header             |
                      +--------------------------+
                      | policy rule identifier   |
                      +--------------------------+
                      | policy rule lifetime     |
                      +--------------------------+

                 Figure 40: Structure of ARE notification

6.  Message Format Checking

   This section describes common processing of all messages that are
   received by a middlebox.

   1) When a message arrives at a middlebox, the header is checked for
      consistency before the payload is processed.

      o  If the header checks fail, the middlebox sends a BFM
         notification.

      o  If a session is already established, then the middlebox also
         sends an AST notification and closes the connection.

   2) The middlebox waits until it has received as many octets from the
      agent as specified by the message length plus 8 octets (the length
      of the SIMCO header).

      o  If the middlebox is still waiting and does not receive any more
         octets from the agent for 60 seconds, it sends a BFM
         notification.

      o  If a session is already established, then the middlebox also
         sends an AST notification and closes the connection after
         sending the BFM notification; otherwise, it closes the
         connection without sending another message.

   3) After receiving a sufficient number of octets, the middlebox reads
      the transaction identifier and the basic message type.

      o  If the value of the basic message type fields does not equal
         0x01 (request message), then the middlebox stops processing the
         message and sends a negative reply of type 'wrong basic request
         message type' (0x0310) to the agent.

Top      Up      ToC       Page 35 
      o  If no session is established, then the middlebox closes the
         connection after sending the 0x0310 reply.

   4) Then the middlebox checks the message sub-type.

      o  If no session is established, then only sub-type 'session
         establishment' (0x01) is accepted.  For all other sub-types,
         the middlebox sends a reply of type 'wrong request message
         sub-type' (0x0311) to the agent and closes the connection after
         sending the reply.

      o  If a session is already established, then the middlebox checks
         if the message sub-type is one of the sub-types defined in
         Section 4.2.2. (excluding 'session establishment' (0x01),
         'session termination' (0x03), and 'policy rule
         deletion'(0x15)).

         o  If not, then the middlebox stops processing the message and
            sends a reply of type 'wrong request message sub-type'
            (0x0311) to the agent.

   5) Then the middlebox checks the TLV-structured attributes in the
      message.

      o  If their type or number does not comply with the defined format
         for this message type, the middlebox stops processing the
         message and sends a reply of type 'badly formed request'
         (0x0312) to the agent.

      o  If no session is established, then the middlebox closes the
         connection after sending the 0x0312 reply.

   6) After all message format checks are passed, the middlebox
      processes the content of the attributes as described in the
      following sections.

Top      Up      ToC       Page 36 
7.  Session Control Message Processing

   For session control, the agent can send SE, SA, and ST request
   messages.  The middlebox then sends per request a single reply back
   to the agent.  Additionally, the middlebox may send unsolicited AST
   notifications.

7.1.  Session State Machine

   For each session, there is a session state machine illustrated by the
   figure below.

                  SE/BFM
                  SE/0x031X
                  SE/0x032X
                  +-------+
                  |       v
                 +----------+
                 |  CLOSED  |----------------+
                 +----------+                |
                    |   ^  ^                 |
                    |   |  | SA/BFM          | SE/SA
                    |   |  | SA/0x031X       |
                    |   |  | SA/0x032X       |
              SE/SE |   |  | ST/ST           v
                    |   |  | AST        +----------+
                    |   |  +------------|  NOAUTH  |
                    |   |               +----------+
                    |   | AST                |
                    v   | ST/ST              | SA/SE
                 +----------+                |
                 |   OPEN   |<---------------+
                 +----------+

                Figure 41: Session state machine

   The figure illustrates all possible state transitions of a session.
   Request transactions (SE, SA, ST) are denoted by a descriptor of the
   request message, a '/' symbol, and a descriptor of the reply message.
   Notification transactions are denoted just by the a notification
   descriptor.  For example, a successful SE transaction is denoted by
   'SE/SE', and an AST notification is denoted by 'AST'.

   Initially, all sessions are in state CLOSED.  From there, a
   successful SE transaction can change its state either to NOAUTH or to
   OPEN.  From state NOAUTH, a successful SA transaction changes session
   state to OPEN.  A failed SA transaction changes session state from

Top      Up      ToC       Page 37 
   NOAUTH back to CLOSED.  Successful ST transactions and AST
   notifications change sessions from state NOAUTH or from state OPEN to
   state CLOSED.

   A SIMCO session is established in state OPEN, which is the only state
   in which the middlebox accepts requests other than SE, SA, and ST.

7.2.  Processing SE Requests

   The SE request is only applicable if the session is in state CLOSED.
   If a session is in state NOAUTH or OPEN, then the middlebox sends a
   negative reply message of type 'request not applicable' (0x0320) to
   the agent, leaving the state of the session unchanged.

   Before processing the content of the SE request message, the
   middlebox may check its resources and decide that available resources
   are not sufficient to serve the agent.  In such a case, the middlebox
   returns a negative reply of type 'lack of resources' (0x0321) and
   closes the connection.  Furthermore, the middlebox may decide to
   reject the SE request if the selected network connection and its
   protocol specific parameters are not acceptable for the middlebox.
   In such a case, the middlebox returns a negative reply of type
   'transport protocol problem' (0x0325) and closes the connection.  The
   middlebox returns a negative reply of type 'security of underlying
   protocol layers insufficient' (0x0326) and closes the connection, if
   the security properties of the network connection do not match the
   middlebox's requirements.

   Processing of an SE request message starts with checking the major
   and minor protocol version number in the protocol version attribute.
   If the middlebox does not support the specified version number, then
   the middlebox returns a negative reply message of type 'protocol
   version mismatch' (0x0322) with the protocol version attribute
   indicating a version number that is supported by the middlebox.
   After sending this reply, the middlebox closes the connection.

   If the agent is already sufficiently authenticated by means of the
   underlying network connection (for instance, IPsec or TLS), then the
   middlebox checks whether the agent is authorized to configure the
   middlebox.  If it is not, the middlebox returns a negative reply of
   type 'no authorization' (0x0324) and closes the connection.

   A positive reply on the SE request may be of sub-type SE or SA.  An
   SE request is sent after both parties sufficiently authenticate and
   authorize each other.  An SA reply message is sent if explicit
   authentication is requested by any party.  The agent requests
   explicit authentication by adding an authentication challenge
   attribute to the SE request message.  The middlebox requests explicit

Top      Up      ToC       Page 38 
   authentication by returning an SA reply message with an
   authentication challenge attribute to the agent.  If both parties
   request explicit authentication, then the SA reply message contains
   both an authentication challenge attribute for the agent and an
   authentication token attribute authenticating the middlebox.

   If the SE request message contains an authentication challenge
   attribute, then the middlebox checks if it can authenticate itself.
   If yes, it adds a corresponding authentication token attribute to the
   SA reply.  If it cannot authenticate based on the authentication
   challenge attribute, it adds an authentication token attribute to the
   SA reply message with a value field of length zero.

   If the middlebox wants the agent to explicitly authenticate itself,
   then the middlebox creates an authentication challenge attribute for
   the agent and adds it to the SA reply message.

   If the middlebox replies to the SE request message with an SA reply
   message, then the session state changes from CLOSED to NO_AUTH.

   If the SE request message did not contain an authentication challenge
   attribute and if the middlebox does not request the agent to
   explicitly authenticate itself, then the middlebox sends an SE reply
   message in response to the SE request message.  This implies that the
   session state changes from CLOSED to OPEN.

   The SE reply message contains a capabilities attribute describing the
   middlebox capabilities.

7.3.  Processing SA Requests

   The SA request is only applicable if the session is in state NOAUTH.
   If a session is in state CLOSED or OPEN, then the middlebox sends a
   negative reply message of type 'request not applicable' (0x0320) to
   the agent.  The state of the session remains unchanged.

   After receiving an SA request message in state NOAUTH, the middlebox
   checks if the agent is sufficiently authenticated.  Authentication
   may be based on an authentication token attribute that is optionally
   contained in the SA request message.  If the agent is not
   sufficiently authenticated, then the middlebox returns a negative
   reply of type 'authentication failed' (0x0323) and closes the
   connection.

   If authentication of the agent is successful, the middlebox checks if
   the agent is authorized to configure the middlebox.  If not, the
   middlebox returns a negative reply of type 'no authorization'
   (0x0324) and closes the connection.

Top      Up      ToC       Page 39 
   If authorization is successful, then the session state changes from
   NOAUTH to OPEN, and the agent returns an SE reply message that
   concludes session setup.  The middlebox states its capabilities in
   the capability attribute contained in the SE reply message.

7.4.  Processing ST Requests

   The ST request is only applicable if the session is in state NOAUTH
   or OPEN.  If a session is in state CLOSED, then the middlebox sends a
   negative reply message of type 'request not applicable' (0x0320) to
   the agent.  The state of the session remains unchanged.

   The middlebox always replies to a correct ST request with a positive
   ST reply.  The state of the session changes from OPEN or from NOAUTH
   to CLOSED.  After sending the ST reply, the middlebox closes the
   connection.  Requests received after receiving the ST request and
   before closing the connection are ignored by the middlebox.

7.5.  Generating AST Notifications

   At any time, the middlebox may terminate an established session and
   change the session state from OPEN or from NOAUTH to CLOSED.  Session
   termination is indicated to the agent by sending an AST notification.

   Before sending the notification, the middlebox ensures that for all
   requests that have been processed, according replies are returned to
   the agent, such that the agent exactly knows the state of the
   middlebox at the time of session termination.  After sending the AST
   notification, the middlebox sends no more messages to the agent, and
   it closes the connection.

7.6.  Session Termination by Interruption of Connection

   Section 2.2.4 of [RFC3989] describes the session behavior when the
   network connection is interrupted.  The behavior is defined for the
   middlebox (i.e., the SIMCO server) only and does not consider the
   behavior of the SIMCO agent in such an event.

   If the SIMCO agent detects an interruption of the underlying network
   connection, it can terminate the session.  The detection of the
   interrupted network connection can be done by several means, for
   instance, feedback of the operating system or a connection timeout.
   The definition of this detection mechanism is out of the scope of
   this memo.

Top      Up      ToC       Page 40 
8.  Policy Rule Control Message Processing

   For policy rule control and monitoring, the agent can send the PRR,
   PER, PEA, PLC, PRS, and PRL requests.  The middlebox then sends a
   single reply message per request message back to the agent.
   Additionally, the middlebox may send unsolicited ARE notifications at
   any time.

   The transaction semantics of policy rule control messages is
   explained in detail in [RFC3989], Section 2.3.

   For examples about protocol operation, see Section 4 of [RFC3989].

8.1.  Policy Rule State Machine

   Policy rules are established by successful PRR, PEA, or PER
   transactions.  Each time a policy rule is created, an unused policy
   rule identifier (PID) is assigned to the new policy rule.  For each
   policy rule identifier, a state machine exists at the middlebox.  The
   state machine is illustrated by the figure below.

                        PRR/PRR       +---------------+
          +----+    +-----------------+  PID UNUSED   |<-+
          |    |    |                 +---------------+  |
          |    v    v        PLC(lt=0)/ ^   |            |
          |  +-------------+    PRD     |   | PER/PER    | ARE(lt=0)
          |  |   RESERVED  +------------+   |            | PLC(lt=0)/
          |  +-+----+------+  ARE(lt=0)     v            |    PRD
          |    |    |                 +---------------+  |
          +----+    +---------------->|    ENABLED    +--+
        PLC(lt>0)/    PEA/PER         +-+-------------+
           PLC                          |           ^
                                        +-----------+
              lt = lifetime             PLC(lt>0)/PLC


                Figure 42: Policy rule state machine

   The figure illustrates all possible state transitions of a PID and
   its associated policy.  Successful configuration request transactions
   (PER, PRR, PEA, PLC) are denoted by a descriptor of the request
   message, a '/' symbol, and a descriptor of the reply message.  Failed
   configuration request transactions are not displayed, because they do
   not change the PID state.  Notification transactions are denoted just
   by the a notification descriptor.  For example, a successful PRR
   request transaction is denoted by 'PRR/PRR', and an ARE notification

Top      Up      ToC       Page 41 
   is denoted by 'ARE'.  For PLC request transactions, the descriptor
   for the request message is extended by an indication of the value of
   the lifetime parameter contained in the message.

   A successful PRR transaction (PRR/PRR) picks a PID in state UNUSED
   and changes the state to RESERVED.  A successful PER transitions
   picks a PID in state UNUSED and changes the state to ENABLED.  A PID
   in state RESERVED is changed to ENABLED by a successful PEA
   transaction.  In state RESERVED or UNUSED, a successful PLC
   transaction with a lifetime parameter greater than zero does not
   change the PID's state.  A successful PLC transaction with a lifetime
   parameter equal to zero changes the state of a PID from RESERVED to
   UNUSED or from ENABLED to UNUSED.

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

   An ARE notification transaction with the lifetime attribute set to
   zero has the same effect as a successful PLC transaction with a
   lifetime parameter equal to zero.

8.2.  Processing PRR Requests

   Processing PRR requests is much simpler on pure firewalls than on
   middleboxes with NAT functions.  Therefore, this section has three
   sub-sections: The first one describes initial checks that are
   performed in any case.  The second sub-section describes processing
   of PRR requests on pure firewalls, and the third one describes
   processing on all devices with NAT functions.

8.2.1.  Initial Checks

   When a middlebox receives a PRR request message, it first checks if
   the authenticated agent is authorized for requesting reservations.
   If not, it returns a negative reply message of type 'agent not
   authorized for this transaction' (0x0341).

   If the request contains the optional group identifier, then the
   middlebox checks if the group already exists.  If not, the middlebox
   returns a negative reply message of type 'specified policy rule group
   does not exist' (0x0344).

   If the request contains the optional group identifier, then the
   middlebox checks if the authenticated agent is authorized for adding
   members to this group.  If not, the middlebox returns a negative
   reply message of type 'not authorized for accessing specified group'
   (0x0346).

Top      Up      ToC       Page 42 
   The middlebox may then check the PRR parameter set.  A negative reply
   of type 'IP version mismatch' (0x034F) is returned if the IPi field
   does not match the inside IP version of the address at the middlebox.
   A negative reply of type 'IP version mismatch' (0x034F) is returned
   if the IPo field does not match the outside IP version of the address
   at the middlebox.  The requested transport protocol type is checked,
   and a negative reply of type 'protocol type not supported' (0x0354)
   is returned if it is not supported.  The middlebox may return a
   negative reply of type 'requested address space not available'
   (0x0347) if the requested address space is completely blocked or not
   supported by the middlebox in any way; for example, if a UDP port
   number is requested and all UDP packets are blocked by a middlebox
   acting as firewall.

   The latter check at the middlebox is optional.  If the check would
   fail and is not performed at this transaction, then two superfluous
   transactions will follow.  First, the agent will send a request
   message for a corresponding PER transaction and will receive a
   negative reply on this.  Second, either the agent will send a
   corresponding PLC request message with lifetime set to zero in order
   to delete the reservation, or the reservation will time out and the
   middlebox will send an ARE notification message with the lifetime
   attribute set to zero.  Both transactions can be avoided if the
   middlebox initially performs this check.

   A reason for avoiding this check might be its complexity.  If the
   check is passed, the same check will have to be performed again for a
   subsequent corresponding PEA request.  If processing two more
   transactions is considered to consume less resources than performing
   the check twice, it might be desirable not to perform it during the
   PRR transaction.

   After checking the PRR parameter set, the middlebox chooses a
   lifetime value for the new policy rule to be created, which is
   greater than or equal to zero and less than or equal to the minimum
   of the requested value and the maximum lifetime specified by the
   middlebox capabilities attribute at session setup.  Formally, the
   lifetime is chosen such that

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

   holds, where 'lt_granted' is the actual lifetime chosen by the
   middlebox, 'lt_requested' is the lifetime requested by the agent, and
   'lt_maximum' is the maximum lifetime specified during capability
   exchange at session setup.

Top      Up      ToC       Page 43 
   If there are further sessions in state OPEN with authenticated agents
   authorized to access the policy rule, then to each of these agents a
   corresponding ARE notification with lifetime set to lt_granted is
   sent.

   If the chosen lifetime is zero, the middlebox sends a negative reply
   of type 'middlebox configuration failed' (0x034A) to the agent.


8.2.2.  Processing on Pure Firewalls

   If the middlebox is configured as a pure firewall, then it accepts
   the request after the initial checks.  It establishes a new policy
   reserve rule and assigns to it a policy rule identifier in state
   RESERVED.  It generates a positive PRR reply and sets the attributes
   as specified below.  No configuration of the firewall function is
   required.

   The identifier chosen for the new policy rule is reported in the
   policy rule identifier attribute of the PRR reply.

   If a group identifier attribute is contained in the PRR request, then
   the middlebox adds the new policy rule to the members of this group.
   If the PRR request does not contain a group identifier attribute,
   then the middlebox creates a new group with the new policy rule as
   the only member.  In any case, the middlebox reports the group of
   which the new policy rule is a member in the group identifier
   attribute of the PRR reply.

   The chosen lifetime is reported in the lifetime attribute of the PRR
   reply.

   In the address tuple (outside) attribute of the PRR reply, the first
   parameter field is set to 'protocols only' (0x1).  Consequently, the
   attribute has a length of 32 bits.  The IP version parameter field is
   set according to the IPo parameter field in the PRR parameter set
   attribute of the PRR request message.  The prefix length parameter
   field is set to 0x00, and the transport protocol parameter field in
   the address tuple (outside) attribute of the PRR reply is set
   identically to the transport protocol attribute in the PRR parameter
   set attribute of the PRR request message.  The location parameter
   field is set to 'outside' (0x02).

Top      Up      ToC       Page 44 
8.2.3.  Processing on Network Address Translators

   If the middlebox is configured as a Network Address Translator (NAT),
   then it tries to reserve a NAT binding.

   The middlebox first checks the PRR parameter set further if the NM
   (NAT mode) parameter matches its configuration.  A negative reply of
   type 'NAT mode not supported' (0x034E) is returned by the middlebox
   if the configuration is not matched.

   The following actions are performed, depending on the middlebox NAT
   type:

     - traditional NAT
       A NAT binding at the outside (A2) with the requested transport
       protocol, external IP version, port range, and port parity is
       reserved.

     - twice NAT
       A NAT binding at the outside (A2) with the requested transport
       protocol, external IP version, port range, and port parity is
       reserved.  Furthermore, the middlebox reserves an inside (A1) NAT
       binding with the requested transport protocol, internal IP
       version, port range, and port parity.

   The identifier chosen for the new policy rule is reported in the
   policy rule identifier attribute of the PRR reply.

   After the checks are successfully performed, the middlebox
   establishes a new policy reserve rule, with the requested PRR
   parameter set, and assigns to it a policy rule identifier in state
   RESERVED.  It generates a positive PRR reply and sets the attributes
   as specified below.

   If a group identifier attribute is contained in the PRR request, then
   the middlebox adds the new policy rule to the members of this group.
   If the PRR request does not contain a group identifier attribute,
   then the middlebox creates a new group with the new policy rule as
   the only member.  In any case, the middlebox reports the group of
   which the new policy rule is a member in the group identifier
   attribute of the PRR reply.

   The chosen lifetime is reported in the lifetime attribute of the PRR
   reply.

   In the address tuple (outside) attribute of the PRR reply, the first
   parameter field is set to 'full addresses' (0x0).  The location
   parameter field is set to 'outside' (0x02).  The IP version parameter

Top      Up      ToC       Page 45 
   field is set according to the IPo parameter field in the PRR
   parameter set attribute of the PRR request message.  For IPv4
   addresses, the prefix length field is set to 0x20 to indicate a full
   address, and the reserved outside IPv4 address is set in the address
   field.  For IPv6 addresses, the prefix length field is set to 0x80 to
   indicate a full address, and the reserved outside IPv6 address is set
   in the address field.  The transport protocol parameter field in the
   address tuple (outside) attribute of the PRR reply is set identically
   to the transport protocol attribute in the PRR parameter set
   attribute of the PRR request message.  The reserved outside base port
   number (i.e., the lowest port number of the allocated range) is
   stored in the port number parameter field, and the allocated port
   range is stored in the port range parameter field.

   If the NM (NAT mode) parameter in the PRR parameter set attribute of
   the PRR request message has the value 'traditional', then the PRR
   reply message does not contain an address tuple (inside) attribute.
   If otherwise (it has the value 'twice'), then the PRR reply message
   contains an address tuple (inside) attribute.  In the address tuple
   (inside) attribute of the PRR reply, the first parameter field is set
   to 'full addresses' (0x0).  The location parameter field is set to
   'inside' (0x01).  The IP version parameter field is set according to
   the IPi parameter field in the PRR parameter set attribute of the PRR
   request message.  For IPv4 addresses, the prefix length field is set
   to 0x20 to indicate a full address, and the reserved inside IPv4
   address is set in the address field.  For IPv6 addresses, the prefix
   length field is set to 0x80 to indicate a full address, and the
   reserved inside IPv6 address is set in the address field.  The
   transport protocol parameter field in the address tuple (inside)
   attribute of the PRR reply is set identically to the transport
   protocol attribute in the PRR parameter set attribute of the PRR
   request message.  The reserved inside base port number (i.e., the
   lowest port number of the allocated range) is stored in the port
   number parameter field, and the allocated port range is stored in the
   port range parameter field.



(page 45 continued on part 3)

Next RFC Part