for major version number and 0 for minor version number.
4.3.2. Authentication Attributes
The authentication challenge attribute and the authentication token
attribute have the same format. Both contain a single value field
with variable length. For both, the maximum length is limited to
4096 octets. Please note that the length of these attributes may
have values that are not multiples of 4 octets. In case of an
authentication challenge attribute, the value field contains an
authentication challenge sent from one peer to the other, requesting
that the other peer authenticate itself.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0002 | challenge length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| challenge
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Authentication challenge attribute
The authentication token attribute is used for transmitting an
authentication token.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0003 | authentication length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| authentication token
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Authentication attribute
4.3.3. Middlebox Capabilities Attribute
The middlebox capabilities attribute has a length of eight octets.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0004 | 0x0008 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MB type |I|E|P|S|IIV|EIV| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| max policy rule lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Capabilities attribute
The first parameter field carries a bit field called MB type and
provides information about the middlebox type. The following bits
within the field are defined. The remaining ones are reserved.
0x80 : packet filter firewall
0x40 : network address translator
0x10 : support of PDR transaction
0x01 : port translation (requires 0x40 set)
0x02 : protocol translation (requires 0x40 set)
0x04 : twice NAT support (requires 0x40 set)
For middleboxes that implement combinations of NAT and firewalls,
combinations of those flags are possible. For instance, for a
Network Address and Port Translator (NAPT) with packet filter and PDR
transaction support, the value of the MB type parameter field is
0xD1.
The following four parameters fields are binary flags with a size of
one bit:
I : internal IP address wildcard support
E : external IP address wildcard support
P : port wildcard support
S : persistent storage of policy rules
The supported IP version for the internal and external network are
coded into the IIV (Internal IP version) and EIV (external IP
version) parameter fields. They both have a size of two bits.
Allowed values are 0x1 for IP version 4 (IPv4), 0x2 for IP version 6
(IPv6), and the combination of both (0x3) for IPv4 and IPv6 dual
stack.
The next parameter field with a length of 16 bits is reserved.
The max policy rule lifetime parameter field specifies the maximum
lifetime a policy rule may have.
4.3.4. Policy Rule Identifier Attribute
The policy rule identifier (PID) attribute contains an identifier of
a policy rule. The identifier has a length of four octets.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0005 | 0x0004 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| policy rule identifier (PID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Policy rule identifier attribute
4.3.5. Group Identifier Attribute
The group identifier (GID) attribute contains an identifier of a
policy rule group. The identifier has a length of four octets.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0006 | 0x0004 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| group identifier (GID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Group identifier attribute
4.3.6. Policy Rule Lifetime Attribute
The policy rule lifetime attribute specifies the requested or actual
remaining lifetime of a policy rule, in seconds. Its value field
contains a 32-bit unsigned integer.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0007 | 0x0004 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| policy rule lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Policy rule lifetime attribute
4.3.7. Policy Rule Owner Attribute
The policy rule owner attribute specifies the authenticated agent
that created and owns the policy rule. Its value field does not have
a fixed length, but its length is limited to 255 octets. Please note
that the length of this attribute may have values that are not
multiples of 4 octets. The owner is set by the middlebox.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0008 | owner length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| owner
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Policy rule owner attribute
4.3.8. Address Tuple Attribute
The address tuple attribute contains a set of parameters specifying
IP and transport addresses. The length of this attribute is 32, 96,
or 192 bits.
The first parameter field has a length of 4 bits. It indicates
whether the contained parameters specify just the used protocols or
also concrete addresses. Defined values for this field are:
0x0 : full addresses
0x1 : protocols only
The second parameter field also has a length of 4 bits. It specifies
the IP version number. Defined values for this field are:
0x1 : IPv4
0x2 : IPv6
The third parameter field has a length of 8 bits. It specifies a
prefix length to be used for IP address wildcarding (see Section
1.1).
The fourth parameter field has also a length of 8 bits. It specifies
the transport protocol. Defined values for this field are all values
that are allowed in the ’Protocol’ field of the IPv4 header [RFC791]
or in the ’Next Header field’ of the IPv6 header [RFC2460]. The set
of defined numbers for these fields is maintained by the Internet
Assigned Numbers Authority (IANA) under the label ’PROTOCOL NUMBERS’.
The fifth parameter field has also a length of 8 bits. It specifies
the location of the address. Defined values for this field are:
0x00 : internal (A0)
0x01 : inside (A1)
0x02 : outside (A2)
0x03 : external (A3)
Port and address wildcarding can only be used in PER and PEA
transactions. The address tuple attribute carries a port number of 0
if the port should be wildcarded. For IPv4, a prefix length less
than 0x20 is IP address wildcarding. For IPv6, a prefix length less
than 0x80 is IP address wildcarding.
The port range field must be always greater than zero, but at least
1.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0009 | 0x0004 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x1 |IP ver.| prefix length |trnsp. protocol| location |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0009 | 0x000C |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0 | 0x1 | prefix length |trnsp. protocol| location |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| port number | port range |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0009 | 0x0018 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0 | 0x2 | prefix length |trnsp. protocol| location |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| port number | port range |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IPv6 address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Address tuple attributes
4.3.9. PRR Parameter Set Attribute
The policy reserve rule (PRR) parameter set attribute contains all
parameters of the PRR request except the group identifier:
- NAT mode
- port parity
- requested inside IP version
- requested outside IP version
- transport protocol
- port range
The attribute value field has a total size of 32 bits. It is sub-
divided into six parameter fields.
The first parameter field, called NM, has a length of 2 bits and
specifies the requested NAT mode of the middlebox at which a
reservation is requested. Defined values for this field are:
01 : traditional
10 : twice
The second parameter field, called PP, has also a length of 2 bits.
It specifies the requested port parity. Defined values for this
field are:
00 : any
01 : odd
10 : even
The third and the fourth parameter fields are called IPi and IPo,
respectively. Both have a length of 2 bits. They specify the
requested version of the IP protocol at the inside (IPi) or outside
(IPo) of the middlebox, respectively. Defined values for these
fields are:
00 : any
01 : IPv4
10 : IPv6
The fifth parameter field has a length of 8 bits. It specifies the
transport protocol for which the reservation should be made. A value
of zero indicates that the reservation is requested for an IP address
without specific selection of a protocol and a port number. Allowed
non-zero values are the defined values for the ’protocol’ field in
the IPv4 header and IPv6 extension headers. The set of defined
numbers for these fields is maintained by the Internet Assigned
Numbers Authority (IANA) under the label ’PROTOCOL NUMBERS’.
The sixth parameter field has a length of 16 bits. It contains an
unsigned integer specifying the length of the port range that should
be supported. A value of 0xFFFF indicates that the reservation
should be made for all port numbers of the specified transport
protocol. A port range field with the value of 0x0001 specifies that
only a single port number should be reserved. Values greater than
one indicate the number of consecutive port numbers to be reserved.
A value of zero is not valid for this field.
Please note that the wildcarding value 0xFFFF can only be used in the
port range field in the PRR parameter set attribute. In the address
tuple attribute, wildcarding of port numbers is specified by the port
number field having a value of zero (see Section 4.3.8).
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x000A | 0x0004 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|NM |PP |IPi|IPo|trnsp. protocol| port range |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: PRR parameter set attribute
4.3.10. PER Parameter Set Attribute
The policy enable rule (PER) parameter set attribute contains two
parameters: the requested port parity, and the direction of the
enabled data stream. The attribute value field has a total size of
32 bits, and it is sub-divided into 3 parameter fields.
The first parameter field has a length of 8 bits. It specifies the
requested port parity. Defined values for this field are:
0x00 : any
0x03 : same
The second parameter field has a length of 8 bits. It specifies the
direction of the enabled data stream. Defined values for this field
are:
0x01 : inbound
0x02 : outbound
0x03 : bi-directional
The third parameter field has a length of 16 bits and is reserved.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x000B | 0x0004 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| port parity | direction | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: PER parameter set attribute
5. SIMCO Message Formats
In the following, the formats of the different SIMCO message types
are defined. The definitions are grouped into protocol error
messages, session control messages, and policy rule control messages.
5.1. Protocol Error Replies and Notifications
When processing a received message, the middlebox might run into
message processing problems before it can identify whether the
message concerns session control or policy rule control. Also, it
might not be possible to determine the message type, or it might
detect a wrong message format. In these cases, the Badly Formed
Message (BFM) notification or one of the following negative replies
is sent:
0x0401 : BFM notification
0x0310 : wrong basic request message type
0x0311 : wrong request message sub-type
0x0312 : badly formed request
5.1.1. BFM Notification
The Badly Formed Message (BFM) notification message is sent from the
middlebox to the agent after a message was received that does not
comply to the SIMCO message format definition. The BFM notification
has no attributes and contains the SIMCO header only.
+--------------------------+
| SIMCO header |
+--------------------------+
Figure 15: BFM notification structure
5.1.2. Protocol Error Negative Replies
Protocol error negative replies are sent from the middlebox to the
agent if a message cannot be clearly interpreted, as it does not
comply with any defined message format. Protocol error negative
replies include ’wrong basic request message type’ (0x0310), ’wrong
request message sub-type’ (0x0311), and ’badly formed request’
(0x0312). These replies have no attributes. They consist of the
SIMCO header only.
+--------------------------+
| SIMCO header |
+--------------------------+
Figure 16: Protocol error negative reply structure
5.2. Session Control Messages
Session control messages include the following list of message types
(composed of basic type and sub-type):
0x0101 : SE request
0x0102 : SA request
0x0103 : ST request
0x0201 : SE positive reply
0x0202 : SA positive reply
0x0203 : ST positive reply
0x0310 : negative reply: wrong basic request message type
0x0311 : negative reply: wrong request message sub-type
0x0312 : negative reply: badly formed request
0x0320 : negative reply: request not applicable
0x0321 : negative reply: lack of resources
0x0322 : negative reply: protocol version mismatch
0x0323 : negative reply: authentication failed
0x0324 : negative reply: no authorization
0x0325 : negative reply: transport protocol problem
0x0326 : negative reply: security of underlying protocol layers
insufficient
0x0401 : BFM notification
0x0402 : AST notification
5.2.1. SE Request
The Session Establishment (SE) request message is sent from the agent
to the middlebox to request establishment of a session. The SE
request message contains one or two attributes: a mandatory SIMCO
version number attribute and an optional authentication challenge
attribute requesting that the middlebox authenticate itself.
+--------------------------+
| SIMCO header |
+--------------------------+
| SIMCO protocol version |
+--------------------------+
| authentication challenge | optional
+--------------------------+
Figure 17: Structure of SE request
5.2.2. SE Positive Reply
The Session Establishment (SE) reply message indicates completion of
session establishment. It contains a single mandatory attribute: the
middlebox capabilities attribute.
+--------------------------+
| SIMCO header |
+--------------------------+
| middlebox capabilities |
+--------------------------+
Figure 18: Structure of SE positive reply
5.2.3. SA Positive Reply
If the agent requested middlebox authentication, or if the middlebox
wants the agent to authenticate itself, then the middlebox replies on
the SE request with a Session Authentication (SA) reply message
instead of an SE reply message. The SA reply message contains two
optional attributes, but at least one of them needs to be present.
The first one is an authentication challenge attribute requesting
that the agent authenticate itself. The second one is an
authentication token attribute authenticating the middlebox as the
reply to an authentication request by the agent.
+--------------------------+