RFC 4540
NEC's Simple Middlebox Configuration (SIMCO) Protocol Version 3.0
Network Working Group M. Stiemerling 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 ........................................651. 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 Message4.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 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 attribute4.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 attribute4.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 attribute4.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 attributes4.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 attribute4.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
(next page on part 2)
