Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 5066

Ethernet in the First Mile Copper (EFMCu) Interfaces MIB

Pages: 90
Proposed Standard
Updated by:  7124
Part 4 of 4 – Pages 84 to 90
First   Prev   None

Top   ToC   RFC5066 - Page 84   prevText

7. Security Considerations

There is a number of managed objects defined in the EFM-CU-MIB module that have a MAX-ACCESS clause of read-write or read-create. Most objects are writeable only when the link is Down. Writing to these objects can have potentially disruptive effects on network operation, for example: o Changing of efmCuPmeAdminSubType may lead to a potential locking of the link, as peer PMEs of the same subtype cannot exchange handshake messages. o Changing of efmCuPAFAdminState to enabled may lead to a potential locking of the link, if the peer PHY does not support PAF. o Changing of efmCuPAFDiscoveryCode, before the discovery operation, may lead to a wrongful discovery, for example, when two -O ports are connected to the same multi-PME -R port and both -O ports have the same Discovery register value.
Top   ToC   RFC5066 - Page 85
   o  Changing PCS or PME configuration parameters (e.g., profile of a
      PCS or PME via efmCuAdminProfile or efmCuPmeAdminProfile) may lead
      to anything from link quality and rate degradation to a complete
      link initialization failure, as ability of an EFMCu port to
      support a particular configuration depends on the copper

   o  Activation of a PME can cause a severe degradation of service for
      another EFMCu PHY, whose PME(s) may be affected by the cross-talk
      from the newly activated PME.

   o  Removal of a PME from an operationally 'up' EFMCu port,
      aggregating several PMEs, may cause port's rate degradation.

   The user of the EFM-CU-MIB module must therefore be aware that
   support for SET operations in a non-secure environment without proper
   protection can have a negative effect on network operations.

   The readable objects in the EFM-CU-MIB module (i.e., those with MAX-
   ACCESS other than not-accessible) may be considered sensitive in some
   environments since, collectively, they provide information about the
   performance of network interfaces and can reveal some aspects of
   their configuration.  In particular, since EFMCu can be carried over
   Unshielded Twisted Pair (UTP) voice-grade copper in a bundle with
   other pairs belonging to another operator/customer, it is
   theoretically possible to eavesdrop to an EFMCu transmission simply
   by "listening" to a cross-talk from the EFMCu pairs, especially if
   the parameters of the EFMCu link in question are known.

   In such environments, it is important to control also GET and NOTIFY
   access to these objects and possibly even to encrypt their values
   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),
   even then, 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 these MIB modules.

   It is RECOMMENDED that implementers consider the security features as
   provided by the SNMPv3 framework (see [RFC3410], section 8),
   including full support for the SNMPv3 cryptographic mechanisms (for
   authentication and privacy).

   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
Top   ToC   RFC5066 - Page 86
   instance of these MIB modules 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.

8. IANA Considerations

Object identifiers for the efmCuMIB MODULE-IDENTITY and ifCapStackMIB MODULE-IDENTITY have been allocated by IANA in the MIB-2 sub-tree.

9. Acknowledgments

This document was produced by the [HUBMIB] working group, whose efforts were greatly advanced by the contributions of the following people (in alphabetical order): Udi Ashkenazi (Actelis) Mike Heard Alfred Hoenes (TR-Sys) Marina Popilov (Actelis) Mathias Riess (Infineon) Dan Romascanu (Avaya) Matt Squire (Hatteras) Bert Wijnen (Alcatel)

10. References

10.1. Normative References

