RFC 4540
NEC's Simple Middlebox Configuration (SIMCO) Protocol Version 3.0
NEC's Simple Middlebox Configuration (SIMCO) Protocol Version 3.0 🎀
Okay bestie, so this is RFC 4540 💖 It came out in May 2006 from the Network Working Group. The authors are M. Stiemerling, J. Quittek, and C. Cadar, and the title block lists all three as being from NEC ✨ It's in the Experimental category 🧪 The title block doesn't list anything it obsoletes or updates, so it stands on its own 🦋
Status of This Memo ✨
Quick vibe check: this memo defines an Experimental Protocol for the Internet community 🧪 It does not specify an Internet standard of any kind 🙅♀️ The authors are asking for discussion and suggestions for improvement, and distribution of this memo is unlimited 📣
Copyright Notice 🌸
Copyright (C) The Internet Society (2006) ©️
IESG Note 🙈
Okay, so the IESG has a little disclaimer here, and it's important 👀 This RFC was at one point considered by the IETF, so it might look a lot like a current IETF work in progress or a published IETF work. But it is not a candidate for any level of Internet Standard 🚫 The IETF doesn't know whether this RFC is fit for any purpose, and it specifically says the decision to publish wasn't based on IETF review of things like security, congestion control, or inappropriate interaction with deployed protocols 😬 The RFC Editor chose to publish it at their discretion 🎀 So if you're reading this, please be careful about how much you trust it before you implement or deploy anything 🫶 For more info, check out RFC 3932 [RFC3932] 🔥
Abstract 🦋
This document describes a protocol for controlling middleboxes like firewalls and network address translators, which is giving real main character energy 👑 It's a fully compliant implementation of the Middlebox Communications (MIDCOM) semantics described in RFC 3989 ✨ Compared to earlier experimental versions of the SIMCO protocol, version 3.0 uses binary message encodings so it takes fewer resources 💜
Table of Contents 📋
1. Introduction ....................................................4
1.1. Terminology ................................................4
1.2. Binary Encodings ...........................................4
2. Compliance with MIDCOM Protocol Semantics .......................5
3. SIMCO Sessions ..................................................6
4. SIMCO Message Components ........................................6
4.1. Message Types ..............................................7
4.2. The SIMCO Header ...........................................7
4.2.1. Basic Message Types .................................8
4.2.2. Message Sub-types for Requests and Positive
Replies .............................................8
4.2.3. Message Sub-types for Negative Replies ..............8
4.2.4. Message Sub-types for Notifications .................9
4.2.5. Transaction Identifier ..............................9
4.3. The SIMCO Payload .........................................10
4.3.1. SIMCO Protocol Version Attribute ...................11
4.3.2. Authentication Attributes ..........................11
4.3.3. Middlebox Capabilities Attribute ...................12
4.3.4. Policy Rule Identifier Attribute ...................13
4.3.5. Group Identifier Attribute .........................13
4.3.6. Policy Rule Lifetime Attribute .....................13
4.3.7. Policy Rule Owner Attribute ........................14
4.3.8. Address Tuple Attribute ............................14
4.3.9. PRR Parameter Set Attribute ........................16
4.3.10. PER Parameter Set Attribute .......................18
5. SIMCO Message Formats ..........................................19
5.1. Protocol Error Replies and Notifications ..................19
5.1.1. BFM Notification ...................................19
5.1.2. Protocol Error Negative Replies ....................19
5.2. Session Control Messages ..................................20
5.2.1. SE Request .........................................20
5.2.2. SE Positive Reply ..................................21
5.2.3. SA Positive Reply ..................................21
5.2.4. SA Request .........................................21
5.2.5. ST Request and ST Positive Reply ...................22
5.2.6. SE Negative Replies ................................22
5.2.7. AST Notification ...................................23
5.3. Policy Rule Control Messages ..............................23
5.3.1. Policy Events and Asynchronous Notifications .......24
5.3.2. PRR Request ........................................24
5.3.3. PER Request ........................................25
5.3.4. PEA Request ........................................26
5.3.5. PLC Request ........................................26
5.3.6. PRS Request ........................................27
5.3.7. PRL Request ........................................27
5.3.8. PDR Request ........................................27
5.3.9. PRR Positive Reply .................................28
5.3.10. PER Positive Reply ................................28
5.3.11. PLC Positive Reply ................................29
5.3.12. PRD Positive Reply ................................29
5.3.13. PRS Positive Reply ................................30
5.3.14. PES Positive Reply ................................31
5.3.15. PDS Positive Reply ................................32
3.5.16. PRL Positive Reply ................................32
5.3.17. PDR Positive Replies ..............................33
5.3.18. Policy Rule Control Negative Replies ..............33
5.3.19. ARE Notification ..................................33
6. Message Format Checking ........................................34
7. Session Control Message Processing .............................36
7.1. Session State Machine .....................................36
7.2. Processing SE Requests ....................................37
7.3. Processing SA Requests ....................................38
7.4. Processing ST Requests ....................................39
7.5. Generating AST Notifications ..............................39
7.6. Session Termination by Interruption of Connection .........39
8. Policy Rule Control Message Processing .........................40
8.1. Policy Rule State Machine .................................40
8.2. Processing PRR Requests ...................................41
8.2.1. Initial Checks .....................................41
8.2.2. Processing on Pure Firewalls .......................43
8.2.3. Processing on Network Address Translators ..........44
8.3. Processing PER Requests ...................................45
8.3.1. Initial Checks .....................................46
8.3.2. Processing on Pure Firewalls .......................48
8.3.3. Processing on Network Address Translators ..........49
8.3.4. Processing on Combined Firewalls and NATs ..........51
8.4. Processing PEA Requests ...................................51
8.4.1. Initial Checks .....................................51
8.4.2. Processing on Pure Firewalls .......................53
8.4.3. Processing on Network Address Translators ..........54
8.5. Processing PLC Requests ...................................55
8.6. Processing PRS Requests ...................................56
8.7. Processing PRL Requests ...................................57
8.8. Processing PDR requests ...................................57
8.8.1. Extending the MIDCOM semantics .....................58
8.8.2. Initial Checks .....................................58
8.8.3. Processing on Pure Firewalls .......................61
8.8.4. Processing on Network Address Translators ..........61
8.8.5. Processing on Combined Firewalls and NATs ..........62
8.9. Generating ARE Notifications ..............................62
9. Security Considerations ........................................63
9.1. Possible Threats to SIMCO .................................63
9.2. Securing SIMCO with IPsec .................................63
10. IAB Considerations on UNSAF ...................................64
11. Acknowledgements ..............................................64
12. Normative References ..........................................65
13. Informative References ........................................651. Introduction ✨
Okay so the Simple Middlebox Configuration (SIMCO) protocol is used to control firewalls and Network Address Translators (NATs) 🔥 As defined in [RFC3234], firewalls and NATs get classified as middleboxes 📦 A middlebox is a device sitting on the datagram path between the source and destination that does more than just IP routing 🧚 As outlined in [RFC3303], firewalls and NATs can be obstacles to packet streams, for example when dynamically negotiated UDP or TCP port numbers are used, which is super common in peer-to-peer apps 🙈
SIMCO lets applications talk to middleboxes on the datagram path so they can ask for a dynamic configuration that lets datagram streams get through 🦋 Apps 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 in this document is fully aligned with the terminology defined in [RFC3989], so no confusion there 🫶 From here on, the term SIMCO refers to SIMCO version 3.0 ✨ The term "prefix-length" is used as described in [RFC4291] and [RFC1519] 🌸 When it comes to wildcarding, the prefix length decides which part of an IP address gets 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 takes more resources than binary encodings do to generate and parse messages 😩 That applies to coding agents and middleboxes, and also to running a SIMCO stack in general 💻
Low resource requirements matter for two big reasons:
- For lots of applications (IP telephony, for example), session setup times are critical 📞 Users will only put up with setup times up to some limit, and some signaling protocols start retransmitting messages if setup isn't finished within a certain time ⏰
- Lots of middleboxes are pretty small and relatively low-cost devices 🧸 For these, supporting resource-intensive protocols might be a problem 😬 Whether a protocol gets accepted on these devices depends, among other things, on what it costs to implement and on its hardware requirements 💸
So the authors 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 ✨
okay so SIMCO version 3 is fully compliant with the MIDCOM protocol semantics defined by [RFC3989] 💅 it's giving total commitment to the spec. It implements protocol transactions the way Section 2.1.1 of [RFC3989] describes them, and every message type from Section 2.1.2 of [RFC3989] is supported. All the mandatory transactions are implemented too 🫶 SIMCO does not implement the optional group transactions, so those are a no-go bestie. For every transaction that IS implemented, SIMCO handles all the parameters for the info it carries. Iconic behaviour, honestly 👑
SIMCO also coins a few new terms so it can talk about the semantics. Two of them are Session Authentication (SA) and Policy Enable Rule After reservation (PEA) messages. SA models the state transition from NOAUTH to OPEN shown in Figure 2 of [RFC3989], and PEA models the transition from RESERVED to ENABLED shown in Figure 4 of [RFC3989] 🦋
Then there's the one extra transaction SIMCO adds on top of what [RFC3989] defines: the Policy Disable Rule (PDR) transaction 🚫 PDRs get used by security functions like intrusion detection and attack detection, and they let the agent block a specified kind of traffic. Main character energy, the PDR outranks Policy Enable Rules (PERs) 👑 When a PDR is established, every conflicting PER gets terminated (yes, even the ones with just a partial overlap 💀), and no new conflicting PER can be established until that PDR is terminated. Support for the PDR transaction is optional, so it's not required to be a SIMCO slay. If you want the full PDR semantics, check out Section 8.8 🌸
3. SIMCO Sessions 🦋
the SIMCO protocol runs on a session model with exactly two parties: an agent that represents one or more applications, and a middlebox. Both parties are allowed to join multiple sessions 💜 An agent can talk to several middleboxes at once, using one session per middlebox. A middlebox can also talk to several agents at once, using one session per agent. Social butterfly behaviour 🦋
+-------+ SIMCO protocol +-----------+
| agent +------------------+ middlebox |
+-------+ +-----------+
Figure 1: Participants in a SIMCO sessionSIMCO sessions must run over a reliable transport layer protocol, and the agent is the one who starts them 🫶 SIMCO implementations must support TCP. Other reliable transport protocols can also be used as transport for SIMCO, if you're feeling extra 🌈 When TCP is the transport, middleboxes must wait for agents to connect on port 7626. That port is assigned to SIMCO servers by IANA, and you can see the registry at http://www.iana.org/assignments/port-numbers 🎀 If it's needed, the session can be secured with either IPsec or TLS [RFC4346], which guarantees authentication, message integrity and confidentiality. Security is a whole vibe, so the IPsec details live in Section 9, "Security Considerations" 🔐
The transaction semantics of sessions are explained in Section 2.2 of [RFC3989] 📖
4. SIMCO Message Components 🧚
every SIMCO message, going from agent to middlebox AND from middlebox to agent, gets sent over the transport protocol described in Section 3 ✨ SIMCO messages are Type-Length-Value (TLV) encoded, using big endian (network ordered) binary data representations. Big endian is a must-know, bestie 💖
All SIMCO messages start with the SIMCO header, which holds the message type, the message length, and a message identifier. The rest of the message, the payload, carries zero, one, or more TLV message attributes 🍓
4.1. Message Types 💌
the message type in the SIMCO header is split 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 the basic type 'request message', while messages going from the middlebox to the agent are one of the other three types. Request messages, plus positive and negative reply messages, all 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, though, a notification message can also belong to a request transaction 🙈 See section 2.3.4. of [RFC3989] for a detailed discussion of this plot twist.
The sub-type gives extra info about the message type, but only within the context of its basic message type. Only the combo of basic type and sub-type truly identifies what a message is 💅
4.2. The SIMCO Header 🎀
the SIMCO header is the first part of every SIMCO message 💖 It has 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 is 64 bits in size, and its layout is shown in Figure 2.
Message Type
_______________^_______________
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Basic Type | Sub-Type | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction Identifier (TID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The SIMCO header4.2.1. Basic Message Types 🌸
for the basic type field, these values are defined:
0x01 : Request Message
0x02 : Positive Reply Message
0x03 : Negative Reply Message
0x04 : Notification Message4.2.2. Message Sub-types for Requests and Positive Replies 🧁
for basic types 0x01 (request) and 0x02 (positive reply), there's a shared set of sub-type values. Most of them work for both basic types, and the restricted ones get marked as such ✨
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), these sub-type values are defined. They're grouped by what the reply is about 💜
Replies concerning general message handling
0x10 : wrong basic request message type
0x11 : wrong request message sub-type
0x12 : badly formed request
0x13 : reply message too big
Replies concerning sessions
0x20 : request not applicable
0x21 : lack of resources
0x22 : protocol version mismatch
0x23 : authentication failed
0x24 : no authorization
0x25 : transport protocol problem
0x26 : security of underlying protocol layers insufficient
Replies concerning policy rules
0x40 : transaction not supported
0x41 : agent not authorized for this transaction
0x42 : no resources available for this transaction
0x43 : specified policy rule does not exist
0x44 : specified policy rule group does not exist
0x45 : not authorized for accessing specified policy
0x46 : not authorized for accessing specified group
0x47 : requested address space not available
0x48 : lack of IP addresses
0x49 : lack of port numbers
0x4A : middlebox configuration failed
0x4B : inconsistent request
0x4C : requested wildcarding not supported
0x4D : protocol type doesn't match
0x4E : NAT mode not supported
0x4F : IP version mismatch
0x50 : conflict with existing rule
0x51 : not authorized to change lifetime
0x52 : lifetime can't be extended
0x53 : illegal IP Address
0x54 : protocol type not supported
0x55 : illegal port number
0x56 : illegal number of subsequent ports (NOSP)
0x57 : already enable PID
0x58 : parity doesn't match4.2.4. Message Sub-types for Notifications 🔔
for basic type 0x04, these sub-type values are defined:
0x01 : (BFM) badly formed message received
0x02 : (AST) asynchronous session termination
0x03 : (ARE) asynchronous policy rule event4.2.5. Transaction Identifier 🆔
the transaction identifier (TID) is an arbitrary number that identifies the transaction 💅 In a request message, the agent picks an agent-unique TID, so the same agent never reuses a TID across two different request messages in the same session. Reply messages must contain the same TID as the request they're replying to. In a notification message, the middlebox picks a middlebox-unique TID, so the same middlebox never reuses a TID across two different notification messages in the same session. Unique IDs are the realest form of self-care 🫶
4.3. The SIMCO Payload 💎
a SIMCO payload is made up 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 attributeThe attribute length field holds the length of the value field, measured 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 bits4.3.1. SIMCO Protocol Version Attribute 🏷️
the SIMCO protocol version attribute has a length of four octets 💖 The first two octets hold the version number: one is the major version number and the other is the minor version number. The remaining two octets are reserved 🤍
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0001 | 0x0004 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|major version #|minor version #| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Protocol version attributethe SIMCO protocol specified in this document is version 3.0 🎉 The version numbers carried in the protocol version attribute are 3 for the major version number and 0 for the minor version number 👑
4.3.2. Authentication Attributes ✨
okay so the authentication challenge attribute and the authentication token attribute have the exact same format 🫶 each one has a single value field with variable length, and for both the max length is 4096 octets. ngl that's the cap 💅 also, heads up, the length of these attributes can be values that are not multiples of 4 octets, so don't be surprised 🙈 For the challenge attribute, the value field holds an authentication challenge that one peer sends to the other, asking the other peer to authenticate itself. main character energy 👑
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0002 | challenge length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| challenge
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 5: Authentication challenge attribute
the authentication token attribute is used for sending an authentication token 🦋
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0003 | authentication length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| authentication token
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 6: Authentication attribute
4.3.3. Middlebox Capabilities Attribute 🌸
this one is eight octets long, so it's a little bigger than the rest 🧚
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0004 | 0x0008 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MB type |I|E|P|S|IIV|EIV| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| max policy rule lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 7: Capabilities attribute
the first parameter field is a bit field called MB type, and it tells you about the middlebox type. these bits are defined, and 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)when middleboxes mix NAT and firewalls, you can combine those flags 🍓 for example, a Network Address and Port Translator (NAPT) with packet filter and PDR transaction support has an MB type value of 0xD1. slay 💖
the next four parameter fields are one-bit binary flags:
I : internal IP address wildcard support
E : external IP address wildcard support
P : port wildcard support
S : persistent storage of policy rulesthe IIV (Internal IP version) and EIV (external IP version) fields each take two bits, and they tell you which IP version is supported. 0x1 means IPv4, 0x2 means IPv6, and 0x3 means both, which is IPv4 and IPv6 dual stack 🌈
the next parameter field is 16 bits long and it's reserved 🫧
the max policy rule lifetime field says the maximum lifetime a policy rule may have ⏳
4.3.4. Policy Rule Identifier Attribute 🎀
this is the policy rule identifier (PID) attribute, and it holds an identifier for a policy rule. it's four octets long 💅
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0005 | 0x0004 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| policy rule identifier (PID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 8: Policy rule identifier attribute
4.3.5. Group Identifier Attribute 🦋
the group identifier (GID) attribute is the one that holds an identifier for a policy rule group. also four octets, same energy as the PID 🫶
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0006 | 0x0004 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| group identifier (GID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 9: Group identifier attribute
4.3.6. Policy Rule Lifetime Attribute ⭐
the policy rule lifetime attribute says the requested or actual remaining lifetime of a policy rule, in seconds ⏰ its value field holds a 32-bit unsigned integer, so it's a nice clean number 🔥
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0007 | 0x0004 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| policy rule lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 10: Policy rule lifetime attribute
4.3.7. Policy Rule Owner Attribute 👑
the policy rule owner attribute says which authenticated agent created and owns the policy rule. its value field doesn't have a fixed length, but it's capped at 255 octets 🙈 same heads up as before: its length can be values that are not multiples of 4 octets. and the owner is set by the middlebox, so the middlebox is the one filling this in 🧚
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0008 | owner length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| owner
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 11: Policy rule owner attribute
4.3.8. Address Tuple Attribute 🌈
okay this is the big one, bestie 😭 the address tuple attribute holds a set of parameters that specify IP and transport addresses. its length is 32, 96, or 192 bits, depending on what's in it.
the first parameter field is 4 bits. it tells you whether the parameters only name the protocols used, or also the concrete addresses. the defined values are:
0x0 : full addresses
0x1 : protocols onlythe second parameter field is also 4 bits, and it gives the IP version number. the defined values are:
0x1 : IPv4
0x2 : IPv6the third parameter field is 8 bits, and it gives a prefix length for IP address wildcarding (see Section 1.1) ✨
the fourth parameter field is also 8 bits, and it gives the transport protocol. the defined values are all the values allowed in the 'Protocol' field of the IPv4 header [RFC791] or in the 'Next Header field' of the IPv6 header [RFC2460]. the Internet Assigned Numbers Authority (IANA) keeps the set of defined numbers for these fields under the label 'PROTOCOL NUMBERS' 📋
the fifth parameter field is 8 bits, and it gives the location of the address. the defined values 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, and for IPv6, a prefix length less than 0x80 is IP address wildcarding.
the port range field must always be greater than zero, but at least 1 🫶
Here are the three layouts, one for each combination of address type and IP version:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 ✨
okay so the policy reserve rule (PRR) parameter set attribute is basically the whole PRR request bundled into one tidy little package 🎀 It carries everything except the group identifier, which lives somewhere else:
- NAT mode 💅
- port parity
- requested inside IP version
- requested outside IP version
- transport protocol
- port range
The attribute value field is 32 bits total, split into six parameter fields. Let's go through them, bestie 🫶
The first one is NM, which is 2 bits and says which NAT mode the middlebox should use for the reservation. The defined values are:
01 : traditional
10 : twiceNext up is PP, also 2 bits, for the requested port parity. Values:
00 : any
01 : odd
10 : evenThen we've got IPi and IPo, each 2 bits. IPi covers the IP version on the inside of the middlebox, and IPo covers the outside. Same value set for both:
00 : any
01 : IPv4
10 : IPv6The fifth field is the transport protocol, 8 bits 🔥 A value of zero means the reservation is for an IP address with no specific protocol or port number picked. Any non-zero value can be one of the defined values for the protocol field in the IPv4 header and IPv6 extension headers. Those numbers are kept by the Internet Assigned Numbers Authority (IANA) under the label PROTOCOL NUMBERS, so that's where to look 👑
The sixth field is the port range, 16 bits, and it's an unsigned integer for how many ports should be supported. Here's the tea ☕
0xFFFFmeans all port numbers of the chosen transport protocol (wildcard energy 🌈)0x0001means just a single port number- anything greater than one means that many consecutive port numbers get reserved
- zero is not valid for this field 💀
The wildcard value 0xFFFF only works in the port range field of the PRR parameter set attribute. In the address tuple attribute, port wildcarding is done differently: the port number field is set to zero instead (see Section 4.3.8). Don't mix them up, bestie 🙈
Here's the visual, Figure 13:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 is smaller and only has two real parameters: the requested port parity, and the direction of the enabled data stream. The attribute value field is 32 bits, split into 3 parameter fields.
The first field is 8 bits and holds the requested port parity. Defined values:
0x00 : any
0x03 : sameThe second field is also 8 bits and says which direction the enabled data stream goes. Defined values:
0x01 : inbound
0x02 : outbound
0x03 : bi-directionalThe third field is 16 bits and is reserved, so it's just sitting there looking pretty 🌸
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x000B | 0x0004 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| port parity | direction | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 14: PER parameter set attribute 💖
5. SIMCO Message Formats 🎀
okay now the message formats, the fun part 💅 Each SIMCO message type gets its format defined here. They're grouped into three buckets: protocol error messages, session control messages, and policy rule control messages.
5.1. Protocol Error Replies and Notifications 🚨
So here's the situation. The middlebox might hit a processing problem before it can even tell whether a message is about session control or policy rule control. Or it might not be able to figure out the message type at all, or it spots a wrong message format. In those cases, it sends the Badly Formed Message (BFM) notification or one of the negative replies below:
0x0401 : BFM notification
0x0310 : wrong basic request message type
0x0311 : wrong request message sub-type
0x0312 : badly formed request5.1.1. BFM Notification 🙈
The BFM notification is sent from the middlebox to the agent after it gets a message that doesn't follow the SIMCO message format definition. It has no attributes and is just the SIMCO header, nothing else 🍓
+--------------------------+
| SIMCO header |
+--------------------------+Figure 15: BFM notification structure ✨
5.1.2. Protocol Error Negative Replies 💀
Protocol error negative replies get sent from the middlebox to the agent when a message can't be clearly interpreted because it doesn't match any defined message format. They cover three things: wrong basic request message type (0x0310), wrong request message sub-type (0x0311), and badly formed request (0x0312). Same deal here, no attributes, just the SIMCO header.
+--------------------------+
| SIMCO header |
+--------------------------+Figure 16: Protocol error negative reply structure 🌷
5.2. Session Control Messages 🦋
Session control messages come in the following list. Each type is made from a basic type plus a 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 notification5.2.1. SE Request 🌈
The Session Establishment (SE) request is sent from the agent to the middlebox to ask for a session to be set up. It holds one or two attributes: a mandatory SIMCO version number attribute, and an optional authentication challenge attribute that asks the middlebox to authenticate itself. Main character behaviour 👑
+--------------------------+
| SIMCO header |
+--------------------------+
| SIMCO protocol version |
+--------------------------+
| authentication challenge | optional
+--------------------------+Figure 17: Structure of SE request 🧊
5.2.2. SE Positive Reply 🎀
The Session Establishment (SE) reply says the session setup is done ✅ It has one mandatory attribute, the middlebox capabilities attribute, and that's it.
+--------------------------+
| SIMCO header |
+--------------------------+
| middlebox capabilities |
+--------------------------+Figure 18: Structure of SE positive reply 💖
5.2.3. SA Positive Reply 🔐
Okay this one's a little plot twist. If the agent asked for middlebox authentication, or the middlebox wants the agent to authenticate itself, then the middlebox answers the SE request with a Session Authentication (SA) reply instead of an SE reply. The SA reply has two optional attributes, but at least one of them has to be present. The first is an authentication challenge attribute asking the agent to authenticate itself. The second is an authentication token attribute, which authenticates the middlebox as the answer to an authentication request from 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 is sent from the agent to the middlebox after an initial SE request got answered with an SA reply. The SE request message contains one optional attribute: an authentication token attribute that authenticates the agent as the response to an authentication challenge the middlebox sent in an SA reply. Full circle energy 🔄
+--------------------------+
| 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 is sent from the agent to the middlebox to ask for a session to be ended. The ST positive reply comes back to acknowledge that the session is terminated. Both of these have no attributes and are just the SIMCO header, so they're super minimal and clean 🧚✨
+--------------------------+
| SIMCO header |
+--------------------------+Figure 21: Structure of ST request and positive reply 🍓
5.2.6. SE Negative Replies 🙅♀️
okay so there are nine different negative reply messages the middlebox can send back to the agent if it rejects an SE request 😭 Three of them are the protocol error negative replies (0x031X), which we already covered in Section 4.1.2 🫶
The other six are specific to session establishment. One of them, the protocol version mismatch negative reply (0x0322), has just one attribute: the protocol version attribute 🎀
+--------------------------+
| SIMCO header |
+--------------------------+
| SIMCO protocol version |
+--------------------------+
Figure 22a: Structure of SE negative repliesThe remaining replies are 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) 🌸 These ones are simpler, bestie, because they only carry the SIMCO header ✨
+--------------------------+
| SIMCO header |
+--------------------------+
Figure 22b: Structure of SE negative replies5.2.7. AST Notification 🦋
The Asynchronous Session Termination (AST) notification is sent from the middlebox to the agent when the middlebox wants to terminate a SIMCO session 💀 It has no attributes at all, just the SIMCO header, so it's giving minimalist 🧚
+--------------------------+
| SIMCO header |
+--------------------------+
Figure 22a: Structure of AST notifications5.3. Policy Rule Control Messages 🌈
Policy Rule control messages come in the following list of message types. Each one is made of a basic type and a 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
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 notification5.3.1. Policy Events and Asynchronous Notifications ✨
SIMCO keeps an owner attribute for each policy rule at the middlebox 👑 Depending on how the middlebox is configured, several agents might access the same policy rule. See also [RFC3989], Sections 2.1.5 and 2.3.4, if you want the deeper dive 🤓
To keep all the agents in sync 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 the agents that are authorized to access that rule. The middlebox also sends an ARE to all the authorized agents when the rule lifetime gets modified, or when the rule is deleted 🧚♀️
5.3.2. PRR Request 🎀
The Policy Reserve Rule (PRR) request is sent from the agent to the middlebox to ask for a reservation of an IP address (and potentially also a range of port numbers) at the middlebox 💖 Besides the SIMCO header, the request has two or three attributes. The first one is the PRR parameter set attribute, which specifies all the parameters of the request except the requested policy rule lifetime and the group identifier. The missing parameters are covered by the next two attributes. The last one, the group identifier, is optional 🫶
+--------------------------+
| SIMCO header |
+--------------------------+
| PRR parameter set |
+--------------------------+
| policy rule lifetime |
+--------------------------+
| group identifier | optional
+--------------------------+
Figure 23: Structure of PRR request5.3.3. PER Request 🦋
The Policy Enable Rule (PER) request is sent from the agent to the middlebox to ask for data communication between an internal and an external address to be enabled 🌈 Besides the SIMCO header, the request has four or five attributes. The first one is the PER parameter set attribute, which specifies all the parameters except the internal address, the external address, the requested policy rule lifetime, and the group identifier. The missing parameters are covered by the next four attributes. Two address tuple parameters specify the 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 request5.3.4. PEA Request 🍓
The Policy Enable rule After reservation (PEA) request is sent from the agent to the middlebox to ask for data communication between an internal and an external address to be enabled 🙈 It's basically a PER request with one difference: the optional group identifier attribute gets swapped out for a mandatory policy rule identifier attribute. That attribute points at an already established policy reserve rule, which was set up 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 requestThe group identifier attribute is not included in the PEA request, because the policy enable rule inherits its group membership from the policy reserve rule 👑
5.3.5. PLC Request 💜
The Policy Rule Lifetime Change (PLC) request is sent from the agent to the middlebox to ask for a change to the remaining policy lifetime ⭐ Besides the SIMCO header, it has two attributes: one that specifies the policy rule the change applies to, and one that specifies the requested remaining lifetime 🧚
+--------------------------+
| SIMCO header |
+--------------------------+
| policy rule identifier |
+--------------------------+
| policy rule lifetime |
+--------------------------+
Figure 26: Structure of PLC request5.3.6. PRS Request 🌸
The Policy Rule Status (PRS) request is sent from the agent to the middlebox to ask for a report on the status of a specific policy rule 🔍 Besides the SIMCO header, it contains just one attribute, the one specifying which policy rule the report is for 🫶
+--------------------------+
| SIMCO header |
+--------------------------+
| policy rule identifier |
+--------------------------+
Figure 27: Structure of PRS request5.3.7. PRL Request 🍓
The Policy Rule List (PRL) request is sent from the agent to the middlebox to ask for a list of all the policy rules the agent can access 📋 It's just the SIMCO header, no extras 💅
+--------------------------+
| SIMCO header |
+--------------------------+
Figure 28: Structure of PRL request5.3.8. PDR Request 🔥
The Policy Disable Rule (PDR) request is sent from the agent to the middlebox to ask for a disable rule 🚫 The message has 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 request5.3.9. PRR Positive Reply ✨
okay bestie, the PRR positive reply is the middlebox saying "yep, I reserved that address for you" 💅 It goes out after a reservation works, whether that address is on the inside or the outside of the middlebox. There are four mandatory attributes and one optional one: the policy rule identifier of the new policy reserve rule, the group identifier that goes with it, the remaining lifetime of the rule, the reserved outside address tuple, and the reserved inside address tuple if it's there. The inside tuple only shows up when the middlebox is 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 reply5.3.10. PER Positive Reply 🌸
The PER positive reply goes out once the middlebox has successfully turned on data transfer between an internal address and an external one, which happens through a PER or PEA request 🫶 This one has five attributes: the policy rule identifier of the new policy enable rule, the group identifier, the remaining lifetime, the address tuple on the outside of the middlebox, and the address tuple on the inside. No optional stuff here, it's all in 🙌
+--------------------------+
| SIMCO header |
+--------------------------+
| policy rule identifier |
+--------------------------+
| group identifier |
+--------------------------+
| policy rule lifetime |
+--------------------------+
| address tuple (outside) |
+--------------------------+
| address tuple (inside) |
+--------------------------+
Figure 31: Structure of PER positive reply5.3.11. PLC Positive Reply 🍓
The PLC positive reply is sent when the middlebox changes a policy rule's lifetime to a positive, non-zero value 🧚 It's the tiniest message ever, just one attribute: the remaining lifetime of the policy rule. Very minimalist, very iconic 💀
+--------------------------+
| SIMCO header |
+--------------------------+
| policy rule lifetime |
+--------------------------+
Figure 32: Structure of PLC positive reply5.3.12. PRD Positive Reply 💜
The PRD positive reply is the "bye bye rule" message 😭 It goes out after the middlebox sets a policy rule's remaining lifetime to zero, which terminates the rule. This one is even simpler: it's just the SIMCO header, no attributes at all.
+--------------------------+
| SIMCO header |
+--------------------------+
Figure 33: Structure of PRD positive reply5.3.13. PRS Positive Reply 🦋
The PRS positive reply is how the middlebox reports the status of a policy reserve rule 👑 Its format matches the PRR positive reply, with one extra thing tacked on the end: a policy rule owner attribute. Same vibes as PRR, just with a little owner tag added ✨
+--------------------------+
| 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 reply5.3.14. PES Positive Reply 🌈
The PES positive reply is for reporting the status of a policy enable rule 🔥 This one has the most fields of the bunch, so get comfy: the policy rule identifier, group identifier, PER parameter set, and then four address tuples (internal, inside, outside, and external), followed by the policy rule lifetime and the policy rule owner. That's a lot of tuples, bestie, but it's giving organized 🎀
+--------------------------+
| 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 reply5.3.15. PDS Positive Reply ⭐
The PDS positive reply reports the status of a policy disable rule 🫧 It carries five attributes: the policy rule identifier, the internal and external address tuples, the policy disable rule lifetime, and the policy rule owner. Clean, cute, and to the point 💖
+--------------------------+
| SIMCO header |
+--------------------------+
| policy rule identifier |
+--------------------------+
| address tuple (internal) |
+--------------------------+
| address tuple (external) |
+--------------------------+
| policy rule lifetime |
+--------------------------+
| policy rule owner |
+--------------------------+
Figure 36: Structure of PDS positive reply3.5.16. PRL Positive Reply 🧁
The PRL positive reply is how the middlebox reports the full list of established policy rules 📋 The number of attributes changes every time, since you get one policy rule identifier attribute for each established rule. Lots of rules? Lots of identifiers, periodt 💅
+--------------------------+
| SIMCO header |
+--------------------------+
| policy rule identifier |
+--------------------------+
| policy rule identifier |
+--------------------------+
| |
. . .
| |
+--------------------------+
| policy rule identifier |
+--------------------------+
Figure 37: Structure of PRL positive reply5.3.17. PDR Positive Replies 🦢
The PDR positive reply goes out after the middlebox successfully turns on the policy disable rule and removes any conflicting policy rules 🧹 It has two attributes: the policy rule identifier of the new policy disable rule, and the remaining lifetime of the policy rule. Two fields, zero drama 🙈
+--------------------------+
| SIMCO header |
+--------------------------+
| policy rule identifier |
+--------------------------+
| policy rule lifetime |
+--------------------------+
Figure 38: Structure of PDR positive reply5.3.18. Policy Rule Control Negative Replies 🚫
Okay so the negative replies. Session establishment negative replies are sent from the middlebox to the agent whenever a middlebox rejects a policy rule control request 🙅♀️ Beyond the protocol error replies, there are a bunch of policy rule control-specific negative replies that can be sent too, and they're all listed at the beginning of Section 5.3. None of them have attributes. They consist of the SIMCO header only, which is honestly the most "no thanks" message possible 💀
+--------------------------+
| SIMCO header |
+--------------------------+
Figure 39: Structure of Policy rule control negative replies5.3.19. ARE Notification 🔔
The ARE notification is the Asynchronous Policy Rule Event message, and it goes from the middlebox to the agent 📣 Every agent in an open SIMCO session that's authorized to access the policy rule gets one, as long as they aren't the ones explicitly asking for an action (reserving, enabling, or changing lifetime). It shows up 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)
Besides the SIMCO header, the request message contains two attributes specifying the policy rule that is concerned and the current lifetime. So that's two attributes plus the header, and the notification is basically the middlebox gossiping about what just happened to a rule 🗣️✨
+--------------------------+
| SIMCO header |
+--------------------------+
| policy rule identifier |
+--------------------------+
| policy rule lifetime |
+--------------------------+
Figure 40: Structure of ARE notification6. Message Format Checking 💅
okay so this part is the checklist that every single message goes through when it lands on a middlebox 📬. it's the common processing for all messages, no matter what kind they are 🫶
- first up, the header gets checked for consistency before the payload is processed 🔍
- if the header checks fail, the middlebox sends a BFM notification 🙅♀️
- and if a session is already established, it also sends an AST notification and closes the connection 💔
- the middlebox waits until it has received as many octets from the agent as the message length plus 8 octets (that's the length of the SIMCO header) ⏳
- if it's still waiting and doesn't get any more octets from the agent for 60 seconds, it sends a BFM notification ⏰
- if a session is already established, it also sends an AST notification and closes the connection after sending the BFM notification 👋 otherwise, it closes the connection without sending another message
- once there are enough octets, it reads the transaction identifier and the basic message type 🧠
- if the basic message type field doesn't equal 0x01 (request message), the middlebox stops processing and sends a negative reply of type 'wrong basic request message type' (0x0310) to the agent 🚫
- if no session is established, it closes the connection after sending the 0x0310 reply
- then it checks the message sub-type 🔎
- if no session is established, 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 it
- if a session is already established, it checks whether the 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))
- if not, the middlebox stops processing the message and sends a reply of type 'wrong request message sub-type' (0x0311) to the agent
- then it checks the TLV-structured attributes in the message 🧩
- if their type or number doesn't comply with the defined format for this message type, the middlebox stops processing and sends a reply of type 'badly formed request' (0x0312) to the agent 💀
- if no session is established, it closes the connection after sending the 0x0312 reply
- once all the message format checks pass, the middlebox processes the content of the attributes as described in the following sections 🎀
7. Session Control Message Processing 🦋
okay this is the good part bestie 🍓 for session control, the agent can send SE, SA, and ST request messages. for each request, the middlebox sends back a single reply to the agent ✨ it can also send unsolicited AST notifications whenever it wants 🔔
7.1. Session State Machine 🌈
every session has its own session state machine, and it's 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 machinethe figure shows every possible state transition of a session 💖 request transactions (SE, SA, ST) are written as the request message descriptor, a /, and then the reply message descriptor. notification transactions are just written as the notification descriptor. so a successful SE transaction is SE/SE, and an AST notification is just AST 🙈
every session starts out in state CLOSED 🌸 from there, a successful SE transaction can move it to either NOAUTH or OPEN. from NOAUTH, a successful SA transaction moves the session to OPEN, and a failed SA transaction moves it from NOAUTH back to CLOSED. successful ST transactions and AST notifications move sessions from NOAUTH or from OPEN to CLOSED 💅
a SIMCO session gets established in state OPEN, and OPEN is the only state where the middlebox accepts requests other than SE, SA, and ST ✨
7.2. Processing SE Requests 🧚
the SE request only applies if the session is in state CLOSED 🚪 if the session is in state NOAUTH or OPEN, the middlebox sends a negative reply of type 'request not applicable' (0x0320) to the agent and leaves the session state unchanged 🙃
before it even looks at the SE request content, the middlebox can check its resources and decide they aren't enough to serve the agent 😬 if so, it returns a negative reply of type 'lack of resources' (0x0321) and closes the connection. the middlebox can also decide to reject the SE request if the selected network connection and its protocol-specific parameters aren't acceptable to it 🚧 in that case, it returns a negative reply of type 'transport protocol problem' (0x0325) and closes the connection. and if the security properties of the network connection don't match the middlebox's requirements, it returns a negative reply of type 'security of underlying protocol layers insufficient' (0x0326) and closes the connection 🔐
processing an SE request starts by checking the major and minor protocol version number in the protocol version attribute 🔢 if the middlebox doesn't support the specified version number, it returns a negative reply of type 'protocol version mismatch' (0x0322), with the protocol version attribute showing a version number the middlebox does support. after sending that reply, it closes the connection 👋
if the agent is already sufficiently authenticated through the underlying network connection (for instance, IPsec or TLS), the middlebox checks whether the agent is authorized to configure it 🪪 if not, it returns a negative reply of type 'no authorization' (0x0324) and closes the connection 💔
a positive reply to an SE request can be of sub-type SE or SA 🎀 an SE request is sent after both parties have sufficiently authenticated and authorized each other. an SA reply is sent when explicit authentication is requested by either party. the agent asks for explicit authentication by adding an authentication challenge attribute to the SE request, and the middlebox asks for it by returning an SA reply with an authentication challenge attribute to the agent. if both parties ask for explicit authentication, the SA reply contains both an authentication challenge attribute for the agent and an authentication token attribute that authenticates the middlebox 🫶
if the SE request has an authentication challenge attribute, the middlebox checks whether it can authenticate itself. if it can, it adds a matching authentication token attribute to the SA reply. if it can't authenticate based on that challenge, it adds an authentication token attribute to the SA reply with a value field of length zero 🥺
if the middlebox wants the agent to explicitly authenticate itself, it creates an authentication challenge attribute for the agent and adds it to the SA reply 🔑
if the middlebox replies to the SE request with an SA reply, the session state changes from CLOSED to NO_AUTH 🌙
if the SE request didn't contain an authentication challenge attribute, and the middlebox doesn't ask the agent to explicitly authenticate itself, then the middlebox sends an SE reply in response to the SE request. that means the session state changes from CLOSED to OPEN 🎉
the SE reply contains a capabilities attribute describing the middlebox's capabilities 📋
7.3. Processing SA Requests 🔐
the SA request only applies if the session is in state NOAUTH 🙌 if the session is in state CLOSED or OPEN, the middlebox sends a negative reply of type 'request not applicable' (0x0320) to the agent, and the session state stays the same 🙃
after receiving an SA request in state NOAUTH, the middlebox checks whether the agent is sufficiently authenticated. that can be based on an authentication token attribute, which is optionally included in the SA request 🪙 if the agent isn't sufficiently authenticated, the middlebox returns a negative reply of type 'authentication failed' (0x0323) and closes the connection 😭
if authentication succeeds, the middlebox checks whether the agent is authorized to configure it. if not, it returns a negative reply of type 'no authorization' (0x0324) and closes the connection 🚫
if authorization succeeds, the session state changes from NOAUTH to OPEN 🥳 the agent then returns an SE reply message, which wraps up session setup. the middlebox states its capabilities in the capability attribute contained in that SE reply 🎁
7.4. Processing ST Requests 👋
the ST request only applies if the session is in state NOAUTH or OPEN 💅 if the session is in state CLOSED, the middlebox sends a negative reply of type 'request not applicable' (0x0320) to the agent, and the session state stays unchanged.
the middlebox always replies to a correct ST request with a positive ST reply 💖 the session state changes from OPEN or from NOAUTH to CLOSED. after sending the ST reply, the middlebox closes the connection. any requests that arrive after the ST request and before the connection closes are ignored by the middlebox 🙈
7.5. Generating AST Notifications 🔔
at any time, the middlebox can terminate an established session and change the session state from OPEN or from NOAUTH to CLOSED 💫 session termination is signalled to the agent by sending an AST notification.
before sending the notification, the middlebox makes sure that for every request it has processed, the matching replies have been returned to the agent, so the agent knows exactly what state the middlebox was in when the session ended 🫶 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 🔌💔
okay so [RFC3989] Section 2.2.4 is the part that explains what a session does when the network connection gets cut off 😭 BUT. this only covers the middlebox (aka the SIMCO server) 🫠 it says nothing about what the SIMCO agent does when that happens, so this is the gap we're looking at.
if the SIMCO agent notices the underlying network connection got interrupted, it can terminate the session 💅 there are a bunch of ways it could spot that, like the operating system telling it something or a connection timeout ⏱️ how that detection actually works is totally out of scope for this memo, so we're not going there ✨
8. Policy Rule Control Message Processing ✨
okay this is where it gets spicy 🌶️ for policy rule control and monitoring, the agent can send PRR, PER, PEA, PLC, PRS, and PRL requests 📨 and the middlebox sends back a single reply message for each request. bestie, that's one-to-one, no cap 💖 on top of that, the middlebox may send unsolicited ARE notifications whenever it wants 🦋
the transaction semantics for policy rule control messages are explained in detail in [RFC3989], Section 2.3 🧠 and if you want to see how the protocol actually runs in practice, check out Section 4 of [RFC3989] 🎀
8.1. Policy Rule State Machine 🌈
okay the big idea here is that policy rules get set up through successful PRR, PEA, or PER transactions 💅 every time a new policy rule shows up, it gets an unused policy rule identifier (PID) assigned to it 🆔 and for every PID, there's a state machine living at the middlebox 🤖 here's the whole thing:
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 machinethis figure shows every single state transition a PID and its policy can make 🗺️ successful configuration requests (PER, PRR, PEA, PLC) are written as the request descriptor, then a /, then the reply descriptor 💕 failed ones don't get drawn at all, because they don't change the PID state, so no drama there 🙈 notification transactions are just shown by their own notification descriptor 📣 so a successful PRR is PRR/PRR, and an ARE notification is just ARE ✨ for PLC requests, the request descriptor also gets extended with whatever the lifetime value in the message is 🧚
here's the actual logic, bestie 👑 a successful PRR transaction (PRR/PRR) grabs a PID that's in state UNUSED and moves it to RESERVED 🎀 a successful PER transitions picks a PID in state UNUSED and changes it to ENABLED 💜 a PID in state RESERVED becomes ENABLED after a successful PEA transaction 🦋 if the PID is in RESERVED or UNUSED, a successful PLC transaction with a lifetime greater than zero doesn't change its state at all 🫶 a successful PLC with lifetime exactly zero moves the PID from RESERVED to UNUSED, or from ENABLED to UNUSED 🍓
a failed request transaction does not change state at the middlebox 🙅♀️ and an ARE notification with the lifetime attribute set to zero works the exact same way as a successful PLC transaction with lifetime zero 💀
8.2. Processing PRR Requests 🫧
ngl processing PRR requests is way simpler on pure firewalls than on middleboxes with NAT functions 🔥 so this section is split into three sub-sections 💅 the first one covers the initial checks that happen no matter what, the second covers PRR processing on pure firewalls, and the third covers processing on all devices with NAT functions 🌸
8.2.1. Initial Checks ✅
okay so when a middlebox gets a PRR request message, the very first thing it does is check whether the authenticated agent is authorized to request reservations 🔐 if it isn't, it sends back a negative reply of type 'agent not authorized for this transaction' (0x0341) 🚫
if the request includes the optional group identifier, the middlebox checks whether that group already exists 👀 if it doesn't, the middlebox returns a negative reply of type 'specified policy rule group does not exist' (0x0344) 💔
also if the request has the optional group identifier, the middlebox checks whether the authenticated agent is allowed to add members to that group 🧑🤝🧑 if not, the reply is a negative one of type 'not authorized for accessing specified group' (0x0346) 🙈
next, the middlebox may check the PRR parameter set 🧐 a negative reply of type 'IP version mismatch' (0x034F) comes back if the IPi field doesn't match the inside IP version of the address at the middlebox ✨ and that same 'IP version mismatch' (0x034F) reply also comes back if the IPo field doesn't match the outside IP version of the address at the middlebox 🌈 the requested transport protocol type gets checked too, and if it isn't supported, you get a negative reply of type 'protocol type not supported' (0x0354) 🫠 the middlebox may also send back a negative reply of type 'requested address space not available' (0x0347) if the requested address space is completely blocked or unsupported in any way at all 🚧 for example, if someone asks for a UDP port number and the middlebox is a firewall that blocks all UDP packets, that's a case for this one 🧱
this last check is optional, and here's the tea ☕ if the check would fail and the middlebox doesn't run it during this transaction, then two extra transactions follow, which is so wasteful 😩 first, the agent sends a PER request for the corresponding transaction and gets a negative reply to it 🙃 second, the agent either sends a PLC request with lifetime set to zero to delete the reservation, or the reservation times out and the middlebox sends an ARE notification with lifetime set to zero 🗑️ both of those extra transactions can be avoided if the middlebox does the check up front 💖
a reason someone might skip this check is that it's complicated 🤯 if the check passes, the same check also has to be done again for a later corresponding PEA request 🔁 so if handling two more transactions is considered to use fewer resources than doing the check twice, it might be better not to run it during the PRR transaction 🧠
after the PRR parameter set is checked, the middlebox picks a lifetime value for the new policy rule ⏳ it has to be greater than or equal to zero, and less than or equal to the smaller of the requested value and the maximum lifetime from the middlebox capabilities attribute at session setup 💅 formally, it works out like this:
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)where lt_granted is the actual lifetime the middlebox picks, lt_requested is the lifetime the agent asked for, and lt_maximum is the maximum lifetime that got exchanged during capability exchange at session setup 🫶
if there are other sessions in state OPEN with authenticated agents who are authorized to access the policy rule, then each of those agents gets a matching ARE notification with lifetime set to lt_granted 📣
and if the chosen lifetime is zero, the middlebox sends a negative reply of type 'middlebox configuration failed' (0x034A) back to the agent 💀
8.2.2. Processing on Pure Firewalls 🔥
okay so if the middlebox is set up as a pure firewall, it accepts the request once the initial checks are done 🧱 it sets up a brand-new policy reserve rule and gives it a PID in state RESERVED 🎀 then it generates a positive PRR reply and sets the attributes as described below 💜 no configuration of the firewall function is needed, bestie, which is lowkey the best part ✨
the identifier picked for the new policy rule gets reported in the policy rule identifier attribute of the PRR reply 🆔
if the PRR request has a group identifier attribute, the middlebox adds the new policy rule to the members of that group 👯♀️ if there's no group identifier attribute, the middlebox creates a new group with the new policy rule as its only member 🌸 either way, the group the new policy rule belongs to gets reported in the group identifier attribute of the PRR reply 🫶
the chosen lifetime is reported in the lifetime attribute of the PRR reply ⏳
now for the address tuple (outside) attribute of the PRR reply 🦋 the first parameter field is set to 'protocols only' (0x1), which means the attribute is 32 bits long 📏 the IP version parameter field gets 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 exactly the same as the transport protocol attribute in the PRR parameter set attribute of the PRR request message 🍓 and the location parameter field is set to 'outside' (0x02) 💅
8.2.3. Processing on Network Address Translators 🦋
Okay so if the middlebox is set up as a Network Address Translator (NAT), 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. If the configuration isn't matched, the middlebox returns a negative reply of type 'NAT mode not supported' (0x034E) 🙈
The actions depend 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 gets reported in the policy rule identifier attribute of the PRR reply 🎀
Once the checks pass, the middlebox sets up a new policy reserve rule with the requested PRR parameter set and gives it a policy rule identifier in state RESERVED. Then it generates a positive PRR reply and sets the attributes as described below ✨
If the PRR request has a group identifier attribute, the middlebox adds the new policy rule to the members of that group. If the PRR request doesn't have a group identifier attribute, the middlebox creates a brand new group with the new policy rule as its only member. Either way, the middlebox reports the group the new policy rule belongs to in the group identifier attribute of the PRR reply 👑
The chosen lifetime gets reported in the lifetime attribute of the PRR reply ⏳
For 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 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 goes 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 goes 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 (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 doesn't contain an address tuple (inside) attribute. Otherwise (it has the value 'twice'), the PRR reply message does contain 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 goes 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 goes 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 (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 way simpler on pure firewalls than on middleboxes with NAT functions 💅 So this section has three sub-sections. The first one describes initial checks that happen 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.
8.3.1. Initial Checks 🔍
When a middlebox receives a PER request message, it first checks whether the authenticated agent is authorized to request 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, the middlebox checks whether the group already exists. If it doesn't, 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, the middlebox checks whether the authenticated agent is authorized to add 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 doesn't have the location parameter field set to 'internal' (0x00), or if the second one doesn't 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 doesn't 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 whether wildcarding is requested and whether 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 to0x00, 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 wildcarded according to this prefix length. If the IP version number field indicates IPv6 and the value of this field is less than0x80, then IP addresses are wildcarded 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 this conflicts with the 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) ⚠️
After checking the address tuple attributes, the middlebox chooses a lifetime value for the new policy rule to be created. This value 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 a corresponding ARE notification with lifetime set to lt_granted is sent to each of these agents 📣
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 ✨
okay so if the middlebox is acting as a pure firewall, it tries to set up the requested pinhole 🦋 the firewall config ignores the port parity parameter field in the PER parameter set attribute, but it does pay attention to the direction parameter field in that same attribute 💅 the pinhole gets configured so communication between the specified internal and external address tuples is enabled in the specified direction, covering the specified wildcarding 🎀 and if the configuration fails (like, say, the pinhole would clash with high-level firewall policies 💀), the middlebox sends back a negative reply of type 'middlebox configuration failed' (0x034A) 😭
if the configuration works, the middlebox creates a new policy enable rule and gives it a policy rule identifier in state ENABLED 🌸 then it generates a positive PER reply and fills in the attributes as described below 🫶
the identifier it picked for the new rule gets reported in the policy rule identifier attribute of the PER reply ✨
if the PER request has a group identifier attribute, the middlebox adds the new policy rule to the members of that group 🧚 if the PRR request doesn't have a group identifier attribute (yes, the original says PRR here, not PER 🙈), then the middlebox makes a brand new group with the new policy rule as its only member 👑 either way, the middlebox reports the group the new rule belongs to in the group identifier attribute of the PER reply 💜
the chosen lifetime gets reported in the lifetime attribute of the PER reply ⭐
the address tuple (internal) attribute of the PER request gets reported as the address tuple (outside) attribute of the PER reply 🍓 and the address tuple (external) attribute of the PER request gets reported as the address tuple (inside) attribute of the PER reply 🦋
8.3.3. Processing on Network Address Translators 🌈
if the middlebox is set up as a NAT, it tries to configure the requested NAT binding 💖 the NAT's actions are pretty similar to what happens for a Policy Reserve Rule (PRR) request, except that in a PER request, a NAT binding gets enabled 🔥
the following actions happen, depending on the middlebox NAT type:
- traditional NAT
- a NAT binding gets established between the internal and external address tuple with the requested transport protocol, port range, direction, and port parity 🌸 the outside address tuple gets created too ✨
- twice NAT
- a NAT binding gets established between the internal and external address tuple with the requested transport protocol, port range, and port parity 🎀 but this time two address tuples get created: an outside address tuple and an inside address tuple 👑
if the configuration fails in either NAT case, a negative reply 'middlebox configuration failed' (0x034A) comes back 😭
if the configuration works, the middlebox creates a new policy enable rule and gives 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 🧚
same vibe for groups: if the PER request has a group identifier attribute, the middlebox adds the new policy rule to that group's members 💜 if the PRR request doesn't contain a group identifier attribute (the original says PRR again, sorry bestie 🙈), the middlebox creates a new group with the new policy rule as the only member 🍓 either way, the group the new rule is in gets reported in the group identifier attribute of the PER reply ⭐
the chosen lifetime is reported in the lifetime attribute of the PER reply 🌈
now for the address tuple (outside) attribute of the PER reply, and this part is very detailed, so stay with me 🤓:
- 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
0x20to 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
0x80to 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 (that's 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 gets omitted 💜 when it is returned, here's how it looks 💅:
- 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
0x20to 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
0x80to 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 (again, 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.4. Processing on Combined Firewalls and NATs 🔥
middleboxes that combine firewalls and NATs are configured so that the NAT bindings get set up first, and the firewall pinholes come afterwards 🧚 the reason is that the firewall rules have to be configured according to the outside address tuples, and for twice NATs, the inside address tuples too 👑
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 way simpler on pure firewalls than on middleboxes with NAT functions 🫶 so this section has three sub-sections ✨: the first one describes the initial checks that get performed in any case 💖, the second sub-section covers processing PEA requests on pure firewalls 🦋, and the third one covers processing on all devices with NAT functions 🌈
8.4.1. Initial Checks ✨
okay so when a middlebox gets a PEA request, the very first thing it does is check if the authenticated agent is even allowed to ask for middlebox configurations that enable communication 💅. If not, it sends back a negative reply of type agent not authorized for this transaction (0x0341). bouncer energy 🚪
Next it checks the policy rule identifier attribute in the PEA message. If there's no policy rule with that identifier, the reply is specified policy rule does not exist (0x0343). If the policy does exist but it's in a state other than RESERVED, the reply is inconsistent request (0x034B) 🙈
If the policy rule exists but the authenticated agent isn't authorized for terminating this policy reserve rule, the reply is agent not authorized for accessing this policy (0x0345) 🔒
Then it's time for the address tuple attributes 👀. If the first one doesn't have its location parameter field set to internal (0x00), or the second one doesn't have its location parameter field set to external (0x03), the reply is inconsistent request (0x034B). Same deal if the transport protocol parameter field doesn't have the same value in both address tuple attributes.
Port range check, bestie: if both address tuple attributes contain a port range parameter field, both of those fields have values not equal to 0xFFFF, and those values are different from each other, the reply is inconsistent request (0x034B) again 🫶
Now the agent checks whether wildcarding is requested and whether the middlebox actually supports the wildcarding that's asked for. Support can be different for internal and external address tuples 🧚 These parameter fields of the address tuple attribute can signal wildcarding:
- the first parameter field If it's set to
protocols only(0x1), then IP addresses and port numbers are completely wildcarded. slay 💖 - the transport protocol field If it's set to 0x00, then the transport protocol is completely wildcarded. Heads up though: a completely wildcarded transport protocol might still only support a limited set of transport protocols, depending on what the middlebox can do. 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 says IPv4 and this value is less than 0x20, then IP addresses are wildcarded according to this prefix length. If the IP version number field says IPv6 and this value is less than 0x80, then IP addresses are wildcarded according to this prefix length too. If the first parameter field is set to
protocols only(0x1), then the prefix length field doesn't matter at all 🌸 - the port number field If it's set to zero, then port numbers are completely wildcarded 🍓
- the port range field If it's set to a value greater than one, then port numbers are wildcarded within an interval that starts at the specified port number and contains as many consecutive port numbers as the parameter says ✨
If any of these kinds of wildcarding is used, and it conflicts with the wildcarding support for internal or external addresses of the middlebox, the reply is requested wildcarding not supported (0x034C) 💀
If the PEA request conflicts with any policy disable rule (see Section 8.8.1), the reply is conflict with existing rule (0x0350) 😭
After the address tuple checks, the middlebox picks a lifetime for the new policy enable rule. It has to be greater than or equal to zero, and less than or equal to the smaller of the requested value and the maximum lifetime from the middlebox capabilities attribute at session setup. The formal version is:
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)Where lt_granted is the actual lifetime the middlebox chooses, lt_requested is the lifetime the agent asked for, and lt_maximum is the maximum lifetime set during capability exchange at session setup 🎀
If there are further sessions in state OPEN with authenticated agents authorized to access the policy rule, each of those agents gets a corresponding ARE notification with lifetime set to lt_granted 📣
And 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, it tries to configure the requested pinhole. The firewall configuration ignores the port parity parameter field in the PER parameter set attribute, but it does consider the direction parameter field in that attribute 👑 The pinhole gets configured so that communication between the specified internal and external address tuples is enabled in the specified direction and covers the specified wildcarding. If the configuration fails, the reply is middlebox configuration failed (0x034A) 😩
If the configuration works, the middlebox swaps the policy reserve rule (the one referenced by the policy rule identifier attribute in the PEA request) with a brand new policy enable rule. The new rule re-uses the policy rule identifier of the replaced policy reserve rule, and that identifier's state changes from RESERVED to ENABLED. The policy enable rule stays in the same group the replaced policy reserve rule was in 🧩
Then the middlebox generates a positive PER reply and sets the attributes like this:
- the chosen identifier for the new policy rule goes in the policy rule identifier attribute of the PER reply
- the group identifier goes in the group identifier attribute of the PER reply
- the chosen lifetime goes 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, it tries to configure the requested NAT binding, which basically means enabling the binding that was already reserved. The already reserved NAT binding from the PRR request now gets enabled in the middlebox 🦋
If the enable configuration works, the middlebox swaps the policy reserve rule (again, the one referenced by the policy rule identifier attribute in the PEA request) for a new policy enable rule. Same vibes as before: the new rule re-uses the replaced rule's identifier, the state goes from RESERVED to ENABLED, and the rule stays in the same group 🫧
Then the middlebox generates a positive PER reply and sets the attributes:
- 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 come from the reserve policy rule that was generated during the PRR transaction 💜
8.5. Processing PLC Requests 🎀
When a middlebox gets a PLC request, it first checks if the authenticated agent is authorized to request policy rule lifetime changes. If not, the reply is agent not authorized for this transaction (0x0341) 🚫
Then the middlebox checks the policy rule identifier attribute in the PLC message. If no policy rule with this identifier exists, the reply is specified policy rule does not exist (0x0343) 🫠
If a policy rule with this identifier exists, but the authenticated agent isn't authorized to change the lifetime of this policy rule, the reply is agent not authorized for accessing this policy (0x0345) 🔐
Next, the middlebox picks a lifetime for the new policy rule. It has to be greater than zero and less than or equal to the smaller of the requested value and the maximum lifetime from the middlebox capabilities attribute at session setup. The formal version is:
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)Where lt_granted is the actual lifetime the middlebox chooses, lt_requested is the lifetime the agent asked for, and lt_maximum is the maximum lifetime set during capability exchange at session setup. This procedure means 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 that message 🌷
Otherwise (the chosen lifetime is zero), 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, each of those agents gets a corresponding ARE notification with lifetime set to zero 💅
8.6. Processing PRS Requests ✨
okay so when a middlebox gets a PRS request, the very first thing it checks is whether the authenticated agent is authorized to receive policy status info 👀. If not, it sends back a negative reply of type 'agent not authorized for this transaction' (0x0341). nope nope 🙅♀️
Next, it looks at the policy rule identifier attribute in the PRS message. If no policy rule with that identifier is in state RESERVED or ENABLED, the middlebox returns a negative reply of type 'specified policy rule does not exist' (0x0343). ghosted 💀
If the rule does exist, but the agent isn't allowed to see status info for it, the middlebox returns a negative reply of type 'agent not authorized for accessing this policy' (0x0345). not the vibe 🙈
If the checks above all pass, the middlebox accepts the request and generates a reply. If the rule is in state RESERVED, it generates a PRS reply and sends it to the agent. Otherwise (the rule is in state ENABLED), it generates a PES reply and sends that. For policy disable rules, a PDS reply is generated and sent to the agent. the way the reply type changes with the rule's state 🦋
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 being asked about. 🎀
The PRS reply is basically the PRR reply with one extra owner attribute tacked on the end. For the attributes it shares with the PRR reply (except lifetime), the values are exactly the same as in the PRR reply that was sent during the PRR transaction that set up the policy reserve rule. twinning 👯♀️
For the PES reply, the PER parameter set attribute, the address tuple (internal) attribute, and the address tuple (external) attribute have exactly the same values as the matching attributes in the PER or PEA request from the transaction that set up the policy enable rule. ✨
The PES reply's policy rule identifier attribute, group identifier attribute, address tuple (inside) attribute, and address tuple (outside) attribute also match exactly, this time with the PER reply from the PER or PEA transaction that set up the rule. consistency is everything 💅
For the PDS reply, the policy rule identifier attribute, address tuple (internal) attribute, and address tuple (external) attribute match exactly the values in the PDR request message. 🌸
And the big one: this transaction does not change the state of any policy rule. just looking, not touching 👀🫶
8.7. Processing PRL Requests
okay bestie, when a middlebox gets a PRL request, it first checks if the authenticated agent is authorized to receive policy information. if not, it sends back a negative reply of type 'agent not authorized for this transaction' (0x0341). 🙅♀️
if the agent is cleared, the middlebox builds a PRL reply. for every policy rule at the middlebox that is in state RESERVED or ENABLED and that the agent can access, a policy rule identifier attribute gets generated and added to the PRL reply before it's sent off. 🧚
but here's the catch 😭: if the number of policy rule attributes being returned is bigger than the maximum transport unit size of the underlying network connection, or bigger than the maximum length of a SIMCO message, the middlebox generates a negative reply of type 'reply message too big' (0x0313) instead. way too much to carry 💀
a SIMCO message can be at most 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
okay so processing PDR requests is split into five sub-sections 🍓. the first one explains how PDR extends the MIDCOM protocol semantics. the second covers the initial checks that happen every single time. the third is about processing PDR requests on pure firewalls. the fourth covers devices with NATs, and the fifth covers devices that combine firewall and NAT functions. a whole plan 📋✨
8.8.1. Extending the MIDCOM semantics
the Policy Disable Rule (PDR) adds another policy rule type on top of the MIDCOM protocol semantics [RFC3989]. it's meant for dynamically blocking unwanted traffic, especially during an attack, like a distributed denial of service attack. big protective energy 🛡️👑
PDR requests follow the same ownership concept as every other transaction (see [RFC3989], Section 2.1.5). however, PDR prioritization over PERs does not depend on ownership. a PDR always overrules a conflicting PER, even if the owners are different. typically, only a highly privileged agent gets to issue PDR requests. 👑🔥
a PDR rule and a PER rule conflict with each other if their address tuples overlap in a way that at least one IP packet matches address tuple A0 of both rules in the internal network and matches address tuple A3 of both rules in the external network. fun fact: the packet may be translated from the internal to the external network, or vice versa. 🦋
let's say 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 that 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 }so if a new PDR gets established, all conflicting PERS are terminated immediately. ✂️ and a new PER can only be established if it doesn't conflict with any PDR that already exists. no PER sneaking past a PDR 🙅♀️🌸
8.8.2. Initial Checks
when a middlebox gets a PDR request message, it first checks if the authenticated agent is authorized to request middlebox configurations for disabling communication. if not, it returns a negative reply of type 'agent not authorized for this transaction' (0x0341). 🙅♀️
next, the middlebox checks the address tuple attributes it contains. 🔍
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), the middlebox returns a negative reply of type 'inconsistent request' (0x034B). mismatched 😭
if the transport protocol parameter field doesn't have the same value in both address tuple attributes, the middlebox returns a negative reply of type 'inconsistent request' (0x034B). both sides gotta match 💅
if both address tuple attributes contain a port range parameter field, if both port range parameter fields have values that are not equal to 0xFFFF, and if the values of both port range parameter fields are different, the middlebox returns a negative reply of type 'inconsistent request' (0x034B). three conditions all at once, that's a lot of drama 🎭
then the agent checks whether wildcarding is requested and whether the requested wildcarding is supported by the middlebox. wildcarding support can 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. heads up: a completely wildcarded transport protocol might still only support a limited set of transport protocols, depending on what the middlebox can do. 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 to0x00, 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 wildcarded according to this prefix length. if the IP version number field indicates IPv6 and the value of this field is less than0x80, then IP addresses are wildcarded 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 are used, and that conflicts with the wildcarding support for the internal or external addresses of the middlebox, the middlebox returns a negative reply of type 'requested wildcarding not supported' (0x034C). 🙃
quick PSA 📣: the port range field can't be used for wildcarding. if it's set to a value greater than one, then middlebox configuration is requested for all port numbers in the interval that starts at the specified port number and contains as many consecutive port numbers as the parameter specifies. 🔢✨
the specified policy disable rule is activated, and the middlebox terminates 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 being terminated get notified via the ARE notification. 📨
the middlebox rejects all requests for new policy enable rules that conflict with the just-established PDR for as long as the PDR isn't terminated. in that case, it generates a negative 'conflict with existing rule' (0x0350) reply. blocked, babe 🚫💅
after checking the address tuple attributes, the middlebox picks a lifetime for the new policy rule. that lifetime has to be greater than or equal to zero and less than or equal to the smaller of the requested value and the maximum lifetime given in the middlebox capabilities attribute at session setup. formally, it looks like this:
0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)here, 'lt_granted' is the actual lifetime the middlebox chooses, 'lt_requested' is the lifetime the agent asked for, and 'lt_maximum' is the maximum lifetime specified during capability exchange at session setup. 🧮💖
if there are other sessions in state OPEN with authenticated agents that are authorized to access the policy rule, then each of those agents gets a matching ARE notification with the lifetime set to lt_granted. 📬🌈
and if the chosen lifetime is zero, the middlebox sends the agent a negative reply of type 'middlebox configuration failed' (0x034A). zero lifetime, zero chance 💀
8.8.3. Processing on Pure Firewalls ✨
Okay bestie, so if the middlebox is acting as a pure firewall, it tries to set up the requested disable rule 🚫. That means configuring a blocking rule at the firewall. The disable rule is built so that communication between the specified internal and external address tuples is blocked, covering the specified wildcarding 🦋. If the configuration fails (for example, the blocking rule would clash with high-level firewall policies 💀), the middlebox sends back a negative reply message of type 'middlebox configuration failed' (0x034A). Rip 😭
If the configuration works 💅, the middlebox sets up a brand new policy disable rule and gives 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 gets reported in the policy rule identifier attribute of the PDR reply 🎀.
The chosen lifetime gets 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, 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. That's a no-go 🙈.
If the configuration was successful, the middlebox establishes a new policy disable rule and assigns 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.5. Processing on Combined Firewalls and NATs 💜
Middleboxes that are combinations of firewall and NAT are configured in a specific order. First the firewall gets 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. It does this by deleting the configuration of the rule and 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, then 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, so it's giving ghosted 👻.
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 the other agents stay synchronized with the latest state of the policy rules. Everyone stays on the same page 📚🫶.
9. Security Considerations 🚨
9.1. Possible Threats to SIMCO 😱
Okay, this section is serious, so buckle up 🎢. Middleboxes, such as firewalls and NATs, are usually operated to improve network security and to extend the IP address space. (Note that stand-alone NATs are not considered to improve security; see [RFC2663].) Configuring middleboxes from an external entity looks quite counterproductive at first glimpse, since an attacker using this can possibly configure the middlebox in such a way that no filtering is applied anymore, or that NAT bindings are configured for malicious use. So the middlebox is not performing its intended function anymore. Possible threats to SIMCO are:
- Man-in-the-middle attack: A malicious host intercepts messages exchanged between the 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 some 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 🛡️.
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 the 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 💕.
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.
- [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.comFull 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 💅
okay so the IETF is NOT taking a position on whether any IPR (intellectual property rights) claimed on the tech in this doc are valid or how far they reach 🙈 and it isn't saying it went looking for any of that either. if you want the rules for rights in RFC docs, check out BCP 78 and BCP 79 📚
copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses that might be made available, or the results of an attempt to get a general license or permission for implementers or users of this spec can all be found in the IETF online IPR repository at http://www.ietf.org/ipr 🔍✨
and if you know about any copyrights, patents, patent applications, or other proprietary rights that may cover tech needed to implement this standard, the IETF invites you to spill the tea! send it to ietf-ipr@ietf.org 💌🫖
Acknowledgement 🫶
funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA) 💜 ily IASA, you keep the lights on 🌈✨
📦 where this page comes from
- ietf: rfc4540 2006-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms