IPCDN
Internet-Draft Eugene Nechamkin
Document: draft-ietf-ipcdn-pktc-mtamib-03.txt Broadcom Corp.
Jean-Francois Mule
CableLabs
Expires: June 2004 January 2004
Multimedia Terminal Adapter (MTA) Management Information Base
for PacketCable and IPCablecom compliant devices
Status of this Memo
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2004). 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 management of PacketCable and IPCablecom compliant Multimedia
Terminal Adapter devices.
Nechamkin/Mule Expires û June 2004 [Page 1]
IPCDN MTA MIB January 2004
Table of Contents
1. The Internet-Standard Management Framework....................2
2. Terminology...................................................3
2.1 DOCSIS....................................................3
2.2 Cable Modem...............................................3
2.3 Multimedia Terminal Adapter...............................3
2.4 Endpoint..................................................4
2.5 X.509 Certificate.........................................4
2.6 Voice Over IP.............................................4
2.7 Public Key Certificate....................................4
2.8 DHCP......................................................4
2.9 Call Management Server....................................4
2.10 CODEC, COder-DECoder.....................................4
2.11 Operations Systems Support...............................5
2.12 Key Distribution Center..................................5
2.13 Security Association.....................................5
3. Overview......................................................5
3.1 Structure of the MTA MIB..................................5
3.2 pktcMtaDevBase............................................6
3.3 pktcMtaDevServer..........................................6
3.4 pktcMtaDevSecurity........................................7
3.5 Relationship between MIB Objects in the MTA MIB...........7
4. Definitions...................................................9
5. Acknowledgments..............................................41
6. Normative References.........................................42
7. Informative References.......................................44
8. Security Considerations......................................45
9. Intellectual Property........................................47
10. Authors' Addresses..........................................48
11. Full Copyright Statement....................................48
1. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of
RFC 3410 [RFC3410].
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. MIB objects are generally
accessed through the Simple Network Management Protocol (SNMP).
Objects in the MIB are defined using the mechanisms defined in the
Structure of Management Information (SMI). This memo specifies a
MIB module that is compliant to the SMIv2, which is described in
STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58,
RFC 2580 [RFC2580].
Nechamkin/Mule Expires - June 2004 [Page 2]
IPCDN MTA MIB January 2004
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL", when used in the guidelines in this memo, are to be
interpreted as described in RFC 2119 [RFC2119].
The terms "MIB module" and "information module" are used
interchangeably in this memo. As used here, both terms refer to any
of the three types of information modules defined in Section 3 of
RFC 2578 [RFC2578].
Some of the terms used in this memo are defined below. Some
additional terms are also defined in the PacketCable MTA Device
Provisioning Specification [PKT-SP-PROV-I08-040113] and the
PacketCable Security Specification [PKT-SP-SEC-I10-040113].
2.1 DOCSIS
The CableLabs(R) Certified(TM) Cable Modem project, also known as
DOCSIS(R) (Data Over Cable Service Interface Specification), defines
interface requirements for cable modems involved in high-speed data
distribution over cable television system networks.
DOCSIS also refers to the ITU-T Recommendation J.112 Annex B for
DOCSIS 1.1 cable modem systems [ITU-T-J112], and, to ITU-T
Recommendation J.122 for DOCSIS 2.0 systems [ITU-T-J122].
2.2 Cable Modem
A Cable Modem (CM) acts as a data transport agent used to transfer
call management and voice data packets over a DOCSIS compliant cable
system.
2.3 Multimedia Terminal Adapter
A Multimedia Terminal Adapter (MTA) is a PacketCable or IPCablecom
compliant device providing telephony services over a cable or hybrid
system used to deliver video signals to a community. It contains an
interface to endpoints, a network interface, CODECs, and all
signaling and encapsulation functions required for Voice over IP
transport, call signaling, and Quality of Service signaling.
An MTA can be an embedded or a standalone device. An Embedded MTA
(E-MTA) is an MTA device containing an embedded DOCSIS Cable Modem.
A Standalone MTA (S-MTA) is an MTA device separated from the DOCSIS
cable modem by non-DOCSIS MAC interface (e.g. Ethernet, USB).
Nechamkin/Mule Expires - June 2004 [Page 3]
IPCDN MTA MIB January 2004
2.4 Endpoint
An endpoint or MTA endpoint is a standard RJ-11 telephony physical
port located on the MTA and used for attaching the telephone device
to the MTA.
2.5 X.509 Certificate
A X.509 certificate is an Internet X.509 Public Key Infrastructure
certificate developed as part of the ITU-T X.500 Directory
recommendations. It is defined in RFC 2459 [RFC2459].
2.6 Voice Over IP
Voice Over IP (VoIP) is a technology providing the means to transfer
the digitized packets with the voice information over IP networks.
2.7 Public Key Certificate
A Public Key Certificate (also known as a Digital Certificate) is a
binding between an entity's public key and one or more attributes
relating to its identity.
2.8 DHCP
The Dynamic Host Configuration Protocol (DHCP) is defined by
RFC 2131 [RFC2131]. In addition, commonly used DHCP options are
defined in RFC 2132 [RFC2132]. Additional DHCP options used by
PacketCable and IPCablecom MTAs can be found in the CableLabs Client
Configuration DHCP specification, RFC 3495 [RFC3495].
2.9 Call Management Server
A Call Management Server (CMS) is an element of the PacketCable
network infrastructure which controls audio connections between
MTAs.
2.10 CODEC, COder-DECoder
A Coder-DECoder is a hardware or software component used in
audio/video systems to convert an analog signal to digital, and then
(possibly) to compress it so that lower bandwidth telecommunications
channels can be used. The signal is decompressed and converted
(decoded) back to analog output by a compatible CODEC at the
receiving end.
Nechamkin/Mule Expires - June 2004 [Page 4]
IPCDN MTA MIB January 2004
2.11 Operations Systems Support
An Operations Systems Support system (OSS) is a system of back
office software components used for fault, configuration,
accounting, performance, and security management working in
interaction with each other and providing the operations support in
deployed PacketCable systems.
2.12 Key Distribution Center
A Key Distribution Center (KDC) is an element of the OSS systems
functioning as a Kerberos Security Server providing mutual
authentication of the various components of the PacketCable system
(e.g. mutual authentication between an MTA and a CMS, or between an
MTA and the Provisioning Server).
2.13 Security Association
A Security Association (SA) is a one-way relationship between sender
and receiver offering security services on the communication flow.
3. Overview
This MIB module provides a set of objects required for the
management of PacketCable, ETSI and ITU-T IPCablecom compliant MTA
devices. The MTA MIB module is intended to supersede various MTA
MIB modules from which it is partly derived:
- the PacketCable 1.0 MTA MIB Specification
[PKT-SP-MIB-MTA-I08-040113],
- the ITU-T IPCablecom MTA MIB requirements [ITU-T-J168],
- the ETSI MTA MIB [ETSI TS 101 909-8]. The ETSI MTA MIB
requirements also refer to various signal characteristics
defined in [EN 300 001] and [EN 300 659-1].
Several normative and informative references are used to help define
MTA MIB objects. As a convention, wherever PacketCable and
IPCablecom requirements are equivalent, the PacketCable reference is
used in the object REFERENCE clause. IPCablecom compliant MTA
devices MUST use the equivalent IPCablecom references.
3.1 Structure of the MTA MIB
The MTA MIB module is identified by pktcMtaMib and is structured in
three object groups:
- pktcMtaDevBase defines the management information pertinent to the
MTA device itself,
Nechamkin/Mule Expires - June 2004 [Page 5]
IPCDN MTA MIB January 2004
- pktcMtaDevServer defines the management information pertinent to
the provisioning back office servers,
- pktcMtaDevSecurity defines the management information pertinent to
the PacketCable and IPCablecom security mechanisms.
The first two object groups, pktcMtaDevBase and pktcMtaDevServer,
contain only scalar information objects describing the corresponding
characteristics of the MTA device and back office servers.
The third group, pktcMtaDevSecurity, contains two tables controlling
the logical associations between KDC realms and Application Servers
(CMS and Provisioning Server). The rows in the various tables of
the MTA MIB module can be created automatically (e.g. by the device
according to the current state information) or they can be created
by the management station depending on the operational situation.
The tables defined in the MTA MIB module may have a mixture of both
types of rows.
3.2 pktcMtaDevBase
This object group contains the management information related to the
MTA device itself. It also contains some objects used to control
the MTA state. Some highlights are as follows:
- pktcMtaDevSerialNumber, this object contains the MTA Serial
Number,
- pktcMtaDevEndPntCount, this object contains the number of
endpoints present in the managed MTA,
- pktcMtaDevProvisioningState, this object contains the information
describing the completion state of the MTA initialization process,
- pktcMtaDevEnabled, this object controls the administrative state
of the MTA endpoints and allows operators to enable or disable
telephony services on the device,
- pktcMtaDevResetNow, this object is used to instruct the MTA to
reset.
3.3 pktcMtaDevServer
This object group contains the management information describing the
back office servers and the parameters related to the communication
timers. It also includes some objects controlling the initial MTA
interaction with the Provisioning Server.
Nechamkin/Mule Expires - June 2004 [Page 6]
IPCDN MTA MIB January 2004
Some highlights are as follows:
- pktcMtaDevServerDhcp1, this object contains the IP address of the
primary DHCP server designated for the MTA provisioning,
- pktcMtaDevServerDhcp2, this object contains the IP address of the
secondary DHCP server designated for the MTA provisioning,
- pktcMtaDevServerDns1, this object contains the IP address of the
primary DNS used by the managed MTA to resolve the Fully Qualified
Domain Name (FQDN) and IP addresses,
- pktcMtaDevServerDns2, this object contains the IP address of the
secondary DNS used by the managed MTA to resolve the FQDN and IP
addresses,
- pktcMtaDevConfigFile, this object contains the name of the
provisioning configuration file the managed MTA must download from
the Provisioning Server,
- pktcMtaDevProvConfigHash, this object contains the hash value of
the MTA configuration file calculated over its content. When the
managed MTA downloads the file, it authenticates the configuration
file using the hash value provided in this object.
3.4 pktcMtaDevSecurity
This object group contains the management information describing the
security related characteristics of the managed MTA. It contains
two tables describing logical dependencies and parameters necessary
to establish Security Associations between the MTA and other
Application Servers (back office components and CMSes).
The CMS table (pktcMtaDevCmsTable) and the realm table
(pktcMtaDevRealmTable) are used for managing the MTA signaling
security. The realm table defines the CMS domains. The CMS table
defines the CMS within the domains. Each MTA endpoint is associated
with one CMS at any given time.
The two tables in this object group are:
- pktcMtaDevRealmTable, this table is used in conjunction with any
Application Server that communicates securely with the managed MTA
(CMS or Provisioning Server),
- pktcMtaDevCmsTable, this table contains the parameters describing
the SA establishment between the MTA and CMSes.
3.5 Relationship between MIB Objects in the MTA MIB
This section clarifies the relationship between various MTA MIB
objects with respect to the role they play in the process of
establishing Security Associations.
Nechamkin/Mule Expires - June 2004 [Page 7]
IPCDN MTA MIB January 2004
The process of Security Association establishment between an MTA and
Application Servers is described in the PacketCable Security
Specification [PKT-SP-SEC-I10-040113]. In particular, an MTA
communicates with 2 types of back office Application Servers: Call
Management Servers and Provisioning Servers.
The SA establishment process consists of two steps:
a. Authentication Server exchange (AS-exchange):
This step provides mutual authentication between the parties, i.e.
between an MTA and an Authentication Server.
The process of AS-exchange is defined by a number of parameters
grouped per each realm. These parameters are gathered in the Realm
Table (pktcMtaDevRealmTable). The Realm Table is indexed by the
Index Counter and contains conceptual column with the Kerberos realm
name.
b. Application server exchange (AP-exchange):
This step allows for the establishment of Security Associations
between authenticated parties.
The CMS table (pktcMtaDevCmsTable) contains the parameters for the
AP-exchange process between an MTA and a CMS. The CMS table is
indexed by the Index Counter and contains the CMS FQDN (the
conceptual column pktcMtaDevCmsFqdn). Each row contains the
Kerberos realm name associated with each CMS FQDN. This allows for
each CMS to exist in a different Kerberos realm.
The MTA MIB module also contains a group of scalar MIB objects in
the server group (pktcMtaDevServer). These objects define various
parameters for the AP-exchange process between an MTA and the
Provisioning Server. These objects are:
- pktcMtaDevProvUnsolicitedKeyMaxTimeout,
- pktcMtaDevProvUnsolicitedKeyNomTimeout,
- pktcMtaDevProvUnsolicitedKeyMaxRetries,
- pktcMtaDevProvSolicitedKeyTimeout.
3.6 Secure Software Download
While E-MTAs have their software upgraded by the Cable Modem
according to the DOCSIS requirements, S-MTAs must implement the a
specific mechanism for Secure Software Download defined in the
PacketCable/IPCablecom Security specification [PKT-SP-SEC-I10-
040113].
This mechanism provides means to verify the code upgrade using Code
Verification Certificates and is modeled after the DOCSIS mechanism
implemented in Cable Modems. This is the reason why the MTA MIB and
the S-MTA compliance modules rely on two MIB object groups
(docsBpi2CodeDownloadGroup and docsDevSoftwareGroupV2) defined in
the IETF BPI Plus MIB module (DOCS-IETF-BPI2-MIB [RFCyyyy]).
Nechamkin/Mule Expires - June 2004 [Page 8]
IPCDN MTA MIB January 2004
4. Definitions
PKTC-IETF-MTA-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY,
OBJECT-TYPE,
Unsigned32,
NOTIFICATION-TYPE,
mib-2
FROM SNMPv2-SMI
RowStatus,
TruthValue
FROM SNMPv2-TC
OBJECT-GROUP,
MODULE-COMPLIANCE,
NOTIFICATION-GROUP
FROM SNMPv2-CONF
InetAddressType,
InetAddress
FROM INET-ADDRESS-MIB
sysDescr
FROM SNMPv2-MIB
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB
DocsX509ASN1DEREncodedCertificate
FROM DOCS-IETF-BPI2-MIB
-- DOCS-IETF-BPI2-MIB per [RFCyyyy]
-- ************************************************************
-- * NOTES TO RFC Editor (to be removed prior to publication) *
-- * *
-- * The I-D <draft-ietf-ipcdn-bpiplus-mib-12.txt> *
-- * is expected to become RFC before this draft. *
-- * Please replace RFCyyy with the RFC number of bpiplus and *
-- * remove this note *
-- * *
-- ************************************************************
ifPhysAddress
FROM IF-MIB;
pktcMtaMib MODULE-IDENTITY
LAST-UPDATED "200401281700Z" -- January 28, 2004
ORGANIZATION "IETF IP over Cable Data Network Working Group"
CONTACT-INFO
"Eugene Nechamkin
Broadcom Corporation,
200-13711 International Place,
Richmond, BC, V6V 2Z8
Nechamkin/Mule Expires - June 2004 [Page 9]
IPCDN MTA MIB January 2004
CANADA
Phone: +1 604 233 8500
Fax: +1 604 233 8501
Email: enechamkin@broadcom.com
Jean-Francois Mule
Cable Television Laboratories, Inc.
400 Centennial Parkway,
Louisville, CO 80027-1266
U.S.A.
Phone: +1 303 661 9100
Fax: +1 303 661 9199
Email: jf.mule@cablelabs.com
IETF IP over Cable Data Network (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-Chair: Jean-Francois Mule, jf.mule@cablelabs.com
Co-Chair: Richard Woundy, Richard_Woundy@cable.comcast.com"
DESCRIPTION
"This MIB module defines the basic management object
for the Multimedia Terminal Adapter devices compliant
with PacketCable and IPCablecom requirements.
Copyright (C) The Internet Society (2004). This version of
this MIB module is part of RFC yyyy; see the RFC itself for
full legal notices."
-- RFC Ed: replace yyyy with actual RFC number and remove this note
REVISION "200401281700Z"
DESCRIPTION
"Initial version, published as RFC yyyy."
-- RFC Ed: replace yyyy with actual RFC number and remove this note
::= { mib-2 XXX }
-- RFC Ed: replace XXX with IANA-assigned number and remove this
-- note
--=================================================================
-- The MTA MIB module only supports a single Provisioning Server.
--=================================================================
pktcMtaMibObjects OBJECT IDENTIFIER ::= { pktcMtaMib 1 }
pktcMtaDevBase OBJECT IDENTIFIER ::= { pktcMtaMibObjects 1 }
pktcMtaDevServer OBJECT IDENTIFIER ::= { pktcMtaMibObjects 2 }
Nechamkin/Mule Expires - June 2004 [Page 10]
IPCDN MTA MIB January 2004
pktcMtaDevSecurity OBJECT IDENTIFIER ::= { pktcMtaMibObjects 3 }
--
-- The following pktcMtaDevBase group describes the base MTA objects
--
pktcMtaDevResetNow OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
" This object controls the MTA software reset.
Reading this object always returns 'false'. Setting this
object to 'true' causes the device to reset immediately
and the following actions occur:
1. All connections (if present) are flushed locally.
2. All current actions such as ringing immediately
terminate.
3. Requests for signaling notifications such as
notification based on digit map recognition are
flushed.
4. All endpoints are disabled.
5. The provisioning flow is started at step MTA-1."
REFERENCE
" PacketCable MTA Device Provisioning Specification."
::= { pktcMtaDevBase 1 }
pktcMtaDevSerialNumber OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object identifies the manufacturer's serial number
for this MTA."
::= { pktcMtaDevBase 2 }
pktcMtaDevSwCurrentVers OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object identifies the software version currently
operating in the MTA.
An MTA MUST return a string descriptive of the current
software load. This object should use the syntax
defined by the individual vendor to identify the software
version. The data presented in this object MUST be
Nechamkin/Mule Expires - June 2004 [Page 11]
IPCDN MTA MIB January 2004
consistent with the software version information contained
in the 'sysDescr' MIB object of the MTA."
::= { pktcMtaDevBase 3 }
pktcMtaDevFQDN OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object contains the Fully Qualified Domain Name for
this MTA."
::= { pktcMtaDevBase 4 }
pktcMtaDevEndPntCount OBJECT-TYPE
SYNTAX Unsigned32 (1..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object contains the number of physical endpoints for
this MTA."
::= { pktcMtaDevBase 5 }
pktcMtaDevEnabled OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
" This object contains the MTA Admin Status of this device.
If this object is set to 'true', the MTA is
administratively enabled and the MTA MUST be able to
interact with the PacketCable entities such as CMS,
Provisioning Server, KDC, and other MTAs and MGs on all
PacketCable interfaces.
If this object is set to 'false', the MTA is
administratively disabled and the MTA MUST perform the
following actions for all endpoints:
- shutdown all media sessions if present,
- shutdown NCS signaling by following the Restart in
Progress procedures in the PacketCable NCS
specification.
Additionally, the MTA MUST maintain the SNMP Interface
For management and also SNMP Key management interface.
Also the MTA MUST NOT continue Kerberized key management
with CMSes until this object is set to 'true'.
Note: MTAs MUST renew the CMS kerberos tickets according
to the PacketCable Security Specification."
REFERENCE
Nechamkin/Mule Expires - June 2004 [Page 12]
IPCDN MTA MIB January 2004
" PacketCable MTA Device Provisioning Specification;
PacketCable Security Specification;
PacketCable Network-Based Call Signaling Protocol
Specification."
::= { pktcMtaDevBase 6 }
pktcMtaDevTypeIdentifier OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object provides the MTA device type identifier. The
value of this object must be a copy of the DHCP option 60
value exchanged between the MTA and the DHCP server."
REFERENCE
" RFC 2132, DHCP Options and BOOTP Vendor Extensions;
PacketCable MTA Device Provisioning Specification."
::= { pktcMtaDevBase 7 }
pktcMtaDevProvisioningState OBJECT-TYPE
SYNTAX INTEGER {
pass (1),
inProgress (2),
failConfigFileError (3),
passWithWarning (4),
passWithIncompleteParsing (5),
failureInternalError (6),
failOtherReason (7)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object indicates the completion state of the MTA
device provisioning process. The object value is sent as
part of the final SNMP INFORM (step 25 of the MTA
provisioning process). Refer to the MTA Device
Provisioning Specification for the definition of
the provisioning states."
REFERENCE
" PacketCable MTA Device Provisioning Specification."
::= { pktcMtaDevBase 8 }
pktcMtaDevHttpAccess OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object indicates whether the HTTP protocol is
supported for the MTA configuration file transfer."
Nechamkin/Mule Expires - June 2004 [Page 13]
IPCDN MTA MIB January 2004
::= { pktcMtaDevBase 9 }
pktcMtaDevProvisioningTimer OBJECT-TYPE
SYNTAX Unsigned32 (0..30)
UNITS "minutes"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
" This object enables setting the duration of the
provisioning timeout timer. The timer covers the
provisioning sequence from step MTA-1 to step MTA-23.
The value is in minutes and setting the timer to '0'
disables this timer."
REFERENCE
" PacketCable MTA Device Provisioning Specification."
DEFVAL {10}
::= {pktcMtaDevBase 10}
pktcMtaDevErrorOidsTable OBJECT-TYPE
SYNTAX SEQUENCE OF PktcMtaDevErrorOidsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
" This table contains the list of configuration errors or
warnings the MTA encountered when parsing the
configuration file it received from the Provisioning
Server.
For each error, an entry is created in this table
containing the configuration parameters the MTA rejected
and the associated reason (e.g. wrong or unknown OID,
inappropriate object values, etc.). If the MTA
did not report a provisioning state of 'pass(1)' in
the pktcMtaDevProvisioningState object, this table MUST be
populated for each error or warning instance. Even if
different parameters share the same error type (e.g., all
realm name configuration parameters are invalid), all
observed errors or warnings must be reported as
different instances. Errors are placed into the table in
no particular order. The table MUST be cleared each time
the MTA reboots."
REFERENCE
" PacketCable MTA Device Provisioning Specification."
::= {pktcMtaDevBase 11 }
pktcMtaDevErrorOidsEntry OBJECT-TYPE
SYNTAX PktcMtaDevErrorOidsEntry
MAX-ACCESS not-accessible
STATUS current
Nechamkin/Mule Expires - June 2004 [Page 14]
IPCDN MTA MIB January 2004
DESCRIPTION
" This entry contains the necessary information the MTA MUST
attempt to provide in case of configuration file errors or
warnings."
INDEX { pktcMtaDevErrorOidIndex }
::= {pktcMtaDevErrorOidsTable 1}
PktcMtaDevErrorOidsEntry ::= SEQUENCE {
pktcMtaDevErrorOidIndex Unsigned32,
pktcMtaDevErrorOid SnmpAdminString,
pktcMtaDevErrorValue SnmpAdminString,
pktcMtaDevErrorReason SnmpAdminString
}
pktcMtaDevErrorOidIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..1024)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
" This object is the index of the MTA configuration error
table. It is an integer value which starts at value '1'
and is incremented for each encountered configuration
file error or warning."
::= {pktcMtaDevErrorOidsEntry 1}
pktcMtaDevErrorOid OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object contains a human readable representation
(character string) of the OID corresponding to the
configuration file parameter that caused the particular
error.
For example, if the value of the pktcMtaDevEnabled object
in the configuration file caused an error, then this
object instance will contain the human readable string of
'.1.3.6.1.2.1.XXX.1.1.6.0'.
************************************************************
* NOTES TO RFC Editor (to be removed prior to publication) *
* *
* Please replace XXX with the IANA-assigned number under *
* mib-2. *
* *
************************************************************
If the MTA generated an error because it was not able
to recognize a particular OID, then this object
instance would contain an empty value (zero-length
Nechamkin/Mule Expires - June 2004 [Page 15]
IPCDN MTA MIB January 2004
string).
For example, if the value of an OID in the configuration
file was interpreted by the MTA as being .1.2.3.4.5, and
the MTA was not able to recognize this OID as a valid one,
this object instance will contain a zero-length string."
::= {pktcMtaDevErrorOidsEntry 2}
pktcMtaDevErrorValue OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object contains the value of the OID corresponding to
the configuration file parameter that caused the error.
If the MTA cannot recognize the OID of the
configuration parameter causing the error, then this
object instance contains the OID itself as interpreted
by the MTA in human readable representation.
If the MTA can recognize the OID but generate an error due
to a wrong value of the parameter, then the object
instance contains the erroneous value of the parameter as
read from the configuration file.
In both cases, the value of this object must be
represented in human readable form as a character string.
For example, if the value of the pktcMtaDevEnabled object
in the configuration file was 3 (invalid value), then the
pktcMtaDevErrorValue object instance will contain the
human readable (string) representation of value '3'.
Similarly, if the OID in the configuration file has been
interpreted by the MTA as being .1.2.3.4.5, and the MTA
cannot recognize this OID as a valid one, then this
pktcMtaDevErrorValue object instance will contain human
readable (string) representation of value '.1.2.3.4.5'"
::= {pktcMtaDevErrorOidsEntry 3}
pktcMtaDevErrorReason OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object indicates the reason for the error or warning,
as per the MTA's interpretation, in human readable form.
Example of possible reason values are:
'VALUE NOT IN RANGE', 'VALUE DOES NOT MATCH TYPE',
'UNSUPPORTED VALUE', 'LAST 4 BITS MUST BE SET TO ZERO',
'OUT OF MEMORY - CANNOT STORE', etc.
This object may also contain vendor specific errors for
private vendor OIDs and any proprietary error codes or
messages which can help diagnose configuration errors."
Nechamkin/Mule Expires - June 2004 [Page 16]
IPCDN MTA MIB January 2004
::= {pktcMtaDevErrorOidsEntry 4}
--
-- The following group describes server access and parameters used
-- for the initial MTA provisioning and bootstrapping phases.
--
pktcMtaDevServerAddressType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS read-write
STATUS current
DESCRIPTION
" This object contains the Internet address type for the
PacketCable servers specified in MTA MIB."
DEFVAL { ipv4 }
::= { pktcMtaDevServer 1}
pktcMtaDevServerDhcp1 OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object contains the Internet Address of the primary
DHCP server the MTA uses during provisioning.
The type of this address is determined by the value of
the pktcMtaDevServerAddressType object.
When the latter has the value 'ipv4(1)', this object
contains the dotted IP address of the primary DHCP
server. It is provided by the CM to the MTA via the DHCP
option code 122 sub-option 1 as defined in RFC 3495.
The behavior of this object when the value of
pktcMtaDevServerAddressType is other than 'ipv4(1)'
is not presently specified, but may be specified
in future versions of this MIB module.
If this object is of value '0.0.0.0', the MTA MUST stop
all provisioning attempts as well as all other activities.
If this object is of value '255.255.255.255', it means
there was no preference given for the primary DHCP
server, and, the MTA must follow the logic of RFC2131 and
the value of DHCP option 122 sub-option 2 must be
ignored."
REFERENCE
" PacketCable MTA Device Provisioning Specification;
RFC 2131, Dynamic Host Configuration Protocol;
RFC 3495, DHCP Option for CableLabs Client Configuration."
::= { pktcMtaDevServer 2 }
Nechamkin/Mule Expires - June 2004 [Page 17]
IPCDN MTA MIB January 2004
pktcMtaDevServerDhcp2 OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object contains the Internet Address of the secondary
DHCP server the MTA uses during provisioning.
The type of this address is determined by the value of
the pktcMtaDevServerAddressType object.
When the latter has the value 'ipv4(1)', this object
contains the dotted IP address of the secondary DHCP
server. It is provided by the CM to the MTA via the DHCP
option code 122 sub-option 2 as defined in RFC 3495.
The behavior of this object when the value of
pktcMtaDevServerAddressType is other than 'ipv4(1)'
is not presently specified, but may be specified
in future versions of this MIB module.
If there was no secondary DHCP server provided in DHCP
Option 122 sub-option 2, this object must return the value
'0.0.0.0'."
REFERENCE
" PacketCable MTA Device Provisioning Specification;
RFC 3495, DHCP Option for CableLabs Client Configuration."
::= { pktcMtaDevServer 3 }
pktcMtaDevServerDns1 OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-write
STATUS current
DESCRIPTION
" This object contains the IP Address of the primary
DNS server to be used by the MTA. The type of this address
is determined by the value of the
pktcMtaDevServerAddressType object.
When the latter has the value 'ipv4(1)', this object
contains the dotted IP address of the primary DNS server.
As defined in RFC 2132, PacketCable compliant MTAs receive
the IP addresses of the DNS Servers in the DHCP option 6.
The behavior of this object when the value of
pktcMtaDevServerAddressType is other than 'ipv4(1)'
is not presently specified, but may be specified
in future versions of this MIB module."
REFERENCE
" PacketCable MTA Device Provisioning Specification;
RFC 2132, DHCP Options and BOOTP Vendor Extensions."
::= { pktcMtaDevServer 4 }
Nechamkin/Mule Expires - June 2004 [Page 18]
IPCDN MTA MIB January 2004
pktcMtaDevServerDns2 OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-write
STATUS current
DESCRIPTION
" This object contains the IP Address of the secondary
DNS server to be used by the MTA. The type of this address
is determined by the value of the
pktcMtaDevServerAddressType object.
When the latter has the value 'ipv4(1)', this object
contains the dotted IP address of the secondary DNS
server. As defined in RFC 2132, PacketCable compliant MTAs
receive the IP addresses of the DNS Servers in the DHCP
option 6.
The behavior of this object when the value of
pktcMtaDevServerAddressType is other than 'ipv4(1)'
is not presently specified, but may be specified
in future versions of this MIB module."
REFERENCE
" PacketCable MTA Device Provisioning Specification;
RFC 2132, DHCP Options and BOOTP Vendor Extensions."
::= { pktcMtaDevServer 5 }
pktcMtaDevTimeServer OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-write
STATUS current
DESCRIPTION
" This object contains the Internet Address of the Time
Server used by an S-MTA for Time Synchronization. The type
of this address is determined by the value of the
pktcMtaDevServerAddressType object.
When the latter has the value 'ipv4(1)', this object
contains the IP address of the Time Server used for Time
Synchronization.
In the case of an S-MTA, this object must be
populated with a value other than '0.0.0.0' as obtained
from DHCP Option 4. The protocol by which the time of day
MUST be retrieved is defined in RFC 868.
In the case of an E-MTA, this object must
contain a value of '0.0.0.0' if the address type is
'ipv4(1)' since an E-MTA does not use the Time Protocol
for time synchronization (an E-MTA uses the time retrieved
by the DOCSIS cable modem).
The behavior of this object when the value of
pktcMtaDevServerAddressType is other than 'ipv4(1)' is not
presently specified, but may be specified in future
versions of this MIB module."
REFERENCE
Nechamkin/Mule Expires - June 2004 [Page 19]
IPCDN MTA MIB January 2004
" RFC 868, Time Protocol;
RFC 2131, Dynamic Host Configuration Protocol;
RFC 2132, DHCP Options and BOOTP Vendor Extensions."
::= { pktcMtaDevServer 6}
pktcMtaDevConfigFile OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-write
STATUS current
DESCRIPTION
" This object contains the configuration file name set by
Provisioning Server. The MTA MUST support the TFTP access
method for configuration file download, and MAY support
the HTTP access method.
In the case of the TFTP access method, the filename MUST
be encoded using the following naming format:
tftp://<host>/mta-configfilename
where the <host> is the IPv4 address or the FQDN of the
TFTP access server.
In the case of HTTP access method, the filename MUST be
URL-encoded using the following naming format:
http://<host>/ mta-configfilename
where the <host> is the IPv4 address or the FQDN of the
HTTP access server.
This object MUST return a zero-length string if the server
address is unknown.
The following three objects (pktcMtaDevConfigFile,
pktcMtaDevConfigKey and pktcMtaDevConfigHash) MUST be
SET in one SNMP PDU."
::= { pktcMtaDevServer 7 }
pktcMtaDevSnmpEntity OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object contains the FQDN of the SNMP entity of the
Provisioning Server. It is the server the MTA communicates
with in order to receive the access method, location and
the name of the configuration file. The SNMP entity is
also the destination entity for all the provisioning
notifications. It may be used for post-provisioning SNMP
operations. During the provisioning phase, this SNMP
entity FQDN is supplied to the MTA via the DHCP option 122
sub-option 3 as defined in RFC 3495. If all the valid DHCP
OFFER messages contain a DHCP option 122 sub-option 3 of
value '0.0.0.0', the MTA must stop provisioning and shut
down until the modem is reset."
REFERENCE
Nechamkin/Mule Expires - June 2004 [Page 20]
IPCDN MTA MIB January 2004
" RFC 3495, DHCP Option for CableLabs Client Configuration."
::= { pktcMtaDevServer 8 }
pktcMtaDevProvConfigHash OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(20))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
" This object contains the hash value of the content of the
configuration file, calculated and sent to the MTA prior
to sending the configuration file. The authentication
algorithm used for calculating hash is SHA-1, and the
length of hash is 160 bits. The hash calculation MUST
follow the requirements of the PacketCable Security
Specification.
The following three objects (pktcMtaDevConfigFile,
pktcMtaDevConfigKey and pktcMtaDevConfigHash) MUST be
SET in one SNMP PDU."
REFERENCE
" PacketCable MTA Device Provisioning Specification;
PacketCable Security Specification."
::= { pktcMtaDevServer 9 }
pktcMtaDevProvConfigKey OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0|8))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
" This object contains the key used to encrypt and decrypt
the configuration file. It is sent to the MTA prior to
sending the configuration file. If the privacy
algorithm is null, the length is 0. If the privacy
algorithm is DES, the length is 64 bits.
The following three objects (pktcMtaDevConfigFile,
pktcMtaDevConfigKey and pktcMtaDevConfigHash) MUST be
SET in one SNMP PDU."
::= { pktcMtaDevServer 10 }
pktcMtaDevProvSolicitedKeyTimeout OBJECT-TYPE
SYNTAX Unsigned32 (1..180)
UNITS "seconds"
MAX-ACCESS read-write
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
Nechamkin/Mule Expires - June 2004 [Page 21]
IPCDN MTA MIB January 2004
response from the Provisioning Server.
After the timeout has been exceeded, the client discards
this (nonce, Server Kerberos Principal Identifier) pair,
after which it will no longer accept a matching AP Reply.
This timer only applies when the Provisioning Server
initiated key management for SNMPv3 (with a
Wake Up message)."
DEFVAL { 3 }
::= { pktcMtaDevServer 11 }
--=================================================================
--
-- Unsolicited key updates are retransmitted based on 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 (pktcMtaDevProvUnsolicitedKeyNomTimeout). The
-- retransmissions occur with an exponentially increasing interval
-- that caps at the maximum timeout value
-- (pktcMtaDevProvUnsolicitedKeyMaxTimeout).
-- Retransmissions stop when the maximum retry counter is reached
-- (pktcMtaDevProvUnsolicitedKeyMaxRetries).
-- For example, with values of 3 seconds for the nominal
-- timer, 100 seconds for the maximum timeout, 8 retries max and
-- an exponential value of 2, this results in retransmission
-- intervals of 3 s, 6 s, 12 s, 24 s, 48 s, 96 s, 100 s, 100 s, and
-- then retransmissions stop because the maximum number of
-- retries (8) has been reached.
--
--=================================================================
--
-- Timeouts for unsolicited key management updates are only
-- pertinent before the first SNMP message is sent between the MTA
-- and the Provisioning Server and before the configuration file is
-- loaded. No SNMP communications should exist under PacketCable
-- without existing Security Associations.
-- The following objects are provided for diagnostic purposes.
--
--=================================================================
pktcMtaDevProvUnsolicitedKeyMaxTimeout OBJECT-TYPE
SYNTAX Unsigned32 (15..600)
UNITS "seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object defines the timeout value that applies to
Nechamkin/Mule Expires - June 2004 [Page 22]
IPCDN MTA MIB January 2004
an MTA-initiated AP-REQ/REP key management exchange with
the Provisioning Server. It is the maximum timeout value
and it may not be exceeded in the exponential back-off
algorithm. If the DHCP option code 122 sub-option 5 is
provided to the MTA, it overwrites this value."
REFERENCE
" PacketCable Security Specification."
DEFVAL {600}
::= { pktcMtaDevServer 12 }
pktcMtaDevProvUnsolicitedKeyNomTimeout OBJECT-TYPE
SYNTAX Unsigned32 (1..600)
UNITS "seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object defines the starting value of the timeout for
the AP-REQ/REP back-off and retry mechanism with
exponential timeout. If the DHCP option code 122
sub-option 5 is provided to the MTA, it overwrites this
value."
REFERENCE
" PacketCable Security Specification."
DEFVAL {3}
::= { pktcMtaDevServer 13}
pktcMtaDevProvUnsolicitedKeyMaxRetries OBJECT-TYPE
SYNTAX Unsigned32 (1..32)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object contains a retry counter that applies to
an MTA-initiated AP-REQ/REP key management exchange with
the Provisioning Server. It is the maximum number of
retries before the MTA stops attempting to establish a
Security Association with Provisioning Server.
If the DHCP option code 122 sub-option 5 is provided to
the MTA, it overwrites this value."
REFERENCE
" PacketCable Security Specification."
DEFVAL {8}
::= { pktcMtaDevServer 14 }
pktcMtaDevProvKerbRealmName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(1..255))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
Nechamkin/Mule Expires - June 2004 [Page 23]
IPCDN MTA MIB January 2004
" This object contains the name of the associated
provisioning Kerberos realm acquired during the MTA4
provisioning step (DHCP Ack). This object value is used as
an index into the pktcMtaDevRealmTable. The upper case
ASCII representation of the associated Kerberos realm name
MUST be used by both the Manager (SNMP entity) and the
MTA.
The Kerberos realm name for the Provisioning Server is
supplied to the MTA via DHCP option code 122 sub-option 6
as defined in RFC 3495. The value of the Kerberos realm
name for the Provisioning Server supplied in the MTA
configuration file must match the value supplied in the
DHCP option code 122 sub-option 6."
REFERENCE
" PacketCable MTA Device Provisioning Specification;
RFC 3495, DHCP Option for CableLabs Client Configuration."
::= { pktcMtaDevServer 15 }
pktcMtaDevProvState OBJECT-TYPE
SYNTAX INTEGER {
operational (1),
waitingForSnmpSetInfo (2),
waitingForTftpAddrResponse (3),
waitingForConfigFile (4)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object defines the MTA provisioning state.
If the state is:
'operational(1)', the device has completed the loading
and processing of the initialization parameters.
'waitingForSnmpSetInfo(2)', the device is waiting on
its configuration file download access information.
'waitingForTftpAddrResponse(3)', the device has sent a
DNS request to resolve the server providing the
configuration file and it is awaiting for a response.
'waitingForConfigFile(4)', the device has sent a
request via TFTP or HTTP for the download of its
configuration file and it is awaiting for a response or
the file download is in progress."
REFERENCE
" PacketCable MTA Device Provisioning Specification,
PacketCable Security Specification."
::= { pktcMtaDevServer 16 }
Nechamkin/Mule Expires - June 2004 [Page 24]
IPCDN MTA MIB January 2004
--
-- The following object group describes the security objects.
--
pktcMtaDevManufacturerCertificate OBJECT-TYPE
SYNTAX DocsX509ASN1DEREncodedCertificate
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object contains the MTA Manufacturer Certificate.
The object value must be the ASN.1 DER encoding of the MTA
manufacturer's X.509 public key certificate. The MTA
Manufacturer Certificate is issued to each MTA
manufacturer and is installed into each MTA at the time of
manufacture or with a secure code download. The specific
requirements related to this certificate are defined in
the PacketCable or IPCablecom Security specifications."
REFERENCE
" PacketCable Security Specification."
::= {pktcMtaDevSecurity 1}
pktcMtaDevCertificate OBJECT-TYPE
SYNTAX DocsX509ASN1DEREncodedCertificate
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object contains the MTA Device Certificate.
The object value must be the ASN.1 DER encoding of the
MTA's X.509 public-key certificate issued by the
manufacturer and installed into the MTA at the time of
manufacture or with a secure code download.
This certificate contains the MTA MAC address. The
specific requirements related to this certificate are
defined in the PacketCable or IPCablecom Security
specifications."
REFERENCE
" PacketCable Security Specification."
::= { pktcMtaDevSecurity 2 }
pktcMtaDevCorrelationId OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object contains a correlation ID, an arbitrary value
generated by the MTA that will be exchanged as part of the
device capability data to the Provisioning Application.
Nechamkin/Mule Expires - June 2004 [Page 25]
IPCDN MTA MIB January 2004
This random value is used as an identifier to correlate
related events in the MTA provisioning sequence.
This value is intended for use only during the MTA
initialization and configuration file download."
REFERENCE
" PacketCable MTA Device Provisioning Specification."
::= { pktcMtaDevSecurity 3 }
pktcMtaDevTelephonyRootCertificate OBJECT-TYPE
SYNTAX DocsX509ASN1DEREncodedCertificate
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object contains the telephony Service Provider Root
certificate. The object value is the ASN.1 DER encoding of
the IP Telephony Service Provider Root X.509 public key
certificate. This certification is stored in the MTA
non-volatile memory and can be updated with a secure code
download. This certificate is used to validate the initial
AS Reply received by the MTA from the KDC during the MTA
initialization. The specific requirements related to this
certificate are defined in the PacketCable or IPCablecom
Security specifications."
REFERENCE
" PacketCable Security Specification."
::= { pktcMtaDevSecurity 4 }
--=================================================================
--
-- Informative procedures for setting up Security Associations:
--
-- A Security Association may be setup either via configuration or
-- via NCS signaling.
--
-- I. Security association setup via configuration.
--
-- The realm must be configured first. Associated with the realm
-- is a KDC. The realm table (pktcMtaDevRealmTable) indicates
-- information about the realm (e.g., name, organization name) and
-- parameters associated with KDC communications (e.g., grace
-- periods, AS Request/AS Reply adaptive back-off parameters).
--
-- Once the realm is established, one or more CMS(es) may be
-- defined in the realm. Associated with each CMS
-- entry in the pktcMtaDevCmsTable is an explicit reference
-- to a Realm via the realm name( pktcMtaDevCmsKerbRealmName),
-- the FQDN of the CMS, and parameters associated with IPSec
-- key management with the CMS (e.g., clock skew, AP Request/
Nechamkin/Mule Expires - June 2004 [Page 26]
IPCDN MTA MIB January 2004
-- AP Reply adaptive back-off parameters).
--
-- II. Security association setup via NCS signaling.
--
-- The procedure of establishing the Security Associations
-- for NCS signaling is described in the PacketCable Security
-- specification.
-- It involves the analysis of the pktcNcsEndPntConfigTable row
-- for the corresponding endpoint number and correlating
-- the CMS FQDN from this row with the CMS Table and
-- consequently - with the Realm Table. Both of these tables
-- are defined below. The pktcNcsEndPntConfigTable is defined in
-- the IPCDN NCS Signaling MIB [RFCzzz].
-- ************************************************************
-- * NOTES TO RFC Editor (to be removed prior to publication) *
-- * *
-- * Please replace RFCzzz with this RFC number for *
-- * draft-ietf-ipcdn-pktc-signaling-02.txt and remove *
-- * the note. *
-- ************************************************************
--
-- III. 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.
--
--=================================================================
--=================================================================
--
-- pktcMtaDevRealmTable
--
-- The pktcMtaDevRealmTable shows the KDC realms. The table is
-- indexed with pktcMtaDevRealmIndex. The Realm Table contains the
-- pktcMtaDevRealmName in conjunction with any server which needs
-- a Security Association with the MTA. Upper case must be use to
-- compare the pktcMtaDevRealmName content.
--
--=================================================================
pktcMtaDevRealmAvailSlot OBJECT-TYPE
SYNTAX Unsigned32 (0..64)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object contains the index number of the first
available entry in the realm table (pktcMtaDevRealmTable).
If all the entries in the realm table have been assigned,
this object contains the value of zero.
Nechamkin/Mule Expires - June 2004 [Page 27]
IPCDN MTA MIB January 2004
A management station should create new entries in the
realm table using the following procedure:
first, issue a management protocol retrieval operation
to determine the value of the first available index in the
realm table (pktcMtaDevRealmAvailSlot);
second, issue a management protocol SET operation
to create an instance of the pktcMtaDevRealmStatus
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 pktcMtaDevRealmStatus object to 'active(1)'."
::= { pktcMtaDevSecurity 5 }
pktcMtaDevRealmTable OBJECT-TYPE
SYNTAX SEQUENCE OF PktcMtaDevRealmEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
" This object contains the realm table.
The CMS table (pktcMtaDevCmsTable) and the realm table
(pktcMtaDevRealmTable) are used for managing the MTA-CMS
Security Associations. The realm table defines the
Kerberos realms for the Application Servers (CMSes & the
Provisioning Server)."
::= { pktcMtaDevSecurity 6 }
pktcMtaDevRealmEntry OBJECT-TYPE
SYNTAX PktcMtaDevRealmEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
" This table entry object lists the MTA security parameters
for a single Kerberos realm. The conceptual rows MUST NOT
persist across MTA reboots."
INDEX { pktcMtaDevRealmIndex }
::= { pktcMtaDevRealmTable 1 }
PktcMtaDevRealmEntry ::= SEQUENCE {
pktcMtaDevRealmIndex Unsigned32,
pktcMtaDevRealmName SnmpAdminString,
pktcMtaDevRealmPkinitGracePeriod Unsigned32,
pktcMtaDevRealmTgsGracePeriod Unsigned32,
pktcMtaDevRealmOrgName SnmpAdminString,
pktcMtaDevRealmUnsolicitedKeyMaxTimeout Unsigned32,
Nechamkin/Mule Expires - June 2004 [Page 28]
IPCDN MTA MIB January 2004
pktcMtaDevRealmUnsolicitedKeyNomTimeout Unsigned32,
pktcMtaDevRealmUnsolicitedKeyMaxRetries Unsigned32,
pktcMtaDevRealmStatus RowStatus
}
pktcMtaDevRealmIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..32)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
" This object defines the realm table index."
::= { pktcMtaDevRealmEntry 1}
pktcMtaDevRealmName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(1..255))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" This object identifies the Kerberos realm name in all
capitals. The MTA MUST prohibit the instantiation of any
two rows with identical Kerberos realm names. The MTA MUST
also verify that any search operation involving Kerberos
realm names is done using the upper case ASCII
representation of the characters."
::= { pktcMtaDevRealmEntry 2 }
pktcMtaDevRealmPkinitGracePeriod OBJECT-TYPE
SYNTAX Unsigned32 (15..600)
UNITS "minutes"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" This object contains the PKINIT Grace Period. For the
purpose of key management with Application Servers (CMSes
or the Provisioning Server), the MTA must utilize the
PKINIT exchange to obtain Application Server tickets. The
MTA may utilize the PKINIT exchange to obtain Ticket
Granting Tickets (TGTs), which are then used to obtain
Application Server tickets in a TGS exchange.
The PKINIT exchange occurs based on the current Ticket
Expiration Time (TicketEXP) and on the PKINIT Grace Period
(PKINITGP). The MTA MUST initiate the PKINIT exchange at
the time: TicketEXP û PKINITGP."
REFERENCE
" PacketCable Security Specification."
DEFVAL { 15 }
::= { pktcMtaDevRealmEntry 3 }
Nechamkin/Mule Expires - June 2004 [Page 29]
IPCDN MTA MIB January 2004
pktcMtaDevRealmTgsGracePeriod OBJECT-TYPE
SYNTAX Unsigned32 (1..600)
UNITS "minutes"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" This object contains the Ticket Granting Server Grace
Period (TGSGP). The Ticket Granting Server (TGS) Request /
Reply exchange may be performed by the MTA on-demand û
whenever an Application Server ticket is needed to
establish security parameters. If the MTA possesses a
ticket that corresponds to the Provisioning Server or a
CMS that currently exists in the CMS table, the MTA MUST
initiate the TGS Request / Reply exchange at the time:
TicketEXP û TGSGP."
REFERENCE
" PacketCable Security Specification."
DEFVAL { 10 }
::= { pktcMtaDevRealmEntry 4 }
pktcMtaDevRealmOrgName OBJECT-TYPE
SYNTAX SnmpAdminString(SIZE (1..64))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" This object contains the X.500 organization name attribute
as defined in the subject name of the service provider
certificate. The value of the organization name includes
the prefix 'O='."
REFERENCE
" PacketCable Security Specification."
::= { pktcMtaDevRealmEntry 5 }
--=================================================================
--
-- Unsolicited key updates are retransmitted based on 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,
-- this results in retransmission intervals of 3 s, 6 s, 12 s,
Nechamkin/Mule Expires - June 2004 [Page 30]
IPCDN MTA MIB January 2004
-- 20 s, 20 s, and then retransmissions stop because the maximum
-- number of retries has been reached.
--
--=================================================================
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. "
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."
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."
REFERENCE
" PacketCable Security Specification."
DEFVAL { 5 }
Nechamkin/Mule Expires - June 2004 [Page 31]
IPCDN MTA MIB January 2004
::= { 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
Nechamkin/Mule Expires - June 2004 [Page 32]
IPCDN MTA MIB January 2004
" 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,
Nechamkin/Mule Expires - June 2004 [Page 33]
IPCDN MTA MIB January 2004
pktcMtaDevCmsFqdn SnmpAdminString,
pktcMtaDevCmsKerbRealmName SnmpAdminString,
pktcMtaDevCmsSolicitedKeyTimeout Unsigned32,
pktcMtaDevCmsMaxClockSkew Unsigned32,
pktcMtaDevCmsUnsolicitedKeyMaxTimeout Unsigned32,
pktcMtaDevCmsUnsolicitedKeyNomTimeout Unsigned32,
pktcMtaDevCmsUnsolicitedKeyMaxRetries Unsigned32,
pktcMtaDevCmsIpsecCtrl TruthValue,
pktcMtaDevCmsStatus RowStatus
}
pktcMtaDevCmsIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..64)
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."
::= { 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 upper
case 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
Nechamkin/Mule Expires - June 2004 [Page 34]
IPCDN MTA MIB January 2004
" 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 based on 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,
-- this results in retransmission intervals of 3 s, 6 s, 12 s,
-- 20 s, 20 s, and then retransmissions 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
Nechamkin/Mule Expires - June 2004 [Page 35]
IPCDN MTA MIB January 2004
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 }
Nechamkin/Mule Expires - June 2004 [Page 36]
IPCDN MTA MIB January 2004
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,
- setting the invalidateAllCmsOnReboot bit (bit 1) to 1
means that the MTA MUST invalidate the Kerberos
Nechamkin/Mule Expires - June 2004 [Page 37]
IPCDN MTA MIB January 2004
Application Ticket(s) for all CMSes currently assigned
to the MTA endpoints."
REFERENCE
"PacketCable Security Specification."
DEFVAL { { } }
::= { pktcMtaDevSecurity 9 }
pktcMtaNotificationPrefix OBJECT IDENTIFIER ::= { pktcMtaMib 2 }
pktcMtaNotification OBJECT IDENTIFIER ::= {
pktcMtaNotificationPrefix 0 }
pktcMtaConformance OBJECT IDENTIFIER ::= { pktcMtaMib 3 }
pktcMtaDevProvisioningEnrollment NOTIFICATION-TYPE
OBJECTS {
sysDescr,
pktcMtaDevSwCurrentVers,
pktcMtaDevTypeIdentifier,
ifPhysAddress,
pktcMtaDevCorrelationId
}
STATUS current
DESCRIPTION
" This inform is issued by the MTA to indicate the start of
the PacketCable provisioning process.
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 is issued by the MTA to confirm the completion
of the PacketCable provisioning process, and to report
its provisioning completion status."
::= { pktcMtaNotification 2 }
--
-- Compliance Statements
--
Nechamkin/Mule Expires - June 2004 [Page 38]
IPCDN MTA MIB January 2004
pktcMtaCompliances OBJECT IDENTIFIER ::= { pktcMtaConformance 1 }
pktcMtaGroups OBJECT IDENTIFIER ::= { pktcMtaConformance 2 }
pktcMtaBasicCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
" The compliance statement for MTA devices (both E-MTA and
S-MTA) that implement PacketCable or IPCablecom
requirements.
This compliance statement applies to MTA implementations
that support PacketCable 1.x or IPCablecom requirements,
which are not IPv6-capable at the time of this
RFC publication."
MODULE -- Unconditionally mandatory groups for E-MTAs & S-MTAs
MANDATORY-GROUPS {
pktcMtaGroup,
pktcMtaNotificationGroup
}
OBJECT pktcMtaDevServerAddressType
SYNTAX InetAddressType
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."
::= { pktcMtaCompliances 1 }
pktcMtaGroup OBJECT-GROUP
OBJECTS {
pktcMtaDevResetNow,
pktcMtaDevSerialNumber,
pktcMtaDevSwCurrentVers,
pktcMtaDevFQDN,
pktcMtaDevEndPntCount,
pktcMtaDevEnabled,
pktcMtaDevErrorOid,
pktcMtaDevErrorValue,
pktcMtaDevErrorReason,
pktcMtaDevTypeIdentifier,
pktcMtaDevProvisioningState,
pktcMtaDevHttpAccess,
pktcMtaDevCertificate,
pktcMtaDevCorrelationId,
Nechamkin/Mule Expires - June 2004 [Page 39]
IPCDN MTA MIB January 2004
pktcMtaDevManufacturerCertificate,
pktcMtaDevServerAddressType,
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,
Nechamkin/Mule Expires - June 2004 [Page 40]
IPCDN MTA MIB January 2004
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 1.3 or IPCablecom requirements,
which are not IPv6-capable at the time of this
RFC publication."
-- Unconditionally Mandatory Groups for S-MTA devices
MODULE
MANDATORY-GROUPS {
pktcMtaGroup,
pktcMtaNotificationGroup
}
MODULE DOCS-CABLE-DEVICE-MIB
MANDATORY-GROUPS {
docsDevSoftwareGroupV2
}
MODULE DOCS-IETF-BPI2-MIB
MANDATORY-GROUPS {
docsBpi2CodeDownloadGroup
}
::= { pktcMtaCompliances 2 }
END
5. Acknowledgments
The current editors wish to express their gratitude to:
Angela Lyda Arris Interactive
Sumanth Channabasappa Alopa Networks
Matt A. Osman CableLabs
Klaus Hermanns, Paul Duffy Cisco Systems
Nechamkin/Mule Expires - June 2004 [Page 41]
IPCDN MTA MIB January 2004
Rick Vetter, Sasha Medvinsky Motorola
Roy Spitzer Telogy Networks, Inc.
Itay Sherman, Satish Kumar Texas Instruments
Rich Woundy Comcast
Bert Wijnen Lucent
Mike Heard Consultant
Eric Rosenfeld CableLabs
6. Normative References
[RFC868] Postel, J., "Time Protocol", STD 26, RFC 868, May 1983.
[RFC2131] R. Droms, "Dynamic Host Configuration Protocol", March
1997.
[RFC2132] S. Alexander, R. Droms, "DHCP Options and BOOTP Vendor
Extensions", March 1997.
[RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo "Internet
X.509 Public Key Infrastructure Certificate and CRL
Profile", RFC 2459, January 1999.
[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.
[RFC2863] McCloghrie, K., Kastenholz, F., "The Interfaces Group
MIB", June 2000.
[RFC3411] Harrington, D., Presuhn, R., and Wijnen, B., "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62,
December 2002.
[RFC3418] Presuhn, R., Case, J., McCloghrie, K., Rose, M.,
and Waldbusser, S., "Management Information Base (MIB)
for the Simple Network Management Protocol (SNMP)",
STD 62, December 2002.
[RFC3291] Daniele, M., Haberman, B., Routhier, S., Schoenwaelder,
Nechamkin/Mule Expires - June 2004 [Page 42]
IPCDN MTA MIB January 2004
J., "Textual Conventions for Internet Network Addresses",
RFC 3291, May 2002.
************************************************************
* NOTES TO RFC Editor (to be removed prior to publication) *
* *
* The I-D <draft-ietf-ops-rfc3291bis-02.txt> (or a *
* successor) is expected to eventually replace RFC 3291. *
* If that draft (or a successor) is published as a RFC *
* prior to or concurrently with this document, then the *
* normative reference [RFC3291] should be updated to *
* point to the replacement RFC, and the reference tag *
* [RFC3291] should be updated to match. *
* *
************************************************************
[RFC3495] B. Beser, P. Duffy, Ed., "Dynamic Host Configuration
Protocol (DHCP) Option for CableLabs Client
Configuration.", RFC 3495, March 2003.
[RFCyyyy] S. Green, K. Ozawa, A. Katsnelson, E. Cardona, "Management
Information Base for DOCSIS Cable Modems and Cable Modem
Termination Systems for Baseline Privacy Plus", RFCyyy,
Monthyyy, 2003.
************************************************************
* NOTES TO RFC Editor (to be removed prior to publication) *
* *
* The I-D <draft-ietf-ipcdn-bpiplus-mib-12.txt> *
* is expected to become RFC before this draft. *
* Please replace RFCyyy with the RFC number of bpiplus and *
* update the reference statement with the correct date: *
* Monthyyy, 2003 *
* *
************************************************************
[PKT-SP-PROV-I08-040113] Packetcable MTA Device Provisioning
Specification, Issued,
PKT-SP-PROV-I08-040113, January 2004.
http://www.packetcable.com/specifications
or http://www.cablelabs.com/specifications/archives
[PKT-SP-SEC-I10-040113] PacketCable Security Specification,
Issued,PKT-SP-SEC-I10-040113, January 2004.
http://www.packetcable.com/specifications
or http://www.cablelabs.com/specifications/archives
[ITU-T-J112] Transmission Systems for Interactive Cable Television
Services, Annex B, J.112, ITU-T, March, 1998.
Nechamkin/Mule Expires - June 2004 [Page 43]
IPCDN MTA MIB January 2004
[ITU-T-J122] Transmission Systems for Interactive Cable Television
Services, J.122, ITU-T, September, 2002.
[ITU-T-J168] IPCablecom Multimedia Terminal Adapter (MTA) MIB
requirements, J.168, ITU-T, March, 2001.
7. 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.
[PKT-SP-MIB-MTA-I08-040113] Packetcable MTA MIB Specification,
Issued, PKT-SP-MIB-MTA-I08-040113,
January 2004.
http://www.packetcable.com/specifications
or http://www.cablelabs.com/specifications/archives
[ETSI TS 101 909-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)".
[EN 300 001] 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; Chapter 3: Ringing
signal characteristics (national deviations are in
Table 3.1.1)".
[EN 300 659-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".
[RFCzzz] Beacham G., Kumar S., Channabasappa S., "Network Control
Signaling (NCS) Signaling MIB for PacketCable and
IPCablecom Multimedia Terminal Adapters (MTAs)", RFCzzz,
Monthzzz, 2003.
************************************************************
* NOTES TO RFC Editor (to be removed prior to publication) *
* *
Nechamkin/Mule Expires - June 2004 [Page 44]
IPCDN MTA MIB January 2004
* The I-D < draft-ietf-ipcdn-pktc-signaling-02.txt> *
* is expected to become RFC with this draft. *
* Please replace RFCzzz with the RFC number of pktc-sig and*
* update the reference statement with the correct date: *
* Monthzzz, 2003 *
* *
************************************************************
8. 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. Hence they are
considered very sensitive for service delivery. The objects in
question are:
pktcMtaDevProvisioningTimer,
pktcMtaDevServerAddressType,
pktcMtaDevServerDns1,
pktcMtaDevServerDns2,
pktcMtaDevTimeServer,
pktcMtaDevConfigFile,
pktcMtaDevProvConfigHash,
pktcMtaDevProvConfigKey,
pktcMtaDevProvSolicitedKeyTimeout,
pktcMtaDevRealmName,
pktcMtaDevRealmOrgName,
pktcMtaDevRealmUnsolicitedKeyMaxTimeout,
pktcMtaDevRealmUnsolicitedKeyNomTimeout,
pktcMtaDevRealmUnsolicitedKeyMaxRetries,
pktcMtaDevRealmStatus.
Certain of the above objects have additional specific
vulnerabilities:
Nechamkin/Mule Expires - June 2004 [Page 45]
IPCDN MTA MIB January 2004
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,
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:
pktcMtaDevResetKrbTickets û this object, if set to 'true' value,
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 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:
Nechamkin/Mule Expires - June 2004 [Page 46]
IPCDN MTA MIB January 2004
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 [RFC3410], section 8),
including full support for the SNMPv3 cryptographic mechanisms (for
authentication and privacy).
Further, deployment of SNMP versions prior to SNMPv3 is NOT
RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
enable cryptographic security. It is then a customer/operator
responsibility to ensure that the SNMP entity giving access to an
instance of this MIB module is properly configured to give access to
the objects only to those principals (users) that have legitimate
rights to indeed GET or SET (change/create/delete) them.
9. 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 in BCP-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.
Nechamkin/Mule Expires - June 2004 [Page 47]
IPCDN MTA MIB January 2004
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.
10. Authors' Addresses
Eugene Nechamkin
Broadcom Corporation,
200 - 13711 International Place
Richmond, BC, V6V 2Z8
CANADA
Phone: +1 604 233 8500
E-mail: enechamkin@broadcom.com
Jean-Francois Mule
Cable Television Laboratories, Inc.
400 Centennial Parkway
Louisville, Colorado 80027-1266
U.S.A.
Phone: +1 303-661-9100
E-mail: jf.mule@cablelabs.com
11. Full Copyright Statement
Copyright (C) The Internet Society (2004). 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
Nechamkin/Mule Expires - June 2004 [Page 48]
IPCDN MTA MIB January 2004
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.
Nechamkin/Mule Expires - June 2004 [Page 49]
