RFC 5066
Ethernet in the First Mile Copper (EFMCu) Interfaces MIB
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.
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
environment.
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
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.
[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, <http://www.itu.int/rec/T-REC-G.991.2/en>. [G.993.1] ITU-T, "Very High speed Digital Subscriber Line transceivers", ITU-T Recommendation G.993.1, June 2004, <http://www.itu.int/rec/T-REC-G.993.1/en>. [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.
[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", <http://www.ietf.org/html.charters/OLD/ hubmib-charter.html>. [IANAifType-MIB] Internet Assigned Numbers Authority (IANA), "IANAifType Textual Convention definition", <http://www.iana.org/assignments/ianaiftype-mib>. [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.
[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: edward.beili@actelis.com
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 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 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 http://www.ietf.org/ipr. 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 ietf-ipr@ietf.org.