RADIUS Authentication Client MIB for IPv6
obsoletes
- rfc-2618 — RADIUS Authentication Client MIB
Extracted elements (19)
RFC 4001 recommends that when revising a MIB with IPv4-specific tables, new tables using version-neutral InetAddressType/InetAddress textual conventions should be defined with status 'current', while old IPv4-only tables should be changed to 'deprecated'. Having multiple similar tables for different IP versions is strongly discouraged. RFC 4668 follows this guidance by deprecating radiusAuthServerTable and introducing radiusAuthServerExtTable.
The deprecated radiusAuthServerTable MAY continue to be supported under two conditions: (1) the managed entity only supports IPv4, or (2) the entity supports both IPv4 and IPv6 and the deprecated table is maintained for backwards compatibility with older management stations, but only when the IP addresses in the new table are in IPv4 format representable in both tables.
Deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. It is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security (authentication and privacy mechanisms).
Managed entities SHOULD NOT instantiate row entries in the deprecated radiusAuthServerTable when the RADIUS server address represented in such a row is not an IPv4 address.
Managed entities SHOULD NOT return inaccurate values of IP address or SNMP object access errors for IPv4-only address objects in otherwise populated deprecated tables when the actual server address is not IPv4.
The radiusAuthClientExtMIBCompliance compliance statement constrains radiusAuthServerInetAddressType to InetAddressType { ipv4(1), ipv6(2) } and radiusAuthServerInetAddress to InetAddress SIZE(4|16); implementations are only required to support IPv4 and globally unique IPv6 addresses.
When row entries exist in both the deprecated IPv4-only table and the new IP-version-neutral table describing the same RADIUS server, the row indexes SHOULD be the same for corresponding rows in each table to facilitate correlation by management applications.
radiusAuthClientCounterDiscontinuity (TimeTicks, UNITS centiseconds) records the time since the last discontinuity in the RADIUS client counters, such as a reinitialization of the RADIUS Client module. All Counter32 objects in radiusAuthServerExtTable reference this object to allow management applications to detect and account for counter resets.
radiusAuthClientExtMalformedAccessResponses (Counter32) counts packets with invalid length received from a server. Bad authenticators, invalid Message-Authenticator attributes, and unknown types are explicitly excluded from this counter and tracked separately in radiusAuthClientExtBadAuthenticators and radiusAuthClientExtUnknownTypes.
radiusAuthClientExtPendingRequests (Gauge32, UNITS packets) tracks the current number of Access-Request packets destined for a given server that have not yet timed out or received a response. It is incremented on each Access-Request sent and decremented on receipt of Access-Accept, Access-Reject, Access-Challenge, timeout, or retransmission.
radiusAuthClientExtTimeouts (Counter32, UNITS timeouts) counts authentication timeouts per server. A retry to the same server is counted as both a retransmission and a timeout; a send to a different server is counted as both a new Request and a timeout, avoiding double-counting ambiguity.
radiusAuthClientInvalidServerAddresses (Counter32, UNITS packets) counts the total number of RADIUS Access-Response packets received from unknown or unexpected server addresses, providing a global indicator of unsolicited or misdirected responses.
radiusAuthServerExtTable (STATUS current) is the version-neutral replacement for the deprecated radiusAuthServerTable. Each entry is indexed by radiusAuthServerExtIndex and includes radiusAuthServerInetAddressType (InetAddressType), radiusAuthServerInetAddress (InetAddress), and radiusAuthClientServerInetPortNumber (InetPortNumber, range 1..65535), supporting both IPv4 and IPv6 server addresses.
radiusAuthServerTable (STATUS deprecated) carries forward the IPv4-only table from RFC 2618, using radiusAuthServerAddress (IpAddress) and radiusAuthClientServerPortNumber (Integer32 0..65535). It contains 15 counter/gauge objects covering Access-Requests, retransmissions, Accepts, Rejects, Challenges, malformed responses, bad authenticators, pending requests, timeouts, unknown types, and dropped packets.
The RADIUS-AUTH-CLIENT-MIB module (OID radiusAuthentication 2) contains two scalars—radiusAuthClientInvalidServerAddresses and radiusAuthClientIdentifier—plus a deprecated IPv4-only table (radiusAuthServerTable) and a current version-neutral table (radiusAuthServerExtTable), each with one row per RADIUS authentication server sharing a secret with the client.
IANA has assigned OID { mib-2 67 } to RADIUS MIB work, represented as radiusMIB. The radiusAuthentication subtree is { radiusMIB 1 } and radiusAuthClientMIB is { radiusAuthentication 2 }.
SNMP versions prior to SNMPv3 lack adequate security controls even on otherwise secure networks (e.g., IPsec-protected), because they provide no mechanism to restrict which principals on the secure network are permitted to access MIB objects.
The radiusAuthServerInetAddress and radiusAuthClientServerInetPortNumber objects are sensitive: knowledge of the server address could aid attacks against the authentication server, and knowledge of the client's source port could enable impersonation of the client to send data to the server. GET and NOTIFY access to these objects should be controlled and their values encrypted in transit.
There are no read-write or read-create objects in this MIB module, so there is no risk that an intruder can alter or create management objects via direct SNMP SET operations.