Transport Area Working Group G. Renker
Internet-Draft G. Fairhurst
Intended status: Standards Track University of Aberdeen
Expires: March 24, 2007 September 20, 2006
MIB for the UDP-Lite protocol
draft-renker-tsvwg-udplite-mib-00
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 March 24, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Renker & Fairhurst Expires March 24, 2007 [Page 1]
Internet-Draft MIB for the UDP-Lite protocol September 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 the transport layer entities using UDP-Lite. UDP-Lite
resembles UDP (RFC 768), but differs from the semantics of UDP by the
addition a single (socket) option. This adds the capability for
variable-length data checksum coverage that can benefit a class of
applications which prefer delivery of 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 . . . . 4
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.1. Normative References . . . . . . . . . . . . . . . . . . . 26
7.2. Informative References . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . . . 28
Renker & Fairhurst Expires March 24, 2007 [Page 2]
Internet-Draft MIB for the UDP-Lite protocol September 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 to UDP-Lite differs from that for UDP by the addition
of a single (socket) option that allows applications to signal the
availability of support for partial checksums. It may be used to
specify a minimum checksum coverage for received datagrams. This
value may be subsequently updated by the application while the socket
is open. UDP-Lite does not provide mechanisms to negotiate this
value 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 common
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 experimental 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
checksum and a coverage length that is consistent the datagram
length specified in the IP header (i.e. where partial-checksum
coverage is employed).
InBadCoverage: The number of received datagrams with an invalid
checksum coverage (as defined in [RFC3828]), and are also counted
by InErrors. (This counter does not include datagrams that are
valid, but whose length is less than the minimum requested by a
Renker & Fairhurst Expires March 24, 2007 [Page 3]
Internet-Draft MIB for the UDP-Lite protocol September 2006
specific application.) The value may be calculated as the sum of:
* The number of datagrams with a checksum coverage length that is
less than the minimum of eight bytes.
* The number of datagrams with a checksum coverage length that
exceeds the total length of the datagram (from the IP header).
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 checksum with a
checksum coverage length that is less than the datagram length
specified in the IP header (i.e. where partial-checksum coverage
is employed).
The above values all employ 32-bit counters, as is the standard case
for UDP [RFC4113]; supplementary 64-bit high-capacity counters are
not defined for UDP-Lite.
Unlike UDP, 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 correctly formatted, these datagrams are discarded rather
than being passed to the application. Incrementing this value
also increments InErrors.
The second entry is not required to manage the transport protocol and
is not manadatory. It may be implemented to assist in debugging
application design and configuration.
1.2. Relationship to HOST-RESOURCES-MIB and SYSAPPL-MIB
The endpoint table of [RFC4113] contains one columnar object that
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
Renker & Fairhurst Expires March 24, 2007 [Page 4]
Internet-Draft MIB for the UDP-Lite protocol September 2006
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
The implementation of UDP-Lite in two connected end hosts may be
tested by comparing the InPartialCov and OutPartialCov counters
(ensuring no other end points are addressed). This can be used to
verify whether the partial coverage option is being used at the
sender and receiver. When there is no packet loss, these two values
should be identical (assuming that the two end hosts use a common
fixed minimum checksum coverage, or that receiver uses a minimum
variable checksum coverage which is always below the coverage of
incoming xdatagrams).
The counters InBadCoverage and InBadChecksum count errors that may
result 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.
These statistics are elementary and can be used to derive the
following information:
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; i.e. it always holds that 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.
InErrors also counts such datagrams whose checksum coverage fails the
minimum acceptable checksum coverage associated with an endpoint.
This covers in particular the following cases: (i) a receiving
application has specified a minimum acceptable coverage and received
datagrams whose checksum coverage violated this threshold; or (ii) it
has specified full coverage (UDP compatibility mode) and received a
partially covered datagram. The minimum coverage is set on a per-
session basis by the application associated with the listening
Renker & Fairhurst Expires March 24, 2007 [Page 5]
Internet-Draft MIB for the UDP-Lite protocol September 2006
endpoint, and its current value is recorded in the
udpliteEndpointTable.
A configuration error may occur when a sender chooses a coverage
value for the datagrams that it sends that is less than the minimum
coverage configured by the intended recipient. Reception of valid
datagrams with a checksum coverage value less than this 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.
Figure 1 summarises the role of the various counters.
Received Datagrams
|
| +-Full Coverage -----------------+---> Deliver
| | |
+ InDatagrams -+ +- >= Rec Coverage +
| | |
| +-InPartialCov-+
| | |
| | +- < Rec Coverage -+
| | |
| +-NoPorts ------------------------+---> Discard
| | (InErrors)
+ InBadCoverage ---------------------------------+
| |
+ InBadChecksum ---------------------------------+
Figure 1: Counters for received UDP-Lite Datagrams
Renker & Fairhurst Expires March 24, 2007 [Page 6]
Internet-Draft MIB for the UDP-Lite protocol September 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 March 24, 2007 [Page 7]
Internet-Draft MIB for the UDP-Lite protocol September 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 | { experimental XXX } |
| | |
| udpliteMIB | { experimental YYY } |
+------------+-------------------------+
Table 1: Object Identifiers for the UDP-Lite MIB
The values "XXX" and "YYY" have been assigned for this MIB under the
'experimental' subtree.
Renker & Fairhurst Expires March 24, 2007 [Page 8]
Internet-Draft MIB for the UDP-Lite protocol September 2006
3. Definitions
UDPLITE-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, Counter32, Unsigned32,
experimental FROM SNMPv2-SMI
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF
InetAddress, InetAddressType,
InetPortNumber FROM INET-ADDRESS-MIB;
udpliteMIB MODULE-IDENTITY
LAST-UPDATED "200609190000Z" -- Tue, 19 Sep 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 "200609190000Z" -- Tue, 19 Sep 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
::= { experimental XXX }
-- RFC Ed.: replace XXX with OBJECT-IDENTIFIER & remove this note
udplite OBJECT IDENTIFIER ::= { experimental YYY }
-- RFC Ed.: replace YYY with OBJECT-IDENTIFIER & remove this note
Renker & Fairhurst Expires March 24, 2007 [Page 9]
Internet-Draft MIB for the UDP-Lite protocol September 2006
udpliteInDatagrams OBJECT-TYPE -- as in UDP-MIB
SYNTAX Counter32
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 Counter32
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 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-initialization of the management system, and at
other times as indicated by discontinuities in the
value of sysUpTime."
::= { udplite 3 }
Renker & Fairhurst Expires March 24, 2007 [Page 10]
Internet-Draft MIB for the UDP-Lite protocol September 2006
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-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 Counter32
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 Counter32
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 March 24, 2007 [Page 11]
Internet-Draft MIB for the UDP-Lite protocol September 2006
udpliteOutDatagrams OBJECT-TYPE -- as in UDP-MIB
SYNTAX Counter32
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 Counter32
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 March 24, 2007 [Page 12]
Internet-Draft MIB for the UDP-Lite protocol September 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 March 24, 2007 [Page 13]
Internet-Draft MIB for the UDP-Lite protocol September 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 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 }
Renker & Fairhurst Expires March 24, 2007 [Page 14]
Internet-Draft MIB for the UDP-Lite protocol September 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 March 24, 2007 [Page 15]
Internet-Draft MIB for the UDP-Lite protocol September 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 March 24, 2007 [Page 16]
Internet-Draft MIB for the UDP-Lite protocol September 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 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 datagrams whose checksum
coverage was strictly smaller than the minimum)."
Renker & Fairhurst Expires March 24, 2007 [Page 17]
Internet-Draft MIB for the UDP-Lite protocol September 2006
::= { udpliteEndpointEntry 10 }
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 }
Renker & Fairhurst Expires March 24, 2007 [Page 18]
Internet-Draft MIB for the UDP-Lite protocol September 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 March 24, 2007 [Page 19]
Internet-Draft MIB for the UDP-Lite protocol September 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 March 24, 2007 [Page 20]
Internet-Draft MIB for the UDP-Lite protocol September 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 in 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 on 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 what attacks are likely to
succeed, without the attacker having to run a port scanner. The
table also identifies ports that are listening using the UDP-Lite
protocol. 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 March 24, 2007 [Page 21]
Internet-Draft MIB for the UDP-Lite protocol September 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 March 24, 2007 [Page 22]
Internet-Draft MIB for the UDP-Lite protocol September 2006
5. IANA Considerations
This document requires IANA action to assign values under the
'experimental' 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 | { experimental XXX} |
| | |
| udpliteMIB | { experimental YYY} |
+------------+-------------------------+
Table 2: IANA Assignments
Renker & Fairhurst Expires March 24, 2007 [Page 23]
Internet-Draft MIB for the UDP-Lite protocol September 2006
Note to RFC Editor (to be removed prior to publication):
The IANA is requested to assign values for "XXX" and "YYY" under the
'experimental' 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 March 24, 2007 [Page 24]
Internet-Draft MIB for the UDP-Lite protocol September 2006
6. Acknowledgments
The design of the MIB presented owes much to the format of the MIB
presented in [RFC4113].
Renker & Fairhurst Expires March 24, 2007 [Page 25]
Internet-Draft MIB for the UDP-Lite protocol September 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 March 24, 2007 [Page 26]
Internet-Draft MIB for the UDP-Lite protocol September 2006
Authors' Addresses
Gerrit Renker
University of Aberdeen
Department of Engineering
Fraser Noble Building
Aberdeen AB24 3UE
Scotland
Email: gerrit@domain.same.as.www
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 March 24, 2007 [Page 27]
Internet-Draft MIB for the UDP-Lite protocol September 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 March 24, 2007 [Page 28]