summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7124.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7124.txt')
-rw-r--r--doc/rfc/rfc7124.txt339
1 files changed, 339 insertions, 0 deletions
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",
+ <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>.
+
+
+
+
+
+
+Beili Standards Track [Page 5]
+
+RFC 7124 EFMCu Interfaces MIB February 2014
+
+
+ [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
+
+
+
+
+
+
+
+
+
+
+
+
+
+Beili Standards Track [Page 6]
+