RFC 5097
MIB for the UDP-Lite protocol
RFC 5097: MIB for the UDP-Lite Protocol 🦋
okay bestie, here's the header tea ☕. This is RFC 5097, titled MIB for the UDP-Lite Protocol, from the Network Working Group. The authors are G. Renker and G. Fairhurst, both at the University of Aberdeen. It's a Standards Track document, dated January 2008. The header doesn't list anything it obsoletes or updates, so there's no drama there 💅
Status of This Memo ✨
this doc is an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions to make it better 🫶 for where things currently stand, check the latest "Internet Official Protocol Standards" (STD 1) listing, because that's the source of truth 📋 and distribution of this memo is unlimited, so share it freely 🌸
Abstract 🎀
okay so this doc defines a Management Information Base (MIB) module for the Lightweight User Datagram Protocol (UDP-Lite) 🧚 it adds a bunch of new MIB objects so you can see how transport-layer endpoints using UDP-Lite are behaving and performing 📊
the vibe: UDP-Lite is basically UDP's sibling, but it's different in one key way 👑 it has a single extra option that lets you choose how much of the datagram gets checksum coverage ✨ that's perfect for apps that would rather get a partially corrupted payload than have the whole datagram tossed 🥹
Table of Contents 🍓
1. Introduction ....................................................2
1.1. Relationship to the UDP-MIB ................................2
1.2. Relationship to HOST-RESOURCES-MIB and SYSAPPL-MIB .........4
1.3. Interpretation of the MIB Variables ........................5
1.4. Conventions ................................................8
2. The Internet-Standard Management Framework ......................8
3. Definitions .....................................................8
4. Security Considerations ........................................19
5. IANA Considerations ............................................20
6. Acknowledgments ................................................20
7. References .....................................................20
7.1. Normative References ......................................20
7.2. Informative References ....................................211. Introduction 💅
okay so the Lightweight User Datagram Protocol (UDP-Lite) [RFC3828] (also called UDPLite) is an IETF standards-track transport protocol 🌈 it works a lot like the User Datagram Protocol (UDP) [RFC768], but it's built for error-prone networks where apps would rather get partially damaged payloads than have them thrown away 🙈 the trick is that the UDP Length field's semantics change to become a Checksum Coverage field ✨ and if you don't use that feature, UDP-Lite is semantically identical to UDP, no cap 💖
the interface is UDP's plus one option that carries a length value 🎀 on the sender side it says how much of the datagram the checksum should cover, and on the receiver side it sets a minimum coverage threshold for incoming datagrams 👀 that length can also change during the life of a connection 🦋 UDP-Lite doesn't have any mechanism for negotiating checksum coverage between sender and receiver, so if you need that, another protocol has to handle it 🧚 for example, the Datagram Congestion Control Protocol (DCCP) [RFC4340] can negotiate checksum coverage values, so it's giving full main character energy 👑
this document defines a set of runtime statistics (variables) that make network management and monitoring way easier 📊 it also lets you compare different protocol implementations and operating environments on equal footing 🫶 to give users and implementors of UDP-Lite modules one shared interface, these statistics are defined as a MIB module using the SMIv2 format [RFC2578] 💜
1.1. Relationship to the UDP-MIB 🌸
UDP and UDP-Lite are so similar that it makes sense for the UDP-Lite MIB module to look like the UDP one [RFC4113], plus extra stuff for UDP-Lite's extra powers ✨ the UDP-Lite MIB module sits under the mib-2 subtree and keeps the familiar UDP-MIB structure so integration is smooth 🫶
these well-known basic counters are supported 🔥:
- InDatagrams
- NoPorts
- InErrors
- OutDatagrams
the basic structure from the UDP-MIB module also gets these new read-only variables 🍓
InPartialCov: the number of received datagrams that have a valid format and checksum, and whose checksum coverage is strictly less than the datagram length.InBadChecksum: the number of received datagrams with an invalid checksum (i.e., where the receiver-recalculated UDP-Lite checksum does not match the one in the Checksum field). Unlike NoPorts, this error type also counts as InErrors 😭OutPartialCov: the number of sent datagrams that have a valid format and checksum and whose checksum coverage is strictly less than the datagram length.
all of the non-error counters in this doc are 64-bit counters 💪 UDP traditionally used 32-bit counters and only mandates 64-bit counters on fast networks [RFC4113], so this is a real departure 🧚 the reasoning is that UDP-Lite is the newer protocol, and network speeds keep climbing 🚀
another difference from the UDP MIB module: the UDP-Lite MIB module does not support an IPv4-only listener table 🙅♀️ that feature only existed for compatibility, and the more informative endpoint table has replaced it 🎀 two columnar objects were added to that endpoint table ✨
udpliteEndpointMinCoverage: the minimum acceptable receiver checksum coverage length [RFC3828]. The application attached to the receiving endpoint can change this value.udpliteEndpointViolCoverage: this object is optional 🌈 it counts valid datagrams whose checksum coverage value is less than the corresponding udpliteEndpointMinCoverage value. Even though they're otherwise valid, these datagrams get discarded instead of being passed to the application 😤 so this object helps tell coverage violations apart from other InErrors 🔍
the second entry isn't needed to manage the transport protocol, so it's not mandatory 🫶 you can implement it if it helps you debug application design and configuration 🧸
the UDP-Lite MIB module also has a discontinuity object 🕰️ it tells you whether one or more of its counters went through a discontinuity event. That's any event, other than re-initialising the management system, that makes the management entity's understanding of the counter values invalid 💀
for example, if UDP-Lite is implemented as a loadable operating system module, then loading or unloading that module causes a discontinuity 🙈 by querying udpliteStatsDiscontinuityTime, a management entity can figure out whether a discontinuity has happened 🔍✨
1.2. Relationship to HOST-RESOURCES-MIB and SYSAPPL-MIB 🧚
the UDP-Lite endpoint table has one columnar object, udpliteEndpointProcess 🦋 it reports a unique value that identifies a distinct piece of software tied to this endpoint. (When more than one piece of software is tied to the endpoint, one representative gets picked, so consecutive queries keep referring to the same identifier 🫶 the value stays consistent for as long as that representative is running and still tied to the endpoint.)
udpliteEndpointProcess is reported as an Unsigned32 💜 it shares a requirement with the hrSWRunIndex of the HOST-RESOURCES-MIB [RFC2790] and the sysApplElmtRunIndex of the SYSAPPL-MIB [RFC2287]: wherever possible, it should be the native, unique identification number the system already uses 🎀
if the SYSAPPL-MIB module is available, udpliteEndpointProcess should match the appropriate sysApplElmtRunIndex value 🌸 if it isn't available, use an alternative instead, like the hrSWRunIndex from the HOST-RESOURCES-MIB module ✨
1.3. Interpretation of the MIB Variables ✨
okay so let's walk through how a UDP-Lite datagram moves through the input path 🦋 Figure 1 is a quick vibe check, with the counter names in parentheses 💅
Received UDP-Lite Datagrams
|
| +- Full Coverage ---------------------+-> Deliver
| | |
+- Valid Header--+ +- >= Rec. Coverage --+
| (InDatagrams) | |
| +- Partial -----+
| (InPartialCov) |
| +- < Rec. Coverage --+
| (EndpointViolCoverage) |
| |
| |
+- Header Error ---+ |
| | |
+- Checksum Error -+-----------------------------------+-> Discard
| (InBadChecksum) (InErrors)
|
+- Port Error -------------------------------------------> Discard
(NoPorts)Figure 1: UDP-Lite Input Processing Path
bestie, you can test UDP-Lite implementations on two connected end hosts without caring what platform they're running on 🧚 here's how it goes:
On the sending side, you look at OutDatagrams and OutPartialCov. The ratio OutPartialCov/OutDatagrams tells you the fraction (between 0 and 1) of datagrams using partial checksum coverage 🌸
On the receiving side, you keep an eye on InDatagrams, InPartialCov, and InErrors. If datagrams are coming in from the given sender, InErrors is close to zero, and InPartialCov is zero, then no partial coverage is being used 🙈 If no datagrams arrive and InErrors goes up in proportion to the sending rate, that's a configuration error, most likely (a wrong value of receiver minimum checksum coverage) 😭
The InBadChecksum counter reflects errors that may stick around after end-host processing, router processing, or link processing. This includes illegal coverage values as defined in [RFC3828], since checksum and checksum coverage are mutually interdependent 💜 InBadChecksum can also act as an indicator of the residual link bit error rate. On links with higher bit error rates, a lower checksum coverage value may help reduce both InErrors and InBadChecksum 🔥 By watching these values and adjusting the configuration, you may find a setting that fits the specific type of link and the type of payload better ✨ In particular, fewer discarded datagrams (InErrors) may mean improved performance 👑
The statistics above are the basics, and you can use them to work out the following:
- The total number of incoming datagrams is
InDatagrams + InErrors + NoPorts. - The number of
InErrorsthat were discarded for reasons other than a bad checksum isInErrors - InBadChecksum. - The number of
InDatagramsthat have full coverage isInDatagrams - InPartialCov. - The number of
OutDatagramsthat have full coverage isOutDatagrams - OutPartialCov.
The Case diagram [CASE] below sums up how the counters on the input processing path relate to each other 🎀
Transport Layer Interface
-------------------------------------------------------------
/\
||
----------------------------- InDatagrams
|| ^
|| |
|| |
||----------------------> InPartialCov
|| |
|| |
|| v
|| EndpointViolCoverage
|| |
NoPorts <--------|| |
|| |
||------> InBadChecksum ------>|
|| |
|| |
|| v
||------------------------> InErrors
||
||
-------------------------------------------------------------
Network Layer InterfaceFigure 2: Counters for Received UDP-Lite Datagrams
a configuration error can happen when a sender picks a coverage value that's lower than the minimum coverage the intended recipient has configured 🚨 The minimum coverage is set per session by the application behind the listening endpoint, and its current value is recorded in theudpliteEndpointTable. If a valid datagram arrives with a checksum coverage value below this threshold, it gets dropped [RFC3828] andInErrorsgoes up 💀
To make these misconfigured cases easier to debug, an implementer may choose to support the optional udpliteEndpointViolCoverage entry in the endpoint table (Section 1.1). That entry specifically counts datagrams that fall into this category 🧚 Without it, a failure caused by misconfiguration can't be told apart from a regular datagram processing failure 😤
1.4. Conventions 🫶
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 BCP 14 [RFC2119].
2. The Internet-Standard Management Framework 🌈
if you want the full rundown on the documents that make up the current Internet-Standard Management Framework, check out section 7 of RFC 3410 [RFC3410] 📚
Managed objects are accessed through 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 that is compliant with SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580] ✨
3. Definitions ✨
okay bestie, this is the actual MIB module 🎀 It's where all the UDP-Lite counters and the endpoint table get defined, so the names and OIDs have to be exactly right. We're starting with the imports and the module identity 🧚
UDPLITE-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY,
OBJECT-TYPE,
mib-2, Unsigned32,
Counter32, Counter64 FROM SNMPv2-SMI -- [RFC2578]
TimeStamp FROM SNMPv2-TC -- [RFC2579]
MODULE-COMPLIANCE,
OBJECT-GROUP FROM SNMPv2-CONF -- [RFC2580]
InetAddress,
InetAddressType,
InetPortNumber FROM INET-ADDRESS-MIB; -- [RFC4001]
udpliteMIB MODULE-IDENTITY
LAST-UPDATED "200712180000Z" -- 18 December 2007
ORGANIZATION "IETF TSV Working Group (TSVWG)"
CONTACT-INFO
"IETF TSV Working Group
http://www.ietf.org/html.charters/tsvwg-charter.html
Mailing List: tsvwg@ietf.org
Gerrit Renker, Godred Fairhurst
Electronics Research Group
School of Engineering, University of Aberdeen
Fraser Noble Building, Aberdeen AB24 3UE, UK"
DESCRIPTION
"The MIB module for managing UDP-Lite implementations.
Copyright (C) The IETF Trust (2008). This version of
this MIB module is part of RFC 5097; see the RFC
itself for full legal notices."
REVISION "200712180000Z" -- 18 December 2007
DESCRIPTION
"Initial SMIv2 revision, based on the format of the UDP
MIB module (RFC 4113) and published as RFC 5097."
::= { mib-2 170 }
udplite OBJECT IDENTIFIER ::= { udpliteMIB 1 }Next up are the counters 📊 Some of them are copied from the UDP-MIB, and a couple are brand new for UDP-Lite, so I've kept the little comments that say which is which 💅
udpliteInDatagrams OBJECT-TYPE -- as in UDP-MIB
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of UDP-Lite datagrams that were
delivered to UDP-Lite users.
Discontinuities in the value of this counter can occur
at re-initialisation of the management system, and at
other times as indicated by the value of
udpliteStatsDiscontinuityTime."
::= { udplite 1 }
udpliteInPartialCov OBJECT-TYPE -- new in UDP-Lite
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of UDP-Lite datagrams that were
delivered to UDP-Lite users (applications) and whose
checksum coverage was strictly less than the datagram
length.
Discontinuities in the value of this counter can occur
at re-initialisation of the management system, and at
other times as indicated by the value of
udpliteStatsDiscontinuityTime."
::= { udplite 2 }
udpliteNoPorts OBJECT-TYPE -- as in UDP-MIB
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of received UDP-Lite datagrams for
which there was no listener at the destination port.
Discontinuities in the value of this counter can occur
at re-initialisation of the management system, and at
other times as indicated by the value of
udpliteStatsDiscontinuityTime."
::= { udplite 3 }
udpliteInErrors OBJECT-TYPE -- as in UDP-MIB
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of received UDP-Lite datagrams that could not
be delivered for reasons other than the lack of an
application at the destination port.
Discontinuities in the value of this counter can occur
at re-initialisation of the management system, and at
other times as indicated by the value of
udpliteStatsDiscontinuityTime."
::= { udplite 4 }
udpliteInBadChecksum OBJECT-TYPE -- new in UDP-Lite
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of received UDP-Lite datagrams whose checksum
could not be validated. This includes illegal checksum
coverage values, as their use would lead to incorrect
checksums.
Discontinuities in the value of this counter can occur
at re-initialisation of the management system, and at
other times as indicated by the value of
udpliteStatsDiscontinuityTime."
REFERENCE "RFC 3828, section 3.1"
::= { udplite 5 }
udpliteOutDatagrams OBJECT-TYPE -- as in UDP-MIB
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of UDP-Lite datagrams sent from this
entity.
Discontinuities in the value of this counter can occur
at re-initialisation of the management system, and at
other times as indicated by the value of
udpliteStatsDiscontinuityTime."
::= { udplite 6 }
udpliteOutPartialCov OBJECT-TYPE -- new in UDP-Lite
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of udpliteOutDatagrams whose
checksum coverage was strictly less than the
datagram length.
Discontinuities in the value of this counter can occur
at re-initialisation of the management system, and at
other times as indicated by the value of
udpliteStatsDiscontinuityTime."
::= { udplite 7 }Now for the big one, the endpoint table 🦋 It's where we track which local apps are listening or sending, and the description has a few different ways to show a listener, so read it slowly 🫶
udpliteEndpointTable OBJECT-TYPE
SYNTAX SEQUENCE OF UdpLiteEndpointEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table containing information about this entity's
UDP-Lite endpoints on which a local application is
currently accepting or sending datagrams.
The address type in this table represents the address
type used for the communication, irrespective of the
higher-layer abstraction. For example, an application
using IPv6 'sockets' to communicate via IPv4 between
::ffff:10.0.0.1 and ::ffff:10.0.0.2 would use
InetAddressType ipv4(1).
Like the udpTable in RFC 4113, this table also allows
the representation of an application that completely
specifies both local and remote addresses and ports. A
listening application is represented in three possible
ways:
1) An application that is willing to accept both IPv4
and IPv6 datagrams is represented by a
udpliteEndpointLocalAddressType of unknown(0) and a
udpliteEndpointLocalAddress of ''h (a zero-length
octet-string).
2) An application that is willing to accept only IPv4
or only IPv6 datagrams is represented by a
udpliteEndpointLocalAddressType of the appropriate
address type and a udpliteEndpointLocalAddress of
'0.0.0.0' or '::' respectively.
3) An application that is listening for datagrams only
for a specific IP address but from any remote
system is represented by a
udpliteEndpointLocalAddressType of the appropriate
address type, with udpliteEndpointLocalAddress
specifying the local address.
In all cases where the remote address is a wildcard,
the udpliteEndpointRemoteAddressType is unknown(0),
the udpliteEndpointRemoteAddress is ''h (a zero-length
octet-string), and the udpliteEndpointRemotePort is 0.
If the operating system is demultiplexing UDP-Lite
packets by remote address/port, or if the application
has 'connected' the socket specifying a default remote
address/port, the udpliteEndpointRemote* values should
be used to reflect this."
::= { udplite 8 }
udpliteEndpointEntry OBJECT-TYPE
SYNTAX UdpLiteEndpointEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information about a particular current UDP-Lite endpoint.
Implementers need to pay attention to the sizes of
udpliteEndpointLocalAddress/RemoteAddress, as Object
Identifiers (OIDs) of column instances in this table must
have no more than 128 sub-identifiers in order to remain
accessible with SNMPv1, SNMPv2c, and SNMPv3."
INDEX { udpliteEndpointLocalAddressType,
udpliteEndpointLocalAddress,
udpliteEndpointLocalPort,
udpliteEndpointRemoteAddressType,
udpliteEndpointRemoteAddress,
udpliteEndpointRemotePort,
udpliteEndpointInstance }
::= { udpliteEndpointTable 1 }
UdpLiteEndpointEntry ::= SEQUENCE {
udpliteEndpointLocalAddressType InetAddressType,
udpliteEndpointLocalAddress InetAddress,
udpliteEndpointLocalPort InetPortNumber,
udpliteEndpointRemoteAddressType InetAddressType,
udpliteEndpointRemoteAddress InetAddress,
udpliteEndpointRemotePort InetPortNumber,
udpliteEndpointInstance Unsigned32,
udpliteEndpointProcess Unsigned32,
udpliteEndpointMinCoverage Unsigned32,
udpliteEndpointViolCoverage Counter32
}
udpliteEndpointLocalAddressType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The address type of udpliteEndpointLocalAddress. Only
IPv4, IPv4z, IPv6, and IPv6z addresses are expected, or
unknown(0) if datagrams for all local IP addresses are
accepted."
::= { udpliteEndpointEntry 1 }
udpliteEndpointLocalAddress OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The local IP address for this UDP-Lite endpoint.
The value of this object can be represented in three
possible ways, depending on the characteristics of the
listening application:
1. For an application that is willing to accept both
IPv4 and IPv6 datagrams, the value of this object
must be ''h (a zero-length octet-string), with
the value of the corresponding instance of the
EndpointLocalAddressType object being unknown(0).
2. For an application that is willing to accept only
IPv4 or only IPv6 datagrams, the value of this
object must be '0.0.0.0' or '::', respectively,
while the corresponding instance of the
EndpointLocalAddressType object represents the
appropriate address type.- For an application that is listening for data
destined only to a specific IP address, the value
of this object is the specific IP address for
which this node is receiving packets, with the
corresponding instance of the
EndpointLocalAddressType object representing the
appropriate address type.
As this object is used in the index for the
udpliteEndpointTable, implementors should be careful
not to create entries that would result in OIDs with
more than 128 sub-identifiers; this is because of SNMP
and SMI limitations."
::= { udpliteEndpointEntry 2 }
udpliteEndpointLocalPort OBJECT-TYPE
SYNTAX InetPortNumber
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The local port number for this UDP-Lite endpoint."
::= { udpliteEndpointEntry 3 }
udpliteEndpointRemoteAddressType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The address type of udpliteEndpointRemoteAddress. Only
IPv4, IPv4z, IPv6, and IPv6z addresses are expected, or
unknown(0) if datagrams for all remote IP addresses are
accepted. Also, note that some combinations of
udpliteEndpointLocalAdressType and
udpliteEndpointRemoteAddressType are not supported. In
particular, if the value of this object is not
unknown(0), it is expected to always refer to the
same IP version as udpliteEndpointLocalAddressType."
::= { udpliteEndpointEntry 4 }
udpliteEndpointRemoteAddress OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The remote IP address for this UDP-Lite endpoint. If
datagrams from any remote system are to be accepted,
this value is ''h (a zero-length octet-string).
Otherwise, it has the type described by
udpliteEndpointRemoteAddressType and is the address of
the remote system from which datagrams are to be
accepted (or to which all datagrams will be sent).
As this object is used in the index for the
udpliteEndpointTable, implementors should be careful
not to create entries that would result in OIDs with
more than 128 sub-identifiers; this is because of SNMP
and SMI limitations."
::= { udpliteEndpointEntry 5 }
udpliteEndpointRemotePort OBJECT-TYPE
SYNTAX InetPortNumber
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The remote port number for this UDP-Lite endpoint. If
datagrams from any remote system are to be accepted,
this value is zero."
::= { udpliteEndpointEntry 6 }
udpliteEndpointInstance OBJECT-TYPE
SYNTAX Unsigned32 (1..'ffffffff'h)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The instance of this tuple. This object is used to
distinguish among multiple processes 'connected' to
the same UDP-Lite endpoint. For example, on a system
implementing the BSD sockets interface, this would be
used to support the SO_REUSEADDR and SO_REUSEPORT
socket options."
::= { udpliteEndpointEntry 7 }
udpliteEndpointProcess OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A unique value corresponding to a piece of software
running on this endpoint.
If this endpoint is associated with more than one piece
of software, the agent should choose one of these. As
long as the representative piece of software
is running and still associated with the endpoint,
subsequent reads will consistently return the same
value. The implementation may use any algorithm
satisfying these constraints (e.g., choosing the entity
with the oldest start time).
This identifier is platform-specific. Wherever possible,
it should use the system's native, unique identification
number as the value.
If the SYSAPPL-MIB module is available, the value should
be the same as sysApplElmtRunIndex. If not available, an
alternative should be used (e.g., the hrSWRunIndex of the
HOST-RESOURCES-MIB module).
If it is not possible to uniquely identify the pieces of
software associated with this endpoint, then the value
zero should be used. (Note that zero is otherwise a
valid value for sysApplElmtRunIndex.)"
::= { udpliteEndpointEntry 8 }Okay, the endpoint table fields are next, and this part gets a bit more spicy with the coverage stuff 🦋 Everything below is copied exactly so the MIB stays legit.
udpliteEndpointMinCoverage OBJECT-TYPE -- new in UDP-Lite
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The minimum checksum coverage expected by this endpoint.
A value of 0 indicates that only fully covered datagrams
are accepted."
REFERENCE "RFC 3828, section 3.1"
::= { udpliteEndpointEntry 9 }
udpliteEndpointViolCoverage OBJECT-TYPE -- new / optional in UDP-Lite
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of datagrams received by this endpoint whose
checksum coverage violated the minimum coverage threshold
set for this connection (i.e., all valid datagrams whose
checksum coverage was strictly smaller than the minimum,
as defined in RFC 3828).
Discontinuities in the value of this counter can occur
at re-initialisation of the management system, and at
other times as indicated by the value of
udpliteStatsDiscontinuityTime."
::= { udpliteEndpointEntry 10 }
udpliteStatsDiscontinuityTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime at the most recent occasion at
which one or more of the UDP-Lite counters suffered a
discontinuity.
A value of zero indicates no such discontinuity has
occurred since the last re-initialisation of the local
management subsystem."
::= { udplite 9 }
-- Conformance Information
udpliteMIBConformance OBJECT IDENTIFIER ::= { udpliteMIB 2 }
udpliteMIBCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for systems that implement
UDP-Lite.
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 udpliteEndpointLocalAddressType
-- SYNTAX InetAddressType { unknown(0), ipv4(1),
-- ipv6(2), ipv4z(3),
-- ipv6z(4) }
-- DESCRIPTION
-- Support for dns(16) is not required.
-- OBJECT udpliteEndpointLocalAddress
-- SYNTAX InetAddress (SIZE(0|4|8|16|20))
-- DESCRIPTION
-- Support is only required for zero-length
-- octet-strings, and for scoped and unscoped
-- IPv4 and IPv6 addresses.
-- OBJECT udpliteEndpointRemoteAddressType
-- SYNTAX InetAddressType { unknown(0), ipv4(1),
-- ipv6(2), ipv4z(3),
-- ipv6z(4) }
-- DESCRIPTION
-- Support for dns(16) is not required.
-- OBJECT udpliteEndpointRemoteAddress
-- SYNTAX InetAddress (SIZE(0|4|8|16|20))
-- DESCRIPTION
-- Support is only required for zero-length
-- octet-strings, and for scoped and unscoped
-- IPv4 and IPv6 addresses.
"
MODULE -- this module
MANDATORY-GROUPS { udpliteBaseGroup,
udplitePartialCsumGroup,
udpliteEndpointGroup }
GROUP udpliteAppGroup
DESCRIPTION
"This group is optional and provides supplementary
information about the effectiveness of using minimum
checksum coverage thresholds on endpoints."
::= { udpliteMIBConformance 1 }
udpliteMIBGroups OBJECT IDENTIFIER ::= { udpliteMIBConformance 2 }
udpliteBaseGroup OBJECT-GROUP -- as in UDP
OBJECTS { udpliteInDatagrams, udpliteNoPorts, udpliteInErrors,
udpliteOutDatagrams, udpliteStatsDiscontinuityTime }
STATUS current
DESCRIPTION
"The group of objects providing for counters of
basic UDP-like statistics."
::= { udpliteMIBGroups 1 }
udplitePartialCsumGroup OBJECT-GROUP -- specific to UDP-Lite
OBJECTS { udpliteInPartialCov,
udpliteInBadChecksum,
udpliteOutPartialCov }
STATUS current
DESCRIPTION
"The group of objects providing for counters of
transport layer statistics exclusive to UDP-Lite."
::= { udpliteMIBGroups 2 }
udpliteEndpointGroup OBJECT-GROUP
OBJECTS { udpliteEndpointProcess, udpliteEndpointMinCoverage }
STATUS current
DESCRIPTION
"The group of objects providing for the IP version
independent management of UDP-Lite 'endpoints'."
::= { udpliteMIBGroups 3 }
udpliteAppGroup OBJECT-GROUP
OBJECTS { udpliteEndpointViolCoverage }
STATUS current
DESCRIPTION
"The group of objects that provide application-level
information for the configuration management of
UDP-Lite 'endpoints'."
::= { udpliteMIBGroups 4 }
END4. Security Considerations 🔐
Okay bestie, good news first 💖 There are no management objects in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. So if this MIB module is implemented correctly, an intruder has no way to alter or create any of its management objects with direct SNMP SET operations. Iconic 💅
Some of the readable objects here (anything with a MAX-ACCESS other than not-accessible) might be sensitive or vulnerable depending on the network environment. So it's really important to control even GET and/or NOTIFY access to these objects, and maybe even encrypt their values when they travel over the network via SNMP 🚨 Here's the list of the tables and objects and why they're sensitive:
The indices of the udpliteEndpointTable tell you about the listeners on an entity 👀 In particular, the udpliteEndpointLocalPort index objects can be used to spot which ports are open on the machine and which attacks are likely to succeed, all without the attacker needing to run a port scanner. The table also shows which UDP-Lite ports are currently listening. Not ideal, not me 😭
The udpliteEndpointMinCoverage object gives info about what the transport service tied to a specific UDP-Lite port requires. That's extra detail about the type of application sitting on that port at the receiver 🧐
Since UDP-Lite lets (partially) corrupted data get delivered to an end host, the counters in this MIB module can be used to infer things about the characteristics of the end-to-end path the datagrams travel over. That info could then be used to infer what kind of application is on the port at the receiver. Main character energy for the attacker, not for us 💀
SNMP versions before SNMPv3 didn't include adequate security. Even if the network itself is secure (for example, by using IPsec), there's still no control over who on that secure network gets to GET or SET (read, change, create, or delete) the objects in this MIB module 🙈
It is RECOMMENDED that implementers consider the security features provided by the SNMPv3 framework (see RFC 3410 [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms for authentication and privacy 🔒✨
Further, deploying SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and turn on cryptographic security 🛡️ It's then a customer or operator responsibility to make sure the SNMP entity giving access to an instance of this MIB module is configured so the objects are only accessible to principals (users) who have legitimate rights to GET or SET (change, create, or delete) them. No free passes, periodt 💜
5. IANA Considerations 🦋
The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER values, which are recorded in the SMI Numbers registry:
+------------+-------------------------+
| Descriptor | OBJECT IDENTIFIER value |
+------------+-------------------------+
| udpliteMIB | { mib-2 170 } |
+------------+-------------------------+6. Acknowledgments 🫶
The design of the MIB module in this document owes a lot to the format of the module presented in [RFC4113]. Thank you, bestie 🌸
7. References 📚
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and
G. Fairhurst, "The Lightweight User Datagram Protocol
(UDP-Lite)", RFC 3828, July 2004.
[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J.
Schoenwaelder, "Textual Conventions for Internet Network
Addresses", RFC 4001, February 2005.7.2. Informative References
[CASE] Case, J. and C. Partridge, "Case Diagrams: A First Step to
Diagrammed Management Information Bases", ACM Computer
Communications Review, 19(1):13-16, January 1989.
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC2287] Krupczak, C. and J. Saperia, "Definitions of System-Level
Managed Objects for Applications", RFC 2287, February
1998.
[RFC2790] Waldbusser, S. and P. Grillo, "Host Resources MIB", RFC
2790, March 2000.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002.
[RFC4113] Fenner, B. and J. Flick, "Management Information Base for
the User Datagram Protocol (UDP)", RFC 4113, June 2005.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March 2006.Authors' Addresses 🖊️
Gerrit Renker
University of Aberdeen
School of Engineering
Fraser Noble Building
Aberdeen AB24 3UE
Scotland
EMail: gerrit@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk
Godred Fairhurst
University of Aberdeen
School of Engineering
Fraser Noble Building
Aberdeen AB24 3UE
Scotland
EMail: gorry@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.ukFull Copyright Statement 🌈
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions contained in BCP 78, 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, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property ⭐
The IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or on the extent to which any license under such rights might or might not be available. It also doesn't represent that it has made any independent effort to identify any such rights. Information on the procedures for rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat, and any assurances of licenses to be made available, or the result of an attempt to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification, can be obtained from the IETF online IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 🎀
📦 where this page comes from
- ietf: rfc5097 2008-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms