From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7124.txt | 339 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 339 insertions(+) create mode 100644 doc/rfc/rfc7124.txt (limited to 'doc/rfc/rfc7124.txt') diff --git a/doc/rfc/rfc7124.txt b/doc/rfc/rfc7124.txt new file mode 100644 index 0000000..1146a88 --- /dev/null +++ b/doc/rfc/rfc7124.txt @@ -0,0 +1,339 @@ + + + + + + +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. + + + + + + +Beili Standards Track [Page 1] + +RFC 7124 EFMCu Interfaces MIB February 2014 + + +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. + + + + + + + + +Beili Standards Track [Page 2] + +RFC 7124 EFMCu Interfaces MIB February 2014 + + +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. + + + + + + + +Beili Standards Track [Page 3] + +RFC 7124 EFMCu Interfaces MIB February 2014 + + +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. + + + + + + + + +Beili Standards Track [Page 4] + +RFC 7124 EFMCu Interfaces MIB February 2014 + + +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", + . + + [IEEE802.3.1] + IEEE, "IEEE Standard for Management Information Base (MIB) + Definitions for Ethernet", IEEE Std 802.3.1-2013, June + 2013, . + + + + + + +Beili Standards Track [Page 5] + +RFC 7124 EFMCu Interfaces MIB February 2014 + + + [IEEE802.3] + IEEE, "802.3 Ethernet Working Group", + . + + [LIST802.3.1] + IEEE, "802.3 MIB Email Reflector", + . + + [OPSAWG] IETF, "Operations and Management Area Working Group + (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 + + + + + + + + + + + + + +Beili Standards Track [Page 6] + -- cgit v1.2.3