RADIUS Authentication Server MIB for IPv6
obsoletes
- rfc-2619 — RADIUS Authentication Server MIB
Extracted elements (18)
RFC 4669 obsoletes RFC 2619 by deprecating the radiusAuthClientTable (which used IPv4-only IpAddress format) and introducing a new radiusAuthClientExtTable using InetAddressType and InetAddress textual conventions from RFC 4001. This follows RFC 4001's recommendation to define new tables with version-neutral IP addressing rather than maintaining parallel tables for different IP versions.
The term 'malformed' for RADIUS packets is not explicitly defined in RFC 2865 but in practice means the implementation determined the packet does not match the RFC 2865 format. Some implementations also treat VSAs that do not follow RFC 2865 recommendations as malformed; these de facto definitions are reflected in the MIB counter descriptions.
RADIUS entities combining client and server functions (e.g., proxies acting as server to some clients and client to other servers) are expected to implement both the RADIUS Authentication Server MIB (this document) and the RADIUS Authentication Client MIB (RFC 4668).
The radiusAuthServMIBExtCompliance constrains radiusAuthClientInetAddressType to ipv4(1) or ipv6(2) only, and radiusAuthClientInetAddress to SIZE (4|16), meaning implementations need only support IPv4 and globally unique IPv6 addresses.
Managed entities SHOULD NOT instantiate row entries in the deprecated table when the RADIUS client address 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.
Option (2) for supporting the deprecated table (backwards compatibility with older management stations) SHOULD only be used when the IP addresses in the new table are in IPv4 format and can accurately be represented in both tables.
The deprecated table MAY be supported when: (1) the managed entity only supports IPv4, or (2) it supports both IPv4 and IPv6 for backwards compatibility with older management stations, but only when SHOULD condition on address accuracy is met.
When row entries exist in both the deprecated IPv4-only table and the new IP-version-neutral table for the same RADIUS client, the row indexes SHOULD be the same in each table to facilitate correlation by management applications.
radiusAuthServConfigReset is a read-write INTEGER object with values other(1), reset(2), initializing(3), running(4). Writing reset(2) reinitializes persistent server state; reads never return reset(2) but return the current operational state.
radiusAuthServCounterDiscontinuity is a TimeTicks object (units: centiseconds) in each radiusAuthClientExtEntry row that indicates the time since the last counter discontinuity. All per-client Ext counters reference this object to signal resets due to RADIUS Server module reinitialization.
The deprecated radiusAuthClientTable (from RFC 2619) uses IpAddress for radiusAuthClientAddress, restricting it to IPv4. The table and all its objects carry STATUS deprecated in this revision.
The MIB module defines fourteen global scalar objects (radiusAuthServIdent, radiusAuthServUpTime, radiusAuthServResetTime, radiusAuthServConfigReset, and ten total-counter objects) plus a per-client table. The scalars track server identity, uptime, reset time, and aggregate packet counts across all clients.
The new radiusAuthClientExtTable (status: current) contains one row per RADIUS authentication client, indexed by radiusAuthClientExtIndex, and includes radiusAuthClientInetAddressType (InetAddressType), radiusAuthClientInetAddress (InetAddress), radiusAuthClientExtID (SnmpAdminString), per-client packet counters, and radiusAuthServCounterDiscontinuity (TimeTicks in centiseconds).
The RADIUS Authentication Server MIB is registered under mib-2 67 (radiusMIB), with radiusAuthentication at radiusMIB 1 and radiusAuthServMIB at radiusAuthentication 1. This OID assignment was made by IANA and is carried forward from RFC 2619.
Deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. SNMPv3 with full cryptographic mechanisms for authentication and privacy is RECOMMENDED. Operators must ensure the SNMP entity is configured to grant access only to principals with legitimate rights.
radiusAuthClientIPAddress and radiusAuthClientInetAddress expose the addresses of RADIUS authentication clients, which could be useful to an attacker mounting an attack against those clients. Even GET access to these objects should be controlled, and values should be encrypted when transmitted over the network via SNMP.
radiusAuthServConfigReset has MAX-ACCESS read-write; abuse of this object to trigger server reinitialization may interrupt processing of pending requests and constitutes a potential Denial of Service attack on the RADIUS server.