RFC 4682
Multimedia Terminal Adapter (MTA) Management Information Base for PacketCable- and IPCablecom-Compliant Devices
pktcMtaDevRealmUnsolicitedKeyMaxTimeout OBJECT-TYPE
SYNTAX Unsigned32 (1..600)
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" This object specifies the maximum time the MTA will
attempt to perform the exponential back-off algorithm.
This timer only applies when the MTA initiated key
management. If the DHCP option code 122, sub-option 4, is
provided to the MTA, it overwrites this value.
Unsolicited key updates are retransmitted according to an
exponential back-off mechanism using two timers and a
maximum retry counter for AS replies.
The initial retransmission timer value is the nominal
timer value (pktcMtaDevRealmUnsolicitedKeyNomTimeout). The
retransmissions occur with an exponentially increasing
interval that caps at the maximum timeout value
(pktcMtaDevRealmUnsolicitedKeyMaxTimeout).
Retransmissions stop when the maximum retry counter is
reached (pktcMatDevRealmUnsolicitedMaxRetries).
For example, with values of 3 seconds for the nominal
timer, 20 seconds for the maximum timeout, and 5 retries
max, retransmission intervals will be 3 s, 6 s,
12 s, 20 s, and 20 s, and retransmissions then stop because
the maximum number of retries has been reached."
REFERENCE
" PacketCable Security Specification."
DEFVAL { 100 }
::= { pktcMtaDevRealmEntry 6 }
pktcMtaDevRealmUnsolicitedKeyNomTimeout OBJECT-TYPE
SYNTAX Unsigned32 (100..600000)
UNITS "milliseconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" This object specifies the initial timeout value
for the AS-REQ/AS-REP exponential back-off and retry
mechanism. If the DHCP option code 122, sub-option 4, is
provided to the MTA, it overwrites this value.
This value should account for the average roundtrip
time between the MTA and the KDC, as well as the
processing delay on the KDC.
Unsolicited key updates are retransmitted according to an
exponential back-off mechanism using two timers and a
maximum retry counter for AS replies.
The initial retransmission timer value is the nominal
timer value (pktcMtaDevRealmUnsolicitedKeyNomTimeout). The
retransmissions occur with an exponentially increasing
interval that caps at the maximum timeout value
(pktcMtaDevRealmUnsolicitedKeyMaxTimeout).
Retransmissions stop when the maximum retry counter is
reached (pktcMatDevRealmUnsolicitedMaxRetries).
For example, with values of 3 seconds for the nominal
timer, 20 seconds for the maximum timeout, and 5 retries
max, in retransmission intervals will be 3 s, 6 s,
12 s, 20 s, and 20 s; retransmissions then stop because
the maximum number of retries has been reached."
REFERENCE
" PacketCable Security Specification."
DEFVAL { 3000 }
::= { pktcMtaDevRealmEntry 7 }
pktcMtaDevRealmUnsolicitedKeyMaxRetries OBJECT-TYPE
SYNTAX Unsigned32 (0..1024)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" This object specifies the maximum number of retries the
MTA attempts to obtain a ticket from the KDC.
Unsolicited key updates are retransmitted according to an
exponential back-off mechanism using two timers and a
maximum retry counter for AS replies.
The initial retransmission timer value is the nominal
timer value (pktcMtaDevRealmUnsolicitedKeyNomTimeout). The
retransmissions occur with an exponentially increasing
interval that caps at the maximum timeout value
(pktcMtaDevRealmUnsolicitedKeyMaxTimeout).
Retransmissions stop when the maximum retry counter is
reached (pktcMatDevRealmUnsolicitedMaxRetries).
For example, with values of 3 seconds for the nominal
timer, 20 seconds for the maximum timeout, and 5 retries
max, retransmission intervals will be 3 s, 6 s,
12 s, 20 s, and 20 s; retransmissions then stop because
the maximum number of retries has been reached."
REFERENCE
" PacketCable Security Specification."
DEFVAL { 5 }
::= { pktcMtaDevRealmEntry 8 }
pktcMtaDevRealmStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" This object defines the row status of this realm in the
realm table (pktcMtaDevRealmTable).
An entry in this table is not qualified for activation
until the object instances of all corresponding columns
have been initialized, either by default values, or via
explicit SET operations. Until all object instances in
this row are initialized, the status value for this realm
must be 'notReady(3)'.
In particular, two columnar objects must be explicitly
SET: the realm name (pktcMtaDevRealmName) and the
organization name (pktcMtaDevRealmOrgName). Once these 2
objects have been set and the row status is SET to
'active(1)', the MTA MUST NOT allow any modification of
these 2 object values.
The value of this object has no effect on whether other
columnar objects in this row can be modified."
::= { pktcMtaDevRealmEntry 9 }
--=================================================================
--
-- The CMS table, pktcMtaDevCmsTable
--
-- The CMS table and the realm table (pktcMtaDevRealmTable) are used
-- for managing the MTA signaling security. The CMS table defines
-- the CMSes the MTA is allowed to communicate with and contains
-- the parameters describing the SA establishment between the MTA
-- and a CMS.
-- The CMS table is indexed by pktcMtaDevCmsIndex. The table
-- contains the CMS FQDN (pktcMtaDevCmsFQDN) and the associated
-- Kerberos realm name (pktcMtaDevCmsKerbRealmName) so that the MTA
-- can find the corresponding Kerberos realm name in the
-- pktcMtaDevRealmTable.
--
--=================================================================
pktcMtaDevCmsAvailSlot OBJECT-TYPE
SYNTAX Unsigned32 (0..128)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object contains the index number of the first
available entry in the CMS table (pktcMtaDevCmsTable).
If all the entries in the CMS table have been assigned,
this object contains the value of zero.
A management station should create new entries in the
CMS table, using the following procedure:
First, issue a management protocol retrieval operation
to determine the value of the first available index in the
CMS table (pktcMtaDevCmsAvailSlot).
Second, issue a management protocol SET operation
to create an instance of the pktcMtaDevCmsStatus
object by setting its value to 'createAndWait(5)'.
Third, if the SET operation succeeded, continue
modifying the object instances corresponding to the newly
created conceptual row, without fear of collision with
other management stations. When all necessary conceptual
columns of the row are properly populated (via SET
operations or default values), the management station may
SET the pktcMtaDevCmsStatus object to 'active(1)'."
::= { pktcMtaDevSecurity 7 }
pktcMtaDevCmsTable OBJECT-TYPE
SYNTAX SEQUENCE OF PktcMtaDevCmsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
" This object defines the CMS table.
The CMS table (pktcMtaDevCmsTable) and the realm table
(pktcMtaDevRealmTable) are used for managing security
between the MTA and CMSes. Each CMS table entry defines
a CMS the managed MTA is allowed to communicate with
and contains security parameters for key management with
that CMS."
::= { pktcMtaDevSecurity 8 }
pktcMtaDevCmsEntry OBJECT-TYPE
SYNTAX PktcMtaDevCmsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
" This table entry object lists the MTA key management
parameters used when establishing Security Associations
with a CMS. The conceptual rows MUST NOT persist across
MTA reboots."
INDEX { pktcMtaDevCmsIndex }
::= { pktcMtaDevCmsTable 1 }
PktcMtaDevCmsEntry ::= SEQUENCE {
pktcMtaDevCmsIndex Unsigned32,
pktcMtaDevCmsFqdn SnmpAdminString,
pktcMtaDevCmsKerbRealmName SnmpAdminString,
pktcMtaDevCmsMaxClockSkew Unsigned32,
pktcMtaDevCmsSolicitedKeyTimeout Unsigned32,
pktcMtaDevCmsUnsolicitedKeyMaxTimeout Unsigned32,
pktcMtaDevCmsUnsolicitedKeyNomTimeout Unsigned32,
pktcMtaDevCmsUnsolicitedKeyMaxRetries Unsigned32,
pktcMtaDevCmsIpsecCtrl TruthValue,
pktcMtaDevCmsStatus RowStatus
}
pktcMtaDevCmsIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..128)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
" This object defines the CMS table index."
::= { pktcMtaDevCmsEntry 1 }
pktcMtaDevCmsFqdn OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(1..255))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" This object specifies the CMS FQDN. The MTA must
prohibit the instantiation of any two rows with identical
FQDNs. The MTA must also verify that any search and/or
comparison operation involving a CMS FQDN is case
insensitive. The MTA must resolve the CMS FQDN as required
by the corresponding PacketCable Specifications."
REFERENCE
" PacketCable MTA Device Provisioning Specification;
PacketCable Security Specification;
PacketCable Network-Based Call Signaling Protocol
Specification."
::= { pktcMtaDevCmsEntry 2 }
pktcMtaDevCmsKerbRealmName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(1..255))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" This object identifies the Kerberos realm name in uppercase
characters associated with the CMS defined in this
conceptual row. The object value is a reference
point to the corresponding Kerberos realm name in the
realm table (pktcMtaDevRealmTable)."
::= { pktcMtaDevCmsEntry 3 }
pktcMtaDevCmsMaxClockSkew OBJECT-TYPE
SYNTAX Unsigned32 (1..1800)
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" This object specifies the maximum allowable clock skew
between the MTA and the CMS defined in this row."
DEFVAL { 300 }
::= { pktcMtaDevCmsEntry 4 }
pktcMtaDevCmsSolicitedKeyTimeout OBJECT-TYPE
SYNTAX Unsigned32 (100..30000)
UNITS "milliseconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" This object defines a Kerberos Key Management timer on the
MTA. It is the time period during which the MTA saves the
nonce and Server Kerberos Principal Identifier to match an
AP Request and its associated AP Reply response from the
CMS. This timer only applies when the CMS initiated key
management (with a Wake Up message or a Rekey message)."
REFERENCE
" PacketCable Security Specification."
DEFVAL { 1000 }
::= { pktcMtaDevCmsEntry 5 }
--=================================================================
--
-- Unsolicited key updates are retransmitted according to an
-- exponential back-off mechanism using two timers and a maximum
-- retry counter for AS replies.
-- The initial retransmission timer value is the nominal timer
-- value (pktcMtaDevCmsUnsolicitedKeyNomTimeout). The
-- retransmissions occur with an exponentially increasing interval
-- that caps at the maximum timeout value
-- (pktcMtaDevCmsUnsolicitedKeyMaxTimeout).
-- Retransmissions stop when the maximum retry counter is reached
-- (pktcMatDevCmsUnsolicitedMaxRetries).
-- For example, with values of 3 seconds for the nominal
-- timer, 20 seconds for the maximum timeout, and 5 retries max,
-- retransmission intervals will be 3 s, 6 s, 12 s,
-- 20 s, and 20 s; retransmissions then stop due to the
-- maximum number of retries reached.
--
--=================================================================
pktcMtaDevCmsUnsolicitedKeyMaxTimeout OBJECT-TYPE
SYNTAX Unsigned32 (1..600)
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" This object defines the timeout value that only applies
to an MTA-initiated key management exchange. It is the
maximum timeout, and it may not be exceeded in the
exponential back-off algorithm."
REFERENCE
" PacketCable Security Specification."
DEFVAL { 600 }
::= { pktcMtaDevCmsEntry 6 }
pktcMtaDevCmsUnsolicitedKeyNomTimeout OBJECT-TYPE
SYNTAX Unsigned32 (100..30000)
UNITS "milliseconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" This object defines the starting value of the timeout
for an MTA-initiated key management. It should account for
the average roundtrip time between the MTA and the CMS and
the processing time on the CMS."
REFERENCE
" PacketCable Security Specification."
DEFVAL { 500 }
::= { pktcMtaDevCmsEntry 7 }
pktcMtaDevCmsUnsolicitedKeyMaxRetries OBJECT-TYPE
SYNTAX Unsigned32 (0..1024)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" This object contains the maximum number of retries before
the MTA stops attempting to establish a Security
Association with the CMS."
REFERENCE
" PacketCable Security Specification."
DEFVAL { 5 }
::= { pktcMtaDevCmsEntry 8 }
pktcMtaDevCmsIpsecCtrl OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object specifies the MTA IPSec control flag.
If the object value is 'true', the MTA must use Kerberos
Key Management and IPsec to communicate with this CMS. If
it is 'false', IPSec Signaling Security and Kerberos key
management are disabled for this specific CMS."
DEFVAL { true }
::= { pktcMtaDevCmsEntry 9 }
pktcMtaDevCmsStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" This object defines the row status associated with this
particular CMS in the CMS table (pktcMtaDevCmsTable).
An entry in this table is not qualified for activation
until the object instances of all corresponding columns
have been initialized, either by default values or via
explicit SET operations. Until all object instances in
this row are initialized, the status value for this realm
must be 'notReady(3)'.
In particular, two columnar objects must be SET: the
CMS FQDN (pktcMtaDevCmsFqdn) and the Kerberos realm name
(pktcMtaDevCmsKerbRealmName). Once these 2 objects have
been set and the row status is SET to 'active(1)', the MTA
MUST NOT allow any modification of these 2 object values.
The value of this object has no effect on
whether other columnar objects in this row can be
modified."
::= { pktcMtaDevCmsEntry 10 }
pktcMtaDevResetKrbTickets OBJECT-TYPE
SYNTAX BITS {
invalidateProvOnReboot (0),
invalidateAllCmsOnReboot (1)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
" This object defines a Kerberos Ticket Control Mask that
instructs the MTA to invalidate the specific Application
Server Kerberos ticket(s) that are stored locally in the
MTA NVRAM (non-volatile or persistent memory).
If the MTA does not store Kerberos tickets in NVRAM, it
MUST ignore setting of this object and MUST report a BITS
value of zero when the object is read.
If the MTA supports Kerberos tickets storage in NVRAM, the
object value is encoded as follows:
- Setting the invalidateProvOnReboot bit (bit 0) to 1
means that the MTA MUST invalidate the Kerberos
Application Ticket(s) for the Provisioning Application
at the next MTA reboot if secure SNMP provisioning mode
is used. In non-secure provisioning modes, the MTA MUST
return an 'inconsistentValue' in response to SNMP SET
operations with a bit 0 set to 1.
- Setting the invalidateAllCmsOnReboot bit (bit 1) to 1
means that the MTA MUST invalidate the Kerberos
Application Ticket(s) for all CMSes currently assigned
to the MTA endpoints.
If a value is written into an instance of
pktcMtaDevResetKrbTickets, the agent MUST retain the
supplied value across an MTA re-initialization or
reboot."
REFERENCE
"PacketCable Security Specification."
DEFVAL { { } }
::= { pktcMtaDevSecurity 9 }
--
-- The following group, pktcMtaDevErrors, defines an OID
-- corresponding to error conditions encountered during the MTA
-- provisioning.
--
pktcMtaDevErrorsTooManyErrors OBJECT-IDENTITY
STATUS current
DESCRIPTION
"This object defines the OID corresponding to the error
condition when too many errors are encountered in the
MTA configuration file during provisioning."
::= { pktcMtaDevErrors 1 }
pktcMtaDevProvisioningEnrollment NOTIFICATION-TYPE
OBJECTS {
sysDescr,
pktcMtaDevSwCurrentVers,
pktcMtaDevTypeIdentifier,
ifPhysAddress,
pktcMtaDevCorrelationId
}
STATUS current
DESCRIPTION
" This INFORM notification is issued by the MTA to initiate
the PacketCable provisioning process when the MTA SNMP
enrollment mechanism is used.
It contains the system description, the current software
version, the MTA device type identifier, the MTA MAC
address (obtained in the MTA ifTable in the ifPhysAddress
object that corresponds to the ifIndex 1), and a
correlation ID."
::= { pktcMtaNotification 1 }
pktcMtaDevProvisioningStatus NOTIFICATION-TYPE
OBJECTS {
ifPhysAddress,
pktcMtaDevCorrelationId,
pktcMtaDevProvisioningState
}
STATUS current
DESCRIPTION
" This INFORM notification may be issued by the MTA to
confirm the completion of the PacketCable provisioning
process, and to report its provisioning completion
status.
It contains the MTA MAC address (obtained in the MTA
ifTable in the ifPhysAddress object that corresponds
to the ifIndex 1), a correlation ID and the MTA
provisioning state as defined in
pktcMtaDevProvisioningState."
::= { pktcMtaNotification 2 }
--
-- Compliance Statements
--
pktcMtaCompliances OBJECT IDENTIFIER ::= { pktcMtaConformance 1 }
pktcMtaGroups OBJECT IDENTIFIER ::= { pktcMtaConformance 2 }
pktcMtaBasicCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
" The compliance statement for MTA devices that implement
PacketCable or IPCablecom requirements.
This compliance statement applies to MTA implementations
that support PacketCable 1.0 or IPCablecom requirements,
which are not IPv6-capable at the time of this
RFC publication."
MODULE -- Unconditionally mandatory groups for MTAs
MANDATORY-GROUPS {
pktcMtaGroup,
pktcMtaNotificationGroup
}
OBJECT pktcMtaDevDhcpServerAddressType
SYNTAX InetAddressType { ipv4(1) }
DESCRIPTION
" Support for address types other than 'ipv4(1)'
is not presently specified and therefore is not
required. It may be defined in future versions of
this MIB module."
OBJECT pktcMtaDevDnsServerAddressType
SYNTAX InetAddressType { ipv4(1) }
DESCRIPTION
" Support for address types other than 'ipv4(1)'
is not presently specified and therefore is not
required. It may be defined in future versions of
this MIB module."
OBJECT pktcMtaDevTimeServerAddressType
SYNTAX InetAddressType { ipv4(1) }
DESCRIPTION
" Support for address types other than 'ipv4(1)'
is not presently specified and therefore is not
required. It may be defined in future versions of
this MIB module."
OBJECT pktcMtaDevServerDhcp1
SYNTAX InetAddress (SIZE(4))
DESCRIPTION
"An implementation is only required to support IPv4
addresses. Other address types support may be defined in
future versions of this MIB module."
OBJECT pktcMtaDevServerDhcp2
SYNTAX InetAddress (SIZE(4))
DESCRIPTION
"An implementation is only required to support IPv4
addresses. Other address types support may be defined in
future versions of this MIB module."
OBJECT pktcMtaDevServerDns1
SYNTAX InetAddress (SIZE(4))
DESCRIPTION
"An implementation is only required to support IPv4
addresses. Other address types support may be defined in
future versions of this MIB module."
OBJECT pktcMtaDevServerDns2
SYNTAX InetAddress (SIZE(4))
DESCRIPTION
"An implementation is only required to support IPv4
addresses. Other address types support may be defined in
future versions of this MIB module."
OBJECT pktcMtaDevTimeServer
SYNTAX InetAddress (SIZE(4))
DESCRIPTION
"An implementation is only required to support IPv4
addresses. Other address types support may be defined in
future versions of this MIB module."
OBJECT pktcMtaDevProvConfigEncryptAlg
SYNTAX PktcMtaDevProvEncryptAlg
DESCRIPTION
"An implementation is only required to support
values of none(0) and des64Cbcmode(1).
An IV of zero is used to encrypt in des64Cbcmode, and
the length of pktcMtaDevProvConfigKey is 64 bits, as
defined in the PacketCable Security specification.
Other encryption types may be defined in future
versions of this MIB module."
OBJECT pktcMtaDevRealmOrgName
SYNTAX LongUtf8String (SIZE (1..384))
DESCRIPTION
"The Organization Name field in X.509 certificates
can contain up to 64 UTF-8 encoded characters,
as defined in RFCs 3280 and 4630. Therefore, compliant
devices are only required to support Organization
Name values of up to 64 UTF-8 encoded characters.
Given that RFCs 3280 and 4630 define the UTF-8 encoding,
compliant devices must support a maximum size of 384
octets for pktcMtaDevRealmOrgName. The calculation of
384 octets comes from the RFC 3629 UTF-8 encoding
definition whereby the UTF-8 encoded characters
are encoded as sequences of 1 to 6 octets,
assuming that code points as high as 0x7ffffffff
might be used. Subsequent versions of Unicode and ISO
10646 have limited the upper bound to 0x10ffff.
Consequently, the current version of UTF-8, defined in
RFC 3629, does not require more than four octets to
encode a valid code point."
::= { pktcMtaCompliances 1 }
pktcMtaGroup OBJECT-GROUP
OBJECTS {
pktcMtaDevResetNow,
pktcMtaDevSerialNumber,
pktcMtaDevSwCurrentVers,
pktcMtaDevFQDN,
pktcMtaDevEndPntCount,
pktcMtaDevEnabled,
pktcMtaDevProvisioningCounter,
pktcMtaDevErrorOid,
pktcMtaDevErrorValue,
pktcMtaDevErrorReason,
pktcMtaDevTypeIdentifier,
pktcMtaDevProvisioningState,
pktcMtaDevHttpAccess,
pktcMtaDevCertificate,
pktcMtaDevCorrelationId,
pktcMtaDevManufacturerCertificate,
pktcMtaDevDhcpServerAddressType,
pktcMtaDevDnsServerAddressType,
pktcMtaDevTimeServerAddressType,
pktcMtaDevProvConfigEncryptAlg,
pktcMtaDevServerDhcp1,
pktcMtaDevServerDhcp2,
pktcMtaDevServerDns1,
pktcMtaDevServerDns2,
pktcMtaDevTimeServer,
pktcMtaDevConfigFile,
pktcMtaDevSnmpEntity,
pktcMtaDevRealmPkinitGracePeriod,
pktcMtaDevRealmTgsGracePeriod,
pktcMtaDevRealmAvailSlot,
pktcMtaDevRealmName,
pktcMtaDevRealmOrgName,
pktcMtaDevRealmUnsolicitedKeyMaxTimeout,
pktcMtaDevRealmUnsolicitedKeyNomTimeout,
pktcMtaDevRealmUnsolicitedKeyMaxRetries,
pktcMtaDevRealmStatus,
pktcMtaDevCmsAvailSlot,
pktcMtaDevCmsFqdn,
pktcMtaDevCmsKerbRealmName,
pktcMtaDevCmsUnsolicitedKeyMaxTimeout,
pktcMtaDevCmsUnsolicitedKeyNomTimeout,
pktcMtaDevCmsUnsolicitedKeyMaxRetries,
pktcMtaDevCmsSolicitedKeyTimeout,
pktcMtaDevCmsMaxClockSkew,
pktcMtaDevCmsIpsecCtrl,
pktcMtaDevCmsStatus,
pktcMtaDevResetKrbTickets,
pktcMtaDevProvUnsolicitedKeyMaxTimeout,
pktcMtaDevProvUnsolicitedKeyNomTimeout,
pktcMtaDevProvUnsolicitedKeyMaxRetries,
pktcMtaDevProvKerbRealmName,
pktcMtaDevProvSolicitedKeyTimeout,
pktcMtaDevProvConfigHash,
pktcMtaDevProvConfigKey,
pktcMtaDevProvState,
pktcMtaDevProvisioningTimer,
pktcMtaDevTelephonyRootCertificate
}
STATUS current
DESCRIPTION
" A collection of objects for managing PacketCable or
IPCablecom MTA implementations."
::= { pktcMtaGroups 1 }
pktcMtaNotificationGroup NOTIFICATION-GROUP
NOTIFICATIONS {
pktcMtaDevProvisioningStatus,
pktcMtaDevProvisioningEnrollment
}
STATUS current
DESCRIPTION
" A collection of notifications dealing with the change of
MTA provisioning status."
::= { pktcMtaGroups 2 }
pktcMtaBasicSmtaCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
" The compliance statement for S-MTA devices
that implement PacketCable or IPCablecom requirements.
This compliance statement applies to S-MTA implementations
that support PacketCable or IPCablecom requirements,
which are not IPv6-capable at the time of this
RFC publication."
MODULE -- Unconditionally Mandatory Groups for S-MTA devices
MANDATORY-GROUPS {
pktcMtaGroup,
pktcMtaNotificationGroup
}
OBJECT pktcMtaDevDhcpServerAddressType
SYNTAX InetAddressType { ipv4(1) }
DESCRIPTION
" Support for address types other than 'ipv4(1)'
is not presently specified and therefore is not
required. It may be defined in future versions of
this MIB module."
OBJECT pktcMtaDevDnsServerAddressType
SYNTAX InetAddressType { ipv4(1) }
DESCRIPTION
" Support for address types other than 'ipv4(1)'
is not presently specified and therefore is not
required. It may be defined in future versions of
this MIB module."
OBJECT pktcMtaDevTimeServerAddressType
SYNTAX InetAddressType { ipv4(1) }
DESCRIPTION
" Support for address types other than 'ipv4(1)'
is not presently specified and therefore is not
required. It may be defined in future versions of
this MIB module."
OBJECT pktcMtaDevServerDhcp1
SYNTAX InetAddress (SIZE(4))
DESCRIPTION
"An implementation is only required to support IPv4
addresses. Other address types support may be defined in
future versions of this MIB module."
OBJECT pktcMtaDevServerDhcp2
SYNTAX InetAddress (SIZE(4))
DESCRIPTION
"An implementation is only required to support IPv4
addresses. Other address types support may be defined in
future versions of this MIB module."
OBJECT pktcMtaDevServerDns1
SYNTAX InetAddress (SIZE(4))
DESCRIPTION
"An implementation is only required to support IPv4
addresses. Other address types support may be defined in
future versions of this MIB module."
OBJECT pktcMtaDevServerDns2
SYNTAX InetAddress (SIZE(4))
DESCRIPTION
"An implementation is only required to support IPv4
addresses. Other address types support may be defined in
future versions of this MIB module."
OBJECT pktcMtaDevTimeServer
SYNTAX InetAddress (SIZE(4))
DESCRIPTION
"An implementation is only required to support IPv4
addresses. Other address types support may be defined in
future versions of this MIB module."
OBJECT pktcMtaDevProvConfigEncryptAlg
SYNTAX PktcMtaDevProvEncryptAlg
DESCRIPTION
"An implementation is only required to support
values of none(0) and des64Cbcmode(1).
An IV of zero is used to encrypt in des64Cbcmode, and
the length of pktcMtaDevProvConfigKey is 64 bits, as
defined in the PacketCable Security specification.
Other encryption types may be defined in future
versions of this MIB module."
OBJECT pktcMtaDevRealmOrgName
SYNTAX LongUtf8String (SIZE (1..384))
DESCRIPTION
"The Organization Name field in X.509 certificates
can contain up to 64 UTF-8 encoded characters, as
defined in RFCs 3280 and 4630. Therefore, compliant
devices are only required to support Organization
Name values of up to 64 UTF-8 encoded characters.
Given that RFCs 3280 and 4630 define the UTF-8 encoding,
compliant devices must support a maximum size of 384
octets for pktcMtaDevRealmOrgName. The calculation of
384 octets comes from the RFC 3629 UTF-8 encoding
definition whereby the UTF-8 encoded characters
are encoded as sequences of 1 to 6 octets,
assuming that code points as high as 0x7ffffffff
might be used. Subsequent versions of Unicode and ISO
10646 have limited the upper bound to 0x10ffff.
Consequently, the current version of UTF-8, defined in
RFC 3629 does not require more than four octets to
encode a valid code point."
MODULE DOCS-CABLE-DEVICE-MIB
MANDATORY-GROUPS {
docsDevSoftwareGroupV2
}
MODULE DOCS-IETF-BPI2-MIB
MANDATORY-GROUPS {
docsBpi2CodeDownloadGroup
}
::= { pktcMtaCompliances 2 }
END
5. Acknowledgements
The current editors would like to thank the members of the IETF IPCDN
working group and the CableLabs PacketCable Provisioning and OSS
focus team for their comments and suggestions. In particular, we
wish to express our gratitude for the contributions made by the
following individuals (in no particular order): Angela Lyda,Sumanth
Channabasappa, Matt A. Osman, Klaus Hermanns, Paul Duffy, Rick
Vetter, Sasha Medvinsky, Roy Spitzer, Itay Sherman, Satish Kumar and
Eric Rosenfeld. Finally, special thanks to our area director Bert
Wijnen, Rich Woundy, Randy Presuhn, Mike Heard, and Dave Thaler.
6. Security Considerations
There are a number of management objects defined in this MIB module
with a MAX-ACCESS clause of read-write and/or read-create. Such
objects may be considered sensitive or vulnerable in some network
environments. The support for SET operations in a non-secure
environment without proper protection can have a negative effect on
network operations. Improper manipulation of the objects defined in
this MIB may result in random behavior of MTA devices and may result
in service disruption. These are the tables and objects and their
sensitivity/vulnerability:
- The following objects, if SET maliciously, would cause the MTA
device to reset and/or stop its service:
pktcMtaDevResetNow.
pktcMtaDevEnabled.
- All writable objects in the pktcMtaDevServer group and some in the
pktcMtaDevRealmTable share the potential, if SET maliciously, to
prevent the MTA from provisioning properly. Thus, they are
considered very sensitive for service delivery. The objects in
question are:
pktcMtaDevProvisioningTimer,
pktcMtaDevDhcpServerAddressType,
pktcMtaDevDnsServerAddressType,
pktcMtaDevTimeServerAddressType,
pktcMtaDevProvConfigEncryptAlg,
pktcMtaDevServerDns1,
pktcMtaDevServerDns2,
pktcMtaDevTimeServer,
pktcMtaDevConfigFile,
pktcMtaDevProvConfigHash,
pktcMtaDevProvConfigKey,
pktcMtaDevProvSolicitedKeyTimeout,
pktcMtaDevRealmName,
pktcMtaDevRealmOrgName,
pktcMtaDevRealmUnsolicitedKeyMaxTimeout,
pktcMtaDevRealmUnsolicitedKeyNomTimeout,
pktcMtaDevRealmUnsolicitedKeyMaxRetries, and
pktcMtaDevRealmStatus.
Certain of the above objects have additional specific
vulnerabilities:
o pktcMtaDevServerDns1 and pktcMtaDevServerDns2, if SET
maliciously, could prevent the MTA from being authenticated and
consequently from getting telephony services.
o pktcMtaDevRealmStatus, if SET maliciously, could cause the
whole row of the table to be deleted, which may prevent MTA
from getting telephony services.
- All writable objects in the pktcMtaDevCmsTable table share the
potential, if SET maliciously, to disrupt the telephony service by
altering which Call Management Server the MTA must send signaling
registration to; in particular:
pktcMtaDevCmsFqdn,
pktcMtaDevCmsKerbRealmName,
pktcMtaDevCmsMaxClockSkew,
pktcMtaDevCmsSolicitedKeyTimeout,
pktcMtaDevCmsUnsolicitedKeyMaxTimeout,
pktcMtaDevCmsUnsolicitedKeyNomTimeout,
pktcMtaDevCmsUnsolicitedKeyMaxRetries (this object, if set to a
zero value '0', may prevent the MTA from retrying its attempt
to establish a Security Association with the CMS), and
pktcMtaDevCmsStatus.
- Some writable objects in the pktcMtaDevRealmTable table will not
have an immediate effect on service, if SET maliciously. However,
they may impact the service performance and cause avalanche
attacks on provisioning and Kerberos KDC servers, especially after
massive device reboots occur. The objects in question are as
follows:
pktcMtaDevResetKrbTickets: This object, if set to 'true', will
cause the MTA to request a new Kerberos ticket at reboot.
pktcMtaDevRealmPkinitGracePeriod, pktcMtaDevRealmTgsGracePeriod:
These 2 objects, if set to short time periods, will cause the MTA
to renew its tickets more frequently.
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. Some of these objects may
contain information that may be sensitive from a business or customer
perspective. 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 and
vulnerability:
- Some readable objects in the pktcMtaDevBase, pktcMtaDevServer, and
pktcMtaDevSecurity groups share the potential, if read
maliciously, to facilitate Denial-of-Service (DoS) attacks against
provisioning or Kerberos servers. The object in question are as
follows:
pktcMtaDevServerDhcp1, pktcMtaDevServerDhcp2, and
pktcMtaDevSnmpEntity. The values of these objects may be used to
launch DoS attacks on the Telephony Service Provider DHCP or
Provisioning servers.
pktcMtaDevProvKerbRealmName, pktcMtaDevManufacturerCertificate,
pktcMtaDevCertificate and pktcMtaDevTelephonyRootCertificate. The
values of these objects may be used by attackers to launch DoS
attacks against Kerberos servers.
- One additional readable object may expose some security threats:
pktcMtaDevFQDN. This object may include sensitive information
about the domain name, and potentially, the domain topology.
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 Section 8 in [RFC3410]), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them.7. IANA Considerations
The MIB module defined in this document uses the following IANA- assigned OBJECT IDENTIFIER values, recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER value ---------- ----------------------- pktcIetfMtaMib { mib-2 140 }8. Normative References
[RFC868] Postel, J. and K. Harrenstien, "Time Protocol", STD 26, RFC 868, May 1983. [RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350, July 1992. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. [RFC2287] Krupczak, C. and J. Saperia, "Definitions of System-Level Managed Objects for Applications", RFC 2287, February 1998.
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder J., Case, J. Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J. Case, J. Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002. [RFC3495] Beser, B. and P. Duffy, "Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client Configuration", RFC 3495, March 2003. [RFC3594] Duffy, P., "PacketCable Security Ticket Control Sub-Option for the DHCP CableLabs Client Configuration (CCC) Option", RFC 3594, September 2003. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005.
[RFC4131] Green, S., Ozawa, K., Cardona, E., and A. Katsnelson, "Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modems and Cable Modem Termination Systems for Baseline Privacy Plus", RFC 4131, September 2005. [RFC4630] Housley, R. and S. Santesson, "Update to DirectoryString Processing in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4630, August 2006. [RFC4639] Woundy, R. and K. Marez, "Cable Device Management Information Base for Data-Over-Cable Service Interface Specification (DOCSIS) Compliant Cable Modems and Cable Modem Termination Systems", RFC 4639, December 2006. [PKT-SP-PROV] Packetcable MTA Device Provisioning Specification, Issued, PKT-SP-PROV-I11-050812, August 2005. http://www.packetcable.com/specifications/ http://www.cablelabs.com/specifications/archives/ [PKT-SP-SEC] PacketCable Security Specification, Issued, PKT-SP- SEC-I12-050812, August 2005. http://www.packetcable.com/specifications/ http://www.cablelabs.com/specifications/archives/ [ITU-T-J112] Transmission Systems for Interactive Cable Television Services, Annex B, J.112, ITU-T, March, 1998. [ITU-T-J168] IPCablecom Multimedia Terminal Adapter (MTA) MIB requirements, J.168, ITU-T, March, 2001.9. Informative References
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [RFC3617] Lear, E., "Uniform Resource Identifier (URI) Scheme and Applicability Statement for the Trivial File Transfer Protocol (TFTP)", RFC 3617, October 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [PKT-SP-MIB-MTA] Packetcable MTA MIB Specification, Issued, PKT-SP- MIB-MTA-I10-050812, August 2005. http://www.packetcable.com/specifications/ http://www.cablelabs.com/specifications/archives/ [ETSITS101909-8] ETSI TS 101 909-8: "Access and Terminals (AT); Digital Broadband Cable Access to the Public Telecommunications Network; IP Multimedia Time Critical Services; Part 8: Media Terminal Adaptor (MTA) Management Information Base (MIB)". [EN300001] EN 300 001 V1.5.1 (1998-10):"European Standard (Telecommunications series) Attachments to Public Switched Telephone Network (PSTN); General technical requirements for equipment connected to an analogue subscriber interface in the PSTN". [EN300659-1] EN 300 659-1: "Public Switched Telephone Network (PSTN); Subscriber line protocol over the local loop for display (and related) services; Part 1: On hook data transmission". [NCSSIGMIB] Beacham G., Kumar S., Channabasappa S., "Network Control Signaling (NCS) Signaling MIB for PacketCable and IPCablecom Multimedia Terminal Adapters (MTAs)", Work in Progress, June 2006.
Authors' Addresses
Eugene Nechamkin Broadcom Corporation, 200 - 13711 International Place Richmond, BC, V6V 2Z8 CANADA Phone: +1 604 233 8500 EMail: enechamkin@broadcom.com Jean-Francois Mule Cable Television Laboratories, Inc. 858 Coal Creek Circle Louisville, Colorado 80027-9750 U.S.A. Phone: +1 303 661 9100 EMail: jf.mule@cablelabs.com
Full Copyright Statement Copyright (C) The IETF Trust (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, 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.