tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5066

 
 
 

Ethernet in the First Mile Copper (EFMCu) Interfaces MIB

Part 4 of 4, p. 84 to 90
Prev RFC Part

 


prevText      Top      Up      ToC       Page 84 
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      Up      ToC       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
      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

Top      Up      ToC       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      Up      ToC       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,
                     <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.

Top      Up      ToC       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", <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.

Top      Up      ToC       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: edward.beili@actelis.com

Top      Up      ToC       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
   "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.