is designed for testing purposes; therefore, it is not
RECOMMENDED for use in commercial deployments [DOCSIS].
Administrators can make use of View-based Access Control
(VACM) introduced in section 7.9 of [RFC3410] to restrict
write access to this object.
docsBpi2CmtsCheckCertValidityPeriods:
A malicious SET in this object that enables the period
validity and a wrong clock time in the CMTS could cause denial
of service, as CM authorization requests will be rejected.
For more details in the validation of CM certificates, refer to
section 9 of [DOCSIS] .
Objects related to the CM only:
Objects in docsBpi2CmDeviceCertTable
docsBpi2CmDeviceCmCert:
This object is not harmful, considering that a CM received a
Certificate during the manufacturing process. Therefore, the
object access becomes read-only. See the object DESCRIPTION
clause in section 3 for details.
Objects for Secure Software Download in table
docsBpi2CodeDownloadControl:
docsBpi2CodeCvcUpdate:
A malicious SET on this object may not constitute a risk,
since the CM holds the DOCSIS root key to verify the CVC
authenticity. The operator, if configured, could receive a
notification for event occurrences, which may lead to
detecting the source of the attack. Moreover, [DOCSIS]
recommends that CMs CVC be regularly updated to minimize the
risk of potential code-signing keys being compromised (e.g.,
by configuration file).
Objects related to the CMTS only:
Objects in docsBpi2CmtsProvisionedCmCertTable and
docsBpi2CmtsCACertTable containing CM Certificates and Certificate
Authority information, respectively:
docsBpi2CmtsProvisionedCmCertTrust,
docsBpi2CmtsProvisionedCmCertStatus,
docsBpi2CmtsProvisionedCmCert,
docsBpi2CmtsCACertStatus,
docsBpi2CmtsCACert:
A malicious SET on these objects may constitute a denial of
service attack that will be experienced after the CMs perform
authorization requests. It does not affect CMs in the
authorized state.
Objects in multicast tables docsBpi2CmtsIpMulticastMapTable and
docsBpi2CmtsMulticastAuthTable:
docsBpi2CmtsIpMulticastAddressType,
docsBpi2CmtsIpMulticastAddress,
docsBpi2CmtsIpMulticastMaskType,
docsBpi2CmtsIpMulticastMask,
docsBpi2CmtsIpMulticastSAId,
docsBpi2CmtsIpMulticastSAType:
Malicious SET on these objects may cause misconfiguration,
causing interruption of the users’ active multicast
applications.
docsBpi2CmtsIpMulticastDataEncryptAlg,
docsBpi2CmtsIpMulticastDataAuthentAlg:
Malicious SETs on these objects may create service
misconfiguration, causing service interruption or theft of
service if encryption algorithms are removed for the multicast
groups.
docsBpi2CmtsIpMulticastMapControl,
docsBpi2CmtsMulticastAuthControl:
Malicious SETs on these objects may remove and/or disable
customers and/or multicast groups, causing service disruption.
This may also constitute theft of service by authorizing non-
subscribed users to multicast groups or by adding other
multicast groups in the forward path.
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 and/or NOTIFY 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:
Objects in docsBpi2CmBaseTable, docsBpi2CmTEKTable,
docsBpi2CmtsBaseTable, docsBpi2CmtsAuthTable,
docsBpi2CmtsTEKTable, docsBpi2CmtsProvisionedCmCertTable, and
docsBpi2CmtsCACertTable:
If this information is accessible, attackers may use it to
distinguish users configured to work without data encryption
(e.g., docsBpi2CmPrivacyEnable) and to know current Baseline
Privacy parameters in the network.
Objects in docsBpi2CmIpMulticastMapTable and
docsBpi2CmtsMulticastAuthTable:
In addition to the vulnerabilities around BPI plus multicast
objects described in the previous part, the read-only objects
of this table may help attackers monitor the status of the
intrusion.
Objects in docsBpi2CodeDownloadControl:
In addition to the vulnerability of the read-write object
docsBpi2CodeCvcUpdate, attackers may be able to monitor the
status of a denial of service using Secure Software Download.
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.
BPI+ Encryption Algorithms:
The BPI+ Traffic Encryption Keys (TEK) defined in the DOCSIS BPI+
specification [DOCSIS] use 40-bit or 56-bit DES for encryption (DES
CBC mode). Currently, there is no mechanism or algorithm defined for
data integrity.
Due to the DES cryptographic weaknesses, future revisions of the
DOCSIS BPI+ specification should introduce more advanced encryption
algorithms, as proposed in the DocsBpkmDataEncryptAlg textual
convention, to overcome the progress in cheaper and faster hardware
or software decryption tools. Future revisions of the DOCSIS BPI+
specification [DOCSIS] should also adopt authentication algorithms,
as described in the DocsBpkmDataAuthentAlg textual convention.
It is important to note that frequent key changes do not necessarily
help in mitigating or reducing the risks of a DES attack. Indeed,
the traffic encryption keys, which are configured on a per cable
modem basis and per BPI+ multicast group, can be utilized to decrypt
old traffic, even when they are no longer in active use.
Note that, not exempt to the same recommendations above, the CM BPI+
authorization protocol uses triple DES encryption, which offers
improved robustness in comparison to DES for CM authorization and TEK
re-key management.
8. IANA Considerations
The MIB module in this document uses the following IANA-assigned
OBJECT IDENTIFIER value, recorded in the SMI Numbers registry:
Descriptor OBJECT IDENTIFIER Value
---------- -----------------------
docsBpi2MIB { mib-2 126 }
Authors’ Addresses
Stuart M. Green
EMail: rubbersoul3@yahoo.com
Kaz Ozawa
Automotive Systems Development Center
TOSHIBA CORPORATION
1-1, Shibaura 1-Chome
Minato-ku, Tokyo 105-8001
Japan
Phone: +81-3-3457-8569
Fax: +81-3-5444-9325
EMail: Kazuyoshi.Ozawa@toshiba.co.jp
Alexander Katsnelson
Phone: +1-303-680-3924
EMail: katsnelson6@peoplepc.com
Eduardo Cardona
Cable Television Laboratories, Inc.
858 Coal Creek Circle
Louisville, CO 80027- 9750
U.S.A.
Phone: +1 303 661 9100
EMail: e.cardona@cablelabs.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
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 currently provided by the
Internet Society.
<!--
erfc("4131");
// -->