Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 4639

Cable Device Management Information Base for Data-Over-Cable Service Interface Specification (DOCSIS) Compliant Cable Modems and Cable Modem Termination Systems

Pages: 88
Proposed Standard
Updated by:  9141
Obsoletes:  2669
Part 5 of 5 – Pages 78 to 88
First   Prev   None

Top   ToC   RFC4639 - Page 78   prevText

5. Acknowledgements

This document is a production of the IPCDN Working Group and is a revision of RFC 2669, "Cable Device Management Information Base for DOCSIS-Compliant Cable Modems and Cable Modem Termination Systems" [RFC2669]. Mike St. Johns and Guenter Roeck served well as the editors of previous versions of this MIB module. The editor specifically wishes to thank Howard Abramson, Eduardo Cardona, Andre Lejeune, Kevin Marez, Jean-Francois Mule, Greg Nakanishi, Pak Siripunkaw, Boris Tsekinovski, Randy Presuhn, Bert Wijnen, and Bill Yost for their contributions to this document.

5.1. Revision Descriptions

This document contains the following revisions over RFC 2669: o All IPv4 address objects were either deprecated and replaced or mirrored with IPv6 objects, where appropriate, following the guidelines of RFC 4001 [RFC4001]. In particular, docsDevCpeInetTable was added, and the docsDevFilterGroup objects were deprecated in favor of the DiffServ MIB. o Objects that were obviated by SNMPv3 and the SNMP Coexistence MIBs have been deprecated; e.g., docsDevNmAccessTable. o A new object, docsDevIgmpModeControl, has been added to control passive versus active IGMP modem operation. o A new object, docsDevMaxCpe, has been added to report the maximum number of CPEs granted network access across the CM. o A new object, docsDevSwServerTransportProtocol, has been added to docsDevSoftware, and other object DESCRIPTIONs have been modified, to enable the use of either TFTP or HTTP for software downloads to the device.
Top   ToC   RFC4639 - Page 79
   o  A new object, docsDevEvThrottleThresholdExceeded, has been added
      to replace docsDevEvThrottleInhibited for simplification of event
      threshold management.

   o  The docsDevEvReporting object has been modified to enable local
      logging to the internal volatile log, and not to the internal
      non-volatile log.

   o  Minor updates to the description text have been made to a number
      of objects to clarify their meaning.

   o  The compliance statements were updated to reflect current
      requirements (including making the docsDevCpe objects optional)
      and split between CM and CMTS devices.

   o  Text was added to indicate support of the SNMP Notification MIB
      [RFC3413] and Notification Log MIB [RFC3014] modules.

6. Security Considerations

This MIB module relates to a system that will provide metropolitan public internet access. As such, improper manipulation of the objects represented by this MIB module may result in denial of service to a large number of end-users. In addition, manipulation of docsDevNmAccessTable, docsDevFilterLLCTable, docsDevFilterIpTable, docsDevFilterInetTable, and the elements of the docsDevCpe and docsDevCpeInetTable groups may allow an end-user to increase his or her service levels, spoof his or her IP addresses, change the permitted management stations, or affect other end-users in either a positive or negative manner. It is recommended that the implementors prevent the "tiny fragment" and "overlapping fragment" attacks for the IP filtering tables in this MIB module, as discussed in [RFC1858] and [RFC3128]. Prevention of these attacks can be implemented with the following rules, when TCP source and/or destination port filtering is enabled: o Admit all packets with fragment offset >= 2. o Discard all packets with fragment offset = 1, or with fragment offset = 0 AND fragment payload length < 16. o Apply filtering rules to all packets with fragment offset = 0. This MIB module does not affect confidentiality of services on a cable modem system. [BPI] and [BPIPLUS] specify the implementation of the DOCSIS Baseline Privacy and Baseline Privacy Plus mechanisms for data transmission confidentiality.
Top   ToC   RFC4639 - Page 80
   There are a number of management objects defined in this MIB module
   with a MAX-ACCESS clause of read-write and/or read-create.  Such
   objects may be considered sensitive or vulnerable in some network
   environments.  The support for SET operations in a non-secure
   environment without proper protection can have a negative effect on
   network operations.  These are the tables and objects and their

   o  The use of docsDevNmAccessTable to specify management stations is
      considered only limited protection and does not protect against
      attacks that spoof the management station's IP address.  The use
      of stronger mechanisms, such as SNMPv3 security, should be
      considered, where possible.  Specifically, SNMPv3 USM [RFC3414]
      and VACM [RFC3415] MUST be used with any v3 agent that implements
      this MIB module.

   o  The CM may have its software changed by the actions of the
      management system using a combination of the following objects:
      docsDevSwServer, docsDevSwFilename, docsDevSwAdminStatus,
      docsDevSwServerAddressType, docsDevSwServerAddress, and
      docsDevSwServerTransportProtocol.  An improper software download
      may result in substantial vulnerabilities and the loss of the
      ability of the management system to control the cable modem.  A
      cable device SHOULD implement the code verification mechanisms of
      [BPIPLUS] to verify the source and integrity of downloaded
      software images.

   o  The device may be reset by setting docsDevResetNow = true(1).
      This causes the device to reload its configuration files, as well
      as to eliminate all previous non-persistent network management
      settings.  As such, this may provide a vector for attacking the

   o  Setting docsDevEvThrottleAdminStatus = unconstrained(1) (which is
      also the DEFVAL) may cause flooding of traps, which can disrupt
      network service.  Additionally, docsDevThrottleThreshold and
      docsDevThrottleInterval could also be set to high values that may
      cause a disruption in service.

   o  Setting docsDevDateTime to an arbitrary (incorrect) value would
      merely cause the device to record incorrect timestamps on many
      events/actions that rely on this object for reporting.

   o  Setting docsDevEvControl to resetLog(1) will delete any event log
      history and could potentially impact debugging/troubleshooting

   o  Setting docsDevEvSyslog.
