INTERNET-DRAFT      DOCSIS Subscriber Management MIB       November 2002

                      Management Information Base
      for Data Over Cable Service Interface Specification (DOCSIS)
                    Cable Modem Termination Systems
                       for Subscriber Management
                 draft-ietf-ipcdn-subscriber-mib-07.txt

                      Fri Nov 01 11:00:00 EST 2002


                             Wilson Sawyer
                                 ARRIS
                            wsawyer@ieee.org




                          Status of this Memo

           This document is an Internet-Draft and is subject to
   all provisions of Section 10 of RFC2026.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at:
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at:
   http://www.ietf.org/shadow.html.

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 set of managed objects for SNMP-based
   management of Data-over-Cable Service Interface Specification
   (DOCSIS)-compliant Cable Modem Termination Systems. These managed
   objects facilitate protection of the cable network from misuse by
   subscribers.

   This memo is a product of the IPCDN working group within the Internet
   Engineering Task Force.  Comments are solicited and should be
   addressed to the working group's mailing list at ipcdn@ietf.org
   and/or the author.




Expires  May 2003                                              [Page 1]


INTERNET-DRAFT      DOCSIS Subscriber Management MIB       November 2002

Table of Contents

1. The SNMP Network Management Framework..............................2
2. Overview...........................................................3
2.1. Structure of the MIB.............................................4
2.2. Management requirements..........................................4
2.2.1. Interaction with DOCSIS provisioning for CPE address control...5
2.2.2. Interaction with DOCSIS provisioning for filtering.............5
2.2.3. Distinguishing Modem from Subscriber Traffic...................6
2.2.4. Row Existence of docsSubMgtTcpUdpFilterTable...................6
2.2.5. Filtering and the Tiny Fragment Attack.........................7
3. Definitions........................................................7
4. Acknowledgments...................................................24
5. Normative References..............................................24
6. Informative References............................................26
7. Security Considerations...........................................26
8. Author's Address..................................................28
9. Intellectual Property.............................................28
10. Full Copyright Statement.........................................28

1. The SNMP Network Management Framework

   The SNMP Management Framework presently consists of five major
   components:

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

   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 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215
       [RFC1215]. The second version, called SMIv2, is described in
       STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and
       STD 58, RFC 2580 [RFC2580].

   o   Message protocols for transferring management information. The
       first version of the SNMP message protocol is called SNMPv1 and
       described in RFC 1157 [RFC1157]. A second version of the SNMP
       message protocol, which is not an Internet standards track
       protocol, is called SNMPv2c and described in RFC 1901 [RFC1901]
       and RFC 1906 [RFC1906]. The third version of the message protocol
       is called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572
       [RFC2572] and RFC 2574 [RFC2574].

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

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

Expires  May 2003                                              [Page 2]


INTERNET-DRAFT      DOCSIS Subscriber Management MIB       November 2002

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

   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
   [RFC2578][RFC2579][RFC2580]. 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. Overview

   This MIB provides a set of objects required for the management of
   DOCSIS Cable Modem Termination Systems (CMTS). The specification is
   derived in part from the operational model described in the DOCSIS
   Radio Frequency Interface Specification [DOCSRFI]. These managed
   objects facilitate protection of the cable network from misuse by
   subscribers.

   The following figure illustrates the operational and physical
   deployment relationships between elements in a cable modem network.
   This MIB resides at the CMTS, which is the first point in the public
   data network at which the cable operator controls physical access.
   The CMTS (possibly assisted by other IP services devices) acts as a
   network edge, separating the physical outside-plant cable television
   network from the operator's IP network.


                    |              operator's IP network
                 +------+          ---------------------
                 | CMTS |          operator's cable head-end
                 +------+          ---------------------
                    |
           +--------+--------+     CATV physical network
           |        |        |
         +----+   +----+   +----+  ------------------
         | CM |   | CM |   | CM |  subscriber premises
         +----+   +----+   +----+  ------------------
           |        |        |     subscriber host or network


   This MIB controls IP packet forwarding to and from each cable modem,
   at the CMTS. Different modems may be accorded different treatment.

   Much of this MIB duplicates capabilities found in the DOCSIS Cable
   Device MIB [RFC2669]. While it is expected that the Cable Device MIB

Expires  May 2003                                              [Page 3]


INTERNET-DRAFT      DOCSIS Subscriber Management MIB       November 2002

   will be used to prevent unwanted traffic from entering the cable
   network, it is also possible that a malicious user might tamper with
   cable modem software, disabling its filtering policies. This MIB
   provides a more secure mechanism, since physical access to the CMTS
   is controlled by the network operator.

   In particular, this MIB provides two capabilities: first, to limit
   the IP addresses behind a modem, and, second, to provide protocol
   filtering to and from a modem. The first duplicates the capabilities
   of the docsDevCpe group [RFC2669]. This provides for either learned
   or provisioned subscriber premises host IP addresses behind a cable
   modem.

   The filtering capability is similar to that provided in docsDevFilter
   [RFC2669].  Rather than maintaining a separate list of filters for
   each modem at the CMTS, however, it is assumed that large numbers of
   modems will share filtering characteristics. Therefore, modems are
   grouped so as to share common filter lists.

2.1. Structure of the MIB

   This MIB is structured in five tables:

   o    The docsSubMgtCpeControlTable controls the acceptance of
        subscriber host addresses behind a cable modem.

   o    The docsSubMgtCpeIpTable monitors the subscriber host addresses
        which the CMTS believes to exist behind the cable modem.

   o    The docsSubMgtPktFilterTable specifies filtering criteria which
        can be applied to packets destined to or originating from a
        cable modem.

   o    The docsSubMgtTcpUdpFilterTable augments
        docsSubMgtPktFilterTable with optional TCP or UDP port filtering
        criteria.

   o    The docsSubMgtCmFilterTable binds a cable modem to an ordered
        list of filters from docsSubMgtPktFilterTable.

   The docsSubMgtCpeControlTable, docsSubMgtCpeIpTable, and
   docsSubMgtCmFilterTable augment the docsIfCmtsCmStatusTable from
   [RFC2670].  As such, each entry in these tables is bound to a
   registered cable modem, as perceived by the CMTS.

   The docsSubMgtPktFilterTable uses two indices. The first identifies
   the group to which a cable modem may be bound. The second is the
   ordering of filter criteria within each group. Any number of modems
   may be bound to the same group.

2.2. Management requirements

   The DOCSIS cable modem provisioning model [DOCSRFI] requires that

Expires  May 2003                                              [Page 4]


INTERNET-DRAFT      DOCSIS Subscriber Management MIB       November 2002

   cable modems use TFTP to acquire a list of parameters. The modem then
   passes many of these parameters to the CMTS in the DOCSIS
   Registration message. The parameter values are digitally signed by
   the creator of the TFTP contents, and the signature is verified by
   the CMTS. In general, then, the CMTS need not itself be configured
   with the attributes of its cable modems. It will acquire these values
   through the Registration process that is secured by the digital
   signature.

   Cable modem subscriber management, as described here, modifies this
   process slightly for reasons of data reduction and ease of
   administrative control.  In the case of filtering management, for
   example, the tables are maintained through SNMP at the CMTS, and the
   modem registration merely signals the index values for the rows that
   apply to that modem.

