GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4682

Network Working Group E. Nechamkin Request for Comments: 4682 Broadcom Corp. Category: Standards Track J-F. Mule

                                                             CableLabs
                                                         December 2006
   Multimedia Terminal Adapter (MTA) Management Information Base
         for PacketCable- and IPCablecom-Compliant Devices

Status of This Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

 Copyright (C) The IETF Trust (2006).

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 Simple
 Network Management Protocol (SNMP)-based management of PacketCable-
 and IPCablecom-compliant Multimedia Terminal Adapter devices.

Table of Contents

 1. The Internet-Standard Management Framework ......................2
 2. Terminology .....................................................2
 3. Introduction ....................................................4
    3.1. Structure of the MTA MIB ...................................5
    3.2. pktcMtaDevBase .............................................5
    3.3. pktcMtaDevServer ...........................................6
    3.4. pktcMtaDevSecurity .........................................6
    3.5. Relationship between MIB Objects in the MTA MIB ............7
    3.6. Secure Software Download ...................................8
    3.7. X.509 Certificates Dependencies ............................8
 4. Definitions .....................................................9
 5. Acknowledgements ...............................................52
 6. Security Considerations ........................................52
 7. IANA Considerations ............................................55
 8. Normative References ...........................................55
 9. Informative References .........................................57

Nechamkin & Mule Standards Track [Page 1] RFC 4682 IPCDN MTA MIB December 2006

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].

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] and the PacketCable Security
 Specification [PKT-SP-SEC].
 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 J.112 recommendation, Annex B, for cable modem
 systems [ITU-T-J112].
 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.
 Multimedia Terminal Adapter
 A Multimedia Terminal Adapter (MTA) is a PacketCable- or IPCablecom-
 compliant device providing telephony services over a cable or hybrid

Nechamkin & Mule Standards Track [Page 2] RFC 4682 IPCDN MTA MIB December 2006

 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 Message Access Control (MAC) interface
 (e.g., Ethernet, USB).
 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.
 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 3280 [RFC3280] and RFC 4630
 [RFC4630].
 Voice over IP
 Voice over IP (VoIP) is a technology providing the means to transfer
 digitized packets with voice information over IP networks.
 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.
 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 specifications, RFC 3495 [RFC3495] and RFC 3594 [RFC3594].
 TFTP
 The Trivial File Transfer Protocol (TFTP) is defined by RFC 1350
 [RFC1350].
 HTTP
 The Hypertext Transfer Protocol (HTTP/1.1) is defined by RFC 2616
 [RFC2616].
 Call Management Server
 A Call Management Server (CMS) is an element of the PacketCable
 network infrastructure that controls audio connections between MTAs.

Nechamkin & Mule Standards Track [Page 3] RFC 4682 IPCDN MTA MIB December 2006

 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.
 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.
 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).
 Security Association
 A Security Association (SA) is a one-way relationship between a
 sender and a receiver offering security services on the communication
 flow.

3. Introduction

 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:
  1. The PacketCable 1.0 MTA MIB Specification [PKT-SP-MIB-MTA].
  1. The ITU-T IPCablecom MTA MIB requirements [ITU-T-J168].
  1. The ETSI MTA MIB [ETSITS101909-8]. The ETSI MTA MIB requirements