Top   ToC   RFC4639 - Page 81
   o  Setting docsDevEvReporting to enable syslog reporting, along with
      a redirect of the syslog server could allow access to sensitive
      information on network devices.  Modifying docsDevEvSyslog,
      docsDevEvSyslogAddressType, or docsDevEvSyslogAddress could allow
      a redirect of sensitive information.

   o  Setting docsDevFilterLLCnmatchedAction or docsDevFilterIpDefault
      could cause significant changes to default traffic filtering on a

   o  Setting docsDevCpeEnroll to any(2) could cause the
      docsDevFilterCPETable to be populated, which may not be the
      intended functionality.

   o  Setting docsDevCpeIpMax to a value other than that intended by the
      MSO may allow a user to provision more devices than the MSO would

   o  Setting values in the docsDevNmAccess table can potentially
      introduce a mechanism for users to use a local NMS device and
      manipulate other settings in the CM or CMTS.

   o  Setting values in the docsDevFilterLLC and docsDevFilterIP tables
      can allow or deny access to certain devices that the MSO does not

   o  Setting docsDevCpeStatus and docsDevCpeInetRowStatus may allow
      users to provision more devices than were intended by the MSO, or
      to provision different ones.

   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.  It is thus important to
   control even GET access to these objects and possibly to even encrypt
   the values of these objects when sending them over the network via
   SNMP.  These are the tables and objects and their

   o  Rows from docsDevNmAccessTable may provide sufficient information
      for attackers to spoof management stations that have management
      access to the device.

   o  The docsDevSwCurrentVers object may provide hints as to the
      software vulnerabilities of the cable device.

   o  The docsDevFilterLLCTable and docsDevFilterLLCTable may provide
      clues for attacking the cable device and other subscriber devices.
Top   ToC   RFC4639 - Page 82
      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 this MIB module.

      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 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)

7. IANA Considerations

The MIB module defined in this document uses the following IANA- assigned OBJECT IDENTIFIER values, recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER value ---------- ----------------------- docsDevMIB { mib-2 69 }
Top   ToC   RFC4639 - Page 83

8. References

8.1. Normative References

