allow an attacker to remove logs of packet and byte counts forwarded
on a Service Flow. If such logs were used for billing, the attacker
would obtain free service.
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 docsIetfQosServiceClassTable provides a template of QOS
parameters such as maximum rate limits for a named service
class. Changing these parameters would allow an attacker to
obtain an unauthorized class of service.
o The docsIetfQosServiceClassPolicyTable applies CMTS vendor
proprietary policies for packet forwarding, including
dropping, scheduling, notification, or other policies.
Changing this table could allow an attacker to deny service to
all subscribers of the CMTS or could grant the attacker
unauthorized forwarding policies.
o The docsIetfQosServiceFlowLogControl object controls the
deletion of entries in the docsIetfQosServiceFlowLogTable,
which acts as a historical "detail record" of DOCSIS Service
Flow packets and bytes transmitted. Such records may be used
for billing purposes, so the unauthorized deletion of the
records can result in free service.
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 Unauthorized SNMP GET access of the docsIetfQosPktClassTable
or docsIetfQosPHSTable can allow an attacker to learn IP
addresses permitted to have enhanced quality of service, for
possible spoofing. This table typically contains the IP
addresses involved in voice-over-IP sessions, for example.
o Unauthorized SNMP GET access of the docsIetfQosParamSetTable
allows an attacker to learn the names of Service Classes that
are permitted to have enhanced QoS service, and the values of
that enhanced service. That name can be referenced in an
unauthorized DOCSIS cable modem configuration file to obtain
enhanced service.
o Unauthorized SNMP GET access of the
docsIetfQosServiceFlowTable can tell an attacker when Service
Flows are active, e.g., when a voice-over-IP call is in
progress.
Unauthorized SNMP GET access of the
docsIetfQosServiceFlowLogTable can expose private information
about network usage.
o Unauthorized SNMP GET access of the
docsIetfQosServiceFlowStatsTable,
docsIetfQosUpstreamStatsTable,
docsIetfQosDynamicServiceStatsTable,
docsIetfQosServiceFlowLogTable, and
docsIetfQosCmtsMacToSrvFlowTable can tell an attacker the
volume of traffic to and from any Service Flow in the system,
resulting in loss of privacy of the amount and direction of
data transfer.
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 [15],
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 in this document uses the following IANA-assigned
OBJECT IDENTIFIER values recorded in the SMI Numbers registry:
Descriptor OBJECT IDENTIFIER Value
-------------- -----------------------
docsIetfQosMIB { mib-2 127 }
8. Acknowledgements
The authors gratefully acknowledge the comments and suggestions of
the IP over Cable Data Network (IPCDN) Working Group (especially the
co-chairs Richard Woundy and Jean-Francois Mule) as well as the
contributions of the Operation and Management Area Director, Bert
Wijnen.
9. Normative References
[1] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of
Management Information Version 2 (SMIv2)", STD 58, RFC 2578,
April 1999.
[2] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual
Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[3] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance
Statements for SMIv2", STD 58, RFC 2580, April 1999.
[4] "Data-Over-Cable Service Interface Specifications: Radio
Frequency Interface Specification SP-RFIv2.0-I06-040804",
DOCSIS, August 2004,
http://www.cablelabs.com/specifications/archives/.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[6] St. Johns, M., "Cable Device Management Information Base for
DOCSIS compliant Cable Modems and Cable Modem Termination
Systems", RFC 2669, August 1999.
[7] St. Johns, M., "Radio Frequency (RF) Interface Management
Information Base for MCNS/DOCSIS compliant RF interfaces", RFC
2670, August 1999.
[8] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder,
"Textual Conventions for Internet Network Addresses", RFC 4001,
February 2005.
[9] Grossman, D., "New Terminology and Clarifications for Diffserv",
RFC 3260, April 2002.
[10] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of
Explicit Congestion Notification (ECN) to IP", RFC 3168,
September 2001.
[11] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB",
RFC 2863, June 2000.
[12] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for
Describing Simple Network Management Protocol (SNMP) Management
Frameworks", STD 62, RFC 3411, December 2002.
[13] Baker, F., Chan, K., and A. Smith, "Management Information Base
for the Differentiated Services Architecture", RFC 3289, May
2002.
[14] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
10. Informative References
[15] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction
and Applicability Statements for Internet-Standard Management
Framework", RFC 3410, December 2002.
Authors’ Addresses
Michael Patrick
Motorola Broadband Communications Sector
111 Locke Drive
Marlborough, MA 01752
Phone: (508) 786-7563
EMail: michael.patrick@motorola.com
William Murwin
Motorola Broadband Communications Sector
111 Locke Drive
Marlborough, MA 01752
Phone: (508) 786-7594
EMail: w.murwin@motorola.com
Full Copyright Statement
Copyright (C) The Internet Society (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 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 provided by the IETF
Administrative Support Activity (IASA).