Transport Area Working Group G. Renker Internet-Draft G. Fairhurst Intended status: Standards Track University of Aberdeen Expires: May 24, 2007 November 20, 2006 MIB for the UDP-Lite protocol draft-renker-tsvwg-udplite-mib-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 24, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Renker & Fairhurst Expires May 24, 2007 [Page 1] Internet-Draft MIB for the UDP-Lite protocol November 2006 Abstract This document specifies a Management Information Base (MIB) for the Lightweight User Datagram Protocol (UDP-Lite, RFC 3828). It defines a set of new MIB entities to characterise the behaviour and performance of transport layer entities deploying UDP-Lite. UDP-Lite resembles UDP (RFC 768), but differs from the semantics of UDP by the addition of a single (socket) option. This adds the capability for variable-length data checksum coverage, which can benefit a class of applications that prefer delivery of (partially) corrupted datagram payload data in preference to discarding the datagram. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Relationship to the UDP-MIB . . . . . . . . . . . . . . . 3 1.2. Relationship to HOST-RESOURCES-MIB and SYSAPPL-MIB . . . . 5 1.3. Interpretation of the MIB Variables . . . . . . . . . . . 5 2. The Internet-Standard Management Framework . . . . . . . . . . 7 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 21 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 7.1. Normative References . . . . . . . . . . . . . . . . . . . 28 7.2. Informative References . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Intellectual Property and Copyright Statements . . . . . . . . . . 30 Renker & Fairhurst Expires May 24, 2007 [Page 2] Internet-Draft MIB for the UDP-Lite protocol November 2006 1. Introduction The Lightweight User Datagram Protocol (UDP-Lite) [RFC3828] (also known as UDPLite) is an IETF standards-track transport protocol. The operation of UDP-Lite is similar to the User Datagram Protocol (UDP) [RFC0768], but can also serve applications in error-prone network environments that prefer to have partially damaged payloads delivered rather than discarded. This is achieved by changing the semantics of the UDP Length field to that of a Checksum Coverage field. If this feature is not used, UDP-Lite is semantically identical to UDP. The interface of UDP-Lite differs from that of UDP by the addition of a single (socket) option which communicates a length value: at the sender this specifies the intended datagram checksum coverage; at the receiver it signifies a minimum coverage threshold for incoming datagrams. This length value may also be modified during the lifetime of a connection. UDP-Lite does not provide mechanisms to negotiate the checksum coverage between the sender and receiver. Where required, this needs to be communicated by another protocol (see for instance DCCP [RFC4340]). This document defines a set of runtime statistics (variables) that facilitate both network management/monitoring as well as unified comparisons between different protocol implementations and operating environments. To provide a common interface for users and implementors of UDP-Lite modules, the definitions of these runtime statistics are provided as a MIB using the SMIv2 format [RFC2578]. 1.1. Relationship to the UDP-MIB The similarities between UDP and UDP-Lite suggest that the MIB for UDP-Lite should resemble the MIB for UDP [RFC4113] with extensions corresponding to the additional capabilities of UDP-Lite. The UDP- Lite MIB is placed beneath the mib-2 subtree, adhering to the familiar structure of the UDP MIB [RFC4113] to ease integration. The following read-only variables have been added to the basic structure used in the UDP MIB: InPartialCov: The number of received datagrams, with a valid format and checksum, whose checksum coverage is strictly less than the datagram length. InBadCoverage: The number of received datagrams with an invalid checksum coverage. There are two cases of invalid coverage, both lead to discarding the datagram [RFC3828]: Renker & Fairhurst Expires May 24, 2007 [Page 3] Internet-Draft MIB for the UDP-Lite protocol November 2006 * Datagrams with a checksum coverage length that is less than the minimum of eight bytes. * Datagrams with a checksum coverage length that exceeds the datagram length (IP payload length). Resembling analogous cases of the UDP MIB [RFC4113], such non- delivered datagrams are additionally counted by InErrors. (Note: InBadCoverage does not include datagrams which are otherwise valid, but whose coverage length fails to meet the minimum threshold potentially set by a receiver.) InBadChecksum: The number of received datagrams with an invalid checksum (i.e. where the receiver recalculated UDP-Lite checksum does not match that in the Checksum field). These errors are also counted as InErrors. OutPartialCov: The number of sent datagrams with a valid format and checksum whose checksum coverage is strictly less than the datagram length. All counters used in this document are 64-bit counters. This is a departure from UDP, which traditionally used 32-bit counters and mandates 64-bit counters only on fast networks [RFC4113]. This choice is justified by the fact that UDP-Lite is a fairly recent protocol, and that network speeds continue to grow. Another contrast to UDP is that the UDP-Lite MIB does not support an IPv4-only listener table. This feature was present only for compatibility reasons and is superseded by the more informative endpoint table. Two columnar objects have been added to this table: udpliteEndpointMinCoverage: The minimum acceptable receiver checksum coverage length [RFC3828]. This value may be manipulated by the application attached to this endpoint. udpliteEndpointViolCoverage: This object is optional and counts the number of valid datagrams with a checksum coverage value less than the corresponding value of udpliteEndpointMinCoverage. Although being otherwise valid, these datagrams are discarded rather than passed to the application. Incrementing this value also increments InErrors. The second entry is not required to manage the transport protocol and hence is not manadatory. It may be implemented to assist in debugging application design and configuration. Renker & Fairhurst Expires May 24, 2007 [Page 4] Internet-Draft MIB for the UDP-Lite protocol November 2006 1.2. Relationship to HOST-RESOURCES-MIB and SYSAPPL-MIB The endpoint table of [RFC4113] contains one columnar object, also used in this MIB, which reports the identification of the operating- system-level process handling a connection or a listening endpoint. The value is reported as an Unsigned32, which is expected to be the same as the hrSWRunIndex of the HOST-RESOURCES-MIB [RFC2790] (if the value is smaller than 2147483647) or the sysApplElmtRunIndex of the SYSAPPL-MIB [RFC2287]. 1.3. Interpretation of the MIB Variables A platform-independent test of the UDP-Lite implementations in two connected end hosts may be performed as follows. On the sending side, OutDatagrams and OutPartialCov are observed. If both values are equal, no partial coverage is employed. On the receiver side, InDatagrams, InPartialCov, and InErrors are monitored. If datagrams are received from the given sender, InErrors is close to zero, and InPartialCov is zero, no partial coverage is employed. If no datagrams are received and InErrors increases proportionally with the sending rate, a configuration error is likely (wrong value of receiver minimum checksum coverage). A non-zero InBadCoverage at the receiver indicates either datagram corruption or, if the link bit-error rate is low, an implementation failure at the sender. In all other cases, InBadChecksum may be used as an indicator of both the link bit error rate as well as the suitability of a chosen coverage length: on links with higher bit error rates, a lower value of the checksum coverage may help to reduce both the values of InErrors and InBadChecksum. By observing these values and adapting the configuration, a setting may then be found which is more adapted to the specific type of link, as well as the type of payload, indicated by a reduction of the number of discarded datagrams (InErrors), leading to an improved performance. The counters InBadCoverage and InBadChecksum count errors that may persist following end-host processing, router processing, or link processing (including any undetected errors that may have occurred in the bytes covered by the UDP-Lite checksum). These errors are also counted as InErrors. The above statistics are elementary and can be used to derive the following information: Renker & Fairhurst Expires May 24, 2007 [Page 5] Internet-Draft MIB for the UDP-Lite protocol November 2006 o The total number of incoming datagrams is InDatagrams + InErrors + NoPorts o The number of InErrors that were discarded due to problems other than illegal coverage or bad checksum (both of which may have been caused by datagram corruption) is InErrors - InBadCoverage - InPartialCov (always: InErrors >= InBadCoverage + InBadChecksum). o The number of InDatagrams that have full coverage is InDatagrams - InPartialCov. o The number of OutDatagrams that have full coverage is OutDatagrams - OutPartialCov. A configuration error may occur when a sender chooses a coverage value for the datagrams that it sends which is less than the minimum coverage configured by the intended recipient. The minimum coverage is set on a per-session basis by the application associated with the listening endpoint, and its current value is recorded in the udpliteEndpointTable. Reception of valid datagrams with a checksum coverage value less than this threshold results in dropping the datagram [RFC3828] and incrementing InErrors. To improve debugging of such (misconfigured) cases, an implementer may choose to support the optional udpliteEndpointViolCoverage entry in the endpoint table (Section 1.1.) that specifically counts datagrams falling in this category. Without this feature, failure due to misconfiguration can not be distinguished from datagram processing failure. Figure 1 summarises the roles of the various counters. Received Datagrams | | +-Full Coverage ---------------------+---> Deliver | | | + InDatagrams -+ +-- >= Rec Coverage --+ | | | | +-InPartialCov-+ | | | +-- < Rec Coverage --+ | (InErrors) | | | + NoPorts ------------------------------------------+ | | + InBadCoverage ------------------------------------+---> Discard | | (InErrors) + InBadChecksum ------------------------------------+ Figure 1: Counters for received UDP-Lite Datagrams Renker & Fairhurst Expires May 24, 2007 [Page 6] Internet-Draft MIB for the UDP-Lite protocol November 2006 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed 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 defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 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, RFC 2119 [RFC2119]. Renker & Fairhurst Expires May 24, 2007 [Page 7] Internet-Draft MIB for the UDP-Lite protocol November 2006 ==> RFC Editor's Note (please replace XXX and YYY with IANA values): The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER values, to be recorded in the SMI Numbers registry: +------------+-------------------------+ | Descriptor | OBJECT IDENTIFIER value | +------------+-------------------------+ | udplite | { mib-2 XXX } | | | | | udpliteMIB | { mib-2 YYY } | +------------+-------------------------+ Table 1: Object Identifiers for the UDP-Lite MIB The values "XXX" and "YYY" have been assigned for this MIB under the 'mib-2' subtree. Renker & Fairhurst Expires May 24, 2007 [Page 8] Internet-Draft MIB for the UDP-Lite protocol November 2006 3. Definitions UDPLITE-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter64, Unsigned32, mib-2 FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF InetAddress, InetAddressType, InetPortNumber FROM INET-ADDRESS-MIB; udpliteMIB MODULE-IDENTITY LAST-UPDATED "200611170000Z" -- Fri, 17th Nov 2006 ORGANIZATION "Electronics Research Group at the University of Aberdeen, UK" CONTACT-INFO "Electronics Research Group Department of Engineering, University of Abderdeen Fraser Noble Building, Aberdeen AB24 3UE, UK Phone: +44 1224 27 2813 Email: gerrit@erg.abdn.ac.uk" DESCRIPTION "The MIB module for managing UDP-Lite implementations. Copyright (C) The Internet Society (2006). This version of this MIB module is part of RFC ZZZ; see the RFC itself for full legal notices." -- RFC Ed.: replace ZZZ with actual RFC number & remove this note REVISION "200611170000Z" -- Fri, 17th Nov 2006 DESCRIPTION "Initial SMIv2 revision, based on the format of the UDP MIB (RFC 4113) and published as RFC ZZZ." -- RFC Ed.: replace ZZZ with actual RFC number & remove this note ::= { mib-2 XXX } -- RFC Ed.: replace XXX with OBJECT-IDENTIFIER & remove this note udplite OBJECT IDENTIFIER ::= { mib-2 YYY } -- RFC Ed.: replace YYY with OBJECT-IDENTIFIER & remove this note Renker & Fairhurst Expires May 24, 2007 [Page 9] Internet-Draft MIB for the UDP-Lite protocol November 2006 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-initialization of the management system, and at other times as indicated by discontinuities in the value of sysUpTime." ::= { 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-initialization of the management system, and at other times as indicated by discontinuities in the value of sysUpTime." ::= { udplite 2 } udpliteNoPorts OBJECT-TYPE -- as in UDP-MIB SYNTAX Counter64 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-initialization of the management system, and at other times as indicated by discontinuities in the value of sysUpTime." ::= { udplite 3 } Renker & Fairhurst Expires May 24, 2007 [Page 10] Internet-Draft MIB for the UDP-Lite protocol November 2006 udpliteInErrors OBJECT-TYPE -- as in UDP-MIB SYNTAX Counter64 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-initialization of the management system, and at other times as indicated by discontinuities in the value of sysUpTime." ::= { udplite 4 } udpliteInBadCoverage OBJECT-TYPE -- new in UDP-Lite SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of received UDP-Lite datagrams whose checksum coverage length was set to an invalid value (as defined per RFC 3828). Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by discontinuities in the value of sysUpTime." ::= { udplite 5 } udpliteInBadChecksum OBJECT-TYPE -- new in UDP-Lite SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of received UDP-Lite datagrams whose checksum could not be validated. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by discontinuities in the value of sysUpTime." ::= { udplite 6 } Renker & Fairhurst Expires May 24, 2007 [Page 11] Internet-Draft MIB for the UDP-Lite protocol November 2006 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-initialization of the management system, and at other times as indicated by discontinuities in the value of sysUpTime." ::= { udplite 7 } 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-initialization of the management system, and at other times as indicated by discontinuities in the value of sysUpTime." ::= { udplite 8 } udpliteEndpointTable OBJECT-TYPE -- The "listener" table 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 Renker & Fairhurst Expires May 24, 2007 [Page 12] Internet-Draft MIB for the UDP-Lite protocol November 2006 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 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 and port, or if the application has 'connected' the socket specifying a default remote address and port, the udpliteEndpointRemote* values should be used to reflect this." ::= { udplite 9 } Renker & Fairhurst Expires May 24, 2007 [Page 13] Internet-Draft MIB for the UDP-Lite protocol November 2006 udpliteEndpointEntry OBJECT-TYPE SYNTAX UdpLiteEndpointEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a particular current UDP-Lite endpoint. Implementers need to be aware that if the total number of elements (octets or sub-identifiers) in udpliteEndpointLocalAddress/RemoteAddress exceeds 111, then OIDs of column instances in this table will have more than 128 sub-identifiers and cannot be accessed using SNMPv1, SNMPv2c, or 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 Counter64 } 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 } Renker & Fairhurst Expires May 24, 2007 [Page 14] Internet-Draft MIB for the UDP-Lite protocol November 2006 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. 3. 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 of this table should be careful not to create entries that would result in OIDs with more than 128 subidentifiers; else the information cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3." ::= { 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 } Renker & Fairhurst Expires May 24, 2007 [Page 15] Internet-Draft MIB for the UDP-Lite protocol November 2006 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 of this table should be careful not to create entries that would result in OIDs with more than 128 subidentifiers; else the information cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3." ::= { 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 } Renker & Fairhurst Expires May 24, 2007 [Page 16] Internet-Draft MIB for the UDP-Lite protocol November 2006 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 "The system's process ID for the process associated with this endpoint, or zero if there is no such process. This value is expected to be the same as HOST-RESOURCES-MIB::hrSWRunIndex or SYSAPPL-MIB:: sysApplElmtRunIndex for some row in the appropriate tables." ::= { udpliteEndpointEntry 8 } udpliteEndpointMinCoverage OBJECT-TYPE -- new in UDP-Lite SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The minimum checksum coverage expected by this endpoint. If set to 0, only fully covered datagrams are accepted." ::= { udpliteEndpointEntry 9 } udpliteEndpointViolCoverage OBJECT-TYPE -- new / optional in UDP-Lite SYNTAX Counter64 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)." Renker & Fairhurst Expires May 24, 2007 [Page 17] Internet-Draft MIB for the UDP-Lite protocol November 2006 ::= { udpliteEndpointEntry 10 } udpliteMIBConformance OBJECT IDENTIFIER ::= { udpliteMIB 1 } 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 } Renker & Fairhurst Expires May 24, 2007 [Page 18] Internet-Draft MIB for the UDP-Lite protocol November 2006 GROUP udpliteAppGroup DESCRIPTION "This group is optional and provides supplementary information about the effectivity 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 } 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, udpliteInBadCoverage, 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 } Renker & Fairhurst Expires May 24, 2007 [Page 19] Internet-Draft MIB for the UDP-Lite protocol November 2006 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 } END Renker & Fairhurst Expires May 24, 2007 [Page 20] Internet-Draft MIB for the UDP-Lite protocol November 2006 4. Security Considerations There are no management objects defined in this MIB module that have a MAX-ACCESS clause of read-write and/or read-create. So, if this MIB module is implemented correctly, then 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: Since UDP-Lite permits the delivery of (partially) corrupted data to an end host, the counters defined in this MIB may be used to imply information about the characteristics of the end-to-end path over which the datagrams are communicated. In the MIB defined by this document, this information is not maintained at the port level, and therefore reflects the overall performance of the end host. The indices of the udpliteEndpointTable contain information about the listeners on an entity. In particular, the udpliteEndpointLocalPort and udpliteLocalPort objects in the indices can be used to identify what ports are open on the machine and which attacks are likely to succeed, without the attacker having to run a port scanner. The table also identifies the currently listening UDP-Lite ports. This could be used to infer the type of application associated with the port at the receiver. The udpliteEndpointMinCoverage provides information about the requirements of the transport service associated with a specific UDP-Lite port. This provides additional detail concerning the type of application associated with the port at the receiver. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is 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 RFC 3410 [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT Renker & Fairhurst Expires May 24, 2007 [Page 21] Internet-Draft MIB for the UDP-Lite protocol November 2006 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. Renker & Fairhurst Expires May 24, 2007 [Page 22] Internet-Draft MIB for the UDP-Lite protocol November 2006 5. IANA Considerations This document requires IANA action to assign values under the 'mib-2' subtree and to record the assignment in the SMI Numbers registry. Table 2 summarises the assignments of OBJECT IDENTIFIER values recorded in the SMI Numbers registry by this document. These assignments are defined in sections 2 and 3 of this document. +------------+-------------------------+ | Descriptor | OBJECT IDENTIFIER value | +------------+-------------------------+ | udplite | { mib-2 XXX} | | | | | udpliteMIB | { mib-2 YYY} | +------------+-------------------------+ Table 2: IANA Assignments Renker & Fairhurst Expires May 24, 2007 [Page 23] Internet-Draft MIB for the UDP-Lite protocol November 2006 ==> Note to the RFC Editor (to be removed prior to publication): The IANA is requested to assign values for "XXX" and "YYY" under the 'mib-2' subtree and to record the assignment in the SMI Numbers registry. When the assignment has been made, the RFC Editor is asked to replace "XXX"/"YYY" (here and in the MIB module) with the assigned value and to remove this note. Renker & Fairhurst Expires May 24, 2007 [Page 24] Internet-Draft MIB for the UDP-Lite protocol November 2006 6. Acknowledgments The design of the MIB presented owes much to the format of the MIB presented in [RFC4113]. Renker & Fairhurst Expires May 24, 2007 [Page 25] Internet-Draft MIB for the UDP-Lite protocol November 2006 ==> NOTE TO RFC EDITOR: PLEASE REMOVE THIS LOG PRIOR TO PUBLICATION Changes introduced in rev-01: o General: - incremented revision number to 01 - updated date to November - rephrased abstract o Section 1: - rephrased the begining of the second paragraph o Section 1.1: - rephrased some items - added missing InBadChecksum heading - updated text to refer to 64bit counters o Section 1.3: - removed 'x' in 'datagrams' - rephrased for clarity - Figure 1: missing bracked text should be InErrors - Figure 1: correction - NoPorts are not counted as InDatagrams o Section 2: - made the "Editor's Note" stand out more o Section 3 / MIB: - upgraded 11 32bit counters to 64bit - moved from experimental to mib-2 - updated revision date Renker & Fairhurst Expires May 24, 2007 [Page 26] Internet-Draft MIB for the UDP-Lite protocol November 2006 o Section 4: - some minor changes o Section 5: - again highlighted the Editor's Note by using `==>' to make it consistent Renker & Fairhurst Expires May 24, 2007 [Page 27] Internet-Draft MIB for the UDP-Lite protocol November 2006 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., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "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. [RFC4113] Fenner, B. and J. Flick, "Management Information Base for the User Datagram Protocol (UDP)", RFC 4113, June 2005. 7.2. Informative References [RFC0768] 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. [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006. Renker & Fairhurst Expires May 24, 2007 [Page 28] Internet-Draft MIB for the UDP-Lite protocol November 2006 Authors' Addresses Gerrit Renker University of Aberdeen Department 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 Department of Engineering Fraser Noble Building Aberdeen AB24 3UE Scotland Email: gorry@erg.abdn.ac.uk URI: http://www.erg.abdn.ac.uk Renker & Fairhurst Expires May 24, 2007 [Page 29] Internet-Draft MIB for the UDP-Lite protocol November 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Renker & Fairhurst Expires May 24, 2007 [Page 30]