[RFCs/IDs] [Plain Text] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 RFC 5189
Network Working Group M. Stiemerling
Internet-Draft J. Quittek
Obsoletes: 3989 NEC
Intended status: Proposed Standard T. Taylor
Expires: December 2007 Nortel
June 2007
Middlebox Communications (MIDCOM) Protocol Semantics
<draft-ietf-midcom-rfc3989-bis-02.txt>
Status of This Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The IETF Trust (2007).
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
Stiemerling, et al. [Page 1]
Internet-Draft MIDCOM Protocol Semantics June 2007
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 .......................... 9
2.1.2. Message Types .................................. 10
2.1.3. Session, Policy Rule, and Policy Rule Group .... 10
2.1.4. Atomicity ...................................... 11
2.1.5. Access Control ................................. 12
2.1.6. Middlebox Capabilities ......................... 12
2.1.7. Agent and Middlebox Identifiers ................ 13
2.1.8. Conformance .................................... 13
2.2. Session Control Transactions ........................... 14
2.2.1. Session Establishment (SE) ..................... 14
2.2.2. Session Termination (ST) ....................... 16
2.2.3. Asynchronous Session Termination (AST) ......... 17
2.2.4. Session Termination by Interruption of
Connection ..................................... 18
2.2.5. Session State Machine .......................... 18
2.3. Policy Rule Transactions ............................... 19
2.3.1. Configuration Transactions ..................... 20
2.3.2. Establishing Policy Rules ...................... 20
2.3.3. Maintaining Policy Rules and Policy Rule Groups 21
2.3.4. Policy Events and Asynchronous Notifications ... 22
2.3.5. Address Tuples ................................. 22
2.3.6. Address Parameter Constraints .................. 24
2.3.7. Interface-specific Policy Rules ................ 26
2.3.8. Policy Reserve Rule (PRR) ...................... 27
2.3.9. Policy Enable Rule (PER) ....................... 31
2.3.10. Policy Rule Lifetime Change (RLC) .............. 37
2.3.11. Policy Rule List (PRL) ......................... 39
2.3.12. Policy Rule Status (PRS) ....................... 40
2.3.13. Asynchronous Policy Rule Event (ARE) ........... 42
2.3.14. Policy Rule State Machine ...................... 43
2.4. Policy Rule Group Transactions ......................... 44
2.4.1. Overview ....................................... 44
2.4.2. Group Lifetime Change (GLC) .................... 45
2.4.3. Group List (GL) ................................ 47
2.4.4. Group Status (GS) .............................. 48
3. Conformance Statements ....................................... 49
3.1. General Implementation Conformance ..................... 50
3.2. Middlebox Conformance .................................. 51
3.3. Agent Conformance ...................................... 51
Stiemerling, et al. [Page 2]
Internet-Draft MIDCOM Protocol Semantics June 2007
4. Transaction Usage Examples ................................... 51
4.1. Exploring Policy Rules and Policy Rule Groups .......... 51
4.2. Enabling a SIP-Signaled Call ........................... 55
5. Compliance with MIDCOM Requirements .......................... 60
5.1. Protocol Machinery Requirements ........................ 60
5.1.1. Authorized Association ......................... 60
5.1.2. Agent Connects to Multiple Middleboxes ......... 61
5.1.3. Multiple Agents Connect to Same Middlebox ...... 61
5.1.4. Deterministic Behavior ......................... 61
5.1.5. Known and Stable State ......................... 61
5.1.6. Status Report .................................. 62
5.1.7. Unsolicited Messages (Asynchronous
Notifications).................................. 62
5.1.8. Mutual Authentication .......................... 62
5.1.9. Session Termination by Any Party ............... 63
5.1.10. Request Result ................................. 63
5.1.11. Version Interworking ........................... 63
5.1.12. Deterministic Handling of Overlapping Rules .... 63
5.2. Protocol Semantics Requirements ........................ 64
5.2.1. Extensible Syntax and Semantics ................ 64
5.2.2. Policy Rules for Different Types of Middleboxes 64
5.2.3. Ruleset Groups ................................. 64
5.2.4. Policy Rule Lifetime Extension ................. 64
5.2.5. Robust Failure Modes ........................... 64
5.2.6. Failure Reasons ................................ 64
5.2.7. Multiple Agents Manipulating Same Policy Rule .. 65
5.2.8. Carrying Filtering Rules ....................... 65
5.2.9. Parity of Port Numbers ......................... 65
5.2.10. Consecutive Range of Port Numbers .............. 65
5.2.11. Contradicting Overlapping Policy Rules ......... 65
5.3. Security Requirements .................................. 66
5.3.1. Authentication, Confidentiality, Integrity ..... 66
5.3.2. Optional Confidentiality of Control Messages ... 66
5.3.3. Operation across Untrusted Domains ............. 66
5.3.4. Mitigate Replay Attacks ........................ 66
6. Security Considerations ...................................... 66
7. IAB Considerations on UNSAF .................................. 67
8. IANA Considerations .......................................... 68
9. Acknowledgments .............................................. 68
10. Informative References ....................................... 68
10.1. Normative References ................................... 68
10.2. Informative References ................................. 68
Appendix A. Changes from RFC 3989 ............................... 69
Authors' Addresses ............................................... 70
Intellectual Property and Copyright Statements ................... 71
Stiemerling, et al. [Page 3]
Internet-Draft MIDCOM Protocol Semantics June 2007
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, 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)
Stiemerling, et al. [Page 4]
Internet-Draft MIDCOM Protocol Semantics June 2007
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.
Stiemerling, et al. [Page 5]
Internet-Draft MIDCOM Protocol Semantics June 2007
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.
Stiemerling, et al. [Page 6]
Internet-Draft MIDCOM Protocol Semantics June 2007
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.
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.
Stiemerling, et al. [Page 7]
Internet-Draft MIDCOM Protocol Semantics June 2007
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.
Stiemerling, et al. [Page 8]
Internet-Draft MIDCOM Protocol Semantics June 2007
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 to report 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 Group Lifetime Change (GLC) transaction and some of the
monitoring transactions are optional.
Stiemerling, et al. [Page 9]
Internet-Draft MIDCOM Protocol Semantics June 2007
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
Stiemerling, et al. [Page 10]
Internet-Draft MIDCOM Protocol Semantics June 2007
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.
Stiemerling, et al. [Page 11]
Internet-Draft MIDCOM Protocol Semantics June 2007
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
Stiemerling, et al. [Page 12]
Internet-Draft MIDCOM Protocol Semantics June 2007
- 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 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, 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
Stiemerling, et al. [Page 13]
Internet-Draft MIDCOM Protocol Semantics June 2007
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.
Stiemerling, et al. [Page 14]
Internet-Draft MIDCOM Protocol Semantics June 2007
- 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.
Stiemerling, et al. [Page 15]
Internet-Draft MIDCOM Protocol Semantics June 2007
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
[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 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:
Stiemerling, et al. [Page 16]
Internet-Draft MIDCOM Protocol Semantics June 2007
- 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.
Stiemerling, et al. [Page 17]
Internet-Draft MIDCOM Protocol Semantics June 2007
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.
Stiemerling, et al. [Page 18]
Internet-Draft MIDCOM Protocol Semantics June 2007
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.
Stiemerling, et al. [Page 19]
Internet-Draft MIDCOM Protocol Semantics June 2007
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.
Stiemerling, et al. [Page 20]
Internet-Draft MIDCOM Protocol Semantics June 2007
The Policy Enable Rule (PER) transaction is used to establish a
policy rule that affects packet processing at the middlebox.
Depending on its input parameters, it may make use of the reservation
established by a PRR transaction or create a new rule from scratch.
On a NAT, the enable action is interpreted as a bind action
establishing bindings between internal and external addresses. At a
firewall, the enable action is interpreted as one or more allow
actions configuring pinholes. The number of allow actions depends on
the parameters of the request and the implementation of the firewall.
On a combined NAT/firewall, the enable action is interpreted as a
combination of bind and allow actions.
The PRR transaction and the PER transaction are described in more
detail in sections 2.3.8 and 2.3.9 below.
2.3.3. Maintaining Policy Rules and Policy Rule Groups
Each policy rule has a middlebox-unique identifier.
Each policy rule has an owner. Access control to the policy rule is
based on ownership (see section 2.1.5). Ownership of a policy rule
does not change during lifetime of the policy rule.
Each policy rule has an individual lifetime. If the policy rule
lifetime expires, the policy rule will be terminated at the
middlebox. Typically, the middlebox indicates termination of a
policy rule by an ARE transaction. A policy rule lifetime change
(RLC) transaction may extend the lifetime of the policy rule up to
the limit specified by the middlebox at session setup. Also an RLC
transaction may be used for shortening a policy rule's lifetime or
deleting a policy rule by requesting a lifetime of zero. (Please
note that policy rule lifetimes may also be modified by the group
lifetime change (GLC) transaction.)
Each policy rule is a member of exactly one policy rule group. Group
membership does not change during the lifetime of a policy rule.
Selecting the group is part of the transaction establishing the
policy rule. This transaction implicitly creates a new group if the
agent does not specify one. The new group identifier is chosen by
the middlebox. New members are added to an existing group if the
agent's request designates one. A group only exists as long as it
has member policy rules. As soon as all policies belonging to the
group have reached the ends of their lifetimes, the group does not
exist anymore.
Stiemerling, et al. [Page 21]
Internet-Draft MIDCOM Protocol Semantics June 2007
Agents can explore the properties and status of all policy rules they
are allowed to access by using the Policy Rule Status (PRS)
transaction.
2.3.4. Policy Events and Asynchronous Notifications
If a policy rule changes its state or if its remaining lifetime is
changed in ways other than being decreased by time, then all agents
that can access this policy rule and that participate in an open
session with the middlebox are notified by the middlebox. If the
state or lifetime change was requested explicitly by a request
message, then the middlebox notifies the requesting agent by
returning the corresponding reply. All other agents that can access
the policy are notified by a Policy Rule Event Notification (REN)
message.
Note that a middlebox can serve multiple agents at the same time in
different parallel sessions. Between these agents, the sets of
policy rules that can be accessed by them may overlap. For example,
there might be an agent that authenticates as administrator and that
can access all policies of all agents. Or there could be a backup
agent running a session in parallel to a main agent and
authenticating itself as the same entity as the main agent.
In case of a PER, PRR, or RLC transaction, the requesting agent
receives a PER, PRR, or RLC reply, respectively. To all other agents
that can access the created, modified, or terminated policy rule (and
that participate in an open session with the middlebox) the middlebox
sends an REN message carrying the policy rule identifier (PID) and
the remaining lifetime of the policy rule.
In case of a rule termination by lifetime truncation or other events
not triggered by an agent, then the middlebox sends an REN message to
each agent that can access the particular policy rule and that
participates in an open session with the middlebox. This ensures
that an agent always knows the most recent state of all policy rules
it can access.
2.3.5. Address Tuples
Request and reply messages of the PRR, PER, and PRS transactions
contain address specifications for IP and transport addresses. These
parameters include
- IP version
- IP address
- IP address prefix length
- transport protocol
Stiemerling, et al. [Page 22]
Internet-Draft MIDCOM Protocol Semantics June 2007
- port number
- port parity
- port range
Additionally, the request message of PER and the reply message of PRS
contain a direction of flow parameter. This direction of flow
parameter indicates for UDP and IP the direction of packets
traversing the middlebox. For 'inbound', the UDP packets are
traversing from outside to inside; for 'outbound', from inside to the
outside. In both cases, the packets can traverse the middelbox only
uni-directionally. A bi-directional flow is enabled through 'bi-
directional' as direction of flow parameter. For TCP, the packet
flow is always bi-directional, but the direction of the flow
parameter is defined as
- inbound: bi-directional TCP packet flow. First packet, with TCP
SYN flag set and ACK flag not set, must arrive at the middlebox
at the outside interface.
- outbound: bi-directional TCP packet flow. First packet, with
TCP SYN flag set and ACK flag not set, must arrive at the
middlebox at the inside interface.
- bi-directional: bi-directional TCP packet flow. First packet,
with TCP SYN flag set and ACK flag not set, may arrive at inside
or outside interface.
We refer to the set of these parameters as an address tuple. An
address tuple specifies either a communication endpoint at an
internal or external device or allocated addresses at the middlebox.
In this document, we distinguish four kinds of address tuples, as
shown in Figure 3.
+----------+ +----------+
| internal | A0 A1 +-----------+ A2 A3 | external |
| endpoint +----------+ middlebox +----------+ endpoint |
+----------+ +-----------+ +----------+
Figure 3: Address tuples A0 - A3
- A0 -- internal endpoint: Address tuple A0 specifies a
communication endpoint of a device within -- with respect to the
middlebox -- the internal network.
- A1 -- middlebox inside address: Address tuple A1 specifies a
virtual communication endpoint at the middlebox within the
internal network. A1 is the destination address for packets
Stiemerling, et al. [Page 23]
Internet-Draft MIDCOM Protocol Semantics June 2007
passing from the internal endpoint to the middlebox and is the
source for packets passing from the middlebox to the internal
endpoint.
- A2 -- middlebox outside address: Address tuple A2 specifies a
virtual communication endpoint at the middlebox within the
external network. A2 is the destination address for packets
passing from the external endpoint to the middlebox and is the
source for packets passing from the middlebox to the external
endpoint.
- A3 -- external endpoint: Address tuple A3 specifies a
communication endpoint of a device within -- with respect to the
middlebox -- the external network.
For a firewall, the inside and outside endpoints are identical to the
corresponding external or internal endpoints, respectively. In this
case the installed policy rule sets the same value in A2 as in A0
(A0=A2) and sets the same value in A1 as in A3 (A1=A3).
For a traditional NAT, A2 is given a value different from that of A0,
but the NAT binds them. As for the firewall, it is also as it is at
a traditional NAT: A1 has the same value as A3.
For a twice-NAT, there are two bindings of address tuples: A1 and A2
are both assigned values by the NAT. The middlebox outside address
A2 is bound to the internal endpoint A0, and the middlebox inside
address A1 is bound to the external endpoint A3.
2.3.6. Address Parameter Constraints
For transaction parameters belonging to an address tuple, some
constraints exist that are common for all messages using them.
Therefore, these constraints are summarized in the following and are
not repeated again when describing the parameters in the transaction
descriptions are presented.
The MIDCOM semantics defined in this document specifies the handling
of IPv4 and IPv6 as network protocols, and of TCP and UDP (over IPv4
and IPv6) as transport protocols. The handling of any other
transport protocol, e.g., SCTP, is not defined within the semantics
but may be supported by concrete protocol specifications.
The IP version parameter has either the value 'IPv4' or 'IPv6'. In a
policy rule, the value of the IP version parameter must be the same
for address tuples A0 and A1, and for A2 and A3.
Stiemerling, et al. [Page 24]
Internet-Draft MIDCOM Protocol Semantics June 2007
The value of the IP address parameter must conform with the specified
IP version.
The IP address of an address tuple may be wildcarded. Whether IP
address wildcarding is allowed or in which range it is allowed
depends on the local policy of the middlebox; see also section 6,
"Security Considerations". Wildcarding is specified by the IP
address prefix length parameter of an address tuple. In line with
the common use of a prefix length, this parameter indicates the
number of high significant bits of the IP address that are fixed,
while the remaining low significant bits of the IP address are
wildcarded.
The value of the transport protocol parameter can be either 'TCP',
'UDP', or 'ANY'. If the transport protocol parameter has the value
'ANY', only IP headers are considered for packet handling in the
middlebox -- i.e., the transport header is not considered. The
values of the parameters port number, port range, and port parity are
irrelevant if the protocol parameter is 'ANY'. In a policy rule, the
value of the transport protocol parameter must be the same for all
address tuples A0, A1, A2, and A3.
The value of the port number parameter is either zero or a positive
integer. A positive integer specifies a concrete UDP or TCP port
number. The value zero specifies port wildcarding for the protocol
specified by the transport protocol parameter. If the port number
parameter has the value zero, then the value of the port range
parameter is irrelevant. Depending on the value of the transport
protocol parameter, this parameter may truly refer to ports or may
refer to an equivalent concept.
The port parity parameter is differently used in the context of
policy reserve rules (PRR) and policy enable rules (PER). In the
context of a PRR, the value of the parameter may be 'odd', 'even', or
'any'. It specifies the parity of the first (lowest) reserved port
number.
In the context of a PER, the port parity parameter indicates to the
middlebox whether port numbers allocated at the middlebox should have
the same parity as the corresponding internal or external port
numbers, respectively. In this context, the parameter has the value
'same' or 'any'. If the value is 'same', then the parity of the port
number of A0 must be the same as the parity of the port number of A2,
and the parity of the port number of A1 must be the same as the
parity of the port number of A3. If the port parity parameter has
the value 'any', then there are no constraints on the parity of any
port number.
Stiemerling, et al. [Page 25]
Internet-Draft MIDCOM Protocol Semantics June 2007
The port range parameter specifies a number of consecutive port
numbers. Its value is a positive integer. Like the port number
parameter, this parameter defines a set of consecutive port numbers
starting with the port number specified by the port number parameter
as the lowest port number and having as many elements as specified by
the port range parameter. A value of 1 specifies a single port
number. The port range parameter must have the same value for each
address tuple A0, A1, A2, and A3.
A single policy rule P containing a port range value greater than one
is equivalent to a set of policy rules containing a number n of
policies P_1, P_2, ..., P_n where n equals the value of the port
range parameter. Each policy rule P_1, P_2, ..., P_n has a port
range parameter value of 1. Policy rule P_1 contains a set of
address tuples A0_1, A1_1, A2_1, and A3_1, each of which contains the
first port number of the respective address tuples in P; policy rule
P_2 contains a set of address tuples A0_2, A1_2, A2_2, and A3_2, each
of which contains the second port number of the respective address
tuples in P; and so on.
2.3.7. Interface-specific Policy Rules
Usually agents request policy rules with the knowledge of A0 and A3
only, i.e., the address tuples (see section 2.3.5). But in very
special cases, agents may need to select the interfaces to which the
requested policy rule is bound. Generally, the middlebox is careful
about choosing the right interfaces when reserving or enabling a
policy rule, as it has the overall knowledge about its configuration.
For agents that want to select the interfaces, optional parameters
are included in the Policy Reserve Rule (PRR) and Policy Enable Rule
(PER) transactions. These parameters are called
- inside interface: The selected interface at the inside of the
middlebox -- i.e., in the private or protected address realm.
- outside interface: The selected interface at the outside of the
middlebox -- i.e., in the public address realm.
The Policy Rule Status (PRS) transactions include these optional
parameters in its replies when they are supported.
Agents can learn at session startup whether interface-specific policy
rules are supported by the middlebox, by checking the middlebox
capabilities (see section 2.1.6).
Stiemerling, et al. [Page 26]
Internet-Draft MIDCOM Protocol Semantics June 2007
2.3.8. Policy Reserve Rule (PRR)
transaction-name: policy reserve rule
transaction-type: configuration
transaction-compliance: mandatory
request-parameters:
- request identifier: An agent-unique identifier for matching
corresponding request and reply at the agent.
- group identifier: A reference to the group of which the policy
reserve rule should be a member. As indicated in section 2.3.3,
if this value is not supplied, the middlebox assigns a new group
for this policy reserve rule.
- service: The requested NAT service of the middlebox. Allowed
values are 'traditional' or 'twice'.
- internal IP version: Requested IP version at the inside of the
middlebox; see section 2.3.5.
- internal IP address: The IP address of the internal
communication endpoint (A0 in Figure 3); see section 2.3.5.
- internal port number: The port number of the internal
communication endpoint (A0 in Figure 3); see section 2.3.5.
- inside interface (optional): Interface at the inside of the
middlebox; see section 2.3.7.
- external IP version: Requested IP version at the outside of the
middlebox; see section 2.3.5.
- outside interface (optional): Interface at the outside of the
middlebox; see Section 2.3.7.
- transport protocol: See section 2.3.5.
- port range: The number of consecutive port numbers to be
reserved; see section 2.3.5.
- port parity: The requested parity of the first (lowest) port
number to be reserved; allowed values for this parameter are
'odd', 'even', and 'any'. See also section 2.3.5.
Stiemerling, et al. [Page 27]
Internet-Draft MIDCOM Protocol Semantics June 2007
- policy rule lifetime: A lifetime proposal to the middlebox for
the requested policy rule.
reply-parameters (success):
- request identifier: An identifier matching the identifier of the
request.
- policy rule identifier: A middlebox-unique policy rule
identifier. It is assigned by the middlebox and used as policy
rule handle in further policy rule transactions, particularly to
refer to the policy reserve rule in a subsequent PER
transaction.
- group identifier: A reference to the group of which the policy
reserve rule is a member.
- reserved inside IP address: The reserved IPv4 or IPv6 address on
the internal side of the middlebox. For an outbound flow, this
will be the destination to which the internal endpoint sends its
packets (A1 in Figure 3). For an inbound flow, it will be the
apparent source address of the packets as forwarded to the
internal endpoint (A0 in Figure 3). The middlebox reserves and
reports an internal address only in the case where twice-NAT is
in effect. Otherwise, an empty value for the addresses
indicates that no internal reservation was made. See also
Section 2.3.5.
- reserved inside port number: See section 2.3.5.
- reserved outside IP address: The reserved IPv4 or IPv6 address
on the external side of the middlebox. For an inbound flow,
this will be the destination to which the external endpoint
sends its packets (A2 in Figure 4). For an outbound flow, it
will be the apparent source address of the packets as forwarded
to the external endpoint (A3 in Figure 3). If the middlebox is
configured as a pure firewall, an empty value for the addresses
indicates that no external reservation was made. See also
section 2.3.5.
- reserved outside port number: See section 2.3.5.
- policy rule lifetime: The policy rule lifetime granted by the
middlebox, after which the reservation will be revoked if it has
not been replaced already by a policy enable rule in a PER
transaction.
Stiemerling, et al. [Page 28]
Internet-Draft MIDCOM Protocol Semantics June 2007
failure reason:
- agent not authorized for this transaction
- agent not authorized to add members to this group
- lack of IP addresses
- lack of port numbers
- lack of resources
- specified inside/outside interface does not exist
- specified inside/outside interface not available for specified
service
notification message type: Policy Rule Event Notification (REN)
semantics:
The agent can use this transaction type to reserve an IP address
or a combination of IP address, transport type, port number, and
port range at neither side, one side, or both sides of the
middlebox as required to support the enabling of a flow.
Typically the PRR will be used in scenarios where it is required
to perform such a reservation before sufficient parameters for a
complete policy enable rule transaction are available. See
section 4.2 for an example.
When receiving the request, the middlebox determines how many
address (and port) reservations are required based on its
configuration. If it provides only packet filter services, it
does not perform any reservation and returns empty values for the
reserved inside and outside IP addresses and port numbers. If it
is configured for twice-NAT, it reserves both inside and outside
IP addresses (and an optional range of port numbers) and returns
them. Otherwise, it reserves and returns an outside IP address
(and an optional range of port numbers) and returns empty values
for the reserved inside address and port range.
The A0 parameter (inside IP address version, inside IP address,
and inside port number) can be used by the middlebox to determine
the correct NAT mapping and thus A2 if necessary. Once a PRR
transaction has reserved an outside address (A2) for an internal
end point (A0) at the middlebox, the middlebox must ensure that
this reserved A2 is available in any subsequent PER and PRR
transaction.
For middleboxes supporting interface-specific policy rules, as
defined in section 2.3.7, the optional inside and outside
interface parameters must both be included in the request, or
neither of them should be included. In the presence of these
parameters, the middlebox uses the outside interface parameter to
Stiemerling, et al. [Page 29]
Internet-Draft MIDCOM Protocol Semantics June 2007
select the interface at which the outside address tuple (outside
IP address and port number) is reserved, and the inside interface
parameter to select the interface at which the inside address
tuple (inside IP address and port number) is reserved. Without
the presence of these parameters, the middlebox selects the
particular interfaces based on its internal configuration.
If there is a lack of resources, such as available IP addresses,
port numbers, or storage for further policy rules, then the
reservation fails, and an appropriate failure reply is generated.
If a non-existing policy rule group was specified, or if an
existing policy rule group was specified that is not owned by the
requesting agent, then no new policy rule is established, and an
appropriate failure reply is generated.
In case of success, this transaction creates a new policy reserve
rule. If an already existing policy rule group is specified, then
the new policy rule becomes a member of it. If no policy group is
specified, a new group is created with the new policy rule as its
only member. The middlebox generates a middlebox-unique
identifier for the new policy rule. The owner of the new policy
rule is the authenticated agent that sent the request. The
middlebox chooses a lifetime value that is greater than zero and
less than or equal to the minimum of the requested value and the
maximum lifetime specified by the middlebox at session startup,
i.e.,
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
where
- lt_granted is the lifetime actually granted by the middlebox
- lt_requested is the lifetime the agent requested
- lt_maximum is the maximum lifetime specified at session
setup
A middlebox with NAT capability always reserves a middlebox
external address tuple (A2) in response to a PRR request. In the
special case of a combined twice-NAT/NAT middlebox, the agent can
request only NAT service or twice-NAT service by choosing the
service parameter 'traditional' or 'twice', respectively. An
agent that does not have any preference chooses 'twice'. The
'traditional' value should only be used in order to select
traditional NAT service at middleboxes offering both traditional
NAT and twice NAT. In the 'twice' case, the combined twice-
NAT/NAT middlebox reserves A2 and A1; the 'traditional' case
results in a reservation of A2 only. An agent
Stiemerling, et al. [Page 30]
Internet-Draft MIDCOM Protocol Semantics June 2007
must always use the PRR transaction for choosing NAT only or
twice-NAT service in the special case of a combined twice-NAT/NAT
middlebox. A firewall middlebox ignores this parameter.
If the protocol identifier is 'ANY', then the middlebox reserves
available inside and/or outside IP address(es) only. The reserved
address(es) are returned to the agent. In this case, the request-
parameters "port range" and "port parity" as well as reply-
parameters "inside port number" and "outside port number", are
irrelevant.
If the protocol identifier is 'UDP' or 'TCP', then a combination
of an IP address and a consecutive sequence of port numbers,
starting with the specified parity, is reserved, on neither side,
one side, or both sides of the middlebox, as appropriate. The IP
address(es) and the first (lowest) reserved port number(s) of the
consecutive sequence are returned to the agent. (This also
applies to other protocols supporting ports or the equivalent.)
After a new policy reserve rule is successfully established and
the reply message has been sent to the requesting agent, the
middlebox checks whether there are other authenticated agents
participating in open sessions, which can access the new policy
rule. If the middlebox finds one or more of these agents, then it
sends a REN message reporting the new policy rule to each of them.
MIDCOM agents use the policy enable rule (PER) transaction to enable
policy reserve rules that have been established beforehand by a
policy reserve rule (PRR) transaction. See also section 2.3.2.
2.3.9. Policy Enable Rule (PER)
transaction-name: policy enable rule
transaction-type: configuration
transaction-compliance: mandatory
request-parameters:
- request identifier: An agent-unique identifier for matching
corresponding request and reply at the agent.
- policy reserve rule identifier: A reference to an already
existing policy reserve rule created by a PRR transaction. The
reference may be empty, in which case the middlebox must assign
any necessary addresses and port numbers within this PER
transaction. If it is not empty, then the following request
Stiemerling, et al. [Page 31]
Internet-Draft MIDCOM Protocol Semantics June 2007
parameters are irrelevant: group identifier, transport protocol,
port range, port parity, internal IP version, external IP
version.
- group identifier: A reference to the group of which the policy
enable rule should be a member. As indicated in section 2.3.3,
if this value is not supplied, the middlebox assigns a new group
for this policy reserve rule.
- transport protocol: See section 2.3.5.
- port range: The number of consecutive port numbers to be
reserved; see section 2.3.5.
- port parity: The requested parity of the port number(s) to be
mapped. Allowed values of this parameter are 'same' and 'any'.
See also section 2.3.5.
- direction of flow: This parameter specifies the direction of
enabled communication, either 'inbound', 'outbound', or 'bi-
directional'.
- internal IP version: Requested IP version at the inside of the
middlebox; see section 2.3.5.
- internal IP address: The IP address of the internal
communication endpoint (A0 in Figure 3); see section 2.3.5.
- internal port number: The port number of the internal
communication endpoint (A0 in Figure 3); see section 2.3.5.
- inside interface (optional): Interface at the inside of the
middlebox; see section 2.3.7.
- external IP version: Requested IP version at the outside of the
middlebox; see section 2.3.5.
- external IP address: The IP address of the external
communication endpoint (A3 in Figure 3); see section 2.3.5.
- external port number: The port number of the external
communication endpoint (A3 in Figure 4), see section 2.3.5.
- outside interface (optional): Interface at the outside of the
middlebox; see section 2.3.7.
- policy rule lifetime: A lifetime proposal to the middlebox for
the requested policy rule.
Stiemerling, et al. [Page 32]
Internet-Draft MIDCOM Protocol Semantics June 2007
reply-parameters (success):
- request identifier: An identifier matching the identifier of the
request.
- policy rule identifier: A middlebox-unique policy rule
identifier. It is assigned by the middlebox and used as policy
rule handle in further policy rule transactions. If a policy
reserve rule identifier was provided in the request, then the
returned policy rule identifier has the same value.
- group identifier: A reference to the group of which the policy
enable rule is a member. If a policy reserve rule identifier
was provided in the request, then this parameter identifies the
group of which the policy reserve rule was a member.
- inside IP address: The IP address provided at the inside of the
middlebox (A1 in Figure 3). In case of a twice-NAT, this
parameter will be an internal IP address reserved at the inside
of the middlebox. In all other cases, this reply-parameter will
be identical with the external IP address passed with the
request. If the policy reserve rule identifier parameter was
supplied in the request and the respective PRR transaction
reserved an inside IP address, then the inside IP address
provided in the PER response will be the identical value to that
returned by the response to the PRR request. See also section
2.3.5.
- inside port number: The internal port number provided at the
inside of the middlebox (A1 in Figure 3); see also section
2.3.5.
- outside IP address: The external IP address provided at the
outside of the middlebox (A2 in Figure 4). In case of a pure
firewall, this parameter will be identical with the internal IP
address passed with the request. In all other cases, this
reply-parameter will be an external IP address reserved at the
outside of the middlebox. See also section 2.3.5.
- outside port number: The external port number provided at the
outside of the NAT (A2 in Figure 3); see section 2.3.5..
- policy rule lifetime: The policy rule lifetime granted by the
middlebox.
failure reason:
- agent not authorized for this transaction
Stiemerling, et al. [Page 33]
Internet-Draft MIDCOM Protocol Semantics June 2007
- agent not authorized to add members to this group
- no such policy reserve rule
- agent not authorized to replace this policy reserve rule
- conflict with already existing policy rule (e.g., the same
internal address-port is being mapped to different outside
address-port pairs)
- lack of IP addresses
- lack of port numbers
- lack of resources
- no internal IP wildcarding allowed
- no external IP wildcarding allowed
- specified inside/outside interface does not exist
- specified inside/outside interface not available for specified
service
- reserved A0 to requested A0 mismatch
notification message type: Policy Rule Event Notification (REN)
semantics:
This transaction can be used by an agent to enable communication
between an internal endpoint and an external endpoint
independently of the type of middlebox (NAT, NAPT, firewall, NAT-
PT, combined devices), for unidirectional or bi-directional
traffic.
The agent sends an enable request specifying the endpoints
(optionally including wildcards) and the direction of
communication (inbound, outbound, bi-directional). The
communication endpoints are displayed in Figure 3. The basic
operation of the PER transaction can be described by
1. the agent sending A0 and A3 to the middlebox,
2. the middlebox reserving A1 and A2 or using A1 and A2 from a
previous PRR transaction,
3. the middlebox enabling packet transfer between A0 and A3 by
binding A0-A2 and A1-A3 and/or by opening the corresponding
pinholes, both according to the specified direction, and
4. the middlebox returning A1 and A2 to the agent.
In case of a pure packet filtering firewall, the returned address
tuples are the same as those in the request: A2=A0 and A1=A3.
Each partner uses the other's real address. In case of a
traditional NAT, the internal endpoint may use the real address of
the external endpoint (A1=A3), but the external endpoint uses an
Stiemerling, et al. [Page 34]
Internet-Draft MIDCOM Protocol Semantics June 2007
address tuple provided by the NAT (A2!=A0). In case of a twice-
NAT device, both endpoints use address tuples provided by the NAT
for addressing their communication partner (A3!=A1 and A2!=A0).
If a firewall is combined with a NAT or a twice-NAT, the replied
address tuples will be the same as for pure traditional NAT or
twice-NAT, respectively, but the middlebox will configure its
packet filter in addition to the performed NAT bindings. In case
of a firewall combined with a traditional NAT, the policy rule may
imply more than one enable action for the firewall configuration,
as incoming and outgoing packets may use different source-
destination pairs.
For middleboxes supporting interface specific policy rules, as
defined in Section 2.3.7, the optional inside and outside
interface parameters must both be included in the request, or
neither of them should be included. In the presence of these
parameters, the middlebox uses the outside interface parameter to
select the interface at which the outside address tuple (outside
IP address and port number) is bound, and the inside interface
parameter to select the interface at which the inside address
tuple (inside IP address and port number) is bound. Without the
presence of these parameters, the middlebox selects the particular
interfaces based on its internal configuration.
Checking the Policy Reservation Rule Identifier
If the parameter specifying the policy reservation rule
identifier is not empty, then the middlebox checks whether the
referenced policy rule exists, whether the agent is authorized
to replace this policy rule, and whether this policy rule is a
policy reserve rule.
In case of success, this transaction creates a new policy
enable rule. If a policy reserve rule was referenced, then the
policy reserve rule is terminated without an explicit
notification sent to the agent (other than the successful PER
reply).
The PRR transaction sets the internal endpoint A0 during the
reservation process. In the process of creating a new policy
enable rule, the middlebox may check whether the requested A0
is equal to the reserved A0. The middlebox may reject a PER
request with a requested A0 not equal to the reserved A0 and
must then send an appropriate failure message. Alternatively,
the middlebox may change A0 due to the PER request.
Stiemerling, et al. [Page 35]
Internet-Draft MIDCOM Protocol Semantics June 2007
The middlebox generates a middlebox-unique identifier for the
new policy rule. If a policy reserve rule was referenced, then
the identifier of the policy reserve rule is reused.
The owner of the new policy rule is the authenticated agent
that sent the request.
Checking the Policy Rule Group Identifier
If no policy reserve rule was specified, then the policy rule
group parameter is checked. If a non-existing policy rule
group is specified, or if an existing policy rule group is
specified that is not owned by the requesting agent, then no
new policy rule is established, and an appropriate failure
reply is generated.
If an already existing policy rule group is specified, then the
new policy rule becomes a member. If no policy group is
specified, then a new group is created with the new policy rule
as its only member.
If the transport protocol parameter value is 'ANY', then the
middlebox enables communication between the specified external IP
address and the specified internal IP address. The addresses to
be used by the communication partners to address each other are
returned to the agent as inside IP address and outside IP address.
If the reservation identifier is not empty and if the reservation
used the same transport protocol type, then the reserved IP
addresses are used.
For the transport protocol parameter values 'UDP' and 'TCP', the
middlebox acts analogously as for 'ANY' but also maps ranges of
port numbers, keeping the port parity, if requested.
The configuration of the middlebox may fail because of lack of
resources, such as available IP addresses, port numbers, or
storage for further policy rules. It may also fail because of a
conflict with an established policy rule. In case of a conflict,
the first-come first-served mechanism is applied. Existing policy
rules remain unchanged and arriving new ones are rejected.
However, in case of a non-conflicting overlap of policy rules
(including identical policy rules), all policy rules are accepted.
The middlebox chooses a lifetime value that is greater than zero
and less than or equal to the minimum of the requested value and
the maximum lifetime specified by the middlebox at session
startup, i.e.,
Stiemerling, et al. [Page 36]
Internet-Draft MIDCOM Protocol Semantics June 2007
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
where
- lt_granted is the lifetime actually granted by the middlebox
- lt_requested is the lifetime the agent requested
- lt_maximum is the maximum lifetime specified at session
setup
In each case of failure, an appropriate failure reply is
generated. The policy reserve rule that is referenced in the PER
transaction is not affected in case of a failure within the PER
transaction -- i.e., the policy reserve rule remains.
After a new policy enable rule is successfully established and the
reply message has been sent to the requesting agent, the middlebox
checks whether there are other authenticated agents participating
in open sessions that can access the new policy rule. If the
middlebox finds one or more of these agents, then it sends a REN
message reporting the new policy rule to each of them.
2.3.10. Policy Rule Lifetime Change (RLC)
transaction-name: policy rule lifetime change
transaction-type: configuration
transaction-compliance: mandatory
request-parameters:
- request identifier: An agent-unique identifier for matching
corresponding request and reply at the agent.
- policy rule identifier: Identifying the policy rule for which
the lifetime is requested to be changed. This may identify
either a policy reserve rule or a policy enable rule.
- policy rule lifetime: The new lifetime proposal for the policy
rule.
reply-parameters (success):
- request identifier: An identifier matching the identifier of the
request.
- policy rule lifetime: The remaining policy rule lifetime granted
by the middlebox.
Stiemerling, et al. [Page 37]
Internet-Draft MIDCOM Protocol Semantics June 2007
failure reason:
- agent not authorized for this transaction
- agent not authorized to change lifetime of this policy
rule
- no such policy rule
- lifetime cannot be extended
notification message type: Policy Rule Event Notification (REN)
semantics:
The agent can use this transaction type to request the extension
of an established policy rule's lifetime, the shortening of the
lifetime, or policy rule termination. Policy rule termination is
requested by suggesting a new policy rule lifetime of zero.
The middlebox first checks whether the specified policy rule
exists and whether the agent is authorized to access this policy
rule. If one of the checks fails, an appropriate failure reply is
generated. If the requested lifetime is longer than the current
one, the middlebox also checks whether the lifetime of the policy
rule may be extended and generates an appropriate failure message
if it may not.
A failure reply implies that the new lifetime was not accepted,
and the policy rule remains unchanged. A success reply is
generated by the middlebox if the lifetime of the policy rule was
changed in any way.
The success reply contains the new lifetime of the policy rule.
The middlebox chooses a lifetime value that is greater than zero
and less than or equal to the minimum of the requested value and
the maximum lifetime specified by the middlebox at session
startup, i.e.,
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
whereas
- lt_granted is the lifetime actually granted by the middlebox
- lt_requested is the lifetime the agent requested
- lt_maximum is the maximum lifetime specified at session
setup
Stiemerling, et al. [Page 38]
Internet-Draft MIDCOM Protocol Semantics June 2007
After sending a success reply with a lifetime of zero, the
middlebox will consider the policy rule non-existent. Any further
transaction on this policy rule results in a negative reply,
indicating that this policy rule does not exist anymore.
Note that policy rule lifetime may also be changed by the Group
Lifetime Change (GLC) transaction, if applied to the group of
which the policy rule is a member.
After the remaining policy rule lifetime was successfully changed
and the reply message has been sent to the requesting agent, the
middlebox checks whether there are other authenticated agents
participating in open sessions that can access the policy rule.
If the middlebox finds one or more of these agents, then it sends
a REN message reporting the new remaining policy rule lifetime to
each of them.
2.3.11. Policy Rule List (PRL)
transaction-name: policy rule list
transaction-type: monitoring
transaction-compliance: mandatory
request-parameters:
- request identifier: An agent-unique identifier for matching
corresponding request and reply at the agent.
reply-parameters (success):
- request identifier: An identifier matching the identifier of the
request.
- policy list: List of policy rule identifiers of all policy rules
that the agent can access.
failure reason:
- transaction not supported
- agent not authorized for this transaction
Stiemerling, et al. [Page 39]
Internet-Draft MIDCOM Protocol Semantics June 2007
semantics:
The agent can use this transaction type to list all policies that
it can access. Usually, the agent has this information already,
but in special cases (for example, after an agent fail-over) or
for special agents (for example, an administrating agent that can
access all policies) this transaction can be helpful.
The middlebox first checks whether the agent is authorized to
request this transaction. If the check fails, an appropriate
failure reply is generated. Otherwise a list of all policies the
agent can access is returned indicating the identifier and the
owner of each policy.
This transaction does not have any effect on the policy rule
state.
2.3.12. Policy Rule Status (PRS)
transaction-name: policy rule status
transaction-type: monitoring
transaction-compliance: mandatory
request-parameters:
- request identifier: An agent-unique identifier for matching
corresponding request and reply at the agent.
- policy rule identifier: The middlebox-unique policy rule
identifier.
reply-parameters (success):
- request identifier: An identifier matching the identifier of the
request.
- policy rule owner: An identifier of the agent owning this policy
rule.
- group identifier: A reference to the group of which the policy
rule is a member.
- policy rule action: This parameter has either the value
'reserve' or the value 'enable'.
Stiemerling, et al. [Page 40]
Internet-Draft MIDCOM Protocol Semantics June 2007
- transport protocol: Identifies the protocol for which a
reservation is requested; see section 2.3.5.
- port range: The number of consecutive port numbers; see section
2.3.5.
- direction: The direction of the communication enabled by the
middlebox. Applicable only to policy enable rules.
- internal IP address version: The version of the internal IP
address (IP version of A0 in Figure 3).
- external IP address version: The version of the external IP
address (IP version of A3 in Figure 3).
- internal IP address: The IP address of the internal
communication endpoint (A0 in Figure 3); see section 2.3.5.
- internal port number: The port number of the internal
communication endpoint (A0 in Figure 3); see section 2.3.5.
- external IP address: The IP address of the external
communication endpoint (A3 in Figure 3); see section 2.3.5.
- external port number: The port number of the external
communication endpoint (A3 in Figure 3); see section 2.3.5.
- inside interface (optional): The inside interface at the
middlebox; see section 2.3.7.
- inside IP address: The internal IP address provided at the
inside of the NAT (A1 in Figure 3); see section 2.3.5.
- inside port number: The internal port number provided at the
inside of the NAT (A1 in Figure 3); see section 2.3.5.
- outside interface (optional): The outside interface at the
middlebox; see section 2.3.7.
- outside IP address: The external IP address provided at the
outside of the NAT (A2 in Figure 3); see section 2.3.5.
- outside port number: The external port number provided at the
outside of the NAT (A2 in Figure 3); see section 2.3.5.
- port parity: The parity of the allocated ports.
Stiemerling, et al. [Page 41]
Internet-Draft MIDCOM Protocol Semantics June 2007
- service: The selected service in the case of mixed traditional
and twice-NAT middlebox (see section 2.3.8).
- policy rule lifetime: The remaining lifetime of the policy rule.
failure reason:
- transaction not supported
- agent not authorized for this transaction
- no such policy rule
- agent not authorized to access this policy rule
semantics:
The agent can use this transaction type to list all properties of
a policy rule. Usually, the agent has this information already,
but in special cases (for example, after an agent fail-over) or
for special agents (for example, an administrating agent that can
access all policy rules) this transaction can be helpful.
The middlebox first checks whether the specified policy rule
exists and whether the agent is authorized to access this group.
If one of the checks fails, an appropriate failure reply is
generated. Otherwise all properties of the policy rule are
returned to the agent. Some of the returned parameters may be
irrelevant, depending on the policy rule action ('reserve' or
'enable') and depending on other parameters -- for example, the
protocol identifier.
This transaction does not have any effect on the policy rule
state.
2.3.13. Asynchronous Policy Rule Event (ARE)
transaction-name: asynchronous policy rule event
transaction-type: asynchronous
transaction-compliance: mandatory
notification message type: Policy Rule Event Notification (REN)
semantics:
The middlebox may decide at any point in time to terminate a
policy rule. This transaction is triggered most frequently by
lifetime expiration of the policy rule. Among other events that
Stiemerling, et al. [Page 42]
Internet-Draft MIDCOM Protocol Semantics June 2007
may cause this transaction are changes in the policy rule decision
point.
The middlebox sends an REN message to all agents that participate
in an open session with the middlebox and that are authorized to
access the policy rule. The notification is sent to the agents
before the middlebox changes the policy rule's lifetime. The
change of lifetime may be triggered by any other authorized agent
and results in shortening (lt_new < lt_existing), extending
(lt_new > lt_existing), or terminating the policy rule
(lt_new = 0).
The ARE transaction corresponds to the REN message handling described
in section 2.3.4 for multiple agents.
2.3.14. Policy Rule State Machine
The state machine for the policy rule transactions is shown in Figure
4 with all possible state transitions. The used transaction
abbreviations may be found in the headings of the particular
transaction section.
PRR/success +---------------+
+-----------------+ PRID UNUSED |<-+
+----+ | +---------------+ |
| | | ^ | |
| v v | | |
| +-------------+ ARE | | PER/ | ARE
| | RESERVED +------------+ | success | RLC(lt=0)/
| +-+----+------+ RLC(lt=0)/ | | success
| | | success | |
+----+ | v |
RLC(lt>0)/ | PER/success +---------------+ |
success +---------------->| ENABLED +--+
+-+-------------+
| ^
lt = lifetime +-----------+
RLC(lt>0)/success
Figure 4: Policy Rule State Machine
This state machine exists per policy rule identifier (PRID).
Initially all policy rules are in state PRID UNUSED, which means that
the policy rule does not exist or is not active. After returning to
state PRID UNUSED, the policy rule identifier is no longer bound to
an existing policy rule and may be reused by the middlebox.
Stiemerling, et al. [Page 43]
Internet-Draft MIDCOM Protocol Semantics June 2007
A successful PRR transaction causes a transition from the initial
state PRID UNUSED to the state RESERVED, where an address reservation
is established. From there, state ENABLED can be entered by a PER
transaction. This transaction can also be used for entering state
ENABLED directly from state PRID UNUSED without a reservation. In
state ENABLED the requested communication between the internal and
the external endpoint is enabled.
The states RESERVED and ENABLED can be maintained by successful RLC
transactions with a requested lifetime greater than 0. Transitions
from both of these states back to state PRID UNUSED can be caused by
an ARE transaction or by a successful RLC transaction with a lifetime
parameter of 0.
A failed request transactions does not change state at the middlebox.
Note that transitions initiated by RLC transactions may also be
initiated by GLC transactions.
2.4. Policy Rule Group Transactions
This section describes the semantics for transactions on groups of
policy rules. These transactions are specified as follows:
- Group Lifetime Change (GLC)
- Group List (GL)
- Group Status (GS)
All are request transactions initiated by the agent. GLC is a
configuration transaction. GL and GS are monitoring transactions
that do not have any effect on the group state machine.
2.4.1. Overview
A policy rule group has only one attribute: the list of its members.
All member policies of a single group must be owned by the same
authenticated agent. Therefore, an implicit property of a group is
its owner, which is the owner of the member policy rules.
A group is implicitly created when its first member policy rule is
established. A group is implicitly terminated when the last
remaining member policy rule is terminated. Consequently, the
lifetime of a group is the maximum of the lifetimes of all member
policy rules.
A group has a middlebox-unique identifier.
Stiemerling, et al. [Page 44]
Internet-Draft MIDCOM Protocol Semantics June 2007
Policy Rule Group transactions are declared as 'optional' by their
respective compliance entry in section 3. However, they provide some
functionalities, such as convenience for the agent in sending only
one request instead of several, that is not available if only
mandatory transactions are available.
The Group Lifetime Change (GLC) transaction is equivalent to
simultaneously performed Policy Rule Lifetime Change (RLC)
transactions on all members of the group. The result of a successful
GLC transaction is that all member policy rules have the same
lifetime. As with the RLC transaction, the GLC transaction can be
used to delete all member policy rules by requesting a lifetime of
zero.
The monitoring transactions Group List (GL) and Group Status (GS) can
be used by the agent to explore the state of the middlebox and to
explore its access rights. The GL transaction lists all groups that
the agent may access, including groups owned by other agents. The GS
transaction reports the status on an individual group and lists all
policy rules of this group by their policy rule identifiers. The
agent can explore the state of the individual policy rules by using
the policy rule identifiers in a policy rule status (PRS) transaction
(see section 2.3.12).
The GL and GS transactions are particularly helpful in case of an
agent fail-over. The agent taking over the role of a failed one can
use these transactions retrieve whichever policies have been
established by the failed agent.
Notifications on group events are generated analogously to policy
rule events. To notify agents about group events, the Policy Rule
Group Event Notification (GEN) message type is used. GEN messages
contain an agent-unique notification identifier, the policy rule
group identifier, and the remaining lifetime of the group.
2.4.2. Group Lifetime Change (GLC)
transaction-name: group lifetime change
transaction-type: configuration
transaction-compliance: optional
request-parameters:
- request identifier: An agent-unique identifier for matching
corresponding request and reply at the agent.
Stiemerling, et al. [Page 45]
Internet-Draft MIDCOM Protocol Semantics June 2007
- group identifier: A reference to the group for which the
lifetime is requested to be changed.
- group lifetime: The new lifetime proposal for the group.
reply-parameters (success):
- request identifier: An identifier matching the identifier of the
request.
- group lifetime: The group lifetime granted by the middlebox.
failure reason:
- transaction not supported
- agent not authorized for this transaction
- agent not authorized to change lifetime of this group
- no such group
- lifetime cannot be extended
notification message type: Policy Rule Group Event Notification (GEN)
semantics:
The agent can use this transaction type to request an extension of
the lifetime of all members of a policy rule group, to request
shortening the lifetime of all members, or to request termination
of all member policies (which implies termination of the group).
Termination is requested by suggesting a new group lifetime of
zero.
The middlebox first checks whether the specified group exists and
whether the agent is authorized to access this group. If one of
the checks fails, an appropriate failure reply is generated. If
the requested lifetime is longer than the current one, the
middlebox also checks whether the lifetime of the group may be
extended and generates an appropriate failure message if it may
not.
A failure reply implies that the lifetime of the group remains
unchanged. A success reply is generated by the middlebox if the
lifetime of the group was changed in any way.
The success reply contains the new common lifetime of all member
policy rules of the group. The middlebox chooses the new lifetime
less than or equal to the minimum of the requested lifetime and
the maximum lifetime that the middlebox specified at session setup
along with its other capabilities, i.e.,
Stiemerling, et al.