[802.3] IEEE, "IEEE Standard for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications", IEEE Std 802.3-2005, December 2005.
Top   ToC   RFC5066 - Page 87
   [802.3ah]         IEEE, "IEEE Standard for Information technology -
                     Telecommunications and information exchange between
                     systems - Local and metropolitan area networks -
                     Specific requirements - Part 3: Carrier Sense
                     Multiple Access with Collision Detection (CSMA/CD)
                     Access Method and Physical Layer Specifications -
                     Amendment: Media Access Control Parameters,
                     Physical Layers and Management Parameters for
                     Subscriber Access Networks", IEEE Std 802.3ah-2004,
                     September 2004.

   [G.991.2]         ITU-T, "Single-pair High-speed Digital Subscriber
                     Line (SHDSL) transceivers", ITU-T
                     Recommendation G.991.2, December 2003,

   [G.993.1]         ITU-T, "Very High speed Digital Subscriber Line
                     transceivers", ITU-T Recommendation G.993.1,
                     June 2004,

   [RFC2119]         Bradner, S., "Key words for use in RFCs to Indicate
                     Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2578]         McCloghrie, K., Ed., Perkins, D., Ed., and J.
                     Schoenwaelder, Ed., "Structure of Management
                     Information Version 2 (SMIv2)", STD 58, RFC 2578,
                     April 1999.

   [RFC2579]         McCloghrie, K., Ed., Perkins, D., Ed., and J.
                     Schoenwaelder, Ed., "Textual Conventions for
                     SMIv2", STD 58, RFC 2579, April 1999.

   [RFC2580]         McCloghrie, K., Perkins, D., and J. Schoenwaelder,
                     "Conformance Statements for SMIv2", STD 58,
                     RFC 2580, April 1999.

   [RFC2863]         McCloghrie, K. and F. Kastenholz, "The Interfaces
                     Group MIB", RFC 2863, June 2000.

   [RFC2864]         McCloghrie, K. and G. Hanson, "The Inverted Stack
                     Table Extension to the Interfaces Group MIB",
                     RFC 2864, June 2000.

   [RFC3411]         Harrington, D., Presuhn, R., and B. Wijnen, "An
                     Architecture for Describing Simple Network
                     Management Protocol (SNMP) Management Frameworks",
                     STD 62, RFC 3411, December 2002.
Top   ToC   RFC5066 - Page 88
   [RFC3635]         Flick, J., "Definitions of Managed Objects for the
                     Ethernet-like Interface Types", RFC 3635,
                     September 2003.

   [RFC4836]         Beili, E., "Definitions of Managed Objects for IEEE
                     802.3 Medium Attachment Units (MAUs)", RFC 4836,
                     April 2007.

   [T1.424]          ANSI, "Interface Between Networks and Customer
                     Installation Very-high-bit-rate Digital Subscriber
                     Lines (VDSL) Metallic Interface (DMT Based)",
                     American National Standard T1.424-2004, June 2004.

   [TS 101 270-1]    ETSI, "Transmission and Multiplexing (TM); Access
                     transmission systems on metallic access cables;
                     Very high speed Digital Subscriber Line (VDSL);
                     Part 1: Functional requirements", Technical
                     Specification TS 101 270-1, October 2005.

10.2. Informative References

[ANFP] Network Interoperability Consultative Committee (NICC), "Specification of the Access Network Frequency Plan (ANFP) applicable to transmission systems used on the BT Access Network", NICC Document ND1602:2005/08, August 2005. [HUBMIB] IETF, "Ethernet Interfaces and Hub MIB (hubmib) Charter", < hubmib-charter.html>. [IANAifType-MIB] Internet Assigned Numbers Authority (IANA), "IANAifType Textual Convention definition", <>. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [RFC4070] Dodge, M. and B. Ray, "Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Multiple Carrier Modulation (MCM) Line Coding", RFC 4070, May 2005. [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB Documents", BCP 111, RFC 4181, September 2005.
Top   ToC   RFC5066 - Page 89
   [RFC4319]         Sikes, C., Ray, B., and R. Abbi, "Definitions of
                     Managed Objects for High Bit-Rate DSL - 2nd
                     generation (HDSL2) and Single-Pair High-Speed
                     Digital Subscriber Line (SHDSL) Lines", RFC 4319,
                     December 2005.

   [RFC4837]         Khermosh, L., "Managed Objects of Ethernet Passive
                     Optical Networks (EPON)", RFC 4837, July 2007.

   [RFC4878]         Squire, M., "Definitions and Managed Objects for
                     Operations, Administration, and Maintenance (OAM)
                     Functions on Ethernet-Like Interfaces", RFC 4878,
                     June 2007.

Author's Address

Edward Beili Actelis Networks Bazel 25 Petach-Tikva Israel Phone: +972-3-924-3491 EMail:
Top   ToC   RFC5066 - Page 90
Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at