EFM-CU MIB: Ethernet in the First Mile Copper (EFMCu) Interfaces MIB
A short note saying that maintenance of the copper Ethernet management module moved from the IETF to the IEEE 802.3 working group.
Beili, E., "Ethernet in the First Mile Copper (EFMCu) Interfaces MIB", RFC 7124, DOI 10.17487/RFC7124, February 2014, <https://www.rfc-editor.org/info/rfc7124>.
@misc{rfc7124,
series = {Request for Comments},
number = 7124,
howpublished = {RFC 7124},
publisher = {RFC Editor},
doi = {10.17487/RFC7124},
url = {https://www.rfc-editor.org/info/rfc7124},
author = {E. Beili},
title = {{Ethernet in the First Mile Copper (EFMCu) Interfaces MIB}},
pagetotal = 6,
year = 2014,
month = feb,
} RFC text
Contents
Internet Engineering Task Force (IETF) E. Beili
Request for Comments: 7124 Actelis Networks
Updates: 5066 February 2014
Category: Standards Track
ISSN: 2070-1721
Ethernet in the First Mile Copper (EFMCu) Interfaces MIB
Abstract
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 concluded IETF Ethernet Interfaces and Hub
MIB Working Group to the Institute of Electrical and Electronics
Engineers (IEEE) 802.3 working group.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7124.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Internet-Standard Management Framework . . . . . . . . . 3
3. Mapping between EFM-CU-MIB and IEEE8023-EFM-CU-MIB . . . . . 3
4. Updating the MIB Modules . . . . . . . . . . . . . . . . . . 3
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . 5
1. Introduction
RFC 5066 [RFC5066] 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 [HUBMIB] working group, the responsibility
for the maintenance and further development of a MIB module for
managing 2BASE-TL and 10PASS-TS interfaces has been transferred to
the Institute of Electrical and Electronics Engineers (IEEE) 802.3
[IEEE802.3] working group. In 2011, the IEEE developed the
IEEE8023-EFM-CU-MIB module, based on the original EFM-CU-MIB module
[RFC5066]. The current revision of IEEE8023-EFM-CU-MIB is defined in
IEEE Std 802.3.1-2013 [IEEE802.3.1].
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 using the MIB should expect that new equipment will use the
IEEE8023-EFM-CU-MIB.
Please note that the IF-CAP-STACK-MIB module was not transferred to
IEEE and remains as defined in RFC 5066. This memo provides an
updated security considerations section for that module, since the
original RFC did not list any security considerations for
IF-CAP-STACK-MIB.
2. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of
RFC 3410 [RFC3410].
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 [RFC2119].
3. Mapping between EFM-CU-MIB and IEEE8023-EFM-CU-MIB
The current version of IEEE8023-EFM-CU-MIB, defined in IEEE Std
802.3.1-2013, has MODULE-IDENTITY of ieee8023efmCuMIB with an object
identifier allocated under the { iso(1)
iso-identified-organization(3) ieee(111)
standards-association-numbered-series-standards(2) lan-man-stds(802)
ieee802dot3(3) ieee802dot3dot1mibs(1) } 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 the first version of the
IEEE8023-EFM-CU-MIB are identical to those in the 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.
4. Updating the MIB Modules
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 version of that
MIB module.
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 802.3.1 task force, currently chartered with MIB
development, via its mailing list [LIST802.3.1].
The IF-CAP-STACK-MIB remains under IETF control and is currently
maintained by the [OPSAWG] working group.
5. Security Considerations
There are no managed objects defined in the IF-CAP-STACK-MIB module
with a MAX-ACCESS clause of read-write and/or read-create. So, if
this MIB module is implemented correctly, then there is no risk that
an intruder can alter or create any management objects of this MIB
module via direct SNMP SET operations.
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.
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 and/or NOTIFY access to
these objects and possibly to 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 SHOULD provide the security features described by the
SNMPv3 framework (see [RFC3410]), and implementations claiming
compliance to the SNMPv3 standard MUST include full support for
authentication and privacy via the User-based Security Model (USM)
[RFC3414] with the AES cipher algorithm [RFC3826]. Implementations
MAY also provide support for the Transport Security Model (TSM)
[RFC5591] in combination with a secure transport such as SSH
[RFC5592] or TLS/DTLS [RFC6353].
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.
6. Acknowledgments
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
Tom Petch
This document updates RFC 5066, authored by Edward Beili of Actelis
Networks, and produced by the now-concluded HUBMIB working group.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
[RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The
Advanced Encryption Standard (AES) Cipher Algorithm in the
SNMP User-based Security Model", RFC 3826, June 2004.
[RFC5066] Beili, E., "Ethernet in the First Mile Copper (EFMCu)
Interfaces MIB", RFC 5066, November 2007.
7.2. Informative References
[HUBMIB] IETF, "Ethernet Interfaces and Hub MIB (hubmib) Charter",
<http://datatracker.ietf.org/wg/hubmib/charter/>.
[IEEE802.3.1]
IEEE, "IEEE Standard for Management Information Base (MIB)
Definitions for Ethernet", IEEE Std 802.3.1-2013, June
2013, <http://standards.ieee.org/getieee802/download/
802.3.1-2013.pdf>.
[IEEE802.3]
IEEE, "802.3 Ethernet Working Group",
<http://www.ieee802.org/3>.
[LIST802.3.1]
IEEE, "802.3 MIB Email Reflector",
<http://www.ieee802.org/3/be/reflector.html>.
[OPSAWG] IETF, "Operations and Management Area Working Group
(opsawg) Charter",
<http://datatracker.ietf.org/wg/opsawg/charter/>.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002.
[RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model
for the Simple Network Management Protocol (SNMP)", RFC
5591, June 2009.
[RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure
Shell Transport Model for the Simple Network Management
Protocol (SNMP)", RFC 5592, June 2009.
[RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport
Model for the Simple Network Management Protocol (SNMP)",
RFC 6353, July 2011.
Author's Address
Edward Beili
Actelis Networks
Bazel 25
Petach-Tikva 49103
Israel
Phone: +972-73-237-6852
EMail: edward.beili@actelis.com
AI ELI5
On this page
§1Why the Module Moved
RFC 5066 defines two MIB modules. EFM-CU-MIB has objects for managing 10PASS-TS and 2BASE-TL Ethernet in the First Mile Copper (EFMCu) interfaces. IF-CAP-STACK-MIB has objects describing the cross-connect capability of a managed device with multi-layer (stacked) interfaces.
When the IETF Ethernet Interfaces and Hub MIB working group (HUBMIB) concluded, responsibility for a MIB module for 2BASE-TL and 10PASS-TS interfaces went to the IEEE 802.3 working group. In 2011 the IEEE built the IEEE8023-EFM-CU-MIB module from the original EFM-CU-MIB. Its current revision is in IEEE Std 802.3.1-2013.
The group that wrote the rulebook closed down, so a different group took over and wrote a new edition.
§2The Management Framework
For an overview of the documents that make up the Internet-Standard Management Framework, the RFC points to section 7 of RFC 3410. It also states that the key words MUST, SHOULD and the like are to be read as described in RFC 2119.
The RFC itself defines no new MIB objects. It is an administrative update to RFC 5066.
This part only tells you where the general rules for these gadgets are written down.
§3Mapping Between the Two Modules
The IEEE module has the MODULE-IDENTITY ieee8023efmCuMIB, with an object identifier under the IEEE 802.3.1 MIBs sub-tree. The older module has the MODULE-IDENTITY efmCuMIB, with an object identifier under the mib-2 sub-tree.
The object names in the first version of IEEE8023-EFM-CU-MIB are identical to those in EFM-CU-MIB. Because the two modules have different OID values, they can coexist. A manager can control newer IEEE MIB-based devices alongside legacy IETF MIB-based devices.
Existing deployments of EFM-CU-MIB need not be upgraded, but operators should expect that new equipment will use the IEEE module.
The two rulebooks use the same words but have different page numbers, so they never get mixed up and can sit on the same shelf.
| Module | MODULE-IDENTITY | OID location | Maintained by |
|---|---|---|---|
| EFM-CU-MIB | efmCuMIB | mib-2 sub-tree | Frozen at RFC 5066 |
| IEEE8023-EFM-CU-MIB THIS RFC | ieee8023efmCuMIB | IEEE 802.3.1 MIBs sub-tree | IEEE 802.3 working group |
| IF-CAP-STACK-MIB | Not stated | Not stated | IETF OPSAWG working group |
§4Who Maintains What
The EFM-CU-MIB defined in RFC 5066 becomes the last version of that module. All further development of the EFM Copper Interfaces MIB is done by the IEEE 802.3 working group in the IEEE8023-EFM-CU-MIB module. Requests and comments should go to the IEEE 802.3.1 task force, which is chartered with MIB development, through its mailing list.
IF-CAP-STACK-MIB was not transferred. It remains under IETF control and is maintained by the OPSAWG working group.
Questions about the copper part now go to the new club. The part about stacked interfaces stays with the old one.
§5Security of IF-CAP-STACK-MIB
The original RFC listed no security considerations for IF-CAP-STACK-MIB, so this one supplies them. The module has no objects with a MAX-ACCESS of read-write or read-create, so correct implementations cannot be altered or have objects created through SNMP SET operations.
Some readable objects may still be sensitive. In particular, ifCapStackStatus and ifInvCapStackStatus can reveal the cross-connect capability of stacked interfaces, and so potentially the underlying hardware architecture. Access to them, even GET and NOTIFY, should be controlled, and values may even be encrypted in transit.
SNMP versions before SNMPv3 did not include adequate security, and deploying them is NOT RECOMMENDED. Implementations SHOULD provide the SNMPv3 security features, and those claiming SNMPv3 compliance MUST fully support authentication and privacy with the User-based Security Model and the AES cipher algorithm. They MAY also support the Transport Security Model with a secure transport such as SSH or TLS/DTLS.
Even a read-only list can tell a snoop how your machine is built, so only trusted people should be allowed to look, and the messages should be locked.