Movatterモバイル変換

Internet Engineering Task Force (IETF)                          E. BeiliRequest for Comments: 7124                              Actelis NetworksUpdates:5066                                              February 2014Category: Standards TrackISSN: 2070-1721Ethernet in the First Mile Copper (EFMCu) Interfaces MIBAbstract   This document updatesRFC 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 inSection 2 of RFC 5741.   Information about the current status of this document, any errata,   and how to provide feedback on it may be obtained athttp://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 toBCP 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 2014Table of Contents1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .22.  The Internet-Standard Management Framework  . . . . . . . . .33.  Mapping between EFM-CU-MIB and IEEE8023-EFM-CU-MIB  . . . . .34.  Updating the MIB Modules  . . . . . . . . . . . . . . . . . .35.  Security Considerations . . . . . . . . . . . . . . . . . . .46.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .57.  References  . . . . . . . . . . . . . . . . . . . . . . . . .57.1.  Normative References  . . . . . . . . . . . . . . . . . .57.2.  Informative References  . . . . . . . . . . . . . . . . .51.  IntroductionRFC 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 inRFC 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 20142.  The Internet-Standard Management Framework   For a detailed overview of the documents that describe the current   Internet-Standard Management Framework, please refer tosection 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 inRFC2119 [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 inRFC 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 20145.  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 20146.  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 updatesRFC 5066, authored by Edward Beili of Actelis   Networks, and produced by the now-concluded HUBMIB working group.7.  References7.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)",RFC5591, 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.comBeili                        Standards Track                    [Page 6]