8. Security Considerations

There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability:

ipForwarding and ipv6IpForwarding - these objects allow a manager to enable or disable the routing functions on the entity. By disabling the routing functions, an attacker would possibly be able to deny service to users. By enabling the routing functions, an attacker could open a conduit into an area. This might result in the area providing transit for packets it shouldn't or might allow the attacker access to the area bypassing security safeguards.

ipDefaultTTL and ipv6IpDefaultHopLimit - these objects allow a manager to determine the diameter of the valid area for a packet. By decreasing the value of these objects, an attacker could cause packets to be discarded before reaching their destinations.

ipv4InterfaceEnableStatus and ipv6InterfaceEnableStatus - these objects allow a manager to enable or disable IPv4 and IPv6 on a specific interface. By enabling a protocol on an interface, an attacker might be able to create an unsecured path into a node (or through it if routing is also enabled). By disabling a protocol on an interface, an attacker might be able to force packets to be routed through some other interface or deny access to some or all of the network via that protocol.

ipAddressTable - the objects in this table specify the addresses in use on this node. By modifying this information, an attacker can cause a node to either ignore messages destined to it or accept (at least at the IP layer) messages it would otherwise ignore. The use of filtering or security associations may reduce the potential damage in the latter case.

ipv6RouterAdvertTable - the objects in this table specify the information that a router should propagate in its routing advertisement messages. By modifying this information, an attacker can interfere with the auto-configuration of all hosts on the link. Most modifications to this table will result in a denial of service to some or all hosts on the link. However two objects, ipv6RouterAdvertManagedFlag and ipv6RouterAdvertOtherConfigFlag, indicate if a host should acquire configuration information from some other source. By enabling these, an attacker might be able to cause a host to retrieve its configuration information from a compromised source.

ipNetToPhysicalPhysAddress and ipNetToPhysicalType - these objects specify information used to translate a network (IP) address into a media dependent address. By modifying these objects, an attacker could disable communication with a node or divert messages from one node to another. However, the attacker may be able to carry out a similar attack by simply responding to the ARP or ND request made by the target node.

Readable Objects

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 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:

Essentially, all of the objects in this MIB could be considered sensitive as they report on the status of the IP modules within a system. However, the ipSystemStatsTable, ipIfStatsTable, and ipAddressTable are likely to be of most interest to an attacker. The statistics tables supply information about the quantity and type of traffic this node is processing and, especially for transit providers, may be considered sensitive. The address table provides a convenient list of all addresses in use by this node. Each address in isolation is unremarkable, however, the total list would allow an attacker to correlate otherwise unrelated traffic. For example, an attacker might be able to correlate an RFC 3041 [15] private address with known public addresses, thus circumventing the intentions of RFC 3041.

SNMPv3 Recommendations

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 [9], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy).

Further, deployment of SNMP versions prior to SNMPv3 is NOT 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.