also refer to various signal characteristics defined in

    [EN300001], Chapter 3, titled 'Ringing Signal Characteristics',
    and [EN300659-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.

Nechamkin & Mule Standards Track [Page 4] RFC 4682 IPCDN MTA MIB December 2006

3.1. Structure of the MTA MIB

 The MTA MIB module is identified by pktcIetfMtaMib and is structured
 in three object groups:
  1. pktcMtaDevBase defines the management information pertinent to the

MTA device itself.

  1. pktcMtaDevServer defines the management information pertinent to

the provisioning back office servers.

  1. 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:
  1. pktcMtaDevSerialNumber. This object contains the MTA Serial

Number.

  1. pktcMtaDevEndPntCount. This object contains the number of

endpoints present in the managed MTA.

  1. pktcMtaDevProvisioningState. This object contains the information

describing the completion state of the MTA initialization process.

  1. pktcMtaDevEnabled. This object controls the administrative state

of the MTA endpoints and allows operators to enable or disable

    telephony services on the device.
  1. pktcMtaDevResetNow. This object is used to instruct the MTA to

reset.

Nechamkin & Mule Standards Track [Page 5] RFC 4682 IPCDN MTA MIB December 2006

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.
 Some highlights are as follows:
  1. pktcMtaDevServerDhcp1. This object contains the IP address of the

primary DHCP server designated for the MTA provisioning.

  1. pktcMtaDevServerDhcp2. This object contains the IP address of the

secondary DHCP server designated for the MTA provisioning.

  1. 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.
  1. pktcMtaDevServerDns2. This object contains the IP address of the

secondary DNS used by the managed MTA to resolve the FQDN and IP

    addresses.
  1. pktcMtaDevConfigFile. This object contains the name of the

provisioning configuration file the managed MTA must download from

    the Provisioning Server.
  1. 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.

Nechamkin & Mule Standards Track [Page 6] RFC 4682 IPCDN MTA MIB December 2006

 The two tables in this object group are as follows:
  1. pktcMtaDevRealmTable. This table is used in conjunction with any

Application Server that communicates securely with the managed MTA

    (CMS or Provisioning Server).
  1. 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.
 The process of Security Association establishment between an MTA and
 Application Servers is described in the PacketCable Security
 Specification [PKT-SP-SEC].  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:
  1. pktcMtaDevProvUnsolicitedKeyMaxTimeout,
  1. pktcMtaDevProvUnsolicitedKeyNomTimeout,

Nechamkin & Mule Standards Track [Page 7] RFC 4682 IPCDN MTA MIB December 2006

  1. pktcMtaDevProvUnsolicitedKeyMaxRetries, and
  1. pktcMtaDevProvSolicitedKeyTimeout.

3.6. Secure Software Download

 E-MTAs are embedded with DOCSIS 1.1 cable modems.  E-MTAs have their
 software upgraded by the Cable Modem according to the DOCSIS
 requirements.
 Although E-MTAs have their software upgraded by the Cable Modem
 according to the DOCSIS requirements, S-MTAs implement a specific
 mechanism for Secure Software Download.  This provides a 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 also
 rely on two MIB object groups:
  1. docsBpi2CodeDownloadGroup, defined in the IETF BPI Plus MIB module

(DOCS-IETF-BPI2-MIB [RFC4131]).

  1. docsDevSoftwareGroupV2, defined in the IETF Cable Devicev2 MIB

module (DOCS-CABLE-DEVICE-MIB [RFC4639]).

3.7. X.509 Certificates Dependencies

 As specified in the PacketCable Security Specification [PKT-SP-SEC],
 E-MTAs must use the authentication mechanism based on the X.509
 Public Key Infrastructure Certificates, as defined in RFC 3280
 [RFC3280] and RFC 4630 [RFC4630].
 The value of the pktcMtaDevRealmOrgName MIB object should contain the
 X.509 organization name attribute of the Telephony Service Provider
 certificate (OrganizationName).  X.509 attributes are defined using
 UTF-8 string encoding [RFC3629, RFC3280, and RFC4630].
 Note that UTF-8 encoded characters can be encoded as sequences of 1
 to 6 octets, assuming that code points as high as 0x7ffffffff might
 be used ([RFC3629]).  Subsequent versions of Unicode and ISO 10646
 have limited the upper bound to 0x10ffff ([RFC3629]).  Consequently,
 the current version of UTF-8, defined in RFC 3629, does not require
 more than four octets to encode a valid code point.

Nechamkin & Mule Standards Track [Page 8] RFC 4682 IPCDN MTA MIB December 2006

4. Definitions

 The MIB module below makes references and citations to [RFC868],
 [RFC3280], [RFC4630], and [RFC3617].
 PKTC-IETF-MTA-MIB DEFINITIONS ::= BEGIN
 IMPORTS
     MODULE-IDENTITY,
     OBJECT-TYPE,
     OBJECT-IDENTITY,
     Unsigned32,
     Counter32,
     NOTIFICATION-TYPE,
     mib-2
           FROM SNMPv2-SMI                    -- [RFC2578]
     TEXTUAL-CONVENTION,
     RowStatus,
     TruthValue
           FROM SNMPv2-TC                     -- [RFC2579]
     OBJECT-GROUP,
     MODULE-COMPLIANCE,
     NOTIFICATION-GROUP
           FROM SNMPv2-CONF                   -- [RFC2580]
     InetAddressType,
     InetAddress
           FROM INET-ADDRESS-MIB              -- [RFC4001]
     sysDescr
           FROM SNMPv2-MIB                    -- [RFC3418]
     SnmpAdminString
           FROM SNMP-FRAMEWORK-MIB            -- [RFC3411]
     docsDevSoftwareGroupV2
           FROM DOCS-CABLE-DEVICE-MIB         -- [RFC4639]
     DocsX509ASN1DEREncodedCertificate,
     docsBpi2CodeDownloadGroup
           FROM DOCS-IETF-BPI2-MIB            -- [RFC4131]
     LongUtf8String
           FROM SYSAPPL-MIB                   -- [RFC2287]
     ifPhysAddress
           FROM IF-MIB;                       -- [RFC2863]
     pktcIetfMtaMib MODULE-IDENTITY
     LAST-UPDATED "200609180000Z" -- September 18, 2006
     ORGANIZATION "IETF IP over Cable Data Network Working Group"
     CONTACT-INFO
         "Eugene Nechamkin
          Broadcom Corporation,
          200-13711 International Place,

Nechamkin & Mule Standards Track [Page 9] RFC 4682 IPCDN MTA MIB December 2006

          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, CO 80027-9750
          U.S.A.
          Phone: +1 303 661 9100
          Email: jf.mule@cablelabs.com
     IETF IPCDN Working Group
          General Discussion: ipcdn@ietf.org
          Subscribe: http://www.ietf.org/mailman/listinfo/ipcdn
          Archive: ftp://ftp.ietf.org/ietf-mail-archive/ipcdn
          Co-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 IETF Trust (2006).  This version of
         this MIB module is part of RFC 4682; see the RFC itself for
         full legal notices."
     REVISION    "200609180000Z"   -- September 18, 2006
     DESCRIPTION
        "Initial version, published as RFC 4682."
 ::=  { mib-2 140 }
  1. - Textual Conventions
 PktcMtaDevProvEncryptAlg  ::= TEXTUAL-CONVENTION
     STATUS      current
     DESCRIPTION
         " This textual convention defines various types of the
           encryption algorithms used for the encryption of the MTA
           configuration file.  The description of the encryption
           algorithm for each enumerated value is as follows:
           'none(0)'            no encryption is used,
           'des64CbcMode(1)'    DES 64-bit key in CBC mode,

Nechamkin & Mule Standards Track [Page 10] RFC 4682 IPCDN MTA MIB December 2006

           't3Des192CbcMode(2)' 3DES 192-bit key in CBC mode,
           'aes128CbcMode(3)'   AES 128-bit key in CBC mode,
           'aes256CbcMode(4)'   AES 256-bit key in CBC mode."
     SYNTAX      INTEGER  {
                 none             (0),
                 des64CbcMode     (1),
                 t3Des192CbcMode  (2),
                 aes128CbcMode    (3),
                 aes256CbcMode    (4)
     }
  1. -=================================================================
  2. - The MTA MIB module only supports a single Provisioning Server.
  3. -=================================================================
 pktcMtaNotification OBJECT IDENTIFIER ::= { pktcIetfMtaMib 0 }
 pktcMtaMibObjects  OBJECT IDENTIFIER ::= { pktcIetfMtaMib 1 }
 pktcMtaDevBase     OBJECT IDENTIFIER ::= { pktcMtaMibObjects 1 }
 pktcMtaDevServer   OBJECT IDENTIFIER ::= { pktcMtaMibObjects 2 }
 pktcMtaDevSecurity OBJECT IDENTIFIER ::= { pktcMtaMibObjects 3 }
 pktcMtaDevErrors   OBJECT IDENTIFIER ::= { pktcMtaMibObjects 4 }
 pktcMtaConformance  OBJECT IDENTIFIER ::= { pktcIetfMtaMib 2 }
  1. -
  2. - The following pktcMtaDevBase group describes the base MTA objects
  3. -
 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 to 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.
           If a value is written into an instance of
           pktcMtaDevResetNow, the agent MUST NOT retain the supplied
           value across MTA re-initializations or reboots."
     REFERENCE

Nechamkin & Mule Standards Track [Page 11] RFC 4682 IPCDN MTA MIB December 2006

         " PacketCable MTA Device Provisioning Specification."
     ::= { pktcMtaDevBase 1 }
 pktcMtaDevSerialNumber OBJECT-TYPE
     SYNTAX      SnmpAdminString
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         " This object specifies the manufacturer's serial
           number of this MTA.  The value of this object MUST be
           identical to the value specified in DHCP option 43,
           sub-option 4.  The list of sub-options for DHCP option
           43 are defined in the PacketCable MTA Device
           Provisioning Specification."
     REFERENCE
         " PacketCable MTA Device Provisioning Specification."
     ::= { 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.
           The 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
           identical to the software version information contained
           in the 'sysDescr' MIB object of the MTA.  The value of
           this object MUST be identical to the value specified in
           DHCP option 43, sub-option 6.  The list of sub-options for
           DHCP option 43 are defined in the PacketCable MTA Device
           Provisioning Specification."
     REFERENCE
         " PacketCable MTA Device Provisioning Specification."
 ::= { 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.  The MTA FQDN is used to uniquely identify the
           device to the PacketCable back office elements."

Nechamkin & Mule Standards Track [Page 12] RFC 4682 IPCDN MTA MIB December 2006

     ::= { 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:
                - Shut down all media sessions, if present.
                - Shut down Network Control Signaling (NCS)
                signaling by following the Restart in
                Progress procedures in the PacketCable NCS
                specification.
            The MTA must execute all actions required to
            enable or disable the telephony services for all
            endpoints immediately upon receipt of an SNMP SET
            operation.
            Additionally, the MTA MUST maintain the SNMP Interface
            for management and also the 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 or IPCablecom Specification.
            If a value is written into an instance of
            pktcMtaDevEnabled, the agent MUST NOT retain the supplied
            value across MTA re-initializations or reboots."
     REFERENCE
         " PacketCable MTA Device Provisioning Specification;
           PacketCable Security Specification;
           PacketCable Network-Based Call Signaling Protocol

Nechamkin & Mule Standards Track [Page 13] RFC 4682 IPCDN MTA MIB December 2006

           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.  The
           DHCP option 60 value contains an ASCII-encoded string
           identifying capabilities of the MTA as defined in the
           PacketCable MTA Device Provisioning Specification."
     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),
                 passWithWarnings          (4),
                 passWithIncompleteParsing (5),
                 failureInternalError      (6),
                 failureOtherReason        (7)
     }
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         " This object indicates the completion state of the MTA
           device provisioning process.
           pass:
           If the configuration file could be parsed successfully
           and the MTA is able to reflect the same in its
           MIB, the MTA MUST return the value 'pass'.
           inProgress:
           If the MTA is in the process of being provisioned,
           the MTA MUST return the value 'inProgress'.
           failConfigFileError:
           If the configuration file was in error due to incorrect
           values in the mandatory parameters, the MTA MUST reject
           the configuration file, and the MTA MUST return the value

Nechamkin & Mule Standards Track [Page 14] RFC 4682 IPCDN MTA MIB December 2006

           'failConfigFileError'.
           passWithWarnings:
           If the configuration file had proper values for all the
           mandatory parameters but has errors in any of the optional
           parameters (this includes any vendor-specific Object
           Identifiers (OIDs) that are incorrect or not known
           to the MTA), the MTA MUST return the value
           'passWithWarnings'.
           passWithIncompleteParsing:
           If the configuration file is valid but the MTA cannot
           reflect the same in its configuration (for example, too
           many entries caused memory exhaustion), it must accept
           the CMS configuration entries related, and the MTA MUST
           return the value 'passWithIncompleteParsing'.
           failureInternalError:
           If the configuration file cannot be parsed due to an
           Internal error, the MTA MUST return the value
           'failureInternalError'.
           failureOtherReason:
           If the MTA cannot accept the configuration file for any
           other reason than the ones stated above, the MTA MUST
           return the value 'failureOtherReason'.
           When a final SNMP INFORM is sent as part of Step 25 of the
           MTA Provisioning process, this parameter is also included
           in the final INFORM message."
        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."
     ::= { pktcMtaDevBase 9 }
 pktcMtaDevProvisioningTimer  OBJECT-TYPE
     SYNTAX      Unsigned32 (0..30)
     UNITS       "minutes"
     MAX-ACCESS  read-write
     STATUS      current

Nechamkin & Mule Standards Track [Page 15] RFC 4682 IPCDN MTA MIB December 2006

     DESCRIPTION
         " This object defines the time interval for the provisioning
           flow to complete.  The MTA MUST finish all provisioning
           operations starting from the moment when an MTA receives
           its DHCP ACK and ending at the moment when the MTA
           downloads its configuration file (e.g., MTA5 to MTA23)
           within the period of time set by this object.
           Failure to comply with this condition constitutes
           a provisioning flow failure.  If the object is set to 0,
           the MTA MUST ignore the provisioning timer condition.
           If a value is written into an instance of
           pktcMtaDevProvisioningTimer, the agent MUST NOT retain the
           supplied value across MTA re-initializations or reboots."
     REFERENCE
         " PacketCable MTA Device Provisioning Specification."
     DEFVAL {10}
     ::=  {pktcMtaDevBase 10}
 pktcMtaDevProvisioningCounter  OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
             "This object counts the number of times the
             provisioning cycle has looped through step MTA-1."
       ::= {pktcMtaDevBase 11}
  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).  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

Nechamkin & Mule Standards Track [Page 16] RFC 4682 IPCDN MTA MIB December 2006

           the MTA reboots."
     REFERENCE
         " PacketCable MTA Device Provisioning Specification."
     ::= {pktcMtaDevBase 12 }
 pktcMtaDevErrorOidsEntry  OBJECT-TYPE
     SYNTAX PktcMtaDevErrorOidsEntry
     MAX-ACCESS not-accessible
     STATUS current
     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 that starts at value '1'
           and is incremented for each encountered configuration
           file error or warning.
           The maximum number of errors or warnings that can be
           recorded in the pktcMtaDevErrorOidsTable is set to 1024 as
           a configuration file is usually validated by operators
           before deployment.  Given the possible number of
           configuration parameter assignments in the MTA
           configuration file, 1024 is perceived as a sufficient
           limit even with future extensions.
           If the number of the errors in the configuration file
           exceeds 1024, all errors beyond the 1024th one MUST
           be ignored and not be reflected in the
           pktcMtaDevErrorOidsTable."
     ::= {pktcMtaDevErrorOidsEntry 1}

Nechamkin & Mule Standards Track [Page 17] RFC 4682 IPCDN MTA MIB December 2006

 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.140.1.1.6.0'.
           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
           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 if
           the MTA was not able to recognize this OID as a valid one,
           this object instance will contain a zero-length string.
           If the number of errors in the configuration file exceeds
           1024, then for all subsequent errors, the
           pktcMtaDevErrorOid of the table's 1024th entry MUST
           contain a human-readable representation of the
           pktcMtaDevErrorsTooManyErrors object; i.e., the string
           '1.3.6.1.2.1.140.1.1.4.1.0'.
           Note that the syntax of this object is SnmpAdminString
           instead of OBJECT IDENTIFIER because the object value may
           not be a valid OID due to human or configuration tool
           encoding errors."
     ::= {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

Nechamkin & Mule Standards Track [Page 18] RFC 4682 IPCDN MTA MIB December 2006

           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'.
           If the number of errors in the configuration file exceeds
           1024, then for all subsequent errors, the
           pktcMtaDevErrorValue of the table's 1024th entry MUST
           contain a human-readable representation of the
           pktcMtaDevErrorsTooManyErrors object; i.e., the string
           '1.3.6.1.2.1.140.1.1.4.1.0'."
     ::= {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.
           For example:
           'VALUE NOT IN RANGE', 'VALUE DOES NOT MATCH TYPE',
           'UNSUPPORTED VALUE', 'LAST 4 BITS MUST BE SET TO ZERO',
           'OUT OF MEMORY - CANNOT STORE'.
           This object may also contain vendor specific errors for
           private vendor OIDs and any proprietary error codes or
           messages that can help diagnose configuration errors.
           If the number of errors in the configuration file exceeds
           1024, then for all subsequent errors, the
           pktcMtaDevErrorReason of the table's 1024th entry MUST
           contain a human-readable string indicating the reason
           for an error; for example,
           'Too many errors in the configuration file'."
     ::= {pktcMtaDevErrorOidsEntry 4}
  1. -
  2. - The following group describes server access and parameters used

Nechamkin & Mule Standards Track [Page 19] RFC 4682 IPCDN MTA MIB December 2006

  1. - for the initial MTA provisioning and bootstrapping phases.
  2. -
 pktcMtaDevDhcpServerAddressType  OBJECT-TYPE
     SYNTAX      InetAddressType
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         " This object contains the Internet address type for the
           PacketCable DHCP 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 pktcMtaDevDhcpServerAddressType object.
           When the latter has the value 'ipv4(1)', this object
           contains the 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
           pktcMtaDevDhcpServerAddressType is other than 'ipv4(1)'
           is not presently specified, but it 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
           that 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 }
 pktcMtaDevServerDhcp2  OBJECT-TYPE
     SYNTAX      InetAddress
     MAX-ACCESS  read-only

Nechamkin & Mule Standards Track [Page 20] RFC 4682 IPCDN MTA MIB December 2006

     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 pktcMtaDevDhcpServerAddressType object.
           When the latter has the value 'ipv4(1)', this object
           contains the 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
           pktcMtaDevDhcpServerAddressType is other than 'ipv4(1)'
           is not presently specified, but it 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 }
 pktcMtaDevDnsServerAddressType  OBJECT-TYPE
     SYNTAX      InetAddressType
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         " This object contains the Internet address type for the
           PacketCable DNS servers specified in MTA MIB."
     DEFVAL { ipv4 }
     ::= { pktcMtaDevServer 4}
 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
           pktcMtaDevDnsServerAddressType object.
           When the latter has the value 'ipv4(1)', this object
           contains the IP address of the primary DNS server.
           As defined in RFC 2132, PacketCable-compliant MTAs receive
           the IP addresses of the DNS Servers in DHCP option 6.
           The behavior of this object when the value of
           pktcMtaDevDnsServerAddressType is other than 'ipv4(1)'

Nechamkin & Mule Standards Track [Page 21] RFC 4682 IPCDN MTA MIB December 2006

           is not presently specified, but it may be specified
           in future versions of this MIB module.
           If a value is written into an instance of
           pktcMtaDevServerDns1, the agent MUST NOT retain the
           supplied value across MTA re-initializations or reboots."
     REFERENCE
         " PacketCable MTA Device Provisioning Specification;
           RFC 2132, DHCP Options and BOOTP Vendor Extensions."
     ::= { pktcMtaDevServer 5 }
 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
           pktcMtaDevDnsServerAddressType object.
           When the latter has the value 'ipv4(1)', this object
           contains the IP address of the secondary DNS
           server.  As defined in RFC 2132, PacketCable-compliant MTAs
           receive the IP addresses of the DNS Servers in DHCP
           option 6.
           The behavior of this object when the value of
           pktcMtaDevDnsServerAddressType is other than 'ipv4(1)'
           is not presently specified, but it may be specified
           in future versions of this MIB module.
           If a value is written into an instance of
           pktcMtaDevServerDns2, the agent MUST NOT retain the
           supplied value across MTA re-initializations or reboots."
     REFERENCE
         " PacketCable MTA Device Provisioning Specification;
           RFC 2132, DHCP Options and BOOTP Vendor Extensions."
     ::= { pktcMtaDevServer 6 }
 pktcMtaDevTimeServerAddressType  OBJECT-TYPE
     SYNTAX      InetAddressType
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         " This object contains the Internet address type for the
           PacketCable Time servers specified in MTA MIB."
     DEFVAL { ipv4 }
     ::= { pktcMtaDevServer 7}
 pktcMtaDevTimeServer   OBJECT-TYPE
     SYNTAX      InetAddress

Nechamkin & Mule Standards Track [Page 22] RFC 4682 IPCDN MTA MIB December 2006

     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
           pktcMtaDevTimeServerAddressType 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
           pktcMtaDevTimeServerAddressType is other than 'ipv4(1)'
           is not presently specified, but it may be specified in
           future versions of this MIB module.
           If a value is written into an instance of
           pktcMtaDevTimeServer, the agent MUST NOT retain the
           supplied value across MTA re-initializations or reboots."
     REFERENCE
         " RFC 868, Time Protocol;
           RFC 2131, Dynamic Host Configuration Protocol;
           RFC 2132, DHCP Options and BOOTP Vendor Extensions."
     ::= { pktcMtaDevServer 8}
 pktcMtaDevConfigFile  OBJECT-TYPE
     SYNTAX      SnmpAdminString
     MAX-ACCESS  read-write
     STATUS      current
     DESCRIPTION
         " This object specifies the MTA device configuration file
           information, including the access method, the server name,
           and the configuration file name.  The value of this object
           is the Uniform Resource Locator (URL) of the configuration
           file for TFTP or HTTP download.
           If this object value is a TFTP URL, it must be formatted
           as defined in RFC 3617.
           If this object value is an HTTP URL, it must be formatted
           as defined in RFC 2616.
           If the MTA SNMP Enrollment mechanism is used, then the MTA
           must download the file provided by the Provisioning Server

Nechamkin & Mule Standards Track [Page 23] RFC 4682 IPCDN MTA MIB December 2006

           during provisioning via an SNMP SET on this object.
           If the MTA SNMP Enrollment mechanism is not used, this
           object MUST contain the URL value corresponding to the
           'siaddr' and 'file' fields received in the DHCP ACK to
           locate the configuration file: the 'siaddr' and 'file'
           fields represent the host and file of the TFTP URL,
           respectively.  In this case, the MTA MUST return an
           'inconsistentValue' error in response to SNMP SET
           operations.
           The MTA MUST return a zero-length string if the server
           address (host part of the URL) is unknown.
           If a value is written into an instance of
           pktcMtaDevConfigFile, the agent MUST NOT retain the
           supplied value across MTA re-initializations or reboots."
     REFERENCE
         " PacketCable MTA Device Provisioning Specification;
           RFC 3617, URI Scheme for TFTP; RFC 2616, HTTP 1.1"
     ::= { pktcMtaDevServer 9 }
 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.  When the MTA SNMP Enrollment
           Mechanism is used, this object represents the server that
           the MTA communicates with, that it receives the
           configuration file URL from, and that it sends the
           enrollment notification to.  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 DHCP option
           122, sub-option 3, as defined in RFC 3495.  The MTA must
           resolve the FQDN value before its very first network
           interaction with the SNMP entity during the provisioning
           phase."
     REFERENCE
         " PacketCable MTA Device Provisioning Specification;
           RFC 3495, DHCP Option for CableLabs Client Configuration."
     ::= { pktcMtaDevServer 10 }
 pktcMtaDevProvConfigHash  OBJECT-TYPE
     SYNTAX      OCTET STRING (SIZE(20))
     MAX-ACCESS  read-write
     STATUS      current

Nechamkin & Mule Standards Track [Page 24] RFC 4682 IPCDN MTA MIB December 2006

     DESCRIPTION
         " This object contains the hash value of the contents of the
           configuration file.
           The authentication algorithm is Secure Hashing Algorithm
           1 (SHA-1), and the length is 160 bits.  The hash
           calculation MUST follow the requirements defined in the
           PacketCable Security Specification.  When the MTA SNMP
           Enrollment mechanism is used, this hash value is
           calculated and sent to the MTA prior to sending the
           config file.  This object value is then provided by the
           Provisioning server via an SNMP SET operation.
           When the MTA SNMP Enrollment mechanism is not in use, the
           hash value is provided in the configuration file itself,
           and it is also calculated by the MTA.  This object value
           MUST represent the hash value calculated by the MTA.
           When the MTA SNMP Enrollment mechanism is not in use, the
           MTA must reject all SNMP SET operations on this object and
           return an 'inconsistentValue' error.
           If a value is written into an instance of
           pktcMtaDevProvConfigHash, the agent MUST NOT retain the
           supplied value across MTA re-initializations or reboots."
     REFERENCE
         " PacketCable MTA Device Provisioning Specification;
           PacketCable Security Specification."
     ::= { pktcMtaDevServer 11 }
 pktcMtaDevProvConfigKey  OBJECT-TYPE
     SYNTAX      OCTET STRING (SIZE(32))
     MAX-ACCESS  read-write
     STATUS      current
     DESCRIPTION
         " This object contains the key used to encrypt/decrypt
           the configuration file when secure SNMPv3 provisioning
           is used.
           The value of this object is provided along with the
           configuration file information (pktcMtaDevConfigFile)
           and hash (pktcMtaDevProvConfigHash) by the Provisioning
           Server via SNMP SET once the configuration file has been
           created, as defined by the PacketCable Security
           specification.
           The privacy algorithm is defined by the
           pktcMtaDevProvConfigEncryptAlg MIB object.  The
           MTA requirements related to the privacy algorithm are
           defined in the PacketCable Security Specification.
           If this object is set at any other provisioning step than
           that allowed by the PacketCable MTA Device

Nechamkin & Mule Standards Track [Page 25] RFC 4682 IPCDN MTA MIB December 2006

           Provisioning Specification, the MTA SHOULD return
           an 'inconsistentValue' error.
           This object must not be used in non secure provisioning
           mode.  In non-secure provisioning modes, the MTA SHOULD
           return an 'inconsistentValue' in response to SNMP SET
           operations, and the MTA SHOULD return a zero-length
           string in response to SNMP GET operations.
           If a value is written into an instance of
           pktcMtaDevProvConfigKey, the agent MUST NOT retain the
           supplied value across MTA re-initializations or reboots."
     REFERENCE
         " PacketCable MTA Device Provisioning Specification;
           PacketCable Security Specification."
     ::= { pktcMtaDevServer 12 }
 pktcMtaDevProvConfigEncryptAlg   OBJECT-TYPE
     SYNTAX      PktcMtaDevProvEncryptAlg
     MAX-ACCESS  read-write
     STATUS      current
     DESCRIPTION
         " This object defines the encryption algorithm used for
           privacy protection of the MTA Configuration File content."
     DEFVAL { des64CbcMode }
     ::= { pktcMtaDevServer 13 }
 pktcMtaDevProvSolicitedKeyTimeout  OBJECT-TYPE
     SYNTAX      Unsigned32 (0..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 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).
           If this object is set to a zero value, the MTA MUST return
           an 'inconsistentValue' in response to SNMP SET operations.
           This object should not be used in non-secure provisioning
           modes.  In non-secure provisioning modes, the MTA MUST
           return an 'inconsistentValue' in response to SNMP SET
           operations, and the MTA MUST return a zero value in

Nechamkin & Mule Standards Track [Page 26] RFC 4682 IPCDN MTA MIB December 2006

           response to SNMP GET operations.
           If a value is written into an instance of
           pktcMtaDevProvSolicitedKeyTimeout, the agent MUST NOT
           retain the supplied value across MTA re-initializations
           or reboots."
     DEFVAL { 3 }
     ::= { pktcMtaDevServer 14 }
  1. -=================================================================
  2. -
  3. - Unsolicited key updates are retransmitted according to an
  4. - exponential back-off mechanism using two timers and a maximum
  5. - retry counter for AS replies.
  6. - The initial retransmission timer value is the nominal timer
  7. - value (pktcMtaDevProvUnsolicitedKeyNomTimeout). The
  8. - retransmissions occur with an exponentially increasing interval
  9. - that caps at the maximum timeout value
  10. - (pktcMtaDevProvUnsolicitedKeyMaxTimeout).
  11. - Retransmissions stop when the maximum retry counter is reached
  12. - (pktcMtaDevProvUnsolicitedKeyMaxRetries).
  13. - For example, with values of 3 seconds for the nominal
  14. - timer, 100 seconds for the maximum timeout, and 8 retries max,
  15. - and with an exponential value of 2, this results in
  16. - retransmission intervals will be 3 s, 6 s, 12 s, 24 s, 48 s,
  17. - 96 s, 100 s, and 100 s;
  18. - retransmissions then stop because the maximum number of
  19. - retries (8) has been reached.
  20. -
  21. -=================================================================
  22. -
  23. - Timeouts for unsolicited key management updates are only
  24. - pertinent before the first SNMPv3 message is sent between the
  25. - MTA and the Provisioning Server and before the configuration
  26. - file is loaded.
  27. -
  28. -=================================================================
 pktcMtaDevProvUnsolicitedKeyMaxTimeout  OBJECT-TYPE
     SYNTAX      Unsigned32 (0..600)
     UNITS       "seconds"
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         " This object defines the timeout value that applies to
           an MTA-initiated AP-REQ/REP key management exchange with
           the Provisioning Server in SNMPv3 provisioning.
           It is the maximum timeout value, and it may not be exceeded
           in the exponential back-off algorithm.  If the DHCP option

Nechamkin & Mule Standards Track [Page 27] RFC 4682 IPCDN MTA MIB December 2006

           code 122, sub-option 5, is provided to the MTA, it
           overwrites this value.
           In non-secure provisioning modes, the MTA MUST
           return a zero value in response to SNMP GET
           operations."
     REFERENCE
         " PacketCable Security Specification."
     DEFVAL {600}
     ::= { pktcMtaDevServer 15 }
 pktcMtaDevProvUnsolicitedKeyNomTimeout  OBJECT-TYPE
     SYNTAX      Unsigned32 (0..600)
     UNITS       "seconds"
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         " This object defines the starting value of the timeout
           for the AP-REQ/REP Backoff and Retry mechanism
           with exponential timeout in SNMPv3 provisioning.
           If the DHCP option code 122, sub-option 5, is provided
           the MTA, it overwrites this value.
           In non-secure provisioning modes, the MTA MUST
           return a zero value in response to SNMP GET
           operations."
     REFERENCE
         " PacketCable Security Specification."
     DEFVAL {3}
     ::= { pktcMtaDevServer 16}
 pktcMtaDevProvUnsolicitedKeyMaxRetries  OBJECT-TYPE
     SYNTAX      Unsigned32 (0..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 in secure SNMPv3 provisioning.
           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.
           If this object is set to a zero value, the MTA MUST return
           an 'inconsistentValue' in response to SNMP SET operations.
           In non-secure provisioning modes, the MTA MUST
           return a zero value in response to SNMP GET
           operations."
     REFERENCE

Nechamkin & Mule Standards Track [Page 28] RFC 4682 IPCDN MTA MIB December 2006

         " PacketCable Security Specification."
     DEFVAL {8}
     ::= { pktcMtaDevServer 17 }
 pktcMtaDevProvKerbRealmName  OBJECT-TYPE
     SYNTAX      SnmpAdminString (SIZE(1..255))
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         " This object contains the name of the associated
           provisioning Kerberos realm acquired during the MTA4
           provisioning step (DHCP Ack) for SNMPv3 provisioning.
           The uppercase 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.  In secure SNMP provisioning mode,
           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.  Otherwise, the value of this object must
           contain the value supplied in DHCP Option 122,
           sub-option 6."
     REFERENCE
         " PacketCable MTA Device Provisioning Specification;
           RFC 3495, DHCP Option for CableLabs Client Configuration."
     ::= { pktcMtaDevServer 18 }
 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.
              Note that this state is only reported when the MTA

Nechamkin & Mule Standards Track [Page 29] RFC 4682 IPCDN MTA MIB December 2006

              SNMP enrollment mechanism is used.
             'waitingForTftpAddrResponse(3)', the device has sent a
              DNS request to resolve the server providing the
              configuration file, and it is awaiting for a response.
              Note that this state is only reported when the MTA
              SNMP enrollment mechanism is used.
             '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 19 }
  1. -
  2. - The following object group describes the security objects.
  3. -
 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

Nechamkin & Mule Standards Track [Page 30] RFC 4682 IPCDN MTA MIB December 2006

           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.
           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 Key Distribution
           Center (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 }
  1. -=================================================================
  2. -
  3. - Informative Procedures for Setting up Security Associations
  4. -

Nechamkin & Mule Standards Track [Page 31] RFC 4682 IPCDN MTA MIB December 2006

  1. - A Security Association may be set up either via configuration or
  2. - via NCS signaling.
  3. -
  4. - I. Security association setup via configuration.
  5. -
  6. - The realm must be configured first. Associated with the realm
  7. - is a KDC. The realm table (pktcMtaDevRealmTable) indicates
  8. - information about the realm (e.g., name, organization name) and
  9. - parameters associated with KDC communications (e.g., grace
  10. - periods, AS Request/AS Reply adaptive back-off parameters).
  11. -
  12. - Once the realm is established, one or more CMS(es) may be
  13. - defined in the realm. Associated with each CMS
  14. - entry in the pktcMtaDevCmsTable is an explicit reference
  15. - to a Realm via the realm name (pktcMtaDevCmsKerbRealmName),
  16. - the FQDN of the CMS, and parameters associated with IPSec
  17. - key management with the CMS (e.g., clock skew, AP Request/
  18. - AP Reply adaptive back-off parameters).
  19. -
  20. - II. Security association setup via NCS signaling.
  21. -
  22. - The procedure of establishing the Security Associations
  23. - for NCS signaling is described in the PacketCable Security
  24. - specification.
  25. - It involves the analysis of the pktcNcsEndPntConfigTable row
  26. - for the corresponding endpoint number and the correlation of
  27. - the CMS FQDN from this row with the CMS Table and
  28. - consequently, with the Realm Table. Both of these tables
  29. - are defined below. The pktcNcsEndPntConfigTable is defined in
  30. - the IP over Cable Data Network (IPCDN)
  31. - NCS Signaling MIB [NCSSIGMIB].
  32. -
  33. - III. When the MTA receives wake-up or re-key messages from a
  34. - CMS, it performs key management based on the corresponding
  35. - entry in the CMS table. If the matching CMS entry does not
  36. - exist, it must ignore the wake-up or re-key messages.
  37. -
  38. -=================================================================
  39. -=================================================================
  40. -
  41. - pktcMtaDevRealmTable
  42. -
  43. - The pktcMtaDevRealmTable shows the KDC realms. The table is
  44. - indexed with pktcMtaDevRealmIndex. The Realm Table contains the
  45. - pktcMtaDevRealmName in conjunction with any server that needs
  46. - a Security Association with the MTA. Uppercase must be used
  47. - to compare the pktcMtaDevRealmName content.
  48. -

Nechamkin & Mule Standards Track [Page 32] RFC 4682 IPCDN MTA MIB December 2006

  1. -=================================================================
 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.
           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 and the
           Provisioning Server)."
     ::= {  pktcMtaDevSecurity 6 }
 pktcMtaDevRealmEntry  OBJECT-TYPE
     SYNTAX      PktcMtaDevRealmEntry
     MAX-ACCESS  not-accessible
     STATUS      current

Nechamkin & Mule Standards Track [Page 33] RFC 4682 IPCDN MTA MIB December 2006

     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                  LongUtf8String,
     pktcMtaDevRealmUnsolicitedKeyMaxTimeout Unsigned32,
     pktcMtaDevRealmUnsolicitedKeyNomTimeout Unsigned32,
     pktcMtaDevRealmUnsolicitedKeyMaxRetries Unsigned32,
     pktcMtaDevRealmStatus                   RowStatus
     }
 pktcMtaDevRealmIndex  OBJECT-TYPE
     SYNTAX      Unsigned32 (1..64)
     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 uppercase 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

Nechamkin & Mule Standards Track [Page 34] RFC 4682 IPCDN MTA MIB December 2006

          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 according to 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 }
 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      LongUtf8String
     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."
     REFERENCE
         " PacketCable Security Specification;
           RFCs 3280 and 4630, Internet X.509 Public Key
           Infrastructure Certificate and Certificate Revocation List
           (CRL) Profile"
     ::= { pktcMtaDevRealmEntry 5 }

Nechamkin & Mule Standards Track [Page 35] RFC 4682 IPCDN MTA MIB December 2006

 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.

Nechamkin & Mule Standards Track [Page 36] RFC 4682 IPCDN MTA MIB December 2006

           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 }

Nechamkin & Mule Standards Track [Page 37] RFC 4682 IPCDN MTA MIB December 2006

     ::= { 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 }
  1. -=================================================================
  2. -
  3. - The CMS table, pktcMtaDevCmsTable
  4. -
  5. - The CMS table and the realm table (pktcMtaDevRealmTable) are used
  6. - for managing the MTA signaling security. The CMS table defines
  7. - the CMSes the MTA is allowed to communicate with and contains
  8. - the parameters describing the SA establishment between the MTA
  9. - and a CMS.
  10. - The CMS table is indexed by pktcMtaDevCmsIndex. The table
  11. - contains the CMS FQDN (pktcMtaDevCmsFQDN) and the associated
  12. - Kerberos realm name (pktcMtaDevCmsKerbRealmName) so that the MTA
  13. - can find the corresponding Kerberos realm name in the
  14. - pktcMtaDevRealmTable.
  15. -
  16. -=================================================================
 pktcMtaDevCmsAvailSlot   OBJECT-TYPE
     SYNTAX      Unsigned32 (0..128)
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION

Nechamkin & Mule Standards Track [Page 38] RFC 4682 IPCDN MTA MIB December 2006

         " 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 }

Nechamkin & Mule Standards Track [Page 39] RFC 4682 IPCDN MTA MIB December 2006

     ::= { 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

Nechamkin & Mule Standards Track [Page 40] RFC 4682 IPCDN MTA MIB December 2006

           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 }
  1. -=================================================================
  2. -
  3. - Unsolicited key updates are retransmitted according to an
  4. - exponential back-off mechanism using two timers and a maximum
  5. - retry counter for AS replies.
  6. - The initial retransmission timer value is the nominal timer
  7. - value (pktcMtaDevCmsUnsolicitedKeyNomTimeout). The
  8. - retransmissions occur with an exponentially increasing interval
  9. - that caps at the maximum timeout value
  10. - (pktcMtaDevCmsUnsolicitedKeyMaxTimeout).
  11. - Retransmissions stop when the maximum retry counter is reached
  12. - (pktcMatDevCmsUnsolicitedMaxRetries).
  13. - For example, with values of 3 seconds for the nominal
  14. - timer, 20 seconds for the maximum timeout, and 5 retries max,
  15. - retransmission intervals will be 3 s, 6 s, 12 s,

Nechamkin & Mule Standards Track [Page 41] RFC 4682 IPCDN MTA MIB December 2006

  1. - 20 s, and 20 s; retransmissions then stop due to the
  2. - maximum number of retries reached.
  3. -
  4. -=================================================================
 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 }

