Movatterモバイル変換
[0]ホーム
[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Errata] [Info page]
INFORMATIONAL
Updated by:9141Errata ExistNetwork Working Group R. WoundyRequest for Comments: 3083 Cisco SystemsCategory: Informational March 2001Baseline Privacy Interface Management Information Basefor DOCSIS Compliant Cable Modems and Cable Modem Termination SystemsStatus of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved.Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP- based (Simple Network Management Protocol) management of the Baseline Privacy Interface (BPI), which provides data privacy for DOCSIS 1.0 (Data-Over-Cable Service Interface Specifications) compliant Cable Modems and Cable Modem Termination Systems. This MIB is defined as an extension to the DOCSIS Radio Frequency Interface MIB,RFC 2670. This memo specifies a MIB module in a manner that is compliant to the SMIv2 (Structure of Management Information Version 2). The set of objects is consistent with the SNMP framework and existing SNMP standards. CableLabs requires the implementation of this MIB in DOCSIS 1.0 cable modems that implement the Baseline Privacy Interface, as a prerequisite for DOCSIS 1.0 certification.Woundy Informational [Page 1]
RFC 3083 DOCSIS Baseline Privacy MIB March 2001Table of Contents1 The SNMP Management Framework ...................................22 Glossary ........................................................32.1 Authorization key .............................................32.2 BPI ...........................................................42.3 BPI+ ..........................................................42.4 CATV ..........................................................42.5 CM ............................................................42.6 CMTS ..........................................................42.7 DOCSIS ........................................................42.8 Downstream ....................................................42.9 Head-end ......................................................42.10 MAC Packet ...................................................42.11 MCNS .........................................................52.12 RF ...........................................................52.13 SID ..........................................................52.14 TEK ..........................................................52.15 Upstream .....................................................53 Overview ........................................................53.1 Structure of the MIB ..........................................53.2 Management requirements .......................................63.3 Textual convention ............................................74 Definitions .....................................................85 Acknowledgments ................................................406 References .....................................................407 Security Considerations ........................................428 Intellectual Property ..........................................439 Author's Address ...............................................4410 Full Copyright Statement ......................................451. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described inRFC 2571 [1]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16,RFC 1155 [2], STD 16,RFC 1212 [3] andRFC 1215 [4]. The second version, called SMIv2, is described in STD 58,RFC 2578 [5],RFC 2579 [6] andRFC 2580 [7]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15,RFC 1157 [8]. A second version of the SNMPWoundy Informational [Page 2]
RFC 3083 DOCSIS Baseline Privacy MIB March 2001 message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described inRFC 1901 [9] andRFC1906 [10]. The third version of the message protocol is called SNMPv3 and described inRFC 1906 [10],RFC 2572 [11] andRFC 2574 [12]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15,RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described inRFC 1905 [13]. o A set of fundamental applications described inRFC 2573 [14] and the view-based access control mechanism described inRFC 2575 [15]. A more detailed introduction to the current SNMP Management Framework can be found inRFC 2570 [24]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB.2. Glossary The terms in this document are derived either from normal cable system usage, or from the documents associated with the Data Over Cable Service Interface Specification process.2.1. Authorization key A key used to derive a key encryption key (used to encrypt TEKs), and to derive message authentication keys. When the CMTS communicates the authorization key to the CM, it encrypts the authorization key using the RSA public key of the CM [22].Woundy Informational [Page 3]
RFC 3083 DOCSIS Baseline Privacy MIB March 20012.2. BPI - Baseline Privacy Interface A term referring to the DOCSIS specification [18] for enabling simple data privacy in the DOCSIS 1.0 system. Management of the BPI is the focus of this document.2.3. BPI+ - Baseline Privacy Plus Interface A term referring to the DOCSIS specification [21] for enabling CM authentication and data privacy in the DOCSIS 1.1 system. Management of the BPI+ is not addressed in this document.2.4. CATV Originally "Community Antenna Television", now used to refer to any cable or hybrid fiber and cable system used to deliver video signals to a community.2.5. CM - Cable Modem A CM acts as a "slave" station in a DOCSIS compliant cable data system.2.6. CMTS - Cable Modem Termination System A generic term covering a cable bridge or cable router in a head-end. A CMTS acts as the master station in a DOCSIS compliant cable data system. It is the only station that transmits downstream, and it controls the scheduling of upstream transmissions by its associated CMs.2.7. DOCSIS "Data-Over-Cable Service Interface Specifications". A term referring to the ITU-T J.112 Annex B standard for cable modem systems [19].2.8. Downstream The direction from the head-end towards the subscriber.2.9. Head-end The origination point in most cable systems of the subscriber video signals. Generally also the location of the CMTS equipment.2.10. MAC Packet A DOCSIS PDU.Woundy Informational [Page 4]
RFC 3083 DOCSIS Baseline Privacy MIB March 20012.11. MCNS "Multimedia Cable Network System". Generally replaced in usage by DOCSIS.2.12. RF Radio Frequency.2.13 SID Service ID. The SID identifies a particular upstream bandwidth allocation and class-of-service management for DOCSIS, and identifies a particular bidirectional security association for BPI.2.14. TEK - Traffic Encryption Key Traffic Encryption Key, which is used for DES encryption of upstream and downstream traffic. When the CMTS communicates the TEK to the CM, it encrypts the TEK using the key encryption key derived from the authorization key.2.15. Upstream The direction from the subscriber towards the head-end.3. Overview This MIB provides a set of objects required for the management of the Baseline Privacy Interface for DOCSIS compliant Cable Modems (CMs) and Cable Modem Termination Systems (CMTSs). This MIB specification is derived from the DOCSIS Baseline Privacy Interface specification [18], which is an extension to the DOCSIS Radio Frequency Interface specification [19]. Please note that this MIB specification is not sufficient for the management of the DOCSIS Baseline Privacy Plus Interface specification [21]. The working group expects to issue a MIB for the management of BPI+ at a later time. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [23].3.1. Structure of the MIB This MIB consists of one group of CM-only objects (docsBpiCmGroup), and one group of CMTS-only objects (docsBpiCmtsGroup).Woundy Informational [Page 5]
RFC 3083 DOCSIS Baseline Privacy MIB March 2001 The CM-only objects are organized into two tables: o The docsBpiCmBaseTable contains objects for managing basic Baseline Privacy parameters and counters, and for managing the Authorization finite state machine. o The docsBpiCmTEKTable contains objects for managing the Traffic Encryption Key (TEK) finite state machine per SID. The CMTS-only objects are organized into four sub-groups: o The docsBpiCmtsBaseTable contains objects for managing basic Baseline Privacy parameters and counters. o The docsBpiCmtsAuthTable contains objects for managing the Authorization association information per cable modem. o The docsBpiCmtsTEKTable contains objects for managing the TEK association information per SID. o The docsBpiMulticastControl consists of two tables. The docsBpiIpMulticastMapTable controls the mapping of downstream IP multicast data traffic to downstream multicast SID values. The docsBpiMulticastAuthTable controls which CMs are authorized to receive downstream traffic transmitted over particular multicast SIDs; a CM will receive TEKs corresponding to the multicast SIDs for which it is authorized. The combination of these two tables will limit the distribution of downstream IP multicast data traffic to authorized CMs.3.2. Management requirements The Baseline Privacy Interface specification is documented in [18], and is an extension to the Radio Frequency Interface specification documented in [19]. In addition to the explicit requirements in this specification, the CM and CMTS enabled for Baseline Privacy MUST support all applicable DOCSIS and IETF requirements and MIB objects. Specifications that identify relevant requirements and MIB objects include the IETF Radio Frequency MIB [16], the IETF Cable Device MIB [17], and the DOCSIS OSSI Specification [20]. The explicit management requirements of the Baseline Privacy Interface, which motivate the development of the MIB in this document, are detailed below: o The CM and CMTS MUST support viewing relevant RSA public keys, for future subscriber authentication applications.Woundy Informational [Page 6]
RFC 3083 DOCSIS Baseline Privacy MIB March 2001 o The Baseline Privacy management interface needs to support operator configuration of Authorization and TEK Finite State Machine (FSM) parameters, for performance tuning and security incident handling. The CMTS MUST support viewing (and configuring if possible) all FSM-related parameters, including baseline privacy status (enabled or disabled), key lifetimes, key grace times, and state timeout values. The CM MUST support viewing these parameters where possible. o The management interface needs to support operator analysis and override of FSM behavior, for fault management, subscriber service de-provisioning, and security incident handling. The CM MUST support viewing the current FSM states. The CM and CMTS MUST support viewing message error codes and message error strings, and counters for invalid KEK and TEK events, for key expirations and renewals, and for duplicate messages. The CM and CMTS MUST support viewing current authorization key sequence numbers and key expiration times for failure diagnosis. o The management interface needs to support dynamic control of the distribution of IP multicast data traffic. This control includes forwarding IP multicast traffic to the correct multicast group (SID), and managing the membership lists of each multicast group (SID). The CMTS MUST support configuring and viewing all IP multicast forwarding state, and all multicast group memberships, within the MAC domains of the CMTS.3.3. Textual convention CableLabs has required the implementation of prior versions of this MIB in DOCSIS 1.0 cable modems that implement the Baseline Privacy Interface, as a prerequisite for DOCSIS 1.0 certification. The Baseline Privacy Interface MIB contains eight MIB objects defined with the (now obsolete) DisplayString textual convention, and one MIB object defined with the (now undesirable) IpAddress textual convention. In the judgment of the working group, it is preferable to keep these less-than-desirable textual conventions, in order to maintain backward compatibility and interoperability with DOCSIS 1.0 cable modems that implemented previous versions of this MIB.Woundy Informational [Page 7]
RFC 3083 DOCSIS Baseline Privacy MIB March 20014. DefinitionsDOCS-BPI-MIB DEFINITIONS ::= BEGINIMPORTSMODULE-IDENTITY, OBJECT-TYPE,Integer32, Counter32, IpAddressFROM SNMPv2-SMIDisplayString, MacAddress, RowStatus, TruthValue, DateAndTimeFROM SNMPv2-TCOBJECT-GROUP, MODULE-COMPLIANCEFROM SNMPv2-CONFifIndexFROM IF-MIBdocsIfMib, docsIfCmServiceId, docsIfCmtsServiceIdFROM DOCS-IF-MIB;docsBpiMIB MODULE-IDENTITYLAST-UPDATED "200103130000Z"ORGANIZATION "IETF IPCDN Working Group"CONTACT-INFO "Rich Woundy Postal: Cisco Systems 250 Apollo Drive Chelmsford, MA 01824 U.S.A. Tel: +1 978 244 8000 E-mail: rwoundy@cisco.com IETF IPCDN Working Group General Discussion: ipcdn@ietf.org Subscribe:http://www.ietf.org/mailman/listinfo/ipcdn Archive:ftp://ftp.ietf.org/ietf-mail-archive/ipcdn Co-chairs: Richard Woundy, rwoundy@cisco.com Andrew Valentine, a.valentine@eu.hns.com"DESCRIPTION"This is the MIB Module for the DOCSIS Baseline Privacy Interface(BPI) at cable modems (CMs) and cable modem termination systems(CMTSs). CableLabs requires the implementation of this MIB inDOCSIS 1.0 cable modems that implement the Baseline PrivacyInterface, as a prerequisite for DOCSIS 1.0 certification."REVISION "200103130000Z"DESCRIPTION"Version published asRFC 3083."REVISION "200011031930Z"DESCRIPTION"Modified by Richard Woundy to fix problems identified by the MIBWoundy Informational [Page 8]
RFC 3083 DOCSIS Baseline Privacy MIB March 2001doctor. I marked docsBpiCmtsDefaultAuthGraceTime anddocsBpiCmtsDefaultTEKGraceTime as obsolete objects, to prevent OIDreassignment. Several object descriptions were also corrected."REVISION "200002161930Z"DESCRIPTION"Initial version.CableLabs requires the implementation of this MIB in certified DOCSIS1.0 cable modems implementing the Baseline Privacy Interface, perDOCSIS 1.0 engineering change notice oss-n-99027."::= { docsIfMib 5 }docsBpiMIBObjects OBJECT IDENTIFIER ::= { docsBpiMIB 1 }-- Cable Modem GroupdocsBpiCmObjects OBJECT IDENTIFIER ::= { docsBpiMIBObjects 1 }---- The BPI base and authorization table for CMs, indexed by ifIndex--docsBpiCmBaseTable OBJECT-TYPESYNTAX SEQUENCE OF DocsBpiCmBaseEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"This table describes the basic and authorization-related BaselinePrivacy attributes of each CM MAC interface."::= { docsBpiCmObjects 1 }docsBpiCmBaseEntry OBJECT-TYPESYNTAX DocsBpiCmBaseEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"Each entry contains objects describing attributes of one CM MACinterface. An entry in this table exists for each ifEntry with anifType of docsCableMaclayer(127)."INDEX { ifIndex }::= { docsBpiCmBaseTable 1 }DocsBpiCmBaseEntry ::= SEQUENCE {docsBpiCmPrivacyEnable TruthValue,docsBpiCmPublicKey OCTET STRING,docsBpiCmAuthState INTEGER,docsBpiCmAuthKeySequenceNumber Integer32,docsBpiCmAuthExpires DateAndTime,Woundy Informational [Page 9]
RFC 3083 DOCSIS Baseline Privacy MIB March 2001docsBpiCmAuthReset TruthValue,docsBpiCmAuthGraceTime Integer32,docsBpiCmTEKGraceTime Integer32,docsBpiCmAuthWaitTimeout Integer32,docsBpiCmReauthWaitTimeout Integer32,docsBpiCmOpWaitTimeout Integer32,docsBpiCmRekeyWaitTimeout Integer32,docsBpiCmAuthRejectWaitTimeout Integer32,docsBpiCmAuthRequests Counter32,docsBpiCmAuthReplies Counter32,docsBpiCmAuthRejects Counter32,docsBpiCmAuthInvalids Counter32,docsBpiCmAuthRejectErrorCode INTEGER,docsBpiCmAuthRejectErrorString DisplayString,docsBpiCmAuthInvalidErrorCode INTEGER,docsBpiCmAuthInvalidErrorString DisplayString}docsBpiCmPrivacyEnable OBJECT-TYPESYNTAX TruthValueMAX-ACCESS read-onlySTATUS currentDESCRIPTION"This object identifies whether this CM is provisioned to runBaseline Privacy. This is analogous to the presence (or absence)of the Baseline Privacy Configuration Setting option. The statusof each individual SID with respect to Baseline Privacy iscaptured in the docsBpiCmTEKPrivacyEnable object."REFERENCE"DOCSIS Baseline Privacy Interface Specification,Appendix A.1.1."::= { docsBpiCmBaseEntry 1 }docsBpiCmPublicKey OBJECT-TYPESYNTAX OCTET STRING (SIZE (74 | 106 | 140 | 270))MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is a DER-encoded RSAPublicKey ASN.1 typestring, as defined in the RSA Encryption Standard (PKCS #1) [22],corresponding to the public key of the CM. The 74, 106, 140, and270 byte key encoding lengths correspond to 512 bit, 768 bit, 1024bit, and 2048 public moduli respectively."REFERENCE"DOCSIS Baseline Privacy Interface Specification,Section 4.2.2.4."::= { docsBpiCmBaseEntry 2 }docsBpiCmAuthState OBJECT-TYPESYNTAX INTEGER {Woundy Informational [Page 10]
RFC 3083 DOCSIS Baseline Privacy MIB March 2001 authWait(2), authorized(3), reauthWait(4), authRejectWait(5) }MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the state of the CM authorizationFSM. The start state indicates that FSM is in its initial state."REFERENCE"DOCSIS Baseline Privacy Interface Specification,Section 4.1.2.1."::= { docsBpiCmBaseEntry 3 }docsBpiCmAuthKeySequenceNumber OBJECT-TYPESYNTAX Integer32 (0..15)MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the authorization key sequence numberfor this FSM."REFERENCE"DOCSIS Baseline Privacy Interface Specification, Sections4.2.1.2and4.2.2.10."::= { docsBpiCmBaseEntry 4 }docsBpiCmAuthExpires OBJECT-TYPESYNTAX DateAndTimeMAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the actual clock time when the currentauthorization for this FSM expires. If the CM does not have an activeauthorization, then the value is of the expiration date and time ofthe last active authorization."REFERENCE"DOCSIS Baseline Privacy Interface Specification, Sections4.2.1.2and4.2.2.9."::= { docsBpiCmBaseEntry 5 }docsBpiCmAuthReset OBJECT-TYPESYNTAX TruthValueMAX-ACCESS read-writeSTATUS currentDESCRIPTION"Setting this object to TRUE generates a Reauthorize event in theauthorization FSM. Reading this object always returns FALSE."REFERENCEWoundy Informational [Page 11]
RFC 3083 DOCSIS Baseline Privacy MIB March 2001"DOCSIS Baseline Privacy Interface Specification,Section 4.1.2.3.4."::= { docsBpiCmBaseEntry 6 }docsBpiCmAuthGraceTime OBJECT-TYPESYNTAX Integer32 (1..1800)UNITS "seconds"MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the grace time for an authorization key.A CM is expected to start trying to get a new authorization keybeginning AuthGraceTime seconds before the authorization key actuallyexpires."REFERENCE"DOCSIS Baseline Privacy Interface Specification,Appendix A.1.1.1.3."::= { docsBpiCmBaseEntry 7 }docsBpiCmTEKGraceTime OBJECT-TYPESYNTAX Integer32 (1..1800)UNITS "seconds"MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the grace time for a TEK. A CM isexpected to start trying to get a new TEK beginning TEKGraceTimeseconds before the TEK actually expires."REFERENCE"DOCSIS Baseline Privacy Interface Specification,Appendix A.1.1.1.6."::= { docsBpiCmBaseEntry 8 }docsBpiCmAuthWaitTimeout OBJECT-TYPESYNTAX Integer32 (1..30)UNITS "seconds"MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the Authorize Wait Timeout."REFERENCE"DOCSIS Baseline Privacy Interface Specification,Appendix A.1.1.1.1."::= { docsBpiCmBaseEntry 9 }docsBpiCmReauthWaitTimeout OBJECT-TYPESYNTAX Integer32 (1..30)UNITS "seconds"MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the Reauthorize Wait Timeout in seconds."Woundy Informational [Page 12]
RFC 3083 DOCSIS Baseline Privacy MIB March 2001REFERENCE"DOCSIS Baseline Privacy Interface Specification,Appendix A.1.1.1.2."::= { docsBpiCmBaseEntry 10 }docsBpiCmOpWaitTimeout OBJECT-TYPESYNTAX Integer32 (1..10)UNITS "seconds"MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the Operational Wait Timeout in seconds."REFERENCE"DOCSIS Baseline Privacy Interface Specification,Appendix A.1.1.1.4."::= { docsBpiCmBaseEntry 11 }docsBpiCmRekeyWaitTimeout OBJECT-TYPESYNTAX Integer32 (1..10)UNITS "seconds"MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the Rekey Wait Timeout in seconds."REFERENCE"DOCSIS Baseline Privacy Interface Specification,Appendix A.1.1.1.5."::= { docsBpiCmBaseEntry 12 }docsBpiCmAuthRejectWaitTimeout OBJECT-TYPESYNTAX Integer32 (1..600)UNITS "seconds"MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the Authorization Reject Wait Timeout inseconds."REFERENCE"DOCSIS Baseline Privacy Interface Specification,Appendix A.1.1.1.7."::= { docsBpiCmBaseEntry 13 }docsBpiCmAuthRequests OBJECT-TYPESYNTAX Counter32MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the count of times the CM hastransmitted an Authorization Request message."REFERENCE"DOCSIS Baseline Privacy Interface Specification,Section 4.2.1.1."::= { docsBpiCmBaseEntry 14 }Woundy Informational [Page 13]
RFC 3083 DOCSIS Baseline Privacy MIB March 2001docsBpiCmAuthReplies OBJECT-TYPESYNTAX Counter32MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the count of times the CM hasreceived an Authorization Reply message."REFERENCE"DOCSIS Baseline Privacy Interface Specification,Section 4.2.1.2."::= { docsBpiCmBaseEntry 15 }docsBpiCmAuthRejects OBJECT-TYPESYNTAX Counter32MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the count of times the CM hasreceived an Authorization Reject message."REFERENCE"DOCSIS Baseline Privacy Interface Specification,Section 4.2.1.3."::= { docsBpiCmBaseEntry 16 }docsBpiCmAuthInvalids OBJECT-TYPESYNTAX Counter32MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the count of times the CM hasreceived an Authorization Invalid message."REFERENCE"DOCSIS Baseline Privacy Interface Specification,Section 4.2.1.7."::= { docsBpiCmBaseEntry 17 }docsBpiCmAuthRejectErrorCode OBJECT-TYPESYNTAX INTEGER { none(1), unknown(2), unauthorizedCm(3), unauthorizedSid(4) }MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the enumerated description of theError-Code in most recent Authorization Reject message received bythe CM. This has value unknown(2) if the last Error-Code value was0, and none(1) if no Authorization Reject message has been receivedsince reboot."Woundy Informational [Page 14]
RFC 3083 DOCSIS Baseline Privacy MIB March 2001REFERENCE"DOCSIS Baseline Privacy Interface Specification, Sections4.2.1.3and4.2.2.16."::= { docsBpiCmBaseEntry 18 }docsBpiCmAuthRejectErrorString OBJECT-TYPESYNTAX DisplayString (SIZE (0..128))MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the Display-String in most recentAuthorization Reject message received by the CM. This is a zerolength string if no Authorization Reject message has been receivedsince reboot."REFERENCE"DOCSIS Baseline Privacy Interface Specification, Sections4.2.1.3and4.2.2.6."::= { docsBpiCmBaseEntry 19 }docsBpiCmAuthInvalidErrorCode OBJECT-TYPESYNTAX INTEGER { none(1), unknown(2), unauthorizedCm(3), unsolicited(5), invalidKeySequence(6), keyRequestAuthenticationFailure(7) }MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the enumerated description of theError-Code in most recent Authorization Invalid message received bythe CM. This has value unknown(2) if the last Error-Code value was0, and none(1) if no Authorization Invalid message has been receivedsince reboot."REFERENCE"DOCSIS Baseline Privacy Interface Specification, Sections4.2.1.7and4.2.2.16."::= { docsBpiCmBaseEntry 20 }docsBpiCmAuthInvalidErrorString OBJECT-TYPESYNTAX DisplayString (SIZE (0..128))MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the Display-String in most recentAuthorization Invalid message received by the CM. This is a zeroWoundy Informational [Page 15]
RFC 3083 DOCSIS Baseline Privacy MIB March 2001length string if no Authorization Invalid message has been receivedsince reboot."REFERENCE"DOCSIS Baseline Privacy Interface Specification, Sections4.2.1.7and4.2.2.6."::= { docsBpiCmBaseEntry 21 }---- The CM TEK Table, indexed by ifIndex and SID--docsBpiCmTEKTable OBJECT-TYPESYNTAX SEQUENCE OF DocsBpiCmTEKEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"This table describes the attributes of each CM Traffic Encryption Key(TEK) association. The CM maintains (no more than) one TEK associationper SID per CM MAC interface."::= { docsBpiCmObjects 2 }docsBpiCmTEKEntry OBJECT-TYPESYNTAX DocsBpiCmTEKEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"Each entry contains objects describing the TEK association attributesof one SID. The CM MUST create one entry per unicast SID, regardlessof whether the SID was obtained from a Registration Response message,or from an Authorization Reply message."INDEX { ifIndex, docsIfCmServiceId }::= { docsBpiCmTEKTable 1 }DocsBpiCmTEKEntry ::= SEQUENCE {docsBpiCmTEKPrivacyEnable TruthValue,docsBpiCmTEKState INTEGER,docsBpiCmTEKExpiresOld DateAndTime,docsBpiCmTEKExpiresNew DateAndTime,docsBpiCmTEKKeyRequests Counter32,docsBpiCmTEKKeyReplies Counter32,docsBpiCmTEKKeyRejects Counter32,docsBpiCmTEKInvalids Counter32,docsBpiCmTEKAuthPends Counter32,docsBpiCmTEKKeyRejectErrorCode INTEGER,docsBpiCmTEKKeyRejectErrorString DisplayString,docsBpiCmTEKInvalidErrorCode INTEGER,docsBpiCmTEKInvalidErrorString DisplayString}Woundy Informational [Page 16]
RFC 3083 DOCSIS Baseline Privacy MIB March 2001docsBpiCmTEKPrivacyEnable OBJECT-TYPESYNTAX TruthValueMAX-ACCESS read-onlySTATUS currentDESCRIPTION"This object identifies whether this SID is provisioned to runBaseline Privacy. This is analogous to enabling Baseline Privacy ona provisioned SID using the Class-of-Service Privacy Enable option.Baseline Privacy is not effectively enabled for any SID unlessBaseline Privacy is enabled for the CM, which is managed via thedocsBpiCmPrivacyEnable object."REFERENCE"DOCSIS Baseline Privacy Interface Specification,Appendix A.1.2."::= { docsBpiCmTEKEntry 1 }docsBpiCmTEKState OBJECT-TYPESYNTAX INTEGER { start(1), opWait(2), opReauthWait(3), operational(4), rekeyWait(5), rekeyReauthWait(6) }MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the state of the indicated TEK FSM.The start(1) state indicates that FSM is in its initial state."REFERENCE"DOCSIS Baseline Privacy Interface Specification,Section 4.1.3.1."::= { docsBpiCmTEKEntry 2 }docsBpiCmTEKExpiresOld OBJECT-TYPESYNTAX DateAndTimeMAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the actual clock time for expirationof the immediate predecessor of the most recent TEK for this FSM.If this FSM has only one TEK, then the value is the time of activationof this FSM."REFERENCE"DOCSIS Baseline Privacy Interface Specification, Sections4.2.1.5 and4.2.2.9."::= { docsBpiCmTEKEntry 3 }docsBpiCmTEKExpiresNew OBJECT-TYPEWoundy Informational [Page 17]
RFC 3083 DOCSIS Baseline Privacy MIB March 2001SYNTAX DateAndTimeMAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the actual clock time for expirationof the most recent TEK for this FSM."REFERENCE"DOCSIS Baseline Privacy Interface Specification, Sections4.2.1.5 and4.2.2.9."::= { docsBpiCmTEKEntry 4 }docsBpiCmTEKKeyRequests OBJECT-TYPESYNTAX Counter32MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the count of times the CM has transmitteda Key Request message."REFERENCE"DOCSIS Baseline Privacy Interface Specification,Section 4.2.1.4."::= { docsBpiCmTEKEntry 5 }docsBpiCmTEKKeyReplies OBJECT-TYPESYNTAX Counter32MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the count of times the CM has receiveda Key Reply message, including a message whose authentication failed."REFERENCE"DOCSIS Baseline Privacy Interface Specification,Section 4.2.1.5."::= { docsBpiCmTEKEntry 6 }docsBpiCmTEKKeyRejects OBJECT-TYPESYNTAX Counter32MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the count of times the CM has receiveda Key Reject message, including a message whose authentication failed."REFERENCE"DOCSIS Baseline Privacy Interface Specification,Section 4.2.1.6."::= { docsBpiCmTEKEntry 7 }docsBpiCmTEKInvalids OBJECT-TYPESYNTAX Counter32MAX-ACCESS read-onlySTATUS currentWoundy Informational [Page 18]
RFC 3083 DOCSIS Baseline Privacy MIB March 2001DESCRIPTION"The value of this object is the count of times the CM has receiveda TEK Invalid message, including a message whose authentication failed."REFERENCE"DOCSIS Baseline Privacy Interface Specification,Section 4.2.1.8."::= { docsBpiCmTEKEntry 8 }docsBpiCmTEKAuthPends OBJECT-TYPESYNTAX Counter32MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the count of times an AuthorizationPending (Auth Pend) event occurred in this FSM."REFERENCE"DOCSIS Baseline Privacy Interface Specification,Section 4.1.3.3.3."::= { docsBpiCmTEKEntry 9 }docsBpiCmTEKKeyRejectErrorCode OBJECT-TYPESYNTAX INTEGER { none(1), unknown(2), unauthorizedSid(4) }MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the enumerated description of theError-Code in most recent Key Reject message received by the CM. Thishas value unknown(2) if the last Error-Code value was 0, and none(1)if no Key Reject message has been received since reboot."REFERENCE"DOCSIS Baseline Privacy Interface Specification, Sections4.1.2.6and4.2.2.16."::= { docsBpiCmTEKEntry 10 }docsBpiCmTEKKeyRejectErrorString OBJECT-TYPESYNTAX DisplayString (SIZE (0..128))MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the Display-String in most recent KeyReject message received by the CM. This is a zero length string if noKey Reject message has been received since reboot."REFERENCE"DOCSIS Baseline Privacy Interface Specification, Sections4.1.2.6and4.2.2.6."::= { docsBpiCmTEKEntry 11 }Woundy Informational [Page 19]
RFC 3083 DOCSIS Baseline Privacy MIB March 2001docsBpiCmTEKInvalidErrorCode OBJECT-TYPESYNTAX INTEGER { none(1), unknown(2), invalidKeySequence(6) }MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the enumerated description of theError-Code in most recent TEK Invalid message received by the CM.This has value unknown(2) if the last Error-Code value was 0, andnone(1) if no TEK Invalid message has been received since reboot."REFERENCE"DOCSIS Baseline Privacy Interface Specification, Sections4.1.2.8and4.2.2.16."::= { docsBpiCmTEKEntry 12 }docsBpiCmTEKInvalidErrorString OBJECT-TYPESYNTAX DisplayString (SIZE (0..128))MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the Display-String in most recent TEKInvalid message received by the CM. This is a zero length string ifno TEK Invalid message has been received since reboot."REFERENCE"DOCSIS Baseline Privacy Interface Specification, Sections4.1.2.8and4.2.2.6."::= { docsBpiCmTEKEntry 13 }-- Cable Modem Termination System GroupdocsBpiCmtsObjects OBJECT IDENTIFIER ::= { docsBpiMIBObjects 2 }---- The BPI base table for CMTSs, indexed by ifIndex--docsBpiCmtsBaseTable OBJECT-TYPESYNTAX SEQUENCE OF DocsBpiCmtsBaseEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"This table describes the basic Baseline Privacy attributes of eachCMTS MAC interface."::= { docsBpiCmtsObjects 1 }Woundy Informational [Page 20]
RFC 3083 DOCSIS Baseline Privacy MIB March 2001docsBpiCmtsBaseEntry OBJECT-TYPESYNTAX DocsBpiCmtsBaseEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"Each entry contains objects describing attributes of one CMTS MACinterface. An entry in this table exists for each ifEntry with anifType of docsCableMaclayer(127)."INDEX { ifIndex }::= { docsBpiCmtsBaseTable 1 }DocsBpiCmtsBaseEntry ::= SEQUENCE {docsBpiCmtsDefaultAuthLifetime Integer32,docsBpiCmtsDefaultTEKLifetime Integer32,docsBpiCmtsDefaultAuthGraceTime Integer32,docsBpiCmtsDefaultTEKGraceTime Integer32,docsBpiCmtsAuthRequests Counter32,docsBpiCmtsAuthReplies Counter32,docsBpiCmtsAuthRejects Counter32,docsBpiCmtsAuthInvalids Counter32}docsBpiCmtsDefaultAuthLifetime OBJECT-TYPESYNTAX Integer32 (1..6048000)UNITS "seconds"MAX-ACCESS read-writeSTATUS currentDESCRIPTION"The value of this object is the default lifetime, in seconds, theCMTS assigns to a new authorization key."REFERENCE"DOCSIS Baseline Privacy Interface Specification,Appendix A.2."::= { docsBpiCmtsBaseEntry 1 }docsBpiCmtsDefaultTEKLifetime OBJECT-TYPESYNTAX Integer32 (1..604800)UNITS "seconds"MAX-ACCESS read-writeSTATUS currentDESCRIPTION"The value of this object is the default lifetime, in seconds, theCMTS assigns to a new Traffic Encryption Key (TEK)."REFERENCE"DOCSIS Baseline Privacy Interface Specification,Appendix A.2."::= { docsBpiCmtsBaseEntry 2 }-- Note: the following two objects have been obsoleted from this MIB.Woundy Informational [Page 21]
RFC 3083 DOCSIS Baseline Privacy MIB March 2001docsBpiCmtsDefaultAuthGraceTime OBJECT-TYPESYNTAX Integer32 (1..1800)UNITS "seconds"MAX-ACCESS read-writeSTATUS obsoleteDESCRIPTION"This object was obsoleted because the provisioning system, not the CMTS,manages the authorization key grace time for DOCSIS CMs."::= { docsBpiCmtsBaseEntry 3 }docsBpiCmtsDefaultTEKGraceTime OBJECT-TYPESYNTAX Integer32 (1..1800)UNITS "seconds"MAX-ACCESS read-writeSTATUS obsoleteDESCRIPTION"This object was obsoleted because the provisioning system, not the CMTS,manages the Traffic Encryption Key (TEK) grace time for DOCSIS CMs."::= { docsBpiCmtsBaseEntry 4 }docsBpiCmtsAuthRequests OBJECT-TYPESYNTAX Counter32MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the count of times the CMTS hasreceived an Authorization Request message from any CM."REFERENCE"DOCSIS Baseline Privacy Interface Specification,Section 4.2.1.1."::= { docsBpiCmtsBaseEntry 5 }docsBpiCmtsAuthReplies OBJECT-TYPESYNTAX Counter32MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the count of times the CMTS hastransmitted an Authorization Reply message to any CM."REFERENCE"DOCSIS Baseline Privacy Interface Specification,Section 4.2.1.2."::= { docsBpiCmtsBaseEntry 6 }docsBpiCmtsAuthRejects OBJECT-TYPESYNTAX Counter32MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the count of times the CMTS hasWoundy Informational [Page 22]
RFC 3083 DOCSIS Baseline Privacy MIB March 2001transmitted an Authorization Reject message to any CM."REFERENCE"DOCSIS Baseline Privacy Interface Specification,Section 4.2.1.3."::= { docsBpiCmtsBaseEntry 7 }docsBpiCmtsAuthInvalids OBJECT-TYPESYNTAX Counter32MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the count of times the CMTS hastransmitted an Authorization Invalid message to any CM."REFERENCE"DOCSIS Baseline Privacy Interface Specification,Section 4.2.1.7."::= { docsBpiCmtsBaseEntry 8 }---- The CMTS Authorization Table, indexed by ifIndex and CM MAC address--docsBpiCmtsAuthTable OBJECT-TYPESYNTAX SEQUENCE OF DocsBpiCmtsAuthEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"This table describes the attributes of each CM authorizationassociation. The CMTS maintains one authorization association witheach Baseline Privacy-enabled CM on each CMTS MAC interface."::= { docsBpiCmtsObjects 2 }docsBpiCmtsAuthEntry OBJECT-TYPESYNTAX DocsBpiCmtsAuthEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"Each entry contains objects describing attributes of oneauthorization association. The CMTS MUST create one entry per CM perMAC interface, based on the receipt of an Authorization Requestmessage, and MUST not delete the entry before the CM authorizationpermanently expires."INDEX { ifIndex, docsBpiCmtsAuthCmMacAddress }::= { docsBpiCmtsAuthTable 1 }DocsBpiCmtsAuthEntry ::= SEQUENCE {docsBpiCmtsAuthCmMacAddress MacAddress,docsBpiCmtsAuthCmPublicKey OCTET STRING,docsBpiCmtsAuthCmKeySequenceNumber Integer32,docsBpiCmtsAuthCmExpires DateAndTime,Woundy Informational [Page 23]
RFC 3083 DOCSIS Baseline Privacy MIB March 2001docsBpiCmtsAuthCmLifetime Integer32,docsBpiCmtsAuthCmGraceTime Integer32,docsBpiCmtsAuthCmReset INTEGER,docsBpiCmtsAuthCmRequests Counter32,docsBpiCmtsAuthCmReplies Counter32,docsBpiCmtsAuthCmRejects Counter32,docsBpiCmtsAuthCmInvalids Counter32,docsBpiCmtsAuthRejectErrorCode INTEGER,docsBpiCmtsAuthRejectErrorString DisplayString,docsBpiCmtsAuthInvalidErrorCode INTEGER,docsBpiCmtsAuthInvalidErrorString DisplayString}docsBpiCmtsAuthCmMacAddress OBJECT-TYPESYNTAX MacAddressMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"The value of this object is the physical address of the CM towhich the authorization association applies."::= { docsBpiCmtsAuthEntry 1 }docsBpiCmtsAuthCmPublicKey OBJECT-TYPESYNTAX OCTET STRING (SIZE (0 | 74 | 106 | 140 | 270))MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is a DER-encoded RSAPublicKey ASN.1 typestring, as defined in the RSA Encryption Standard (PKCS #1) [22],corresponding to the public key of the CM. The 74, 106, 140, and270 byte key encoding lengths correspond to 512 bit, 768 bit, 1024bit, and 2048 public moduli respectively. This is a zero-lengthstring if the CMTS does not retain the public key."REFERENCE"DOCSIS Baseline Privacy Interface Specification,Section 4.2.2.4."::= { docsBpiCmtsAuthEntry 2 }docsBpiCmtsAuthCmKeySequenceNumber OBJECT-TYPESYNTAX Integer32 (0..15)MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the authorization key sequence numberfor this CM."REFERENCE"DOCSIS Baseline Privacy Interface Specification, Sections4.2.1.2and4.2.2.10."Woundy Informational [Page 24]
RFC 3083 DOCSIS Baseline Privacy MIB March 2001::= { docsBpiCmtsAuthEntry 3 }docsBpiCmtsAuthCmExpires OBJECT-TYPESYNTAX DateAndTimeMAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the actual clock time when the currentauthorization for this CM expires. If this CM does not have anactive authorization, then the value is of the expiration date andtime of the last active authorization."REFERENCE"DOCSIS Baseline Privacy Interface Specification, Sections4.2.1.2and4.2.2.9."::= { docsBpiCmtsAuthEntry 4 }docsBpiCmtsAuthCmLifetime OBJECT-TYPESYNTAX Integer32 (1..6048000)UNITS "seconds"MAX-ACCESS read-writeSTATUS currentDESCRIPTION"The value of this object is the lifetime, in seconds, the CMTSassigns to an authorization key for this CM."REFERENCE"DOCSIS Baseline Privacy Interface Specification,Section 4.2.1.2andAppendix A.2."::= { docsBpiCmtsAuthEntry 5 }docsBpiCmtsAuthCmGraceTime OBJECT-TYPESYNTAX Integer32 (1..1800)UNITS "seconds"MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the grace time for the authorization keyin seconds. The CM is expected to start trying to get a newauthorization key beginning AuthGraceTime seconds before theauthorization key actually expires."REFERENCE"DOCSIS Baseline Privacy Interface Specification,Appendix A.1.1.1.3."::= { docsBpiCmtsAuthEntry 6 }docsBpiCmtsAuthCmReset OBJECT-TYPESYNTAX INTEGER { noResetRequested(1), invalidateAuth(2), sendAuthInvalid(3),Woundy Informational [Page 25]
RFC 3083 DOCSIS Baseline Privacy MIB March 2001 invalidateTeks(4) }MAX-ACCESS read-writeSTATUS currentDESCRIPTION"Setting this object to invalidateAuth(2) causes the CMTS toinvalidate the current CM authorization key, but not to transmit anAuthorization Invalid message nor to invalidate unicast TEKs. Settingthis object to sendAuthInvalid(3) causes the CMTS to invalidate thecurrent CM authorization key, and to transmit an Authorization Invalidmessage to the CM, but not to invalidate unicast TEKs. Setting thisobject to invalidateTeks(4) causes the CMTS to invalidate the currentCM authorization key, to transmit an Authorization Invalid message tothe CM, and to invalidate all unicast TEKs associated with this CMauthorization. Reading this object returns the most-recently-set valueof this object, or returns noResetRequested(1) if the object has notbeen set since the last CMTS reboot."REFERENCE"DOCSIS Baseline Privacy Interface Specification, Sections4.1.2.3.4,4.1.2.3.5, and4.1.3.3.5."::= { docsBpiCmtsAuthEntry 7 }docsBpiCmtsAuthCmRequests OBJECT-TYPESYNTAX Counter32MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the count of times the CMTS hasreceived an Authorization Request message from this CM."REFERENCE"DOCSIS Baseline Privacy Interface Specification,Section 4.2.1.1."::= { docsBpiCmtsAuthEntry 8 }docsBpiCmtsAuthCmReplies OBJECT-TYPESYNTAX Counter32MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the count of times the CMTS hastransmitted an Authorization Reply message to this CM."REFERENCE"DOCSIS Baseline Privacy Interface Specification,Section 4.2.1.2."::= { docsBpiCmtsAuthEntry 9 }docsBpiCmtsAuthCmRejects OBJECT-TYPESYNTAX Counter32MAX-ACCESS read-onlySTATUS currentWoundy Informational [Page 26]
RFC 3083 DOCSIS Baseline Privacy MIB March 2001DESCRIPTION"The value of this object is the count of times the CMTS hastransmitted an Authorization Reject message to this CM."REFERENCE"DOCSIS Baseline Privacy Interface Specification,Section 4.2.1.3."::= { docsBpiCmtsAuthEntry 10 }docsBpiCmtsAuthCmInvalids OBJECT-TYPESYNTAX Counter32MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the count of times the CMTS hastransmitted an Authorization Invalid message to this CM."REFERENCE"DOCSIS Baseline Privacy Interface Specification,Section 4.2.1.7."::= { docsBpiCmtsAuthEntry 11 }docsBpiCmtsAuthRejectErrorCode OBJECT-TYPESYNTAX INTEGER { none(1), unknown(2), unauthorizedCm(3), unauthorizedSid(4) }MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the enumerated description of theError-Code in most recent Authorization Reject message transmitted tothe CM. This has value unknown(2) if the last Error-Code value was0, and none(1) if no Authorization Reject message has been transmittedto the CM."REFERENCE"DOCSIS Baseline Privacy Interface Specification, Sections4.2.1.3and4.2.2.16."::= { docsBpiCmtsAuthEntry 12 }docsBpiCmtsAuthRejectErrorString OBJECT-TYPESYNTAX DisplayString (SIZE (0..128))MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the Display-String in most recentAuthorization Reject message transmitted to the CM. This is azero length string if no Authorization Reject message has beentransmitted to the CM."REFERENCEWoundy Informational [Page 27]
RFC 3083 DOCSIS Baseline Privacy MIB March 2001"DOCSIS Baseline Privacy Interface Specification, Sections4.2.1.3and4.2.2.6."::= { docsBpiCmtsAuthEntry 13 }docsBpiCmtsAuthInvalidErrorCode OBJECT-TYPESYNTAX INTEGER { none(1), unknown(2), unauthorizedCm(3), unsolicited(5), invalidKeySequence(6), keyRequestAuthenticationFailure(7) }MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the enumerated description of theError-Code in most recent Authorization Invalid message transmittedto the CM. This has value unknown(2) if the last Error-Code value was0, and none(1) if no Authorization Invalid message has beentransmitted to the CM."REFERENCE"DOCSIS Baseline Privacy Interface Specification, Sections4.2.1.7and4.2.2.16."::= { docsBpiCmtsAuthEntry 14 }docsBpiCmtsAuthInvalidErrorString OBJECT-TYPESYNTAX DisplayString (SIZE (0..128))MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the Display-String in most recentAuthorization Invalid message transmitted to the CM. This is azero length string if no Authorization Invalid message has beentransmitted to the CM."REFERENCE"DOCSIS Baseline Privacy Interface Specification, Sections4.2.1.7and4.2.2.6."::= { docsBpiCmtsAuthEntry 15 }---- The CMTS TEK Table, indexed by ifIndex and SID--docsBpiCmtsTEKTable OBJECT-TYPESYNTAX SEQUENCE OF DocsBpiCmtsTEKEntryMAX-ACCESS not-accessibleSTATUS currentWoundy Informational [Page 28]
RFC 3083 DOCSIS Baseline Privacy MIB March 2001DESCRIPTION"This table describes the attributes of each CM Traffic EncryptionKey (TEK) association. The CMTS maintains one TEK association per BPISID on each CMTS MAC interface."::= { docsBpiCmtsObjects 3 }docsBpiCmtsTEKEntry OBJECT-TYPESYNTAX DocsBpiCmtsTEKEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"Each entry contains objects describing attributes of one TEKassociation on a particular CMTS MAC interface. The CMTS MUST createone entry per SID per MAC interface, based on the receipt of anKey Request message, and MUST not delete the entry before the CMauthorization for the SID permanently expires."INDEX { ifIndex, docsIfCmtsServiceId }::= { docsBpiCmtsTEKTable 1 }DocsBpiCmtsTEKEntry ::= SEQUENCE {docsBpiCmtsTEKLifetime Integer32,docsBpiCmtsTEKGraceTime Integer32,docsBpiCmtsTEKExpiresOld DateAndTime,docsBpiCmtsTEKExpiresNew DateAndTime,docsBpiCmtsTEKReset TruthValue,docsBpiCmtsKeyRequests Counter32,docsBpiCmtsKeyReplies Counter32,docsBpiCmtsKeyRejects Counter32,docsBpiCmtsTEKInvalids Counter32,docsBpiCmtsKeyRejectErrorCode INTEGER,docsBpiCmtsKeyRejectErrorString DisplayString,docsBpiCmtsTEKInvalidErrorCode INTEGER,docsBpiCmtsTEKInvalidErrorString DisplayString}docsBpiCmtsTEKLifetime OBJECT-TYPESYNTAX Integer32 (1..604800)UNITS "seconds"MAX-ACCESS read-writeSTATUS currentDESCRIPTION"The value of this object is the lifetime, in seconds, the CMTS assignsto keys for this TEK association."REFERENCE"DOCSIS Baseline Privacy Interface Specification,Section 4.2.1.5andAppendix A.2."::= { docsBpiCmtsTEKEntry 1 }Woundy Informational [Page 29]
RFC 3083 DOCSIS Baseline Privacy MIB March 2001docsBpiCmtsTEKGraceTime OBJECT-TYPESYNTAX Integer32 (1..1800)UNITS "seconds"MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the grace time for the TEK in seconds.The CM is expected to start trying to get a new TEK beginningTEKGraceTime seconds before the TEK actually expires."REFERENCE"DOCSIS Baseline Privacy Interface Specification,Appendix A.1.1.1.6."::= { docsBpiCmtsTEKEntry 2 }docsBpiCmtsTEKExpiresOld OBJECT-TYPESYNTAX DateAndTimeMAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the actual clock time for expirationof the immediate predecessor of the most recent TEK for this FSM.If this FSM has only one TEK, then the value is the time of activationof this FSM."REFERENCE"DOCSIS Baseline Privacy Interface Specification, Sections4.2.1.5and4.2.2.9."::= { docsBpiCmtsTEKEntry 3 }docsBpiCmtsTEKExpiresNew OBJECT-TYPESYNTAX DateAndTimeMAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the actual clock time for expirationof the most recent TEK for this FSM."REFERENCE"DOCSIS Baseline Privacy Interface Specification, Sections4.2.1.5and4.2.2.9."::= { docsBpiCmtsTEKEntry 4 }docsBpiCmtsTEKReset OBJECT-TYPESYNTAX TruthValueMAX-ACCESS read-writeSTATUS currentDESCRIPTION"Setting this object to TRUE causes the CMTS to invalidate the currentactive TEK(s) (plural due to key transition periods), and to generatea new TEK for the associated SID; the CMTS MAY also generate anunsolicited TEK Invalid message, to optimize the TEK synchronizationWoundy Informational [Page 30]
RFC 3083 DOCSIS Baseline Privacy MIB March 2001between the CMTS and the CM. Reading this object always returnsFALSE."REFERENCE"DOCSIS Baseline Privacy Interface Specification,Section 4.1.3.3.5."::= { docsBpiCmtsTEKEntry 5 }docsBpiCmtsKeyRequests OBJECT-TYPESYNTAX Counter32MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the count of times the CMTS hasreceived a Key Request message."REFERENCE"DOCSIS Baseline Privacy Interface Specification,Section 4.2.1.4."::= { docsBpiCmtsTEKEntry 6 }docsBpiCmtsKeyReplies OBJECT-TYPESYNTAX Counter32MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the count of times the CMTS hastransmitted a Key Reply message."REFERENCE"DOCSIS Baseline Privacy Interface Specification,Section 4.2.1.5."::= { docsBpiCmtsTEKEntry 7 }docsBpiCmtsKeyRejects OBJECT-TYPESYNTAX Counter32MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the count of times the CMTS hastransmitted a Key Reject message."REFERENCE"DOCSIS Baseline Privacy Interface Specification,Section 4.2.1.6."::= { docsBpiCmtsTEKEntry 8 }docsBpiCmtsTEKInvalids OBJECT-TYPESYNTAX Counter32MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the count of times the CMTS hastransmitted a TEK Invalid message."REFERENCE"DOCSIS Baseline Privacy Interface Specification,Section 4.2.1.8."Woundy Informational [Page 31]
RFC 3083 DOCSIS Baseline Privacy MIB March 2001::= { docsBpiCmtsTEKEntry 9 }docsBpiCmtsKeyRejectErrorCode OBJECT-TYPESYNTAX INTEGER { none(1), unknown(2), unauthorizedSid(4) }MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the enumerated description of theError-Code in the most recent Key Reject message sent in response toa Key Request for this BPI SID. This has value unknown(2) if the lastError-Code value was 0, and none(1) if no Key Reject message has beenreceived since reboot."REFERENCE"DOCSIS Baseline Privacy Interface Specification, Sections4.2.1.6and4.2.2.16."::= { docsBpiCmtsTEKEntry 10 }docsBpiCmtsKeyRejectErrorString OBJECT-TYPESYNTAX DisplayString (SIZE (0..128))MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the Display-String in the most recentKey Reject message sent in response to a Key Request for this BPISID. This is a zero length string if no Key Reject message has beenreceived since reboot."REFERENCE"DOCSIS Baseline Privacy Interface Specification, Sections4.2.1.6and4.2.2.6."::= { docsBpiCmtsTEKEntry 11 }docsBpiCmtsTEKInvalidErrorCode OBJECT-TYPESYNTAX INTEGER { none(1), unknown(2), invalidKeySequence(6) }MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the enumerated description of theError-Code in the most recent TEK Invalid message sent in associationwith this BPI SID. This has value unknown(2) if the last Error-Codevalue was 0, and none(1) if no TEK Invalid message has been receivedWoundy Informational [Page 32]
RFC 3083 DOCSIS Baseline Privacy MIB March 2001since reboot."REFERENCE"DOCSIS Baseline Privacy Interface Specification, Sections4.2.1.8and4.2.2.16."::= { docsBpiCmtsTEKEntry 12 }docsBpiCmtsTEKInvalidErrorString OBJECT-TYPESYNTAX DisplayString (SIZE (0..128))MAX-ACCESS read-onlySTATUS currentDESCRIPTION"The value of this object is the Display-String in the most recent TEKInvalid message sent in association with this BPI SID. This is a zerolength string if no TEK Invalid message has been received since reboot."REFERENCE"DOCSIS Baseline Privacy Interface Specification, Sections4.2.1.8and4.2.2.6."::= { docsBpiCmtsTEKEntry 13 }---- The CMTS Multicast Control Group--docsBpiMulticastControl OBJECT IDENTIFIER ::= { docsBpiCmtsObjects 4 }---- The CMTS IP Multicast Mapping Table, indexed by IP multicast-- address and prefix, and by ifindex--docsBpiIpMulticastMapTable OBJECT-TYPESYNTAX SEQUENCE OF DocsBpiIpMulticastMapEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"This table describes the mapping of IP multicast address prefixes tomulticast SIDs on each CMTS MAC interface."::= { docsBpiMulticastControl 1 }docsBpiIpMulticastMapEntry OBJECT-TYPESYNTAX DocsBpiIpMulticastMapEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"Each entry contains objects describing the mapping of one IPmulticast address prefix to one multicast SID on one CMTS MACinterface. The CMTS uses the mapping when forwarding downstream IPmulticast traffic."Woundy Informational [Page 33]
RFC 3083 DOCSIS Baseline Privacy MIB March 2001INDEX { ifIndex, docsBpiIpMulticastAddress, docsBpiIpMulticastPrefixLength }::= { docsBpiIpMulticastMapTable 1 }DocsBpiIpMulticastMapEntry ::= SEQUENCE {docsBpiIpMulticastAddress IpAddress,docsBpiIpMulticastPrefixLength Integer32,docsBpiIpMulticastServiceId Integer32,docsBpiIpMulticastMapControl RowStatus}docsBpiIpMulticastAddress OBJECT-TYPESYNTAX IpAddressMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"This object represents the IP multicast address (prefix) to bemapped by this row, in conjunction withdocsBpiIpMulticastPrefixLength."::= { docsBpiIpMulticastMapEntry 1 }docsBpiIpMulticastPrefixLength OBJECT-TYPESYNTAX Integer32 (0..32)MAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"This object represents the IP multicast address prefix lengthfor this row. The value of this object represents the length inbits of docsBpiIpMulticastAddress for multicast addresscomparisons, using big-endian ordering. An IP multicast addressmatches this row if the (docsBpiIpMulticastPrefixLength) mostsignificant bits of the IP multicast address and of the(docsBpiIpMulticastAddress) are identical.This object is similar in usage to an IP address mask. The value0 corresponds to IP address mask 0.0.0.0, the value 1 correspondsto IP address mask 128.0.0.0, the value 8 corresponds to IPaddress mask 255.0.0.0, and the value 32 corresponds to IPaddress mask 255.255.255.255."::= { docsBpiIpMulticastMapEntry 2 }docsBpiIpMulticastServiceId OBJECT-TYPESYNTAX Integer32 (8192..16368)MAX-ACCESS read-createSTATUS currentDESCRIPTION"This object represents the multicast SID to be used in thisIP multicast address prefix mapping entry."-- DEFVAL is an unused multicast SID value chosen by CMTS.Woundy Informational [Page 34]
RFC 3083 DOCSIS Baseline Privacy MIB March 2001::= { docsBpiIpMulticastMapEntry 3 }docsBpiIpMulticastMapControl OBJECT-TYPESYNTAX RowStatusMAX-ACCESS read-createSTATUS currentDESCRIPTION"This object controls and reflects the IP multicast address prefixmapping entry. There is no restriction on the ability to change valuesin this row while the row is active."::= { docsBpiIpMulticastMapEntry 4 }---- The CMTS Multicast SID Authorization Table, indexed by ifIndex by-- multicast SID by CM MAC address--docsBpiMulticastAuthTable OBJECT-TYPESYNTAX SEQUENCE OF DocsBpiMulticastAuthEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"This table describes the multicast SID authorization for eachCM on each CMTS MAC interface."::= { docsBpiMulticastControl 2 }docsBpiMulticastAuthEntry OBJECT-TYPESYNTAX DocsBpiMulticastAuthEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"Each entry contains objects describing the key authorization of onecable modem for one multicast SID for one CMTS MAC interface."INDEX { ifIndex, docsBpiMulticastServiceId, docsBpiMulticastCmMacAddress }::= { docsBpiMulticastAuthTable 1 }DocsBpiMulticastAuthEntry ::= SEQUENCE {docsBpiMulticastServiceId Integer32,docsBpiMulticastCmMacAddress MacAddress,docsBpiMulticastAuthControl RowStatus}docsBpiMulticastServiceId OBJECT-TYPESYNTAX Integer32 (8192..16368)MAX-ACCESS not-accessibleSTATUS currentDESCRIPTIONWoundy Informational [Page 35]
RFC 3083 DOCSIS Baseline Privacy MIB March 2001"This object represents the multicast SID for authorization."::= { docsBpiMulticastAuthEntry 1 }docsBpiMulticastCmMacAddress OBJECT-TYPESYNTAX MacAddressMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION"This object represents the MAC address of the CM to which themulticast SID authorization applies."::= { docsBpiMulticastAuthEntry 2 }docsBpiMulticastAuthControl OBJECT-TYPESYNTAX RowStatusMAX-ACCESS read-createSTATUS currentDESCRIPTION"This object controls and reflects the CM authorization for eachmulticast SID. There is no restriction on the ability to changevalues in this row while the row is active."::= { docsBpiMulticastAuthEntry 3 }---- The BPI MIB Conformance Statements (with a placeholder for-- notifications)--docsBpiNotification OBJECT IDENTIFIER ::= { docsBpiMIB 2 }docsBpiConformance OBJECT IDENTIFIER ::= { docsBpiMIB 3 }docsBpiCompliances OBJECT IDENTIFIER ::= { docsBpiConformance 1 }docsBpiGroups OBJECT IDENTIFIER ::= { docsBpiConformance 2 }docsBpiBasicCompliance MODULE-COMPLIANCESTATUS currentDESCRIPTION"This is the compliance statement for devices which implement theDOCSIS Baseline Privacy Interface."MODULE -- docsBpiMIB-- conditionally mandatory groupGROUP docsBpiCmGroupDESCRIPTION"This group is implemented only in CMs, not in CMTSs."-- conditionally mandatory groupGROUP docsBpiCmtsGroupDESCRIPTIONWoundy Informational [Page 36]
RFC 3083 DOCSIS Baseline Privacy MIB March 2001"This group is implemented only in CMTSs, not in CMs."-- relaxation on mandatory range (unnecessary since object is read-only)-- OBJECT docsBpiCmAuthGraceTime-- SYNTAX Integer32 (300..1800)-- DESCRIPTION-- "The refined range corresponds to the minimum and maximum values in-- operational networks, according toAppendix A.2 in [18]."-- relaxation on mandatory range (unnecessary since object is read-only)-- OBJECT docsBpiCmTEKGraceTime-- SYNTAX Integer32 (300..1800)-- DESCRIPTION-- "The refined range corresponds to the minimum and maximum values in-- operational networks, according toAppendix A.2 in [18]."-- relaxation on mandatory rangeOBJECT docsBpiCmtsDefaultAuthLifetimeSYNTAX Integer32 (86400..6048000)DESCRIPTION"The refined range corresponds to the minimum and maximum values inoperational networks, according toAppendix A.2 in [18]."-- relaxation on mandatory rangeOBJECT docsBpiCmtsDefaultTEKLifetimeSYNTAX Integer32 (1800..604800)DESCRIPTION"The refined range corresponds to the minimum and maximum values inoperational networks, according toAppendix A.2 in [18]."-- relaxation on mandatory range (object removed from MIB)-- OBJECT docsBpiCmtsDefaultAuthGraceTime-- SYNTAX INTEGER (300..1800)-- DESCRIPTION-- "The refined range corresponds to the minimum and maximum values in-- operational networks, according toAppendix A.2 in [18]."-- relaxation on mandatory range (object removed from MIB)-- OBJECT docsBpiCmtsDefaultTEKGraceTime-- SYNTAX INTEGER (300..1800)-- DESCRIPTION-- "The refined range corresponds to the minimum and maximum values in-- operational networks, according toAppendix A.2 in [18]."-- relaxation on mandatory rangeOBJECT docsBpiCmtsAuthCmLifetimeSYNTAX Integer32 (86400..6048000)DESCRIPTIONWoundy Informational [Page 37]
RFC 3083 DOCSIS Baseline Privacy MIB March 2001"The refined range corresponds to the minimum and maximum values inoperational networks, according toAppendix A.2 in [18]."-- relaxation on mandatory range (unnecessary since object is read-only)-- OBJECT docsBpiCmtsAuthCmGraceTime-- SYNTAX Integer32 (300..1800)-- DESCRIPTION-- "The refined range corresponds to the minimum and maximum values in-- operational networks, according toAppendix A.2 in [18]."-- relaxation on mandatory rangeOBJECT docsBpiCmtsTEKLifetimeSYNTAX Integer32 (1800..604800)DESCRIPTION"The refined range corresponds to the minimum and maximum values inoperational networks, according toAppendix A.2 in [18]."-- relaxation on mandatory range (unnecessary since object is read-only)-- OBJECT docsBpiCmtsTEKGraceTime-- SYNTAX Integer32 (300..1800)-- DESCRIPTION-- "The refined range corresponds to the minimum and maximum values in-- operational networks, according toAppendix A.2 in [18]."::= { docsBpiCompliances 1 }docsBpiCmGroup OBJECT-GROUPOBJECTS {docsBpiCmPrivacyEnable,docsBpiCmPublicKey,docsBpiCmAuthState,docsBpiCmAuthKeySequenceNumber,docsBpiCmAuthExpires,docsBpiCmAuthReset,docsBpiCmAuthGraceTime,docsBpiCmTEKGraceTime,docsBpiCmAuthWaitTimeout,docsBpiCmReauthWaitTimeout,docsBpiCmOpWaitTimeout,docsBpiCmRekeyWaitTimeout,docsBpiCmAuthRejectWaitTimeout,docsBpiCmAuthRequests,docsBpiCmAuthReplies,docsBpiCmAuthRejects,docsBpiCmAuthInvalids,docsBpiCmAuthRejectErrorCode,docsBpiCmAuthRejectErrorString,docsBpiCmAuthInvalidErrorCode,Woundy Informational [Page 38]
RFC 3083 DOCSIS Baseline Privacy MIB March 2001docsBpiCmAuthInvalidErrorString,docsBpiCmTEKPrivacyEnable,docsBpiCmTEKState,docsBpiCmTEKExpiresOld,docsBpiCmTEKExpiresNew,docsBpiCmTEKKeyRequests,docsBpiCmTEKKeyReplies,docsBpiCmTEKKeyRejects,docsBpiCmTEKInvalids,docsBpiCmTEKAuthPends,docsBpiCmTEKKeyRejectErrorCode,docsBpiCmTEKKeyRejectErrorString,docsBpiCmTEKInvalidErrorCode,docsBpiCmTEKInvalidErrorString}STATUS currentDESCRIPTION"This collection of objects provides CM BPI status and control."::= { docsBpiGroups 1 }docsBpiCmtsGroup OBJECT-GROUPOBJECTS {docsBpiCmtsDefaultAuthLifetime,docsBpiCmtsDefaultTEKLifetime,docsBpiCmtsAuthRequests,docsBpiCmtsAuthReplies,docsBpiCmtsAuthRejects,docsBpiCmtsAuthInvalids,docsBpiCmtsAuthCmPublicKey,docsBpiCmtsAuthCmKeySequenceNumber,docsBpiCmtsAuthCmExpires,docsBpiCmtsAuthCmLifetime,docsBpiCmtsAuthCmGraceTime,docsBpiCmtsAuthCmReset,docsBpiCmtsAuthCmRequests,docsBpiCmtsAuthCmReplies,docsBpiCmtsAuthCmRejects,docsBpiCmtsAuthCmInvalids,docsBpiCmtsAuthRejectErrorCode,docsBpiCmtsAuthRejectErrorString,docsBpiCmtsAuthInvalidErrorCode,docsBpiCmtsAuthInvalidErrorString,docsBpiCmtsTEKLifetime,docsBpiCmtsTEKGraceTime,docsBpiCmtsTEKExpiresOld,docsBpiCmtsTEKExpiresNew,docsBpiCmtsTEKReset,docsBpiCmtsKeyRequests,Woundy Informational [Page 39]
RFC 3083 DOCSIS Baseline Privacy MIB March 2001docsBpiCmtsKeyReplies,docsBpiCmtsKeyRejects,docsBpiCmtsTEKInvalids,docsBpiCmtsKeyRejectErrorCode,docsBpiCmtsKeyRejectErrorString,docsBpiCmtsTEKInvalidErrorCode,docsBpiCmtsTEKInvalidErrorString,docsBpiIpMulticastServiceId,docsBpiIpMulticastMapControl,docsBpiMulticastAuthControl}STATUS currentDESCRIPTION"This collection of objects provides CMTS BPI status and control."::= { docsBpiGroups 2 }docsBpiObsoleteObjectsGroup OBJECT-GROUPOBJECTS {docsBpiCmtsDefaultAuthGraceTime,docsBpiCmtsDefaultTEKGraceTime}STATUS obsoleteDESCRIPTION"This is a collection of obsolete BPI objects."::= { docsBpiGroups 3 }END5. Acknowledgments This document was produced by the IPCDN Working Group. Much of the content of this MIB was conceived by Chet Birger and Mike StJohns. Kazuyoshi Ozawa and Bob Himlin provided many useful technical corrections.6. References [1] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks",RFC 2571, April 1999. [2] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16,RFC1155, May 1990. [3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16,RFC 1212, March 1991.Woundy Informational [Page 40]
RFC 3083 DOCSIS Baseline Privacy MIB March 2001 [4] Rose, M., "A Convention for Defining Traps for use with the SNMP",RFC 1215, March 1991. [5] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of e Management Information for Version 2 (SMIv2)", STD 58,RFC2578, April 1999. [6] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58,RFC 2579, April 1999. [7] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58,RFC 2580, April 1999. [8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15,RFC 1157, May 1990. [9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2",RFC 1901, January 1996. [10] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)",RFC 1906, January 1996. [11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)",RFC 2572, April 1999. [12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)",RFC 2574, April 1999. [13] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)",RFC 1905, January 1996. [14] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications",RFC2573, April 1999. [15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)",RFC 2575, April 1999. [16] St. Johns, M., editor, "Radio Frequency (RF) Interface Management Information Base for MCNS/DOCSIS compliant RF interfaces",RFC 2670, August 1999.Woundy Informational [Page 41]
RFC 3083 DOCSIS Baseline Privacy MIB March 2001 [17] St. Johns, M., editor, "DOCSIS Cable Device MIB, Cable Device Management Information Base for DOCSIS compliant Cable Modems and Cable Modem Termination Systems",RFC 2669, August 1999. [18] "Data-Over-Cable Service Interface Specifications: Baseline Privacy Interface Specification SP-BPI-I02-990319", DOCSIS, March 1999,http://www.cablemodem.com/. [19] "Data-Over-Cable Service Interface Specifications: Cable Modem Radio Frequency Interface Specification SP-RFI-I05-991105", DOCSIS, November 1999,http://www.cablemodem.com/. [20] "Data-Over-Cable Service Interface Specifications: Operations Support System Interface Specification RF Interface SP-OSSI-RF- I02-990113", DOCSIS, January 1999,http://www.cablemodem.com/. [21] "Data-Over-Cable Service Interface Specifications: Baseline Privacy Plus Interface Specification SP-BPI+-I05-000714", DOCSIS, July 2000,http://www.cablemodem.com/. [22] RSA Laboratories, "The Public-Key Cryptography Standards", RSA Data Security Inc., Redwood City, CA. [23] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels",BCP 14,RFC 2119, March 1997. [24] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework",RFC 2570, April 1999.7. Security Considerations The Baseline Privacy Interface provides data encryption for DOCSIS data-over-cable services. Baseline Privacy-capable cable modems have RSA private/public key pairs installed by manufacturers. The public key is used to encrypt an Authorization key, and the Authorization key is used to encrypt one or more Traffic Encryption Keys (TEKs). The TEKs are used to encrypt both upstream and downstream data traffic. Please refer to [18] to obtain further information on the Baseline Privacy specification. In particular, the Baseline Privacy Interface does not provide an authentication service. CMTS implementors are encouraged not to rely on the MAC address of the CM for service authorization -- in particular, for the docsBpiMulticastAuthTable in this MIB. The Baseline Privacy Plus Interface does provide a CM authentication service, and the working group expects to issue a MIB for the management of BPI+ at a later time.Woundy Informational [Page 42]
RFC 3083 DOCSIS Baseline Privacy MIB March 2001 This MIB specification contains a number of read-write objects, that should be protected from unauthorized modification to prevent denial of service and theft of service attacks: in particular, objects that reset state machines (ex. docsBpiCmAuthReset), change key lifetimes (ex. docsBpiCmtsDefaultAuthLifetime), change rekeying grace times (ex. docsBpiCmtsDefaultAuthGraceTime), and control multicast traffic (ex. most objects in the docsBpiMulticastControl group). The desired means to protect these objects from unwarranted access is to implement the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model [12] and the View-based Access Control Model [15] is recommended. Weaker methods to protect CMs from unauthorized access include using the docsDevNmAccessTable from the Cable Device MIB [17] to disallow configuration changes from unauthorized network management stations, and using the SNMP MIB Object and SNMP Write-Access Control configuration file options from the Radio Frequency Interface [19] to set MIB object values and disable SNMP SET operations at cable modem boot time. Note that these mechanisms may be vulnerable to an unauthorized network management station "spoofing" the source address of a legitimate network management station.8. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found inBCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.Woundy Informational [Page 43]
RFC 3083 DOCSIS Baseline Privacy MIB March 20019. Author's Address Richard Woundy Cisco Systems 250 Apollo Drive Chelmsford, MA 01824 U.S.A. Phone: +1 978 244 8000 EMail: rwoundy@cisco.comWoundy Informational [Page 44]
RFC 3083 DOCSIS Baseline Privacy MIB March 200110. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.Woundy Informational [Page 45]
[8]ページ先頭