Ethernet in the First Mile Copper (EFMCu) Interfaces MIB
updates
- rfc-5066 — Ethernet in the First Mile Copper (EFMCu) Interfaces MIB
Extracted elements (11)
Responsibility for maintenance and further development of the EFM-CU-MIB module was transferred from the concluded IETF HUBMIB working group to the IEEE 802.3 working group. IEEE developed IEEE8023-EFM-CU-MIB in 2011, based on the original EFM-CU-MIB, and the current revision is defined in IEEE Std 802.3.1-2013.
The EFM-CU-MIB defined in RFC 5066 becomes the last IETF version of that MIB module. All further development will be done by the IEEE 802.3 working group in IEEE8023-EFM-CU-MIB; requests should be sent to the IEEE 802.3.1 task force.
The IF-CAP-STACK-MIB module was not transferred to IEEE and remains under IETF control, currently maintained by the OPSAWG working group. This RFC provides an updated security considerations section for IF-CAP-STACK-MIB since the original RFC 5066 did not include any.
The IEEE8023-EFM-CU-MIB and EFM-CU-MIB MIB modules can coexist. Existing deployments of the EFM-CU-MIB need not be upgraded, but operators should expect that new equipment will use the IEEE8023-EFM-CU-MIB.
Deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security.
Implementations MAY also provide support for the Transport Security Model (TSM) in combination with a secure transport such as SSH or TLS/DTLS.
Implementations SHOULD provide the security features described by the SNMPv3 framework, and implementations claiming compliance to SNMPv3 MUST include full support for authentication and privacy via the User-based Security Model (USM) with the AES cipher algorithm.
The EFM-CU-MIB has MODULE-IDENTITY of efmCuMIB with an OID allocated under the mib-2 sub-tree. Object names in the first version of IEEE8023-EFM-CU-MIB are identical to those in EFM-CU-MIB, but different OID values allow both to coexist.
The IEEE8023-EFM-CU-MIB has MODULE-IDENTITY of ieee8023efmCuMIB with an OID allocated under the IEEE sub-tree: { iso(1) iso-identified-organization(3) ieee(111) standards-association-numbered-series-standards(2) lan-man-stds(802) ieee802dot3(3) ieee802dot3dot1mibs(1) }.
IF-CAP-STACK-MIB has no objects with MAX-ACCESS of read-write or read-create, so there is no risk that an intruder can alter or create management objects via direct SNMP SET operations.
The objects ifCapStackStatus and ifInvCapStackStatus can identify cross-connect capability of multi-layer (stacked) network interfaces, potentially revealing the underlying hardware architecture of the managed device. It is important to control GET and NOTIFY access and possibly encrypt these values when sending over SNMP.