Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4540

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

Pages: 67
Experimental
Updated by:  8996
Part 2 of 3 – Pages 19 to 45
First   Prev   Next

Top   ToC   RFC4540 - Page 19   prevText

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   ToC   RFC4540 - 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   ToC   RFC4540 - 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   ToC   RFC4540 - 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   ToC   RFC4540 - 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   ToC   RFC4540 - 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   ToC   RFC4540 - 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   ToC   RFC4540 - 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   ToC   RFC4540 - 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   ToC   RFC4540 - 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   ToC   RFC4540 - 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   ToC   RFC4540 - 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   ToC   RFC4540 - 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   ToC   RFC4540 - 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   ToC   RFC4540 - 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   ToC   RFC4540 - 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   ToC   RFC4540 - 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   ToC   RFC4540 - 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   ToC   RFC4540 - 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   ToC   RFC4540 - 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   ToC   RFC4540 - 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   ToC   RFC4540 - 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   ToC   RFC4540 - 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   ToC   RFC4540 - 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   ToC   RFC4540 - 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   ToC   RFC4540 - 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   ToC   RFC4540 - 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 Section