rfc3083.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,778 行 · 第 1/5 页

Network Working Group                                          R. Woundy
Request for Comments: 3083                                 Cisco Systems
Category: Informational                                       March 2001


         Baseline Privacy Interface Management Information Base
 for DOCSIS Compliant Cable Modems and Cable Modem Termination Systems

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it defines a basic set of managed objects for SNMP-
   based (Simple Network Management Protocol) management of the Baseline
   Privacy Interface (BPI), which provides data privacy for DOCSIS 1.0
   (Data-Over-Cable Service Interface Specifications) compliant Cable
   Modems and Cable Modem Termination Systems.  This MIB is defined as
   an extension to the DOCSIS Radio Frequency Interface MIB, RFC 2670.

   This memo specifies a MIB module in a manner that is compliant to the
   SMIv2 (Structure of Management Information Version 2).  The set of
   objects is consistent with the SNMP framework and existing SNMP
   standards.

   CableLabs requires the implementation of this MIB in DOCSIS 1.0 cable
   modems that implement the Baseline Privacy Interface, as a
   prerequisite for DOCSIS 1.0 certification.














Woundy                       Informational                      [Page 1]

RFC 3083              DOCSIS Baseline Privacy MIB             March 2001


Table of Contents

   1 The SNMP Management Framework ................................... 2
   2 Glossary ........................................................ 3
   2.1 Authorization key ............................................. 3
   2.2 BPI ........................................................... 4
   2.3 BPI+ .......................................................... 4
   2.4 CATV .......................................................... 4
   2.5 CM ............................................................ 4
   2.6 CMTS .......................................................... 4
   2.7 DOCSIS ........................................................ 4
   2.8 Downstream .................................................... 4
   2.9 Head-end ...................................................... 4
   2.10 MAC Packet ................................................... 4
   2.11 MCNS ......................................................... 5
   2.12 RF ........................................................... 5
   2.13 SID .......................................................... 5
   2.14 TEK .......................................................... 5
   2.15 Upstream ..................................................... 5
   3 Overview ........................................................ 5
   3.1 Structure of the MIB .......................................... 5
   3.2 Management requirements ....................................... 6
   3.3 Textual convention ............................................ 7
   4 Definitions ..................................................... 8
   5 Acknowledgments ................................................ 40
   6 References ..................................................... 40
   7 Security Considerations ........................................ 42
   8 Intellectual Property .......................................... 43
   9 Author's Address ............................................... 44
   10 Full Copyright Statement ...................................... 45

1.  The SNMP Management Framework

   The SNMP Management Framework presently consists of five major
   components:

   o  An overall architecture, described in RFC 2571 [1].

   o  Mechanisms for describing and naming objects and events for the
      purpose of management.  The first version of this Structure of
      Management Information (SMI) is called SMIv1 and described in STD
      16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4].  The
      second version, called SMIv2, is described in STD 58, RFC 2578
      [5], RFC 2579 [6] and RFC 2580 [7].

   o  Message protocols for transferring management information.  The
      first version of the SNMP message protocol is called SNMPv1 and
      described in STD 15, RFC 1157 [8].  A second version of the SNMP



Woundy                       Informational                      [Page 2]

RFC 3083              DOCSIS Baseline Privacy MIB             March 2001


      message protocol, which is not an Internet standards track
      protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC
      1906 [10].  The third version of the message protocol is called
      SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and RFC 2574
      [12].

   o  Protocol operations for accessing management information. The
      first set of protocol operations and associated PDU formats is
      described in STD 15, RFC 1157 [8].  A second set of protocol
      operations and associated PDU formats is described in RFC 1905
      [13].

   o  A set of fundamental applications described in RFC 2573 [14] and
      the view-based access control mechanism described in RFC 2575
      [15].

   A more detailed introduction to the current SNMP Management Framework
   can be found in RFC 2570 [24].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  Objects in the MIB are
   defined using the mechanisms defined in the SMI.

   This memo specifies a MIB module that is compliant to the SMIv2.  A
   MIB conforming to the SMIv1 can be produced through the appropriate
   translations.  The resulting translated MIB must be semantically
   equivalent, except where objects or events are omitted because no
   translation is possible (use of Counter64).  Some machine readable
   information in SMIv2 will be converted into textual descriptions in
   SMIv1 during the translation process.  However, this loss of machine
   readable information is not considered to change the semantics of the
   MIB.

2.  Glossary

   The terms in this document are derived either from normal cable
   system usage, or from the documents associated with the Data Over
   Cable Service Interface Specification process.

2.1.  Authorization key

   A key used to derive a key encryption key (used to encrypt TEKs), and
   to derive message authentication keys.  When the CMTS communicates
   the authorization key to the CM, it encrypts the authorization key
   using the RSA public key of the CM [22].






Woundy                       Informational                      [Page 3]

RFC 3083              DOCSIS Baseline Privacy MIB             March 2001


2.2.  BPI - Baseline Privacy Interface

   A term referring to the DOCSIS specification [18] for enabling simple
   data privacy in the DOCSIS 1.0 system.  Management of the BPI is the
   focus of this document.

2.3.  BPI+ - Baseline Privacy Plus Interface

   A term referring to the DOCSIS specification [21] for enabling CM
   authentication and data privacy in the DOCSIS 1.1 system.  Management
   of the BPI+ is not addressed in this document.

