Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modems and Cable Modem Termination Systems for Baseline Privacy Plus
updated by
- rfc-9141 — Updating References to the IETF FTP Service
Extracted elements (29)
The docsBpi2CmtsIpMulticastMapTable uses InetAddress rather than InetAddressPrefixLength for the multicast mask object because the mask may be non-contiguous, enabling assignment of one SAID to multiple IPv6 multicast groups spanning non-contiguous scopes (e.g., any scope for a given group ID using mask FF10:Y).
The MIB design reflects the DOCSIS 1.1/2.0 requirement that CMs process only IPv4 customer traffic; the document explicitly notes that future DOCSIS versions are expected to require IPv6 support, which will necessitate MIB updates.
BPI+ is a distinct protocol from DOCSIS 1.0 BPI, not merely an enhancement; the BPI+ MIB objects (this document) are separate from the BPI MIB (RFC 3083). DOCSIS 1.1 and 2.0 systems implement both protocols to maintain backward compatibility with DOCSIS 1.0 systems.
When a CM is operating in BPI mode (not BPI+), the CMTS must map SAIDs and SIDs (Service IDs) to one contiguous space; for BPI-mode CMs, docsBpi2CmtsAuthCmReset's invalidateTeks action applies to all unicast TEKs rather than the primary SAID's TEKs.
The CM MUST create one entry in docsBpi2CmTEKTable per SAID, regardless of whether the SAID was obtained from a Registration Response, an Authorization Reply, or any dynamic SAID establishment mechanism.
The CMTS MUST create one entry in docsBpi2CmtsAuthTable per CM per MAC interface upon receipt of an Authorization Request message, and MUST NOT delete the entry until the CM loses registration.
The docsBpi2CmDeviceCmCert object can be set only when the current value is the zero-length OCTET STRING; once populated, its access MUST be read-only and the value MUST persist after re-initialization of the managed system.
docsBpi2CmBaseTable (indexed by ifIndex) contains authorization key exchange information for each CM MAC interface, including authorization state, key sequence number, old and new key expiry times, grace times, FSM timeout parameters, and BPKM message counters.
docsBpi2CmCryptoSuiteTable enumerates the cryptographic suite capability pairs (data encryption algorithm + data authentication algorithm) supported by each CM MAC interface, allowing management systems to discover which suites a CM can negotiate.
docsBpi2CmDeviceCertTable stores the DER-encoded CM device certificate (docsBpi2CmDeviceCmCert, read-write until populated) and the manufacturer certificate that signed it (docsBpi2CmDeviceManufCert, read-only), indexed by CM MAC interface.
docsBpi2CmIpMulticastMapTable maps multicast IP addresses to SAIDs per CM MAC interface, recording the SA Mapping FSM state, SA Map Request/Reply/Reject counters, and the most recent SA Map Reject error code and string for each multicast IP.
docsBpi2CmTEKTable (indexed by ifIndex and SAID) contains TEK association attributes for each security association on a CM MAC interface, including TEK FSM state, key sequence number, expiry times, encryption and authentication algorithms, and Key Request/Reply/Reject/Invalid counters.
docsBpi2CmtsAuthCmReset is a read-write management action object with values invalidateAuth(2), sendAuthInvalid(3), and invalidateTeks(4), allowing operators to progressively invalidate CM authorization keys, trigger an Authorization Invalid message to the CM, and invalidate the primary SAID's TEKs.
docsBpi2CmtsAuthTable maintains one authorization association entry per CM per CMTS MAC interface, recording the CM's BPI version (bpi or bpiPlus), RSA public key, authorization key sequence number, expiry times, per-CM BPKM message counters, and the CM's BPKM certificate extracted from the Authorization Request.
docsBpi2CmtsBaseTable provides CMTS-wide BPI+ settings and aggregate counters: default authorization key lifetime (default 604800 s), default TEK lifetime (default 43200 s), self-signed manufacturer certificate trust policy, and a flag to enable or disable certificate validity period checking.
DocsBpkmDataAuthentAlg enumerates data integrity algorithms for the BPKM cryptographic-suite parameter: none(0) and hmacSha196(1). The value none indicates no data integrity is applied to the referenced SAID.
DocsBpkmDataEncryptAlg enumerates data encryption algorithms for the BPKM cryptographic-suite parameter: none(0), des56CbcMode(1), des40CbcMode(2), t3Des128CbcMode(3), aes128CbcMode(4), aes256CbcMode(5).
DocsBpkmSAType enumerates security association types: none(0), primary(1), static(2), and dynamic(3), corresponding directly to BPKM SA-Type attribute codes 1–3. The none value is used only when the SA type has not yet been determined.
The docsBpi2CodeDownloadControl objects manage authenticated software image download for both CM and CMTS devices, forming a common group in the BPI+ MIB that covers the fourth functional area of BPI+: authentication of downloaded software images.
The DOCS-IETF-BPI2-MIB module is registered at { mib-2 126 }, establishing the OID arc for all BPI+ managed objects for DOCSIS cable modems and CMTSs.
Several BPI+ MIB objects have read-write or read-create access, including objects that invalidate authorization keys, set TEK lifetimes, and control certificate trust policies; unauthorized write access to these objects could allow an attacker to disrupt BPI+ security or deny service to cable modems.
The docsBpi2CmtsCheckCertValidityPeriods object controls whether certificate validity periods are checked against current time during CM authorization; setting it to false disables temporal certificate validation for the entire CMTS MAC interface, potentially allowing expired certificates to authenticate.
The docsBpi2CmtsDefaultSelfSignedManufCertTrust object sets a CMTS-wide default trust level for newly added self-signed manufacturer certificates; setting it to 'trusted' permits CM authentication based on unverified self-signed manufacturer certificates, weakening the BPI+ PKI chain of trust.
The CM Authorization FSM (docsBpi2CmAuthState) has six states: start, authWait, authorized, reauthWait, authRejectWait, and silent. Transitions are triggered by authorization protocol events including requests, replies, rejects, invalids, and timeouts.
The CM SA Mapping FSM (docsBpi2CmIpMulticastSAMapState) has three states: start, mapWait, and mapped. It tracks the resolution of multicast IP addresses to SAIDs via SA Map Request, SA Map Reply, and SA Map Reject messages.
The CM TEK (Traffic Encryption Key) FSM (docsBpi2CmTEKState) has six states: start, opWait, opReauthWait, operational, rekeyWait, and rekeyReauthWait. Transitions are driven by Key Request, Key Reply, Key Reject, TEK Invalid messages, and Authorization Pending events.
DocsSAId is an Integer32 in the range 1..16383 representing a DOCSIS Security Association Identifier (SAID). DocsSAIdOrZero extends this to Unsigned32 (0 | 1..16383), where zero indicates the SAID is not yet determined.
DocsX509ASN1DEREncodedCertificate is an OCTET STRING of SIZE 0..4096 bytes encoding an X.509 digital certificate in ASN.1 DER format, used for both CM device certificates and CA certificates in the BPI+ PKI.
The CM RSA public key (docsBpi2CmPublicKey, docsBpi2CmtsAuthCmPublicKey) is an OCTET STRING of SIZE 0..524, encoding a DER-encoded RSAPublicKey ASN.1 type as defined in PKCS #1.