Convenience transactions simplify MIDCOM sessions by combining a set
of configuration transactions into a single one. They are not
necessary for MIDCOM protocol operation.
As specified in detail in section 3, configuration transactions and
asynchronous transactions are mandatory. They must be implemented by
a compliant middlebox. All convenience transactions are optional,
and some of the monitoring transactions are optional.
2.1.2. Message Types
The MIDCOM protocol supports three kinds of messages: request
messages, reply messages, and notification messages. For each kind,
different message types exist. In this semantics document, message
types are only defined by the list of parameters. The order of the
parameters and their encoding is left to a concrete protocol
definition. A protocol definition may also add further parameters to
a message type or combine several parameters into one, as long as the
information contained in the parameters defined in the semantics is
still present.
For request messages and positive reply messages there exists one
message type per request transaction. Each reply transaction defines
the parameter list of the request message and of the positive
(successful) reply message by using the transaction definition
template defined in section 1.2.
In case of a failed request transaction, a negative reply message is
sent from the middlebox to the agent. This message is the same for
all request transactions; it contains the request identifier
identifying the request to which the reply is sent and a parameter
indicating the failure reason.
There are three notification message types: the Session Termination
Notification (STN), the Policy Rule Event Notification (REN), and the
Group Event Notification (GEN). All of these contain a middlebox-
unique notification identifier.
STN The Session Termination Notification message additionally
contains a single parameter indicating the reason for session
termination by the middlebox.
REN The Policy Rule Event Notification message contains the
notification identifier, a policy rule identifier, and the
remaining policy lifetime.
GEN The Group Event Notification message contains the notification
identifier, a policy rule group identifier, and the remaining
policy rule group lifetime.
2.1.3. Session, Policy Rule, and Policy Rule Group
All transactions can be further grouped into transactions concerning
sessions, transactions concerning policy rules, and transactions
concerning policy rule groups. Policy rule groups can be used to
indicate relationships between policy rules and to simplify
transactions on a set of policy rules by using a single transaction
per group instead of one per policy rule.
Sessions and policy rules at the middlebox are stateful. Their
states are independent of each other, and their state machines (one
per session and one per policy rule) can be separated. Policy rule
groups are also stateful, but the middlebox does not need to maintain
state for policy rule groups, because the semantics were chosen so
that the policy rule group state is implicitly defined by the state
of all policy rules belonging to the group (see section 2.4).
The separation of session state and policy rule state simplifies the
specification of the semantics as well as a protocol implementation.
Therefore, the semantics specification is structured accordingly and
we use two separated state machines to illustrate the semantics.
Please note that state machines of concrete protocol designs and
implementations will probably be more complex than the state machines
presented here. However, the protocol state machines are expected to
be a superset of the semantics state machines in this document.
2.1.4. Atomicity
All request transactions are atomic with respect to each other. This
means that processing of a request at the middlebox is never
interrupted by another request arriving or already queued. This
particularly applies when the middlebox concurrently receives
requests originating in different sessions. However, asynchronous
transactions may interrupt and/or terminate processing of a request
at any time.
All request transactions are atomic from the point of view of the
agent. The processing of a request does not start before the
complete request arrives at the middlebox. No intermediate state is
stable at the middlebox, and no intermediate state is reported to any
agent.
The number of transactions specified in this document is rather
small. Again, for simplicity, we reduced it to a minimal set that
still meets the requirements. A real implementation of the protocol
might require splitting some of the transactions specified below into
two or more transactions of the respective protocol. Reasons for
this might include constraints of the particular protocol or the
desire for more flexibility. In general this should not be a
problem. However, it should be considered that this might change
atomicity of the affected transactions.
2.1.5. Access Control
Ownership determines access to policy rules and policy rule groups.
When a policy rule is created, a middlebox-unique identifier is
generated to identify it in further transactions. Beyond the
identifier, each policy rule has an owner. The owner is the
authenticated agent that established the policy rule. The middlebox
uses the owner attribute of a policy rule to control access to it;
each time an authenticated agent requests to modify an existing
policy rule, the middlebox determines the owner of the policy rule
and checks whether the requesting agent is authorized to perform
transactions on the owning agent’s policy rules.
All policy rules belonging to the same policy rule group must have
the same owner. Therefore, authenticated agents have access either
to all members of a policy rule group, or to none of them.
The middlebox may be configured to allow specific authenticated
agents to access and modify policy rules with certain specific
owners. Certainly, a reasonable default configuration would let each
agent access its own policy rules. Also, it might be good to
configure an agent identity to act as administrator, allowing
modification of all policy rules owned by any agent. However, the
configuration of authorization at the middlebox is out of scope of
the MIDCOM semantics and protocol.
2.1.6. Middlebox Capabilities
For several reasons it is useful that at session establishment the
agent learns about particular capabilities of the middlebox.
Therefore, the session establishment procedure described in section
2.2.1 includes a transfer of capability information from the
middlebox to the agent. The list of covered middlebox capabilities
includes the following:
- Support of firewall function
- List of supported NAT functions, perhaps including
- address translation
- port translation
- protocol translation
- twice-NAT
- Internal IP address wildcard support
- External IP address wildcard support
- Port wildcard support
- Supported IP version(s) for internal network:
IPv4, IPv6, or both
- Supported IP version(s) for external network:
IPv4, IPv6, or both
- List of supported optional MIDCOM protocol transactions
- Optional interface-specific policy rule support: not
supported or supported
- Policy rule persistence: persistent or non-persistent
(a rule is persistent when the middlebox can save the rule to
a non-volatile memory, e.g., a hard disk or flash memory)
- Maximum remaining lifetime of a policy rule or policy rule
group
- Idle-timeout of policy rules in the middlebox
(reserved and enabled policy rules not used by any
data traffic for the time of this idle-timeout are deleted
automatically by the middlebox; for the deletion of policy
rules by middleboxes, see section 2.3.13 about Asynchronous
Policy Rule Event).
- Maximum number of simultaneous MIDCOM sessions
The list of middlebox capabilities may be extended by a concrete
protocol specification with further information useful for the agent.
2.1.7. Agent and Middlebox Identifiers
To allow both agents and middleboxes to maintain multiple sessions,
each request message contains a parameter identifying the requesting
agent, and each reply message and each notification message contains
a parameter identifying the middlebox. These parameters are not
explicitly listed in the description of the individual transactions,
because they are common to all of them. They are not further
referenced in the individual semantics descriptions. Although, they
are not necessarily passed explicitly as parameters of the MIDCOM
protocol, they might be provided by the underlying (secure) transport
protocol being used. Agent identifiers at the middlebox are
middlebox-unique, and middlebox identifiers at the agent are agent-
unique, respectively.
2.1.8. Conformance
The MIDCOM requirements in [MDC-REQ] demand capabilities of the
MIDCOM protocol that are met by the set of transactions specified
below. However, an actual implementation of a middlebox may support
only a subset of these transactions. The set of announced supported
transactions may be different for different authenticated agents.
The middlebox informs the authenticated agent with the capability
exchange at session establishment about the transactions that the
agent is authorized to perform. Some transactions need to be offered
to every authenticated agent.
Each transaction definition below has a conformance entry that
contains either ’mandatory’ or ’optional’. A mandatory transaction
needs to be implemented by every middlebox offering MIDCOM service
and must be must be offered to each of the authenticated agents. An
optional transaction does not necessarily need to be implemented by a
middlebox; it may offer these optional transactions only to certain
authenticated agents. The middlebox may offer one, several, all, or
no optional transactions to the agents. Whether an agent is allowed
to use an optional request transaction is determined by the
middlebox’s authorization procedure, which is not further specified
by this document.
2.2. Session Control Transactions
Before any transaction on policy rules or policy rule groups is
possible, a valid MIDCOM session must be established. A MIDCOM
session is an authenticated and authorized association between agent
and middlebox. Sessions are initiated by agents and can be
terminated by either the agent or the middlebox. Both agent and
middlebox may participate in several sessions (with different
entities) at the same time. To distinguish different sessions, each
party uses local session identifiers.
All transactions are transmitted within this MIDCOM session.
Session control is supported by three transactions:
- Session Establishment (SE)
- Session Termination (ST)
- Asynchronous Session Termination (AST)
The first two are configuration transactions initiated by the agent,
and the last one is an asynchronous transaction initiated by the
middlebox.
2.2.1. Session Establishment (SE)
transaction-name: session establishment
transaction-type: configuration
transaction-compliance: mandatory
request-parameters:
- request identifier: An agent-unique identifier for matching
corresponding request and reply at the agent.
- version: The version of the MIDCOM protocol.
- middlebox authentication challenge (mc): An authentication
challenge token for authentication of the middlebox. As seen
below, this is present only in the first iteration of the
request.
- agent authentication (aa): An authentication token
authenticating the agent to the middlebox. As seen below, this
is updated in the second iteration of the request with material
responding to the middlebox challenge.
reply-parameters (success):
- request identifier: An identifier matching the identifier
request.
- middlebox authentication (ma): An authentication token
authenticating the middlebox to the agent.
- agent challenge token (ac): An authentication challenge token
for the agent authentication.
- middlebox capabilities: A list describing the middlebox’s
capabilities. See section 2.1.6 for the list of middlebox
capabilities.
failure reason:
- authentication failed
- no authorization
- protocol version of agent and middlebox do not match
- lack of resources
semantics:
This session establishment transaction is used to establish a
MIDCOM session. For mutual authentication of both parties two
subsequent session establishment transactions are required as
shown in Figure 1.
agent middlebox
| session establishment request |
| (with middlebox challenge mc) | CLOSED
|-------------------------------------------->|
| |
| successful reply (with middlebox |
| authentication ma and agent challenge ac) |
|<--------------------------------------------|
| | NOAUTH
| session establishment request |
| (with agent authentication aa) |
|-------------------------------------------->|
| |
| successful reply |
|<--------------------------------------------|
| | OPEN
| |
Figure 1: Mutual authentication of agent and middlebox
Session establishment may be simplified by using only a single
transaction. In this case, server challenge and agent challenge
are omitted by the sender or ignored by the receiver, and
authentication must be provided by other means, for example by TLS
[RFC2246] or IPsec [RFC2402][RFC2406].
The middlebox checks with its policy decision point whether the
requesting agent is authorized to open a MIDCOM session. If it is
not, the middlebox generates a negative reply with ’no
authorization’ as failure reason. If authentication and
authorization are successful, the session is established, and the
agent may start with requesting transactions on policy rules and
policy rule groups.
Part of the successful reply is an indication of the middlebox’s
capabilities.
2.2.2. Session Termination (ST)
transaction-name: session termination
transaction-type: configuration
transaction-compliance: mandatory
request-parameters:
- request identifier: An agent-unique identifier for matching
corresponding request and reply at the agent.
reply-parameters (success only):
- request identifier: An identifier matching the identifier of the
request.
semantics:
This transaction is used to close the MIDCOM session on behalf of
the agent. After session termination, the middlebox keeps all
established policy rules until their lifetime expires or until an
event occurs that causes the middlebox to terminate them.
The middlebox always generates a successful reply. After sending
the reply, the middlebox will not send any further messages to the
agent within the current session. It also will not process any
further request within this session that it received while
processing the session termination request, or that it receives
later.
2.2.3. Asynchronous Session Termination (AST)
transaction-name: asynchronous session termination
transaction-type: asynchronous
transaction-compliance: mandatory
notification message type: Session Termination Notification (STN)
reply-parameters (success only):
- termination reason: The reason why the session is terminated.
semantics:
The middlebox may decide to terminate a MIDCOM session at any
time. Before terminating the actual session the middlebox
generates a STN message and sends it to the agent. After sending
the notification, the middlebox will not process any further
request by the agent, even if it is already queued at the
middlebox.
After session termination, the middlebox keeps all established
policy rules until their lifetime expires or until an event occurs
for which the middlebox terminates them.
Unlike in other asynchronous transactions, no more than one
notification is sent, because there is only one agent affected by
the transaction.
2.2.4. Session Termination by Interruption of Connection
If a MIDCOM session is based on an underlying network connection, the
session can also be terminated by an interruption of this connection.
If the middlebox detects this, it immediately terminates the session.
The effect on established policy rules is the same as for the
Asynchronous Session Termination.
2.2.5. Session State Machine
A state machine illustrating the semantics of the session
transactions is shown in Figure 2. The transaction abbreviations
used can be found in the headings of the particular transaction
section.
All sessions start in state CLOSED. If mutual authentication is
already provided by other means, a successful SE transaction can
cause a state transition to state OPEN. Otherwise, it causes a
transition to state NOAUTH. From this state a failed second SE
transaction returns to state CLOSED. A successful SE transaction
causes a transition to state OPEN. At any time, an AST transaction
or a connection failure may occur, causing a transition to state
CLOSED. A successful ST transaction from either NOAUTH or OPEN also
causes a return to CLOSED. The parameters of the transactions are
explained in Figure 2; the value mc=0 represents an empty middlebox
challenge.
mc = middlebox challenge
SE/failure ma = middlebox authentication
+-------+ ac = agent challenge
| v aa = agent authentication
+----------+
| CLOSED |----------------+
+----------+ | SE(mc!=0)/
| ^ ^ | success(ma,ac)
SE(mc=0, | | | AST |
aa=OK)/ | | | SE/failure v
success | | | ST/success +----------+
| | +------------| NOAUTH |
| | +----------+
| | AST | SE(mc=0,
v | ST/success | aa=OK)/
+----------+ | success
| OPEN |<---------------+
+----------+
Figure 2: Session State Machine
2.3. Policy Rule Transactions
This section describes the semantics for transactions on policy
rules. The following transactions are specified:
- Policy Reserve Rule (PRR)
- Policy Enable Rule (PER)
- Policy Rule Lifetime Change (RLC)
- Policy Rule List (PRL)
- Policy Rule Status (PRS)
- Asynchronous Policy Rule Event (ARE)
The first three transactions (PRR, PER, RLC) are configuration
transactions initiated by the agent. The fourth and fifth (PRL, PRS)
are monitoring transactions. The last one (ARE) is an asynchronous
transaction. The PRL and PRS and transactions do not have any effect
on the policy rule state machine.
Before any transaction can start, a valid MIDCOM session must be
established.
2.3.1. Configuration Transactions
Policy Rule transactions PER and RLC constitute the core of the
MIDCOM protocol. Both are mandatory, and they serve for
- configuring NAT bindings (PER)
- configuring firewall pinholes (PER)
- extending the lifetime of established policy rules (RLC)
- deleting policy rules (RLC)
Some cases require knowing in advance which IP address (and port
number) would be chosen by NAT in a PER transaction. This
information is required before sufficient information for performing
a complete PER transaction is available (see example in section 4.2).
For supporting such cases, the core transactions are extended by the
Policy Reserve Rule (PRR) transaction serving for
- reserving addresses and port numbers at NATs (PRR)
2.3.2. Establishing Policy Rules
Both PRR and PER establish a policy rule. The action within the rule
is ’reserve’ if set by PRR and ’enable’ if set by PER.
The Policy Reserve Rule (PRR) transaction is used to establish an
address reservation on neither side, one side, or both sides of the
middlebox, depending on the middlebox configuration. The transaction
returns the reserved IP addresses and the optional ranges of port
numbers to the agent. No address binding or pinhole configuration is
performed at the middlebox. Packet processing at the middlebox
remains unchanged.
On pure firewalls, the PRR transaction is successfully processed
without any reservation, but the state transition of the MIDCOM
protocol engine is exactly the same as on NATs.
On a traditional NAT (see [NAT-TRAD]), only an external address is
reserved; on a twice-NAT, an internal and an external address are
reserved. The reservation at a NAT is for required resources, such
as IP addresses and port numbers, for future use. How the
reservation is exactly done depends on the implementation of the NAT.
In both cases the reservation concerns either an IP address only or a
combination of an IP address with a range of port numbers.
The Policy Enable Rule (PER) transaction is used to establish a
policy rule that affects packet processing at the middlebox.