Request for Comments: 4540 J. Quittek
Category: Experimental NEC
C. Cadar
May 2006
NEC’s Simple Middlebox Configuration (SIMCO) Protocol Version 3.0
Status of This Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
IESG Note
The content of this RFC was at one time considered by the IETF, and
therefore it may resemble a current IETF work in progress or a
published IETF work. This RFC is not a candidate for any level of
Internet Standard. The IETF disclaims any knowledge of the fitness
of this RFC for any purpose and in particular notes that the decision
to publish is not based on IETF review for such things as security,
congestion control, or inappropriate interaction with deployed
protocols. The RFC Editor has chosen to publish this document at its
discretion. Readers of this RFC should exercise caution in
evaluating its value for implementation and deployment. See RFC 3932
[RFC3932] for more information.
Abstract
This document describes a protocol for controlling middleboxes such
as firewalls and network address translators. It is a fully
compliant implementation of the Middlebox Communications (MIDCOM)
semantics described in RFC 3989. Compared to earlier experimental
versions of the SIMCO protocol, this version (3.0) uses binary
message encodings in order to reduce resource requirements.
Table of Contents
1. Introduction ....................................................4
1.1. Terminology ................................................4
1.2. Binary Encodings ...........................................4
2. Compliance with MIDCOM Protocol Semantics .......................5
3. SIMCO Sessions ..................................................6
4. SIMCO Message Components ........................................6
4.1. Message Types ..............................................7
4.2. The SIMCO Header ...........................................7
4.2.1. Basic Message Types .................................8
4.2.2. Message Sub-types for Requests and Positive
Replies .............................................8
4.2.3. Message Sub-types for Negative Replies ..............8
4.2.4. Message Sub-types for Notifications .................9
4.2.5. Transaction Identifier ..............................9
4.3. The SIMCO Payload .........................................10
4.3.1. SIMCO Protocol Version Attribute ...................11
4.3.2. Authentication Attributes ..........................11
4.3.3. Middlebox Capabilities Attribute ...................12
4.3.4. Policy Rule Identifier Attribute ...................13
4.3.5. Group Identifier Attribute .........................13
4.3.6. Policy Rule Lifetime Attribute .....................13
4.3.7. Policy Rule Owner Attribute ........................14
4.3.8. Address Tuple Attribute ............................14
4.3.9. PRR Parameter Set Attribute ........................16
4.3.10. PER Parameter Set Attribute .......................18
5. SIMCO Message Formats ..........................................19
5.1. Protocol Error Replies and Notifications ..................19
5.1.1. BFM Notification ...................................19
5.1.2. Protocol Error Negative Replies ....................19
5.2. Session Control Messages ..................................20
5.2.1. SE Request .........................................20
5.2.2. SE Positive Reply ..................................21
5.2.3. SA Positive Reply ..................................21
5.2.4. SA Request .........................................21
5.2.5. ST Request and ST Positive Reply ...................22
5.2.6. SE Negative Replies ................................22
5.2.7. AST Notification ...................................23
5.3. Policy Rule Control Messages ..............................23
5.3.1. Policy Events and Asynchronous Notifications .......24
5.3.2. PRR Request ........................................24
5.3.3. PER Request ........................................25
5.3.4. PEA Request ........................................26
5.3.5. PLC Request ........................................26
5.3.6. PRS Request ........................................27
5.3.7. PRL Request ........................................27
5.3.8. PDR Request ........................................27
5.3.9. PRR Positive Reply .................................28
5.3.10. PER Positive Reply ................................28
5.3.11. PLC Positive Reply ................................29
5.3.12. PRD Positive Reply ................................29
5.3.13. PRS Positive Reply ................................30
5.3.14. PES Positive Reply ................................31
5.3.15. PDS Positive Reply ................................32
3.5.16. PRL Positive Reply ................................32
5.3.17. PDR Positive Replies ..............................33
5.3.18. Policy Rule Control Negative Replies ..............33
5.3.19. ARE Notification ..................................33
6. Message Format Checking ........................................34
7. Session Control Message Processing .............................36
7.1. Session State Machine .....................................36
7.2. Processing SE Requests ....................................37
7.3. Processing SA Requests ....................................38
7.4. Processing ST Requests ....................................39
7.5. Generating AST Notifications ..............................39
7.6. Session Termination by Interruption of Connection .........39
8. Policy Rule Control Message Processing .........................40
8.1. Policy Rule State Machine .................................40
8.2. Processing PRR Requests ...................................41
8.2.1. Initial Checks .....................................41
8.2.2. Processing on Pure Firewalls .......................43
8.2.3. Processing on Network Address Translators ..........44
8.3. Processing PER Requests ...................................45
8.3.1. Initial Checks .....................................46
8.3.2. Processing on Pure Firewalls .......................48
8.3.3. Processing on Network Address Translators ..........49
8.3.4. Processing on Combined Firewalls and NATs ..........51
8.4. Processing PEA Requests ...................................51
8.4.1. Initial Checks .....................................51
8.4.2. Processing on Pure Firewalls .......................53
8.4.3. Processing on Network Address Translators ..........54
8.5. Processing PLC Requests ...................................55
8.6. Processing PRS Requests ...................................56
8.7. Processing PRL Requests ...................................57
8.8. Processing PDR requests ...................................57
8.8.1. Extending the MIDCOM semantics .....................58
8.8.2. Initial Checks .....................................58
8.8.3. Processing on Pure Firewalls .......................61
8.8.4. Processing on Network Address Translators ..........61
8.8.5. Processing on Combined Firewalls and NATs ..........62
8.9. Generating ARE Notifications ..............................62
9. Security Considerations ........................................63
9.1. Possible Threats to SIMCO .................................63
9.2. Securing SIMCO with IPsec .................................63
10. IAB Considerations on UNSAF ...................................64
11. Acknowledgements ..............................................64
12. Normative References ..........................................65
13. Informative References ........................................65
1. Introduction
The Simple Middlebox Configuration (SIMCO) protocol is used to
control firewalls and Network Address Translators (NATs). As defined
in [RFC3234], firewalls and NATs are classified as middleboxes. A
middlebox is a device on the datagram path between the source and
destination that performs other functions than just IP routing. As
outlined in [RFC3303], firewalls and NATs are potential obstacles to
packet streams, for example, if dynamically negotiated UDP or TCP
port numbers are used, as in many peer-to-peer communication
applications.
SIMCO allows applications to communicate with middleboxes on the
datagram path in order to request a dynamic configuration at the
middlebox that enables datagram streams to pass the middlebox.
Applications can request pinholes at firewalls and address bindings
at NATs.
The semantics for the SIMCO protocol are described in [RFC3989].
1.1. Terminology
The terminology used in this document is fully aligned with the
terminology defined in [RFC3989]. In the remainder of the text, the
term SIMCO refers to SIMCO version 3.0. The term "prefix-length" is
used as described in [RFC4291] and [RFC1519]. With respect to
wildcarding, the prefix length determines the part of an IP address
that will be used in address match operations.
1.2. Binary Encodings
Previous experimental versions of SIMCO used simple ASCII encodings
with augmented BNF for syntax specification. This encoding requires
more resources than binary encodings do for generation and parsing of
messages. This applies to resources for coding agents and
middleboxes as well as to resources for executing a SIMCO stack.
Low resource requirements are important properties for two main
reasons:
- For many applications (for example, IP telephony), session setup
times are critical. Users do accept setup times only up to some
limit, and some signaling protocols start retransmitting
messages if setup is not completed within a certain time.
- Many middleboxes are rather small and relatively low-cost
devices. For these, support of resource-intensive protocols
might be a problem. The acceptance of a protocol on these
devices depends, among other things, on the cost of implementing
the protocol and of its hardware requirements.
Therefore, we decided to use a simple and efficient binary encoding
for SIMCO version 3.0, which is described in this document.
2. Compliance with MIDCOM Protocol Semantics
SIMCO version 3 is fully compliant with the MIDCOM protocol semantics
defined by [RFC3989]. SIMCO implements protocol transactions as
defined in Section 2.1.1 of [RFC3989]. All message types defined in
Section 2.1.2 of [RFC3989] are supported by SIMCO, and all mandatory
transactions are implemented. SIMCO does not implement the optional
group transactions. For all implemented transactions, SIMCO
implements all parameters concerning the information contained.
SIMCO defines a few new terms to reference functionality in the
semantics. Among these terms are Session Authentication (SA) and
Policy Enable Rule After reservation (PEA) messages. SA is used to
model the state transition given in Figure 2 of [RFC3989] from NOAUTH
to OPEN. PEA is used to model the state transition given in Figure 4
of [RFC3989] from RESERVED to ENABLED.
SIMCO implements one additional transaction, the Policy Disable Rule
(PDR) transaction, to those defined in [RFC3989]. PDR transactions
are used by security functions such as intrusion detection and attack
detection. They allow the agent to block a specified kind of
traffic. PDRs have priority above Policy Enable Rules (PERs). When
a PDR is established, all conflicting PERs (including PERs with just
a partial overlap) are terminated, and no new conflicting PER can be
established before the PDR is terminated. Support of the PDR
transaction by SIMCO is optional. For a detailed description of the
PDR transaction semantics, see Section 8.8.
3. SIMCO Sessions
The SIMCO protocol uses a session model with two parties: an agent
representing one or more applications and a middlebox. Both parties
may participate in multiple sessions. An agent may simultaneously
communicate with several middleboxes using one session per middlebox.
A middlebox may simultaneously communicate with several agents using
one session per agent.
+-------+ SIMCO protocol +-----------+
| agent +------------------+ middlebox |
+-------+ +-----------+
Figure 1: Participants in a SIMCO session
SIMCO sessions must run over a reliable transport layer protocol and
are initiated by the agent. SIMCO implementations must support TCP,
while other reliable transport protocols can be used as transport for
SIMCO as well. When using TCP as transport, middleboxes must wait
for agents to connect on port 7626. This port is assigned to SIMCO
servers by IANA (see http://www.iana.org/assignments/port-numbers).
The session may be secured, if required, by either IPsec or TLS
[RFC4346] to guarantee authentication, message integrity and
confidentiality. The use of IPsec is outlined in Section 9,
"Security Considerations".
The transaction semantics of sessions is explained in [RFC3989]
Section 2.2.
4. SIMCO Message Components
All SIMCO messages from agent to middlebox and from middlebox to
agent are sent over the transport protocol as specified in Section 3.
SIMCO messages are Type-Length-Value (TLV) encoded using big endian
(network ordered) binary data representations.
All SIMCO messages start with the SIMCO header containing message
type, message length, and a message identifier. The rest of the
message, the payload, contains zero, one, or more TLV message
attributes.
4.1. Message Types
The message type in the SIMCO header is divided into a basic type and
a sub-type. There are four basic types of SIMCO messages:
- request,
- positive reply,
- negative reply,
- notification.
Messages sent from the agent to the middlebox are always of basic
type ’request message’, while the basic type of messages sent from
the middlebox to the agent is one of the three other types. Request
messages and positive and negative reply messages belong to request
transactions. From the agent’s point of view, notification messages
belong to notification transactions only. From the middlebox’s point
of view, a notification message may also belong to a request
transaction. See section 2.3.4. of [RFC3989] for a detailed
discussion of this issue.
The message sub-type gives further information on the message type
within the context of the basic message type. Only the combination
of basic type and sub-type clearly identify the type of a message.
4.2. The SIMCO Header
The SIMCO header is the first part of all SIMCO messages. It
contains four fields: the basic message type, the message sub-type,
the message length (excluding the SIMCO header) in octets, and the
transaction identifier. The SIMCO header has a size of 64 bits. Its
layout is defined in Figure 2.
Message Type
_______________^_______________
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Basic Type | Sub-Type | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction Identifier (TID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The SIMCO header
4.2.1. Basic Message Types
For the basic type field, the following values are defined:
0x01 : Request Message
0x02 : Positive Reply Message
0x03 : Negative Reply Message
0x04 : Notification Message
4.2.2. Message Sub-types for Requests and Positive Replies
For basic types 0x01 (request) and 0x02 (positive reply), a common
set of values for the sub-type field is defined. Most of the sub-
types can be used for both basic types. Restricted sub-types are
marked accordingly.
0x01 : (SE) session establishment
0x02 : (SA) session authentication
0x03 : (ST) session termination
0x11 : (PRR) policy reserve rule
0x12 : (PER) policy enable rule
0x13 : (PEA) PER after reservation (request only)
0x14 : (PDR) policy disable rule
0x15 : (PLC) policy rule lifetime change
0x16 : (PRD) policy rule deletion (positive reply only)
0x21 : (PRS) policy rule status
0x22 : (PRL) policy rule list
0x23 : (PES) policy enable rule status (positive reply only)
0x24 : (PDS) policy disable rule status (positive reply only)
4.2.3. Message Sub-types for Negative Replies
For basic type 0x03 (negative reply message), the following values of
the sub-type field are defined:
Replies concerning general message handling
0x10 : wrong basic request message type
0x11 : wrong request message sub-type
0x12 : badly formed request
0x13 : reply message too big
Replies concerning sessions
0x20 : request not applicable
0x21 : lack of resources
0x22 : protocol version mismatch
0x23 : authentication failed
0x24 : no authorization
0x25 : transport protocol problem
0x26 : security of underlying protocol layers insufficient
Replies concerning policy rules
0x40 : transaction not supported
0x41 : agent not authorized for this transaction
0x42 : no resources available for this transaction
0x43 : specified policy rule does not exist
0x44 : specified policy rule group does not exist
0x45 : not authorized for accessing specified policy
0x46 : not authorized for accessing specified group
0x47 : requested address space not available
0x48 : lack of IP addresses
0x49 : lack of port numbers
0x4A : middlebox configuration failed
0x4B : inconsistent request
0x4C : requested wildcarding not supported
0x4D : protocol type doesn’t match
0x4E : NAT mode not supported
0x4F : IP version mismatch
0x50 : conflict with existing rule
0x51 : not authorized to change lifetime
0x52 : lifetime can’t be extended
0x53 : illegal IP Address
0x54 : protocol type not supported
0x55 : illegal port number
0x56 : illegal number of subsequent ports (NOSP)
0x57 : already enable PID
0x58 : parity doesn’t match
4.2.4. Message Sub-types for Notifications
For basic type 0x04, the following values of the sub-type field are
defined:
0x01 : (BFM) badly formed message received
0x02 : (AST) asynchronous session termination
0x03 : (ARE) asynchronous policy rule event
4.2.5. Transaction Identifier
The transaction identifier (TID) is an arbitrary number identifying
the transaction. In a request message, the agent chooses an agent-
unique TID, such that the same agent never uses the same TID in two
different request messages belonging to the same session. Reply
messages must contain the same TID as the corresponding request
message. In a notification message, the middlebox chooses a
middlebox-unique TID, such that the same middlebox never uses the
same TID in two different notification messages belonging to the same
session.
4.3. The SIMCO Payload
A SIMCO payload consists of zero, one, or more type-length-value
(TLV) attributes. Each TLV attribute starts with a 16-bit type field
and a 16-bit length field, as shown in Figure 3.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| attribute type | attribute length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Structure of TLV attribute
The attribute length field contains the length of the value field in
octets.
The following attribute types are defined:
type description length
----------------------------------------------------
0x0001 : SIMCO protocol version 32 bits
0x0002 : authentication challenge <= 4096 octets
0x0003 : authentication token <= 4096 octets
0x0004 : middlebox capabilities 64 bits
0x0005 : policy rule identifier 32 bits
0x0006 : group identifier 32 bits
0x0007 : policy rule lifetime 32 bits
0x0008 : policy rule owner <= 255 octets
0x0009 : address tuple 32, 96 or 192 bits
0x000A : PRR parameter set 32 bits
0x000B : PER parameter set 32 bits
4.3.1. SIMCO Protocol Version Attribute
The SIMCO protocol version attribute has a length of four octets.
The first two octets contain the version number, one the major
version number and the other the minor version number. Two remaining
octets are reserved.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0001 | 0x0004 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|major version #|minor version #| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Protocol version attribute
The SIMCO protocol specified within this document is version 3.0.
The version numbers carried in the protocol version attribute are 3