[BPI] SCTE Data Standards Subcommittee, "Data-Over-Cable Service Interface Specifications: DOCSIS 1.0 Baseline Privacy Interface Specification SCTE 22-2 2002", 2002, <>. [BPIPLUS] CableLabs, "Data-Over-Cable Service Interface Specifications: Baseline Privacy Plus Interface Specification CM-SP-BPI+_I12-050812", August 2005, <>, <>. [ITU-T_J.112] ITU-T Recommendation J.112 (3/98), "Transmission Systems for Interactive Cable Television Services, J.112, International Telecommunications Union", March 1998, <>. [MTA-PROV] CableLabs, "PacketCable(TM) 1.5 Specification: MTA Device Provisioning PKT-SP-PROV1.5-I02-050812", August 2005, <>, <>. [OSSI1.0] SCTE Data Standards Subcommittee, "Data-Over-Cable Service Interface Specification: DOCSIS 1.0 Operations Support System Interface (OSSI), SCTE 22-3 2002", 2002, <>. [OSSI1.1] SCTE Data Standards Subcommittee, "DOCSIS 1.1 Part 3: Operations Support System Interface ANSI/SCTE 23-3 2005", 2005, <>. [OSSI2.0] CableLabs, "Data-Over-Cable Service Interface Specifications: Operations Support System Interface Specification SP-OSSIv2.0-I09-050812", August 2005, <>, <>. [RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350, July 1992. [RFC4502] Waldbusser, S., "Remote Network Monitoring Management Information Base Version 2", RFC 4502, May 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
Top   ToC   RFC4639 - Page 84
   [RFC2578]     McCloghrie, K., Perkins, D., Schoenwaelder J., Case,
                 J., Rose, M. and S. Waldbusser, "Structure of
                 Management Information Version 2 (SMIv2)", STD 58, RFC
                 2578, April 1999.

   [RFC2579]     McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,
                 J., Rose, M. and S. Waldbusser , "Textual Conventions
                 for SMIv2", STD 58, RFC 2579, April 1999.

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

   [RFC2616]     Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
                 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
                 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC2669]     St. Johns, M., "DOCSIS Cable Device MIB Cable Device
                 Management Information Base for DOCSIS compliant Cable
                 Modems and Cable Modem Termination Systems", RFC 2669,
                 August 1999.

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

   [RFC3014]     Kavasseri, R., "Notification Log MIB", RFC 3014,
                 November 2000.

   [RFC3289]     Baker, F., Chan, K., and A. Smith, "Management
                 Information Base for the Differentiated Services
                 Architecture", RFC 3289, May 2002.

   [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.

   [RFC3413]     Levi, D., Meyer, P., and B. Stewart, "Simple Network
                 Management Protocol (SNMP) Applications", STD 62, RFC
                 3413, December 2002.

   [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.
Top   ToC   RFC4639 - Page 85
   [RFC3415]     Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
                 Access Control Model (VACM) for the Simple Network
                 Management Protocol (SNMP)", STD 62, RFC 3415, December

   [RFC3418]     Presuhn, R., "Management Information Base (MIB) for the
                 Simple Network Management Protocol (SNMP)", STD 62, RFC
                 3418, December 2002.

   [RFC3584]     Frye, R., Levi, D., Routhier, S., and B. Wijnen,
                 "Coexistence between Version 1, Version 2, and Version
                 3 of the Internet-standard Network Management
                 Framework", BCP 74, RFC 3584, August 2003.

   [RFC868]      Postel, J. and K. Harrenstien, "Time Protocol", STD 26,
                 RFC 868, May 1983.

   [RFC4001]     Daniele, M., Haberman, B., Routhier, S., and J.
                 Schoenwaelder, "Textual Conventions for Internet
                 Network Addresses", RFC 4001, February 2005.

   [RFI1.0]      SCTE Data Standards Subcommittee, "Data-Over-Cable
                 Service Interface Specifications: DOCSIS 1.0 Radio
                 Frequency Interface Specification SCTE 22-1 2002",
                 2002, <>.

   [RFI1.1]      SCTE Data Standards Subcommittee, "DOCSIS 1.1 Part 1:
                 Radio Frequency Interface ANSI/SCTE 23-1 2005", 2005,

   [RFI2.0]      CableLabs, "Data-Over-Cable Service Interface
                 Specifications: Radio Frequency Interface Specification
                 SP-RFI2.0-I11-060602", June 2006,

8.2. Informative References

[RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security Considerations r IP Fragment Filtering", RFC 1858, October 1995. [RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext Traner Protocol -- HTTP/1.0", RFC 1945, May 1996. [RFC3128] Miller, I., "Protection Against a Variant of the Tiny Fragment Attack (RFC 1858)", RFC 3128, June 2001.
Top   ToC   RFC4639 - Page 86
   [RFC3164]     Lonvick, C., "The BSD Syslog Protocol", RFC 3164,
                 August 2001.

   [RFC3617]     Lear, E., "Uniform Resource Identifier (URI) Scheme and
                 Applicbility Statement for the Trivial File Transfer
                 Protocol (TFTP)", RFC 3617, October 2003.

   [RFC4547]     Ahmad, A. and G. Nakanishi, "Event Notification
                 Management Information Base for Data over Cable Service
                 Interface Specifications (DOCSIS) Compliant Cable
                 Modems and Cable Modem Termination Systems", RFC 4547,
                 June 2006.

   [RFC1224]     Steinberg, L., "Techniques for managing asynchronously
                 generated alerts", RFC 1224, May 1991.

   [RFC3410]     Case, J., Mundy, R., Partain, D., and B. Stewart,
                 "Introduction and Applicability Statements for
                 Internet-Standard Management Framework", RFC 3410,
                 December 2002.

   [RFC4036]     Sawyer, W., "Management Information Base for Data Over
                 Cable Service Interface Specification (DOCSIS) Cable
                 Modem Termination Systems for Subscriber Management",
                 RFC 4036, April 2005.

   [RFC4323]     Patrick, M. and W. Murwin, "Data Over Cable System
                 Interface Specification Quality of Service Management
                 Information Base (DOCSIS-QoS MIB)", RFC 4323, January

   [MULPI3.0]    CableLabs, "Data-Over-Cable Service Interface
                 Specifications: DOCSIS 3.0 MAC and Upper Layer
                 Protocols Interface Specification CM-SP-MULPIv3.0-I01-
                 060804", August 2006,
Top   ToC   RFC4639 - Page 87

Authors' Addresses

Richard Woundy Comcast Cable 27 Industrial Avenue Chelmsford, MA 01824 USA Phone: +1 978 244 4010 EMail: Kevin Marez Motorola Corporation 6450 Sequence Drive San Diego, CA 92121 USA Phone: +1 858 404 3785 EMail:
Top   ToC   RFC4639 - Page 88
Full Copyright Statement

   Copyright (C) The IETF Trust (2006).

   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


   Funding for the RFC Editor function is currently provided by the
   Internet Society.