RFC 4639
Cable Device Management Information Base for Data-Over-Cable Service Interface Specification (DOCSIS) Compliant Cable Modems and Cable Modem Termination Systems
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.
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.
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
sensitivity/vulnerability:
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
system.
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
efforts.
o Setting docsDevEvSyslog.
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
device.
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
like.
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
want.
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
sensitivity/vulnerability:
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.
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)
them.
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 }
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, <http://www.scte.org/standards/>. [BPIPLUS] CableLabs, "Data-Over-Cable Service Interface Specifications: Baseline Privacy Plus Interface Specification CM-SP-BPI+_I12-050812", August 2005, <http://www.cablemodem.com/specifications/>, <http://www.cablelabs.com/specifications/archives/>. [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, <http://www.itu.int/ITU-T/studygroups/com09/>. [MTA-PROV] CableLabs, "PacketCable(TM) 1.5 Specification: MTA Device Provisioning PKT-SP-PROV1.5-I02-050812", August 2005, <http://www.packetcable.com/specifications/>, <http://www.cablelabs.com/specifications/archives/>. [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, <http://www.scte.org/standards/>. [OSSI1.1] SCTE Data Standards Subcommittee, "DOCSIS 1.1 Part 3: Operations Support System Interface ANSI/SCTE 23-3 2005", 2005, <http://www.scte.org/standards/>. [OSSI2.0] CableLabs, "Data-Over-Cable Service Interface Specifications: Operations Support System Interface Specification SP-OSSIv2.0-I09-050812", August 2005, <http://www.cablemodem.com/specifications/>, <http://www.cablelabs.com/specifications/archives/>. [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.
[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.
[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 2002. [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, <http://www.scte.org/standards/>. [RFI1.1] SCTE Data Standards Subcommittee, "DOCSIS 1.1 Part 1: Radio Frequency Interface ANSI/SCTE 23-1 2005", 2005, <http://www.scte.org/standards/>. [RFI2.0] CableLabs, "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFI2.0-I11-060602", June 2006, <http://www.cablemodem.com/specifications/>, <http://www.cablelabs.com/specifications/archives/>.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.
[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 2006. [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, <http://www.cablemodem.com/specifications/>, <http://www.cablelabs.com/specifications/archives/>.
Authors' Addresses
Richard Woundy Comcast Cable 27 Industrial Avenue Chelmsford, MA 01824 USA Phone: +1 978 244 4010 EMail: richard_woundy@cable.comcast.com Kevin Marez Motorola Corporation 6450 Sequence Drive San Diego, CA 92121 USA Phone: +1 858 404 3785 EMail: kevin.marez@motorola.com
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 "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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.