RFC 4540
NEC's Simple Middlebox Configuration (SIMCO) Protocol Version 3.0
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 request5.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 structure5.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.
+--------------------------+ | SIMCO header | +--------------------------+ Figure 16: Protocol error negative reply structure5.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 notification5.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
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 reply5.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 reply5.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.
+--------------------------+ | SIMCO header | +--------------------------+ | authentication token | optional +--------------------------+ Figure 20: Structure of SA request5.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 reply5.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.
+--------------------------+ | SIMCO header | +--------------------------+ Figure 22b: Structure of SE negative replies5.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 notifications5.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
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
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 request5.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
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
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 request5.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 request5.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
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 reply5.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.
+--------------------------+ | SIMCO header | +--------------------------+ | policy rule identifier | +--------------------------+ | group identifier | +--------------------------+ | policy rule lifetime | +--------------------------+ | address tuple (outside) | +--------------------------+ | address tuple (inside) | +--------------------------+ Figure 31: Structure of PER positive reply5.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 reply5.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
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
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
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 reply3.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
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 reply5.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 replies5.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)
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 notification6. 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.
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.
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
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
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.
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.
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
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).
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.
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).
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
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)
