Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4540

NEC's Simple Middlebox Configuration (SIMCO) Protocol Version 3.0

Pages: 67
Experimental
Updated by:  8996
Part 1 of 3 – Pages 1 to 18
None   None   Next

Top   ToC   RFC4540 - Page 1
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.
Top   ToC   RFC4540 - Page 2

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
Top   ToC   RFC4540 - Page 3
           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
Top   ToC   RFC4540 - Page 4
   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.
Top   ToC   RFC4540 - Page 5
   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.
Top   ToC   RFC4540 - Page 6

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.
Top   ToC   RFC4540 - Page 7

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
Top   ToC   RFC4540 - Page 8

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
Top   ToC   RFC4540 - Page 9
      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
Top   ToC   RFC4540 - Page 10
   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
Top   ToC   RFC4540 - Page 11

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.
Top   ToC   RFC4540 - Page 12
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            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:
Top   ToC   RFC4540 - Page 13
      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.
Top   ToC   RFC4540 - Page 14
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            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
Top   ToC   RFC4540 - Page 15
   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.
Top   ToC   RFC4540 - Page 16
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            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
Top   ToC   RFC4540 - Page 17
   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.
Top   ToC   RFC4540 - Page 18
   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


(next page on part 2)

Next Section