RFC 4712
Transport Mappings for Real-time Application Quality-of-Service Monitoring (RAQMON) Protocol Data Unit (PDU)
RFC 4712 💖 Transport Mappings for Real-time Application Quality-of-Service Monitoring (RAQMON) Protocol Data Unit (PDU)
okay bestie, so this is the spec for how RAQMON PDUs actually travel between devices 🎀 Here's the title block lowkey explained 👇
- Number: RFC 4712
- Title: Transport Mappings for Real-time Application Quality-of-Service Monitoring (RAQMON) Protocol Data Unit (PDU)
- Stream: Network Working Group
- Category: Standards Track ✨
- Date: October 2006
- Authors: A. Siddiqui and D. Romascanu (both Avaya), E. Golovinsky (Alert Logic), M. Rahman (Samsung Information Systems America), and Y. Kim (Broadcom) 🫶
- Obsoletes / Updates: the title block doesn't list anything it obsoletes or updates 🦋
Status of This Memo
this one is an Internet standards track protocol for the Internet community, and it's basically asking everyone for discussion and suggestions to make it better 🌸 For the standardization state and status, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited, so share away 💅
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
okay so this memo spells out two transport mappings for the Real-Time Application Quality-of-Service Monitoring (RAQMON) information model from RFC 4710 🧚 One uses TCP as a native transport, and the other uses the Simple Network Management Protocol (SNMP) to carry RAQMON information from a RAQMON Data Source (RDS) over to a RAQMON Report Collector (RRC). Iconic transport content 😭
Table of Contents
1. Introduction ....................................................3
2. Transporting RAQMON Protocol Data Units .........................3
2.1. TCP as an RDS/RRC Network Transport Protocol ...............3
2.1.1. The RAQMON PDU ......................................5
2.1.2. The BASIC Part of the RAQMON Protocol Data Unit .....7
2.1.3. APP Part of the RAQMON Protocol Data Unit ..........14
2.1.4. Byte Order, Alignment, and Time Format of
RAQMON PDUs ........................................15
2.2. Securing RAQMON Session ...................................15
2.2.1. Sequencing of the Start TLS Operation ..............18
2.2.2. Closing a TLS Connection ...........................21
2.3. SNMP Notifications as an RDS/RRC Network Transport
Protocol ..................................................22
3. IANA Considerations ............................................38
4. Congestion-Safe RAQMON Operation ...............................38
5. Acknowledgements ...............................................39
6. Security Considerations ........................................39
6.1. Usage of TLS with RAQMON ..................................41
6.1.1. Confidentiality & Message Integrity ................41
6.1.2. TLS CipherSuites ...................................41
6.1.3. RAQMON Authorization State .........................42
7. References .....................................................43
7.1. Normative References ......................................43
7.2. Informative References ....................................44
Appendix A. Pseudocode ............................................461. Introduction ✨
the Real-Time Application QoS Monitoring (RAQMON) Framework, as outlined in [RFC4710], extends the Remote Monitoring family of protocols (RMON) 🍓 It does this by defining entities like RAQMON Data Sources (RDS) and RAQMON Report Collectors (RRC) that do various application monitoring in real time. [RFC4710] defines the relevant metrics for RAQMON monitoring, which ride along in the common protocol data unit (PDU) that an RDS and RRC use to report QoS statistics. This memo is where the syntax of the RAQMON PDU structure gets described, so it's the bit that tells you exactly how the bytes look 👑
the detailed specs for using TCP and SNMP to carry RAQMON information come in the sections that follow 🦋
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. (this part is super important, periodt 💅)
2. Transporting RAQMON Protocol Data Units 🌈
the RAQMON Protocol Data Unit (PDU) uses a common data format that both the RDS and the RRC understand 🫶 A RAQMON PDU doesn't carry application data. Instead, it sits in the spot of a payload specification at the application layer of the protocol stack. This memo also specifies using TCP and SNMP as the underlying transport protocols that carry RAQMON PDUs between RDSs and RRCs. There are two transport choices for RDS implementers to pick from, but the RRC side is strict: RRCs MUST implement the TCP transport and MAY implement the SNMP transport. Main character energy from TCP, no cap 😭
2.1. TCP as an RDS/RRC Network Transport Protocol 🎀
the TCP binding is in the RAQMON spec so devices can report stuff from all kinds of embedded gadgets running stuff like Voice over IP, Voice over Wi-Fi, Fax over IP, Video over IP, Instant Messaging (IM), E-mail, software download apps, e-business style transactions, and web access from wired or wireless computing devices, etc. ✨ For a lot of these devices, PDUs plus a TCP-based transport are exactly what the deployment needs 🧚
the RAQMON transport requirements for end-to-end congestion control and reliability are built right into TCP as a transport protocol [RFC793]. It's giving "already handled" energy 💅
to use TCP to transport RAQMON PDUs, you just send the PDUs as TCP data. Every PDU carries its own length, so the receiver can figure out where each PDU starts and stops 🦋
the next section details the RAQMON PDU specifications. Even though it's transmitted as one Protocol Data Unit, a RAQMON PDU is functionally split into two parts: the BASIC part and application extensions for vendor-specific extension [RFC4710] 🌸 Both functional parts come after a field carrying an SMI Network Management Private Enterprise code. That code is currently maintained by IANA at http://www.iana.org/assignments/enterprise-numbers, and it identifies the organization that defined the information carried in the PDU 👑
A RAQMON PDU in the current version is marked as PDU Type (PDT) = 1. The parameters a RAQMON PDU carries are shown in Figure 1 and defined in section 5 of [RFC4710] 🍓
Vendors MUST use the BASIC part of the PDU to report the parameters pre-listed in this specification, for interoperability, instead of the application-specific portion 🫶 Vendors MAY also use application-specific extensions to convey application-, vendor-, or device-specific parameters that aren't in the BASIC part, but they have to explicitly publish that data externally to get extended interoperability. Lowkey the most important rule in this whole section 🔥
2.1.1. The RAQMON PDU ✨
okay bestie, here's the whole RAQMON PDU laid out 🦋 it's a lot, I know 😭 but the picture is worth it
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PDT = 1 |B| T |P|S|R| RC | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMI Enterprise Code = 0 |Report Type = 0| RC_N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |flag
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Source Address {DA} |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver's Address (RA) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP Timestamp, most significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP Timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Application Name (AN) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Data Source Name (DN) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Receiver's Name (RN) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Session State ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Round-Trip End-to-End Network Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| One-Way End-to-End Network Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cumulative Packet Loss |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cumulative Application Packet Discard |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total # Application Packets sent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total # Application Packets received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total # Application Octets sent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total # Application Octets received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Source Device Port Used | Receiver Device Port Used |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S_Layer2 | S_Layer3 | S_Layer2 | S_Layer3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Source Payload |Receiver | CPU | Memory |
|Type |Payload Type | Utilization | Utilization |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Setup Delay | Application Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Packet Delay Variation | Inter arrival Jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Discrd | Packet loss | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMI Enterprise Code = "xxx" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Report Type = "yyy" | Length of Application Part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| application/vendor specific extension |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ............... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ............... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ............... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMI Enterprise Code = "abc" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Report Type = "zzz" | Length of Application Part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| application/vendor specific extension |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ............... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 1: RAQMON Protocol Data Unit
2.1.2. The BASIC Part of the RAQMON Protocol Data Unit 💅
A RAQMON PDU must contain the following BASIC part fields at all times 🫶 so these are the non-negotiable bits:
- PDU type (PDT): 5 bits - This tells you what kind of RAQMON PDU is being sent. PDT = 1 is the one for the current RAQMON PDU version defined in this document ✨
- basic (B): 1 bit - When it's set to 1, the basic flag says the PDU has the BASIC part of the RAQMON PDU. A value of zero is valid too and means a RAQMON NULL PDU 🌸
- trailer (T): 3 bits - This is the total number of Application-Specific Extensions that follow the BASIC part of the RAQMON PDU. Zero is valid as many times as there's no application-specific info to add to the basic information 🎀
- padding (P): 1 bit - When the padding bit is set, the BASIC part has some extra padding octets at the end that aren't part of the monitoring information. Padding might be needed in some cases, since reporting depends on what an RDS intends to report. Also, some parameters only get reported once at the start of the reporting session, like Data Source Name, Receiver Name, payload type, etc. Real padding at the end of the BASIC part is 0, 8, 16, or 24 bits, so the BASIC part's length ends up a multiple of 32 bits 🧚
- Source IP version Flag (S): 1 bit - When this is set to 1, it means the Source IP address in the PDU is an IPv6 address 🦋
- Receiver IP version Flag (R): 1 bit - When this is set to 1, it means the receiver IP address in the PDU is an IPv6 address 🦋
- record count (RC): 4 bits - The total number of application records in the BASIC part of the PDU. Zero is valid but kinda useless, except for a NULL PDU that marks the end of an RDS reporting session 💀
- length: 16 bits (unsigned integer) - The length of the BASIC part of the RAQMON PDU in units of 32-bit words minus one. This count includes the header and any padding 🍓
- DSRC: 32 bits - The Data Source identifier is a unique RAQMON reporting session descriptor. It points to one specific reporting session between RDS and RRC. DSRC is only unique within a reporting session. DSRC values should be randomly generated using vendor-chosen algorithms for each communication session. Calling random() without carefully initializing the state is not enough to get a DSRC. You could use an algorithm like the one in Appendix A.6 in [RFC3550] to create a DSRC. Depending on the algorithm, there's a finite chance that two DSRCs from two different RDSs end up the same. To lower the odds that two RDSs pick the same DSRC for two different reporting sessions, it is recommended that an RRC use parameters like Data Source Address (DA), Data Source Name (DN), and layer 2 Media Access Control (MAC) Address in the PDU together with a DSRC value. RDSs aren't required to send parameters like Data Source Address (DA), Data Source Name (DN), and MAC Address in every PDU sent to RRC, but sending them now and then cuts the chance of a DSRC collision a lot. The catch is that it adds overhead to each PDU 😭
A value of zero for the basic (B) bit and trailer (T) bits makes a RAQMON NULL PDU, which means nothing to report. RDSs MUST send a RAQMON NULL PDU to RRC to indicate the end of the RDS reporting session 🙈 A NULL PDU ends with the DSRC field.
- SMI Enterprise Code: 16 bits - A value of SMI Enterprise Code = 0 is used to indicate the RMON-WG-compliant BASIC part of the RAQMON PDU format 👑
- Report Type: 8 bits - These bits are reserved by the IETF RMON Working Group. A value of 0 within SMI Enterprise Code = 0 is used for the version of the PDU defined by this document 💜
The BASIC part of each RAQMON PDU consists of Record Count Number (RC_N) and RAQMON Parameter Presence Flags (RPPF). Together they indicate which RAQMON parameters are present in a record, as defined in Table 1 ✨
- RC_N: 8 bits - The Record Count number shows a sub-session within a communication session. A value of zero is a valid record number. The maximum number of records that can be described in one RAQMON Packet is 256 🌈
- RAQMON Parameter Presence Flags (RPPF): 32 bits - Each of these flags, while set, means this RAQMON PDU contains the corresponding parameters listed in Table 1 🔥
+----------------+--------------------------------------------------+
| Bit Sequence | Presence/Absence of corresponding Parameter |
| Number | within this RAQMON PDU |
+----------------+--------------------------------------------------+
| 0 | Data Source Address (DA) |
| | |
| 1 | Receiver Address (RA) |
| | |
| 2 | NTP Timestamp |
| | |
| 3 | Application Name |
| | |
| 4 | Data Source Name (DN) |
| | |
| 5 | Receiver Name (RN) |
| | |
| 6 | Session Setup Status |
| | |
| 7 | Session Duration |
| | |
| 8 | Round-Trip End-to-End Net Delay (RTT) |
| | |
| 9 | One-Way End-to-End Network Delay (OWD) |
| | |
| 10 | Cumulative Packets Loss |
| | |
| 11 | Cumulative Packets Discards |
| | |
| 12 | Total number of App Packets sent |
| | |
| 13 | Total number of App Packets received |
| | |
| 14 | Total number of App Octets sent |
| | |
| 15 | Total number of App Octets received |
| | |
| 16 | Data Source Device Port Used |
| | |
| 17 | Receiver Device Port Used |
| | |
| 18 | Source Layer 2 Priority |
| | |
| 19 | Source Layer 3 Priority |
| | |
| 20 | Destination Layer 2 Priority |
| | |
| 21 | Destination Layer 3 Priority |
| | |
| 22 | Source Payload Type |
| | |
| 23 | Receiver Payload Type |
| | |
| 24 | CPU Utilization |
| | |
| 25 | Memory Utilization |
| | |
| 26 | Session Setup Delay |
| | |
| 27 | Application Delay |
| | |
| 28 | IP Packet Delay Variation |
| | |
| 29 | Inter arrival Jitter |
| | |
| 30 | Packet Discard (in fraction) |
| | |
| 31 | Packet Loss (in fraction) |
+----------------+--------------------------------------------------+
Table 1: RAQMON Parameters and Corresponding RPPFOkay bestie, now let's go through each parameter in that table, because every single one has its own little personality 💅✨
Data Source Address (DA) 🌸: This is 32 bits or 160 bits in binary representation. It's defined in section 5.1 of [RFC4710]. IPv6 addresses get tucked into the Data Source Address by setting the source IP version flag (S bit) of the RAQMON PDU header to 1. So the S bit is the thing that tells everyone "hey, this one's IPv6, no cap" 🦋
Receiver Address (RA) 💜: Also 32 bits or 160 bits. This one's defined in section 5.2 of [RFC4710] and follows the exact same syntax as Data Source Address, it's just being used to show the Receiver Address instead. IPv6 addresses go in here when the receiver IP version flag (R bit) of the RAQMON PDU header is set to 1. Twins, but make it networking 👯♀️
Session Setup Date/Time (NTP timestamp) ⏰: This is 64 bits, defined in section 5.7 of [RFC4710], and it's written using the timestamp format of the Network Time Protocol (NTP), which counts in seconds [RFC1305]. The full resolution NTP timestamp is a 64-bit unsigned fixed-point number. The integer part lives in the first 32 bits and the fractional part lives in the last 32 bits. Iconic precision, honestly 🔥
Application Name 🎀: This one's defined in section 5.32 of [RFC4710]. The Application Name field starts with an 8-bit octet count that tells you how long the text is, and then the text itself follows, encoded in UTF-8. The whole field has to be a multiple of 32 bits, and padding gets added when it's needed to make that happen 🧚
A Data Source that does not support NTP SHOULD set the appropriate RAQMON flag to 0 so it doesn't waste 64 bits in the PDU. Like, why waste the space when you don't need it? 🙈 And since the NTP timestamp is really meant to show when a session was set up, it is RECOMMENDED that the NTP Timestamp only shows up in the first RAQMON PDU after sub-session RC_N setup is completed. That's how you keep network resources efficient, and that's giving responsible network energy 🌈
Data Source Name (DN) 🍓: Defined in section 5.3 of [RFC4710]. The Data Source Name field starts with an 8-bit octet count for the length of the text, followed by the text itself. Padding makes sure the length and text encoding come out to a multiple of 32 bits in the DN field of the PDU. The text MUST NOT be longer than 255 octets. It's encoded with UTF-8 as specified in [RFC3629]. Applications SHOULD tell RDSs to send out the Data Source Name infrequently, because this parameter is expected to stay the same for the whole reporting session, and that keeps network resources efficient 💖
Receiver Name (RN) 🦋: This metric is defined in section 5.4 of [RFC4710]. Just like Data Source Name, the Receiver Name field starts with an 8-bit octet count for the length of the text, then the text itself. The Receiver Name, length field included, is a multiple of 32 bits and follows the same padding rules as the Data Source Name. Since the Receiver Name is expected to stay constant for the entire reporting session, this info SHOULD be sent out occasionally over random time intervals. That helps maximize the chance of reaching an RRC and also saves bandwidth. Strategic, bestie 🧠✨
Session Setup Status 🌷: Defined in section 5.10 of [RFC4710]. This field starts with an 8-bit length field, followed by the text itself, and the Session Setup Status is a multiple of 32 bits 💜
Session Duration ⏳: 32 bits. This one's defined in section 5.9 of [RFC4710] and it's an unsigned integer expressed in seconds ⭐
Round-Trip End-to-End Network Delay 🏓: 32 bits. Defined in section 5.11 of [RFC4710], this field shows the Round-Trip End-to-End Delay of sub-session RC_N. It's an unsigned integer expressed in milliseconds 🔥
One-Way End-to-End Network Delay 📨: 32 bits. Defined in section 5.12 of [RFC4710], this field represents the One-Way End-to-End Delay of sub-session RC_N. It's also an unsigned integer in milliseconds 💅
Cumulative Application Packet Loss 📉: 32 bits. Defined in section 5.20 of [RFC4710] as an unsigned integer, and it counts the total number of packets from sub-session RC_N that got lost while this RAQMON PDU was being generated 😭
Cumulative Application Packet Discards 🗑️: 32 bits. Defined in section 5.22 of [RFC4710] as an unsigned integer, and it counts the total number of packets from sub-session RC_N that got discarded while this RAQMON PDU was generated 💀
Total number of Application Packets sent 📤: 32 bits. Defined in section 5.17 of [RFC4710] as an unsigned integer, counting the total number of packets transmitted within sub-session RC_N by the sender 🌸
Total number of Application Packets received 📥: 32 bits. Defined in section 5.16 of [RFC4710] and represented as an unsigned integer, counting the total number of packets transmitted within sub-session RC_N by the receiver 🦋
Total number of Application Octets sent 🧮: 32 bits. Defined in section 5.19 of [RFC4710] as an unsigned integer, counting the total number of payload octets (so not counting header or padding) transmitted in packets by the sender within sub-session RC_N 🍓
Total number of Application Octets received 🧾: 32 bits. Defined in section 5.18 of [RFC4710] as an unsigned integer, counting the total number of payload octets (again, not header or padding) transmitted in packets by the receiver within sub-session RC_N 💜
Data Source Device Port Used 🚪: 16 bits. Defined in section 5.5 of [RFC4710], this describes the port number the Data Source used through the application in the RC_N session while this RAQMON PDU was generated 🌈
Receiver Device Port Used 🔌: 16 bits. Defined in section 5.6 of [RFC4710], this describes the receiver port the application used to communicate with the receiver. It follows the same syntax as Source Device Port Used ✨
S_Layer2 🏷️: 8 bits. Defined in section 5.26 of [RFC4710], this one's tied to the source's IEEE 802.1D [IEEE802.1D] priority tagging of traffic in the communication sub-session RC_N. IEEE 802.1 priority tags are 3 bits long, so the first 3 bits of this parameter hold the IEEE 802.1 tag value, and the last 5 bits are padded to 0. Tiny but mighty 👑
S_Layer3 🎯: 8 bits. Defined in section 5.27 of [RFC4710], this represents the layer 3 QoS marking used by this data source to send packets to the receiver during sub-session RC_N. Quality of service, served with a bow 🎀💅
Okay so, the BASIC part is still going, and the next bits are all about the layer 2 and layer 3 info and the CPU and memory vibes 💖
D_Layer2: 8 bits 🎀 This one is defined in section 5.28 of [RFC4710] and holds the layer 2 IEEE 802.1D priority tags that the receiver uses to send packets to the data source during sub-session RC_N, but only if the Data Source can learn that info. IEEE 802.1 priority tags are only 3 bits long, so the first 3 bits carry the tag value and the last 5 bits are padded to 0. Padding slay 🧚
D_Layer3: 8 bits 🦋 Defined in section 5.29 of [RFC4710], this one carries the layer 3 QoS marking the receiver uses to send packets to the data source during sub-session RC_N, if the Data Source can learn that too 💅
Source Payload Type: 8 bits 🌸 This is defined in section 5.24 of [RFC4710]. It tells you the payload type of the data source for the RC_N sub-session, as defined in [RFC3551] ✨
Receiver Payload Type: 8 bits 🍓 Same energy, but defined in section 5.25 of [RFC4710]. It gives the receiver payload type for the RC_N sub-session, as defined in [RFC3551] 🫶
CPU Utilization: 8 bits 🔥 Defined in section 5.30 of [RFC4710], this is the percentage of CPU used during session RC_N, measured from the last report until this RAQMON PDU was generated. It's expressed in percent, from 0 to 100. The value should show not just the CPU use tied to session RC_N but the actual CPU utilization too, so you get a snapshot of how busy the host running the RDS is while session RC_N is in progress 👑
Memory Utilization: 8 bits 🌈 Defined in section 5.31 of [RFC4710], this is the percentage of total memory used during session RC_N up until this RAQMON PDU was generated. It's expressed in percent, 0 to 100. The Memory Utilization value should show not only the memory tied to session RC_N but the total memory utilization, so you get a snapshot of end-device memory while session RC_N is in progress 💜
Session Setup Delay: 16 bits ⭐ The Session (sub-session) Setup Delay metric is defined in section 5.8 of [RFC4710] and is expressed in milliseconds ⏱️
Application Delay: 16 bits 🎀 Defined in section 5.13 of [RFC4710], this is represented as an unsigned integer in milliseconds 💖
IP Packet Delay Variation: 16 bits 🦋 Defined in section 5.15 of [RFC4710], this is also an unsigned integer in milliseconds. Main character energy 👑
Inter-Arrival Jitter: 16 bits 🌸 Defined in section 5.14 of [RFC4710], represented as an unsigned integer in milliseconds 🫶
Packet Discard in Fraction: 8 bits 💅 Defined in section 5.23 of [RFC4710], this is a fixed-point number with the binary point at the left edge of the field. In other words, it's the integer part after you multiply the discard fraction by 256. The metric is the number of packets discarded divided by the total number of packets ✨
Packet Loss in Fraction: 8 bits 💀 Defined in section 5.21 of [RFC4710], this is also a fixed-point number with the binary point at the left edge of the field. The metric is the number of packets lost divided by the number of packets expected. The value comes from dividing the total packets lost (after any error protection, like Forward Error Correction (FEC), has been applied) by the total packets expected, then multiplying that result by 256, capping the maximum at 255 so it doesn't overflow, and taking the integer part. Overflow is not it 🙈
padding: 0, 8, 16, or 24 bits 🧚 If the padding bit (P) is set, this field may be present. The actual padding at the end of the BASIC part of the PDU is 0, 8, 16, or 24 bits, so the BASIC part's length ends up a multiple of 32 bits. Everything lines up, periodt 🎀
2.1.3. APP Part of the RAQMON Protocol Data Unit ✨
Okay, the APP part is where the extensions live 🦋 It's built to hold extensions for new applications in a modular way, so you don't need a new PDU type value registration every time.
Vendors can design and publish their own application-specific extensions 💅 Any RAQMON-compliant RRC MUST be able to recognize vendors' SMI Enterprise Codes, and it MUST recognize when application-specific extensions are present by looking at the Report Type fields 🔥 As shown in Figure 1, the Report Type and Application Length fields always sit at a fixed offset from the start of the extension fields. The RRC doesn't need to understand what the enterprise-specific parts of the PDU mean, which is honestly so freeing 🫶
SMI Enterprise Code: 32 bits 🌈 Vendors and application developers should fill in the right SMI Enterprise IDs, which you can find at http://www.iana.org/assignments/enterprise-numbers. A non-zero SMI Enterprise Code means there's a vendor- or application-specific extension going on 💜
RAQMON PDUs can carry multiple Application Parts inside a single PDU, so you can stack them up 🍓
Report Type: 16 bits ⭐ Vendors and application developers should fill in the appropriate report type within a given SMI Enterprise Code. It is RECOMMENDED that vendors publish their application-specific extensions and maintain those report types, because that makes interoperability way better 🎀
Length of the Application Part: 16 bits (unsigned integer) 🦋 This is the length of the Application Part of the RAQMON PDU in 32-bit words minus one, and it includes the header of the Application Part 💖
Application-dependent data: variable length 👑 This data is defined by the application developers. It's interpreted by the vendor-specific application and not by the RRC itself 🙌 Its length must be a multiple of 32 bits, and it gets padded if it needs to 🌸
2.1.4. Byte Order, Alignment, and Time Format of RAQMON PDUs 🕰️
All integer fields are sent in network byte order, meaning most significant byte (octet) first. This is commonly called big-endian, and the transmission order is described in detail in [RFC791] 🧚 Unless noted otherwise, numeric constants are in decimal (base 10) 💅
All header data is aligned to its natural length. So 16-bit fields sit on even offsets, 32-bit fields sit at offsets divisible by four, and so on 🫶 Octets designated as padding have the value zero 🍓
2.2. Securing RAQMON Session 🔐
okay so the RAQMON session is the connection that starts over TCP between an RDS and an RRC 🦋 The RDS client sends its monitoring info to the RRC, which is the collector. The RRC tells clients apart using identifiers. The RDS introduces itself with Data Source Address and Data Source Name, and the RRC uses Receiver's Address and Receiver's Name to identify itself 💅
RDS and RRC need to be able to trust each other's claimed identities, so authentication services are required ✨
Then, if you need to keep RAQMON data safe in transit from RDS to RRC (no one messing with it, no one reading it), you'll need data confidentiality and message integrity services 🔒 To stop anyone from recording a session and replaying it to feed the collector fake monitoring info, replay protection services may be required too 🙈
TLS handles all of this at the transport layer. Through its handshake protocol it provides the authentication services, and after that it covers data confidentiality, message integrity, and replay protection for the application protocol, using a ciphersuite negotiated during authentication 🎀
The RDS client authenticates the RRC in session. The RRC optionally authenticates the RDS. 🤝
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PDT = 1 |B| T |P|S|R| RC | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMI Enterprise Code = 0 |Report Type = | RC_N |
| | TLS_REQ| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: RAQMON StartTLS Request - TLS_REQThe protection of a RAQMON session kicks off when the RDS client sends a StartTLS request, right after the TCP session is successfully set up 🚀 The RDS sends it by transmitting the TLS_REQ PDU shown in Figure 2. You can spot this PDU by its TLS_REQ Report Type 👀
After sending this request, the client MUST NOT send any PDUs on this connection until it gets a StartTLS response. No sneaking in extra messages! 🙅♀️
The other fields of the PDU are as specified in Figure 1.
The flags field doesn't mean anything. It's only there for compatibility with the generic RAQMON PDU. In this version, the flags field MUST be ignored 💖
When a StartTLS request comes in, the target server (the RRC) MUST send back a RAQMON PDU with a StartTLS response, which is TLS_RESP. Here's how a RAQMON TLS_RESP is laid out:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PDT = 1 |B| T |P|S|R| RC | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMI Enterprise Code = 0 |Report Type = | Result |
| | TLS_RESP| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: RAQMON StartTLS Response - TLS_RESPThe RRC answers the StartTLS request by transmitting the TLS_RESP PDU shown in Figure 3. This PDU is identified by its TLS_RESP Report Type 🌸
The Result field is one octet holding the outcome of the request. It can be any of these values:
+-------+------------------+----------------------------------------+
| Value | Mnemonic | Result |
+-------+------------------+----------------------------------------+
| 0 | OK | Success. The server is willing and |
| | | able to negotiate TLS. |
| 1 | OP_ERR | Sequencing Error (e.g., TLS already |
| | | established). |
| 2 | PROTO_ERR | TLS not supported or incorrect PDU |
| | | format. |
| 3 | UNAVAIL | TLS service problem or RRC server |
| | | going down. |
| 4 | CONF_REQD | Confidentiality Service Required. |
| | | |
| 5 | STRONG_AUTH_REQD | Strong Authentication Service |
| | | Required. |
| 6 | REFERRAL | Referral to a RRC Server supporting |
| | | TLS. |
+-------+------------------+----------------------------------------+
Table 2The other fields of the PDU are as specified in Figure 1.
If the client breaks any of the StartTLS sequencing rules spelled out in the section below, the server MUST return OP_ERR 🙅♀️
If the server doesn't support TLS (on purpose, or because of how it's currently configured), it MUST set the resultCode to PROTO_ERR or to REFERRAL. If it picks REFERRAL, the server MUST include an actual referral value in the RAQMON REFER field. The client's current session is unaffected when the server doesn't support TLS 🦋 The client MAY carry on with the RAQMON session, or it MAY close the connection.
If the server supports TLS but can't set up a TLS connection for some reason (the example given is a certificate server not responding, or the TLS implementation can't be reached, or the server is shutting down), it MUST return UNAVAIL 😬 The client MAY retry the StartTLS operation, MAY carry on with the RAQMON session, or MAY close the connection.
2.2.1. Sequencing of the Start TLS Operation 🎬
This section lays out the full steps that clients and servers MUST follow to get TLS up and running. These steps also take into account the bigger picture of the RAQMON connection's security, including figuring out what security level you actually ended up with 💜
2.2.1.1. Requesting to Start TLS on a RAQMON Association
The client MAY send the StartTLS request at any time after it sets up a RAQMON (TCP) connection. The exceptions are these two cases, where the client MUST NOT send a StartTLS request:
- if TLS is already established on the connection, or
- if RAQMON traffic is in progress on the connection.
Breaking any of these rules gets you a Result of OP_ERR, as described above in Table 2. Oops 💀
If the client hasn't set up a TLS connection before sending other requests, and the server needs TLS in place before it'll handle a particular request, the server MUST reject that request with a CONF_REQD or STRONG_AUTH_REQD result. Then the client MAY send a Start TLS extended request, or it MAY choose to close the connection 🧚
2.2.1.2. Starting TLS
The server returns an extended response with a resultCode of success if it's willing and able to negotiate TLS. If it can't, it returns one of the other resultCodes listed above ✨
In the successful case, the client has stopped sending RAQMON PDUs on the connection, and now it MUST either begin a TLS negotiation or close the connection. The client sends PDUs in the TLS Record Protocol straight over the underlying transport connection to the server to kick off TLS negotiation [TLS] 🌈
2.2.1.3. TLS Version Negotiation
Picking which version of TLS or SSL to use is part of the TLS Handshake Protocol, as documented in [TLS]. Go read that doc for all the details 📖
2.2.1.4. Discovery of Resultant Security Level
Once a TLS connection is up on a RAQMON connection, both parties MUST individually decide whether to continue, based on the security assurance level they got. How you figure out that level is up to the implementation. You do it by talking to your own local TLS implementation 🔍
If the client or the server decides the authentication or confidentiality level isn't high enough to keep going, it SHOULD gracefully close the TLS connection right after the TLS negotiation has completed Section 2.2.2.1. 👋
The client MAY try to Start TLS again, MAY disconnect, or MAY go ahead and send RAQMON session data, if RRC policy allows it.
2.2.1.5. Server Identity Check
To guard against man-in-the-middle attacks, the client MUST check the server's hostname against the identity the server presents in its Certificate message 🕵️♀️
The matching works like this:
- The client MUST use the server dnsNAME in the subjectAltName field to validate the server certificate it gets. The server dnsName MUST be part of the server's subjectAltName.
- Matching is case-insensitive.
- The "*" wildcard character is allowed. If it's there, it only applies to the left-most name component.
For example, *.example.com would match a.example.com, b.example.com, etc., but not example.com. If the certificate has more than one identity of a given type (e.g., more than one dNSName name), a match against any one of them is considered acceptable 🌟
If the hostname doesn't match the dNSName-based identity in the certificate using the check above, automated clients SHOULD close the connection, and return and/or log an error saying the server's identity is suspect 🚨
Beyond the server identity checks in this section, clients SHOULD be ready to do extra checking to make sure the server is authorized to provide the service it appears to be providing. The client MAY need to use local policy information for this 🫶
We also point readers to similar guidelines used for LDAP over TLS [RFC4513] 💅
2.2.1.6. Client Identity Check
Okay bestie, so anonymous TLS auth gets you a TLS RAQMON session that's lowkey decent 🫶 It gives you:
- server authentication while TLS is being set up, and
- confidentiality and replay protection for RAQMON traffic, but
- zero protection against man-in-the-middle attacks during session establishment, and
- zero protection from spoofing by unauthorized clients 💀
So if the deployment is open to those threats, the server MUST authenticate the RDS client. 🔒 That happens by requiring client authentication during TLS session establishment.
During the TLS negotiation, the server MUST request a certificate. The client hands over its certificate, and it MUST do a private-key-based encryption to prove it actually holds the private key tied to that certificate. Main character proof 👑
Deployments are going to be protecting sensitive data in transit, so the client and server MUST negotiate a ciphersuite with a bulk encryption algorithm of appropriate strength. No weak sauce allowed 💅
The server MUST verify that the client's certificate is valid. Normally it checks that the certificate was issued by a known CA and that none of the certificates on the client's certificate chain are invalid or revoked. There are several procedures the server can use to do these checks, so it has options ✨
The server validates the certificate using the Distinguished Name of the RDS client entity in the Subject field of the certificate. 🎀
Same vibes apply if you're using TLS-PSK modes [TLS-PSK] with pre-shared keys instead of client certificates. A corresponding set of guidelines applies there too 🦋
2.2.1.7. Refresh of Server Capabilities Information
The client MUST refresh any cached server capabilities information upon TLS session establishment. An example is the prior RRC state tied to a previous RAQMON session based on another DSRC. 🧚 Why? Because this protects against active-intermediary attacks, which could have messed with any server capabilities information the client grabbed before TLS was set up. Iykyk 🙈
The server MAY advertise different capabilities after TLS establishment. Plot twist, and totally allowed 🌈
2.2.2. Closing a TLS Connection
2.2.2.1. Graceful Closure
Either the client or the server MAY terminate the TLS connection on a RAQMON session by sending a TLS closure alert. The good news is this leaves the RAQMON connection intact 🦋
Before closing a TLS connection, the client MUST wait for any outstanding RAQMON transmissions to complete. This happens naturally when the RAQMON client is single-threaded and synchronous. Patience is a virtue, bestie 🌸
After the initiator of a close has sent a closure alert, it MUST discard any TLS messages until it has received an alert from the other party. It stops sending TLS Record Protocol PDUs, and once that alert arrives, it MAY send and receive RAQMON PDUs. ✨
The other party, if it receives a closure alert, MUST immediately transmit a TLS closure alert. After that it stops sending TLS Record Protocol PDUs, and it MAY send and receive RAQMON PDUs too 💖
2.2.2.2. Abrupt Closure
Either the client or the server MAY abruptly close the entire RAQMON session, plus any TLS connection running on it, by dropping the underlying TCP connection. Rude but valid 💀
It MAY be possible for RRC to send RDS a disconnection notification. That would let the client know the disconnect wasn't caused by a network failure. However, this message is not defined in this version, so don't hold your breath 🙈
2.3. SNMP Notifications as an RDS/RRC Network Transport Protocol
Okay so the whole point of the RAQMON Framework was to reuse existing application-level transport protocols. That way you get to use installations people already have, and you skip a bunch of transport-protocol-level complexity during design. Big brain energy 🧠✨ That's why SNMP got picked to carry RAQMON PDUs: lots of devices already run SNMP agents and can act as RAQMON Data Sources (RDSs) 🍓
Now, SNMP isn't perfect. It's got a couple of potential problems:
- Congestion risk is higher than with TCP, because it runs over UDP at the transport layer. 😬
- The encoding is less efficient. That means bigger messages, which can hurt congestion conditions and memory use on the devices 💀
To dodge those problems, here's what's recommended:
- Using the TCP transport is RECOMMENDED for SNMP-transport deployments wherever it's available for a pair of RDS/RRC. 💅
- Using Inform PDUs is RECOMMENDED. 🫶
- Using Traps PDU is NOT RECOMMENDED. 🙅♀️
- It is RECOMMENDED that information carried by notifications stays within the MTU size limits, so nothing gets fragmented 🦋
If SNMP is picked to transport RAQMON PDUs, the following specification applies to RAQMON-related SNMP usage:
- RDSs implement the ability to embed RAQMON parameters in SNMP Notifications. They reuse well-known SNMP mechanisms to report RAQMON Statistics, which is so efficient 🔥 The RAQMON RDS MIB module, as specified in 2.1.1, MUST be used to map the RAQMON PDUs onto the SNMP Notifications transport.
- RDSs aren't computationally rich, and the goal is to keep them as lightweight as possible. So RDSs MAY fail to respond to SNMP requests like GET, SET, etc. The exception is the GET and SET commands needed to implement the User-Based Security Model (USM) defined by [RFC3414]. 🧚
- To meet congestion safety requirements, SNMP INFORM PDUs SHOULD be used. If INFORM PDUs are used, RDSs MUST process the SNMP INFORM responses from RRCs and MUST serialize the PDU transmission rate, meaning they limit the number of PDUs sent in a specific time interval. Pacing is everything ✨
- Standard UDP port 162 SHOULD be used for SNMP Notifications. 🌈
2.3.1. Encoding RAQMON Using the RAQMON RDS MIB Module
The RAQMON RDS MIB module is what maps RAQMON PDUs onto SNMP Notifications for transport. It defines the objects needed to map the BASIC part of the RAQMON PDU, which is defined in [RFC4710], and it also defines the Notifications themselves. Want to add application-specific extensions to the Application (APP) part of the RAQMON PDU, as defined in [RFC4710]? You can include additional variable bindings in RAQMON notifications, as described in the MIB module, because they MAY be included there 🎀
For a detailed overview of the documents that describe the current Internet-Standard Management Framework, check out section 7 of [RFC3410]. Homework, but make it cute 📚
Managed objects are accessed via a virtual information store called the Management Information Base, or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms in the Structure of Management Information (SMI). This memo specifies a MIB module compliant with SMIv2, which is described in STD 58, [RFC2578], STD 58, [RFC2579] and STD 58, [RFC2580]. 💜
The following MIB module IMPORTS definitions from these:
SNMPv2-SMI [RFC2578]
SNMPv2-TC [RFC2579]
SNMPv2-CONF [RFC2580]
RMON-MIB [RFC2819]
DIFFSERV-DSCP-TC [RFC3289]
SNMP-FRAMEWORK-MIB [RFC3411]
INET-ADDRESS-MIB [RFC4001]It also uses REFERENCE clauses to refer to [RFC4710]. 🦋
RAQMON-RDS-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
Counter32, Unsigned32
FROM SNMPv2-SMI
DateAndTime
FROM SNMPv2-TC
rmon
FROM RMON-MIB
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB
InetAddressType, InetAddress, InetPortNumber
FROM INET-ADDRESS-MIB
Dscp
FROM DIFFSERV-DSCP-TC
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
FROM SNMPv2-CONF;
raqmonDsMIB MODULE-IDENTITY
LAST-UPDATED "200610100000Z" -- October 10, 2006
ORGANIZATION "RMON Working Group"
CONTACT-INFO
"WG EMail: rmonmib@ietf.org
Subscribe: rmonmib-request@ietf.org
MIB Editor:
Eugene Golovinsky
Postal: BMC Software, Inc.
2101 CityWest Boulevard,
Houston, TX, 77094
USA
Tel: +713-918-1816
Email: egolovin@bmc.com
"
DESCRIPTION
"This is the RAQMON Data Source notification MIB Module.
It provides a mapping of RAQMON PDUs to SNMP
notifications.
Ds stands for data source.
Note that all of the object types defined in this module
are accessible-for-notify and would consequently not be
available to a browser using simple Get, GetNext, or
GetBulk requests.
Copyright (c) The Internet Society (2006).
This version of this MIB module is part of RFC 4712;
See the RFC itself for full legal notices."
REVISION "200610100000Z" -- October 10, 2006
DESCRIPTION
"Initial version, published as RFC 4712."
::= { rmon 32 }
-- This OID allocation conforms to [RFC3737]
raqmonDsNotifications OBJECT IDENTIFIER ::= { raqmonDsMIB 0 }
raqmonDsMIBObjects OBJECT IDENTIFIER ::= { raqmonDsMIB 1 }
raqmonDsConformance OBJECT IDENTIFIER ::= { raqmonDsMIB 2 }
raqmonDsNotificationTable OBJECT-TYPE
SYNTAX SEQUENCE OF RaqmonDsNotificationEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This conceptual table provides the SNMP mapping of
the RAQMON BASIC PDU. It is indexed by the RAQMON
Data Source, sub-session, and address of the peer
entity.
Note that there is no concern about the indexation of
this table exceeding the limits defined by RFC 2578
Section 3.5. According to [RFC4710], Section 5.1,
only IPv4 and IPv6 addresses can be reported as
participant addresses."
::= { raqmonDsMIBObjects 1 }
raqmonDsNotificationEntry OBJECT-TYPE
SYNTAX RaqmonDsNotificationEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The entry (row) is not retrievable and is not kept by
RDSs. It serves data organization purposes only."
INDEX { raqmonDsDSRC, raqmonDsRCN, raqmonDsPeerAddrType,
raqmonDsPeerAddr }
::= { raqmonDsNotificationTable 1 }okay so this is the big list of everything a RAQMON data source notification can carry 🎀 each field gets its own little definition, and every single one is set up the exact same way, so the whole thing is lowkey so satisfying to read ✨
RaqmonDsNotificationEntry ::= SEQUENCE {
raqmonDsDSRC Unsigned32,
raqmonDsRCN Unsigned32,
raqmonDsPeerAddrType InetAddressType,
raqmonDsPeerAddr InetAddress,
raqmonDsAppName SnmpAdminString,
raqmonDsDataSourceDevicePort InetPortNumber,
raqmonDsReceiverDevicePort InetPortNumber,
raqmonDsSessionSetupDateTime DateAndTime,
raqmonDsSessionSetupDelay Unsigned32,
raqmonDsSessionDuration Unsigned32,
raqmonDsSessionSetupStatus SnmpAdminString,
raqmonDsRoundTripEndToEndNetDelay Unsigned32,
raqmonDsOneWayEndToEndNetDelay Unsigned32,
raqmonDsApplicationDelay Unsigned32,
raqmonDsInterArrivalJitter Unsigned32,
raqmonDsIPPacketDelayVariation Unsigned32,
raqmonDsTotalPacketsReceived Counter32,
raqmonDsTotalPacketsSent Counter32,
raqmonDsTotalOctetsReceived Counter32,
raqmonDsTotalOctetsSent Counter32,
raqmonDsCumulativePacketLoss Counter32,
raqmonDsPacketLossFraction Unsigned32,
raqmonDsCumulativeDiscards Counter32,
raqmonDsDiscardsFraction Unsigned32,
raqmonDsSourcePayloadType Unsigned32,
raqmonDsReceiverPayloadType Unsigned32,
raqmonDsSourceLayer2Priority Unsigned32,
raqmonDsSourceDscp Dscp,
raqmonDsDestinationLayer2Priority Unsigned32,
raqmonDsDestinationDscp Dscp,
raqmonDsCpuUtilization Unsigned32,
raqmonDsMemoryUtilization Unsigned32 }the first two objects are the session identifiers 🫶 raqmonDsDSRC is the Data Source identifier, which is basically a unique session descriptor 💅 and raqmonDsRCN is the Record Count Number for a sub-session inside that session 🦋
raqmonDsDSRC OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Data Source identifier represents a unique session
descriptor that points to a specific session
between communicating entities. Identifiers unique for
sessions conducted between two entities are
generated by the communicating entities. Zero is a
valid value, with no special semantics."
::= { raqmonDsNotificationEntry 1 }
raqmonDsRCN OBJECT-TYPE
SYNTAX Unsigned32 (0..15)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The Record Count Number indicates a sub-session
within a communication session. A maximum number of 16
sub-sessions are supported; this limitation is
dictated by reasons of compatibility with other
transport protocols."
::= { raqmonDsNotificationEntry 2 }
raqmonDsPeerAddrType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The type of the Internet address of the peer participant
for this session."
REFERENCE
"Section 5.2 of [RFC4710]"
::= { raqmonDsNotificationEntry 3 }
raqmonDsPeerAddr OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The Internet Address of the peer participant for this
session."
REFERENCE
"Section 5.2 of [RFC4710]"
::= { raqmonDsNotificationEntry 4 }
raqmonDsAppName OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"This is a text string giving the name and possibly the
version of the application associated with that session,
e.g., 'XYZ VoIP Agent 1.2'."
REFERENCE
"Section 5.28 of [RFC4710]"
::= { raqmonDsNotificationEntry 5 }
raqmonDsDataSourceDevicePort OBJECT-TYPE
SYNTAX InetPortNumber
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The port number from which data for this session was sent
by the Data Source device."
REFERENCE
"Section 5.5 of [RFC4710]"
::= { raqmonDsNotificationEntry 6 }
raqmonDsReceiverDevicePort OBJECT-TYPE
SYNTAX InetPortNumber
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The port number where the data for this session was
received."
REFERENCE
"Section 5.6 of [RFC4710]"
::= { raqmonDsNotificationEntry 7 }
raqmonDsSessionSetupDateTime OBJECT-TYPE
SYNTAX DateAndTime
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The time when session was initiated."
REFERENCE
"Section 5.7 of [RFC4710]"
::= { raqmonDsNotificationEntry 8 }
raqmonDsSessionSetupDelay OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
UNITS "milliseconds"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Session setup time."
REFERENCE
"Section 5.8 of [RFC4710]"
::= { raqmonDsNotificationEntry 9 }
raqmonDsSessionDuration OBJECT-TYPE
SYNTAX Unsigned32
UNITS "seconds"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Session duration, including setup time. The SYNTAX of
this object allows expression of the duration of sessions
that do not exceed 4660 hours and 20 minutes."
REFERENCE
"Section 5.9 of [RFC4710]"
::= { raqmonDsNotificationEntry 10 }
raqmonDsSessionSetupStatus OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Describes appropriate communication session states, e.g.,
Call Established successfully, RSVP reservation
failed, etc."
REFERENCE
"Section 5.10 of [RFC4710]"
::= { raqmonDsNotificationEntry 11 }
raqmonDsRoundTripEndToEndNetDelay OBJECT-TYPE
SYNTAX Unsigned32
UNITS "milliseconds"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Most recent available information about the
round-trip end-to-end network delay."
REFERENCE
"Section 5.11 of [RFC4710]"
::= { raqmonDsNotificationEntry 12}
raqmonDsOneWayEndToEndNetDelay OBJECT-TYPE
SYNTAX Unsigned32
UNITS "milliseconds"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Most recent available information about the
one-way end-to-end network delay."
REFERENCE
"Section 5.12 of [RFC4710]"
::= { raqmonDsNotificationEntry 13}
raqmonDsApplicationDelay OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
UNITS "milliseconds"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Most recent available information about the
application delay."
REFERENCE
"Section 5.13 of [RFC4710"
::= { raqmonDsNotificationEntry 14}
raqmonDsInterArrivalJitter OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
UNITS "milliseconds"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"An estimate of the inter-arrival jitter."
REFERENCE
"Section 5.14 of [RFC4710]"
::= { raqmonDsNotificationEntry 15}
raqmonDsIPPacketDelayVariation OBJECT-TYPE
SYNTAX Unsigned32 (0..65535)
UNITS "milliseconds"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"An estimate of the inter-arrival delay variation."
REFERENCE
"Section 5.15 of [RFC4710]"
::= { raqmonDsNotificationEntry 16}
raqmonDsTotalPacketsReceived OBJECT-TYPE
SYNTAX Counter32
UNITS "packets"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The number of packets transmitted within a communication
session by the receiver since the start of the session."
REFERENCE
"Section 5.16 of [RFC4710]"
::= { raqmonDsNotificationEntry 17 }
raqmonDsTotalPacketsSent OBJECT-TYPE
SYNTAX Counter32
UNITS "packets"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The number of packets transmitted within a communication
session by the sender since the start of the session."
REFERENCE
"Section 5.17 of [RFC4710]"
::= { raqmonDsNotificationEntry 18 }
raqmonDsTotalOctetsReceived OBJECT-TYPE
SYNTAX Counter32
UNITS "octets"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The total number of payload octets (i.e., not including
header or padding octets) transmitted in packets by the
receiver within a communication session since the start
of the session."
REFERENCE
"Section 5.18 of [RFC4710]"
::= { raqmonDsNotificationEntry 19 }
raqmonDsTotalOctetsSent OBJECT-TYPE
SYNTAX Counter32
UNITS "octets"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The number of payload octets (i.e., not including headers
or padding) transmitted in packets by the sender within
a communication sub-session since the start of the
session."
REFERENCE
"Section 5.19 of [RFC4710]"
::= { raqmonDsNotificationEntry 20 }
raqmonDsCumulativePacketLoss OBJECT-TYPE
SYNTAX Counter32
UNITS "packets"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The number of packets from this session whose loss
had been detected since the start of the session."
REFERENCE
"Section 5.20 of [RFC4710]"
::= { raqmonDsNotificationEntry 21 }
raqmonDsPacketLossFraction OBJECT-TYPE
SYNTAX Unsigned32 (0..100)
UNITS "percentage of packets sent"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The percentage of lost packets with respect to the
overall packets sent. This is defined to be 100 times
the number of packets lost divided by the number of
packets expected."
REFERENCE
"Section 5.21 of [RFC4710]"
::= { raqmonDsNotificationEntry 22 }the delay, jitter and packet counter objects are giving data-collection realness 📊✨ and these are the ones that are all about how the session actually performed 💜
Okay, so the MIB module keeps going, and this is where the notifications get their whole personality 💅✨
raqmonDsCumulativeDiscards OBJECT-TYPE
SYNTAX Counter32
UNITS "packets"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The number of packet discards detected since the
start of the session."
REFERENCE
"Section 5.22 of [RFC4710]"
::= { raqmonDsNotificationEntry 23 }
raqmonDsDiscardsFraction OBJECT-TYPE
SYNTAX Unsigned32 (0..100)
UNITS "percentage of packets sent"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The percentage of discards with respect to the overall
packets sent. This is defined to be 100 times the number
of discards divided by the number of packets expected."
REFERENCE
"Section 5.23 of [RFC4710]"
::= { raqmonDsNotificationEntry 24 }
raqmonDsSourcePayloadType OBJECT-TYPE
SYNTAX Unsigned32 (0..127)
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The payload type of the packet sent by this RDS."
REFERENCE
"RFC 1890, Section 5.24 of [RFC4710] "
::= { raqmonDsNotificationEntry 25 }
raqmonDsReceiverPayloadType OBJECT-TYPE
SYNTAX Unsigned32 (0..127)
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The payload type of the packet received by this RDS."
REFERENCE
"RFC 1890, Section 5.25 of [RFC4710] "
::= { raqmonDsNotificationEntry 26 }
raqmonDsSourceLayer2Priority OBJECT-TYPE
SYNTAX Unsigned32 (0..7)
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Source Layer 2 priority used by the data source to send
packets to the receiver by this data source during this
communication session."
REFERENCE
"Section 5.26 of [RFC4710]"
::= { raqmonDsNotificationEntry 27 }
raqmonDsSourceDscp OBJECT-TYPE
SYNTAX Dscp
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Layer 3 TOS/DSCP values used by the Data Source to
prioritize traffic sent."
REFERENCE
"Section 5.27 of [RFC4710]"
::= { raqmonDsNotificationEntry 28 }
raqmonDsDestinationLayer2Priority OBJECT-TYPE
SYNTAX Unsigned32 (0..7)
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Destination Layer 2 priority. This is the priority used
by the peer communicating entity to send packets to the
data source."
REFERENCE
"Section 5.28 of [RFC4710]"
::= { raqmonDsNotificationEntry 29 }
raqmonDsDestinationDscp OBJECT-TYPE
SYNTAX Dscp
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Layer 3 TOS/DSCP values used by the
peer communicating entity to prioritize traffic
sent to the source."
REFERENCE
"Section 5.29 of [RFC4710]"
::= { raqmonDsNotificationEntry 30 }
raqmonDsCpuUtilization OBJECT-TYPE
SYNTAX Unsigned32 (0..100)
UNITS "percent"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Latest available information about the total CPU
utilization."
REFERENCE
"Section 5.30 of [RFC4710]"
::= { raqmonDsNotificationEntry 31 }
raqmonDsMemoryUtilization OBJECT-TYPE
SYNTAX Unsigned32 (0..100)
UNITS "percent"
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"Latest available information about the total memory
utilization."
REFERENCE
"Section 5.31 of [RFC4710]"
::= { raqmonDsNotificationEntry 32 }
-- definitions of the notifications
--
-- raqmonDsAppName is the only object that MUST be sent by an
-- RDS every time the static notification is generated.
-- raqmonDsTotalPacketsReceived is the only object that MUST be
-- sent by an RD every time the dynamic notification is generated.
-- Other objects from the raqmonDsNotificationTable may be
-- included in the variable binding list. Specifically, a raqmon
-- notification will include MIB objects that provide information
-- about metrics that characterize the application session
raqmonDsStaticNotification NOTIFICATION-TYPE
OBJECTS { raqmonDsAppName }
STATUS current
DESCRIPTION
"This notification maps the static parameters in the
BASIC RAQMON PDU onto an SNMP transport.
This notification is expected to be sent once per
session, or when a new sub-session is initiated.
The following objects MAY be carried by the
raqmonDsStaticNotification:
raqmonDsDataSourceDevicePort,
raqmonDsReceiverDevicePort,
raqmonDsSessionSetupDateTime,
raqmonDsSessionSetupDelay,
raqmonDsSessionDuration,
raqmonDsSourcePayloadType,
raqmonDsReceiverPayloadType,
raqmonDsSourceLayer2Priority,
raqmonDsSourceDscp,
raqmonDsDestinationLayer2Priority,
raqmonDsDestinationDscp
It is RECOMMENDED to keep the size of a notification
within the MTU size limits in order to avoid
fragmentation."
::= { raqmonDsNotifications 1 }
raqmonDsDynamicNotification NOTIFICATION-TYPE
OBJECTS { raqmonDsTotalPacketsReceived }
STATUS current
DESCRIPTION
"This notification maps the dynamic parameters in the
BASIC RAQMON PDU onto an SNMP transport.
The following objects MAY be carried by the
raqmonDsDynamicNotification:
raqmonDsRoundTripEndToEndNetDelay,
raqmonDsOneWayEndToEndNetDelay,
raqmonDsApplicationDelay,
raqmonDsInterArrivalJitter,
raqmonDsIPPacketDelayVariation,
raqmonDsTotalPacketsSent,
raqmonDsTotalOctetsReceived,
raqmonDsTotalOctetsSent,
raqmonDsCumulativePacketLoss,
raqmonDsPacketLossFraction,
raqmonDsCumulativeDiscards,
raqmonDsDiscardsFraction,
raqmonDsCpuUtilization,
raqmonDsMemoryUtilization
It is RECOMMENDED to keep the size of a notification
within the MTU size limits in order to avoid
fragmentation."
::= { raqmonDsNotifications 2 }
raqmonDsByeNotification NOTIFICATION-TYPE
OBJECTS { raqmonDsAppName }
STATUS current
DESCRIPTION
"The BYE Notification. This Notification is the
equivalent of the RAQMON NULL PDU, which signals the
end of a RAQMON session."
::= { raqmonDsNotifications 3 }
--
-- conformance information
raqmonDsCompliance OBJECT IDENTIFIER ::=
{ raqmonDsConformance 1 }
raqmonDsGroups OBJECT IDENTIFIER ::= { raqmonDsConformance 2 }
raqmonDsBasicCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP entities that
implement this MIB module.
There are a number of INDEX objects that cannot be
represented in the form of OBJECT clauses in SMIv2, but
for which we have the following compliance requirements,
expressed in OBJECT clause form in this description
clause:
-- OBJECT raqmonDsPeerAddrType
-- SYNTAX InetAddressType { ipv4(1), ipv6(2) }
-- DESCRIPTION
-- This MIB requires support for only global IPv4
-- and IPv6 address types.
--
-- OBJECT raqmonDsPeerAddr
-- SYNTAX InetAddress (SIZE(4|16))
-- DESCRIPTION
-- This MIB requires support for only global IPv4
-- and IPv6 address types.
--
"
MODULE -- this module
MANDATORY-GROUPS { raqmonDsNotificationGroup,
raqmonDsPayloadGroup }
::= { raqmonDsCompliance 1 }
raqmonDsNotificationGroup NOTIFICATION-GROUP
NOTIFICATIONS { raqmonDsStaticNotification,
raqmonDsDynamicNotification,
raqmonDsByeNotification }
STATUS current
DESCRIPTION
"Standard RAQMON Data Source Notification group."
::= { raqmonDsGroups 1 }
raqmonDsPayloadGroup OBJECT-GROUP
OBJECTS { raqmonDsAppName,
raqmonDsDataSourceDevicePort,
raqmonDsReceiverDevicePort,
raqmonDsSessionSetupDateTime,
raqmonDsSessionSetupDelay,
raqmonDsSessionDuration,
raqmonDsSessionSetupStatus,
raqmonDsRoundTripEndToEndNetDelay,
raqmonDsOneWayEndToEndNetDelay,
raqmonDsApplicationDelay,
raqmonDsInterArrivalJitter,
raqmonDsIPPacketDelayVariation,
raqmonDsTotalPacketsReceived,
raqmonDsTotalPacketsSent,
raqmonDsTotalOctetsReceived,
raqmonDsTotalOctetsSent,
raqmonDsCumulativePacketLoss,
raqmonDsPacketLossFraction,
raqmonDsCumulativeDiscards,
raqmonDsDiscardsFraction,
raqmonDsSourcePayloadType,
raqmonDsReceiverPayloadType,
raqmonDsSourceLayer2Priority,
raqmonDsSourceDscp,
raqmonDsDestinationLayer2Priority,
raqmonDsDestinationDscp,
raqmonDsCpuUtilization,
raqmonDsMemoryUtilization }
STATUS current
DESCRIPTION
"Standard RAQMON Data Source payload MIB objects group."
::= { raqmonDsGroups 2 }
ENDThe static notification carries the session setup and payload details, while the dynamic one carries the live metrics 📊🫶
3. IANA Considerations 🎀
Okay, so RAQMON needs one fixed port to live on! 🌸 Port number 7744 is registered with IANA as the default port for RAQMON PDUs over TCP. Hosts running several applications can treat this port as a sign that RAQMON has been used, or they can set up a separate TCP port while provisioning RAQMON RDS and RAQMON Collector. 💜
The port was chosen to sit above 5000 because of how Unix handles port allocation. Privileged processes can only use port numbers below 1024, and port numbers between 1024 and 5000 get assigned automatically by the operating system. So 7744 fits neatly in its own lane 🦋✨
The OID assignment for the raqmonDsMIB MODULE-IDENTITY is made according to [RFC3737], so there's no IANA action needed on this front. Iconic, no notes 💅
4. Congestion-Safe RAQMON Operation ✨
okay so, like we covered earlier 🌸, TCP's congestion control gives you built-in congestion safety when TCP is the transport carrying RAQMON PDUs 💖
so the absolute best move is a congestion-safe transport like TCP 👑. if that's not doable, it may be necessary to fall back to UDP, since SNMP over UDP is already a widely deployed transport 🦋
when SNMP gets picked as the RAQMON PDU Transport, implementers MUST follow section 3 of [RFC4710] 💅. that section lays out the measures that MUST be taken to use RAQMON in a congestion-safe way. those congestion safety requirements are what make sure a RAQMON implementation using SNMP over UDP doesn't lead to congestion under heavy network load 😭
5. Acknowledgements 🫶
the authors want to thank Bill Walker and Joseph Mastroguilio from Avaya and Bin Hu from Motorola for their discussions 💜. special thanks to Randy Presuhn, who reviewed this document for spelling and formatting and gave a deep review of the technical content 👑. Bert Wijnen gets a shoutout too for the permanent coaching during the evolution of this document and the detailed review of its final versions 🎀. the Security Considerations section was reviewed by Sam Hartman and Kurt D. Zeilenga, and then almost completely re-written by Mahalingam Mani 🔥
6. Security Considerations 🔐
[RFC4710] lays out a threat model for RAQMON, plus the security considerations the RAQMON spec has to take into account to mitigate those threats 💀. it is imperative that RAQMON PDU implementations be able to provide the following protection mechanisms in order to attain end-to-end security:
- Authentication: The RRC SHOULD be able to verify that a RAQMON report was originated by the RDS claiming to have sent it. At minimum, an RDS/RRC pair MUST use a digest-based authentication procedure to authenticate, like the one defined in [RFC1321].
- Privacy: RAQMON information includes identification of the parties participating in a communication session. RAQMON deployments SHOULD be able to provide protection from eavesdropping, and to prevent an unauthorized third party from gathering potentially sensitive information. This can be achieved by using secure transport protocols supporting confidentiality based on encryption technologies such as DES (Data Encryption Standard), [3DES], and AES (Advanced Encryption Standard) [AES].
- Protection from DoS attacks directed at the RRC: RDSs send RAQMON reports as a side effect of external events (for example, receipt of a phone call). An attacker can try to overwhelm the RRC (or the network) by initiating a large number of events in order to swamp the RRC with excessive numbers of RAQMON PDUs.
To prevent DoS attacks against the RRC, the RDS will send the first report for a session only after the session has been established, so that the session set-up process is not affected.
- NAT and Firewall Friendly Design: The presence of IP addresses and TCP/UDP port information in RAQMON PDUs may be NAT-unfriendly. Where NAT-friendliness is a requirement, the RDS MAY omit IP address information from the RAQMON PDU. Another way to avoid this problem is by using NAT-Aware Application Layer Gateways (ALGs) to ensure that correct IP addresses appear in RAQMON PDUs.
for the usage of TCP, TLS MUST be used to provide transport layer security. Section 6.1 describes the usage of TLS with RAQMON.
this memo also defines the RAQMON-RDS-MIB module, whose purpose is mapping the RAQMON PDUs into SNMP Notifications. to attain end-to-end security, the following measures have been taken in the RAQMON-RDS-MIB module design:
there are no management objects defined in this MIB module that have a MAX-ACCESS clause of read-write and/or read-create. consequently, if this MIB module is implemented correctly, there is no risk that an intruder can alter or create any management objects of this MIB module via direct SNMP SET operations.
some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. it is thus important to control even GET and/or NOTIFY access to these objects, and possibly to even encrypt the values of these objects when sending them over the network via SNMP. these are the tables and objects and their sensitivity/vulnerability:
raqmonDsNotificationTablethe objects in this table contain user session information, and their disclosure may be sensitive in some environments.
SNMP versions prior to SNMPv3 did not include adequate security. even if the network itself is secure (for example by using IPsec), there is still no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. 🙈
It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and confidentiality).
it is a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured, so access to the objects is given only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 🧚
6.1. Usage of TLS with RAQMON 🔒
6.1.1. Confidentiality & Message Integrity
the subsequently authorized RAQMON data flow itself is protected by the same TLS security association that protects the client-side exchange. this standard TLS channel is now bound to the server through the above client-side authentication. the session itself is identified by the tuple:
{RDS ip-address:RDS_port / RRC ip-address:
RRC port}6.1.2. TLS CipherSuites
several issues should be considered when selecting TLS ciphersuites that are appropriate for use in a given circumstance. these issues include the following 🍓
the ciphersuite's ability to provide adequate confidentiality protection for passwords and other data sent over the transport connection. client and server implementers should recognize that some TLS ciphersuites provide no confidentiality protection, while other ciphersuites that do provide confidentiality protection may be vulnerable to being cracked using brute force methods, especially in light of ever-increasing CPU speeds that reduce the time needed to successfully mount such attacks.
client and server implementers should carefully consider the value of the password or data being protected versus the level of confidentiality protection provided by the ciphersuite, to ensure that the level of protection afforded by the ciphersuite is appropriate.
the ciphersuite's vulnerability (or lack thereof) to man-in-the-middle attacks. Ciphersuites vulnerable to man-in-the-middle attacks SHOULD NOT be used to protect passwords or sensitive data, unless the network configuration is such that the danger of a man-in-the-middle attack is negligible.
after a TLS negotiation (either initial or subsequent) is completed, both protocol peers should independently verify that the security services provided by the negotiated ciphersuite are adequate for the intended use of the RAQMON session. if not, the TLS layer should be closed.
Spoofing Attacks: when anonymous TLS alone is negotiated without client authentication, the client's identity is never established. this easily allows any end-entity to establish a TLS-secured RAQMON connection to the RRC. this not only offers an opportunity to spoof legitimate RDS clients and hence compromise the integrity of RRC monitoring data, but also opens the RRC up to unauthorized clients posing as genuine RDS entities to launch a DoS by flooding data. RAQMON deployment policy MUST consider requiring RDS client authentication during TLS session establishment, especially when RDS clients communicate across the unprotected internet. 🚨
Insider attacks: even client-authenticated TLS connections are open to spoofing attacks by one trusted client on another. validation of RDS source address against RDS TLS-session source address SHOULD be performed to detect such attempts. 👀
6.1.3. RAQMON Authorization State
every RAQMON session (between RDS and RRC) has an associated authorization state. this state is made up of numerous factors, such as what (if any) authorization state has been established, how it was established, and what security services are in place. some factors may be determined and/or affected by protocol events (e.g., StartTLS, or TLS closure), and some factors may be determined by external events (e.g., time of day or server load). 🦋
while it is often convenient to view authorization state in simplistic terms (as we often do in this technical specification), such as "an anonymous state", it is noted that authorization systems in RAQMON implementations commonly involve many factors that interrelate.
authorization in RAQMON is a local matter. one of the key factors in making authorization decisions is authorization identity. the initial session establishment defined in Section 2.2 allows information to be exchanged between the client and server to establish an authorization identity for the RAQMON session. the RRC is not to allow any RDS-transactions-related traffic through for processing until the client authentication is complete, unless anonymous authentication mode is negotiated.
upon initial establishment of the RAQMON session, the session has an anonymous authorization identity. among other things, this implies that the client need not send a TLSStartRequired in the first PDU of the RAQMON message. the client may send any operation request prior to binding RDS to any authentication, and the RRC MUST treat it as if it had been performed after an anonymous RAQMON session start. 🌈
the RDS automatically is placed in an unauthorized state upon RRC sending a TLSstart request to the RRC.
it is noted that other events, both internal and external to RAQMON, may result in the authentication and authorization states being moved to an anonymous one. for instance, the establishment, change, or closure of data security services may result in a move to an anonymous state, or the user's credential information (e.g., certificate) may have expired. the former is an example of an event internal to RAQMON, whereas the latter is an example of an event external to RAQMON. ⭐
7. References 📚
7.1. Normative References ✨
okay bestie, these are the references the spec needs you to have read 📚💅 Every one of these is load-bearing, no cap.
[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🔑 This is the one that defines all those capital-letter key words. Iconic.[RFC2578]McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 🧱[RFC2579]McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. 🎀[RFC2580]McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. ✅[RFC2819]Waldbusser, S., "Remote Network Monitoring Management Information Base", STD 59, RFC 2819, May 2000. 👀[RFC3289]Baker, F., Chan, K., and A. Smith, "Management Information Base for the Differentiated Services Architecture", RFC 3289, May 2002. 🌈[RFC3411]Harrington, D., Preshun, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. 🏗️[RFC4001]Daniele, M., Haberman, B., Routhier, S., and J. Schoenwalder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. 🌐[RFC791]Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. 🦋 the OG IP spec, obsessed.[RFC793]Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. 🫶 the OG TCP spec, also iconic.[RFC4710]Siddiqui, A., Romascanu, D., and E. Golovinsky, "Real-time Application Quality-of-Service Monitoring (RAQMON)", RFC 4710, October 2006. 💖 the whole reason we're here.[TLS]Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. 🔐
7.2. Informative References ✨
these ones are more like "extra credit" reading, lowkey helpful but not required 🧚
[3DES]Americation National Standards Institute, "Triple Data Encryption Algorithm Modes of Operation", ANSI X9.52-1998. 🔒[AES]Federal Information Processing Standard (FIPS), "Specifications for the ADVANCED ENCRYPTION STANDARD(AES)", Publication 197, November 2001. 💎[IEEE802.1D]"Information technology-Telecommunications and information exchange between systems--Local and metropolitan area networks-Common Specification a--Media access control (MAC) bridges:15802-3: 1998(ISO/IEC)", [ANSI/IEEE Std 802.1D Edition], 1998. 🌉[RFC1305]Mills, D., "Network Time Protocol Version 3", RFC 1305, March 1992. ⏰[RFC1321]Rivest, R., "Message Digest Algorithm MD5", RFC 1321, April 1992. 🧾[RFC3410]Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. 🍓[RFC3414]Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 3414, December 2002. 🛡️[RFC3550]Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003. 🎥[RFC3551]Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003. 🎧[RFC3629]Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. 🔤[RFC3737]Wijnen, B. and A. Bierman, "IANA Guidelines for the Registry of Remote Monitoring (RMON) MIB modules", RFC 3737, April 2004. 📋[RFC4513]Harrison, R., "Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms", RFC 4513, June 2006. 🗂️[TLS-PSK]Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, December 2005. 🗝️
Appendix A. Pseudocode ✨
okay so this appendix is all about the implementation notes 🧁 They're purely for information, bestie. Their whole job is to help you understand the RAQMON spec better, not to be the spec itself 💅
Pseudocode for RDS & RRC
we drop some pseudocode examples for the RDS and RRC pieces 🎀 Just know there could be other ways to do this that run faster in certain environments, or that have other perks too ✨
RDS:
when (session starts} {
report.identifier = session.endpoints, session.starttime;
report.timestamp = 0;
while (session in progress) {
wait interval;
report.statistics = update statistics;
report.curtimestamp += interval;
if encryption required
report_data = encrypt(report, encrypt parameters);
else
report_data = report;
raqmon_pdu = header, report_data;
send raqmon-pdu;
}
}
RRC:
listen on raqmon port
when ( raqmon_pdu received ) {
decrypt raqmon_pdu.data if needed
if report.identifier in database
if report.current_time_stamp > last update
update session statistics from report.statistics
else
discard report
}Authors' Addresses 🌸
the squad behind this one 🫶
Anwar Siddiqui
Avaya
307 Middletown Lincroft Road
Lincroft, NJ 80302
USA
Phone: +1 732 852-3200
EMail: anwars@avaya.com
Dan Romascanu
Avaya
Atidim Technology Park, Bldg #3
Tel Aviv, 61131
Israel
Phone: +972-3-645-8414
EMail: dromasca@avaya.com
Eugene Golovinsky
Alert Logic
Phone: +1 713 918-1816
EMail: gene@alertlogic.net
Mahfuzur Rahman
Samsung Information Systems America
75 West Plumeria Drive
San Jose, CA 95134
USA
Phone: +1 408 544-5559
Yongbum Yong Kim
Broadcom
3151 Zanker Road
San Jose, CA 95134
USA
Phone: +1 408 501-7800
EMail: ybkim@broadcom.comFull Copyright Statement 💜
Copyright (C) The Internet Society (2006).
this document is covered by the rights, licenses and restrictions in BCP 78, and apart from what BCP 78 says, the authors keep all their rights 🔐
this document and everything in it is handed over "AS IS". THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💀
Intellectual Property 🦋
the IETF doesn't take a side on whether any IPR claims around this tech are valid or how far they reach, and it doesn't say whether licenses for them are easy to get 🫠 It also hasn't gone looking for any such rights itself. If you want the rules on rights for RFC documents, check out BCP 78 and BCP 79 📖
copies of IPR disclosures sent to the IETF Secretariat, any promises of licenses, and the results of attempts to get a general license or permission for implementers or users of this spec can all be found in the IETF's online IPR repository at http://www.ietf.org/ipr 🔍
and if you know about any copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard, the IETF invites you to tell them. Send that info to ietf-ipr@ietf.org 📨
Acknowledgement 🌈
the RFC Editor function gets its funding from the IETF Administrative Support Activity (IASA) 💖
📦 where this page comes from
- ietf: rfc4712 2006-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms