Multimedia Terminal Adapter (MTA) Management Information Base for PacketCable- and IPCablecom-Compliant Devices
updated by
- rfc-9141 — Updating References to the IETF FTP Service
Extracted elements (29)
pktcMtaDevRealmOrgName uses the LongUtf8String syntax (rather than ASCII) to accommodate the X.509 OrganizationName attribute from the Telephony Service Provider certificate, which is defined using UTF-8 encoding. UTF-8 characters may span 1–4 octets under RFC 3629.
S-MTAs implement a dedicated Secure Software Download mechanism (using Code Verification Certificates, modeled after DOCSIS) because they are separated from the cable modem by a non-DOCSIS interface. E-MTAs have their software upgraded directly by the embedded DOCSIS Cable Modem and therefore do not need this mechanism.
The pktcMtaDevErrorOidsTable is limited to 1024 entries because configuration files are usually validated by operators before deployment, making 1024 a sufficient bound even with future extensions. Errors beyond 1024 are silently discarded with the 1024th entry overwritten to signal overflow.
Wherever PacketCable and IPCablecom requirements are equivalent, the PacketCable reference is used in MIB object REFERENCE clauses. However, IPCablecom-compliant MTA devices MUST use the equivalent IPCablecom references (e.g., ITU-T J.168 and ETSI TS 101 909-8) instead.
For any object where a value is written via SNMP SET (pktcMtaDevResetNow, pktcMtaDevEnabled, pktcMtaDevProvisioningTimer, DNS servers, time server, config file, config hash, config key, various timeout objects), the agent MUST NOT retain the supplied value across MTA re-initializations or reboots.
If the MTA did not report a provisioning state of 'pass(1)', the pktcMtaDevErrorOidsTable MUST be populated for each error or warning instance, even when different parameters share the same error type. Errors beyond the 1024th MUST be ignored and the 1024th entry MUST be overwritten to indicate 'too many errors'.
In non-secure provisioning modes, pktcMtaDevProvSolicitedKeyTimeout, pktcMtaDevProvUnsolicitedKeyMaxTimeout, pktcMtaDevProvUnsolicitedKeyNomTimeout, and pktcMtaDevProvUnsolicitedKeyMaxRetries MUST return zero in response to SNMP GET operations, and MUST return 'inconsistentValue' for SET operations.
In secure SNMPv3 provisioning mode, the Kerberos realm name for the Provisioning Server supplied in the MTA configuration file MUST match the value supplied in DHCP option code 122, sub-option 6; otherwise, the object must contain the DHCP-supplied value.
Once pktcMtaDevRealmName and pktcMtaDevRealmOrgName have been SET and the row status is 'active(1)', the MTA MUST NOT allow any modification of these two object values. A realm row is not qualified for activation until both objects are explicitly SET.
pktcMtaDevConfigFile, when the MTA SNMP Enrollment mechanism is not used, MUST contain the TFTP URL derived from the 'siaddr' and 'file' fields of the DHCP ACK, and the MTA MUST return an 'inconsistentValue' error in response to SNMP SET operations.
The MTA MUST complete all provisioning operations from DHCP ACK receipt through configuration file download (steps MTA5–MTA23) within the pktcMtaDevProvisioningTimer interval (0–30 minutes, default 10). If the object is set to 0, the MTA MUST ignore the provisioning timer condition.
The MTA MUST initiate the PKINIT exchange at time TicketEXP - PKINITGP (default grace period 15 minutes) to renew Application Server tickets. If the MTA possesses a TGS ticket for a Provisioning Server or current CMS, it MUST initiate the TGS Request/Reply exchange at TicketEXP - TGSGP (default 10 minutes).
The MTA MUST prohibit the instantiation of any two rows with identical Kerberos realm names in pktcMtaDevRealmTable, and MUST perform all Kerberos realm name search operations using the uppercase ASCII representation. The uppercase Kerberos realm name MUST be used by both Manager and MTA.
The value of pktcMtaDevSerialNumber MUST be identical to the value specified in DHCP option 43, sub-option 4. Similarly, pktcMtaDevSwCurrentVers MUST be identical to both the sysDescr MIB object and DHCP option 43, sub-option 6.
When pktcMtaDevEnabled is set to 'false', the MTA MUST immediately shut down all media sessions and NCS signaling via Restart in Progress procedures for all endpoints, MUST maintain SNMP management and key management interfaces, and MUST NOT continue Kerberized key management with CMSes until re-enabled.
When the MTA receives wake-up or re-key messages from a CMS, it performs key management based on the corresponding entry in the CMS table. If the matching CMS entry does not exist, it must ignore the wake-up or re-key messages.
pktcMtaDevCmsTable (up to 128 entries, indexed by pktcMtaDevCmsIndex) stores parameters for Security Association establishment between the MTA and each Call Management Server, including the CMS FQDN and the associated Kerberos realm name that links to pktcMtaDevRealmTable.
pktcMtaDevErrorOidsTable records configuration file errors and warnings encountered during provisioning, up to a maximum of 1024 entries. Each row contains the erroneous OID (pktcMtaDevErrorOid), its value (pktcMtaDevErrorValue), and a human-readable reason (pktcMtaDevErrorReason). The table MUST be cleared on each reboot.
pktcMtaDevProvConfigHash is an OCTET STRING of SIZE(20) holding the SHA-1 (160-bit) hash of the MTA configuration file content. When the SNMP Enrollment mechanism is used, this value is SET by the Provisioning Server; otherwise the MTA calculates and reflects it, and MUST reject SET operations.
pktcMtaDevProvisioningState is a read-only integer object indicating MTA provisioning completion: pass(1), inProgress(2), failConfigFileError(3), passWithWarnings(4), passWithIncompleteParsing(5), failureInternalError(6), failureOtherReason(7). This value is also included in the final SNMP INFORM at step 25 of provisioning.
pktcMtaDevProvState is a read-only integer object tracking the live provisioning state machine: operational(1), waitingForSnmpSetInfo(2), waitingForTftpAddrResponse(3), waitingForConfigFile(4). States 2 and 3 are only reported when the MTA SNMP enrollment mechanism is used.
pktcMtaDevRealmTable (up to 64 entries, indexed by pktcMtaDevRealmIndex) stores Kerberos realm parameters per realm, including realm name, PKINIT grace period (15–600 min), TGS grace period (1–600 min), organization name, and exponential back-off timers for unsolicited key management. Rows MUST NOT persist across MTA reboots.
The MTA MIB module is structured into three object groups: pktcMtaDevBase (device characteristics), pktcMtaDevServer (back office servers and timers), and pktcMtaDevSecurity (security associations, KDC realms, and CMSes). A fourth subtree pktcMtaDevErrors holds configuration error reporting objects.
The PktcMtaDevProvEncryptAlg textual convention defines encryption algorithms for MTA configuration file privacy: none(0), des64CbcMode(1), t3Des192CbcMode(2), aes128CbcMode(3), and aes256CbcMode(4). The default value is des64CbcMode(1).
The PKTC-IETF-MTA-MIB module is registered under mib-2 140, assigned as pktcIetfMtaMib. This establishes the OID arc for all MTA MIB objects defined in this document.
pktcMtaDevProvConfigKey (OCTET STRING SIZE 32) holds the encryption key for the configuration file and MUST NOT be used in non-secure provisioning modes; in those modes the MTA SHOULD return 'inconsistentValue' on SET and a zero-length string on GET. This object MUST NOT be retained across reboots.
Several MIB objects in the MTA MIB expose sensitive information or allow control operations (pktcMtaDevResetNow, pktcMtaDevEnabled, pktcMtaDevProvConfigKey, pktcMtaDevProvConfigHash, certificate objects) and MUST be protected using SNMPv3 with appropriate access control. Implementations MUST NOT deploy SNMPv1 or SNMPv2c for write access to these objects.
The MTA uses X.509 Public Key Infrastructure certificates (Manufacturer Certificate, Device Certificate, and Telephony Service Provider Root Certificate) stored in non-volatile memory for mutual authentication with the KDC and provisioning infrastructure. These can only be updated via secure code download.
Kerberos unsolicited key management uses an exponential back-off state machine with three parameters: nominal timeout (default 3 s for provisioning server, 3000 ms for realm), maximum timeout cap (default 600 s for provisioning, 100 s for realm), and maximum retries (default 8 for provisioning, 5 for realm). Retransmissions double each interval until capped, then stop when the retry counter is exhausted.