2.2.1. Interaction with DOCSIS provisioning for CPE address control

   Rows in docsSubMgtCpeControlTable are created by the CMTS for each
   modem as a result of the DOCSIS registration process. The DOCSIS
   registration attributes may include items semantically equivalent to
   those in the DocsDevCpe branch of the DOCSIS Cable Device MIB
   [RFC2669]:

   o    docsDevCpeEnroll
   o    docsDevCpeIpMax
   o    docsDevCpeIp

   Successful DOCSIS registration shall have the effect of setting the
   corresponding fields in the docsSubMgtCpeControlTable and the
   docsSubMgtCpeIpTable. If not present, the default at registration
   shall be to set docsSubMgtCpeControlActive to false.

   Rows in docsSubMgtCpeIpTable are created through any of three ways:
   DOCSIS registration (as described above), learning by the CMTS, or
   through some unspecified administrative mechanism on the CMTS. The
   docsDevCpeIpMax table bound applies only to the first two.

   The CMTS may learn addresses by simply snooping source IP addresses
   from each cable modem. Other learning mechanisms (for example, ARP
   snooping) may be used. The learning mechanism is not defined by this
   document.

2.2.2. Interaction with DOCSIS provisioning for filtering

   Rows in docsSubMgtCmFilterTable are created by the CMTS for each
   modem as a result of the DOCSIS registration process. The DOCSIS
   registration attributes may include four indices:

   o   one identifying the upstream filter group for packets
       originating from the cable modem (i.e., those packets whose
       source MAC address matches that of the cable modem).
   o   one identifying the upstream filter group for packets

Expires  May 2003                                              [Page 5]


INTERNET-DRAFT      DOCSIS Subscriber Management MIB       November 2002

       originating from subscribers attached to the cable modem (i.e.,
       those packets whose source MAC address does not match that of
       the cable modem).
   o   one identifying the downstream filter group for packets
       destined to the cable modem (i.e., those packets whose
       destination MAC address matches that of the cable modem).
   o   one identifying the downstream filter group for packets
       destined to subscribers attached to the cable modem (i.e.,
       those packets whose destination MAC address does not match
       that of the cable modem).

   Successful registration shall have the effect of setting
   docsSubMgtCmFilterDownstream, docsSubMgtCmFilterUpstream,
   docsSubMgtSubFilterDownstream, and docsSubMgtSubFilterUpstream, for
   that modem (just as if set through the SNMP protocol). If the DOCSIS
   attributes are not present, the effect shall be to set the modem's
   filter groups to the values of docsSubMgtCmFilterUpDefault,
   docsSubMgtCmFilterDownDefault, docsSubMgtSubFilterUpDefault, and
   docsSubMgtSubFilterDownDefault.

2.2.3. Distinguishing Modem from Subscriber Traffic

   All traffic originating from or destined to a subscriber site is
   potentially suspect, and subject to suppression by the network
   operator.  This is true even if the traffic is ostensibly sourced or
   sunk by the cable modem itself, rather than the subscriber hosts
   behind the modem. To provide more nuanced administrative control,
   this document allows separate filter policies for modems and hosts.
   For example, modem policies may limit modems to server-subnet-only
   access, while allowing a different scope to subscribers.

   The CMTS chooses the filter set to apply based solely on the MAC
   address (source MAC upstream, destination MAC downstream). If the MAC
   address matches that of the modem, then the
   docsSubMgtCmFilterUp/Downstream pair is used; otherwise the
   docsSubMgtSubFilterUp/Downstream pair is applied.

   If the CM acts as a router rather than as a DOCSIS bridging
   forwarder, then the network operator will only use the
   docsSubMgtCmFilterUp/Downstream pair.

2.2.4. Row Existence of docsSubMgtTcpUdpFilterTable

   The docsSubMgtTcpUdpFilterTable exists apart from the
   docsSubMgtPktFilterTable because its filtering criteria is expected
   to be applied to a minority of modems relative to
   docsSubMgtPktFilterTable. It is separate in order to emphasize this
   expectation to both CMTS vendors and network operators. The rules for
   row creation are:

   o    Row creation in docsSubMgtTcpUdpFilterTable is disallowed unless
        the corresponding row in docsSubMgtPktFilterTable already
        exists (or that row is being created simultaneously in the same

Expires  May 2003                                              [Page 6]


INTERNET-DRAFT      DOCSIS Subscriber Management MIB       November 2002

        SNMP SET message).

   o    Deletion of the row in docsSubMgtPktFilterTable deletes the
        corresponding row in docsSubMgtTcpUdpFilterTable.

   o    Row creation for docsSubMgtPktFilterTable does not create the
        corresponding row in docsSubMgtTcpUdpFilterTable.

   o    Row deletion of docsSubMgtTcpUdpFilterTable does not delete the
        corresponding row in docsSubMgtPktFilterTable.

2.2.5. Filtering and the Tiny Fragment Attack

   It is recommended that the implementers prevent the "tiny fragment"
   and "overlapping fragment" attacks for the TCP filtering tables in
   this MIB, as discussed in RFC 1858 [RFC1858] and RFC 3128 [RFC2138].

   Prevention of these attacks can be implemented with the following
   rules, when filtering is enabled:

   o    admit all packets with fragment offset >= 2

   o    discard all packets with fragment offset = 1, or with fragment
        offset = 0 AND fragment payload length < 16.

   o    apply filtering rules to all packets with fragment offset = 0.

3. Definitions

   DOCS-SUBMGT-MIB  DEFINITIONS ::= BEGIN

   IMPORTS
           MODULE-IDENTITY,
           OBJECT-TYPE,
           Counter32,
           Integer32,
           mib-2
           -- , BITS
                   FROM SNMPv2-SMI
           RowStatus,
           TruthValue,
           StorageType
                   FROM SNMPv2-TC
           OBJECT-GROUP,
           MODULE-COMPLIANCE
                   FROM SNMPv2-CONF
           InetAddressType,
           InetAddress,
           InetAddressPrefixLength,
           InetPortNumber
                   FROM INET-ADDRESS-MIB
           docsIfCmtsCmStatusIndex,
           docsIfCmtsCmStatusEntry

Expires  May 2003                                              [Page 7]


INTERNET-DRAFT      DOCSIS Subscriber Management MIB       November 2002

                   FROM DOCS-IF-MIB;  -- RFC2670

   docsSubMgt MODULE-IDENTITY
           LAST-UPDATED    "200211010000Z" -- November 1, 2002
           ORGANIZATION    "IETF IPCDN Working Group"
           CONTACT-INFO
               "        Wilson Sawyer
                Postal: ARRIS
                        6 Riverside Drive
                        Andover, MA 01810
                        U.S.A.
                Phone:  +1 978 946 4711
                E-mail: wsawyer@ieee.org

                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-chairs: Richard Woundy, rwoundy@broadband.att.com
                           Jean-Francois Mule, jf.mule@cablelabs.com"
           DESCRIPTION
               "This is the CMTS centric subscriber management MIB for
           DOCSIS compliant CMTS."
        REVISION "200211010000Z" -- November 1, 2002
           DESCRIPTION
              "Initial version, published as RFC xxxx."
              -- RFC editor to assign xxxx
           ::= { mib-2 xx }   -- xx to be assigned by IANA


   docsSubMgtObjects OBJECT IDENTIFIER ::= { docsSubMgt 1 }

   docsSubMgtCpeControlTable OBJECT-TYPE
       SYNTAX  SEQUENCE OF DocsSubMgtCpeControlEntry
       MAX-ACCESS not-accessible
       STATUS  current
       DESCRIPTION
           "This table AUGMENTs the docsIfCmtsCmStatusTable and adds
       four WRITEable objects which reflect the state of subscriber
       management on a particular CM."
       ::= { docsSubMgtObjects 1 }

   docsSubMgtCpeControlEntry OBJECT-TYPE
       SYNTAX  DocsSubMgtCpeControlEntry
       MAX-ACCESS not-accessible
       STATUS  current
       DESCRIPTION
           "A row in the docsSubMgtCpeControlTable.  All values are set
       at successful modem registration, either from the system default,
       or from objects included in the DOCSIS registration request sent
       upstream to the CMTS from the CM. The contents of this entry are
       meaningless unless the corresponding docsIfCmtsCmStatusValue is
       registrationComplete(6). The persistence of this row is

Expires  May 2003                                              [Page 8]


INTERNET-DRAFT      DOCSIS Subscriber Management MIB       November 2002

       determined solely by the lifespan of the corresponding
       docsIfCmtsCmStatusEntry (normally StorageType=volatile)."
       AUGMENTS { docsIfCmtsCmStatusEntry }
       ::= {docsSubMgtCpeControlTable 1 }

   DocsSubMgtCpeControlEntry ::= SEQUENCE
       {
       docsSubMgtCpeControlMaxCpeIp        Integer32,
       docsSubMgtCpeControlActive          TruthValue,
       docsSubMgtCpeControlLearnable       TruthValue,
       docsSubMgtCpeControlReset           TruthValue
       }

   docsSubMgtCpeControlMaxCpeIp OBJECT-TYPE
       SYNTAX  Integer32(0..2147483647)
       MAX-ACCESS read-write
       STATUS  current
       DESCRIPTION
           "The number of simultaneous IP addresses permitted behind
       the CM. If this is set to zero, all CPE traffic from the CM is
       dropped.  If the provisioning object corresponding to
       docsSubMgtCpeIpTable includes more CPE IP address entries for
       this modem than the value of this object, then this object is
       set to the count of the number of rows in docsSubMgtCpeIpTable
       that have the same docsIfCmtsCmStatusIndex value. (E.g. if the
       CM has 5 IP addresses specified for it, this value is 5). This
       limit applies to learned and docsis-provisioned entries, but
       does not limit entries added through some administrative
       process at the CMTS. If not set through DOCSIS provisioning,
       this object defaults to docsSubMgtCpeMaxIpDefault. Note that
       this object is only meaningful if docsSubMgtCpeControlActive
       is true."
       ::= { docsSubMgtCpeControlEntry 1 }

   docsSubMgtCpeControlActive OBJECT-TYPE
       SYNTAX  TruthValue
       MAX-ACCESS read-write
       STATUS  current
       DESCRIPTION
           "If this is set to true, CMTS based CPE control is active and
       all the actions required by the various filter tables and
       controls apply at the CMTS.  If this is set to false, no
       subscriber management filtering is done at the CMTS (but other
       filters may apply). If not set through DOCSIS provisioning,
       this object defaults to docsSubMgtCpeActiveDefault."
       ::= { docsSubMgtCpeControlEntry 2 }

   docsSubMgtCpeControlLearnable OBJECT-TYPE
       SYNTAX  TruthValue
       MAX-ACCESS read-write
       STATUS  current
       DESCRIPTION
           "If this is set to true, the CMTS may learn up to

Expires  May 2003                                              [Page 9]


INTERNET-DRAFT      DOCSIS Subscriber Management MIB       November 2002

       docsSubMgtMaxCpeIp addresses (less any DOCSIS-provisioned
       entries) related to this CM.  Those IP addresses are added (by
       internal process) to the docsSubMgtCpeIpTable. The nature of the
       learning mechanism is not specified here. If not set through
       DOCSIS provisioning, this object defaults to
       docsSubMgtCpeLearnableDefault. Note that this object is only
       meaningful if docsSubMgtCpeControlActive is true."
       ::= { docsSubMgtCpeControlEntry 3 }

   docsSubMgtCpeControlReset OBJECT-TYPE
       SYNTAX  TruthValue
       MAX-ACCESS read-write
       STATUS  current
       DESCRIPTION
           "This object always returns false on read.  If this object is
       set to true, the rows with  'learned' addresses in
       docsSubMgtCpeIpTable for this CM are deleted from that table."
       ::= { docsSubMgtCpeControlEntry 4 }

   docsSubMgtCpeMaxIpDefault OBJECT-TYPE
       SYNTAX  Integer32(0..2147483647)
       MAX-ACCESS read-write
       STATUS  current
       DESCRIPTION
           "The default value for docsSubMgtCpeControlMaxCpeIp if not
       signaled in the DOCSIS Registration request. Upon initial CMTS
       initialization, this defaults to 16."
       ::= { docsSubMgtObjects 2 }

   docsSubMgtCpeActiveDefault OBJECT-TYPE
       SYNTAX  TruthValue
       MAX-ACCESS read-write
       STATUS  current
       DESCRIPTION
           "The default value for docsSubMgtCpeControlActive if not
       signaled in the DOCSIS Registration request. Upon initial CMTS
       initialization, this defaults to false."
       ::= { docsSubMgtObjects 3 }

   docsSubMgtCpeLearnableDefault OBJECT-TYPE
       SYNTAX  TruthValue
       MAX-ACCESS read-write
       STATUS  current
       DESCRIPTION
           "The default value for docsSubMgtCpeControlLearnable if not
       signaled in the DOCSIS Registration request. Upon initial CMTS
       initialization, this defaults to true."
       ::= { docsSubMgtObjects 4 }

   docsSubMgtCpeIpTable OBJECT-TYPE
       SYNTAX      SEQUENCE OF DocsSubMgtCpeIpEntry
       MAX-ACCESS  not-accessible
       STATUS      current

Expires  May 2003                                             [Page 10]


