Request for Comments: 3989 J. Quittek
Category: Informational NEC
T. Taylor
Nortel
February 2005
Middlebox Communications (MIDCOM) Protocol Semantics
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This memo 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.
Table of Contents
1. Introduction ................................................. 3
1.1. Terminology ............................................ 4
1.2. Transaction Definition Template ........................ 6
2. Semantics Specification ...................................... 7
2.1. General Protocol Design ................................ 7
2.1.1. Protocol Transactions .......................... 8
2.1.2. Message Types .................................. 9
2.1.3. Session, Policy Rule, and Policy Rule Group .... 9
2.1.4. Atomicity ...................................... 10
2.1.5. Access Control ................................. 11
2.1.6. Middlebox Capabilities ......................... 11
2.1.7. Agent and Middlebox Identifiers ................ 12
2.1.8. Conformance .................................... 12
2.2. Session Control Transactions ........................... 13
2.2.1. Session Establishment (SE) ..................... 13
2.2.2. Session Termination (ST) ....................... 15
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) ...................... 26
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 ............... 62
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 ........................ 63
5.2.1. Extensible Syntax and Semantics ................ 63
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 .. 64
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 .................................. 65
5.3.1. Authentication, Confidentiality, Integrity ..... 65
5.3.2. Optional Confidentiality of Control Messages ... 65
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. Acknowledgments .............................................. 67
9. References ................................................... 67
9.1. Normative References ................................... 67
9.2. Informative References ................................. 67
Authors’ Addresses ............................................... 69
Full Copyright Statement ......................................... 70
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.
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-reply transactions and asynchronous
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, and (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 Issues (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 end points 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.
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
The type of 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 four kinds of
transactions are required:
- Configuration transactions allowing the agent to request state
transitions at the middlebox.
- Asynchronous transactions allowing the middlebox to change state
without a request by an agent.
- Monitoring transactions allowing the agent to request state
information from the middlebox.
- Convenience transactions combining a set of configuration
transactions.
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.