RFC 4036
Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modem Termination Systems for Subscriber Management
Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modem Termination Systems for Subscriber Management 🎀
Okay bestie, here's the vibe check on this RFC 🫶
- Document: RFC 4036
- Author: W. Sawyer
- Stream: Network Working Group
- Category: Standards Track
- Date: April 2005
- Obsoletes / Updates: The title block doesn't list anything it obsoletes or updates, so there's nothing to report there 💅
This is the MIB for managing Cable Modem Termination Systems (CMTS) from SNMP. It's all about keeping subscribers in their lane 🚦✨
Status of This Memo ✨
Bestie, this part is the official fine print. This document specifies an Internet standards track protocol for the Internet community, and it asks for discussion and suggestions for improvements. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 💖
Copyright Notice 🌸
Copyright (C) The Internet Society (2005).
Abstract 🦋
Okay so this memo defines a chunk of the Management Information Base (MIB) for network management protocols in the Internet community. Specifically, it's 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 help protect the cable network from misuse by subscribers, which is honestly so iconic 👑 The Differentiated Services MIB (RFC 3289) provides the filtering functions needed here, using the 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.......................................... 271. The Internet-Standard Management Framework ✨
If you want the full tea on the documents that describe the current Internet-Standard Management Framework, check section 7 of RFC 3410 [RFC3410] 📚
Managed objects are accessed via a virtual information store called the Management Information Base, or MIB. MIB objects are usually accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant with SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580] 🍓
2. Conventions 🧚
Okay so 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 gives you a set of objects needed to manage DOCSIS Cable Modem Termination Systems (CMTS). The spec is partly derived from the operational model in the DOCSIS Radio Frequency Interface Specification [ITU-T-J122]. These managed objects help protect the cable network from misuse by subscribers. That misuse could include things like address spoofing, service spoofing, or running unauthorized services 🙈
The figure below shows how the operational and physical pieces fit together in a cable modem network. This MIB module lives at the CMTS, which is the first point in the public data network where the cable operator controls physical access. So the CMTS (maybe with help from other IP service devices) is the 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 networkThis MIB module controls IP packet forwarding to and from each cable modem, at the CMTS. Different modems can get different treatment, which is giving main character energy 👑
A lot of this module overlaps with the DOCSIS Cable Device MIB [RFC2669]. The Cable Device MIB is expected to be used to keep unwanted traffic out of the cable network, but a sneaky user could tamper with the cable modem software and disable its filtering policies. This MIB offers a more secure mechanism, since the network operator controls physical access to the CMTS 🔒
This MIB gives you two main capabilities. First, it limits the IP addresses behind a modem. Second, it provides address and protocol filtering to and from a modem. The first one duplicates the capabilities of the docsDevCpe group [RFC2669]. It allows either learned or provisioned subscriber premises host IP addresses behind a cable modem 🌸
The address and protocol filtering is similar to what the cable modem does itself, but it's different in a few ways because it controls subscriber traffic at the CMTS instead of at the individual CM. First, the MIB structure has to be indexed properly at the CMTS to show which cable modem subscriber is meant. Second, instead of keeping a separate filter list for each modem at the CMTS, the design assumes that lots of modems will share the same filtering characteristics. So modems get grouped to share common filter lists ✨
The filtering works using the Classification, Counting, and Drop facilities of the Differentiated Services MIB [RFC3289]. To give different filtering to different classes of subscribers, this MIB defines the docsSubMgtFilterGroupTable, which says which filters apply to each subscriber packet. This table is used by RFC 3289 as a first pass of classification, and it's also used to pick 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)Since lots of modems are expected to share filtering characteristics, DOCSIS signaling defines filter groups based on 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:
- The
docsSubMgtCpeControlTablecontrols the acceptance of subscriber host addresses behind a cable modem. - The
docsSubMgtCpeIpTablemonitors the subscriber host addresses that the CMTS believes exist behind the cable modem. - The
docsSubMgtCmFilterTablebinds a cable modem to a set of filters indiffServMultiFieldClfrTable. - The
docsSubMgtFilterGroupTableprovides the OIDs by which thediffServClfrElementTableselects a filter group.
The docsSubMgtCpeControlTable and docsSubMgtCmFilterTable AUGMENT the docsIfCmtsCmStatusTable from [RFC2670]. Similarly, docsSubMgtCpeIpTable expands this table (it uses an additional index). So every entry in these tables is bound to a registered cable modem, as the CMTS sees it 🦋
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, so this table exists to provide the referenced objects for diffServClfrElementSpecific. The classification method goes like this:
- Use the DOCSIS filter group, as inferred from the sending or receiving modem, as the classification criterion.
- Use
docsSubMgtFilterGroupIndexas the value to match.
An entry exists in this table if a reference to it exists in diffServClfrElementSpecific.
So, 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 🌐
Heads up: the compliance statements in this version of the MIB module only require support for IPv4 addresses. That's because the current versions of the DOCSIS protocols (1.0, 1.1, and 2.0) are not IPv6 capable. Support for IPv6 will need changes to the DOCSIS protocols, and it's expected that the only changes to the MIB module itself will be new compliance statements that mandate support for IPv6 addresses. All IP addresses 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 CMTS verifies the signature. So in general, the CMTS itself doesn't need to be configured with the attributes of its cable modems. It gets these values through the Registration process, which is secured by the digital signature 🔐
Cable modem subscriber management, as described here, tweaks this process a little to reduce data and make administrative control easier. Filtering criteria, for example, are maintained through SNMP at the CMTS, and the modem registration just signals the index values for the rows that apply to that modem 🫶
3.2.1. Interaction with DOCSIS Provisioning for CPE Address Control 💅
okay so the CMTS creates rows in docsSubMgtCpeControlTable for each modem as part of the DOCSIS registration process 🫶 the registration attributes might include stuff that's basically the same as the stuff in the docsDevCpe section of the DOCSIS Cable Device MIB [RFC2669]:
docsDevCpeEnrolldocsDevCpeIpMaxdocsDevCpeIp
a successful DOCSIS registration sets the matching fields in docsSubMgtCpeControlTable and docsSubMgtCpeIpTable ✨ if those aren't there when the modem registers, the CMTS shall apply these defaults:
docsSubMgtCpeControlActive <-- docsSubMgtCpeActiveDefaultdocsSubMgtCpeControlMaxCpeIp <-- docsSubMgtCpeMaxIpDefaultdocsSubMgtCpeControlLearnable <-- docsSubMgtCpeLearnableDefault
rows in docsSubMgtCpeIpTable can be created in three ways: DOCSIS registration (the thing we just talked about), the CMTS learning addresses, or some unspecified administrative mechanism on the CMTS 🌸 the docsDevCpeIpMax table bound only applies to the first two, so the admin route doesn't count. main character energy for the bound, honestly 🦋
the CMTS may learn addresses just by snooping source IP addresses from traffic coming from each cable modem 👀 other learning mechanisms (for example, ARP snooping) may be used too. the learning mechanism itself is not defined by this document, so that's a whole other story 💜
3.2.2. Interaction with DOCSIS Provisioning for Filtering 🎀
rows in docsSubMgtCmFilterTable get created by the CMTS for each modem as part of the DOCSIS registration process ✨ the registration attributes may include four indices (see section C.1.1.18.3 of [ITU-T-J122]):
- 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).
- 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).
- 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).
- 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).
a successful registration sets docsSubMgtCmFilterCmDownstream, docsSubMgtCmFilterCmUpstream, docsSubMgtCmFilterSubDownstream, and docsSubMgtCmFilterSubUpstream for that modem, just as if they'd been set through the SNMP protocol 🔥 if the DOCSIS attributes aren't there, all four values get set to zero. that means the modem uses the default entry (diffServClfrElementSpecific=zeroDotZero) from the diffServClfrElementTable 🧚
omission of the DOCSIS-signaled values gives you the default filtering entry, NOT no filtering at all. read that twice bestie 🙈
3.2.3. Distinguishing Modem from Subscriber Traffic 💖
all traffic going to or coming from a subscriber site is potentially suspect and subject to suppression by the network operator 😭 that's true even when the traffic is sourced or sunk by the cable modem itself instead of the subscriber hosts behind it. for more nuanced admin control, this document allows separate filter policies for modems and hosts. for example, modem policies might limit modems to server-subnet-only access while subscribers get a different scope 🌈
the CMTS picks the filter set to apply based only on the MAC address (source MAC upstream, destination MAC downstream). if the MAC address matches the modem's, the docsSubMgtCmFilterCmUp/Downstream pair is used. otherwise, the docsSubMgtCmFilterSubUp/Downstream pair is applied ✨
if the CM acts as a router rather than as a DOCS IS 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's expected that any implementation of this MIB also includes at least the following from RFC 3289:
diffServDataPathTablediffServClfrTablediffServClfrElementTablediffServMultiFieldClfrTablediffServActionTablediffServCountActTablediffServAlgDropTable(diffServAlgDropType=alwaysDrop)
the corresponding "next-free" objects are also required 🥹
using other facilities from RFC 3289 isn't precluded, but it's beyond the scope of this spec 💅
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 get classified by the same criteria. so, Filter Groups (introduced in this document) expand on RFC 3289 to let different subscribers get different classification (filtering) treatment 💜 one way to picture filter groups is as sub-interfaces inside the physical DOCSIS channel. another way is as a value of a field logically prepended to the packet before classification:
[filter group][DOCSIS MAC header][IP header]...of course this 'logical' field has no existence outside of the CMTS 👑
the diffServClfrTable and diffServClfrElementTable get 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 that second match may be a 'count' (and accept), a 'drop', or some other feature from RFC 3289 🔥
3.3.2. Interface Usage 🌈
for DOCSIS subscriber management, only the DOCSIS MAC cable interface(s) are used. the interface shows up as the index to diffServDataPathEntry, which is the starting point for diffserv MIB table traversal ✨
using the diffserv MIB for other purposes, both on the DOCSIS MAC interfaces and on other network interfaces, isn't precluded by this document 🧚
3.4. Filtering and the Tiny Fragment Attack 🛡️
it is recommended that 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] 😭
preventing these attacks can be done with the following rules, when filtering is enabled:
- Admit all packets with fragment offset
>= 2. - Discard all packets with fragment offset
= 1, or with fragment offset= 0AND fragment payload length< 16. - 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 }Okay bestie, this part is all about the MIB definitions, so it's pure code, no cap 💅✨ Every object, default, and index is copied exactly, so nothing gets lost in translation 🦋
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. (For example,
if the CM has 5 IP addresses specified for it, this value is 5.)
This limit applies to learned and DOCSIS-provisioned entries
but not to 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
"Controls the application of subscriber management to
this cable modem. 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
"Controls whether the CMTS may learn (and pass traffic
for) CPE IP addresses associated with a cable modem. 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."
DEFVAL { 0 }
::= { docsSubMgtCpeControlEntry 5 }
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. This value should
be treated as nonvolatile; if set, its value should persist
across device resets."
DEFVAL { 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. This value should
be treated as nonvolatile; if set, its value should persist
across device resets."
DEFVAL { 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. This value should
be treated as nonvolatile; if set, its value should persist
across device resets."
DEFVAL { 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, and 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 docsSubMgtCpeControlActive is true and a CMTS receives
an IP packet from a CM that contains a source IP address that
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, then the packet is
dropped."
::= { 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.
The type of this address is determined by the value of
docsSubMgtCpeIpAddressType."
::= { 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, identifying for each modem
the upstream and downstream filter groups that apply to packets
for that modem. Normally, this table reflects the filter group
values signaled by DOCSIS Registration, although values may be
overridden by management action.
For each of the columns in this table, zero is a distinguished
value, indicating that the default filtering action is to be
taken rather than that associated with a filter group number.
Zero is used if the filter group is not signaled by DOCSIS
registration."
::= { 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 (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 }
::= {docsSubMgtCmFilterTable 1 }
DocsSubMgtCmFilterEntry ::= SEQUENCE
{
docsSubMgtCmFilterSubDownstream Integer32,
docsSubMgtCmFilterSubUpstream Integer32,
docsSubMgtCmFilterCmDownstream Integer32,
docsSubMgtCmFilterCmUpstream Integer32
}
docsSubMgtCmFilterSubDownstream OBJECT-TYPE
SYNTAX Integer32(0..65535)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The filter group applied to traffic destined for subscribers
attached to the referenced CM. Upon row creation, this is set
either to zero (use default classification, the
diffServClfrElementSpecific=zeroDotZero row of
diffServClfrElementTable) 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 that of the filter group
index appearing as docsSubMgtFilterGroupIndex."
::= { docsSubMgtCmFilterEntry 1 }
docsSubMgtCmFilterSubUpstream OBJECT-TYPE
SYNTAX Integer32(0..65535)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The filter group applied to traffic originating from
subscribers attached to the referenced CM. Upon row creation
this is set to either zero (use default classification, the
diffServClfrElementSpecific=zeroDotZero row of
diffServClfrElementTable), 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 that of the filter group index appearing as
docsSubMgtFilterGroupIndex."
::= { docsSubMgtCmFilterEntry 2 }
docsSubMgtCmFilterCmDownstream OBJECT-TYPE
SYNTAX Integer32(0..65535)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The filter group applied to traffic destined for the
referenced CM itself. Upon row creation this is set either to
zero (use default classification, the
diffServClfrElementSpecific=zeroDotZero row of
diffServClfrElementTable), 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 that of the filter group
index appearing as docsSubMgtFilterGroupIndex."
::= { docsSubMgtCmFilterEntry 3 }Okay so this is where the actual MIB lives, and it's giving very precise, very serious spec energy 🎀 Every line matters, so I'm keeping the code exactly as it is 💅
docsSubMgtCmFilterCmUpstream OBJECT-TYPE
SYNTAX Integer32(0..65535)
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, the
diffServClfrElementSpecific=zeroDotZero row of
diffServClfrElementTable), 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 referenceable entries to which
diffServClfrElementSpecific refers. This table provides filter
group indices that 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
that 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 }
DocsSubMgtFilterGroupEntry ::= SEQUENCE
{
docsSubMgtFilterGroupIndex Integer32
}
docsSubMgtFilterGroupIndex OBJECT-TYPE
SYNTAX Integer32(1..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The filter group index, from the set signaled at DOCSIS
Registration. Provides a referenceable entry to which
diffServClfrElementSpecific points. A packet matches this
classifier 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 SMI custom of making indices
not-accessible.
Note that although zero may be signaled (or defaulted) at DOCSIS
Registration to indicate a default filtering group, no such entry
appears in this table, as diffServClfrElementSpecific will
use a zeroDotZero pointer for that classification."
::= { 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.
This compliance statement applies to implementations that
support DOCSIS 1.0/1.1/2.0, which are not IPv6 capable."
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) }
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
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
addresses."
OBJECT docsSubMgtCpeIpAddr
SYNTAX InetAddress (SIZE(4))
DESCRIPTION
"An implementation is only required to support IPv4
addresses."
OBJECT docsSubMgtCmFilterSubDownstream
SYNTAX Integer32(0..30)
DESCRIPTION
"An implementation is only required to support thirty
filter groups."
OBJECT docsSubMgtCmFilterSubUpstream
SYNTAX Integer32(0..30)
DESCRIPTION
"An implementation is only required to support thirty
filter groups."
OBJECT docsSubMgtCmFilterCmDownstream
SYNTAX Integer32(0..30)
DESCRIPTION
"An implementation is only required to support thirty
filter groups."
OBJECT docsSubMgtCmFilterCmUpstream
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,
docsSubMgtCmFilterSubDownstream,
docsSubMgtCmFilterSubUpstream,
docsSubMgtCmFilterCmDownstream,
docsSubMgtCmFilterCmUpstream,
docsSubMgtFilterGroupIndex
}
STATUS current
DESCRIPTION
"The objects used to manage host-based cable modems
via a set of CMTS enforced controls."
::= { docsSubMgtGroups 1 }
END5. Acknowledgements 🙏
This whole document is built on work by Michael St. Johns, who was at Excite@Home back then 🌸 Huge thanks to Guenter Roeck and Julie McGray for reviewing the earlier versions, and to Bert Wijnen, Mike Heard, and Harrie Hazewinkel for the extensive later review 💜 Also a big shoutout to the working group chairs, Richard Woundy and Jean-Francois Mule, for all their extensive support 👑
6. IANA Considerations 🦋
The MIB module defined in this document uses the following IANA-assigned OBJECT IDENTIFIER value, which is recorded in the SMI Numbers registry:
Descriptor OBJECT IDENTIFIER value
---------- -----------------------
docsSubMgt { mib-2 125}7. Normative References 📚
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information 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.
- [ITU-T-J122] Second-Generation Transmission Systems for Interactive Cable Television Services, J.122, ITU-T, December, 2002.
- [RFC2670] St. Johns, M., "Radio Frequency (RF) Interface Management Information Base for MCNS/DOCSIS compliant RF interfaces", RFC 2670, August 1999.
- [RFC3289] Baker, F., Chan, K., and A. Smith, "Management Information Base for the Differentiated Services Architecture", RFC 3289, May 2002.
- [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005.
8. Informative References ✨
okay bestie, this is the extra-reading shelf 📚 the RFCs and specs the author pointed to for more context, and I'm listing every single one with all its details 💅
[RFC1858]Ziemba, G., Reed, D., and P. Traina, "Security Considerations for IP Fragment Filtering", RFC 1858, October 1995.[RFC2669]St. Johns, M., "DOCSIS Cable Device MIB Cable Device Management Information Base for DOCSIS compliant Cable Modems and Cable Modem Termination Systems", RFC 2669, August 1999.[RFC3128]Miller, I., "Protection Against a Variant of the Tiny Fragment Attack (RFC 1858)", RFC 3128, 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+-I11-040407", DOCSIS, April 2004, available athttp://www.cablemodem.com/and athttp://www.cablelabs.com/specifications/archives.
9. Security Considerations 🔒
okay this part is SERIOUS, so pay attention 👀 this MIB is meant to limit certain kinds of network behavior by subscriber hosts sitting behind cable modems. IP spoofing is the big example. BUT, and this is a huge but 😭, those limits can get bypassed if the cable modem's identity or its registration process gets spoofed. The DOCSIS RFI and privacy specs, [ITU-T-J122] and [DOCSBPI], lay out a bunch of mechanisms for making sure the modem is who it says it is.
For network filtering of TCP traffic to actually work, implementors MUST follow the recommendations in section 3.4. No skipping, no vibes-based filtering 🙅♀️
This MIB also has a bunch of management objects with a MAX-ACCESS clause of read-write and/or read-create. Those objects might be sensitive or vulnerable depending on the network. Letting anyone SET them in an unprotected environment can seriously mess up network operations 🤯
Unauthorized SETs to this MIB can open up two major security problems for public cable networks: IP address spoofing, and defeating the operator's packet filtering. Chaotic 💀
These objects, if SET maliciously, would dodge the controls on address spoofing:
docsSubMgtCpeControlMaxCpeIp
docsSubMgtCpeControlActive
docsSubMgtCpeControlLearnable
docsSubMgtCpeControlReset
docsSubMgtCpeMaxIpDefault
docsSubMgtCpeActiveDefault
docsSubMgtCpeLearnableDefaultThese ones could also let someone defeat packet filtering:
docsSubMgtCmFilterSubDownstream
docsSubMgtCmFilterSubUpstream
docsSubMgtCmFilterCmDownstream
docsSubMgtCmFilterCmUpstreamSome of the readable objects in this MIB (anything with a MAX-ACCESS other than not-accessible) can be sensitive too 🫣 so it's important to lock down even GET access, and maybe even encrypt their values when they travel over the network via SNMP. The most sensitive one is docsSubMgtCpeIpAddr inside docsSubMgtCpeIpTable. That table exists to control address spoofing, BUT it also shows the current subscriber address pool, and that info is seriously valuable to would-be spoofers 👀
SNMP versions before SNMPv3 didn't include adequate security. Even if the network itself is secure (say, by using IPSec), there's no control over who on that secure network gets to GET/SET (read/change/create/delete) the objects in this MIB module 😤
It is RECOMMENDED that implementers consider the security features provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms for authentication and privacy. Main character energy for security 🔐
Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and turn on cryptographic security. After that, it's on the customer or operator to make sure the SNMP entity giving access to this MIB module is configured so only the principals (users) with legitimate rights to GET or SET (change/create/delete) the objects can do it 🫶
Author's Address 🏡
Wilson Sawyer
50 Kelly Brook Lane
East Hampstead NH 03826
Phone: +1 603 382 7080
EMail: wsawyer@ieee.orgFull Copyright Statement ©️
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🧾
The IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described here, or on whether any license under those rights might or might not be available. It also doesn't claim to have made any independent effort to identify such rights. Info on how rights work for RFC documents is in BCP 78 and BCP 79 📚
Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users to use those proprietary rights can be found in the IETF online IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology required to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 📬
Acknowledgement 🌸
Funding for the RFC Editor function is currently provided by the Internet Society. Thank you, Internet Society 🫶✨
📦 where this page comes from
- ietf: rfc4036 2005-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms