summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4540.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4540.txt')
-rw-r--r--doc/rfc/rfc4540.txt3755
1 files changed, 3755 insertions, 0 deletions
diff --git a/doc/rfc/rfc4540.txt b/doc/rfc/rfc4540.txt
new file mode 100644
index 0000000..501dbf6
--- /dev/null
+++ b/doc/rfc/rfc4540.txt
@@ -0,0 +1,3755 @@
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+
+
+Stiemerling, et al. Experimental [Page 1]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+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
+
+
+
+Stiemerling, et al. Experimental [Page 2]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+ 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
+
+
+
+
+Stiemerling, et al. Experimental [Page 3]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+Stiemerling, et al. Experimental [Page 4]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+ 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.
+
+
+
+
+
+
+
+Stiemerling, et al. Experimental [Page 5]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+Stiemerling, et al. Experimental [Page 6]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+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
+
+
+
+
+
+
+
+
+
+Stiemerling, et al. Experimental [Page 7]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+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
+
+
+
+Stiemerling, et al. Experimental [Page 8]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+ 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
+
+
+
+
+
+Stiemerling, et al. Experimental [Page 9]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+ 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
+
+
+
+
+
+
+
+
+
+Stiemerling, et al. Experimental [Page 10]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+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.
+
+
+
+
+
+Stiemerling, et al. Experimental [Page 11]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 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:
+
+
+
+
+Stiemerling, et al. Experimental [Page 12]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+ 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.
+
+
+
+Stiemerling, et al. Experimental [Page 13]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 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
+
+
+
+Stiemerling, et al. Experimental [Page 14]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stiemerling, et al. Experimental [Page 15]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 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
+
+
+
+
+Stiemerling, et al. Experimental [Page 16]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+ 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.
+
+
+
+
+
+Stiemerling, et al. Experimental [Page 17]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+ 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
+
+
+
+
+
+
+
+
+Stiemerling, et al. Experimental [Page 18]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+5. SIMCO Message Formats
+
+ In the following, the formats of the different SIMCO message types
+ are defined. The definitions are grouped into protocol error
+ messages, session control messages, and policy rule control messages.
+
+5.1. Protocol Error Replies and Notifications
+
+ When processing a received message, the middlebox might run into
+ message processing problems before it can identify whether the
+ message concerns session control or policy rule control. Also, it
+ might not be possible to determine the message type, or it might
+ detect a wrong message format. In these cases, the Badly Formed
+ Message (BFM) notification or one of the following negative replies
+ is sent:
+
+ 0x0401 : BFM notification
+ 0x0310 : wrong basic request message type
+ 0x0311 : wrong request message sub-type
+ 0x0312 : badly formed request
+
+5.1.1. BFM Notification
+
+ The Badly Formed Message (BFM) notification message is sent from the
+ middlebox to the agent after a message was received that does not
+ comply to the SIMCO message format definition. The BFM notification
+ has no attributes and contains the SIMCO header only.
+
+ +--------------------------+
+ | SIMCO header |
+ +--------------------------+
+
+ Figure 15: BFM notification structure
+
+5.1.2. Protocol Error Negative Replies
+
+ Protocol error negative replies are sent from the middlebox to the
+ agent if a message cannot be clearly interpreted, as it does not
+ comply with any defined message format. Protocol error negative
+ replies include 'wrong basic request message type' (0x0310), 'wrong
+ request message sub-type' (0x0311), and 'badly formed request'
+ (0x0312). These replies have no attributes. They consist of the
+ SIMCO header only.
+
+
+
+
+
+
+
+
+Stiemerling, et al. Experimental [Page 19]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+ +--------------------------+
+ | SIMCO header |
+ +--------------------------+
+
+ Figure 16: Protocol error negative reply structure
+
+5.2. Session Control Messages
+
+ Session control messages include the following list of message types
+ (composed of basic type and sub-type):
+
+ 0x0101 : SE request
+ 0x0102 : SA request
+ 0x0103 : ST request
+ 0x0201 : SE positive reply
+ 0x0202 : SA positive reply
+ 0x0203 : ST positive reply
+ 0x0310 : negative reply: wrong basic request message type
+ 0x0311 : negative reply: wrong request message sub-type
+ 0x0312 : negative reply: badly formed request
+ 0x0320 : negative reply: request not applicable
+ 0x0321 : negative reply: lack of resources
+ 0x0322 : negative reply: protocol version mismatch
+ 0x0323 : negative reply: authentication failed
+ 0x0324 : negative reply: no authorization
+ 0x0325 : negative reply: transport protocol problem
+ 0x0326 : negative reply: security of underlying protocol layers
+ insufficient
+ 0x0401 : BFM notification
+ 0x0402 : AST notification
+
+5.2.1. SE Request
+
+ The Session Establishment (SE) request message is sent from the agent
+ to the middlebox to request establishment of a session. The SE
+ request message contains one or two attributes: a mandatory SIMCO
+ version number attribute and an optional authentication challenge
+ attribute requesting that the middlebox authenticate itself.
+
+ +--------------------------+
+ | SIMCO header |
+ +--------------------------+
+ | SIMCO protocol version |
+ +--------------------------+
+ | authentication challenge | optional
+ +--------------------------+
+
+ Figure 17: Structure of SE request
+
+
+
+Stiemerling, et al. Experimental [Page 20]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+5.2.2. SE Positive Reply
+
+ The Session Establishment (SE) reply message indicates completion of
+ session establishment. It contains a single mandatory attribute: the
+ middlebox capabilities attribute.
+
+ +--------------------------+
+ | SIMCO header |
+ +--------------------------+
+ | middlebox capabilities |
+ +--------------------------+
+
+ Figure 18: Structure of SE positive reply
+
+5.2.3. SA Positive Reply
+
+ If the agent requested middlebox authentication, or if the middlebox
+ wants the agent to authenticate itself, then the middlebox replies on
+ the SE request with a Session Authentication (SA) reply message
+ instead of an SE reply message. The SA reply message contains two
+ optional attributes, but at least one of them needs to be present.
+ The first one is an authentication challenge attribute requesting
+ that the agent authenticate itself. The second one is an
+ authentication token attribute authenticating the middlebox as the
+ reply to an authentication request by the agent.
+
+ +--------------------------+
+ | SIMCO header |
+ +--------------------------+
+ | authentication challenge | optional
+ +--------------------------+
+ | authentication token | optional
+ +--------------------------+
+
+ Figure 19: Structure of SA positive reply
+
+5.2.4. SA Request
+
+ The Session Authentication (SA) request message is sent from the
+ agent to the middlebox after an initial SE request was answered by an
+ SA reply. The SE request message contains one optional attribute: an
+ authentication token attribute authenticating the agent as the
+ response to an authentication challenge sent by the middlebox in an
+ SA reply.
+
+
+
+
+
+
+
+Stiemerling, et al. Experimental [Page 21]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+ +--------------------------+
+ | SIMCO header |
+ +--------------------------+
+ | authentication token | optional
+ +--------------------------+
+
+ Figure 20: Structure of SA request
+
+5.2.5. ST Request and ST Positive Reply
+
+ The Session Termination (ST) request message is sent from the agent
+ to the middlebox to request termination of a session. The ST
+ positive reply is returned, acknowledging the session termination.
+ Both messages have no attributes and contain the SIMCO header only.
+
+ +--------------------------+
+ | SIMCO header |
+ +--------------------------+
+
+ Figure 21: Structure of ST request and positive reply
+
+5.2.6. SE Negative Replies
+
+ There are nine different negative reply messages that can be sent
+ from a middlebox to the agent if the middlebox rejects an SE request.
+ Three of them are protocol error negative replies (0x031X) already
+ covered in Section 4.1.2.
+
+ The remaining six negative replies are specific to session
+ establishment. One of them, the 'protocol version mismatch' negative
+ reply (0x0322), contains a single attribute: the protocol version
+ attribute.
+
+ +--------------------------+
+ | SIMCO header |
+ +--------------------------+
+ | SIMCO protocol version |
+ +--------------------------+
+
+ Figure 22a: Structure of SE negative replies
+
+ The remaining three replies include 'request not applicable'
+ (0x0320), 'lack of resources' (0x0321), 'authentication failed'
+ (0x0323), 'no authorization' (0x0324), 'transport protocol problem'
+ (0x0325), and 'security of underlying protocol layers insufficient'
+ (0x0326). They consist of the SIMCO header only.
+
+
+
+
+
+Stiemerling, et al. Experimental [Page 22]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+ +--------------------------+
+ | SIMCO header |
+ +--------------------------+
+
+ Figure 22b: Structure of SE negative replies
+
+5.2.7. AST Notification
+
+ The Asynchronous Session Termination (AST) notification message is
+ sent from the middlebox to the agent, if the middlebox wants to
+ terminate a SIMCO session. It has no attributes and contains the
+ SIMCO header only.
+
+ +--------------------------+
+ | SIMCO header |
+ +--------------------------+
+
+ Figure 22a: Structure of AST notifications
+
+5.3. Policy Rule Control Messages
+
+ Policy Rule control messages include the following list of message
+ types (composed of basic type and sub-type):
+
+ 0x0111 : PRR request
+ 0x0112 : PER request
+ 0x0113 : PEA request
+ 0x0114 : PDR request
+ 0x0115 : PLC request
+ 0x0121 : PRS request
+ 0x0122 : PRL request
+ 0x0211 : PRR positive reply
+ 0x0212 : PER positive reply
+ 0x0214 : PDR positive reply
+ 0x0215 : PLC positive reply
+ 0x0216 : PRD positive reply
+ 0x0221 : PRS positive reply
+ 0x0223 : PES positive reply
+ 0x0224 : PDS positive reply
+ 0x0222 : PRL positive reply
+ 0x0310 : negative reply: wrong basic request message type
+ 0x0311 : negative reply: wrong request message sub-type
+ 0x0312 : negative reply: badly formed request
+ 0x0340 : negative reply: transaction not supported
+ 0x0341 : negative reply: agent not authorized for this transaction
+ 0x0342 : negative reply: no resources available for this
+ transaction
+ 0x0343 : negative reply: specified policy rule does not exist
+
+
+
+Stiemerling, et al. Experimental [Page 23]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+ 0x0344 : negative reply: specified policy rule group does not exist
+ 0x0345 : negative reply: not authorized for accessing this policy
+ 0x0346 : negative reply: not authorized for accessing specified
+ group
+ 0x0347 : negative reply: requested address space not available
+ 0x0348 : negative reply: lack of IP addresses
+ 0x0349 : negative reply: lack of port numbers
+ 0x034A : negative reply: middlebox configuration failed
+ 0x034B : negative reply: inconsistent request
+ 0x034C : negative reply: requested wildcarding not supported
+ 0x034D : negative reply: protocol type doesn't match
+ 0x034E : negative reply: NAT mode not supported
+ 0x034F : negative reply: IP version mismatch
+ 0x0350 : negative reply: conflict with existing rule
+ 0x0351 : negative reply: not authorized to change lifetime
+ 0x0352 : negative reply: lifetime can't be extended
+ 0x0353 : negative reply: illegal IP Address
+ 0x0354 : negative reply: protocol type not supported
+ 0x0355 : negative reply: illegal port number
+ 0x0356 : negative reply: illegal NOSP
+ 0x0357 : negative reply: already enable PID
+ 0x0358 : negative reply: parity doesn't match
+ 0x0401 : negative reply: BFM notification
+ 0x0403 : negative reply: ARE notification
+
+5.3.1. Policy Events and Asynchronous Notifications
+
+ SIMCO maintains an owner attribute for each policy rule at the
+ middlebox. Depending on the configuration of the middlebox, several
+ agents may access the same policy rule; see also [RFC3989], Sections
+ 2.1.5 and 2.3.4.
+
+ To keep all agents synchronized about the state of their policy
+ rules, SIMCO generates Asynchronous Rule Event (ARE) notifications.
+ When an agent is reserving or enabling a policy rule, the middlebox
+ sends an ARE to all agents that are authorized to access this policy
+ rule. The middlebox sends an ARE to all agents authorized to access
+ this policy rule when the rule lifetime is modified or if the rule is
+ deleted.
+
+5.3.2. PRR Request
+
+ The Policy Reserve Rule (PRR) request message is sent from the agent
+ to the middlebox to request reservation of an IP address (and
+ potentially also a range of port numbers) at the middlebox. Besides
+ the SIMCO header, the request message contains two or three
+ attributes. The first one is the PRR parameter set attribute
+ specifying all parameters of the request except the requested policy
+
+
+
+Stiemerling, et al. Experimental [Page 24]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+ rule lifetime and the group identifier. The missing parameters are
+ covered by the following two attributes. The last attribute, the
+ group identifier, is optional.
+
+ +--------------------------+
+ | SIMCO header |
+ +--------------------------+
+ | PRR parameter set |
+ +--------------------------+
+ | policy rule lifetime |
+ +--------------------------+
+ | group identifier | optional
+ +--------------------------+
+
+ Figure 23: Structure of PRR request
+
+5.3.3. PER Request
+
+ The Policy Enable Rule (PER) request message is sent from the agent
+ to the middlebox to request enabling of data communication between an
+ internal and an external address. Besides the SIMCO header, the
+ request message contains four or five attributes. The first one is
+ the PER parameter set attribute specifying all parameters of the
+ request except the internal address, the external address, the
+ requested policy rule lifetime, and the group identifier. The
+ missing parameters are covered by the following four attributes. Two
+ address tuple parameters specify internal and external address
+ tuples. Much like the PRR request, the last two attributes specify
+ the requested lifetime and group identifier. The group identifier
+ attribute is optional.
+
+ +--------------------------+
+ | SIMCO header |
+ +--------------------------+
+ | PER parameter set |
+ +--------------------------+
+ | address tuple (internal) |
+ +--------------------------+
+ | address tuple (external) |
+ +--------------------------+
+ | policy rule lifetime |
+ +--------------------------+
+ | group identifier | optional
+ +--------------------------+
+
+ Figure 24: Structure of PER request
+
+
+
+
+
+Stiemerling, et al. Experimental [Page 25]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+5.3.4. PEA Request
+
+ The Policy Enable rule After reservation (PEA) request message is
+ sent from the agent to the middlebox to request enabling of data
+ communication between an internal and an external address. It is
+ similar to the PER request. There is just one difference. The
+ optional group identifier attribute of the PER request is replaced by
+ a mandatory policy rule identifier attribute referencing an already
+ established policy reserve rule established by a PRR transaction.
+
+ +--------------------------+
+ | SIMCO header |
+ +--------------------------+
+ | PER parameter set |
+ +--------------------------+
+ | address tuple (internal) |
+ +--------------------------+
+ | address tuple (external) |
+ +--------------------------+
+ | policy rule lifetime |
+ +--------------------------+
+ | policy rule identifier |
+ +--------------------------+
+
+ Figure 25: Structure of PEA request
+
+ The group identifier attribute is not included in the PEA request,
+ since the group membership of the policy enable rule is inherited of
+ the policy reserve rule.
+
+5.3.5. PLC Request
+
+ The Policy Rule Lifetime Change (PLC) request message is sent from
+ the agent to the middlebox to request a change of the remaining
+ policy lifetime. Besides the SIMCO header, the request message
+ contains two attributes specifying the policy rule to which the
+ change should be applied and specifying the requested remaining
+ lifetime.
+
+ +--------------------------+
+ | SIMCO header |
+ +--------------------------+
+ | policy rule identifier |
+ +--------------------------+
+ | policy rule lifetime |
+ +--------------------------+
+
+ Figure 26: Structure of PLC request
+
+
+
+Stiemerling, et al. Experimental [Page 26]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+5.3.6. PRS Request
+
+ The Policy Rule Status (PRS) request message is sent from the agent
+ to the middlebox to request a report on the status of a specified
+ policy rule. Besides the SIMCO header, the request message contains
+ just one attribute specifying the policy rule for which the report is
+ requested.
+
+ +--------------------------+
+ | SIMCO header |
+ +--------------------------+
+ | policy rule identifier |
+ +--------------------------+
+
+ Figure 27: Structure of PRS request
+
+5.3.7. PRL Request
+
+ The Policy Rule List (PRL) request message is sent from the agent to
+ the middlebox to request a list of all policy rules accessible to the
+ agent. The message consists of the SIMCO header only.
+
+ +--------------------------+
+ | SIMCO header |
+ +--------------------------+
+
+ Figure 28: Structure of PRL request
+
+5.3.8. PDR Request
+
+ The Policy Disable Rule (PDR) request message is sent from the agent
+ to the middlebox to request a disable rule. The message consists of
+ the SIMCO header, an internal address tuple, an external address
+ tuple, and a lifetime attribute.
+
+ +--------------------------+
+ | SIMCO header |
+ +--------------------------+
+ | address tuple (internal) |
+ +--------------------------+
+ | address tuple (external) |
+ +--------------------------+
+ | policy rule lifetime |
+ +--------------------------+
+
+ Figure 29: Structure of PDR request
+
+
+
+
+
+Stiemerling, et al. Experimental [Page 27]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+5.3.9. PRR Positive Reply
+
+ The Policy Reserve Rule (PRR) positive reply is sent after successful
+ reservation of an address at the inside or outside of the middlebox.
+ The message contains four mandatory attributes and an optional
+ attribute: the policy rule identifier of the new policy reserve rule,
+ the corresponding group identifier, the remaining lifetime of the
+ policy rule, the reserved outside address tuple, and the optional
+ reserved inside address tuple. The reserved inside address tuple is
+ only returned when the middlebox is of type twice-NAT.
+
+ +--------------------------+
+ | SIMCO header |
+ +--------------------------+
+ | policy rule identifier |
+ +--------------------------+
+ | group identifier |
+ +--------------------------+
+ | policy rule lifetime |
+ +--------------------------+
+ | address tuple (outside) |
+ +--------------------------+
+ | address tuple (inside) | optional
+ +--------------------------+
+
+ Figure 30: Structure of PRR positive reply
+
+5.3.10. PER Positive Reply
+
+ The Policy Enable Rule (PER) positive reply is sent after the
+ middlebox successfully enables data transfer between an internal and
+ an external address (by using a PER or PEA request message). The
+ message contains five attributes: the policy rule identifier of the
+ new policy enable rule, the corresponding group identifier, the
+ remaining lifetime of the policy rule, the address tuple at the
+ outside of the middlebox, and the address tuple at the inside of the
+ middlebox.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stiemerling, et al. Experimental [Page 28]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+ +--------------------------+
+ | SIMCO header |
+ +--------------------------+
+ | policy rule identifier |
+ +--------------------------+
+ | group identifier |
+ +--------------------------+
+ | policy rule lifetime |
+ +--------------------------+
+ | address tuple (outside) |
+ +--------------------------+
+ | address tuple (inside) |
+ +--------------------------+
+
+ Figure 31: Structure of PER positive reply
+
+5.3.11. PLC Positive Reply
+
+ The Policy Lifetime Change (PLC) positive reply is sent after the
+ middlebox changes the lifetime of a policy rule to a positive (non-
+ zero) value. The message contains just a single attribute: the
+ remaining lifetime of the policy rule.
+
+ +--------------------------+
+ | SIMCO header |
+ +--------------------------+
+ | policy rule lifetime |
+ +--------------------------+
+
+ Figure 32: Structure of PLC positive reply
+
+5.3.12. PRD Positive Reply
+
+ The Policy Rule Deleted (PRD) positive reply is sent after the
+ middlebox changes the remaining lifetime of a policy rule to zero,
+ which means that it terminates the policy rule. The message consists
+ of the SIMCO header only.
+
+ +--------------------------+
+ | SIMCO header |
+ +--------------------------+
+
+ Figure 33: Structure of PRD positive reply
+
+
+
+
+
+
+
+
+Stiemerling, et al. Experimental [Page 29]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+5.3.13. PRS Positive Reply
+
+ The Policy Reserve Rule Status (PRS) positive reply is used for
+ reporting the status of a policy reserve rule. The message format is
+ identical with the format of the PRR positive reply except that it
+ contains, in addition, a policy rule owner attribute.
+
+ +--------------------------+
+ | SIMCO header |
+ +--------------------------+
+ | policy rule identifier |
+ +--------------------------+
+ | group identifier |
+ +--------------------------+
+ | policy rule lifetime |
+ +--------------------------+
+ | address tuple (outside) |
+ +--------------------------+
+ | address tuple (inside) | optional
+ +--------------------------+
+ | policy rule owner |
+ +--------------------------+
+
+ Figure 34: Structure of PRS positive reply
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stiemerling, et al. Experimental [Page 30]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+5.3.14. PES Positive Reply
+
+ The Policy Enable Rule Status (PES) positive reply is used for
+ reporting the status of a policy enable rule.
+
+ +--------------------------+
+ | SIMCO header |
+ +--------------------------+
+ | policy rule identifier |
+ +--------------------------+
+ | group identifier |
+ +--------------------------+
+ | PER parameter set |
+ +--------------------------+
+ | address tuple (internal) |
+ +--------------------------+
+ | address tuple (inside) |
+ +--------------------------+
+ | address tuple (outside) |
+ +--------------------------+
+ | address tuple (external) |
+ +--------------------------+
+ | policy rule lifetime |
+ +--------------------------+
+ | policy rule owner |
+ +--------------------------+
+
+ Figure 35: Structure of PES positive reply
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stiemerling, et al. Experimental [Page 31]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+5.3.15. PDS Positive Reply
+
+ The Policy Disable Rule Status (PDS) positive reply is used for
+ reporting the status of a policy disable rule. The message contains
+ five attributes: the policy rule identifier, the internal and
+ external address tuples, the policy disable rule lifetime, and the
+ policy rule owner.
+
+ +--------------------------+
+ | SIMCO header |
+ +--------------------------+
+ | policy rule identifier |
+ +--------------------------+
+ | address tuple (internal) |
+ +--------------------------+
+ | address tuple (external) |
+ +--------------------------+
+ | policy rule lifetime |
+ +--------------------------+
+ | policy rule owner |
+ +--------------------------+
+
+ Figure 36: Structure of PDS positive reply
+
+3.5.16. PRL Positive Reply
+
+ The Policy Rule List (PRL) positive reply is used for reporting the
+ list of all established policy rules. The number of attributes of
+ this message is variable. The message contains one policy rule
+ identifier attribute per established policy rule.
+
+ +--------------------------+
+ | SIMCO header |
+ +--------------------------+
+ | policy rule identifier |
+ +--------------------------+
+ | policy rule identifier |
+ +--------------------------+
+ | |
+ . . .
+ | |
+ +--------------------------+
+ | policy rule identifier |
+ +--------------------------+
+
+ Figure 37: Structure of PRL positive reply
+
+
+
+
+
+Stiemerling, et al. Experimental [Page 32]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+5.3.17. PDR Positive Replies
+
+ The Policy Disable Rule (PDR) positive reply is sent after the
+ middlebox successfully enables the policy disable rule and removal of
+ conflicting policy rules. The message contains two attributes: the
+ policy rule identifier of the new policy disable rule, and the
+ remaining lifetime of the policy rule.
+
+ +--------------------------+
+ | SIMCO header |
+ +--------------------------+
+ | policy rule identifier |
+ +--------------------------+
+ | policy rule lifetime |
+ +--------------------------+
+
+ Figure 38: Structure of PDR positive reply
+
+5.3.18. Policy Rule Control Negative Replies
+
+ Session establishment negative replies are sent from the middlebox to
+ the agent if a middlebox rejects a policy rule control request.
+ Beyond protocol error replies, a number of policy rule control-
+ specific negative reply messages that can be sent. They are listed
+ at the beginning of Section 5.3. They all have no attributes. They
+ consist of the SIMCO header only.
+
+ +--------------------------+
+ | SIMCO header |
+ +--------------------------+
+
+ Figure 39: Structure of Policy rule control negative replies
+
+5.3.19. ARE Notification
+
+ The Asynchronous Policy Rule Event (ARE) notification message is sent
+ from the middlebox to the agent. All agents participating in an open
+ SIMCO session that are authorized to access this policy rule and are
+ not explicitly requesting an action (i.e., reserving, enabling, and
+ changing lifetime) receive such an ARE notification, when:
+
+ - a policy rule is deleted (lifetime attribute = 0)
+
+ - a policy rule is reserved (lifetime attribute = lifetime)
+
+ - a policy rule is enabled (lifetime attribute = lifetime)
+
+ - a policy rule's lifetime changed (lifetime attribute = lifetime)
+
+
+
+Stiemerling, et al. Experimental [Page 33]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+ Besides the SIMCO header, the request message contains two attributes
+ specifying the policy rule that is concerned and the current
+ lifetime.
+
+ +--------------------------+
+ | SIMCO header |
+ +--------------------------+
+ | policy rule identifier |
+ +--------------------------+
+ | policy rule lifetime |
+ +--------------------------+
+
+ Figure 40: Structure of ARE notification
+
+6. Message Format Checking
+
+ This section describes common processing of all messages that are
+ received by a middlebox.
+
+ 1) When a message arrives at a middlebox, the header is checked for
+ consistency before the payload is processed.
+
+ o If the header checks fail, the middlebox sends a BFM
+ notification.
+
+ o If a session is already established, then the middlebox also
+ sends an AST notification and closes the connection.
+
+ 2) The middlebox waits until it has received as many octets from the
+ agent as specified by the message length plus 8 octets (the length
+ of the SIMCO header).
+
+ o If the middlebox is still waiting and does not receive any more
+ octets from the agent for 60 seconds, it sends a BFM
+ notification.
+
+ o If a session is already established, then the middlebox also
+ sends an AST notification and closes the connection after
+ sending the BFM notification; otherwise, it closes the
+ connection without sending another message.
+
+ 3) After receiving a sufficient number of octets, the middlebox reads
+ the transaction identifier and the basic message type.
+
+ o If the value of the basic message type fields does not equal
+ 0x01 (request message), then the middlebox stops processing the
+ message and sends a negative reply of type 'wrong basic request
+ message type' (0x0310) to the agent.
+
+
+
+Stiemerling, et al. Experimental [Page 34]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+ o If no session is established, then the middlebox closes the
+ connection after sending the 0x0310 reply.
+
+ 4) Then the middlebox checks the message sub-type.
+
+ o If no session is established, then only sub-type 'session
+ establishment' (0x01) is accepted. For all other sub-types,
+ the middlebox sends a reply of type 'wrong request message
+ sub-type' (0x0311) to the agent and closes the connection after
+ sending the reply.
+
+ o If a session is already established, then the middlebox checks
+ if the message sub-type is one of the sub-types defined in
+ Section 4.2.2. (excluding 'session establishment' (0x01),
+ 'session termination' (0x03), and 'policy rule
+ deletion'(0x15)).
+
+ o If not, then the middlebox stops processing the message and
+ sends a reply of type 'wrong request message sub-type'
+ (0x0311) to the agent.
+
+ 5) Then the middlebox checks the TLV-structured attributes in the
+ message.
+
+ o If their type or number does not comply with the defined format
+ for this message type, the middlebox stops processing the
+ message and sends a reply of type 'badly formed request'
+ (0x0312) to the agent.
+
+ o If no session is established, then the middlebox closes the
+ connection after sending the 0x0312 reply.
+
+ 6) After all message format checks are passed, the middlebox
+ processes the content of the attributes as described in the
+ following sections.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stiemerling, et al. Experimental [Page 35]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+7. Session Control Message Processing
+
+ For session control, the agent can send SE, SA, and ST request
+ messages. The middlebox then sends per request a single reply back
+ to the agent. Additionally, the middlebox may send unsolicited AST
+ notifications.
+
+7.1. Session State Machine
+
+ For each session, there is a session state machine illustrated by the
+ figure below.
+
+ SE/BFM
+ SE/0x031X
+ SE/0x032X
+ +-------+
+ | v
+ +----------+
+ | CLOSED |----------------+
+ +----------+ |
+ | ^ ^ |
+ | | | SA/BFM | SE/SA
+ | | | SA/0x031X |
+ | | | SA/0x032X |
+ SE/SE | | | ST/ST v
+ | | | AST +----------+
+ | | +------------| NOAUTH |
+ | | +----------+
+ | | AST |
+ v | ST/ST | SA/SE
+ +----------+ |
+ | OPEN |<---------------+
+ +----------+
+
+ Figure 41: Session state machine
+
+ The figure illustrates all possible state transitions of a session.
+ Request transactions (SE, SA, ST) are denoted by a descriptor of the
+ request message, a '/' symbol, and a descriptor of the reply message.
+ Notification transactions are denoted just by the a notification
+ descriptor. For example, a successful SE transaction is denoted by
+ 'SE/SE', and an AST notification is denoted by 'AST'.
+
+ Initially, all sessions are in state CLOSED. From there, a
+ successful SE transaction can change its state either to NOAUTH or to
+ OPEN. From state NOAUTH, a successful SA transaction changes session
+ state to OPEN. A failed SA transaction changes session state from
+
+
+
+
+Stiemerling, et al. Experimental [Page 36]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+ NOAUTH back to CLOSED. Successful ST transactions and AST
+ notifications change sessions from state NOAUTH or from state OPEN to
+ state CLOSED.
+
+ A SIMCO session is established in state OPEN, which is the only state
+ in which the middlebox accepts requests other than SE, SA, and ST.
+
+7.2. Processing SE Requests
+
+ The SE request is only applicable if the session is in state CLOSED.
+ If a session is in state NOAUTH or OPEN, then the middlebox sends a
+ negative reply message of type 'request not applicable' (0x0320) to
+ the agent, leaving the state of the session unchanged.
+
+ Before processing the content of the SE request message, the
+ middlebox may check its resources and decide that available resources
+ are not sufficient to serve the agent. In such a case, the middlebox
+ returns a negative reply of type 'lack of resources' (0x0321) and
+ closes the connection. Furthermore, the middlebox may decide to
+ reject the SE request if the selected network connection and its
+ protocol specific parameters are not acceptable for the middlebox.
+ In such a case, the middlebox returns a negative reply of type
+ 'transport protocol problem' (0x0325) and closes the connection. The
+ middlebox returns a negative reply of type 'security of underlying
+ protocol layers insufficient' (0x0326) and closes the connection, if
+ the security properties of the network connection do not match the
+ middlebox's requirements.
+
+ Processing of an SE request message starts with checking the major
+ and minor protocol version number in the protocol version attribute.
+ If the middlebox does not support the specified version number, then
+ the middlebox returns a negative reply message of type 'protocol
+ version mismatch' (0x0322) with the protocol version attribute
+ indicating a version number that is supported by the middlebox.
+ After sending this reply, the middlebox closes the connection.
+
+ If the agent is already sufficiently authenticated by means of the
+ underlying network connection (for instance, IPsec or TLS), then the
+ middlebox checks whether the agent is authorized to configure the
+ middlebox. If it is not, the middlebox returns a negative reply of
+ type 'no authorization' (0x0324) and closes the connection.
+
+ A positive reply on the SE request may be of sub-type SE or SA. An
+ SE request is sent after both parties sufficiently authenticate and
+ authorize each other. An SA reply message is sent if explicit
+ authentication is requested by any party. The agent requests
+ explicit authentication by adding an authentication challenge
+ attribute to the SE request message. The middlebox requests explicit
+
+
+
+Stiemerling, et al. Experimental [Page 37]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+ authentication by returning an SA reply message with an
+ authentication challenge attribute to the agent. If both parties
+ request explicit authentication, then the SA reply message contains
+ both an authentication challenge attribute for the agent and an
+ authentication token attribute authenticating the middlebox.
+
+ If the SE request message contains an authentication challenge
+ attribute, then the middlebox checks if it can authenticate itself.
+ If yes, it adds a corresponding authentication token attribute to the
+ SA reply. If it cannot authenticate based on the authentication
+ challenge attribute, it adds an authentication token attribute to the
+ SA reply message with a value field of length zero.
+
+ If the middlebox wants the agent to explicitly authenticate itself,
+ then the middlebox creates an authentication challenge attribute for
+ the agent and adds it to the SA reply message.
+
+ If the middlebox replies to the SE request message with an SA reply
+ message, then the session state changes from CLOSED to NO_AUTH.
+
+ If the SE request message did not contain an authentication challenge
+ attribute and if the middlebox does not request the agent to
+ explicitly authenticate itself, then the middlebox sends an SE reply
+ message in response to the SE request message. This implies that the
+ session state changes from CLOSED to OPEN.
+
+ The SE reply message contains a capabilities attribute describing the
+ middlebox capabilities.
+
+7.3. Processing SA Requests
+
+ The SA request is only applicable if the session is in state NOAUTH.
+ If a session is in state CLOSED or OPEN, then the middlebox sends a
+ negative reply message of type 'request not applicable' (0x0320) to
+ the agent. The state of the session remains unchanged.
+
+ After receiving an SA request message in state NOAUTH, the middlebox
+ checks if the agent is sufficiently authenticated. Authentication
+ may be based on an authentication token attribute that is optionally
+ contained in the SA request message. If the agent is not
+ sufficiently authenticated, then the middlebox returns a negative
+ reply of type 'authentication failed' (0x0323) and closes the
+ connection.
+
+ If authentication of the agent is successful, the middlebox checks if
+ the agent is authorized to configure the middlebox. If not, the
+ middlebox returns a negative reply of type 'no authorization'
+ (0x0324) and closes the connection.
+
+
+
+Stiemerling, et al. Experimental [Page 38]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+ If authorization is successful, then the session state changes from
+ NOAUTH to OPEN, and the agent returns an SE reply message that
+ concludes session setup. The middlebox states its capabilities in
+ the capability attribute contained in the SE reply message.
+
+7.4. Processing ST Requests
+
+ The ST request is only applicable if the session is in state NOAUTH
+ or OPEN. If a session is in state CLOSED, then the middlebox sends a
+ negative reply message of type 'request not applicable' (0x0320) to
+ the agent. The state of the session remains unchanged.
+
+ The middlebox always replies to a correct ST request with a positive
+ ST reply. The state of the session changes from OPEN or from NOAUTH
+ to CLOSED. After sending the ST reply, the middlebox closes the
+ connection. Requests received after receiving the ST request and
+ before closing the connection are ignored by the middlebox.
+
+7.5. Generating AST Notifications
+
+ At any time, the middlebox may terminate an established session and
+ change the session state from OPEN or from NOAUTH to CLOSED. Session
+ termination is indicated to the agent by sending an AST notification.
+
+ Before sending the notification, the middlebox ensures that for all
+ requests that have been processed, according replies are returned to
+ the agent, such that the agent exactly knows the state of the
+ middlebox at the time of session termination. After sending the AST
+ notification, the middlebox sends no more messages to the agent, and
+ it closes the connection.
+
+7.6. Session Termination by Interruption of Connection
+
+ Section 2.2.4 of [RFC3989] describes the session behavior when the
+ network connection is interrupted. The behavior is defined for the
+ middlebox (i.e., the SIMCO server) only and does not consider the
+ behavior of the SIMCO agent in such an event.
+
+ If the SIMCO agent detects an interruption of the underlying network
+ connection, it can terminate the session. The detection of the
+ interrupted network connection can be done by several means, for
+ instance, feedback of the operating system or a connection timeout.
+ The definition of this detection mechanism is out of the scope of
+ this memo.
+
+
+
+
+
+
+
+Stiemerling, et al. Experimental [Page 39]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+8. Policy Rule Control Message Processing
+
+ For policy rule control and monitoring, the agent can send the PRR,
+ PER, PEA, PLC, PRS, and PRL requests. The middlebox then sends a
+ single reply message per request message back to the agent.
+ Additionally, the middlebox may send unsolicited ARE notifications at
+ any time.
+
+ The transaction semantics of policy rule control messages is
+ explained in detail in [RFC3989], Section 2.3.
+
+ For examples about protocol operation, see Section 4 of [RFC3989].
+
+8.1. Policy Rule State Machine
+
+ Policy rules are established by successful PRR, PEA, or PER
+ transactions. Each time a policy rule is created, an unused policy
+ rule identifier (PID) is assigned to the new policy rule. For each
+ policy rule identifier, a state machine exists at the middlebox. The
+ state machine is illustrated by the figure below.
+
+ PRR/PRR +---------------+
+ +----+ +-----------------+ PID UNUSED |<-+
+ | | | +---------------+ |
+ | v v PLC(lt=0)/ ^ | |
+ | +-------------+ PRD | | PER/PER | ARE(lt=0)
+ | | RESERVED +------------+ | | PLC(lt=0)/
+ | +-+----+------+ ARE(lt=0) v | PRD
+ | | | +---------------+ |
+ +----+ +---------------->| ENABLED +--+
+ PLC(lt>0)/ PEA/PER +-+-------------+
+ PLC | ^
+ +-----------+
+ lt = lifetime PLC(lt>0)/PLC
+
+
+ Figure 42: Policy rule state machine
+
+ The figure illustrates all possible state transitions of a PID and
+ its associated policy. Successful configuration request transactions
+ (PER, PRR, PEA, PLC) are denoted by a descriptor of the request
+ message, a '/' symbol, and a descriptor of the reply message. Failed
+ configuration request transactions are not displayed, because they do
+ not change the PID state. Notification transactions are denoted just
+ by the a notification descriptor. For example, a successful PRR
+ request transaction is denoted by 'PRR/PRR', and an ARE notification
+
+
+
+
+
+Stiemerling, et al. Experimental [Page 40]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+ is denoted by 'ARE'. For PLC request transactions, the descriptor
+ for the request message is extended by an indication of the value of
+ the lifetime parameter contained in the message.
+
+ A successful PRR transaction (PRR/PRR) picks a PID in state UNUSED
+ and changes the state to RESERVED. A successful PER transitions
+ picks a PID in state UNUSED and changes the state to ENABLED. A PID
+ in state RESERVED is changed to ENABLED by a successful PEA
+ transaction. In state RESERVED or UNUSED, a successful PLC
+ transaction with a lifetime parameter greater than zero does not
+ change the PID's state. A successful PLC transaction with a lifetime
+ parameter equal to zero changes the state of a PID from RESERVED to
+ UNUSED or from ENABLED to UNUSED.
+
+ A failed request transaction does not change state at the middlebox.
+
+ An ARE notification transaction with the lifetime attribute set to
+ zero has the same effect as a successful PLC transaction with a
+ lifetime parameter equal to zero.
+
+8.2. Processing PRR Requests
+
+ Processing PRR requests is much simpler on pure firewalls than on
+ middleboxes with NAT functions. Therefore, this section has three
+ sub-sections: The first one describes initial checks that are
+ performed in any case. The second sub-section describes processing
+ of PRR requests on pure firewalls, and the third one describes
+ processing on all devices with NAT functions.
+
+8.2.1. Initial Checks
+
+ When a middlebox receives a PRR request message, it first checks if
+ the authenticated agent is authorized for requesting reservations.
+ If not, it returns a negative reply message of type 'agent not
+ authorized for this transaction' (0x0341).
+
+ If the request contains the optional group identifier, then the
+ middlebox checks if the group already exists. If not, the middlebox
+ returns a negative reply message of type 'specified policy rule group
+ does not exist' (0x0344).
+
+ If the request contains the optional group identifier, then the
+ middlebox checks if the authenticated agent is authorized for adding
+ members to this group. If not, the middlebox returns a negative
+ reply message of type 'not authorized for accessing specified group'
+ (0x0346).
+
+
+
+
+
+Stiemerling, et al. Experimental [Page 41]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+ The middlebox may then check the PRR parameter set. A negative reply
+ of type 'IP version mismatch' (0x034F) is returned if the IPi field
+ does not match the inside IP version of the address at the middlebox.
+ A negative reply of type 'IP version mismatch' (0x034F) is returned
+ if the IPo field does not match the outside IP version of the address
+ at the middlebox. The requested transport protocol type is checked,
+ and a negative reply of type 'protocol type not supported' (0x0354)
+ is returned if it is not supported. The middlebox may return a
+ negative reply of type 'requested address space not available'
+ (0x0347) if the requested address space is completely blocked or not
+ supported by the middlebox in any way; for example, if a UDP port
+ number is requested and all UDP packets are blocked by a middlebox
+ acting as firewall.
+
+ The latter check at the middlebox is optional. If the check would
+ fail and is not performed at this transaction, then two superfluous
+ transactions will follow. First, the agent will send a request
+ message for a corresponding PER transaction and will receive a
+ negative reply on this. Second, either the agent will send a
+ corresponding PLC request message with lifetime set to zero in order
+ to delete the reservation, or the reservation will time out and the
+ middlebox will send an ARE notification message with the lifetime
+ attribute set to zero. Both transactions can be avoided if the
+ middlebox initially performs this check.
+
+ A reason for avoiding this check might be its complexity. If the
+ check is passed, the same check will have to be performed again for a
+ subsequent corresponding PEA request. If processing two more
+ transactions is considered to consume less resources than performing
+ the check twice, it might be desirable not to perform it during the
+ PRR transaction.
+
+ After checking the PRR parameter set, the middlebox chooses a
+ lifetime value for the new policy rule to be created, which is
+ greater than or equal to zero and less than or equal to the minimum
+ of the requested value and the maximum lifetime specified by the
+ middlebox capabilities attribute at session setup. Formally, the
+ lifetime is chosen such that
+
+ 0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
+
+ holds, where 'lt_granted' is the actual lifetime chosen by the
+ middlebox, 'lt_requested' is the lifetime requested by the agent, and
+ 'lt_maximum' is the maximum lifetime specified during capability
+ exchange at session setup.
+
+
+
+
+
+
+Stiemerling, et al. Experimental [Page 42]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+ If there are further sessions in state OPEN with authenticated agents
+ authorized to access the policy rule, then to each of these agents a
+ corresponding ARE notification with lifetime set to lt_granted is
+ sent.
+
+ If the chosen lifetime is zero, the middlebox sends a negative reply
+ of type 'middlebox configuration failed' (0x034A) to the agent.
+
+
+8.2.2. Processing on Pure Firewalls
+
+ If the middlebox is configured as a pure firewall, then it accepts
+ the request after the initial checks. It establishes a new policy
+ reserve rule and assigns to it a policy rule identifier in state
+ RESERVED. It generates a positive PRR reply and sets the attributes
+ as specified below. No configuration of the firewall function is
+ required.
+
+ The identifier chosen for the new policy rule is reported in the
+ policy rule identifier attribute of the PRR reply.
+
+ If a group identifier attribute is contained in the PRR request, then
+ the middlebox adds the new policy rule to the members of this group.
+ If the PRR request does not contain a group identifier attribute,
+ then the middlebox creates a new group with the new policy rule as
+ the only member. In any case, the middlebox reports the group of
+ which the new policy rule is a member in the group identifier
+ attribute of the PRR reply.
+
+ The chosen lifetime is reported in the lifetime attribute of the PRR
+ reply.
+
+ In the address tuple (outside) attribute of the PRR reply, the first
+ parameter field is set to 'protocols only' (0x1). Consequently, the
+ attribute has a length of 32 bits. The IP version parameter field is
+ set according to the IPo parameter field in the PRR parameter set
+ attribute of the PRR request message. The prefix length parameter
+ field is set to 0x00, and the transport protocol parameter field in
+ the address tuple (outside) attribute of the PRR reply is set
+ identically to the transport protocol attribute in the PRR parameter
+ set attribute of the PRR request message. The location parameter
+ field is set to 'outside' (0x02).
+
+
+
+
+
+
+
+
+
+Stiemerling, et al. Experimental [Page 43]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+8.2.3. Processing on Network Address Translators
+
+ If the middlebox is configured as a Network Address Translator (NAT),
+ then it tries to reserve a NAT binding.
+
+ The middlebox first checks the PRR parameter set further if the NM
+ (NAT mode) parameter matches its configuration. A negative reply of
+ type 'NAT mode not supported' (0x034E) is returned by the middlebox
+ if the configuration is not matched.
+
+ The following actions are performed, depending on the middlebox NAT
+ type:
+
+ - traditional NAT
+ A NAT binding at the outside (A2) with the requested transport
+ protocol, external IP version, port range, and port parity is
+ reserved.
+
+ - twice NAT
+ A NAT binding at the outside (A2) with the requested transport
+ protocol, external IP version, port range, and port parity is
+ reserved. Furthermore, the middlebox reserves an inside (A1) NAT
+ binding with the requested transport protocol, internal IP
+ version, port range, and port parity.
+
+ The identifier chosen for the new policy rule is reported in the
+ policy rule identifier attribute of the PRR reply.
+
+ After the checks are successfully performed, the middlebox
+ establishes a new policy reserve rule, with the requested PRR
+ parameter set, and assigns to it a policy rule identifier in state
+ RESERVED. It generates a positive PRR reply and sets the attributes
+ as specified below.
+
+ If a group identifier attribute is contained in the PRR request, then
+ the middlebox adds the new policy rule to the members of this group.
+ If the PRR request does not contain a group identifier attribute,
+ then the middlebox creates a new group with the new policy rule as
+ the only member. In any case, the middlebox reports the group of
+ which the new policy rule is a member in the group identifier
+ attribute of the PRR reply.
+
+ The chosen lifetime is reported in the lifetime attribute of the PRR
+ reply.
+
+ In the address tuple (outside) attribute of the PRR reply, the first
+ parameter field is set to 'full addresses' (0x0). The location
+ parameter field is set to 'outside' (0x02). The IP version parameter
+
+
+
+Stiemerling, et al. Experimental [Page 44]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+ field is set according to the IPo parameter field in the PRR
+ parameter set attribute of the PRR request message. For IPv4
+ addresses, the prefix length field is set to 0x20 to indicate a full
+ address, and the reserved outside IPv4 address is set in the address
+ field. For IPv6 addresses, the prefix length field is set to 0x80 to
+ indicate a full address, and the reserved outside IPv6 address is set
+ in the address field. The transport protocol parameter field in the
+ address tuple (outside) attribute of the PRR reply is set identically
+ to the transport protocol attribute in the PRR parameter set
+ attribute of the PRR request message. The reserved outside base port
+ number (i.e., the lowest port number of the allocated range) is
+ stored in the port number parameter field, and the allocated port
+ range is stored in the port range parameter field.
+
+ If the NM (NAT mode) parameter in the PRR parameter set attribute of
+ the PRR request message has the value 'traditional', then the PRR
+ reply message does not contain an address tuple (inside) attribute.
+ If otherwise (it has the value 'twice'), then the PRR reply message
+ contains an address tuple (inside) attribute. In the address tuple
+ (inside) attribute of the PRR reply, the first parameter field is set
+ to 'full addresses' (0x0). The location parameter field is set to
+ 'inside' (0x01). The IP version parameter field is set according to
+ the IPi parameter field in the PRR parameter set attribute of the PRR
+ request message. For IPv4 addresses, the prefix length field is set
+ to 0x20 to indicate a full address, and the reserved inside IPv4
+ address is set in the address field. For IPv6 addresses, the prefix
+ length field is set to 0x80 to indicate a full address, and the
+ reserved inside IPv6 address is set in the address field. The
+ transport protocol parameter field in the address tuple (inside)
+ attribute of the PRR reply is set identically to the transport
+ protocol attribute in the PRR parameter set attribute of the PRR
+ request message. The reserved inside base port number (i.e., the
+ lowest port number of the allocated range) is stored in the port
+ number parameter field, and the allocated port range is stored in the
+ port range parameter field.
+
+8.3. Processing PER Requests
+
+ Processing PER requests is much simpler on pure firewalls than on
+ middleboxes with NAT functions. Therefore, this section has three
+ sub-sections: The first one describes initial checks that are
+ performed in any case. The second sub-section describes processing
+ of PER requests on pure firewalls, and the third one describes
+ processing on all devices with NAT functions.
+
+
+
+
+
+
+
+Stiemerling, et al. Experimental [Page 45]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+8.3.1. Initial Checks
+
+ When a middlebox receives a PER request message, it first checks if
+ the authenticated agent is authorized for requesting middlebox
+ configurations for enabling communication. If not, it returns a
+ negative reply message of type 'agent not authorized for this
+ transaction' (0x0341).
+
+ If the request contains the optional group identifier, then the
+ middlebox checks if the group already exists. If not, the middlebox
+ returns a negative reply message of type 'specified policy rule group
+ does not exist' (0x0344).
+
+ If the request contains the optional group identifier, then the
+ middlebox checks if the authenticated agent is authorized for adding
+ members to this group. If not, the middlebox returns a negative
+ reply message of type 'not authorized for accessing specified group'
+ (0x0346).
+
+ Then the middlebox checks the contained address tuple attributes.
+
+ If the first one does not have the location parameter field set to
+ 'internal' (0x00), or if the second one does not have the location
+ parameter field set to 'external' (0x03), then the middlebox returns
+ a negative reply message of type 'inconsistent request' (0x034B).
+
+ If the transport protocol parameter field does not have the same
+ value in both address tuple attributes, then the middlebox returns a
+ negative reply message of type 'inconsistent request' (0x034B).
+
+ If both address tuple attributes contain a port range parameter
+ field, if both port range parameter fields have values not equal to
+ 0xFFFF, and if the values of both port range parameter fields are
+ different, then the middlebox returns a negative reply message of
+ type 'inconsistent request' (0x034B).
+
+ Then the agent checks if wildcarding is requested and if the
+ requested wildcarding is supported by the middlebox. Wildcarding
+ support may be different for internal address tuples and external
+ address tuples. The following parameter fields of the address tuple
+ attribute can indicate wildcarding:
+
+ - the first parameter field
+ If it is set to 'protocols only' (0x1), then IP addresses and
+ port numbers are completely wildcarded.
+
+
+
+
+
+
+Stiemerling, et al. Experimental [Page 46]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+ - the transport protocol field
+ If it is set to 0x00, then the transport protocol is completely
+ wildcarded. Please note that a completely wildcarded transport
+ protocol might still support only a limited set of transport
+ protocols according to the capabilities of the middlebox. For
+ example, a typical NAT implementation may apply transport
+ wildcarding to UDP and TCP transport only. Wildcarding the
+ transport protocol implies wildcarding of port numbers. If this
+ field is set to 0x00, then the values of the port number field
+ and the port range field are irrelevant.
+
+ - the prefix length field
+ If the IP version number field indicates IPv4 and the value of
+ this field is less than 0x20, then IP addresses are wildcarding
+ according to this prefix length. If the IP version number field
+ indicates IPv6 and the value of this field is less than 0x80,
+ then IP addresses are wildcarding according to this prefix
+ length. If the first parameter field is set to 'protocols only'
+ (0x1), then the value of the prefix length field is irrelevant.
+
+ - the port number field
+ If it is set to zero, then port numbers are completely
+ wildcarded. In this case, the value of the port range field is
+ irrelevant.
+
+ If any of these kinds of wildcarding is used, and if this is in
+ conflict with wildcarding support for internal or external addresses
+ of the middlebox, then the middlebox returns a negative reply message
+ of type 'requested wildcarding not supported' (0x034C).
+
+ Please note that the port range field cannot be used for wildcarding.
+ If it is set to a value greater than one, then middlebox
+ configuration is requested for all port numbers in the interval
+ starting with the specified port number and containing as many
+ consecutive port numbers as specified by the parameter.
+
+ If the direction parameter field in the PER parameter set attribute
+ has the value 'bi-directional', then only transport protocol
+ wildcarding is allowed. If any other kind of wildcarding is
+ specified in one or both of the IP address tuple attributes, then the
+ middlebox returns a negative reply message of type 'inconsistent
+ request' (0x034B).
+
+ If the PER request conflicts with any policy disable rule (see
+ Section 8.8.1), then the middlebox returns a negative reply message
+ of type 'conflict with existing rule' (0x0350).
+
+
+
+
+
+Stiemerling, et al. Experimental [Page 47]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+ After checking the address tuple attributes, the middlebox chooses a
+ lifetime value for the new policy rule to be created, which is
+ greater than or equal to zero and less than or equal to the minimum
+ of the requested value and the maximum lifetime specified by the
+ middlebox capabilities attribute at session setup. Formally, the
+ lifetime is chosen such that
+
+ 0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
+
+ holds, where 'lt_granted' is the actual lifetime chosen by the
+ middlebox, 'lt_requested' is the lifetime requested by the agent, and
+ 'lt_maximum' is the maximum lifetime specified during capability
+ exchange at session setup.
+
+ If there are further sessions in state OPEN with authenticated agents
+ authorized to access the policy rule, then to each of these agents a
+ corresponding ARE notification with lifetime set to lt_granted is
+ sent.
+
+ If the chosen lifetime is zero, the middlebox sends a negative reply
+ of type 'middlebox configuration failed' (0x034A) to the agent.
+
+8.3.2. Processing on Pure Firewalls
+
+ If the middlebox is acting as a pure firewall, then it tries to
+ configure the requested pinhole. The firewall configuration ignores
+ the port parity parameter field in the PER parameter set attribute,
+ but it considers the direction parameter field in this attribute.
+ The pinhole is configured such that communication between the
+ specified internal and external address tuples is enabled in the
+ specified direction and covering the specified wildcarding. If the
+ configuration fails (for example, because the pinhole would conflict
+ with high-level firewall policies), then the middlebox returns a
+ negative reply message of type 'middlebox configuration failed'
+ (0x034A).
+
+ If the configuration was successful, the middlebox establishes a new
+ policy enable rule and assigns to it a policy rule identifier in
+ state ENABLED. It generates a positive PER reply and sets the
+ attributes as specified below.
+
+ The identifier chosen for the new policy rule is reported in the
+ policy rule identifier attribute of the PER reply.
+
+ If a group identifier attribute is contained in the PER request, then
+ the middlebox adds the new policy rule to the members of this group.
+ If the PRR request does not contain a group identifier attribute,
+ then the middlebox creates a new group with the new policy rule as
+
+
+
+Stiemerling, et al. Experimental [Page 48]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+ the only member. In any case, the middlebox reports the group of
+ which the new policy rule is a member in the group identifier
+ attribute of the PER reply.
+
+ The chosen lifetime is reported in the lifetime attribute of the PER
+ reply.
+
+ The address tuple (internal) attribute of the PER request is reported
+ as address tuple (outside) attribute of the PER reply. The address
+ tuple (external) attribute of the PER request is reported as address
+ tuple (inside) attribute of the PER reply.
+
+8.3.3. Processing on Network Address Translators
+
+ If the middlebox is configured as a NAT, then it tries to configure
+ the requested NAT binding. The actions taken by the NAT are quite
+ similar to the actions of the Policy Reserve Rule (PRR) request, but
+ in the PER request a NAT binding is enabled.
+
+ The following actions are performed, depending on the middlebox NAT
+ type:
+
+ - traditional NAT
+ A NAT binding is established between the internal and external
+ address tuple with the requested transport protocol, port range,
+ direction, and port parity. The outside address tuple is
+ created.
+
+ - twice NAT
+ A NAT binding is established between the internal and external
+ address tuple with the requested transport protocol, port range,
+ and port parity. But two address tuples are created: an outside
+ address tuple and an inside address tuple.
+
+ Should the configuration fail in either NAT case, a negative reply
+ 'middlebox configuration failed' (0x034A) is returned.
+
+ If the configuration was successful, the middlebox establishes a new
+ policy enable rule and assigns to it a policy rule identifier in
+ state ENABLED. It generates a positive PER reply and sets the
+ attributes as specified below.
+
+ The identifier chosen for the new policy rule is reported in the
+ policy rule identifier attribute of the PER reply.
+
+ If a group identifier attribute is contained in the PER request, then
+ the middlebox adds the new policy rule to the members of this group.
+ If the PRR request does not contain a group identifier attribute,
+
+
+
+Stiemerling, et al. Experimental [Page 49]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+ then the middlebox creates a new group with the new policy rule as
+ the only member. In any case, the middlebox reports the group of
+ which the new policy rule is a member in the group identifier
+ attribute of the PER reply.
+
+ The chosen lifetime is reported in the lifetime attribute of the PER
+ reply.
+
+ In the address tuple (outside) attribute of the PER reply, the first
+ parameter field is set to 'full addresses' (0x0). The location
+ parameter field is set to 'outside' (0x02). The IP version parameter
+ field is set according to the IP version parameter field in the PER
+ parameter set attribute of the PER request message. For IPv4
+ addresses, the prefix length field is set to 0x20 to indicate a full
+ address, and the reserved outside IPv4 address is set in the address
+ field. For IPv6 addresses, the prefix length field is set to 0x80 to
+ indicate a full address, and the reserved outside IPv6 address is set
+ in the address field. The transport protocol parameter field in the
+ address tuple (outside) attribute of the PER reply is set identically
+ to the transport protocol attribute in the PER parameter set
+ attribute of the PER request message. The reserved outside base port
+ number (i.e., the lowest port number of the allocated range) is
+ stored in the port number parameter field, and the allocated port
+ range is stored in the port range parameter field.
+
+ The address tuple (inside) is only returned if the middlebox is a
+ twice NAT; otherwise, it is omitted. In the address tuple (inside)
+ attribute of the PER reply, the first parameter field is set to 'full
+ addresses' (0x0). The location parameter field is set to 'inside'
+ (0x01). The IP version parameter field is set according to the IP
+ version parameter field in the PER parameter set attribute of the PER
+ request message. For IPv4 addresses, the prefix length field is set
+ to 0x20 to indicate a full address, and the reserved inside IPv4
+ address is set in the address field. For IPv6 addresses, the prefix
+ length field is set to 0x80 to indicate a full address, and the
+ reserved inside IPv6 address is set in the address field. The
+ transport protocol parameter field in the address tuple (inside)
+ attribute of the PER reply is set identically to the transport
+ protocol attribute in the PER parameter set attribute of the PER
+ request message. The reserved inside base port number (i.e., the
+ lowest port number of the allocated range) is stored in the port
+ number parameter field, and the allocated port range is stored in the
+ port range parameter field.
+
+
+
+
+
+
+
+
+Stiemerling, et al. Experimental [Page 50]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+8.3.4. Processing on Combined Firewalls and NATs
+
+ Middleboxes that are combinations of firewalls and NATs are
+ configured in such a way that first the NAT bindings are configured
+ and afterwards the firewall pinholes. This sequence is needed since
+ the firewall rules must be configured according to the outside
+ address tuples and for twice NATs the inside address tuples as well.
+ This aspect of middlebox operation may be irrelevant to SIMCO, since
+ some NATs already do firewall configuration on their own.
+
+8.4. Processing PEA Requests
+
+ Processing PEA requests is much simpler on pure firewalls than on
+ middleboxes with NAT functions. Therefore, this section has three
+ sub-sections: The first one describes initial checks that are
+ performed in any case. The second sub-section describes processing
+ of PEA requests on pure firewalls, and the third one describes
+ processing on all devices with NAT functions.
+
+8.4.1. Initial Checks
+
+ When a middlebox receives a PEA request message, it first checks if
+ the authenticated agent is authorized for requesting middlebox
+ configurations for enabling communication. If not, it returns a
+ negative reply message of type 'agent not authorized for this
+ transaction' (0x0341).
+
+ Then the middlebox checks the policy rule identifier attribute
+ contained in the PEA message. If no policy rule with this identifier
+ exists, then the middlebox returns a negative reply message of type
+ 'specified policy rule does not exist' (0x0343). If there exists a
+ policy with this identifier and if it is in a state other than
+ RESERVED, then the middlebox returns a negative reply message of type
+ 'inconsistent request' (0x034B).
+
+ If a policy rule with this identifier exists, but the authenticated
+ agent is not authorized for terminating this policy reserve rule,
+ then the middlebox returns a negative reply message of type 'agent
+ not authorized for accessing this policy' (0x0345).
+
+ Then the middlebox checks the contained address tuple attributes.
+
+ If the first one does not have the location parameter field set to
+ 'internal' (0x00) or if the second one does not have the location
+ parameter field set to 'external' (0x03), then the middlebox returns
+ a negative reply message of type 'inconsistent request' (0x034B).
+
+
+
+
+
+Stiemerling, et al. Experimental [Page 51]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+ If the transport protocol parameter field does not have the same
+ value in both address tuple attributes, then the middlebox returns a
+ negative reply message of type 'inconsistent request' (0x034B).
+
+ If both address tuple attributes contain a port range parameter
+ field, if both port range parameter fields have values not equal to
+ 0xFFFF, and if the values of both port range parameter fields are
+ different, then the middlebox returns a negative reply message of
+ type 'inconsistent request' (0x034B).
+
+ Then the agent checks if wildcarding is requested and if the
+ requested wildcarding is supported by the middlebox. Wildcarding
+ support may be different for internal address tuples and external
+ address tuples. The following parameter fields of the address tuple
+ attribute can indicate wildcarding:
+
+ - the first parameter field
+ If it is set to 'protocols only' (0x1), then IP addresses and
+ port numbers are completely wildcarded.
+
+ - the transport protocol field
+ If it is set to 0x00, then IP the transport protocol is
+ completely wildcarded. Please note that a completely wildcarded
+ transport protocol might still support only a limited set of
+ transport protocols according to the capabilities of the
+ middlebox. For example, a typical NAT implementation may apply
+ transport wildcarding to UDP and TCP transport only.
+
+ - the prefix length field
+ If the IP version number field indicates IPv4 and the value of
+ this field is less than 0x20, then IP addresses are wildcarding
+ according to this prefix length. If the IP version number field
+ indicates IPv6 and the value of this field is less than 0x80,
+ then IP addresses are wildcarding according to this prefix
+ length. If the first parameter field is set to 'protocols only'
+ (0x1), then the value of the prefix length field is irrelevant.
+
+ - the port number field
+ If it is set to zero, then port numbers are completely
+ wildcarded.
+
+ - the port range field
+ If it is set to a value greater than one, then port numbers are
+ wildcarded within an interval starting with the specified port
+ number and containing as many consecutive port numbers as
+ specified by the parameter.
+
+
+
+
+
+Stiemerling, et al. Experimental [Page 52]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+ If any of these kinds of wildcarding is used, and if this is in
+ conflict with wildcarding support for internal or external addresses
+ of the middlebox, then the middlebox returns a negative reply message
+ of type 'requested wildcarding not supported' (0x034C).
+
+ If the PEA request conflicts with any policy disable rule (see
+ Section 8.8.1), then the middlebox returns a negative reply message
+ of type 'conflict with existing rule' (0x0350).
+
+ After checking the address tuple attributes, the middlebox chooses a
+ lifetime value for the new policy enable rule to be created, which is
+ greater than or equal to zero and less than or equal to the minimum
+ of the requested value and the maximum lifetime specified by the
+ middlebox capabilities attribute at session setup. Formally, the
+ lifetime is chosen such that
+
+ 0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
+
+ holds, where 'lt_granted' is the actual lifetime chosen by the
+ middlebox, 'lt_requested' is the lifetime requested by the agent, and
+ 'lt_maximum' is the maximum lifetime specified during capability
+ exchange at session setup.
+
+ If there are further sessions in state OPEN with authenticated agents
+ authorized to access the policy rule, then to each of these agents a
+ corresponding ARE notification with lifetime set to lt_granted is
+ sent.
+
+ If the chosen lifetime is zero, the middlebox sends a negative reply
+ of type 'middlebox configuration failed' (0x034A) to the agent.
+
+8.4.2. Processing on Pure Firewalls
+
+ If the middlebox is configured as a pure firewall, then it tries to
+ configure the requested pinhole. The firewall configuration ignores
+ the port parity parameter field in the PER parameter set attribute,
+ but it considers the direction parameter field in this attribute.
+ The pinhole is configured such that communication between the
+ specified internal and external address tuples is enabled in the
+ specified direction and covering the specified wildcarding. If the
+ configuration fails, then the middlebox returns a negative reply
+ message of type 'middlebox configuration failed' (0x034A).
+
+ If the configuration was successful, the middlebox replaces the
+ policy reserve rule referenced by the policy rule identifier
+ attribute in the PEA request message with a new policy enable rule.
+ The policy enable rule re-uses the policy rule identifier of the
+ replaced policy reserve rule. The state of the policy rule
+
+
+
+Stiemerling, et al. Experimental [Page 53]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+ identifier changes from RESERVED to ENABLED. The policy reserve rule
+ is a member of the same group as the replaced policy reserve rule
+ was.
+
+ Then the middlebox generates a positive PER reply and sets the
+ attributes as specified below.
+
+ The identifier chosen for the new policy rule is reported in the
+ policy rule identifier attribute of the PER reply.
+
+ The group identifier is reported in the group identifier attribute of
+ the PER reply.
+
+ The chosen lifetime is reported in the lifetime attribute of the PER
+ reply.
+
+ The address tuple (internal) attribute of the PER request is reported
+ as the address tuple (outside) attribute of the PER reply. The
+ address tuple (external) attribute of the PER request is reported as
+ the address tuple (inside) attribute of the PER reply.
+
+8.4.3. Processing on Network Address Translators
+
+ If the middlebox is configured as a NAT, then it tries to configure
+ the requested NAT binding, i.e., enabling the already reserved
+ binding. The already reserved NAT binding from the PRR request is
+ now enabled in the middlebox.
+
+ If the enable configuration was successful, the middlebox replaces
+ the policy reserve rule referenced by the policy rule identifier
+ attribute in the PEA request message with a new policy enable rule.
+ The policy enable rule re-uses the policy rule identifier of the
+ replaced policy reserve rule. The state of the policy rule
+ identifier changes from RESERVED to ENABLED. The policy reserve rule
+ is a member of the same group as the replaced policy reserve rule
+ was.
+
+ Then the middlebox generates a positive PER reply and sets the
+ attributes as specified below.
+
+ The reserved outside address tuple is reported as the address tuple
+ (outside) attribute of the PER reply. The reserved inside address
+ tuple is reported as the address tuple (inside) attribute of the PER
+ reply. Both reserved outside and inside address tuples are taken
+ from the reserve policy rule generated during the PRR transaction.
+
+
+
+
+
+
+Stiemerling, et al. Experimental [Page 54]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+8.5. Processing PLC Requests
+
+ When a middlebox receives a PLC request message, it first checks if
+ the authenticated agent is authorized for requesting policy rule
+ lifetime changes. If not, it returns a negative reply message of
+ type 'agent not authorized for this transaction' (0x0341).
+
+ Then the middlebox checks the policy rule identifier attribute
+ contained in the PLC message. If no policy rule with this identifier
+ exists, then the middlebox returns a negative reply message of type
+ 'specified policy rule does not exist' (0x0343).
+
+ If a policy rule with this identifier exists, but the authenticated
+ agent is not authorized for changing the lifetime of this policy
+ rule, then the middlebox returns a negative reply message of type
+ 'agent not authorized for accessing this policy' (0x0345).
+
+ Then the middlebox chooses a lifetime value for the new policy rule,
+ which is greater than zero and less than or equal to the minimum of
+ the requested value and the maximum lifetime specified by the
+ middlebox capabilities attribute at session setup. Formally, the
+ lifetime is chosen such that
+
+ 0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
+
+ holds, where 'lt_granted' is the actual lifetime chosen by the
+ middlebox, 'lt_requested' is the lifetime requested by the agent, and
+ 'lt_maximum' is the maximum lifetime specified during capability
+ exchange at session setup. This procedure implies that the chosen
+ lifetime is zero if the requested lifetime is zero.
+
+ If the chosen lifetime is greater than zero, the middlebox changes
+ the lifetime of the policy rule to the chosen value and generates a
+ PLC reply message. The chosen lifetime is reported in the lifetime
+ attribute of the message.
+
+ If otherwise (the chosen lifetime is zero), then the middlebox
+ terminates the policy rule and changes the PID state from ENABLED or
+ RESERVED, respectively, to UNUSED.
+
+ The middlebox generates a PRD reply message and sends it to the
+ requesting agent. If there are further sessions in state OPEN with
+ authenticated agents authorized to access the policy rule, then to
+ each of these agents a corresponding ARE notification with lifetime
+ set to zero is sent.
+
+
+
+
+
+
+Stiemerling, et al. Experimental [Page 55]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+8.6. Processing PRS Requests
+
+ When a middlebox receives a PRS request message, it first checks if
+ the authenticated agent is authorized for receiving policy status
+ information. If not, it returns a negative reply message of type
+ 'agent not authorized for this transaction' (0x0341).
+
+ Then the middlebox checks the policy rule identifier attribute
+ contained in the PRS message. If no policy rule with this identifier
+ exists in state RESERVED or ENABLED, then the middlebox returns a
+ negative reply message of type 'specified policy rule does not exist'
+ (0x0343).
+
+ If a policy rule with this identifier exists, but the authenticated
+ agent is not authorized to receive status information for this policy
+ rule, then the middlebox returns a negative reply message of type
+ 'agent not authorized for accessing this policy' (0x0345).
+
+ If the checks described above are passed, the middlebox accepts the
+ requests and generates a reply. If the policy rule for which status
+ information is requested is in state RESERVED, then a PRS reply is
+ generated and sent to the agent. If otherwise (the policy rule is in
+ state ENABLED), then a PES reply is generated and sent to the agent.
+ For policy disable rules, a PDS reply is generated and sent to the
+ agent.
+
+ In both message formats, the lifetime attribute reports the current
+ remaining lifetime of the policy rule, and the owner attribute
+ reports the owner of the policy rule for which status information is
+ requested.
+
+ The PRS reply message format is identical to the PRR reply message
+ format except for an appended owner attribute. In the PRS reply, the
+ attributes that are common with the PRR reply (except for the
+ lifetime attribute) have exactly the same values as the corresponding
+ attributes of the PRR reply that was sent as part of the PRR
+ transaction that established the policy reserve rule.
+
+ In the PES reply message, the PER parameter set attribute, the
+ address tuple (internal) attribute, and the address tuple (external)
+ attribute have exactly the same values as the corresponding
+ attributes of the PER or PEA request that were sent as part of the
+ corresponding transaction that established the policy enable rule.
+
+
+
+
+
+
+
+
+Stiemerling, et al. Experimental [Page 56]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+ In the PES reply message, the policy rule identifier attribute, the
+ group identifier attribute, the address tuple (inside) attribute, and
+ the address tuple (outside) attribute have exactly the same values as
+ the corresponding attributes of the PER reply that was sent as part
+ of the PER or PEA transaction that established the policy enable
+ rule.
+
+ In the PDS reply message, the policy rule identifier attribute, the
+ address tuple (internal) attribute, and the address tuple (external)
+ attribute have exactly the same values as the corresponding
+ attributes of the PDR request message.
+
+ This transaction does not change the state of any policy rule.
+
+8.7. Processing PRL Requests
+
+ When a middlebox receives a PRL request message, it first checks if
+ the authenticated agent is authorized for receiving policy
+ information. If not, it returns a negative reply message of type
+ 'agent not authorized for this transaction' (0x0341).
+
+ Then the middlebox generates a PRL reply message. For each policy
+ rule at the middlebox in state RESERVED or ENABLED that the
+ authenticated agent can access, a policy rule identifier attribute is
+ generated and added to the PRL reply message before the message is
+ sent to the agent. A negative reply message of type 'reply message
+ too big' (0x0313) is generated if the number of policy rule
+ attributes to be returned exceeds the maximum transport unit size of
+ the underlying network connection or the maximum length of a SIMCO
+ message. The total size of a SIMCO message is limited to 65,536
+ octets in total (see Section 4.2 for the SIMCO header).
+
+ This transaction does not change the state of any policy rule.
+
+8.8. Processing PDR requests
+
+ Processing of PDR requests is structured into five sub-sections. The
+ first one describes the general extension of the MIDCOM protocol
+ semantics by PDR. The second sub-section describes the initial
+ checks that are performed in any case. The third sub-section
+ describes the processing of PDR requests on pure firewalls. The
+ fourth one describes processing on devices with NATs, and the fifth
+ describes processing of devices with combined firewall and NAT
+ functions.
+
+
+
+
+
+
+
+Stiemerling, et al. Experimental [Page 57]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+8.8.1. Extending the MIDCOM semantics
+
+ The Policy Disable Rule (PDR) extends the MIDCOM protocol semantics
+ [RFC3989] by another policy rule type. The PDR is intended to be
+ used for dynamically blocking unwanted traffic, particularly in case
+ of an attack, for example, a distributed denial of service attack.
+
+ PDR requests follow the same ownership concept as all other
+ transactions do (see [RFC3989], Section 2.1.5). However, PDR
+ prioritization over PERs is independent of ownership. A PDR always
+ overrules a conflicting PER, even if the respective owners are
+ different. Typically, only a highly privileged agent will be allowed
+ to issue PDR requests.
+
+ A PDR rule and PER rule conflict with each other if their address
+ tuples overlap such that there exists at least one IP packet that
+ matches address tuple A0 of both rules in the internal network and
+ that matches address tuple A3 of both rules in the external network.
+ Note that the packet may be translated from the internal to external
+ network, or vice versa.
+
+ Let's assume, for instance, that a policy enable rule (PER) enables
+ all traffic from any external host using any UDP port to a certain
+ UDP port of a certain internal host:
+
+ PER A3={ any external IP address, UDP, any port }
+ PER A0={ internal IP address 10.1.8.3, UDP, port 12345 }
+
+ Then this conflicts with a policy disable rule (PDR) blocking all UDP
+ traffic from a potentially attacking host:
+
+ PDR A3={ external IP address 192.0.2.100, UDP, any port }
+ PDR A0={ any internal IP address, UDP, any port }
+
+ If a new PDR is established, then all conflicting PERS are terminated
+ immediately. A new PER can only be established if it does not
+ conflict with any already existing PDR.
+
+8.8.2. Initial Checks
+
+ When a middlebox receives a PDR request message, it first checks if
+ the authenticated agent is authorized for requesting middlebox
+ configurations for disabling communication. If not, it returns a
+ negative reply message of type 'agent not authorized for this
+ transaction' (0x0341).
+
+ Then the middlebox checks the contained address tuple attributes.
+
+
+
+
+Stiemerling, et al. Experimental [Page 58]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+ If the first one does not have the location parameter field set to
+ 'internal' (0x00), or if the second one does not have the location
+ parameter field set to 'external' (0x03), then the middlebox returns
+ a negative reply message of type 'inconsistent request' (0x034B).
+
+ If the transport protocol parameter field does not have the same
+ value in both address tuple attributes, then the middlebox returns a
+ negative reply message of type 'inconsistent request' (0x034B).
+
+ If both address tuple attributes contain a port range parameter
+ field, if both port range parameter fields have values not equal to
+ 0xFFFF, and if the values of both port range parameter fields are
+ different, then the middlebox returns a negative reply message of
+ type 'inconsistent request' (0x034B).
+
+ Then the agent checks if wildcarding is requested and if the
+ requested wildcarding is supported by the middlebox. Wildcarding
+ support may be different for internal address tuples and external
+ address tuples. The following parameter fields of the address tuple
+ attribute can indicate wildcarding:
+
+ - the first parameter field
+ If it is set to 'protocols only' (0x1), then IP addresses and
+ port numbers are completely wildcarded.
+
+ - the transport protocol field
+ If it is set to 0x00, then the transport protocol is completely
+ wildcarded. Please note that a completely wildcarded transport
+ protocol might still support only a limited set of transport
+ protocols according to the capabilities of the middlebox. For
+ example, a typical NAT implementation may apply transport
+ wildcarding to UDP and TCP transport only. Wildcarding the
+ transport protocol implies wildcarding of port numbers. If this
+ field is set to 0x00, then the values of the port number field
+ and the port range field are irrelevant.
+
+ - the prefix length field
+ If the IP version number field indicates IPv4 and the value of
+ this field is less than 0x20, then IP addresses are wildcarding
+ according to this prefix length. If the IP version number field
+ indicates IPv6 and the value of this field is less than 0x80,
+ then IP addresses are wildcarding according to this prefix
+ length. If the first parameter field is set to 'protocols only'
+ (0x1), then the value of the prefix length field is irrelevant.
+
+
+
+
+
+
+
+Stiemerling, et al. Experimental [Page 59]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+ - the port number field
+ If it is set to zero, then port numbers are completely
+ wildcarded. In this case, the value of the port range field is
+ irrelevant.
+
+ If any of these kinds of wildcarding is used, and if this is in
+ conflict with wildcarding support for internal or external addresses
+ of the middlebox, then the middlebox returns a negative reply message
+ of type 'requested wildcarding not supported' (0x034C).
+
+ Please note that the port range field cannot be used for wildcarding.
+ If it is set to a value greater than one, then middlebox
+ configuration is requested for all port numbers in the interval
+ starting with the specified port number and containing as many
+ consecutive port numbers as specified by the parameter.
+
+ The specified policy disable rule is activated, and the middlebox
+ will terminate any conflicting policy enable rule immediately.
+ Conflicts are defined in Section 8.8.1. Agents with open sessions
+ that have access to the policy rules to be terminated are notified
+ via the ARE notification.
+
+ The middlebox will reject all requests for new policy enable rules
+ that conflict with the just established PDR as long as the PDR is not
+ terminated. In such a case, a negative 'conflict with existing rule'
+ (0x0350) reply will be generated.
+
+ After checking the address tuple attributes, the middlebox chooses a
+ lifetime value for the new policy rule to be created, which is
+ greater than or equal to zero and less than or equal to the minimum
+ of the requested value and the maximum lifetime specified by the
+ middlebox capabilities attribute at session setup. Formally, the
+ lifetime is chosen such that
+
+ 0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
+
+ holds, where 'lt_granted' is the actual lifetime chosen by the
+ middlebox, 'lt_requested' is the lifetime requested by the agent, and
+ 'lt_maximum' is the maximum lifetime specified during capability
+ exchange at session setup.
+
+ If there are further sessions in state OPEN with authenticated agents
+ authorized to access the policy rule, then to each of these agents a
+ corresponding ARE notification with lifetime set to lt_granted is
+ sent.
+
+ If the chosen lifetime is zero, the middlebox sends a negative reply
+ of type 'middlebox configuration failed' (0x034A) to the agent.
+
+
+
+Stiemerling, et al. Experimental [Page 60]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+8.8.3. Processing on Pure Firewalls
+
+ If the middlebox is acting as a pure firewall, then it tries to
+ configure the requested disable rule, i.e., configuring a blocking
+ rule at the firewall. The disable rule is configured such that
+ communication between the specified internal and external address
+ tuples is blocked, covering the specified wildcarding. If the
+ configuration fails (for example, because the blocking rule would
+ conflict with high-level firewall policies), then the middlebox
+ returns a negative reply message of type 'middlebox configuration
+ failed' (0x034A).
+
+ If the configuration was successful, the middlebox establishes a new
+ policy disable rule and assigns to it a policy rule identifier in
+ state ENABLED. It generates a positive PDR reply and sets the
+ attributes as specified below.
+
+ The identifier chosen for the new policy rule is reported in the
+ policy rule identifier attribute of the PDR reply.
+
+ The chosen lifetime is reported in the lifetime attribute of the PDR
+ reply.
+
+8.8.4. Processing on Network Address Translators
+
+ If the middlebox is configured as a NAT, then it tries to block the
+ specified address tuple in the NAT. The mechanisms used for this
+ depend on the implementation and capabilities of the NAT.
+
+ Should the configuration fail in either NAT case, a negative reply
+ 'middlebox configuration failed' (0x034A) is returned.
+
+ If the configuration was successful, the middlebox establishes a new
+ policy disable rule and assigns to it a policy rule identifier in
+ state ENABLED. It generates a positive PDR reply and sets the
+ attributes as specified below.
+
+ The identifier chosen for the new policy rule is reported in the
+ policy rule identifier attribute of the PDR reply.
+
+ The chosen lifetime is reported in the lifetime attribute of the PDR
+ reply.
+
+
+
+
+
+
+
+
+
+Stiemerling, et al. Experimental [Page 61]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+8.8.5. Processing on Combined Firewalls and NATs
+
+ Middleboxes that are combinations of firewall and NAT are configured
+ in such a way that first the firewall is configured with the blocking
+ rule and afterwards the NAT is configured to block the address tuple.
+ This aspect of middlebox operation may be irrelevant to SIMCO, since
+ some NATs already do firewall configuration on their own.
+
+8.9 Generating ARE Notifications
+
+ At any time, the middlebox may terminate a policy rule by deleting
+ the configuration of the rule and by changing the corresponding PID
+ state from ENABLED or from RESERVED, respectively, to UNUSED.
+
+ For each session in state OPEN with authenticated agents authorized
+ to access the policy rule, the middlebox generates a corresponding
+ ARE notification with the lifetime attribute set to zero and sends it
+ to the respective agent. The identifier of the terminated policy
+ rule is reported in the policy rule identifier attribute of the ARE
+ notification.
+
+ After sending the notification, the middlebox will consider the
+ policy rule non-existent. It will not process any further
+ transaction on this policy rule.
+
+ In the case of PRR, PER, PEA, and PLC (reserving and enabling policy
+ rules and changes of the lifetime), the middlebox generates an ARE
+ notification after processing the request. This ARE notification is
+ generated for each session in state OPEN with authenticated agents
+ (other than the requesting agent) who are authorized to access the
+ policy rule. Through this ARE notification all other agents are kept
+ synchronized with the latest state of the policy rules.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stiemerling, et al. Experimental [Page 62]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+9. Security Considerations
+
+9.1. Possible Threats to SIMCO
+
+ Middleboxes, such as firewalls and NATs, are usually operated for
+ improving the network security and for extending the IP address space
+ (note that stand-alone NATs are not considered to improve security;
+ see [RFC2663]). The configuration of middleboxes from an external
+ entity looks quite counterproductive on the first glimpse, since an
+ attacker using this can possibly configure the middlebox in such way
+ that no filtering is applied anymore or that NAT bindings are
+ configured for malicious use. So the middlebox is not performing the
+ intended function anymore. Possible threats to SIMCO are:
+
+ - Man-in-the-middle attack
+ A malicious host intercepts messages exchanged between then SIMCO
+ agent and middlebox and can change the content of the messages on
+ the fly. This man-in-the-middle attack would result, from the
+ agent's view, in a proper middlebox configuration, but the
+ middlebox would not be configured accordingly. The man in the
+ middlebox could open pinholes that compromise the protected
+ network's security.
+
+ - Changing content
+ The message content could be changed in such a way that the
+ requested policy rule configuration is not configured in the
+ middlebox, but that any other unwanted configuration could be.
+ That way, an attacker can open the firewall for his own traffic.
+
+ - Replaying
+ Already sent messages could be re-sent in order to configure the
+ middlebox in such a way that hosts could configure policy rules
+ without the permission of an application-level gateway or system
+ administrator.
+
+ - Wiretapping
+ An already configured policy rule could be re-used by other hosts
+ if the policy rule is configured with too broad a wildcarding
+ (see below). These hosts could send unwanted traffic.
+
+9.2. Securing SIMCO with IPsec
+
+ The previous subsection identifies several issues on security for
+ SIMCO. SIMCO can rely on IPsec mechanisms, as defined in [RFC4302]
+ and [RFC4303], for ensuring proper operations.
+
+
+
+
+
+
+Stiemerling, et al. Experimental [Page 63]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+ When SIMCO relies on IPsec, it uses IPsec in transport mode with an
+ authentication header (AH) [RFC4302] and an encapsulating security
+ payload (ESP) [RFC4303], so that IP traffic between SIMCO agent and
+ middlebox is protected. The authentication header is used for
+ protecting the whole packet against content changes and replaying.
+ The ESP header is used to prevent wiretapping.
+
+ At either the agent or middlebox side, the following should be pre-
+ configured: the IP addresses of the agent or middlebox, TCP (as the
+ transport protocol), and the port numbers (if possible). Only
+ packets from the pre-configured address of the agents or middlebox
+ should be accepted.
+
+ The keys for authentication for both the SIMCO agent and middlebox
+ are pre-configured at each side. For replay protection, the use of a
+ key management system is recommended. For the Internet Key Exchange
+ (IKE) protocol, see [RFC4306].
+
+10. IAB Considerations on UNSAF
+
+ UNilateral Self-Address Fixing (UNSAF) is described in [RFC3424] as a
+ process at originating endpoints that attempt to determine or fix the
+ address (and port) by which they are known to another endpoint.
+ UNSAF proposals, such as STUN [RFC3489], are considered a general
+ class of work-arounds for NAT traversal and solutions for scenarios
+ with no middlebox communication (MIDCOM).
+
+ This document describes a protocol implementation of the MIDCOM
+ semantics and thus implements a middlebox communication (MIDCOM)
+ solution. MIDCOM is not intended as a short-term work-around, but
+ more as a long-term solution for middlebox communication. In MIDCOM,
+ endpoints are not involved in allocating, maintaining, and deleting
+ addresses and ports at the middlebox. The full control of addresses
+ and ports at the middlebox is located at the SIMCO server.
+
+ Therefore, this document addresses the UNSAF considerations in
+ [RFC3424] by proposing a long-term alternative solution.
+
+11. Acknowledgements
+
+ The authors would like to thank Sebastian Kiesel and Andreas Mueller
+ for valuable feedback from their SIMCO implementation and Mary Barnes
+ for a thorough document review.
+
+
+
+
+
+
+
+
+Stiemerling, et al. Experimental [Page 64]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+12. Normative References
+
+ [RFC3989] Stiemerling, M., Quittek, J., and T. Taylor, "Middlebox
+ Communications (MIDCOM) Protocol Semantics", RFC 3989,
+ February 2005.
+
+ [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
+ 2005.
+
+ [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
+ 4303, December 2005.
+
+ [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
+ (TLS) Protocol Version 1.1", RFC 4346, April 2006.
+
+13. Informative References
+
+ [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
+ September 1981.
+
+ [RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless
+ Inter-Domain Routing (CIDR): an Address Assignment and
+ Aggregation Strategy", RFC 1519, September 1993.
+
+ [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
+ (IPv6) Specification", RFC 2460, December 1998.
+
+ [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
+ Translator (NAT) Terminology and Considerations", RFC
+ 2663, August 1999.
+
+ [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
+ Issues", RFC 3234, February 2002.
+
+ [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A.,
+ and A. Rayhan, "Middlebox communication architecture and
+ framework", RFC 3303, August 2002.
+
+ [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral
+ Self-Address Fixing (UNSAF) Across Network Address
+ Translation", RFC 3424, November 2002.
+
+ [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
+ "STUN - Simple Traversal of User Datagram Protocol (UDP)
+ Through Network Address Translators (NATs)", RFC 3489,
+ March 2003.
+
+
+
+
+
+Stiemerling, et al. Experimental [Page 65]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+ [RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents:
+ Procedures", BCP 92, RFC 3932, October 2004.
+
+ [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
+ Architecture", RFC 4291, February 2006.
+
+ [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
+ RFC 4306, December 2005.
+
+Authors' Addresses
+
+ Martin Stiemerling
+ NEC Europe Ltd.
+ Network Laboratories Europe
+ Kurfuersten-Anlage 36
+ 69115 Heidelberg
+ Germany
+
+ Phone: +49 6221 4342-113
+ EMail: stiemerling@netlab.nec.de
+
+
+ Juergen Quittek
+ NEC Europe Ltd.
+ Network Laboratories Europe
+ Kurfuersten-Anlage 36
+ 69115 Heidelberg
+ Germany
+
+ Phone: +49 6221 4342-115
+ EMail: quittek@netlab.nec.de
+
+
+ Cristian Cadar
+ Muelheimer Strasse 23
+ 40239 Duesseldorf
+ Germany
+
+ EMail: ccadar2@yahoo.com
+
+
+
+
+
+
+
+
+
+
+
+
+Stiemerling, et al. Experimental [Page 66]
+
+RFC 4540 NEC's SIMCO Protocol Version 3.0 May 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78 and at www.rfc-editor.org/copyright.html, and
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Stiemerling, et al. Experimental [Page 67]
+