RFC 5189
Middlebox Communication (MIDCOM) Protocol Semantics
Network Working Group M. Stiemerling Request for Comments: 5189 J. Quittek Obsoletes: 3989 NEC Category: Standards Track T. Taylor Nortel March 2008 Middlebox Communication (MIDCOM) Protocol Semantics Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.Abstract
This document specifies semantics for a Middlebox Communication (MIDCOM) protocol to be used by MIDCOM agents for interacting with middleboxes such as firewalls and Network Address Translators (NATs). The semantics discussion does not include any specification of a concrete syntax or a transport protocol. However, a concrete protocol is expected to implement the specified semantics or, more likely, a superset of it. The MIDCOM protocol semantics is derived from the MIDCOM requirements, from the MIDCOM framework, and from working group decisions. This document obsoletes RFC 3989.
Table of Contents
1. Introduction ....................................................4 1.1. Terminology ................................................5 1.2. Transaction Definition Template ............................7 2. Semantics Specification .........................................8 2.1. General Protocol Design ....................................8 2.1.1. Protocol Transactions ...............................8 2.1.2. Message Types .......................................9 2.1.3. Session, Policy Rule, and Policy Rule Group ........10 2.1.4. Atomicity ..........................................11 2.1.5. Access Control .....................................11 2.1.6. Middlebox Capabilities .............................12 2.1.7. Agent and Middlebox Identifiers ....................12 2.1.8. Conformance ........................................13 2.2. Session Control Transactions ..............................13 2.2.1. Session Establishment (SE) .........................14 2.2.2. Session Termination (ST) ...........................16 2.2.3. Asynchronous Session Termination (AST) .............16 2.2.4. Session Termination by Interruption of Connection ..17 2.2.5. Session State Machine ..............................17 2.3. Policy Rule Transactions ..................................18 2.3.1. Configuration Transactions .........................19 2.3.2. Establishing Policy Rules ..........................19 2.3.3. Maintaining Policy Rules and Policy Rule Groups ....20 2.3.4. Policy Events and Asynchronous Notifications .......21 2.3.5. Address Tuples .....................................21 2.3.6. Address Parameter Constraints ......................23 2.3.7. Interface-Specific Policy Rules ....................25 2.3.8. Policy Reserve Rule (PRR) ..........................25 2.3.9. Policy Enable Rule (PER) ...........................30 2.3.10. Policy Rule Lifetime Change (RLC) .................36 2.3.11. Policy Rule List (PRL) ............................38 2.3.12. Policy Rule Status (PRS) ..........................39 2.3.13. Asynchronous Policy Rule Event (ARE) ..............41 2.3.14. Policy Rule State Machine .........................42 2.4. Policy Rule Group Transactions ............................43 2.4.1. Overview ...........................................43 2.4.2. Group Lifetime Change (GLC) ........................44 2.4.3. Group List (GL) ....................................46 2.4.4. Group Status (GS) ..................................47 3. Conformance Statements .........................................48 3.1. General Implementation Conformance ........................49 3.2. Middlebox Conformance .....................................50 3.3. Agent Conformance .........................................50 4. Transaction Usage Examples .....................................50 4.1. Exploring Policy Rules and Policy Rule Groups .............50 4.2. Enabling a SIP-Signaled Call ..............................54
5. Compliance with MIDCOM Requirements ............................59 5.1. Protocol Machinery Requirements ...........................59 5.1.1. Authorized Association .............................59 5.1.2. Agent Connects to Multiple Middleboxes .............60 5.1.3. Multiple Agents Connect to Same Middlebox ..........60 5.1.4. Deterministic Behavior .............................60 5.1.5. Known and Stable State .............................60 5.1.6. Status Report ......................................61 5.1.7. Unsolicited Messages (Asynchronous Notifications) ..61 5.1.8. Mutual Authentication ..............................61 5.1.9. Session Termination by Any Party ...................61 5.1.10. Request Result ....................................62 5.1.11. Version Interworking ..............................62 5.1.12. Deterministic Handling of Overlapping Rules .......62 5.2. Protocol Semantics Requirements ...........................62 5.2.1. Extensible Syntax and Semantics ....................62 5.2.2. Policy Rules for Different Types of Middleboxes ....63 5.2.3. Ruleset Groups .....................................63 5.2.4. Policy Rule Lifetime Extension .....................63 5.2.5. Robust Failure Modes ...............................63 5.2.6. Failure Reasons ....................................63 5.2.7. Multiple Agents Manipulating Same Policy Rule ......63 5.2.8. Carrying Filtering Rules ...........................64 5.2.9. Parity of Port Numbers .............................64 5.2.10. Consecutive Range of Port Numbers .................64 5.2.11. Contradicting Overlapping Policy Rules ............64 5.3. Security Requirements .....................................64 5.3.1. Authentication, Confidentiality, Integrity .........64 5.3.2. Optional Confidentiality of Control Messages .......64 5.3.3. Operation across Untrusted Domains .................65 5.3.4. Mitigate Replay Attacks ............................65 6. Security Considerations ........................................65 7. IAB Considerations on UNSAF ....................................66 8. Acknowledgements ...............................................66 9. References .....................................................67 9.1. Normative References ......................................67 9.2. Informative References ....................................67 Appendix A. Changes from RFC 3989 .................................69
1. Introduction
The MIDCOM working group has defined a framework [MDC-FRM] and a list of requirements [MDC-REQ] for middlebox communication. The next step toward a MIDCOM protocol is the specification of protocol semantics that is constrained, but not completely implied, by the documents mentioned above. This memo suggests a semantics for the MIDCOM protocol. It is fully compliant with the requirements listed in [MDC-REQ] and with the working group's consensus on semantic issues. This document obsoletes RFC 3989 [MDC-SEM]. In conformance with the working group charter, the semantics description is targeted at packet filters and Network Address Translators (NATs), and it supports applications that require dynamic configuration of these middleboxes. The semantics is defined in terms of transactions. Two basic types of transactions are used: request transactions and asynchronous transactions. Further, we distinguish two concrete types of request transactions: configuration transactions and monitoring transactions. For each transaction, the semantics is specified by describing (1) the parameters of the transaction; (2) the processing of request messages at the middlebox; (3) the state transitions at the middlebox caused by the request transactions or indicated by the asynchronous transactions, respectively; and (4) the reply and notification messages sent from the middlebox to the agent in order to inform the agent about the state change. The semantics can be implemented by any protocol that supports these two transaction types and that is sufficiently flexible concerning transaction parameters. Different implementations for different protocols might need to extend the semantics described below by adding further transactions and/or adding further parameters to transactions and/or splitting single transactions into a set of transactions. Regardless of such extensions, the semantics below provides a minimum necessary subset of what must be implemented. The remainder of this document is structured as follows. Section 2 describes the protocol semantics. It is structured in four subsections: - General Protocol Design (section 2.1) - Session Control (section 2.2) - Policy Rules (section 2.3) - Policy Rule Groups (section 2.4)
Section 3 contains conformance statements for MIDCOM protocol definitions and MIDCOM protocol implementations with respect to the semantics defined in section 2. Section 4 gives two elaborated usage examples. Finally, section 5 explains how the semantics meets the MIDCOM requirements.1.1. Terminology
The terminology in this memo follows the definitions given in the framework [MDC-FRM] and requirements [MDC-REQ] document. In addition, the following terms are used: request transaction A request transaction consists of a request message transfer from the agent to the middlebox, processing of the message at the middlebox, a reply message transfer from the middlebox to the agent, and the optional transfer of notification messages from the middlebox to agents other than the one requesting the transaction. A request transaction might cause a state transition at the middlebox. configuration transaction A configuration transaction is a request transaction containing a request for state change in the middlebox. If accepted, it causes a state change at the middlebox. monitoring transaction A monitoring transaction is a request transaction containing a request for state information from the middlebox. It does not cause a state transition at the middlebox. asynchronous transaction An asynchronous transaction is not triggered by an agent. It may occur without any agent participating in a session with the middlebox. Potentially, an asynchronous transaction includes the transfer of notification messages from the middlebox to agents that participate in an open session. A notification message is sent to each agent that needs to be notified about the asynchronous event. The message indicates the state transition at the middlebox.
agent-unique An agent-unique value is unique in the
context of the agent. This context
includes all MIDCOM sessions the agent
participates in. An agent-unique value is
assigned by the agent.
middlebox-unique A middlebox-unique value is unique in the
context of the middlebox. This context
includes all MIDCOM sessions the middlebox
participates in. A middlebox-unique value
is assigned by the middlebox.
policy rule In general, a policy rule is "a basic
building block of a policy-based system.
It is the binding of a set of actions to a
set of conditions -- where the conditions
are evaluated to determine whether the
actions are performed" [RFC3198]. In the
MIDCOM context, the condition is a
specification of a set of packets to which
rules are applied. The set of actions
always contains just a single element per
rule, either action "reserve" or action
"enable".
policy reserve rule A policy rule containing a reserve action.
The policy condition of this rule is
always true. The action is the
reservation of just an IP address or a
combination of an IP address and a range
of port numbers on neither side, one side,
or both sides of the middlebox, depending
on the middlebox configuration.
policy enable rule A policy rule containing an enable action.
The policy condition consists of a
descriptor of one or more unidirectional
or bidirectional packet flows, and the
policy action enables packets belonging to
this flow to traverse the middlebox. The
descriptor identifies the protocol, the
flow direction, and the source and
destination addresses, optionally with a
range of port numbers.
NAT binding The term NAT binding as used in this
document does not necessarily refer to a
NAT bind as defined in [NAT-TERM]. A NAT
binding in the MIDCOM semantics refers to
an abstraction that enables communication
between two endpoints through the NAT-type
middlebox. An enable action may result in
a NAT bind or a NAT session, depending on
the request and its parameters.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
1.2. Transaction Definition Template
In the following sections, the semantics of the MIDCOM protocol is
specified per transaction. A transaction specification contains the
following entries. Parameter entries, failure reason, and
notification message type are only specified if applicable.
transaction-name
A description name for this type of transaction.
transaction-type
The transaction type is either 'configuration', 'monitoring', or
'asynchronous'. See section 1.1 for a description of transaction
types.
transaction-compliance
This entry contains either 'mandatory' or 'optional'. For
details, see section 2.1.8.
request-parameters
This entry lists all parameters necessary for this request. A
description for each parameter is given.
reply-parameters (success)
This entry lists all parameters sent back from the middlebox to
the agent as positive response to the prior request. A
description for each parameter is given.
failure reason
All negative replies have two parameters: a request identifier
identifying the request on which the reply is sent and a parameter
indicating the failure reason. As these parameters are
compulsory, they are not listed in the template. But the template
contains a list of potential failure reasons that may be indicated
by the second parameter. The list is not exhaustive. A concrete
protocol specification may extend the list.
notification message type
This entry describes the notification message type that may be
used by this transaction.
semantics
This entry describes the actual semantics of the transaction.
Particularly, it describes the processing of the request message
by the middlebox, and middlebox state transitions caused by or
causing the transaction, respectively.
2. Semantics Specification
2.1. General Protocol Design
The semantics specification aims at a balance between proper support
of applications that require dynamic configuration of middleboxes and
simplicity of specification and implementation of the protocol.
Protocol interactions are structured into transactions. The state of
middleboxes is described by state machines. The state machines are
defined by states and state transitions. A single transaction may
cause or be caused by state transitions in more than one state
machine, but per state machine there is no more than one transition
per transaction.
2.1.1. Protocol Transactions
State transitions are initiated either by a request message from the
agent to the middlebox or by some other event at the middlebox. In
the first case, the middlebox informs the agent by sending a reply
message on the actual state transition; in the second, the middlebox
sends an unsolicited asynchronous notification message to each agent
affected by the transaction (if it participates in an open session
with the middlebox).
Request and reply messages contain an agent-unique request identifier
that allows the agent to determine to which sent request a received
reply corresponds.
An analysis of the requirements showed that three kinds of
transactions are required:
- Configuration transactions allowing the agent to request state
transitions at the middlebox.
- Asynchronous transactions allowing the reporting of state
changes that have not been requested by the agent.
- Monitoring transactions allowing the agent to request state
information from the middlebox.
Configuration transactions and asynchronous transactions provide the
basic MIDCOM protocol functionality. They are related to middlebox
state transitions, and they concern establishment and termination of
MIDCOM sessions and of policy rules.
Monitoring transactions are not related to middlebox state
transitions. They are used by agents to explore the number, status,
and properties of policy rules established at the middlebox.
As specified in detail in section 3, configuration transactions and
asynchronous transactions are mandatory except of the Group Lifetime
Change (GLC). They must be implemented by a compliant middlebox.
The GLC transaction 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 are 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 was 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 - Support for interface-specific policy rules - 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, "Asynchronous Policy Rule Event (ARE)"). - 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, it is not required that an actual implementation of a middlebox supports all 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 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 (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
Transport Layer Security (TLS) [RFC4346] or IPsec
[RFC4302][RFC4303].
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 the 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 an 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
(page 18 continued on part 2)
