INTERNET-DRAFT DOCSIS Subscriber Management MIB August 2003
Management Information Base
for Data Over Cable Service Interface Specification (DOCSIS)
Cable Modem Termination Systems
for Subscriber Management
draft-ietf-ipcdn-subscriber-mib-12.txt
Fri Aug 1 15:00:00 EST 2003
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 February 2004 [Page 1]
INTERNET-DRAFT DOCSIS Subscriber Management MIB August 2003
Table of Contents
1. The Internet-Standard Management Framework.........................2
2. Overview...........................................................2
2.1. Structure of the MIB.............................................4
2.1.1. docsSubMgtFilterGroupTable.....................................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.3. Relationship to the Differentiated Services MIB [RFC3289]........6
2.3.1. Using the Filter Group to Extend Packet Classification.........6
2.3.2. Interface Usage................................................7
2.4. Filtering and the Tiny Fragment Attack...........................7
3. Definitions........................................................7
4. Acknowledgments...................................................19
5. Normative References..............................................19
6. Informative References............................................19
7. Security Considerations...........................................20
8. Author's Address..................................................21
9. Intellectual Property.............................................21
10. Full Copyright Statement.........................................22
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. 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
Expires February 2004 [Page 2]
INTERNET-DRAFT DOCSIS Subscriber Management MIB August 2003
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
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 makes use of the Classification, Counting,
and Drop facilities of the Differentiated Services MIB [RFC3289]. In
order to provide different filtering for various classes of
subscribers, this MIB defines the docsSubMgtFilterGroupTable which
specifies which filters are to apply to each subscriber packet. This
table is used by RFC3289 as a first pass of classification, to then
choose a second pass of classification using the
diffServMultiFieldClfrTable:
diffServDataPathStart --> diffServClfrEntry(1)
diffServClfrElementSpecific(1) --> docsSubMgtFilterGroupIndex
diffServClfrElementNext(1) --> diffServClfrEntry(2)
diffServClfrElementSpecific(2)--> diffServMultiFieldClfrEntry
diffServClfrElementNext(2) --> difServActionEntry (count or algDrop)
Rather than maintaining a separate list of filters for each modem at
the CMTS, it is assumed that large numbers of modems will share
filtering characteristics. Therefore, DOCSIS signaling defines filter
groups by which cable modems share common filter lists.
Expires February 2004 [Page 3]
INTERNET-DRAFT DOCSIS Subscriber Management MIB August 2003
2.1. Structure of the MIB
This MIB is structured in four 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 docsSubMgtCmFilterTable binds a cable modem to a set of
filters in diffServMultiFieldClfrTable.
o The docsSubMgtFilterGroupTable provides the OIDs by which
the diffServClfrElementTable selects a filter group.
The docsSubMgtCpeControlTable and docsSubMgtCmFilterTable AUGMENT the
docsIfCmtsCmStatusTable from [RFC2670]. Similarly,
docsSubMgtCpeIpTable expands this table (an additional index is
used). As such, each entry in these tables is bound to a registered
cable modem, as perceived by the CMTS.
2.1.1. docsSubMgtFilterGroupTable
The docsSubMgtFilterGroupTable is unusual in that it might be viewed
not so much as an array of single-object entries as an array of
OBJECT-IDENTIFIER conventions. Each instance of
docsSubMgtFilterGroupIndex serves as an OID reference for
diffServClfrElementSpecific. The index value corresponds to the
filter group identifier signaled by the cable modem [DOCSRFI]. An
entry exists in this Table if a reference to it exists in
diffServClfrElementSpecific.
As such, contrary to common practice, the index for the table is
read-only, and is both the Entry's index and its only value.
2.2. Management requirements
The DOCSIS cable modem provisioning model [DOCSRFI] requires that
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
Expires February 2004 [Page 4]
INTERNET-DRAFT DOCSIS Subscriber Management MIB August 2003
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 (see section
C.1.1.18.3 of [DOCSRFI]):
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
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,
Expires February 2004 [Page 5]
INTERNET-DRAFT DOCSIS Subscriber Management MIB August 2003
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 use the default
entry (diffServClfrElementSpecific=zeroDotZero) specified in the
diffServClfrElementTable.
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.3. Relationship to the Differentiated Services MIB [RFC3289]
DOCSIS CMTSs rely on the classification, counting, and drop
facilities of the Differentiated Services MIB to screen subscriber
packets for IP, TCP, and UDP characteristics. It is expected that any
implementation of this MIB also include at least the following from
RFC 3289:
o diffServDataPathTable
o diffServClfrTable
o diffServClfrElementTable
o diffServMultiFieldClfrTable
o diffServActionTable
o diffServCountActTable
o diffServAlgDropTable (diffServAlgDropType=alwaysDrop)
The corresponding "next-free" objects are also required.
The use of other facilities from RFC 3289 is not precluded, but is
beyond the scope of this specification.
2.3.1. Using the Filter Group to Extend Packet Classification
The base capability of RFC 3289 assumes that all packets on the same
direction of the same interface will be classified by the same
criteria. Filter Groups, introduced in this document, expand on RFC
Expires February 2004 [Page 6]
INTERNET-DRAFT DOCSIS Subscriber Management MIB August 2003
3289 to allow various subscribers to receive different classification
(filtering) treatment. One way to view filter groups is as sub-
interfaces within the physical DOCSIS channel. Another way to view
them is as values of a field logically prepended to the packet prior
to classification:
[filter group][docsis MAC header][IP header]...
Of course this 'logical' field has no existence outside of the CMTS.
The diffServClfrTable and diffServClfrElementTable are then used
twice: the first classifiers select among filter groups, using OIDs
from docsSubMgtFilterGroupTable. The 'next' action on matching a
filter group is to select a diffServClfrEntry which now classifies on
IP/TCP/UDP criteria (the diffServMultiFieldClfrTable_. The 'next'
action on this second match may be a 'count' (and accept), a 'drop',
or some other feature from RFC 3289.
2.3.2. Interface Usage
For purposes of DOCSIS subscriber management, only the DOCSIS MAC
cable interface(s) are used. The interface appears as the index to
diffServDataPathEntry, which is the starting point for diffserv MIB
table traversal.
The use of the diffserv MIB for other purposes, both on the DOCSIS
MAC interfaces and on other network interfaces, is not precluded by
this document.
2.4. 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 [RFC3128].
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-IETF-SUBMGT-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY,
OBJECT-TYPE,
Integer32,
Expires February 2004 [Page 7]
INTERNET-DRAFT DOCSIS Subscriber Management MIB August 2003
mib-2
FROM SNMPv2-SMI
RowStatus,
TruthValue,
TimeStamp,
StorageType
FROM SNMPv2-TC
OBJECT-GROUP,
MODULE-COMPLIANCE
FROM SNMPv2-CONF
InetAddressType,
InetAddress
FROM INET-ADDRESS-MIB
docsIfCmtsCmStatusIndex,
docsIfCmtsCmStatusEntry
FROM DOCS-IF-MIB -- RFC2670
;
docsSubMgt MODULE-IDENTITY
LAST-UPDATED "200308010000Z" -- August 1, 2003
ORGANIZATION "IETF IPCDN Working Group"
CONTACT-INFO
" Wilson Sawyer
Postal: ARRIS
50 Kelly Brook Lane
East Hampstead, NH 03826
U.S.A.
Phone: +1 603 382 7080
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, Richard_Woundy@cable.comcast.com
Jean-Francois Mule, jf.mule@cablelabs.com"
DESCRIPTION
"This is the CMTS centric subscriber management MIB for
DOCSIS compliant CMTS. Copyright (C) The Internet Society
(2003). This version of this MIB module is part of RFC xxxx;
see the RFC itself for full legal notices."
REVISION "200308010000Z" -- August 1, 2003
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
Expires February 2004 [Page 8]
INTERNET-DRAFT DOCSIS Subscriber Management MIB August 2003
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
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,
docsSubMgtCpeControlLastReset TimeStamp
}
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 }
Expires February 2004 [Page 9]
INTERNET-DRAFT DOCSIS Subscriber Management MIB August 2003
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
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 }
docsSubMgtCpeControlLastReset OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime when docsSubMgtCpeControlReset was
last set true. Zero if never reset."
::= { docsSubMgtCpeControlEntry 5 }
docsSubMgtCpeMaxIpDefault OBJECT-TYPE
SYNTAX Integer32(0..2147483647)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The default value for docsSubMgtCpeControlMaxCpeIp if not
Expires February 2004 [Page 10]
INTERNET-DRAFT DOCSIS Subscriber Management MIB August 2003
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
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
}
Expires February 2004 [Page 11]
INTERNET-DRAFT DOCSIS Subscriber Management MIB August 2003
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
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 }
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
Expires February 2004 [Page 12]
INTERNET-DRAFT DOCSIS Subscriber Management MIB August 2003
to mean no filter group."
::= { docsSubMgtObjects 6 }
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
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 zero (use default classification), or to the value in the
provisioning object sent upstream from the CM to the CMTS during
registration. The value of this object is the same as the filter
group index appearing as docsSubMgtFilterGroupIndex."
::= { 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 zero (use default classification), or
to the value in the provisioning object sent upstream from the CM
to the CMTS. The value of this object is the same as the filter
group index appearing as docsSubMgtFilterGroupIndex."
::= { docsSubMgtCmFilterEntry 2 }
docsSubMgtCmFilterDownstream OBJECT-TYPE
Expires February 2004 [Page 13]
INTERNET-DRAFT DOCSIS Subscriber Management MIB August 2003
SYNTAX Integer32(0..2147483647)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The filter group applied to traffic destined for the
referenced CM itself. This is set upon row creation to either
zero (use default classification), or to the value in
the provisioning object sent upstream from the CM to the CMTS
during registration. The value of this object is the same as
the filter group index appearing as docsSubMgtFilterGroupIndex."
::= { 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
zero use default classification), or to the value in
the provisioning object sent upstream from the CM to the CMTS
during registration. The value of this object is the same as
the filter group index appearing as docsSubMgtFilterGroupIndex."
::= { docsSubMgtCmFilterEntry 4 }
docsSubMgtFilterGroupTable OBJECT-TYPE
SYNTAX SEQUENCE OF DocsSubMgtFilterGroupEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Provides a collection of OIDs to which
diffServClfrElementSpecific refers. This table provides filter
group indices which can be compared with those signaled during
Docsis registration. A packet matches an entry from this table
if the packet originated from or is destined to a cable modem
which registered this index as one of its four filter groups
(see docsSubMgtCmFilterTable) and if the packet direction and
MAC address select the use of this index among the four."
::= { docsSubMgtObjects 7 }
docsSubMgtFilterGroupEntry OBJECT-TYPE
SYNTAX DocsSubMgtFilterGroupEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry only exists if needed by the
diffServClfrElementEntry. A packet matches this entry if the
packet's cable modem registered this index as one of its four
filter groups (see docsSubMgtCmFilterTable) and if the packet
direction and MAC address select the use of this index among
the four."
INDEX { docsSubMgtFilterGroupIndex }
::= { docsSubMgtFilterGroupTable 1 }
Expires February 2004 [Page 14]
INTERNET-DRAFT DOCSIS Subscriber Management MIB August 2003
DocsSubMgtFilterGroupEntry ::= SEQUENCE
{
docsSubMgtFilterGroupIndex Integer32
}
docsSubMgtFilterGroupIndex OBJECT-TYPE
SYNTAX Integer32(0..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Provides an OID to which diffServClfrElementSpecific
refers. A packet matches this entry if the packet's cable modem
registered this index value as one of its four filter groups
and if the packet direction and MAC address select the use of
this index among the four. Because this is the only field in
this table, it is read-only, contrary to the usual SNMP custom
of making indices not-accessible."
::= { docsSubMgtFilterGroupEntry 1 }
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 DIFFSERV-MIB -- RFC3289
MANDATORY-GROUPS {
diffServMIBDataPathGroup,
diffServMIBClfrGroup,
diffServMIBClfrElementGroup,
diffServMIBMultiFieldClfrGroup,
diffServMIBActionGroup,
diffServMIBAlgDropGroup,
diffServMIBCounterGroup
}
OBJECT diffServDataPathStatus -- same as RFC3289
SYNTAX RowStatus { active(1) }
WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) }
DESCRIPTION
"Support for createAndWait and notInService is not required."
OBJECT diffServClfrStatus -- same as RFC3289
SYNTAX RowStatus { active(1) }
WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) }
Expires February 2004 [Page 15]
INTERNET-DRAFT DOCSIS Subscriber Management MIB August 2003
DESCRIPTION
"Support for createAndWait and notInService is not required."
OBJECT diffServClfrElementStatus -- same as RFC3289
SYNTAX RowStatus { active(1) }
WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) }
DESCRIPTION
"Support for createAndWait and notInService is not required."
OBJECT diffServMultiFieldClfrAddrType
SYNTAX InetAddressType { ipv4(1) }
DESCRIPTION
"An implementation is only required to support IPv4
addresses."
OBJECT diffServMultiFieldClfrSrcAddr
SYNTAX InetAddress (SIZE(4))
DESCRIPTION
"An implementation is only required to support IPv4
addresses."
OBJECT diffServMultiFieldClfrDstAddr
SYNTAX InetAddress (SIZE(4))
DESCRIPTION
"An implementation is only required to support IPv4
addresses."
OBJECT diffServAlgDropStatus -- same as RFC3289
SYNTAX RowStatus { active(1) }
WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) }
DESCRIPTION
"Support for createAndWait and notInService is not required."
OBJECT diffServDataPathStorage
SYNTAX StorageType { nonVolatile(3) }
DESCRIPTION
"An implementation is only required to support nonvolatile
storage."
OBJECT diffServClfrStorage
SYNTAX StorageType { nonVolatile(3) }
DESCRIPTION
"An implementation is only required to support nonvolatile
storage."
OBJECT diffServClfrElementStorage
SYNTAX StorageType { nonVolatile(3) }
DESCRIPTION
"An implementation is only required to support nonvolatile
storage."
OBJECT diffServMultiFieldClfrStorage
Expires February 2004 [Page 16]
INTERNET-DRAFT DOCSIS Subscriber Management MIB August 2003
SYNTAX StorageType { nonVolatile(3) }
DESCRIPTION
"An implementation is only required to support nonvolatile
storage."
OBJECT diffServActionStorage
SYNTAX StorageType { nonVolatile(3) }
DESCRIPTION
"An implementation is only required to support nonvolatile
storage."
OBJECT diffServCountActStorage
SYNTAX StorageType { nonVolatile(3) }
DESCRIPTION
"An implementation is only required to support nonvolatile
storage."
OBJECT diffServAlgDropStorage
SYNTAX StorageType { nonVolatile(3) }
DESCRIPTION
"An implementation is only required to support nonvolatile
storage."
OBJECT diffServAlgDropType
SYNTAX INTEGER { alwaysDrop(5) }
DESCRIPTION
"For DOCSIS subscriber management, this object is
only used to provide packet filtering. Implementations
need not support other values of this enumeration."
MODULE -- This module i.e. DOCS-IETF-SUBMGT-MIB
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."
OBJECT docsSubMgtCpeIpAddressType
SYNTAX InetAddressType { ipv4(1) }
DESCRIPTION
"An implementation is only required to support IPv4
Expires February 2004 [Page 17]
INTERNET-DRAFT DOCSIS Subscriber Management MIB August 2003
addresses."
OBJECT docsSubMgtCpeIpAddr
SYNTAX InetAddress (SIZE(4))
DESCRIPTION
"An implementation is only required to support IPv4
addresses."
OBJECT docsSubMgtSubFilterDownstream
SYNTAX Integer32(0..30)
DESCRIPTION
"An implementation is only required to support thirty
filter groups."
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."
::= { docsSubMgtCompliances 1 }
docsSubMgtGroup OBJECT-GROUP
OBJECTS {
docsSubMgtCpeControlMaxCpeIp,
docsSubMgtCpeControlActive,
docsSubMgtCpeControlLearnable,
docsSubMgtCpeControlReset,
docsSubMgtCpeControlLastReset,
docsSubMgtCpeMaxIpDefault,
docsSubMgtCpeActiveDefault,
docsSubMgtCpeLearnableDefault,
docsSubMgtCpeIpAddressType,
docsSubMgtCpeIpAddr,
docsSubMgtCpeIpLearned,
docsSubMgtSubFilterDownstream,
docsSubMgtSubFilterUpstream,
docsSubMgtCmFilterDownstream,
docsSubMgtCmFilterUpstream,
docsSubMgtFilterGroupIndex
}
Expires February 2004 [Page 18]
INTERNET-DRAFT DOCSIS Subscriber Management MIB August 2003
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, Julie McGray, and Bert Wijnen
for reviewing earlier drafts.
5. Normative References
[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-I03-021218",
DOCSIS, December 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",
RFC2670, August 1999.
[RFC3289]
Baker, F., Chan, K., and A. Smith, "Management Information
Base for the Differentiated Services Architecture", RFC3289,
May 2002.
6. Informative References
[RFC1858]
Ziemba, G., Reed, D., and P. Traina, "Security Considerations
Expires February 2004 [Page 19]
INTERNET-DRAFT DOCSIS Subscriber Management MIB August 2003
for IP Fragment Filtering", RFC1858, October 1995.
[RFC3128]
Miller, I., "Protection against a Variant of the Tiny Fragment
Attack". RFC3128, June 2001.
[RFC3410]
Case, J., Mundy, R., Partain, D. and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002.
[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.
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
[RFC3128] 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
The following objects could also permit packet filtering to be
Expires February 2004 [Page 20]
INTERNET-DRAFT DOCSIS Subscriber Management MIB August 2003
defeated:
docsSubMgtSubFilterDownstream
docsSubMgtSubFilterUpstream
docsSubMgtCmFilterDownstream
docsSubMgtCmFilterUpstream
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. It is thus important to
control even GET access to these objects and possibly to even encrypt
the values of these objects when sending them over the network via
SNMP. The most sensitive is docsSubMgtCpeIpAddr within
docsSubMgtCpeIpTable. While docsSubMgtCpeIpTable is intended to
control address spoofing, it includes information about the current
subscriber address pool. This information may itself be valuable to
would-be spoofers.
SNMP versions prior to SNMPv3 did not include adequate security.
Even if the network itself is secure (for example by using IPSec),
even then, there is no control as to who on the secure network is
allowed to access and GET/SET (read/change/create/delete) the objects
in this MIB module.
It is RECOMMENDED that implementers consider the security features as
provided by the SNMPv3 framework (see [RFC3410], section 8),
including full support for the SNMPv3 cryptographic mechanisms (for
authentication and privacy).
Further, deployment of SNMP versions prior to SNMPv3 is NOT
RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
enable cryptographic security. It is then a customer/operator
responsibility to ensure that the SNMP entity giving access to an
instance of this MIB module, is properly configured to give access to
the objects only to those principals (users) that have legitimate
rights to indeed GET or SET (change/create/delete) them.
8. Author's Address
Wilson Sawyer
ARRIS
50 Kelly Brook Lane
East Hampstead NH 03826
Phone: +1 603 382 7080
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
Expires February 2004 [Page 21]
INTERNET-DRAFT DOCSIS Subscriber Management MIB August 2003
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 (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
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
Expires February 2004 [Page 22]
INTERNET-DRAFT DOCSIS Subscriber Management MIB August 2003
Internet Society.
Expires February 2004 [Page 23]