2.4.  CATV

   Originally "Community Antenna Television", now used to refer to any
   cable or hybrid fiber and cable system used to deliver video signals
   to a community.

2.5.  CM - Cable Modem

   A CM acts as a "slave" station in a DOCSIS compliant cable data
   system.

2.6.  CMTS - Cable Modem Termination System

   A generic term covering a cable bridge or cable router in a head-end.
   A CMTS acts as the master station in a DOCSIS compliant cable data
   system.  It is the only station that transmits downstream, and it
   controls the scheduling of upstream transmissions by its associated
   CMs.

2.7.  DOCSIS

   "Data-Over-Cable Service Interface Specifications".  A term referring
   to the ITU-T J.112 Annex B standard for cable modem systems [19].

2.8.  Downstream

   The direction from the head-end towards the subscriber.

2.9.  Head-end

   The origination point in most cable systems of the subscriber video
   signals.  Generally also the location of the CMTS equipment.

2.10.  MAC Packet

   A DOCSIS PDU.



Woundy                       Informational                      [Page 4]

RFC 3083              DOCSIS Baseline Privacy MIB             March 2001


2.11.  MCNS

   "Multimedia Cable Network System".  Generally replaced in usage by
   DOCSIS.

2.12.  RF

   Radio Frequency.

2.13  SID

   Service ID.  The SID identifies a particular upstream bandwidth
   allocation and class-of-service management for DOCSIS, and identifies
   a particular bidirectional security association for BPI.

2.14.  TEK - Traffic Encryption Key

   Traffic Encryption Key, which is used for DES encryption of upstream
   and downstream traffic.  When the CMTS communicates the TEK to the
   CM, it encrypts the TEK using the key encryption key derived from the
   authorization key.

2.15.  Upstream

   The direction from the subscriber towards the head-end.

3.  Overview

   This MIB provides a set of objects required for the management of the
   Baseline Privacy Interface for DOCSIS compliant Cable Modems (CMs)
   and Cable Modem Termination Systems (CMTSs).  This MIB specification
   is derived from the DOCSIS Baseline Privacy Interface specification
   [18], which is an extension to the DOCSIS Radio Frequency Interface
   specification [19].

   Please note that this MIB specification is not sufficient for the
   management of the DOCSIS Baseline Privacy Plus Interface
   specification [21].  The working group expects to issue a MIB for the
   management of BPI+ at a later time.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [23].

3.1.  Structure of the MIB

   This MIB consists of one group of CM-only objects (docsBpiCmGroup),
   and one group of CMTS-only objects (docsBpiCmtsGroup).



Woundy                       Informational                      [Page 5]

RFC 3083              DOCSIS Baseline Privacy MIB             March 2001


   The CM-only objects are organized into two tables:

   o  The docsBpiCmBaseTable contains objects for managing basic
      Baseline Privacy parameters and counters, and for managing the
      Authorization finite state machine.

   o  The docsBpiCmTEKTable contains objects for managing the Traffic
      Encryption Key (TEK) finite state machine per SID.

   The CMTS-only objects are organized into four sub-groups:

   o  The docsBpiCmtsBaseTable contains objects for managing basic
      Baseline Privacy parameters and counters.

   o  The docsBpiCmtsAuthTable contains objects for managing the
      Authorization association information per cable modem.

   o  The docsBpiCmtsTEKTable contains objects for managing the TEK
      association information per SID.

   o  The docsBpiMulticastControl consists of two tables.  The
      docsBpiIpMulticastMapTable controls the mapping of downstream IP
      multicast data traffic to downstream multicast SID values.  The
      docsBpiMulticastAuthTable controls which CMs are authorized to
      receive downstream traffic transmitted over particular multicast
      SIDs; a CM will receive TEKs corresponding to the multicast SIDs
      for which it is authorized.  The combination of these two tables
      will limit the distribution of downstream IP multicast data
      traffic to authorized CMs.

3.2.  Management requirements

   The Baseline Privacy Interface specification is documented in [18],
   and is an extension to the Radio Frequency Interface specification
   documented in [19].  In addition to the explicit requirements in this
   specification, the CM and CMTS enabled for Baseline Privacy MUST
   support all applicable DOCSIS and IETF requirements and MIB objects.
   Specifications that identify relevant requirements and MIB objects
   include the IETF Radio Frequency MIB [16], the IETF Cable Device MIB
   [17], and the DOCSIS OSSI Specification [20].

   The explicit management requirements of the Baseline Privacy
   Interface, which motivate the development of the MIB in this
   document, are detailed below:

   o  The CM and CMTS MUST support viewing relevant RSA public keys, for
      future subscriber authentication applications.




Woundy                       Informational                      [Page 6]

RFC 3083              DOCSIS Baseline Privacy MIB             March 2001


   o  The Baseline Privacy management interface needs to support
      operator configuration of Authorization and TEK Finite State
      Machine (FSM) parameters, for performance tuning and security
      incident handling.  The CMTS MUST support viewing (and configuring
      if possible) all FSM-related parameters, including baseline
      privacy status (enabled or disabled), key lifetimes, key grace
      times, and state timeout values.  The CM MUST support viewing
      these parameters where possible.

   o  The management interface needs to support operator analysis and
      override of FSM behavior, for fault management, subscriber service
      de-provisioning, and security incident handling.  The CM MUST
      support viewing the current FSM states.  The CM and CMTS MUST
      support viewing message error codes and message error strings, and