INTERNET-DRAFT      DOCSIS Subscriber Management MIB       November 2002

       DESCRIPTION
           "A table of CPE IP addresses known on a per CM basis."
       ::= { docsSubMgtObjects 5 }

   docsSubMgtCpeIpEntry OBJECT-TYPE
       SYNTAX      DocsSubMgtCpeIpEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "An entry in the docsSubMgtCpeIpTable.  The first index is
       the specific modem we're referring to, the second index is the
       specific CPE IP entry."
       INDEX   { docsIfCmtsCmStatusIndex,
                 docsSubMgtCpeIpIndex }
       ::= {docsSubMgtCpeIpTable 1 }

   DocsSubMgtCpeIpEntry ::= SEQUENCE
       {
       docsSubMgtCpeIpIndex        Integer32,
       docsSubMgtCpeIpAddressType  InetAddressType,
       docsSubMgtCpeIpAddr         InetAddress,
       docsSubMgtCpeIpLearned      TruthValue
       }


   docsSubMgtCpeIpIndex OBJECT-TYPE
       SYNTAX      Integer32(1..2147483647)
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "The index of this CPE IP address relative to the indexed CM.
       An entry is created either through the included CPE IP addresses
       in the provisioning object, or via learning.  If a CMTS receives
       an IP packet from a CM that contains a source IP address which
       does not match one of the docsSubMgtCpeIpAddr entries for this
       CM, one of two things occurs.  If the number of entries is less
       than docsSubMgtCpeControlMaxCpeIp, the source address is added to
       the table and the packet is forwarded.  If the number of entries
       equals the docsSubMgtCpeControlMaxCpeIp, AND
       docsSubMgtCpeControlActive is true, then the packet is dropped.
       Otherwise the packet is forwarded. "
       ::= { docsSubMgtCpeIpEntry 1 }

   docsSubMgtCpeIpAddressType OBJECT-TYPE
       SYNTAX      InetAddressType
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The type of internet address of docsSubMgtCpeIpAddr."
       ::= { docsSubMgtCpeIpEntry 2 }

   docsSubMgtCpeIpAddr OBJECT-TYPE
       SYNTAX      InetAddress

Expires  May 2003                                             [Page 11]


INTERNET-DRAFT      DOCSIS Subscriber Management MIB       November 2002

       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The IP address either set from provisioning or learned via
       address gleaning or other forwarding means. See
       docsSubMgtCpeIpIndex for the mechanism."
       ::= { docsSubMgtCpeIpEntry 3 }

   docsSubMgtCpeIpLearned OBJECT-TYPE
       SYNTAX  TruthValue
       MAX-ACCESS read-only
       STATUS  current
       DESCRIPTION
           "If true, this entry was learned from IP packets sent
       upstream rather than from the provisioning objects."
       ::= { docsSubMgtCpeIpEntry 4 }


   -- The generic packet filter table.  Note that this just defines the
   -- match criteria.  The docsSubMgtCmFilterTable links this table to
   -- the specific modems.

   docsSubMgtPktFilterTable OBJECT-TYPE
       SYNTAX      SEQUENCE OF DocsSubMgtPktFilterEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "A table of filter or classifier criteria. Classifiers are
       assigned by group to the individual CMs.  That assignment is made
       via the configuration objects sent upstream from the CM to the
       CMTS during registration."
       ::= { docsSubMgtObjects 6 }

   docsSubMgtPktFilterEntry OBJECT-TYPE
       SYNTAX      DocsSubMgtPktFilterEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "An entry in the docsSubMgtPktFilterTable."
       INDEX   { docsSubMgtPktFilterGroup,
                 docsSubMgtPktFilterIndex }
       ::= {docsSubMgtPktFilterTable 1 }

   DocsSubMgtPktFilterEntry ::= SEQUENCE
       {
       docsSubMgtPktFilterGroup        Integer32,
       docsSubMgtPktFilterIndex        Integer32,
       docsSubMgtPktFilterAddrType     InetAddressType,
       docsSubMgtPktFilterSrcAddr      InetAddress,
       docsSubMgtPktFilterSrcMask      InetAddressPrefixLength,
       docsSubMgtPktFilterDstAddr      InetAddress,
       docsSubMgtPktFilterDstMask      InetAddressPrefixLength,
       docsSubMgtPktFilterUlp          Integer32,

Expires  May 2003                                             [Page 12]


INTERNET-DRAFT      DOCSIS Subscriber Management MIB       November 2002

       docsSubMgtPktFilterTosValue     OCTET STRING,
       docsSubMgtPktFilterTosMask      OCTET STRING,
       docsSubMgtPktFilterAction       INTEGER,
       docsSubMgtPktFilterMatches      Counter32,
       docsSubMgtPktFilterStatus       RowStatus,
       docsSubMgtPktFilterStorageType  StorageType
       }

   docsSubMgtPktFilterGroup OBJECT-TYPE
       SYNTAX      Integer32(1..2147483647)
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "Identifies an ordered group of filters. Each modem may be
       associated with a filter group for its upstream traffic
       (docsSubMgtCmFilterUpstream) and a filter group for its
       downstream traffic (docsSubMgtCmFilterDownstream). Typically,
       many modems will use the same filter group."
       ::= { docsSubMgtPktFilterEntry 1 }

   docsSubMgtPktFilterIndex OBJECT-TYPE
       SYNTAX      Integer32(1..2147483647)
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "An index which describes the ordering of a set of filter
       specifications within the group.  Filters are applied in index
       order."
       ::= { docsSubMgtPktFilterEntry 2 }

   docsSubMgtPktFilterAddrType OBJECT-TYPE
       SYNTAX      InetAddressType
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The type of internet address of docsSubMgtPktFilterSrcAddr,
       docsSubMgtPktFilterSrcMask, docsSubMgtPktFilterDstAddr, and
       docsSubMgtPktFilterDstMask."
       DEFVAL { ipv4 }
       ::= { docsSubMgtPktFilterEntry 3 }

   docsSubMgtPktFilterSrcAddr OBJECT-TYPE
       SYNTAX      InetAddress
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The source IP address to match in the packet to be
       classified.  By default, this is the all-zero's IP v4 and v6
       address. A packet matches the SrcAddr filter if the following is
       true:
            AND (FilterSrcAddr, FilterSrcMask) ==
            AND (Packet SrcAddr, FilterSrcMask).
       The mask value is applied to both the match value in this table

Expires  May 2003                                             [Page 13]


INTERNET-DRAFT      DOCSIS Subscriber Management MIB       November 2002

       and to the packet IP address. The address type of this object is
       specified by docsSubMgtPktFilterAddrType."
       DEFVAL { '0400000000'H }    -- 0.0.0.0
       ::= { docsSubMgtPktFilterEntry 4 }

   docsSubMgtPktFilterSrcMask OBJECT-TYPE
       SYNTAX      InetAddressPrefixLength
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "Specifies the number of leftmost 1's bits in an address
       bit mask. The bit mask that is applied to the source address
       prior to matching. This, taken with the SrcAddr specifies a
       matching criteria.  By default, the pair specifies a filter
       which matches all source addresses. The address type of this
       object is specified by docsSubMgtPktFilterAddrType."
       DEFVAL { 0  }
       ::= { docsSubMgtPktFilterEntry 5 }

   docsSubMgtPktFilterDstAddr OBJECT-TYPE
       SYNTAX      InetAddress
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The destination IP address to match in the packet to be
       classified.  By default, this is the all-zero's IP v4 and v6
       address. A packet matches the DstAddr filter if the following is
       true:
            AND (FilterDstAddr, FilterDstMask) ==
            AND (Packet DstAddr, FilterDstMask).
       The mask value is applied to both the match value in this table
       and to the packet IP address. The address type of this object is
       specified by docsSubMgtPktFilterAddrType."
       DEFVAL { '0400000000'H }    -- 0.0.0.0
       ::= { docsSubMgtPktFilterEntry 6 }

   docsSubMgtPktFilterDstMask OBJECT-TYPE
       SYNTAX      InetAddressPrefixLength
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "Specifies the number of leftmost 1's bits in an address
       bit mask. The bit mask that is applied to the destination
       address prior to matching. This, taken with the DstAddr specifies
       a matching criteria.  By default, the pair specifies a filter
       which matches all destination addresses. The address type of this
       object is specified by docsSubMgtPktFilterAddrType."
       DEFVAL { 0  }
       ::= { docsSubMgtPktFilterEntry 7 }

   docsSubMgtPktFilterUlp OBJECT-TYPE
       SYNTAX      Integer32 (0..256)
       MAX-ACCESS  read-create

Expires  May 2003                                             [Page 14]


INTERNET-DRAFT      DOCSIS Subscriber Management MIB       November 2002

       STATUS      current
       DESCRIPTION
           "Upper level protocol to match.  If this value is 256,
       matches ALL ULP values.  Otherwise, this matches the specific
       protocol value.  Note that if the packet ULP is either 6 (tcp) or
       17 (udp), then docsSubMgtPktTcpUdpFilterTable must also be
       consulted (if its entry exists) to see if this entry matches.
       If this value is neither tcp(6) nor udp(17), then that
       table is not consulted."
       DEFVAL { 256 }
       ::= { docsSubMgtPktFilterEntry 8 }

   docsSubMgtPktFilterTosValue OBJECT-TYPE
       SYNTAX      OCTET STRING (SIZE(1))
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The TOS value to match in the IP packet."
       DEFVAL { '00'h }
       ::= { docsSubMgtPktFilterEntry 9 }

   docsSubMgtPktFilterTosMask OBJECT-TYPE
       SYNTAX      OCTET STRING(SIZE(1))
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The mask to apply against the TOS value to be matched in the
       IP packet.  The default for both these objects taken together
       matches all TOS values. A packet matches this filter if the
       following is true:
           AND (FilterTosValue, FilterTosMask) ==
           AND (Packet TOS Value, FilterTosMask)."
       DEFVAL { '00'h }
       ::= { docsSubMgtPktFilterEntry 10 }

   docsSubMgtPktFilterAction OBJECT-TYPE
       SYNTAX      INTEGER
                      {
                      accept(1),
                      drop(2)
                      }
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The action to take upon this filter matching.  Accept means
       to end filter matching and to accept the packet for further
       processing. Drop means to drop the packet."
       DEFVAL { accept }
       ::= { docsSubMgtPktFilterEntry 11 }

   docsSubMgtPktFilterMatches OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only

Expires  May 2003                                             [Page 15]


INTERNET-DRAFT      DOCSIS Subscriber Management MIB       November 2002

       STATUS      current
       DESCRIPTION
           "This object counts the number of times this specific rule
       has been matched.  This is incremented any time this rule is
       encountered and all components match. It is only incremented for
       the first (lowest-indexed) filter matching a packet."
       ::= { docsSubMgtPktFilterEntry 12 }

   docsSubMgtPktFilterStatus OBJECT-TYPE
       SYNTAX      RowStatus
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "Standard rowStatus object for creating this row.  Any object
       in this row which is writable may be changed at any time while
       the row is active. Since all writable objects in the entry have
       DEFVALs, a row may be made active without specifying any other
       values."
       ::= { docsSubMgtPktFilterEntry 13 }

   docsSubMgtPktFilterStorageType OBJECT-TYPE
       SYNTAX     StorageType
       MAX-ACCESS read-create
       STATUS     current
       DESCRIPTION
           "This object defines whether this filter is kept in volatile
       storage and lost upon reboot or if this row is backed up by
       non-volatile or permanent storage. 'permanent' entries need not
       allow writable access to any object."
       DEFVAL { nonVolatile }
       ::= { docsSubMgtPktFilterEntry 14 }

   docsSubMgtTcpUdpFilterTable OBJECT-TYPE
       SYNTAX  SEQUENCE OF DocsSubMgtTcpUdpFilterEntry
       MAX-ACCESS not-accessible
       STATUS  current
       DESCRIPTION
           "This is an adjunct to docsSubMgtPktFilterTable. It provides
            optional filtering based on elements in TCP or UDP headers.
            This table is separate from docsSubMgtPktFilterTable only
            because it is expected to be used more rarely. This table
            is not consulted unless the upper-layer protocol is TCP or
            UDP."
       ::= { docsSubMgtObjects 7 }

   docsSubMgtTcpUdpFilterEntry OBJECT-TYPE
       SYNTAX  DocsSubMgtTcpUdpFilterEntry
       MAX-ACCESS not-accessible
       STATUS  current
       DESCRIPTION
           "Defines filtering criteria for TCP and UDP headers.
        Persistence of this row is controlled by
        docsSubMgtPktFilterStorageType."

Expires  May 2003                                             [Page 16]


INTERNET-DRAFT      DOCSIS Subscriber Management MIB       November 2002

       INDEX   { docsSubMgtPktFilterGroup, docsSubMgtPktFilterIndex }
       ::= {docsSubMgtTcpUdpFilterTable 1 }

   DocsSubMgtTcpUdpFilterEntry ::= SEQUENCE
       {
       docsSubMgtTcpUdpSrcPort     InetPortNumber,
       docsSubMgtTcpUdpDstPort     InetPortNumber,
       docsSubMgtTcpFlagValues     BITS,
       docsSubMgtTcpFlagMask       BITS,
       docsSubMgtTcpUdpStatus      RowStatus
       }

   docsSubMgtTcpUdpSrcPort OBJECT-TYPE
       SYNTAX  InetPortNumber
       MAX-ACCESS read-create
       STATUS  current
       DESCRIPTION
           "The source port to match.  Zero matches any value in the
       TCP or UDP source port field."
       DEFVAL { 0 }
       ::= { docsSubMgtTcpUdpFilterEntry 1 }

   docsSubMgtTcpUdpDstPort OBJECT-TYPE
       SYNTAX  InetPortNumber
       MAX-ACCESS read-create
       STATUS  current
       DESCRIPTION
           "The destination port to match.  Zero matches any value in
       the TCP or UDP destination port field."
       DEFVAL { 0 }
       ::= { docsSubMgtTcpUdpFilterEntry 2 }

   docsSubMgtTcpFlagValues OBJECT-TYPE
       SYNTAX  BITS
                   {
                   urgent(0),
                   ack(1),
                   push(2),
                   reset(3),
                   syn(4),
                   fin(5)
                   }
       MAX-ACCESS read-create
       STATUS  current
       DESCRIPTION
           "The value of the flags of interest.  The value of this
       object MUST always be a subset (proper or otherwise) of
       docsSubMgtTcpFlagMask.  An attempt to violate this constraint
       returns an inconsistentValue."
       DEFVAL { {} }
       ::= { docsSubMgtTcpUdpFilterEntry 3 }

   docsSubMgtTcpFlagMask OBJECT-TYPE

Expires  May 2003                                             [Page 17]


INTERNET-DRAFT      DOCSIS Subscriber Management MIB       November 2002

       SYNTAX  BITS
                   {
                   urgent(0),
                   ack(1),
                   push(2),
                   reset(3),
                   syn(4),
                   fin(5)
                   }
       MAX-ACCESS read-create
       STATUS  current
       DESCRIPTION
           "This bit set indicates the flags of interest in the TCP
       header for the packet to be matched.  For example to match all
       packets where the urgent bit is set, but that are not either syn
       or fin, the value of docsSubMgtTcpFlagValues would be { urgent },
       and the value of this object would be { urgent, syn, fin }"
       DEFVAL { {} }
       ::= { docsSubMgtTcpUdpFilterEntry 4 }

   docsSubMgtTcpUdpStatus OBJECT-TYPE
       SYNTAX  RowStatus
       MAX-ACCESS read-create
       STATUS  current
       DESCRIPTION
           "Standard row object for this table.  Any object in the
       conceptual row may be modified regardless of whether this row is
       active or not. Since all writable objects in the entry have
       DEFVALs, a row may be made active without specifying any other
       values."
       ::= { docsSubMgtTcpUdpFilterEntry 5 }

   docsSubMgtCmFilterTable OBJECT-TYPE
       SYNTAX  SEQUENCE OF DocsSubMgtCmFilterEntry
       MAX-ACCESS not-accessible
       STATUS  current
       DESCRIPTION
           "Binds filter groups to modems. This table identifies for
       each modem the upstream and downstream filter groups that apply
       to packets for that modem. Zero is used as a distinguished value
       to mean no filter group."
       ::= { docsSubMgtObjects 8 }

   docsSubMgtCmFilterEntry OBJECT-TYPE
       SYNTAX  DocsSubMgtCmFilterEntry
       MAX-ACCESS not-accessible
       STATUS  current
       DESCRIPTION
           "Binds a filter group to each direction of traffic for a
       modem. The filters in this entry apply if
       docsSubMgtCpeControlActive is true. The contents of this entry
       are meaningless unless the corresponding docsIfCmtsCmStatusValue
       is registrationComplete(6). The persistence of this row is

Expires  May 2003                                             [Page 18]


INTERNET-DRAFT      DOCSIS Subscriber Management MIB       November 2002

       determined solely by the lifespan of the corresponding
       docsIfCmtsCmStatusEntry (normally StorageType=volatile)."
       AUGMENTS { docsIfCmtsCmStatusEntry }
       ::= {docsSubMgtCmFilterTable 1 }

   DocsSubMgtCmFilterEntry ::= SEQUENCE
       {
       docsSubMgtSubFilterDownstream        Integer32,
       docsSubMgtSubFilterUpstream          Integer32,
       docsSubMgtCmFilterDownstream         Integer32,
       docsSubMgtCmFilterUpstream           Integer32
   }

   docsSubMgtSubFilterDownstream OBJECT-TYPE
       SYNTAX  Integer32(0..2147483647)
       MAX-ACCESS read-write
       STATUS  current
       DESCRIPTION
           "The filter group applied to traffic destined for subscribers
       attached to the referenced CM.  This is set upon row creation to
       either the default (docsSubMgtSubFilterDownDefault), or to the
       value in the provisioning object sent upstream from the CM to the
       CMTS during registration. The value of this object is a pointer
       into the docsSubMgtPktFilterTable and refers to all filter rows
       with matching docsSubMgtPktFilterGroup indices. If there are no
       matching filter rows in that table, or if this object is set to
       zero, no filtering is applied to traffic destined to hosts
       attached to this CM."
       ::= { docsSubMgtCmFilterEntry 1 }

   docsSubMgtSubFilterUpstream OBJECT-TYPE
       SYNTAX  Integer32(0..2147483647)
       MAX-ACCESS read-write
       STATUS  current
       DESCRIPTION
           "The filter group applied to traffic originating from
       subscribers attached to the referenced CM.  This is set upon row
       creation to either the default (docsSubMgtSubFilterUpDefault), or
       to the value in the provisioning object sent upstream from the CM
       to the CMTS. The value of this object is a pointer into the
       docsSubMgtPktFilterTable and refers to all filter rows with
       matching docsSubMgtPktFilterGroup indices. If there are no
       matching filter rows in that table, or if this object is set to
       zero, no filtering is applied to traffic originating from
       hosts attached to this CM."
       ::= { docsSubMgtCmFilterEntry 2 }

   docsSubMgtCmFilterDownstream OBJECT-TYPE
       SYNTAX  Integer32(0..2147483647)
       MAX-ACCESS read-write
       STATUS  current
       DESCRIPTION
           "The filter group applied to traffic destined for the

Expires  May 2003                                             [Page 19]


INTERNET-DRAFT      DOCSIS Subscriber Management MIB       November 2002

       referenced CM itself.  This is set upon row creation to either
       the default (docsSubMgtCmFilterDownDefault), or to the value in
       the provisioning object sent upstream from the CM to the CMTS
       during registration. The value of this object is a pointer into
       the docsSubMgtPktFilterTable and refers to all filter rows with
       matching docsSubMgtPktFilterGroup indices. If there are no
       matching filter rows in that table, or if this object is set to
       zero, no filtering is applied to traffic destined to this CM."
       ::= { docsSubMgtCmFilterEntry 3 }

   docsSubMgtCmFilterUpstream OBJECT-TYPE
       SYNTAX  Integer32(0..2147483647)
       MAX-ACCESS read-write
       STATUS  current
       DESCRIPTION
           "The filter group applied to traffic originating from the
       referenced CM itself.  This is set upon row creation to either
       the default (docsSubMgtCmFilterUpDefault), or to the value in
       the provisioning object sent upstream from the CM to the CMTS.
       The value of this object is a pointer into the
       docsSubMgtPktFilterTable and refers to all filter rows with
       matching docsSubMgtPktFilterGroup indices. If there are no
       matching filter rows in that table, or if this object is set
       to zero, no filtering is applied to traffic originating from
       this CM."
       ::= { docsSubMgtCmFilterEntry 4 }

   docsSubMgtSubFilterDownDefault OBJECT-TYPE
       SYNTAX  Integer32(0..2147483647)
       MAX-ACCESS read-write
       STATUS  current
       DESCRIPTION
           "Upon a row creation in docsSubMgtCmFilterTable,
       docsSubMgtSubFilterDownstream is set to this value if no
       provisioning object is present to override it.  This object is
       persistent across CMTS reboots.  Upon initial CMTS
       initialization, this defaults to 0."
       ::= { docsSubMgtObjects 9 }

   docsSubMgtSubFilterUpDefault OBJECT-TYPE
       SYNTAX  Integer32(0..2147483647)
       MAX-ACCESS read-write
       STATUS  current
       DESCRIPTION
           "Upon a row creation in docsSubMgtCmFilterTable,
       docsSubMgtSubFilterUpstream is set to this value if no
       provisioning object is present to override it.  This object is
       persistent across CMTS reboots.  Upon initial CMTS
       initialization, this defaults to 0."
       ::= { docsSubMgtObjects 10 }

   docsSubMgtCmFilterDownDefault OBJECT-TYPE
       SYNTAX  Integer32(0..2147483647)

Expires  May 2003                                             [Page 20]


INTERNET-DRAFT      DOCSIS Subscriber Management MIB       November 2002

       MAX-ACCESS read-write
       STATUS  current
       DESCRIPTION
           "Upon a row creation in docsSubMgtCmFilterTable,
       docsSubMgtCmFilterDownstream is set to this value if no
       provisioning object is present to override it.  This object is
       persistent across CMTS reboots.  Upon initial CMTS
       initialization, this defaults to 0."
       ::= { docsSubMgtObjects 11 }

   docsSubMgtCmFilterUpDefault OBJECT-TYPE
       SYNTAX  Integer32(0..2147483647)
       MAX-ACCESS read-write
       STATUS  current
       DESCRIPTION
           "Upon a row creation in docsSubMgtCmFilterTable,
       docsSubMgtCmFilterUpstream is set to this value if no
       provisioning object is present to override it.  This object is
       persistent across CMTS reboots.  Upon initial CMTS
       initialization, this defaults to 0."
       ::= { docsSubMgtObjects 12 }


   docsSubMgtConformance OBJECT IDENTIFIER ::= { docsSubMgt 2 }
   docsSubMgtCompliances OBJECT IDENTIFIER ::=
                                           { docsSubMgtConformance 1 }
   docsSubMgtGroups OBJECT IDENTIFIER      ::=
                                           { docsSubMgtConformance 2 }

   docsSubMgtBasicCompliance MODULE-COMPLIANCE
       STATUS      current
       DESCRIPTION
           "The compliance statement for CMTS devices that implement
       CMTS centric subscriber management."

   MODULE

   MANDATORY-GROUPS {
           docsSubMgtGroup
           }

   OBJECT docsSubMgtCpeControlMaxCpeIp
       SYNTAX Integer32(0..16)
       DESCRIPTION
           "An implementation is only required to support up to
            sixteen addresses per modem."

   OBJECT docsSubMgtCpeMaxIpDefault
       SYNTAX Integer32(0..16)
       DESCRIPTION
           "An implementation is only required to support up to
            sixteen addresses per modem."


Expires  May 2003                                             [Page 21]


INTERNET-DRAFT      DOCSIS Subscriber Management MIB       November 2002

   OBJECT docsSubMgtCpeIpAddressType
       SYNTAX InetAddressType { ipv4(1) }
       DESCRIPTION
           "An implementation is only required to support IPv4
            addresses."

   OBJECT docsSubMgtCpeIpAddr
       SYNTAX  InetAddress (SIZE(5))
       DESCRIPTION
           "An implementation is only required to support IPv4
            addresses."

   OBJECT docsSubMgtPktFilterAddrType
       SYNTAX InetAddressType { ipv4(1) }
       DESCRIPTION
           "An implementation is only required to support IPv4
            addresses."

   OBJECT docsSubMgtPktFilterSrcAddr
       SYNTAX InetAddress (SIZE(5))
       DESCRIPTION
           "An implementation is only required to support IPv4
            addresses."

   OBJECT docsSubMgtPktFilterSrcMask
       SYNTAX InetAddressPrefixLength(0..32)
       DESCRIPTION
           "An implementation is only required to support IPv4
            addresses."

   OBJECT docsSubMgtPktFilterDstAddr
       SYNTAX InetAddress (SIZE(5))
       DESCRIPTION
           "An implementation is only required to support IPv4
            addresses."

   OBJECT docsSubMgtPktFilterDstMask
       SYNTAX InetAddressPrefixLength(0..32)
       DESCRIPTION
           "An implementation is only required to support IPv4
            addresses."

   OBJECT docsSubMgtPktFilterStorageType
       SYNTAX StorageType { nonVolatile(3) }
       DESCRIPTION
           "An implementation is only required to support nonvolatile
            storage of filter entries."

   OBJECT docsSubMgtSubFilterDownstream
       SYNTAX  Integer32(0..30)
       DESCRIPTION
           "An implementation is only required to support thirty
       filter groups."

Expires  May 2003                                             [Page 22]


INTERNET-DRAFT      DOCSIS Subscriber Management MIB       November 2002

   OBJECT docsSubMgtSubFilterUpstream
       SYNTAX  Integer32(0..30)
       DESCRIPTION
           "An implementation is only required to support thirty
       filter groups."

   OBJECT docsSubMgtCmFilterDownstream
       SYNTAX  Integer32(0..30)
       DESCRIPTION
           "An implementation is only required to support thirty
       filter groups."

   OBJECT docsSubMgtCmFilterUpstream
       SYNTAX  Integer32(0..30)
       DESCRIPTION
           "An implementation is only required to support thirty
       filter groups."

   OBJECT docsSubMgtSubFilterDownDefault
       SYNTAX  Integer32(0..30)
       DESCRIPTION
           "An implementation is only required to support thirty
       filter groups."

   OBJECT docsSubMgtSubFilterUpDefault
       SYNTAX  Integer32(0..30)
       DESCRIPTION
           "An implementation is only required to support thirty
       filter groups."

   OBJECT docsSubMgtCmFilterDownDefault
       SYNTAX  Integer32(0..30)
       DESCRIPTION
           "An implementation is only required to support thirty
       filter groups."

   OBJECT docsSubMgtCmFilterUpDefault
       SYNTAX  Integer32(0..30)
       DESCRIPTION
           "An implementation is only required to support thirty
       filter groups."

           ::= { docsSubMgtCompliances 1 }

   docsSubMgtGroup OBJECT-GROUP
           OBJECTS {
               docsSubMgtCpeControlMaxCpeIp,
               docsSubMgtCpeControlActive,
               docsSubMgtCpeControlLearnable,
               docsSubMgtCpeControlReset,
               docsSubMgtCpeMaxIpDefault,
               docsSubMgtCpeActiveDefault,
               docsSubMgtCpeLearnableDefault,

Expires  May 2003                                             [Page 23]


INTERNET-DRAFT      DOCSIS Subscriber Management MIB       November 2002

               docsSubMgtCpeIpAddressType,
               docsSubMgtCpeIpAddr,
               docsSubMgtCpeIpLearned,
               docsSubMgtPktFilterAddrType,
               docsSubMgtPktFilterSrcAddr,
               docsSubMgtPktFilterSrcMask,
               docsSubMgtPktFilterDstAddr,
               docsSubMgtPktFilterDstMask,
               docsSubMgtPktFilterUlp,
               docsSubMgtPktFilterTosValue,
               docsSubMgtPktFilterTosMask,
               docsSubMgtPktFilterAction,
               docsSubMgtPktFilterMatches,
               docsSubMgtPktFilterStatus,
               docsSubMgtPktFilterStorageType,
               docsSubMgtTcpUdpSrcPort,
               docsSubMgtTcpUdpDstPort,
               docsSubMgtTcpFlagValues,
               docsSubMgtTcpFlagMask,
               docsSubMgtTcpUdpStatus,
               docsSubMgtSubFilterDownstream,
               docsSubMgtSubFilterUpstream,
               docsSubMgtCmFilterDownstream,
               docsSubMgtCmFilterUpstream,
               docsSubMgtSubFilterDownDefault,
               docsSubMgtSubFilterUpDefault,
               docsSubMgtCmFilterDownDefault,
               docsSubMgtCmFilterUpDefault
               }
               STATUS      current
               DESCRIPTION
                   "The objects use to managed host-based cable modems
                   via a set of CMTS enforced controls."
               ::= {  docsSubMgtGroups 1 }

   END

4. Acknowledgments

   This document is based on work by Michael St.Johns, then at
   Excite@Home.  Thanks to Guenter Roeck and Julie McGray for reviewing
   early drafts.  This draft benefitted from extensive review by Bert
   Wijnen.

5. Normative References

   [RFC1905]
        Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol
        Operations for Version 2 of the Simple Network Management
        Protocol (SNMPv2)", RFC 1905, January 1996.

   [RFC1906]
        Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport

Expires  May 2003                                             [Page 24]


INTERNET-DRAFT      DOCSIS Subscriber Management MIB       November 2002

        Mappings for Version 2 of the Simple Network Management Protocol
        (SNMPv2)", RFC 1906, January 1996.

   [RFC2571]
        Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture
        for Describing SNMP Management Frameworks", RFC 2571, April
        1999.

   [RFC2572]
        Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message
        Processing and Dispatching for the Simple Network Management
        Protocol (SNMP)", RFC 2572, April 1999.

   [RFC2573]
        Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC
        2573, April 1999.

   [RFC2574]
        Blumenthal, U. and B. Wijnen, "User-based Security Model (USM)
        for version 3 of the Simple Network Management Protocol
        (SNMPv3)", RFC 2574, April 1999.

   [RFC2575]
        Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access
        Control Model (VACM) for the Simple Network Management Protocol
        (SNMP)", RFC 2575, April 1999.

   [RFC2578]
        McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of
        Management Information for Version 2 (SMIv2)", STD 58, RFC 2578,
        April 1999.

   [RFC2579]
        McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual
        Conventions for SMIv2", STD 58, RFC 2579, April 1999.

   [RFC2580]
        McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Conformance
        Statements for SMIv2", STD 58, RFC 2580, April 1999.

   [DOCSRFI]
        "Data-Over-Cable Service Interface Specifications: Cable Modem
        Radio Frequency Interface Specification SP-RFIv2.0-I02-020617",
        DOCSIS, June 2002, available at http://www.cablemodem.com/.

   [RFC2669]
        StJohns, M. , "Cable Device Management Information Base for
        DOCSIS Compliant Cable Modems and Cable Modem Termination
        Systems", RFC2669, August 1999.

   [RFC2670]
        StJohns, M. , "Radio Frequency (RF) Interface Management
        Information Base for MCNS/DOCSIS compliant RF interfaces",

Expires  May 2003                                             [Page 25]


INTERNET-DRAFT      DOCSIS Subscriber Management MIB       November 2002

        RFC2670, August 1999.

6. Informative References

   [RFC1155]
        Rose, M. and K. McCloghrie, "Structure and Identification of
        Management Information for TCP/IP-based Internets", STD 16, RFC
        1155, May 1990.

   [RFC1157]
        Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple
        Management Protocol", STD 15, RFC 1157, May 1990.

   [RFC1212]
        Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16,
        RFC 1212, March 1991.

   [RFC1215]
        Rose, M., "A Convention for Defining Traps for use with the
        SNMP", RFC 1215, March 1991.

   [RFC1901]
        Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
        "Introduction to Community-based SNMPv2", RFC 1901, January
        1996.

   [RFC2570]
        Case, J., Mundy, R., Partain, D., and B. Stewart,
        "Introduction to Version 3 of the Internet-standard Network
        Management Framework", RFC2570, April 1999.

   [RFC1858]
        Ziemba, G., Reed, D., and P. Traina, "Security Considerations
        for IP Fragment Filtering", RFC1858, October 1995.

   [RFC2138]
        Miller, I., "Protection against a Variant of the Tiny Fragment
        Attack". RFC3128, June 2001.

   [DOCSBPI]
        "Data-Over-Cable Service Interface Specifications: Baseline
        Privacy Plus Interface Specification SP-BPI+-I09-020830",
        DOCSIS, August 2002, available at http://www.cablemodem.com/.

7. Security Considerations

   This MIB is intended to limit certain kinds of network behavior by
   subscriber hosts attached to cable modems, including, for example, IP
   spoofing. These limitations may be compromised, however, if the cable
   modem's identity or registration process is spoofed. The DOCSIS RFI
   and privacy specifications [DOCSRFI] and [DOCSBPI] define a number of
   mechanisms for assuring modem identity.


Expires  May 2003                                             [Page 26]


INTERNET-DRAFT      DOCSIS Subscriber Management MIB       November 2002

   The filtering mechanism defined here can be defeated through the
   "tiny fragment" and "overlapping fragment" attacks if the
   recommendations in section 2.2.6 are omitted. See [RFC1858] and
   [RFC2138] for discussion of these attacks.

   There are a number of management objects defined in this MIB that
   have 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.

   Unauthorized SETs to this MIB can permit two major security problems
   with public cable network operation: IP address spoofing, and defeat
   of operator-defined packet filtering.

   The following objects, if SET maliciously, would evade controls on
   address spoofing:

       docsSubMgtCpeControlMaxCpeIp
       docsSubMgtCpeControlActive
       docsSubMgtCpeControlLearnable
       docsSubMgtCpeControlReset
       docsSubMgtCpeMaxIpDefault
       docsSubMgtCpeActiveDefault
       docsSubMgtCpeLearnableDefault

   All writable objects in docsSubMgtPktFilterTable and
   docsSubMgtTcpUdpFilterTable share the potential, if SET maliciously,
   to permit unwanted and disruptive traffic to enter the public data
   network, as well as to be transmitted to subscribers. The following
   objects could also permit packet filtering to be defeated:

       docsSubMgtSubFilterDownstream
       docsSubMgtSubFilterUpstream
       docsSubMgtCmFilterDownstream
       docsSubMgtCmFilterUpstream
       docsSubMgtSubFilterDownDefault
       docsSubMgtSubFilterUpDefault
       docsSubMgtCmFilterDownDefault
       docsSubMgtCmFilterUpDefault

   SNMPv1 by itself is not a secure environment.  Even if the network
   itself is secure (for example by using IPSec), even then, there is no
   control as to who on the secure network is allowed to access and
   GET/SET (read/change/create/delete) the objects in this MIB.

   It is recommended that the implementers consider the security
   features as provided by the SNMPv3 framework.  Specifically, the use
   of the User-based Security Model RFC 2574 [RFC2574] and the View-
   based Access Control Model RFC 2575 [RFC2575] is recommended.

   It is then a customer/user responsibility to ensure that the SNMP

Expires  May 2003                                             [Page 27]


INTERNET-DRAFT      DOCSIS Subscriber Management MIB       November 2002

   entity giving access to an instance of this MIB, 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.

8. Author's Address

        Wilson Sawyer
        ARRIS
        6 Riverside Drive
        Andover, MA 01810
        USA

        Phone: +1 978 946 4711
        Email: wsawyer@ieee.org

9. Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementers or users of this specification can
   be obtained from the IETF Secretariat.


   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.




10. Full Copyright Statement

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


   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this

Expires  May 2003                                             [Page 28]


INTERNET-DRAFT      DOCSIS Subscriber Management MIB       November 2002

   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the  purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.


   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   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.

   Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.































Expires  May 2003                                             [Page 29]