tech-invite   World Map
3GPP     Specs     Glossaries     UICC       IETF     RFCs     Groups     SIP     ABNFs       T+       Search     Home

RFC 4540

Experimental
Pages: 67
Top     in Index     Prev     Next
in Group Index     No Prev: Lowest Number in Group     No Next: Highest Number in Group     Group: ~nec

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

Part 1 of 3, p. 1 to 18
None       Next RFC Part

 


Top       ToC       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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 RFC Part