+--------------------------+
| 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 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
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)
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.
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