Ethernet in the First Mile Copper (EFMCu) Interfaces MIB
Actelis Networks
Bazel 25
Petach-Tikva
Israel
+972-3-924-3491
edward.beili@actelis.com
Operations and Management
Network Management
Simple Network Management Protocol
SNMP
Management Information Base
MIB
2BASE-TL
10PASS-TS
802.3ah
EFM
PAF
PME
Interface
Stack
Bonding
This document updates RFC 5066.
It amends that specification by informing the internet community
about the transition of the EFM-CU-MIB module from the IETF Ethernet
Interfaces and Hub MIB Working Group to the Institute
of Electrical and Electronics Engineers (IEEE) 802.3 working group.
RFC 5066 defines two MIB modules:
EFM-CU-MIB, with a set of objects for managing 10PASS-TS and
2BASE-TL Ethernet in the First Mile Copper (EFMCu) interfaces;
IF-CAP-STACK-MIB, with a set of objects describing cross-connect
capability of a managed device with multi-layer (stacked)
interfaces, extending the stack management objects in the
Interfaces Group MIB and the Inverted Stack Table MIB modules.
With the conclusion of the working group,
the responsibility for the maintenance and further development of
the EFM-CU-MIB module has been transfered to the
Institute of Electrical and Electronics Engineers (IEEE)
working group. In 2011 the IEEE developed IEEE8023-EFM-CU-MIB
module, defined in IEEE Std 802.3.1-2011 and
based on the EFM-CU-MIB, defined in RFC 5066.
The IEEE8023-EFM-CU-MIB and EFM-CU-MIB are both valid MIB modules,
which can coexist.
Please note that IF-CAP-STACK-MIB module was not transfered to IEEE
and remains as defined in RFC 5066. This memo provides an updated
security considerations section for that module.
For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to
section 7 of RFC 3410 .
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as described
in RFC 2119 .
The initial version of IEEE8023-EFM-CU-MIB, defined in IEEE Std
802.3.1-2011, has MODULE-IDENTITY of ieee8023efmCuMIB with an object
identifier allocated under the { org ieee
standards-association-numbers-series-standards
lan-man-stds ieee802dot3 ieee802dot3dot1mibs } sub-tree.
The EFM-CU-MIB has MODULE-IDENTITY of efmCuMIB with an object
identifier allocated under the mib-2 sub-tree.
The names of the objects in IEEE8023-EFM-CU-MIB are identical to
those in EFM-CU-MIB. However, since both MIB modules have different
OID values, they can coexist, allowing the management of the newer
IEEE MIB-based devices, alongside the legacy IETF MIB-based devices.
With the transfer of the responsibility for maintenance and further
development of the EFM-CU-MIB module to the IEEE 802.3 working group,
the EFM-CU-MIB defined in RFC 5066 becomes the last valid version of
that MIB.
All further development of the EFM Copper Interfaces MIB
will be done by the IEEE 802.3 working group in the IEEE8023-EFM-CU-MIB
module. Requests and comments pertaining to EFM Copper Interfaces
MIB SHOULD be sent to the IEEE 803.3.1
task force mailing list: .
The IF-CAP-STACK-MIB remains under IETF jurisdiction and is
maintained by the working group.
There are no managed objects defined in IF-CAP-STACK-MIB module
with a MAX-ACCESS clause of read-write and/or read-create.
Some of the readable objects in this MIB module (i.e., those with
MAX-ACCESS other than not-accessible) may be considered sensitive or
vulnerable in some network environments since they
can reveal some configuration aspects of the network interfaces.
In particular, 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 thus important to control even GET access to these
objects and possibly even encrypt the values of these objects when sending
them over the network via SNMP.
SNMP versions prior to SNMPv3 did not include adequate security.
Even if the network itself is secure (for example by using IPSec),
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.
Implementations MUST provide the security features described by the
SNMPv3 framework (see ), including full support for
authentication and privacy via the User-based Security Model (USM)
with the AES cipher algorithm
.
Implementations MAY also provide support for the Transport Security Model
(TSM) in combination with a secure transport such
as SSH or TLS/DTLS .
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.
No action is required from IANA.
This document was produced by the OPSAWG working
group, whose efforts were advanced by the contributions of
the following people (in alphabetical order):
Dan Romascanu
David Harrington
Michael MacFaden
This document updates RFC 5066, authored by Edward Beili of
Actelis Networks, and produced by the, now concluded,
HUBMIB working group.
802.3 Ethernet Working Group
IEEE
802.3 MIB Email Reflector
IEEE
IEEE Standard for Management Information Base (MIB)
Definitions for Ethernet
IEEE
Ethernet Interfaces and Hub MIB (hubmib) Charter
IETF
Operations and Management Area Working Group (opsawg) Charter
IETF