One document matched: draft-stiemerling-midcom-semantics-02.txt
Differences from draft-stiemerling-midcom-semantics-01.txt
Internet Draft M. Stiemerling
Document: draft-stiemerling-midcom-semantics-02.txt J. Quittek
Expires: February 2003 NEC Europe Ltd.
August 2002
MIDCOM Protocol Semantics
<draft-stiemerling-midcom-semantics-02.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. 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
Distribution of this document is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
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 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 a superset of it. The MIDCOM
protocol semantics is derived from the MIDCOM requirements, from the
MIDCOM framework, and from working group decisions.
Stiemerling & Quittek [Page 1]
Internet-Draft MIDCOM Protocol Semantics August 2002
Table of Contents
1 Introduction ................................................. 2
1.1 Terminology ................................................ 3
1.2 Transaction Definition Template ............................ 3
2 Semantics Specification ...................................... 5
2.1 General Protocol Design .................................... 5
2.1.1 Session, Policy, and Policy Group ........................ 5
2.1.2 Atomicity ................................................ 5
2.1.3 Access Control ........................................... 6
2.1.4 Conformance .............................................. 6
2.2 Session Control Transactions ............................... 7
2.2.1 Session Establishment (SE) ............................... 7
2.2.2 Session Termination (ST) ................................. 9
2.2.3 Asynchronous Session Termination (AST) ................... 10
2.2.4 Session Termination by Interruption of Connection ........ 11
2.2.5 Session State Machine .................................... 11
2.3 Policy Group Transactions .................................. 12
2.3.1 Group Establishment (GE) ................................. 13
2.3.2 Group Lifetime Change (GLC) .............................. 14
2.3.3 Group List (GL) .......................................... 15
2.3.4 Group Status (GS) ........................................ 16
2.3.5 Asynchronous Group Deletion (AGD) ........................ 17
2.3.6 Group State Machine ...................................... 18
2.4 Policy Rule Transactions ................................... 19
2.4.1 Policy Reserve Rule (PRR) ................................ 20
2.4.2 Policy Allow Rule (PAR) .................................. 23
2.4.3 Policy Lifetime Change (PLC) ............................. 27
2.4.4 Policy Status (PS) ....................................... 28
2.4.5 Asynchronous Policy Deletion (APD) ....................... 31
2.4.6 Policy Rule State Machine ................................ 31
3 Conformance Statements ....................................... 32
3.1 General Implementation Conformance ......................... 33
3.2 Middlebox Conformance ...................................... 33
3.3 Agent Conformance .......................................... 34
4 Transaction Usage Examples ................................... 34
4.1 Exploring Policies and Policy Groups ....................... 34
4.2 Enabling a SIP-Signaled Call ............................... 38
5 Compliance with MIDCOM Requirements .......................... 42
5.1 Protocol Machinery Requirements ............................ 42
5.1.1 Authorized Association ................................... 42
5.1.2 Agent connects to Multiple Middleboxes ................... 42
5.1.3 Multiple Agents connect to same Middlebox ................ 43
5.1.4 Deterministic Behavior ................................... 43
5.1.5 Known and Stable State ................................... 43
5.1.6 Status Report ............................................ 44
5.1.7 Unsolicited Messages (Asynchronous Notifications) ........ 44
5.1.8 Mutual Authentication .................................... 44
5.1.9 Session Termination by any Party ......................... 44
5.1.10 Request Result .......................................... 44
Stiemerling & Quittek [Page 2]
Internet-Draft MIDCOM Protocol Semantics August 2002
5.1.11 Version Interworking .................................... 45
5.1.12 Deterministic Handling of Overlapping Rules ............. 45
5.2 Protocol Semantics Requirements ............................ 45
5.2.1 Extensible Syntax and Semantics .......................... 45
5.2.2 Policy Rules for Different Types of Middleboxes .......... 45
5.2.3 Ruleset Groups ........................................... 45
5.2.4 Policy Lifetime Extension ................................ 46
5.2.5 Robust Failure Modes ..................................... 46
5.2.6 Failure Reasons .......................................... 46
5.2.7 Multiple Agents Manipulating Same Policy ................. 46
5.2.8 Carrying Filtering Rules ................................. 46
5.2.9 Oddity of Port Numbers ................................... 46
5.2.10 Consecutive Range of Port Numbers ....................... 46
5.2.11 Contradicting Overlapping Policies ...................... 47
5.3 Security Requirements ...................................... 47
5.3.1 Authentication, Confidentiality, Integrity ............... 47
5.3.2 Optional Confidentiality of Control Messages ............. 47
5.3.3 Operation across Un-trusted Domains ...................... 47
5.3.4 Mitigate Replay Attacks .................................. 47
6 Security Considerations ...................................... 47
7 Acknowledgments .............................................. 48
8 Open Issues .................................................. 48
9 Acknowledgements ............................................. 48
10 References .................................................. 48
11 Authors' Address ............................................ 49
12 Full Copyright Statement .................................... 49
1. Introduction
The MIDCOM working group has defined a framework [MDC-FRM] for the
middle box communication as well as a list of requirements [MDC-REQ].
But for specifying a concrete protocol, the clear semantics need to
be defined. The documents mentioned above are not completely
sufficient for this purpose. Some required capabilities are not
mentioned explicitly in the framework or requirements document, but
are inherent to the problem.
This memo suggests a semantics for the MIDCOM protocol. It is fully
compliant with the requirements listed in [MDC-REQ] and with the
working groups consensus on semantical issues.
In conformance with the working group charter, the semantics is
targeted at packet filters and network address translators (NATs) and
it supports applications that require dynamic configuration of these
middleboxes.
The semantics are defined in terms of transactions. Two basic types
of transactions are used: request-reply transactions and notification
transactions. For each transaction the semantics is specified by
Stiemerling & Quittek [Page 3]
Internet-Draft MIDCOM Protocol Semantics August 2002
describing (1) the parameters of the transaction, (2) the processing
(of request transactions) at the middlebox, and (3) the state
transitions at the middlebox caused by the transactions.
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. Anyway, the semantics below will still be a subset of
the implemented semantics.
The document contains four major sections. Section 2 describes the
protocol semantics. It is structured in four subsections:
- General Protocol Issues (Section 2.1)
- Session Control (Section 2.2)
- Policy Groups (Section 2.3)
- Policy Rules (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 message transfer from the agent
and to the middlebox followed by a reply
message transfer from the middlebox to the
agent.
notification transaction An asynchronous message transfer from the
middlebox and to the agent.
agent unique An agent unique value is unique in the
context of the agent. This context
includes all MIDCOM session 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 session the middlebox
Stiemerling & Quittek [Page 4]
Internet-Draft MIDCOM Protocol Semantics August 2002
participates in. A middlebox unique value
is assigned by the middlebox.
1.2. Transaction Definition Template
In the following sections semantics of the MIDCOM protocol is
specified per transaction. A transaction specification contains the
following entries. (Parameter entities are only specified if
applicable.)
transaction-name
A description name for this type of transaction.
transaction-type
The transaction type is either 'request' or 'notification'. See
above for the description of request transaction and notification
transaction.
transaction-compliance
This entry contains either 'mandatory' or 'optional'. For details
see Section 2.1.4.
request-parameter
This entry lists all parameters that are necessary for this
request. A description for each parameter is given.
reply-parameter (success)
This entry lists all parameters that are sent back from the
middlebox to the agent as positive response to the prior request.
A description for each parameter is given.
reply-parameter (failure)
This entry lists all parameters that are sent back from the
middlebox to the agent as negative response to the prior request.
A description for each parameter is given.
notification parameters
This entry lists all parameters that are used by the middlebox to
notify the agent about any asynchronous event. A description for
each parameter is given.
semantics
This entry describes the actual semantics of the transaction.
Stiemerling & Quittek [Page 5]
Internet-Draft MIDCOM Protocol Semantics August 2002
2. Semantics Specification
2.1. General Protocol Design
A major goal of the semantics is finding a good balance between
properly support of applications that require dynamic configuration
of middleboxes and simplicity of specification and implementation of
the protocol.
The MIDCOM protocol will be subdivided into three phases as specified
in Section 4 of [MDC-FRM]:
- session setup phase
- run-time phase
- session termination phase
In all phases two kinds of state transitions may occur at the
middlebox: State transactions either are initiated by a requests from
the agent to the middlebox, or they are initiated by any other event.
In the first case the middlebox informs the agent by sending a reply
on the actual state transition, in latter case the middlebox sends a
notification to the agent. Requests and replies contain an agent
unique request identifier that allows the agent to determine to which
sent request a received reply corresponds.
2.1.1. Session, Policy, and Policy Group
An analysis of the requirements showed that three kinds of
transactions are required: transactions for session control,
transactions for controlling of policies, and transaction for
controlling policy groups. Policy groups can be used to indicated
relationships between policies and to simplify transactions on a set
of policies by using a single one per group instead of one per
policy.
Requirement analysis also showed that session state, policy state,
and policy group state can be separated. The separation simplifies
the specification of the semantics as well as a protocol
implementation. Therefore, the semantics specification is structured
accordingly and we use three separated state machines to illustrate
the semantics. Please note, that state machines of concrete protocol
designs and implementations will most probably more complex than the
state machines presented here. However, the protocol state machines
are expected to be a superset of the state machines in this document.
2.1.2. Atomicity
All request transactions are atomic with respect to each other. This
means that processing a request at the middlebox is never interrupted
by another arriving or already queued request. This particularly
applies when the middlebox concurrently receives requests originating
Stiemerling & Quittek [Page 6]
Internet-Draft MIDCOM Protocol Semantics August 2002
in different session. However, asynchronous notification transactions
may interrupt and terminate processing of a request at any time.
All request transactions are atomic from the point of view of the
agent. Processing of a request does not start before the complete
request arrived 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 close to a minimal set
that still meets the requirements. For a real implementation of the
protocol, it might be required to split some of the transactions
specified below into two or more transactions of the respective
protocol. Reasons for this might be constraints of the particular
protocol or the desire for more flexibility. In general this should
not be a problem. However, it should be considered that this might
change atomicity of the affected transactions.
2.1.3. Access Control
Access to policies and policy groups is based on ownership. When a
policy or a group is created, a middlebox unique identifier is
generated for identifying it in further transactions. Beyond the
identifier, each group has an owner. The owner is the authenticated
agent that established the policy or group. The middlebox uses the
owner attribute of a policy or group for controlling access to it:
each time an authenticated agent requests to modify an existing
policy or group, the middlebox determines the owner of the policy or
group and checks if the requesting agent is authorized to perform
transactions on the owning agent's policies or groups.
By configuring the middlebox, certain authenticated agents may get
authorized to access and modify groups with certain owner.
Certainly, a reasonable default configuration would be that each
agent can access its own groups. Also, it might be a good idea, to
have an agent identity configured to act as administrator being
allowed to modify all policies owned by any agent. Anyway, the
configuration of authorization is not subject of the MIDCOM protocol
semantics.
2.1.4. Conformance
The MIDCOM requirements in [MDC-REQ] demand certain capabilities of
the MIDCOM protocol, which are met by the set of transactions
specified below. However, an actual implementation of a middlebox
may support only a subset of these transactions. Support limitation
may be different for different authenticated agents. At session
establishment, the middlebox informs the authenticated agent by
capability exchange, which transactions the agent is authorized to
perform. Some transactions need to be offered to every authenticated
Stiemerling & Quittek [Page 7]
Internet-Draft MIDCOM Protocol Semantics August 2002
agent.
Each transaction definitions below has a conformance entry which
contains either 'mandatory' or 'optional'. A mandatory transaction
need to be implemented by every middlebox offering MIDCOM service. A
mandatory request transaction must be offered to each of the
authenticated agents. An optional transaction does not necessarily
need to be implemented by a middlebox. An implemented optional
request transaction does not necessarily need to be offered to every
authenticated agent. Whether or not 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 groups is possible,
a valid MIDCOM session must be established. A MIDCOM session is an
authorized association between agent and middlebox. Sessions are
initiated by agents and can be terminated by any party. Both agent
and middlebox may participate in several sessions at the same time.
For distinguishing different sessions each party uses local session
identifiers.
Session control is supported by three transactions:
- Session Establishment (SE)
- Session Termination (ST)
- Asynchronous Session Termination (AST)
The first two are request transactions initiated by the agent, the
last one is a notification transaction initiated by the middlebox.
2.2.1. Session Establishment (SE)
transaction-name: session establishment
transaction-type: request
transaction-compliance: mandatory
request-parameters:
- request identifier: an agent unique identifier for matching
corresponding request and reply at the agent.
- version: the version of the MIDCOM protocol
- middlebox authentication challenge (mc): an authentication
challenge token for the middlebox authentication.
Stiemerling & Quittek [Page 8]
Internet-Draft MIDCOM Protocol Semantics August 2002
- agent authentication (aa): an authentication token to
authenticate the agent to the middlebox.
- encryption method: an identifier of an encryption method. Also
'no encryption' may be specified.
reply-parameters (success):
- request identifier: an identifier matching the identifier
request.
- middlebox authentication (ma): an authentication token to
authenticate the middlebox to the agent.
- agent challenge token (ac): an authentication challenge token for
the agent authentication.
- middlebox capabilities: a parameter set describing the
middlebox's capabilities. The set includes
- type of the middlebox
for example: FW, NAT, NATFW, NAPT, NAPTFW, NAT-PT, NAT-PTFW,
...)
- IP address wildcard support
- port wildcard support
- supported IP version(s) for internal network:
IPv4, IPv6, or both
- supported IP version(s) for external network:
IPv4, IPv6, or both
- list of supported optional MIDCOM protocol transactions
- policy rule persistency: persistent or not persistent
- maximum remaining lifetime of a policy rule or policy group
reply-parameters (failure):
- request identifier: an identifier matching the identifier
request.
- failure reason: the reason why the session establishment
transaction failed. The list of possible reasons includes but is
not restricted to:
- authentication failed
- no authorization
- protocol version of agent and middlebox do not match
- encryption method not supported
- lack of resources
semantics:
This session establishment transaction is used to establish a
MIDCOM session. For mutual authentication of both parties two
Stiemerling & Quittek [Page 9]
Internet-Draft MIDCOM Protocol Semantics August 2002
subsequent session establishment transactions are required as
shown in Figure 1.
agent middlebox
| session establishment request |
| (with middlebox challenge mc) |
|-------------------------------------------->|
| |
| successful reply (with middlebox |
| authentication ma and agent challenge ac) |
|<--------------------------------------------|
| |
| session establishment request |
| (with agent authentication aa) |
|-------------------------------------------->|
| |
| successful reply |
|<--------------------------------------------|
| |
Figure 1: Mutual authentication of agent and middlebox
Session establishment may be simplified by using only a single
transaction. In this case server challenge and agent challenge
are omitted by the sender or ignored by the receiver, and
authentication must be provided by other means, for example by TLS
[RFC2246] or IPSEC [RFC2402][RFC2406].
The middlebox checks with its policy decision point if the
requesting agent is authorized to open a MIDCOM session. If not a
negative reply with 'no authorization' as failure reason is
generated by the middlebox. If authentication and authorization
are successful, the session is established and the agent may start
with requesting transactions on policy rules and policy groups.
Part of the successful reply is an indication of the middlebox's
capabilities. The list of capabilities to be included needs to be
further elaborated.
The agent specifies an encryption method for the session including
the option of not using encryption. The middlebox can accept this
suggestion or reject it. In case of rejection, the session
establishment fails and an appropriate failure reason is indicated
by the middlebox in the reply message. Then the agent may try
session setup again with a different encryption method.
2.2.2. Session Termination (ST)
transaction-name: session termination
Stiemerling & Quittek [Page 10]
Internet-Draft MIDCOM Protocol Semantics August 2002
transaction-type: request
transaction-compliance: mandatory
request-parameters:
- request identifier: an agent unique identifier for matching
corresponding request and reply at the agent.
reply-parameters (success only):
- request identifier: an identifier matching the identifier
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 groups and policy rules until their lifetime
expires or until an event occurs on which the middlebox terminates
them.
The middlebox generates always 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, which it has received while
it was processing the session termination request, or which it
receives later.
2.2.3. Asynchronous Session Termination (AST)
transaction-name: asynchronous session termination
transaction-type: notification
transaction-compliance: mandatory
notification-parameters:
- termination reason: The reason why the session is terminated
without any request from the agent.
semantics:
The middlebox may decide at any point in time to terminate a
MIDCOM session. Before terminating the actual session the middle
box generates this notification transaction. After sending the
notification, the middlebox will not process any further request
by the agent, even if it is already queued at the middlebox.
Stiemerling & Quittek [Page 11]
Internet-Draft MIDCOM Protocol Semantics August 2002
After session termination the middlebox keeps all established
policy groups and policy rules until their lifetime expires or
until an event occurs on which the middlebox terminates them.
2.2.4. Session Termination by Interruption of Connection
If a MIDCOM session is based on an underlying network connection,
then 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 groups and 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 used transaction
abbreviations can be found in the headings of the particular
transaction section.
All sessions start in state CLOSED. A successful SE transaction can
cause a state transition to state OPEN, if mutual authentication is
already provided by other means. Otherwise, it causes a transition
to state NOAUTH. From this state a failed SE transaction returns to
state closed, as well as a successful ST transaction. A successful
SE transaction causes a transition to state OPEN. At any time an AST
transaction may occur causing a transition to state CLOSED.
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
Stiemerling & Quittek [Page 12]
Internet-Draft MIDCOM Protocol Semantics August 2002
2.3. Policy Group Transactions
This section describes the semantics for transactions on groups of
policies. The following transactions are specified:
- Group Establishment (GE)
- Group Lifetime Change (GLC)
- Group List (GL)
- Group Status (GS)
- Asynchronous Group Deletion (AGD)
The first four are request transactions initiated by the agent, the
last one is a notification transaction initiated by the middlebox.
The status information transactions (GL and GS) do not have any
effect on the group state machine.
Group transactions are redundant in the sense that a transaction on a
group can be replaced by the corresponding transaction on each member
of a group (except for the GE transaction). They can be removed
easily from the semantics specification without changing the set of
possible middlebox configurations an agent can request. Therefore
all of them are declared as 'optional' by their respective compliance
entry.
Before any group request can be processed a valid MIDCOM session must
have been established. The establishment of groups is a premise of
any further policy establishment. However, there is a default group
which is automatically established by the middlebox for every
authenticated agent. This group has unlimited lifetime and cannot be
controlled by a GE or GLC transaction. It has to be used by the
agent if the middlebox does not offer group transactions. But it may
be used by the agent at any time. It is addressed by a fixed group
identifier value.
Each policy is member of exactly one group, and membership does not
change during policy lifetime.
Each group that is not a default group has its individual lifetime.
If the group lifetime expires, the group and all member policies will
be deleted at the middlebox. A group lifetime change (GLC)
transaction may extend the lifetime of the group up to the limit
specified at session setup, when the middlebox informs the agent
about its capabilities. Also a GLC transaction may be used for
deleting a group by requesting a lifetime of 0. After a successful
GLC transaction, all member policies have the same lifetime as the
group. Please note that by policy-specific transactions, the
lifetime of an individual policy may be set to other values than the
group lifetime, but an individual policy lifetime may never exceed
the group lifetime.
Stiemerling & Quittek [Page 13]
Internet-Draft MIDCOM Protocol Semantics August 2002
The status information transactions GL and GS can be used by the
agent for exploring the state of the middlebox and for exploring 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 of an individual group and it lists
all policies of this group by their policy identifers. The agent can
explore the state of the individual policies by using the policy
identifiers in a policy information transaction (see Section 2.4.4).
2.3.1. Group Establishment (GE)
transaction-name: group establishment
transaction-type: request
transaction-compliance: optional
request-parameters:
- request identifier: an agent unique identifier for matching
corresponding request and reply at the agent.
- group lifetime: a lifetime proposal to the middlebox for the
requested group.
reply-parameters (success):
- request identifier: an identifier matching the identifier
request.
- group identifier: a middlebox unique group identifier. It is
assigned by the middlebox and used as group handle in further
group transactions and in policy transactions adding policies to
the group.
- group lifetime: the group lifetime granted by the middlebox.
reply-parameters (failure):
- request identifier: an identifier matching the identifier
request.
- failure reason: the reason why the group establishment was
rejected. The list of possible reasons includes but is not
restricted to:
- transaction not supported
- agent not authorized for this transaction
- lack of resources
semantics:
Stiemerling & Quittek [Page 14]
Internet-Draft MIDCOM Protocol Semantics August 2002
This transaction creates an empty group with no policy being
member of. The middlebox generates a middlebox unique identifier
for the new group and assigns the requesting agent to be the group
owner. The lifetime of the group is proposed by the agent. In
case of a success reply, the middlebox chooses a lifetime value
that is greater than zero and smaller than or equal to the
proposed value. If the middlebox decides not to create a new
group, a failure reply is generated containing a specification of
the reason for failure.
2.3.2. Group Lifetime Change (GLC)
transaction-name: group lifetime change
transaction-type: request
transaction-compliance: optional
request-parameters:
- request identifier: an agent unique identifier for matching
corresponding request and reply at the agent.
- 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
request.
- group lifetime: The remaining group lifetime granted by the
middlebox.
reply-parameters (failure):
- request identifier: an identifier matching the identifier
request.
- failure reason: the reason why the lifetime change was rejected.
The list of possible reasons includes but is not restricted to:
- transaction not supported
- agent not authorized for this transaction
- agent not authorized for changing lifetime of this group
- no such group
- this transaction cannot be applied to the default group
- lifetime cannot be extended
Stiemerling & Quittek [Page 15]
Internet-Draft MIDCOM Protocol Semantics August 2002
semantics:
The agent can use this transaction type to request an extension
the lifetime of an already established group, to request
shortening of the life time, or to request group termination which
includes termination of all member policies. Group termination is
requested by suggesting a new group lifetime of zero.
The middlebox first checks whether or not the specified group
exists and whether or not the agent is authorized to access this
group. If one of the checks fails, an appropriate failure reply
is generated. Also a failure reply is generated if the
transaction is applied to the agent's default group. If the
requested lifetime is longer than the current one, the middlebox
also checks, whether or not the lifetime of the group may be
extended and generates an appropriate failure message if not.
A failure reply is 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 lifetime of the group. The
middlebox chooses the lifetime within the interval limited by the
lifetime of the group at arrival of the request and by the
suggested lifetime. The granted remaining lifetime must not
exceed the maximum lifetime that the middlebox specified at
session setup together with its other capabilities.
A changed lifetime is applied to each member of the group. After
sending a success reply with a lifetime of zero, the member
policies will be deleted without any further notification to the
agent, and the middlebox will consider the group and its members
to be non-existent. It will not process any further transaction
on this group or on any of its members.
2.3.3. Group List (GL)
transaction-name: group list
transaction-type: request
transaction-compliance: optional
request-parameters:
- request identifier: an agent unique identifier for matching
corresponding request and reply at the agent.
reply-parameters (success):
Stiemerling & Quittek [Page 16]
Internet-Draft MIDCOM Protocol Semantics August 2002
- request identifier: an identifier matching the identifier
request.
- group list: list of all groups that the agent can access. For
each listed group the identifier and the owner are indicated.
reply-parameters (failure):
- request identifier: an identifier matching the identifier
request.
- failure reason: the reason why the request for listing groups was
rejected. The list of possible reasons includes but is not
restricted to:
- transaction not supported
- agent not authorized for this transaction
semantics:
The agent can use this transaction type to list all groups which
it can access, including default groups. Usually, the agent has
this information already, but in special cases (for example after
an agent failover) or for special agents (for example an
administrating agent that can access all groups) this transaction
can be helpful.
The middlebox first checks whether or not the agent is authorized
to request this transaction. If the checks fails, an appropriate
failure reply is generated. Otherwise a list of all groups the
agent can access is returned indicating the identifier and the
owner each group. The shortest possible list to be replied
contains just the requesting agent's default group.
This transaction does not have any effect on the group state.
2.3.4. Group Status (GS)
transaction-name: group status
transaction-type: request
transaction-compliance: optional
request-parameters:
- request identifier: an agent unique identifier for matching
corresponding request and reply at the agent.
- group identifier: a reference to the group for which status
information is requested.
Stiemerling & Quittek [Page 17]
Internet-Draft MIDCOM Protocol Semantics August 2002
reply-parameters (success):
- request identifier: an identifier matching the identifier
request.
- group owner: an identifier of the agent owning this policy group.
- group lifetime: the remaining lifetime of the group.
- member list: list of all policies that are members of the group.
The policies are specified by their middlebox unique policy
identifier.
reply-parameters (failure):
- request identifier: an identifier matching the identifier
request.
- failure reason: the reason why the request for a status report
was rejected. The list of possible reasons includes but is not
restricted to:
- transaction not supported
- agent not authorized for this transaction
- no such group
- agent not authorized for listing members of this group
semantics:
The agent can use this transaction type to list all member
policies of a group. Usually, the agent has this information
already, but in special cases (for example after an agent
failover) or for special agents (for example an administrating
agent that can access all groups) this transaction can be helpful.
The middlebox first checks whether or not the specified group
exists and whether or not the agent is authorized to access this
group. If one of the checks fails, an appropriate failure reply
is generated. Otherwise a list of all group members is returned
indicating the identifier of each group. If the list of member
policies is empty, a successful reply is returned containing an
empty list.
This transaction does not have any effect on the group state.
2.3.5. Asynchronous Group Deletion (AGD)
transaction-name: asynchronous group deletion
transaction-type: notification
Stiemerling & Quittek [Page 18]
Internet-Draft MIDCOM Protocol Semantics August 2002
transaction-compliance: optional
notification-parameters:
- group identifier: a reference to the group that will be deleted.
- deletion reason: the reason why the middlebox will delete the
group including all member policies.
semantics:
The middlebox may decide at any point in time to delete a group.
Particularly, this transaction is triggered by lifetime expiration
of the group. Among other events that may cause this transaction
are changes in the policy decision point.
If this notification is generated, it is sent to all agents that
are in an open session with the middlebox and that are authorized
to access the group. The notification is sent to the agents
before the middlebox deletes the group and its member policies.
The member policies will be deleted without any further
notification to the agents. After sending the notification, the
middlebox will consider the group and all its members to be non-
existent. It will not process any further transaction on the
group or on any of its members.
2.3.6. Group State Machine
A state machine illustrating the semantics of the transactions on
groups is shown in Figure 3. The used transaction abbreviations can
be found in the headings of the particular transaction section.
This state machine exists per group identifier. Initially, all
groups are in state GROUP UNUSED, which means that the group does not
exist. A successful GE transaction causes a transition to state
GROUP INUSE. From there the state returns to GROUP UNUSED with a
successful GLC transaction requesting a lifetime of zero and with an
AGD transaction. After returning to state GROUP UNUSED, the group
identifier is not anymore bound to an existing group and may be re-
used by the middlebox.
Stiemerling & Quittek [Page 19]
Internet-Draft MIDCOM Protocol Semantics August 2002
GE/failure
+--------+
| v
+----------+
| GROUP |
| UNUSED |
+----------+
| ^
GE/success | | GLC(lt=0)/success
| | AGD
v |
+----------+
| GROUP |
| INUSE |
+----------+
| ^
+--------+
GLC(lt>0)/
success lt = lifetime
GLC/failure
Figure 3: Group State Machine
2.4. Policy Rule Transactions
This section describes the semantics for transactions on policies.
The following transactions are specified:
- Policy Reserve Rule (PRR)
- Policy Allow Rule (PAR)
- Policy Lifetime Change (PLC)
- Policy Status (PS)
- Asynchronous Policy Deletion (APD)
The first four are request transactions initiated by the agent, the
last one is a notification transaction initiated by the middlebox.
The status information transaction (PS) does not have any effect on
the policy state machine.
Policy transactions PAR and PLC constitute the core of the MIDCOM
protocol. Both are mandatory. They serve for
- configuring NAT bindings (PAR)
- configuring firewall pinholes (PAR)
- extending the lifetime of established policies (PLC)
- deleting policies (PLC)
In some cases it is required to know in advance which IP address (and
port number) would be chosen by NAT in a PAR transaction. This
Stiemerling & Quittek [Page 20]
Internet-Draft MIDCOM Protocol Semantics August 2002
information is required before sufficient information for performing
a complete PAR transaction is required (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)
A policy rule contains either a reserve action or an allow action.
The reserve action allocates IP addresses and port numbers at a NAT.
It does not have any function at a firewall. The allow action is
interpreted as as bind action at a NAT for establishing bindings
between internal and external addresses. At a firewall, the allow
action is interpreted as one or more allow actions. The number of
allow actions depends on the parameters of the request and the
implementation of the firewall. For a more detailed description, see
Sections 2.4.1. and 2.4.2. below.
When a policy is established, it immediately becomes a member of one
of the groups the agent may access. Each policy is member of exactly
one group, and membership does not change during policy lifetime. If
an agent does not need to group policies, it may just use its default
group and have all policies being member of it. A default group is
automatically generated by the middlebox for each authenticated
agent.
Each policy has its individual lifetime. If the policy lifetime
expires, the policy will be deleted at the middlebox. A policy
lifetime change (PLC) transaction may extend the lifetime of the
policy up to the limit specified at session setup. Also a PLC
transaction may be used for deleting a policy by requesting a
lifetime of 0. Pease note that policy lifetime may also be modified
by the group lifetime change transaction.
The agent can explore the status of any policy by using the Policy
Status (PS) transaction.
2.4.1. Policy Reserve Rule (PRR)
transaction-name: policy reserve rule
transaction-type: request
transaction-compliance: optional
request-parameters:
- request identifier: an agent unique identifier for matching
corresponding request and reply at the agent.
Stiemerling & Quittek [Page 21]
Internet-Draft MIDCOM Protocol Semantics August 2002
- group identifier: a reference to the group of which the reserve
policy should be a member.
- protocol identifier: identifies the protocol for which a
reservation is requested. Examples are 'IP', 'UDP', and 'TCP'.
- port range: the number of consecutive ports numbers to be
reserved. This parameter is irrelevant, if the protocol
identifier does not have the value 'TCP' or 'UDP'.
- port oddity: the requested oddity of the port number to be
reserved. Allowed values of this parameter are 'odd', 'even',
and 'any'.
- side of middlebox: the value of this parameter is either 'inside'
or 'outside'. For an outside reservation, a reservation of an
external address at the middlebox is requested, for an inside
reservation, an internal address reservation at the middlebox is
requested.
- policy lifetime: a lifetime proposal to the middlebox for the
requested policy.
reply-parameters (success):
- an identifier matching the identifier request.
- policy identifier: a middlebox unique policy rule identifier. It
is assigned by the middlebox and used as policy rule handle in
further policy transactions.
- reserved IP address: The reserved IPv4 or IPv6 address.
- reserved port number: The reserved port number. In case of a
port range greater than 1, it is the lowest port number of a
consecutive sequence of reserved port numbers. This parameter is
irrelevant, if the in the protocol identifier of the request
parameters does not have the value 'TCP' or 'UDP'.
- policy lifetime: the policy lifetime granted by the middlebox.
reply-parameters (failure):
- an identifier matching the identifier request.
- failure reason: the reason why the reserve policy was rejected.
The list of possible reasons includes but is not restricted to:
- agent not authorized for this transaction
- agent not authorized for adding members to this group
- no such group
Stiemerling & Quittek [Page 22]
Internet-Draft MIDCOM Protocol Semantics August 2002
- no reservation of inside addresses supported
- no reservation of outside addresses supported
- lack of IP addresses
- lack of port numbers
- lack of resources
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 the middlebox. In some scenarios it is required to
perform such a reservation before sufficient parameters for a
complete policy allow rule transaction are available. See section
4.2 for an example. The reservation can be made for either side
of the NAT but not for both of them. So far, not scenario has
been found where reservation on both sides of the middlebox is
required. Typically reservations will be requested for external
addresses of a single-NAT. But for twice-NAT middleboxes, also
reservations of internal addresses are supported.
The middlebox first checks whether or not the specified group
exists and whether or not the agent is authorized to add members
to this group. If one of the checks fails, an appropriate failure
reply is generated.
In case of success, this transaction creates a new policy that
becomes a member of the specified group. The middlebox generates
a middlebox unique identifier for the new policy. The owner of
the new policy is the owner of the group. The middlebox chooses a
lifetime value that is greater than zero and smaller than or equal
to the proposed value and that is smaller than or equal to the
maximum lifetime specified at session setup.
If the protocol identifier is 'IP', then the middlebox reserves an
available internal or external IP address, depending on the
specified direction. Depending on the specified side of the
middlebox, either and internal address is reserved at the inside
of the middlebox or an external address is reserved at the outside
of the middlebox. The reserved address is returned to the agent.
In this case the request-parameters port range and port oddity and
the reply-parameter 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 oddity is reserved. As for the
protocol identifier 'IP', now the IP address is reserved as an
internal one or an external one depending on the specified side of
the middlebox. The IP address and the first reserved port number
of the consecutive sequence are returned to the agent.
Stiemerling & Quittek [Page 23]
Internet-Draft MIDCOM Protocol Semantics August 2002
If the reservation fails because of lack of resources, such as
available IP addresses, port numbers, or storage for further
policies, then an appropriate failure reply is generated.
2.4.2. Policy Allow Rule (PAR)
transaction-name: policy allow rule
transaction-type: request
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 allow
policy should be a member.
- reservation identifier: a reference to an already existing
reserve policy. As reference the policy identifier can be used.
The reference may be empty.
- protocol identifier: identifies the protocol for which a
reservation is requested. Examples are 'IP', 'UDP', and 'TCP'.
- port range: the number of consecutive ports numbers to be
reserved. This parameter is irrelevant, if the protocol
identifier does not have the value 'TCP' or 'UDP'.
- port oddity: the requested oddity of the port number(s) to be
mapped. Allowed values of this parameter are 'same' and 'any'.
- topology: location of reservation or direction of communication.
For the reserve action, this parameter specifies the side of the
middlebox, either 'inside' or 'outside'. For allow actions, this
parameter specifies the direction of allowed communication,
either 'inbound', 'outbound', or 'bi-directional'.
- internal IP address: the IP address of the internal communication
endpoint (A0 in Fig. 4). The address may be wildcarded, for
example by carrying a network mask.
- internal port number: the port number of the internal
communication endpoint (A0 in Fig. 4). The port number may be
wildcarded. This parameter is irrelevant, if the in the protocol
identifier does not have the value 'TCP' or 'UDP'.
Stiemerling & Quittek [Page 24]
Internet-Draft MIDCOM Protocol Semantics August 2002
- external IP address: the IP address of the external communication
endpoint (A3 in Fig. 4). The address may be wildcarded, for
example by carrying a network mask.
- external port number: the port number of the external
communication endpoint (A3 in Fig. 4). The port number may be
wildcarded. This parameter is irrelevant, if the in the protocol
identifier does not have the value 'TCP' or 'UDP'.
- policy lifetime: a lifetime proposal to the middlebox for the
requested policy.
reply-parameters (success):
- an identifier matching the identifier request.
- policy identifier: a middlebox unique policy rule identifier. It
is assigned by the middlebox and used as policy rule handle in
further policy transactions.
- inside IP address number: the internal IP address provided at the
inside of the NAT (A1 in Fig. 4). The address may be wildcarded,
for example by carrying a network mask.
- inside port number: the internal port number provided at the
inside of the NAT (A1 in Fig. 4). In case of a port range
greater than 1, it is the lowest port number of a consecutive
sequence of mapped port numbers. The port number may be
wildcarded. This parameter is irrelevant, if the in the protocol
identifier of the request parameters does not have the value
'TCP' or 'UDP'.
- outside IP address number: the external IP address provided at
the outside of the NAT (A2 in Fig. 4). The address may be
wildcarded, for example by carrying a network mask.
- outside port number: the external port number provided at the
outside of the NAT (A2 in Fig. 4). In case of a port range
greater than 1, it is the lowest port number of a consecutive
sequence of mapped port numbers. The port number may be
wildcarded. This parameter is irrelevant, if the in the protocol
identifier of the request parameters does not have the value
'TCP' or 'UDP'.
- policy lifetime: the policy lifetime granted by the middlebox.
reply-parameters (failure):
- an identifier matching the identifier request.
Stiemerling & Quittek [Page 25]
Internet-Draft MIDCOM Protocol Semantics August 2002
- failure reason: the reason why the allow policy was rejected.
The list of possible reasons includes but is not restricted to:
- agent not authorized for this transaction
- no such group
- agent not authorized for adding members to this group
- no such reserve policy
- the reserve policy is not member of the specified group
- agent not authorized for accessing this reserve policy
- mismatching protocol identifier in reserve policy
- conflict with already existing policy rule
- lack of IP addresses
- lack of port numbers
- lack of resources
semantics:
This transactions can be used by an agent for enabling
communication between an internal endpoint and an external
endpoint independent of the type of middlebox (NAT, NAPT,
firewall, NAT-PT, combined devices, ... ) for uni-directional or
bi-directional traffic.
The agent sends an allow request specifying the endpoints
(optionally including wildcards) and the direction of
communication (inbound, outbound, bi-directional). The
communication endpoints are displayed in Figure 4. They are
addressed by the address tuples A0 and A3, respectively. An
address tuple includes a protocol identifier, an IP address, and
optionally a port number and a port number range. The middlebox
replies to the allow request with a pair of communication address
tuples A1 and A2 to be used by the partners for addressing each
other.
+----------+ +----------+
| internal | A0 A1 +-----------+ A2 A3 | external |
| endpoint +----------+ middlebox +----------+ endpoint |
+----------+ +-----------+ +----------+
Policy Allow Rule (PAR) Transaction:
agent -> middlebox: A0, A3, direction
middlebox -> agent: A1, A2 (in case of success)
Figure 4: Communication endpoints in the PAR transaction
In case of a pure packet filtering firewall, the returned address
tuples are the same than the ones in the request: A2=A0 and A1=A3.
Each partner uses the other one'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 & Quittek [Page 26]
Internet-Draft MIDCOM Protocol Semantics August 2002
address tuple provided by the NAT (A2!=A0). In case of a twice-
NAT device, both endpoints uses 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, more than one allow
action might be required for the firewall configuration, because
incoming and outgoing packets use different source-destination
pairs.
The middlebox first checks whether or not the specified group
exists and whether or not the agent is authorized to add members
to this group. If the reservation identifier is not empty, then
the middlebox also checks whether or not the reference policy
exists whether or not it is member of the specified group, and
whether or not the agent is authorized to modify this policy. If
one of the checks fails, an appropriate failure reply is
generated.
In case of success, this transaction creates a new policy that
becomes a member of the specified group. If a reservation policy
was referenced, then the identifier of the reservation policy will
be used for the new allow policy. Otherwise, the middlebox
generates a middlebox unique identifier for the new policy. The
owner of the new policy is the owner of the group. The middlebox
chooses a lifetime value that is greater than zero and smaller
than or equal to the proposed value and that is smaller than or
equal to the maximum lifetime specified at session setup.
If the protocol identifier is 'IP', then the middlebox allows
communication between the specified external IP address and the
specified internal IP address. The addresses to be used by the
communication partners in order 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 protocol type, then the reserved IP address is used
either as inside or as outside IP address (depending on the
reservation).
For the protocol identifiers 'UDP' and 'TCP' the middlebox acts
analogously to 'IP' with additionally mapping ranges of port
numbers and keeping the port oddity if requested.
The configuration of the middlebox may fail because a specified
reservation policy does not have a matching protocol identifier or
because of lack of resources, such as available IP addresses, port
numbers, or storage for further policies. Also it may fail
Stiemerling & Quittek [Page 27]
Internet-Draft MIDCOM Protocol Semantics August 2002
because of a conflict with an already established policy. In case
of a conflict, the first come first serve mechanism is applied.
Already existing policies remain unchanged and arriving new ones
are rejected. However, in case of a non-conflicting overlap of
policies (including identical policies), all policies are
accepted.
In each case of failure, an appropriate failure reply is
generated.
2.4.3. Policy Lifetime Change (PLC)
transaction-name: policy lifetime change
transaction-type: request
transaction-compliance: mandatory
request-parameters:
- request identifier: an agent unique identifier for matching
corresponding request and reply at the agent.
- policy identifier: identifying the policy for which the lifetime
is requested to be changed.
- policy lifetime: the new lifetime proposal for the policy.
reply-parameters (success):
- request identifier: an identifier matching the identifier
request.
- policy lifetime: The remaining policy lifetime granted by the
middlebox.
reply-parameters (failure):
- request identifier: an identifier matching the identifier
request.
- failure reason: the reason why the lifetime change was rejected.
The list of possible reasons includes but is not restricted to:
- agent not authorized for this transaction
- agent not authorized for changing lifetime of this policy
- no such policy
- lifetime cannot be extended
semantics:
Stiemerling & Quittek [Page 28]
Internet-Draft MIDCOM Protocol Semantics August 2002
The agent can use this transaction type to request an extension
the lifetime of an already established policy, to request
shortening of the life time, or to request policy termination.
Policy termination is requested by suggesting a new policy
lifetime of zero.
The middlebox first checks whether or not the specified policy
exists and whether or not the agent is authorized to access this
policy. 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 or not the
lifetime of the policy may be extended and generates an
appropriate failure message if not.
A failure reply is implies that the lifetime of the policy remains
unchanged. A success reply is generated by the middlebox, if the
lifetime of the policy was changed in any way.
The success reply contains the new lifetime of the policy. The
middlebox chooses the lifetime within the interval limited by the
lifetime of the policy at arrival of the request and by the
suggested lifetime. The granted remaining lifetime must not
exceed the maximum lifetime that the middlebox specified at
session setup together with its other capabilities. it also must
not exceed the lifetime of the group of which the policy is a
member.
After sending a success reply with a lifetime of zero, the
middlebox will consider the policy to be non-existent. It will
not process any further transaction on this policy.
Please note, that policy lifetime may also be changed by the Group
Lifetime Change (AGD) transaction if applied to the group of which
the policy is a member.
2.4.4. Policy Status (PS)
transaction-name: policy status
transaction-type: request
transaction-compliance: optional
request-parameters:
- request identifier: an agent unique identifier for matching
corresponding request and reply at the agent.
- policy identifier: the middlebox unique policy identifier.
Stiemerling & Quittek [Page 29]
Internet-Draft MIDCOM Protocol Semantics August 2002
reply-parameters (success):
- request identifier: an identifier matching the identifier
request.
- policy owner: an identifier of the agent owning this policy.
- group identifier: a reference to the group of which the policy is
a member.
- policy action: this parameter has either the value 'reserve' or
the value 'allow'.
- protocol identifier: identifies the protocol for which a
reservation is requested. Examples are 'IP', 'UDP', and 'TCP'.
- port range: the number of consecutive ports numbers. This
parameter is irrelevant, if the protocol identifier does not have
the value 'TCP' or 'UDP'.
- direction: the direction of the communication allowed by the
middlebox. The value of this parameter is either 'inbound',
'outbound', or 'bi-directional'.
- internal IP address: the IP address of the internal communication
endpoint (A0 in Fig. 4). The address may be wildcarded, for
example by carrying a network mask.
- internal port number: the port number of the internal
communication endpoint (A0 in Fig. 4). The port number may be
wildcarded. This parameter is irrelevant, if the in the protocol
identifier does not have the value 'TCP' or 'UDP'.
- external IP address: the IP address of the external communication
endpoint (A3 in Fig. 4). The address may be wildcarded, for
example by carrying a network mask.
- external port number: the port number of the external
communication endpoint (A3 in Fig. 4). The port number may be
wildcarded. This parameter is irrelevant, if the in the protocol
identifier does not have the value 'TCP' or 'UDP'.
- inside IP address number: the internal IP address provided at the
inside of the NAT (A1 in Fig. 4). The address may be wildcarded,
for example by carrying a network mask.
- inside port number: the internal port number provided at the
inside of the NAT (A1 in Fig. 4). In case of a port range
greater than 1, it is the lowest port number of a consecutive
sequence of mapped port numbers. The port number may be
Stiemerling & Quittek [Page 30]
Internet-Draft MIDCOM Protocol Semantics August 2002
wildcarded. This parameter is irrelevant, if the in the protocol
identifier of the request parameters does not have the value
'TCP' or 'UDP'.
- outside IP address number: the external IP address provided at
the outside of the NAT (A2 in Fig. 4). The address may be
wildcarded, for example by carrying a network mask.
- outside port number: the external port number provided at the
outside of the NAT (A2 in Fig. 4). In case of a port range
greater than 1, it is the lowest port number of a consecutive
sequence of mapped port numbers. The port number may be
wildcarded. This parameter is irrelevant, if the in the protocol
identifier of the request parameters does not have the value
'TCP' or 'UDP'.
- policy lifetime: the remaining lifetime of the policy.
reply-parameters (failure):
- request identifier: an identifier matching the identifier
request.
- failure reason: the reason why the request for a status report
was rejected. The list of possible reasons includes but is not
restricted to:
- transaction not supported
- agent not authorized for this transaction
- no such policy
- agent not authorized for accessing this policy
semantics:
The agent can use this transaction type to list all properties of
a policy. Usually, the agent has this information already, but in
special cases (for example after an agent failover) or for special
agents (for example an administrating agent that can access all
policies) this optional transaction can be helpful.
The middlebox first checks whether or not the specified policy
exists and whether or not 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 are returned
to the agent. Some of the returned parameters may be irrelevant,
depending on the policy action ('reserve' or 'allow') and
depending on other parameters, for example the protocol
identifier.
This transaction does not have any effect on the policy state.
Stiemerling & Quittek [Page 31]
Internet-Draft MIDCOM Protocol Semantics August 2002
2.4.5. Asynchronous Policy Deletion (APD)
transaction-name: asynchronous policy deletion
transaction-type: notification
transaction-compliance: mandatory
notification-parameters:
- policy identifier: the policy that will be deleted.
- deletion reason: the reason why the middlebox will delete the
policy.
semantics:
The middlebox may decide at any point in time to delete a policy.
Particularly, this transaction is triggered by lifetime expiration
of the policy. Among other events that may cause this transaction
are changes in the policy decision point.
If this notification is generated, it is sent to all agents that
are in an open session with the middlebox and that are authorized
to access the policy. The notification is sent to the agents
before the middlebox deletes the policy. After sending the
notification, the middlebox will consider the policy to be non-
existent. It will not process any further transaction on the
policy.
Please note that asynchronous policy termination may also be
indicated by an Asynchronous Group Deletion (AGD) transaction
without an individual APD for each member of the group.
2.4.6. Policy Rule State Machine
The state machine for the policy rule transactions is shown in Figure
5 with all possible state transitions. You'll find the used
transaction abbreviations in the headings of the particular
transaction section. After returning to state POLICY UNUSED, the
policy identifier is not anymore bound to an existing policy and may
be re-used by the middlebox.
Stiemerling & Quittek [Page 32]
Internet-Draft MIDCOM Protocol Semantics August 2002
PRR/failure
PAR/failure
+-----------+
| v
PRR/success +-+-------------+
+-----------------+ POLICY UNUSED |<-+
+----+ | +---------------+ |
| | | ^ | |
| v v APD | | |
| +-------------+ PAR/failure| | PAR/ | APD
| | RESERVED +------------+ | success | PLC(lt=0)/
| +-+----+------+ PLC(lt=0)/ | | success
| | | success | |
+----+ | v |
PLC(lt>0)/ | PAR/success +---------------+ |
success +---------------->| POLICY INUSE +--+
PLC/failure +-+-------------+
| ^
+-----------+
lt = lifetime PLC(lt>0)/success
PLC/failure
Figure 5: Policy Rule State Machine
This state machine exists per policy identifier. Initially, all
policies are in state POLICY UNUSED, which means that the policy does
not exist or is not active. A successful PRR transaction causes a
transition to state RESERVED, where an address reservation is
established. From there, state POLICY INUSE can be entered by a PAR
transaction. This transaction can also be used for entering state
POLICY INUSE directly from state POLICY UNUSED without a reservation.
In state POLICY INUSE the requested communication between the
internal and the external endpoint is allowed.
The states RESERVED and POLICY INUSE can be maintained by a
successful PLC transactions with a requested lifetime greater than 0.
Transitions from both of these states back to state POLICY UNUSED can
be caused by an APD transaction or by a successful PLC transaction
with a lifetime parameter of 0. Additionally, a failed PAR
transaction causes a transition from state RESERVED to POLICY UNUSED.
Please note, transitions initiated by APD transactions may also be
initiated by AGD transactions. Analogously, transitions initiated by
PLC transactions may also be initiated by GLC transactions.
3. Conformance Statements
A protocol definition complies with the semantics defined in Section
2 if the protocol specification includes all specified transactions
Stiemerling & Quittek [Page 33]
Internet-Draft MIDCOM Protocol Semantics August 2002
with all their parameters. However, concrete implementations of the
protocol may not support some of the optional transactions. Which
transactions are required for compliancy is different for agent and
middlebox.
This section contains conformance statements for MIDCOM protocol
implementations related to the semantics. Conformance is specified
differently for agents and middleboxes. Most probably these
conformance statements will be extended by a concrete protocol
specification. However, such an extension is expected to extend the
statements below in a way that all of them still hold.
The following list shows the transaction-compliance property of all
transactions as specified in the previous section:
- Session Control Transactions
- Session Establishment (SE) mandatory
- Session Termination (ST) mandatory
- Asynchronous Session Termination (AST) mandatory
- Policy Group Transactions
- Group Establishment (GE) optional
- Group Lifetime Change (GLC) optional
- Group List (GL) optional
- Group Status (GS) optional
- Asynchronous Group Deletion (AGD) optional
- Policy Rule Transactions
- Policy Reserve Rule (PRR) optional
- Policy Allow Rule (PAR) mandatory
- Policy Lifetime Change (PLC) mandatory
- Policy Status (PS) optional
- Asynchronous Policy Deletion (APD) mandatory
3.1. General Implementation Conformance
A compliant implementation of a MIDCOM protocol must support all
mandatory transactions.
A compliant implementation of a MIDCOM protocol must support either
the entire set of the group transactions GE, GLC, and AGD, or none of
them.
A compliant implementation of a MIDCOM protocol may support none,
one, or more of the following transactions: GL, GS, PRR, PS.
3.2. Middlebox Conformance
A middlebox implementation of a MIDCOM protocol supports a request
transaction if it is able to receive and process all possible correct
Stiemerling & Quittek [Page 34]
Internet-Draft MIDCOM Protocol Semantics August 2002
message instances of the particular request transaction and if it
generates a correct reply for any correct request it receives.
A middlebox implementation o a MIDCOM protocol supports a
notification transaction if it is able to to generate the
corresponding notification message properly.
A compliant middlebox implementation of a MIDCOM protocol must inform
the agent about the list of supported transactions within the SE
transaction.
3.3. Agent Conformance
An agent implementation of a MIDCOM protocol supports a request
transaction if it is able to generate the corresponding request
message properly and if it is able to receive and process all
possible correct replies to the particular request.
An agent implementation of a MIDCOM protocol supports a notification
transaction if it is able to receive and process all possible correct
message instances of the particular transaction.
A compliant agent implementation of a MIDCOM protocol must not use
any optional transaction that is not supported by the middlebox. The
middlebox informs the agent about the list of supported transactions
within the SE transaction.
4. Transaction Usage Examples
This section gives two usage examples of the transactions specified
in Section 2. First it is shown, how an agent can explore all
policies and policy groups, which it may access at a middlebox. Then
the middlebox configuration for enabling a SIP-signaled call is
demonstrated.
4.1. Exploring Policies and Policy Groups
This example precludes an already established session. It shows how
an agent can find out
- which groups it may access and who owns these groups
- the status and member list of all accessible groups
- the status and properties of all accessible policies
If there is just a single session, there is no need for any of these
actions, because the middlebox informs the agent about each state
transition of any policy or policy group. However, after the
disruption of a session or after an intentional session termination,
the agent might want to re-establish the session and explore, which
Stiemerling & Quittek [Page 35]
Internet-Draft MIDCOM Protocol Semantics August 2002
of the groups and policies it established are still in place.
Also an agent system may fail and another one takes over. Then the
other one need to find out what has already been configured by the
failing system and what still needs to be done.
A third situation where exploring policies and groups is useful is
the case of an agent with 'administrator' authorization. This agent
may access any policy or group created by any other agent and modify
them.
All of them probably will start their exploration with the Group List
(GL) transaction, as shown in Figure 6. On this request, the
middlebox returns a list of pairs each containing an agent identifier
and a group identifier (GID). The agent gets informed which own
group and which of other agents' groups it may access.
agent middlebox
| GL |
|**********************************************>|
|<**********************************************|
| (agent1,GID1) (agent1,GID2) (agent2,GID3) |
| |
| GS GID2 |
|**********************************************>|
|<**********************************************|
| agent1 lifetime PID1 PID2 PID3 PID4 |
| |
Figure 6: Using the GL and the GS transaction
In Figure 6 three groups are accessible to the agent, and the agent
retrieves information about the second group by using the Group
Status (GS) transaction. It receives the owner of the group, the
remaining lifetime, and the list of member policies, in this case
containing four policy identifiers (PIDs).
In the following, the agent explores these four policies. The
example assumes the middlebox to be a traditional NAPT. Figure 7
shows the exploration of the first policy. As reply to a Policy
Status (PS) transaction, the middlebox always returns the following
list of parameters:
- policy owner
- group identifier
- policy action (reserve or allow)
- protocol type
- port range
- direction
Stiemerling & Quittek [Page 36]
Internet-Draft MIDCOM Protocol Semantics August 2002
- internal IP address
- internal port number
- external address
- external port number
- NAT inside IP address
- NAT inside port number
- NAT outside IP address
- NAT outside port number
agent middlebox
| PS PID1 |
|**********************************************>|
|<**********************************************|
| agent1 GID2 RESERVE UDP 1 OUTSIDE |
| ANY ANY ANY ANY |
| ANY ANY IPADR_OUT PORT_OUT1 |
| |
Figure 7: Status report for an outside reservation
The policy with PID1 is a reserve policy for UDP traffic at the
outside of the middlebox. Since there is no internal or external
address involved yet, these four fields are wildcarded in the reply.
The same holds for the inside NAT address and port number. The only
address information given by the reply is the reserved outside IP
address of the NAT (IPADDR_OUT) and the corresponding port number
(PORT_OUT1). Note, that IPADR_OUT and PORT_OUT1 may not be
wildcarded, because the reserve action does not support this.
Applying PS to PID2 (Figure 8) shows that the second policy is an
allow policy for inbound UDP packets. The internal destination is
fixed concerning IP address, protocol and port number, but for the
external source, the port number is wildcarded. The outside IP
address and port number of the middlebox are the ones the external
sender needs to use as destination in the original packet it sends.
At the middlebox, the destination address is replaced with the
internal address of the final receiver. During address translation,
the source IP address and the source port numbers of the packets
remain unchanged. This is indicated by the inside address which is
identical to the external address.
Stiemerling & Quittek [Page 37]
Internet-Draft MIDCOM Protocol Semantics August 2002
agent middlebox
| PS PID2 |
|**********************************************>|
|<**********************************************|
| agent1 GID2 ALLOW UDP 1 IN |
| IPADR_INT PORT_INT1 IPADR_EXT ANY |
| IPADR_EXT ANY IPADR_OUT PORT_OUT2 |
| |
Figure 8: Status report for allowed inbound packets
For traditional NATs the identity of the inside IP address and port
number with the external IP address and port number always holds
(A1=A3 in Figure 4). For a pure firewall, also the outside IP
address and port number are always identical with the internal IP
address and port number (A0=A2 in Figure 4).
agent middlebox
| PS PID3 |
|**********************************************>|
|<**********************************************|
| agent1 GID2 ALLOW UDP 1 OUT |
| IPADR_INT PORT_INT2 IPADR_EXT PORT_EXT1 |
| IPADR_EXT PORT_EXT1 IPADR_OUT PORT_OUT3 |
| |
Figure 9: Status report for allowed outbound packets
Figure 9 shows allowed outbound UDP communication between the same
host. Here all port numbers are known. Since again A1=A3, the
internal sender uses the external IP address and port number as
destination in the original packets. At the firewall, the internal
source IP address and port number are replaced by the shown outside
IP address and port number of the middlebox.
agent middlebox
| PS PID4 |
|**********************************************>|
|<**********************************************|
| agent1 GID2 ALLOW TCP 1 BI |
| IPADR_INT PORT_INT3 IPADR_EXT PORT_EXT2 |
| IPADR_EXT PORT_EXT2 IPADR_OUT PORT_OUT4 |
| |
Figure 10: Status report for bi-directional TCP traffic
Finally, Figure 10 shows the status report for allowed bi-directional
TCP traffic. Please note that still A1=A3: For outbound packets, only
Stiemerling & Quittek [Page 38]
Internet-Draft MIDCOM Protocol Semantics August 2002
the source IP address and port number are replaced at the middlebox,
and for inbound packets, only the destination IP address and port
number are replaced.
4.2. Enabling a SIP-Signaled Call
This elaborated transaction usage example shows the interaction
between a SIP proxy and a middlebox. The middlebox itself is a
traditional NAPT and two user agents communciate with each other via
the SIP proxy and NAPT as shown in figure 11.
+----------+
|SIP Proxy |
|for domain|
| mb.com |
+----------+
Private ^ ^ Public Network
Network | |
+----------+ | | +---------+ +----------+
|User Agent|<-+ +->|Middlebox|<------->|User Agent|
| A |<#######>| NAPT |<#######>| B |
+----------+ +---------+ +----------+
<--> SIP Signalling
<##> RTP Traffic
Figure 11: Example SIP Scenario
For the below sequence charts we make these assumptions:
- The NAPT is statically configured to forward SIP signalling from
the outside to the SIP proxy server, i.e. traffic to the NAPT's
external IP address and port 5060 is forwarded to the internal
SIP proxy.
- The user agent A, located inside the private network, is
registered at the SIP proxy with its private IP address.
- User A knows the general SIP URL of user B. The URL is B@b.de.
However, the concrete URL of the SIP User Agent B, which user B
currently uses, is not known.
- Only the RTP paths are configured, but not the RTCP paths.
- The middlebox and the SIP server share an already established
MIDCOM session.
Stiemerling & Quittek [Page 39]
Internet-Draft MIDCOM Protocol Semantics August 2002
Furthermore these abbreviations are used:
- IP_AI: Internal IP address of user agent A
- P_AI: Internal port number of user agent A to receive RTP data
- P_AE: External mapped port number of user agent A
- IP_AE: External IP address of the middlebox
- IP_B: IP address of user agent B
- P_B: Port number of user agent B to receive RTP data
- GID: Group identifier
- PID: Policy rule identifier
The abbreviations of the MIDCOM transactions can be found in the
particular section headings.
In our example, user A tries to call user B. Therefore, the user agent A
sends an INVITE SIP message to the SIP proxy server (see Figure 13). The
SDP part of the particular SIP message that is relevant for the middlebox
configuration is shown in the sequence chart as:
SDP: m=..P_AI..
c=IP_AI
Whereas the m tag is the media tag which contains the receiving udp
port number and the c tag contains the IP address of the terminal
receiving the media stream.
On receiving the SIP INVITE message, the SIP proxy server
allocates a group for this call with the group establishment (GE)
transaction. All following policy rules for this call will be bound to
this group.
The INVITE message forwarded to user agent B must contain a public IP address
and a port number to which user agent B can send its RTP media stream.
Therefore, the SIP proxy server needs an outside IP address and port
number at the middlebox (the NAPT) to be available for this purpose.
However, since the IP address of user agent B is not known yet (it will
be sent by user agent B in the reply message), the porxy server cannot
just request an address binding. Instead it just reserves an outside
IP address and port number with the policy reserve rule (PRR).
The PRR reply delivers the reserved IP address and port number. Now the SIP
proxy server replaces in the SDP payload of the INVITE message the IP address
and port number of user agent A by the reserved address and port
(see Figure 12).
Then the SIP INVITE message is forwarded to user agent B with a modified
SDP body containing the outside address and port number, to which user agent B
will send its RTP media stream.
Stiemerling & Quittek [Page 40]
Internet-Draft MIDCOM Protocol Semantics August 2002
User Agent SIP Middlebox User Agent
A Proxy NAPT B
| | | |
| INIVTE B@B.DE | | |
| SDP:m=..P_AI.. | | |
| c=IP_AI | | |
|--------------->| GE 600s | |
| |*****************************>| |
| |<*****************************| |
| | GE OK GID 600s | |
| | | |
| | PRR GID UDP 1 EVEN IN 300s | |
| |*****************************>| |
| |<*****************************| |
| | PRR OK PID1 IP_MB/P_AE 300s | |
| | | |
| | INVITE B@B.DE SDP:m=..P_AE.. c=IP_MB |
| |-------------------------------------------->|
| |<--------------------------------------------|
| | 200 OK SDP:m=..P_B.. c=IP_B |
Figure 12: Group establishment and rule reservation
This SIP `200 OK' reply contains the IP address and port number, at which
user agent B will receive a media stream. The IP address is assumed to be
equal to the IP address from which user agwent B will send its media stream.
Now, the SIP proxy server has sufficient information for estblishing
the complete NAT binding with a policy allow rule (PAR) transaction, i.e.
the UDP/RTP data of the call can flow from user agent B to user agent A.
For the opposite direction, UDP/RTP data from user agent A to B, has to be
allowed also. This is done by a second PAR transaction
with all the necessary parameters (see figure 13). After having allowed
both UDP/RTP streams the SIP proxy can forward the `200 OK' SIP message
to user agent A to indicate that the telephone call can start.
Stiemerling & Quittek [Page 41]
Internet-Draft MIDCOM Protocol Semantics August 2002
User Agent SIP Middlebox User Agent
A Proxy NAPT B
| | | |
| | PAR GID PID1 UDP 1 EVEN IN | |
| | IP_AI P_AI IP_B ANY 300s | |
| |*****************************>| |
| |<*****************************| |
| | PAR OK PID1 NONE NONE | |
| | IP_MB P_AE1 300s | |
| | | |
...media stream from user agent B to A allowed...
| | | |
| | PAR GID PID2 UDP 1 EVEN OUT | |
| | IP_AI ANY IP_B P_B 300s | |
| |*****************************>| |
| |<*****************************| |
| | PAR OK PID2 NONE NONE | |
| | IP_MB P_AE2 300s | |
| | | |
...media streams from both directions allowed...
| | | |
| 200 OK | | |
|<---------------| | |
| SDP:m=..P_B.. | | |
| c=IP_B | | |
Figure 13: Policy rule establishment for UDP flows
User agent B decides to terminate the call and sends its `BYE'
SIP message to user agent A. The SIP proxy forwards all SIP messages
and deletes the group afterwards using a group lifetime change (GLC)
transaction with a requested remaining lifetime of 0 seconds (see
Figure 14). Deletion of the group includes deleting all member policies.
Stiemerling & Quittek [Page 42]
Internet-Draft MIDCOM Protocol Semantics August 2002
User Agent SIP Middlebox User Agent
A Proxy NAPT B
| | | |
| BYE | BYE |
|<---------------|<--------------------------------------------|
| | | |
| 200 OK | 200 OK |
|--------------->|-------------------------------------------->|
| | | |
| | GLC GID 0s | |
| |*****************************>| |
| |<*****************************| |
| | GLC OK 0s | |
| | | |
...both NAT bindings for the media streams are removed...
Figure 14: Deletion of Policy Groups
5. Compliance with MIDCOM Requirements
This section explains the compliance of the specified semantics with
the MIDCOM requirements. It is structured according to [MDC-REQ]:
- Compliance with Protocol Machinery Requirements (Section 5.1)
- Compliance with Protocol Semantics Requirements (Section 5.2)
- Compliance with Security Requirements (Section 5.3)
The requirements are referred to using the section number they are
defined in: "requirement x.y.z" refers to the requirement specified
in section x.y.z of [MDC-REQ].
5.1. Protocol Machinery Requirements
5.1.1. Authorized Association
The specified semantics enable a MIDCOM agent to establish an
authorized association between itself and the middlebox. The agent
identifies itself by the authentication mechanism of the Session
Establishment transaction described in Section 2.2.1. Based on this
authentication the middlebox can make a determination as to whether
or not the agent will be permitted to request a service. Thus,
requirement 2.1.1 is met.
5.1.2. Agent connects to Multiple Middleboxes
As specified in Section 2.2, the MIDCOM protocol allows the agent to
communicate with more than one middlebox simultaneously. The
selection of a mechanism for separating different sessions is left to
Stiemerling & Quittek [Page 43]
Internet-Draft MIDCOM Protocol Semantics August 2002
the concrete protocol definition. It must provide a clear mapping of
protocol messages to open sessions. Then requirement 2.1.2 is met.
5.1.3. Multiple Agents connect to same Middlebox
As specified in Section 2.2, the MIDCOM protocol allows the middlebox
to communicate with more than one agent simultaneously. The
selection of a mechanism for separating different sessions is left to
the concrete protocol definition. It must provide a clear mapping of
protocol messages to open sessions. Then requirement 2.1.3 is met.
5.1.4. Deterministic Behavior
Section 2.1.2 states, that processing a request of an agent may not
be interrupted by any request of the same or another agent. This
provides atomicity among request transactions. This avoids race
conditions resulting in an unpredictable behavior of the middlebox.
Anyway, the behavior of the middlebox can only be predictable in the
view of its administrators. In the view of an agent, the middlebox
behavior is unpredictable, because the administrator can, for example
at any time modify the authorization of the agent without the agent
being able to observe this change. Consequently, the behavior of the
middlebox is not necessarily deterministic from the point of view of
any agent.
Since predictability of the middlebox behavior is given for its
administrator, requirement 2.1.4 is met.
5.1.5. Known and Stable State
Section 2.1.2 states that request transactions are atomic with
respect to each other and from the point of view of an agent. All
transactions are defined clearly as state transitions that either
leave the current stable and well defined state and enter a new
stable and well defined one or that remain in the current stable and
well defined state. Section 2.1 clearly demands that intermediate
states are not stable and not reported to any agent.
Furthermore, for each state transition a message is sent to the
corresponding agent, either a reply or a notification. The agent can
uniquely map each reply to one of the requests that it sent to the
middlebox, because request agent unique request identifiers are used
for this purpose. Notifications are self-explanatory by their
definition.
Furthermore, the Group List transaction (Section 2.3.3), the Group
Status transaction (Section 2.3.4), and the Policy Status transaction
(Section 2.4.4) allow the agent at any time during a session to
retrieve information about
Stiemerling & Quittek [Page 44]
Internet-Draft MIDCOM Protocol Semantics August 2002
- all policy groups it may access,
- the status and member policies of all accessible groups,
- and the status of all accessible policies.
Therefore, the agent is precisely informed about the state of the
middlebox (as far as the services requested by the agent are
affected) and requirement 2.1.5 is met.
5.1.6. Status Report
As argued in the previous section, the middlebox unambiguously
informs the agent about every state transition related to any of the
services requested by the agent. Also the agent can at any time
retrieve full status information about all accessible policies and
policy groups. Thus, requirement 2.1.6 is met.
5.1.7. Unsolicited Messages (Asynchronous Notifications)
The semantics include asynchronous notifications from the middlebox
to the agent, including Asynchronous Session Termination (Section
2.2.3), Asynchronous Group Deletion (Section 2.3.5), and Asynchronous
Policy Deletion (Section 2.4.5). These notifications report every
change of state, that was not explicitly requested by the agent.
Thus, requirement 2.1.7 is met by the semantics specified above.
5.1.8. Mutual Authentication
As specified in Section 2.2.1, the semantics require mutual
authentication of agent and middlebox, either by using two subsequent
Session Establishment transactions or by using mutual authentication
provided on a lower protocol layer. Thus, requirement 2.1.8 is met.
5.1.9. Session Termination by any Party
The semantics specification states in Section 2.2.2 that the agent
may request session termination by generating the Session Termination
request and that the middlebox may not reject this request. In turn,
Session 2.2.3 states that the agent may send the Asynchronous Session
Termination notification at any time and then terminate the session.
Thus, requirement 2.1.9 is met.
5.1.10. Request Result
Section 2.1 states that each request of an agent is followed by a
reply of the middlebox indicating either success of failure. Thus,
requirement 2.2.10 is met.
Stiemerling & Quittek [Page 45]
Internet-Draft MIDCOM Protocol Semantics August 2002
5.1.11. Version Interworking
Section 2.2.1 states that the agent need to specify the protocol
version number which it is going to use during the session. The
middlebox may accept this and act according to this protocol version
or reject the session if it does not support this version. If the
session setup gets rejected, the agent may try again with another
version. Thus, requirement 2.2.11 is met.
5.1.12. Deterministic Handling of Overlapping Rules
The only policy rule actions specified are 'reserve' and 'allow'.
For firewalls, overlapping allow actions or reserve actions do not
create any conflict, so a firewall will always accept overlapping
rules as specified in Sections 2.4.1 and 2.4.2 (assuming the required
authorization is given).
For NATs reserve and allow may conflict. If a conflicting request
arrives, it is rejected, as stated in Sections 2.4.1 and 2.4.2. If
an overlapping request arrives that does not conflict with the ones
it overlaps, it is accepted (assuming the required authorization is
given).
Therefore, the behavior of the middlebox in the presence of
overlapping rules can be predicted deterministically, and requirement
2.1.12 is met.
5.2. Protocol Semantics Requirements
5.2.1. Extensible Syntax and Semantics
requirement 2.2.1 explicitly requests extensibility of protocol
syntax. This needs to be addressed by the concrete protocol
definition. The semantics specification is extensible anyway,
because new transaction may be added.
5.2.2. Policy Rules for Different Types of Middleboxes
Section 2.4 explains that the semantics use identical transactions
for all middlebox types and that the same policy rule can be applied
to all of them. Thus requirement 2.2.2 is met.
5.2.3. Ruleset Groups
The semantics explicitly supports grouping of policies and
transactions on policy groups, as described in Section 2.3. The
group transactions can be used for lifetime extension and deletion of
all policies being member of the particular group. Thus, requirement
2.2.3 is met.
Stiemerling & Quittek [Page 46]
Internet-Draft MIDCOM Protocol Semantics August 2002
5.2.4. Policy Lifetime Extension
The semantics include a transaction for explicit lifetime extension
of policies, as described in Section 2.4.3. Thus requirement 2.2.4
is met.
5.2.5. Robust Failure Modes
The state transitions at the middlebox are clearly specified and
communicated to the agent. There is no intermediate state reached by
a partial processing of a request. All requests are always processed
completely, either successful or unsuccessful. All request
transaction include a list of failure reasons. These failure reasons
cover indication of invalid parameters where applicable. In case of
failure one of the specified reasons is returned from the middlebox
to the agent. Thus requirement 2.2.5 is met.
5.2.6. Failure Reasons
The semantics include a failure reason parameter in each failure
reply. Thus requirement 2.2.6 is met.
5.2.7. Multiple Agents Manipulating Same Policy
As specified in Sections 2.3 and 2.4, each installed policy rule and
policy group has an owner, which is the authenticated agent that
created the policy or group, respectively. The authenticated
identity is input to authorization of access to policies and groups.
If the middlebox is sufficiently configurable, its administrator can
configure it such that one authenticated agent is is authorized to
access and modify policies and groups owned by another agent.
Because specified semantics does not preclude this, it meets
requirement 2.2.7.
5.2.8. Carrying Filtering Rules
The Policy Allow Rule transaction specified in Section 2.4.2 can
carry 5-tuple filtering rules. It meets requirement 2.2.8.
5.2.9. Oddity of Port Numbers
As specified in Section 2.4.2, the agent is able to request to keep
the port oddity. Thus requirement 2.2.9 is met.
5.2.10. Consecutive Range of Port Numbers
The Policy Allow Rule transaction (PAR, Section 2.4.2) allows the
agent to specify a range of consecutive port numbers to be mapped.
This can be used for mapping a consecutive range of external port
Stiemerling & Quittek [Page 47]
Internet-Draft MIDCOM Protocol Semantics August 2002
numbers to consecutive internal ports. Thus requirement 2.2.10 is
met.
5.2.11. Contradicting Overlapping Policies
requirement 2.2.11 is based on the assumption that contradicting
policy actions, such as 'allow' and 'disallow' are supported. In
conformance with decisions made by the working group after finalizing
the requirements document, this requirement is not met by the
semantics, because not 'disallow' action is supported.
5.3. Security Requirements
5.3.1. Authentication, Confidentiality, Integrity
The semantics definition support mutual authentication of agent and
middlebox and the selection of an encryption method in the Session
Establishment transaction (Section 2.2.1). Encryption can be used
for achieving confidentiality of messages as well as for ensuring
integrity. Thus requirement 2.3.1 is met.
5.3.2. Optional Confidentiality of Control Messages
The Session Establishment transaction (Section 2.2.1) allows the
agent to suggest an encryption method (including 'no encryption').
Thus requirement 2.3.2 is met.
5.3.3. Operation across Un-trusted Domains
Operation across un-trusted domains is supported by mutual
authentication and by encryption. Thus requirement 2.3.3 is met.
5.3.4. Mitigate Replay Attacks
The specified semantics mitigates replay attacks and meets
requirement 2.3.4 by requiring mutual authentication of agent and
middlebox, and by supporting message encryption. Further mitigation
can be provided as part of a concrete MIDCOM protocol definition, for
example by requiring consecutively increasing numbers for request
identifiers.
6. Security Considerations
The interaction between a middlebox and an agent is (see [MDC-FRM]) a
very sensitive point with respect to security. The configuration of
policy rules from a middlebox external entity appears very
contradictive to the nature of a middlebox. Therefore, effective
means have to be used to ensure:
- mutual authentication between agent and middlebox
Stiemerling & Quittek [Page 48]
Internet-Draft MIDCOM Protocol Semantics August 2002
- authorization
- message integrity
- message confidentiality
The semantics define a mechanism to ensure mutual authentication
between agent and middlebox (see section 2.2.1). In combination with
the authentication, the middlebox is able to decide wether an agent
is authorized to request an action at the middlebox or not. The
semantics rely on underlying protocols, like TLS or IPSEC, to keep
the message integrity and confidentiality of the transfered data
between both entities.
7. Acknowledgments
We like to thank all the people contributing to the semantics
discussion on the mailing list for a lot of valuable comments.
8. Open Issues
Here is the list of open issues and to do issues:
- The capability information send from the middlebox to the agent
at session setup need to be modeled. What further capability
items should be sent?
- Define behavior for ICMP, IGMP, RSVP, ...
- Complete section on security considerations.
9. Acknowledgements
We like to thank all the people contributing to the semantics
discussion on the mailling list and especially Tom Taylor.
10. References
[MDC-FRM] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A.,
Rayhan, A., "Middlebox Communication Architecture and
framework", RFC 3303, August 2002
[MDC-REQ] Swale, R.P., Mart, P.A., Sijben, P., Brimm, S., Shore, M.,
"Middlebox Control (MIDCOM) Protocol Architecture and
Requirements", RFC 3304, August 2002
[NAT-TERM] Srisuresh,P., and Holdrege, M., "IP Network Translator (NAT)
Terminology and Considerations", RFC 2663, August 1999.
Stiemerling & Quittek [Page 49]
Internet-Draft MIDCOM Protocol Semantics August 2002
[RFC2246] Dierks, T., Allen, C., "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[RFC2402] Kent, S., and Atkinson, R., "IP Authentication Header", RFC
2402, November 1998.
[RFC2406] Kent, S., and Atkinson, R., "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
11. Authors' Address
Martin Stiemerling
NEC Europe Ltd.
Network Laboratories
Adenauerplatz 6
69115 Heidelberg
Germany
Phone: +49 6221 90511-13
Email: stiemerling@ccrle.nec.de
Juergen Quittek
NEC Europe Ltd.
Network Laboratories
Adenauerplatz 6
69115 Heidelberg
Germany
Phone: +49 6221 90511-15
EMail: quittek@ccrle.nec.de
12. Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
Stiemerling & Quittek [Page 50]
Internet-Draft MIDCOM Protocol Semantics August 2002
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Stiemerling & Quittek [Page 51]
| PAFTECH AB 2003-2026 | 2026-04-26 12:52:19 |