Nechamkin & Mule Standards Track [Page 42] RFC 4682 IPCDN MTA MIB December 2006

 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

Nechamkin & Mule Standards Track [Page 43] RFC 4682 IPCDN MTA MIB December 2006

           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 }
  1. -
  2. - The following group, pktcMtaDevErrors, defines an OID
  3. - corresponding to error conditions encountered during the MTA
  4. - provisioning.
  5. -
 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

Nechamkin & Mule Standards Track [Page 44] RFC 4682 IPCDN MTA MIB December 2006

     }
     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 }
  1. -
  2. - Compliance Statements
  3. -
 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

Nechamkin & Mule Standards Track [Page 45] RFC 4682 IPCDN MTA MIB December 2006

           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

Nechamkin & Mule Standards Track [Page 46] RFC 4682 IPCDN MTA MIB December 2006

             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.

Nechamkin & Mule Standards Track [Page 47] RFC 4682 IPCDN MTA MIB December 2006

             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,

Nechamkin & Mule Standards Track [Page 48] RFC 4682 IPCDN MTA MIB December 2006

             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 {

Nechamkin & Mule Standards Track [Page 49] RFC 4682 IPCDN MTA MIB December 2006

             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."

Nechamkin & Mule Standards Track [Page 50] RFC 4682 IPCDN MTA MIB December 2006

         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 {

Nechamkin & Mule Standards Track [Page 51] RFC 4682 IPCDN MTA MIB December 2006

             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:
  1. The following objects, if SET maliciously, would cause the MTA

device to reset and/or stop its service:

       pktcMtaDevResetNow.
       pktcMtaDevEnabled.
  1. 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:

Nechamkin & Mule Standards Track [Page 52] RFC 4682 IPCDN MTA MIB December 2006

       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.
  1. 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.

Nechamkin & Mule Standards Track [Page 53] RFC 4682 IPCDN MTA MIB December 2006

  1. 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:
  1. 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.
  1. 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

Nechamkin & Mule Standards Track [Page 54] RFC 4682 IPCDN MTA MIB December 2006

 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.

Nechamkin & Mule Standards Track [Page 55] RFC 4682 IPCDN MTA MIB December 2006

 [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.

Nechamkin & Mule Standards Track [Page 56] RFC 4682 IPCDN MTA MIB December 2006

 [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.

Nechamkin & Mule Standards Track [Page 57] RFC 4682 IPCDN MTA MIB December 2006

 [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.

Nechamkin & Mule Standards Track [Page 58] RFC 4682 IPCDN MTA MIB December 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

Nechamkin & Mule Standards Track [Page 59] RFC 4682 IPCDN MTA MIB December 2006

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.

Nechamkin & Mule Standards Track [Page 60]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4682.txt · Last modified: 2006/12/21 20:15 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki