Request for Comments: 4036 April 2005
Category: Standards Track
Management Information Base for
Data Over Cable Service Interface Specification (DOCSIS)
Cable Modem Termination Systems for Subscriber Management
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
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 Simple Network
Management Protocol (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. The Differentiated
Services MIB (RFC 3289) provides the filtering functions needed here,
making use of classification items defined in this specification.
Table of Contents
1. The Internet-Standard Management Framework.................... 2
2. Conventions................................................... 2
3. Overview...................................................... 2
3.1. Structure of the MIB.................................... 4
3.1.1. docsSubMgtFilterGroupTable...................... 4
3.1.2. IPv4 Compliance................................. 5
3.2. Management Requirements................................. 5
3.2.1. Interaction with DOCSIS Provisioning for CPE
Address Control................................. 6
3.2.2. Interaction with DOCSIS Provisioning for
Filtering....................................... 6
3.2.3. Distinguishing Modem from Subscriber Traffic.... 7
3.3. Relationship to the Differentiated Services MIB
[RFC3289]............................................... 7
3.3.1. Using the Filter Group to Extend Packet
Classification.................................. 8
3.3.2. Interface Usage................................. 8
3.4. Filtering and the Tiny Fragment Attack.................. 9
4. Definitions................................................... 9
5. Acknowledgements.............................................. 23
6. IANA Considerations........................................... 23
7. Normative References.......................................... 23
8. Informative References........................................ 24
9. Security Considerations....................................... 25
Author’s Address.................................................. 26
Full Copyright Statement.......................................... 27
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. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119].
3. Overview
This MIB module 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 [ITU-T-J122]. These managed
objects facilitate protection of the cable network from misuse by
subscribers. This misuse might include, for example, address
spoofing, service spoofing, or operation of unauthorized services.
The following figure illustrates the operational and physical
deployment relationships between elements in a cable modem network.
This MIB module 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 service 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 module controls IP packet forwarding to and from each cable
modem, at the CMTS. Different modems may be accorded different
treatment.
Much of this module duplicates capabilities found in the DOCSIS Cable
Device MIB [RFC2669]. Although 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, as 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 address and
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 address and protocol filtering capability is similar to that
performed by the cable modem itself. It differs in several respects
because it is intended to control subscriber traffic at the CMTS,
rather than at the individual CM. First, the MIB structure must be
indexed appropriately at the CMTS to indicate which cable modem
subscriber is intended. Second, 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,
modems are grouped so as to share common filter lists.
The filtering capability is implemented using 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 apply to
each subscriber packet. This table is used by RFC 3289 as a first
pass of classification, and also to 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)
Because it is assumed that large numbers of modems will share
filtering characteristics, DOCSIS signaling defines filter groups
according to which cable modems share common filter lists. The
operator creates references to these groups in the
diffServClfrElementSpecific(1) entries above.
3.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
that the CMTS believes 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.
3.1.1. docsSubMgtFilterGroupTable
The docsSubMgtFilterGroupTable links the filter group (signaled by
DOCSIS as a small integer) to the diffServClfrElementEntry for the
first pass of filter classification. diffServClfrElementSpecific
requires a RowPointer. Thus, this table exists to provide referenced
objects for diffServClfrElementSpecific. The classification method
is as follows:
o Use the DOCSIS filter group, as inferred from the sending or
receiving modem, as the classification criterion.
o Use docsSubMgtFilterGroupIndex as the value to match.
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.
3.1.2. IPv4 Compliance
Please note that the compliance statements in this version of the MIB
module require support only for IPv4 addresses. That is because the
current version of the DOCSIS protocols (1.0, 1.1, and 2.0) are not
IPv6 capable. Although support for IPv6 will require changes to the
DOCSIS protocols, it is expected that the only changes to the MIB
module itself will be the addition of new compliance statements that
mandate support for IPv6 addresses. All IP addresses that appear in
this document conform to the textual conventions specified in
[RFC4001].
3.2. Management Requirements
The DOCSIS cable modem provisioning model [ITU-T-J122] 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 itself need not 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 to reduce data and to ease administrative control.
Filtering criteria, for example, are maintained through SNMP at the
CMTS, and the modem registration merely signals the index values for
the rows that apply to that modem.
3.2.1. Interaction with DOCSIS Provisioning for CPE Address Control
The CMTS creates rows in docsSubMgtCpeControlTable 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 section of the DOCSIS Cable Device MIB [RFC2669]:
o docsDevCpeEnroll
o docsDevCpeIpMax
o docsDevCpeIp
Successful DOCSIS registration will have the effect of setting the
corresponding fields in the docsSubMgtCpeControlTable and the
docsSubMgtCpeIpTable. If they are not present at modem registration,
the CMTS shall apply the following:
o docsSubMgtCpeControlActive <-- docsSubMgtCpeActiveDefault
o docsSubMgtCpeControlMaxCpeIp <-- docsSubMgtCpeMaxIpDefault
o docsSubMgtCpeControlLearnable <-- docsSubMgtCpeLearnableDefault
Rows in docsSubMgtCpeIpTable are created through any of three ways:
DOCSIS registration (as described above), learning by the CMTS, or
some unspecified administrative mechanism on the CMTS. The
docsDevCpeIpMax table bound applies only to the first two.
The CMTS may learn addresses simply by snooping source IP addresses
from traffic originating from each cable modem. Other learning
mechanisms (for example, ARP snooping) may be used. The learning
mechanism is not defined by this document.
3.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 [ITU-T-J122]):
o One identifying the upstream (ingress with respect to the CMTS
interface) 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 (egress with respect to the CMTS
interface) 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 will have the effect of setting
docsSubMgtCmFilterCmDownstream, docsSubMgtCmFilterCmUpstream,
docsSubMgtCmFilterSubDownstream, and docsSubMgtCmFilterSubUpstream,
for that modem (just as if they were set through the SNMP protocol).
If the DOCSIS attributes are not present, the four values are set to
zero. The effect will be to use the default entry
(diffServClfrElementSpecific=zeroDotZero) specified in the
diffServClfrElementTable. Note that omission of the DOCSIS-signaled
values results in application of the default filtering entry, not in
omission of filtering.
3.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 by 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
docsSubMgtCmFilterCmUp/Downstream pair is used; otherwise, the
docsSubMgtCmFilterSubUp/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
docsSubMgtCmFilterCmUp/Downstream pair.
3.3. Relationship to the Differentiated Services MIB [RFC3289]
DOCSIS CMTSes 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 includes 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.
3.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, which are introduced in this document,
expand on RFC 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 that 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.
3.3.2. Interface Usage
For the 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.
3.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.
4. Definitions
DOCS-IETF-SUBMGT-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY,
OBJECT-TYPE,
Integer32,
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
diffServMIBDataPathGroup,
diffServMIBClfrGroup,
diffServMIBClfrElementGroup,
diffServMIBMultiFieldClfrGroup,
diffServMIBActionGroup,
diffServMIBAlgDropGroup,
diffServMIBCounterGroup,
diffServDataPathStatus,
diffServClfrStatus,
diffServClfrElementStatus,
diffServMultiFieldClfrAddrType,
diffServMultiFieldClfrSrcAddr,
diffServMultiFieldClfrDstAddr,
diffServAlgDropStatus,
diffServDataPathStorage,
diffServClfrStorage,
diffServClfrElementStorage,
diffServMultiFieldClfrStorage,
diffServActionStorage,
diffServCountActStorage,
diffServAlgDropStorage,
diffServAlgDropType
FROM DIFFSERV-MIB -- RFC3289
;
docsSubMgt MODULE-IDENTITY
LAST-UPDATED "200503290000Z" -- March 29, 2005
ORGANIZATION "IETF IP over Cable Data Network (IPCDN) Working
Group"
CONTACT-INFO
" Wilson Sawyer
Postal: 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. It provides the objects to allow a Cable
Modem Termination operator to control the IP addresses and
protocols associated with subscribers’ cable modems.
Copyright (C) The Internet Society (2005). This version of this
MIB module is part of RFC 4036; see the RFC itself for full legal
notices."
REVISION "200503290000Z" -- March 29, 2005
DESCRIPTION
"Initial version, published as RFC 4036. Note that the
compliance statements in this version apply only to
implementations that support DOCSIS 1.0/1.1/2.0, which
are not IPv6-capable."
::= { mib-2 125 }
docsSubMgtObjects OBJECT IDENTIFIER ::= { docsSubMgt 1 }
docsSubMgtCpeControlTable OBJECT-TYPE
SYNTAX SEQUENCE OF DocsSubMgtCpeControlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table AUGMENTs the docsIfCmtsCmStatusTable, adding
four WRITEable objects, as well as a read-only object, all of
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 (see
reference) is registrationComplete(6). The persistence of this
row is determined solely by the lifespan of the corresponding
docsIfCmtsCmStatusEntry (normally StorageType=volatile)."
REFERENCE
"RFC 2670"
AUGMENTS { docsIfCmtsCmStatusEntry }
::= {docsSubMgtCpeControlTable 1 }
DocsSubMgtCpeControlEntry ::= SEQUENCE
{
docsSubMgtCpeControlMaxCpeIp Integer32,
docsSubMgtCpeControlActive TruthValue,
docsSubMgtCpeControlLearnable TruthValue,
docsSubMgtCpeControlReset TruthValue,
docsSubMgtCpeControlLastReset TimeStamp
}