INTERNET-DRAFT DOCSIS Subscriber Management MIB February 2002 Management Information Base for DOCSIS Cable Modem Termination Systems for Subscriber Management draft-ietf-ipcdn-subscriber-mib-06.txt Mon Feb 28 16:00:00 EST 2002 Wilson Sawyer ARRIS wsawyer@ieee.org Status of this Memo This document is an Internet-Draft and is in full conformance with 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 an experimental 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 DOCSIS-compliant[16] Cable Modem Termination Systems. These managed objects facilitate protection of the cable network from misuse by subscribers. This memo specifies a MIB module in a manner that is compliant to the SNMP SMIv2 [5][6][7]. The set of objects are consistent with the SNMP framework and existing SNMP standards. 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 authors. Expires August 2002 [Page 1] INTERNET-DRAFT DOCSIS Subscriber Management MIB February 2002 Table of Contents 1. The SNMP Network Management Framework..............................2 2. Overview...........................................................3 2.1. Structure of the MIB.............................................3 2.2. Management requirements..........................................4 2.2.1. Interaction with DOCSIS provisioning for CPE address control...4 2.2.2. Interaction with DOCSIS provisioning for filtering.............5 2.2.3. Distinguishing Modem from Subscriber Traffic...................5 2.2.4. Row Existence of docsSubMgtTcpUdpFilterTable...................6 2.2.5. Notes on Table Bounds..........................................6 2.2.6. Filtering and the Tiny Fragment Attack.........................6 3. Definitions........................................................7 4. Acknowledgments...................................................23 5. References........................................................24 6. Security Considerations...........................................25 7. Author's Address..................................................26 8. Intellectual Property.............................................26 9. Full Copyright Statement..........................................27 1. The SNMP Network Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [1]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in STD 58, RFC 2578 [5], STD 58, RFC 2579 [6] and STD 58, RFC 2580 [7]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and RFC 2574 [12]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. o A set of fundamental applications described in RFC 2573 [14] and the view-based access control mechanism described in RFC 2575 [15]. A more detailed introduction to the current SNMP Management Framework Expires August 2002 [Page 2] INTERNET-DRAFT DOCSIS Subscriber Management MIB February 2002 can be found in RFC 2570 [21]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB MUST be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. 2. 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 [16]. These managed objects facilitate protection of the cable network from misuse by subscribers. Much of this MIB duplicates capabilities found in the DOCSIS Cable Device MIB [17]. 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 [17]. This provides for either learned or provisioned subscriber premises host IP addresses behind a cable modem. The filtering capability is similar to that provided in docsDevFilter [17]. Rather than maintaining a separate list of filters for each modem at the CMTS, however, it is assumed that large numbers of modems will share filtering characteristics. Therefore, modems are grouped so as to share common filter lists. 2.1. Structure of the MIB This MIB is structured in five tables: o The docsSubMgtCpeControlTable controls the acceptance of subscriber host addresses behind a cable modem. Expires August 2002 [Page 3] INTERNET-DRAFT DOCSIS Subscriber Management MIB February 2002 o The docsSubMgtCpeIpTable monitors the subscriber host addresses which the CMTS believes to exist behind the cable modem. o The docsSubMgtPktFilterTable specifies filtering criteria which can be applied to packets destined to or originating from a cable modem. o The docsSubMgtTcpUdpFilterTable augments docsSubMgtPktFilterTable with optional TCP or UDP port filtering criteria. o The docsSubMgtCmFilterTable binds a cable modem to an ordered list of filters from docsSubMgtPktFilterTable. The docsSubMgtCpeControlTable, docsSubMgtCpeIpTable, and docsSubMgtCmFilterTable augment the docsIfCmtsCmStatusTable from [18]. As such, each entry in these tables is bound to a registered cable modem, as perceived by the CMTS. The docsSubMgtPktFilterTable uses two indices. The first identifies the group to which a cable modem may be bound. The second is the ordering of filter criteria within each group. Any number of modems may be bound to the same group. 2.2. Management requirements The DOCSIS cable modem provisioning model 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 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 [17]: o docsDevCpeEnroll o docsDevCpeIpMax o docsDevCpeIp Expires August 2002 [Page 4] INTERNET-DRAFT DOCSIS Subscriber Management MIB February 2002 Successful DOCSIS registration shall have the effect of setting the corresponding fields in the docsSubMgtCpeControlTable and the docsSubMgtCpeIpTable. If not present, the default at registration shall be to set docsSubMgtCpeControlActive to false. Rows in docsSubMgtCpeIpTable are created through any of three ways: DOCSIS registration (as described above), learning by the CMTS, or through some unspecified administrative mechanism on the CMTS. The docsDevCpeIpMax table bound applies only to the first two. The CMTS may learn addresses by simply snooping source IP addresses from each cable modem. Other learning mechanisms (for example, ARP snooping) may be used. The learning mechanism is not defined by this document. 2.2.2. Interaction with DOCSIS provisioning for filtering Rows in docsSubMgtCmFilterTable are created by the CMTS for each modem as a result of the DOCSIS registration process. The DOCSIS registration attributes may include four indices: o one identifying the upstream filter group for packets originating from the cable modem (i.e., those packets whose source MAC address matches that of the cable modem). o one identifying the upstream filter group for packets originating from subscribers attached to the cable modem (i.e., those packets whose source MAC address does not match that of the cable modem). o one identifying the downstream filter group for packets destined to the cable modem (i.e., those packets whose destination MAC address matches that of the cable modem). o one identifying the downstream filter group for packets destined to subscribers attached to the cable modem (i.e., those packets whose destination MAC address does not match that of the cable modem). Successful registration shall have the effect of setting docsSubMgtCmFilterDownstream, docsSubMgtCmFilterUpstream, docsSubMgtSubFilterDownstream, and docsSubMgtSubFilterUpstream, for that modem (just as if set through the SNMP protocol). If the DOCSIS attributes are not present, the effect shall be to set the modem's filter groups to the values of docsSubMgtCmFilterUpDefault, docsSubMgtCmFilterDownDefault, docsSubMgtSubFilterUpDefault, and docsSubMgtSubFilterDownDefault. 2.2.3. Distinguishing Modem from Subscriber Traffic All traffic originating from or destined to a subscriber site is potentially suspect, and subject to suppression by the network operator. This is true even if the traffic is ostensibly sourced or sunk by the cable modem itself, rather than the subscriber hosts behind the modem. To provide more nuanced administrative control, this document allows separate filter policies for modems and hosts. Expires August 2002 [Page 5] INTERNET-DRAFT DOCSIS Subscriber Management MIB February 2002 For example, modem policies may limit modems to server-subnet-only access, while allowing a different scope to subscribers. The CMTS chooses the filter set to apply based solely on the MAC address (source MAC upstream, destination MAC downstream). If the MAC address matches that of the modem, then the docsSubMgtCmFilterUp/Downstream pair is used; otherwise the docsSubMgtSubFilterUp/Downstream pair is applied. If the CM acts as a router rather than as a DOCSIS bridging forwarder, then the network operator will only use the docsSubMgtCmFilterUp/Downstream pair. 2.2.4. Row Existence of docsSubMgtTcpUdpFilterTable The docsSubMgtTcpUdpFilterTable exists apart from the docsSubMgtPktFilterTable because its filtering criteria is expected to be applied to a minority of modems relative to docsSubMgtPktFilterTable. It is separate in order to emphasize this expectation to both CMTS vendors and network operators. The rules for row creation are: o Row creation in docsSubMgtTcpUdpFilterTable is disallowed unless the corresponding row in docsSubMgtPktFilterTable already exists (or that row is being created simultaneously in the same SNMP SET message). o Deletion of the row in docsSubMgtPktFilterTable deletes the corresponding row in docsSubMgtTcpUdpFilterTable. o Row creation for docsSubMgtPktFilterTable does not create the corresponding row in docsSubMgtTcpUdpFilterTable. o Row deletion of docsSubMgtTcpUdpFilterTable does not delete the corresponding row in docsSubMgtPktFilterTable. 2.2.5. Notes on Table Bounds Throughout this document, index bounds for both filter groups and filters within a group are arbitrarily set at 1024. This does not impose a minimum requirement, but is chosen to be sufficiently large for any expected implementation. It is expected that the Data over Cable System Interface Specification (DOCSIS) process will define minimum-supported-size bounds for these objects for DOCSIS-compliant devices, but that is beyond the scope of this document. Early DOCSIS discussions anticipated a requirement for thirty groups of twenty filters each. Similarly, the maximum number of CPE addresses is arbitrarily bounded at 1024, although the corresponding modem table for the cable device MIB [17] is bounded at 16. 2.2.6. Filtering and the Tiny Fragment Attack It is recommended that the implementers prevent the "tiny fragment" Expires August 2002 [Page 6] INTERNET-DRAFT DOCSIS Subscriber Management MIB February 2002 and "overlapping fragment" attacks for the TCP filtering tables in this MIB, as discussed in RFC 1858 [22] and RFC 3128 [23]. Prevention of these attacks can be implemented with the following rules, when filtering is enabled: o admit all packets with fragment offset >= 2 o discard all packets with fragment offset = 1, or with fragment offset = 0 AND fragment payload length < 16. o apply filtering rules to all packets with fragment offset = 0. 3. Definitions DOCS-SUBMGT-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, Integer32 -- , BITS FROM SNMPv2-SMI RowStatus, TruthValue FROM SNMPv2-TC OBJECT-GROUP, MODULE-COMPLIANCE FROM SNMPv2-CONF InetAddressType, InetAddress FROM INET-ADDRESS-MIB docsDev FROM DOCS-CABLE-DEVICE-MIB -- RFC2669 docsIfCmtsCmStatusIndex, docsIfCmtsCmStatusEntry FROM DOCS-IF-MIB; -- RFC2670 docsSubMgt MODULE-IDENTITY LAST-UPDATED "0202280000Z" -- February 28, 2002 ORGANIZATION "IETF IPCDN Working Group" CONTACT-INFO " Wilson Sawyer Postal: ARRIS 6 Riverside Drive Andover, MA 01810 U.S.A. Phone: +1 978 946 4711 E-mail: wsawyer@ieee.org IETF IPCDN Working Group General Discussion: ipcdn@ietf.org Expires August 2002 [Page 7] INTERNET-DRAFT DOCSIS Subscriber Management MIB February 2002 Subscribe: http://www.ietf.org/mailman/listinfo/ipcdn Archive: ftp://ftp.ietf.org/ietf-mail-archive/ipcdn Co-chairs: Richard Woundy, rwoundy@cisco.com Andrew Valentine, a.valentine@eu.hns.com" DESCRIPTION "This is the CMTS centric subscriber management MIB for DOCSIS compliant CMTS. This will be rooted in experimental space with a future transition to be incorporated into the cable device MIB." REVISION "0202280000Z" -- February 28, 2002 DESCRIPTION "fixed typo in ULP description from -05" REVISION "0202180000Z" -- February 18, 2002 DESCRIPTION "Modified to incorporate ipcdn last-call comments. Re-rooted from experimental. Excluded docsSubMgtPktFilterUlp=ANY from docsSubMgtTcpUdpFilter processing. Clarified range for docsSubMgtCpeControlMaxCpeIp and applicability of docsSubMgtCpeControlActive." ::= { docsDev 5 } docsSubMgtObjects OBJECT IDENTIFIER ::= { docsSubMgt 1 } docsSubMgtCpeControlTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsSubMgtCpeControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table extends the docsIfCmtsCmStatusTable and adds 4 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 the values are either set from the system default, or are set from objects included in the DOCSIS registration request sent upstream to the CMTS from the CM." AUGMENTS { docsIfCmtsCmStatusEntry } ::= {docsSubMgtCpeControlTable 1 } DocsSubMgtCpeControlEntry ::= SEQUENCE { docsSubMgtCpeControlMaxCpeIp Integer32, docsSubMgtCpeControlActive TruthValue, docsSubMgtCpeControlLearnable TruthValue, docsSubMgtCpeControlReset TruthValue Expires August 2002 [Page 8] INTERNET-DRAFT DOCSIS Subscriber Management MIB February 2002 } docsSubMgtCpeControlMaxCpeIp OBJECT-TYPE SYNTAX Integer32(0..1023) MAX-ACCESS read-write STATUS current DESCRIPTION "The number of simultaneous IP addresses permitted behind the CM. If this is set to zero, all CPE traffic from the CM is dropped. If the provisioning object corresponding to docsSubMgtCpeIpTable includes more CPE IP address entries for this modem than the value of this object, then this object is set to the count of the number of rows in docsSubMgtCpeIpTable that have the same docsIfCmtsCmStatusIndex value. (E.g. if the CM has 5 IP addresses specified for it, this value is 5). This limit applies to learned and docsis-provisioned entries, but does not limit entries added through some administrative process at the CMTS. If not set through DOCSIS provisioning, this object defaults to docsSubMgtCpeMaxIpDefault. Note that this object is only meaningful if docsSubMgtCpeControlActive is true." ::= { docsSubMgtCpeControlEntry 1 } docsSubMgtCpeControlActive OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "If this is set to true, CMTS based CPE control is active and all the actions required by the various filter tables and controls apply at the CMTS. If this is set to false, no subscriber management filtering is done at the CMTS (but other filters may apply). If not set through DOCSIS provisioning, this object defaults to docsSubMgtCpeActiveDefault." ::= { docsSubMgtCpeControlEntry 2 } docsSubMgtCpeControlLearnable OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "If this is set to true, the CMTS may learn up to 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 } Expires August 2002 [Page 9] INTERNET-DRAFT DOCSIS Subscriber Management MIB February 2002 docsSubMgtCpeControlReset OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This object always returns false on read. If this object is set to true, the rows with 'learned' addresses in docsSubMgtCpeIpTable for this CM are deleted from that table." ::= { docsSubMgtCpeControlEntry 4 } docsSubMgtCpeMaxIpDefault OBJECT-TYPE SYNTAX Integer32(0..1024) MAX-ACCESS read-write STATUS current DESCRIPTION "The default value for docsSubMgtCpeControlMaxCpeIp if not signaled in the DOCSIS Registration request. Upon initial CMTS initialization, this defaults to 16." ::= { docsSubMgtObjects 2 } docsSubMgtCpeActiveDefault OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "The default value for docsSubMgtCpeControlActive if not signaled in the DOCSIS Registration request. Upon initial CMTS initialization, this defaults to false." ::= { docsSubMgtObjects 3 } docsSubMgtCpeLearnableDefault OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "The default value for docsSubMgtCpeControlLearnable if not signaled in the DOCSIS Registration request. Upon initial CMTS initialization, this defaults to true." ::= { docsSubMgtObjects 4 } docsSubMgtCpeIpTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsSubMgtCpeIpEntry MAX-ACCESS not-accessible STATUS current 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 Expires August 2002 [Page 10] INTERNET-DRAFT DOCSIS Subscriber Management MIB February 2002 "An entry in the docsSubMgtCpeIpTable. The first index is the specific modem we're referring to, the second index is the specific CPE IP entry." INDEX { docsIfCmtsCmStatusIndex, docsSubMgtCpeIpIndex } ::= {docsSubMgtCpeIpTable 1 } DocsSubMgtCpeIpEntry ::= SEQUENCE { docsSubMgtCpeIpIndex Integer32, docsSubMgtCpeIpAddressType InetAddressType, docsSubMgtCpeIpAddr InetAddress, docsSubMgtCpeIpLearned TruthValue } docsSubMgtCpeIpIndex OBJECT-TYPE SYNTAX Integer32(1..1024) 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 wiretapping. See docsSubMgtCpeIpIndex for the mechanism." ::= { docsSubMgtCpeIpEntry 3 } docsSubMgtCpeIpLearned OBJECT-TYPE SYNTAX TruthValue Expires August 2002 [Page 11] INTERNET-DRAFT DOCSIS Subscriber Management MIB February 2002 MAX-ACCESS read-only STATUS current DESCRIPTION "If true, this entry was learned from IP packets sent upstream rather than from the provisioning objects." ::= { docsSubMgtCpeIpEntry 4 } -- The generic packet filter table. Note that this just defines the -- match criteria. The docsSubMgtCmFilterTable links this table to -- the specific modems. docsSubMgtPktFilterTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsSubMgtPktFilterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of filter or classifier criteria. Classifiers are assigned by group to the individual CMs. That assignment is made via the configuration objects sent upstream from the CM to the CMTS during registration." ::= { docsSubMgtObjects 6 } docsSubMgtPktFilterEntry OBJECT-TYPE SYNTAX DocsSubMgtPktFilterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the docsSubMgtPktFilterTable." INDEX { docsSubMgtPktFilterGroup, docsSubMgtPktFilterIndex } ::= {docsSubMgtPktFilterTable 1 } DocsSubMgtPktFilterEntry ::= SEQUENCE { docsSubMgtPktFilterGroup Integer32, docsSubMgtPktFilterIndex Integer32, docsSubMgtPktFilterSrcAddrType InetAddressType, docsSubMgtPktFilterSrcAddr InetAddress, docsSubMgtPktFilterSrcMaskType InetAddressType, docsSubMgtPktFilterSrcMask InetAddress, docsSubMgtPktFilterDstAddrType InetAddressType, docsSubMgtPktFilterDstAddr InetAddress, docsSubMgtPktFilterDstMaskType InetAddressType, docsSubMgtPktFilterDstMask InetAddress, docsSubMgtPktFilterUlp Integer32, docsSubMgtPktFilterTosValue OCTET STRING, docsSubMgtPktFilterTosMask OCTET STRING, docsSubMgtPktFilterAction INTEGER, docsSubMgtPktFilterMatches Counter32, docsSubMgtPktFilterStatus RowStatus } Expires August 2002 [Page 12] INTERNET-DRAFT DOCSIS Subscriber Management MIB February 2002 docsSubMgtPktFilterGroup OBJECT-TYPE SYNTAX Integer32(1..1024) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Identifies an ordered group of filters. Each modem may be associated with a filter group for its upstream traffic (docsSubMgtCmFilterUpstream) and a filter group for its downstream traffic (docsSubMgtCmFilterDownstream). Typically, many modems will use the same filter group." ::= { docsSubMgtPktFilterEntry 1 } docsSubMgtPktFilterIndex OBJECT-TYPE SYNTAX Integer32(1..1024) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index which describes the ordering of a set of filter specifications within the group. Filters are applied in index order." ::= { docsSubMgtPktFilterEntry 2 } docsSubMgtPktFilterSrcAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "The type of internet address of docsSubMgtPktFilterSrcAddr." DEFVAL { ipv4 } ::= { docsSubMgtPktFilterEntry 3 } docsSubMgtPktFilterSrcAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The source IP address to match in the packet to be classified. By default, this is the all-zero's IP v4 and v6 address. A packet matches the SrcAddr filter if the following is true: AND (FilterSrcAddr, FilterSrcMask) == AND (Packet SrcAddr, FilterSrcMask). The mask value is applied to both the match value in this table and to the packet IP address." ::= { docsSubMgtPktFilterEntry 4 } docsSubMgtPktFilterSrcMaskType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "The type of internet address of docsSubMgtPktFilterSrcMask." Expires August 2002 [Page 13] INTERNET-DRAFT DOCSIS Subscriber Management MIB February 2002 DEFVAL { ipv4 } ::= { docsSubMgtPktFilterEntry 5 } docsSubMgtPktFilterSrcMask OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "A bit mask that is to be applied to the source address prior to matching. This, taken with the SrcAddr specifies a matching criteria. By default, the pair specifies a filter which matches all source addresses. This mask is not necessarily the same as a subnet mask, but for IPv4 addresses the 1's bits must be leftmost and contiguous. IPv6 masks have no such restriction." DEFVAL { ''h } ::= { docsSubMgtPktFilterEntry 6 } docsSubMgtPktFilterDstAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "The type of internet address of docsSubMgtPktFilterDstAddr." DEFVAL { ipv4 } ::= { docsSubMgtPktFilterEntry 7 } docsSubMgtPktFilterDstAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The destination IP address to match in the packet to be classified. By default, this is the all-zero's IP v4 and v6 address. A packet matches the DstAddr filter if the following is true: AND (FilterDstAddr, FilterDstMask) == AND (Packet DstAddr, FilterDstMask). The mask value is applied to both the match value in this table and to the packet IP address." ::= { docsSubMgtPktFilterEntry 8 } docsSubMgtPktFilterDstMaskType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "The type of internet address of docsSubMgtPktFilterDstMask." DEFVAL { ipv4 } ::= { docsSubMgtPktFilterEntry 9 } docsSubMgtPktFilterDstMask OBJECT-TYPE SYNTAX InetAddress Expires August 2002 [Page 14] INTERNET-DRAFT DOCSIS Subscriber Management MIB February 2002 MAX-ACCESS read-create STATUS current DESCRIPTION "A bit mask that is to be applied to the destination address prior to matching. This, taken with the DstAddr specifies a matching criteria. By default, the pair specifies a filter which matches all destination addresses. This mask is not necessarily the same as a subnet mask, but for IPv4 addresses the 1's bits must be leftmost and contiguous. IPv6 masks have no such restriction." DEFVAL { ''h } ::= { docsSubMgtPktFilterEntry 10 } docsSubMgtPktFilterUlp OBJECT-TYPE SYNTAX Integer32 (0..256) MAX-ACCESS read-create STATUS current DESCRIPTION "Upper level protocol to match. If this value is 256, matches ALL ULP values. Otherwise, this matches the specific protocol value. Note that if the packet ULP is either 6 (tcp) or 17 (udp), then docsSubMgtPktTcpUdpFilterTable must also be consulted (if its entry exists) to see if this entry matches. If this value is neither tcp(6) nor udp(17), then that table is not consulted." DEFVAL { 256 } ::= { docsSubMgtPktFilterEntry 11 } docsSubMgtPktFilterTosValue OBJECT-TYPE SYNTAX OCTET STRING (SIZE(1)) MAX-ACCESS read-create STATUS current DESCRIPTION "The TOS value to match in the IP packet." DEFVAL { '00'h } ::= { docsSubMgtPktFilterEntry 12 } docsSubMgtPktFilterTosMask OBJECT-TYPE SYNTAX OCTET STRING(SIZE(1)) MAX-ACCESS read-create STATUS current DESCRIPTION "The mask to apply against the TOS value to be matched in the IP packet. The default for both these objects taken together matches all TOS values. A packet matches this filter if the following is true: AND (FilterTosValue, FilterTosMask) == AND (Packet TOS Value, FilterTosMask)." DEFVAL { '00'h } ::= { docsSubMgtPktFilterEntry 13 } docsSubMgtPktFilterAction OBJECT-TYPE SYNTAX INTEGER Expires August 2002 [Page 15] INTERNET-DRAFT DOCSIS Subscriber Management MIB February 2002 { accept(1), drop(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The action to take upon this filter matching. Accept means to accept the packet for further processing. Drop means to drop the packet." DEFVAL { accept } ::= { docsSubMgtPktFilterEntry 14 } docsSubMgtPktFilterMatches OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object counts the number of times this specific rule has been matched. This is incremented any time this rule is encountered and all components match. It is only incremented for the first (lowest-indexed) filter matching a packet." ::= { docsSubMgtPktFilterEntry 15 } docsSubMgtPktFilterStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "Standard rowStatus object for creating this row. Any object in this row which is writable may be changed at any time while the row is active." ::= { docsSubMgtPktFilterEntry 16 } docsSubMgtTcpUdpFilterTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsSubMgtTcpUdpFilterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This is an adjunct to docsSubMgtPktFilterTable. It provides optional filtering based on elements in TCP or UDP headers. This table is separate from docsSubMgtPktFilterTable only because it is expected to be used more rarely. This table is not consulted unless the upper-layer protocol is TCP, UDP, or 'any'." ::= { docsSubMgtObjects 7 } docsSubMgtTcpUdpFilterEntry OBJECT-TYPE SYNTAX DocsSubMgtTcpUdpFilterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Expires August 2002 [Page 16] INTERNET-DRAFT DOCSIS Subscriber Management MIB February 2002 "Defines filtering criteria for TCP and UDP headers." INDEX { docsSubMgtPktFilterGroup, docsSubMgtPktFilterIndex } ::= {docsSubMgtTcpUdpFilterTable 1 } DocsSubMgtTcpUdpFilterEntry ::= SEQUENCE { docsSubMgtTcpUdpSrcPort Integer32, docsSubMgtTcpUdpDstPort Integer32, docsSubMgtTcpFlagValues BITS, docsSubMgtTcpFlagMask BITS, docsSubMgtTcpUdpStatus RowStatus } docsSubMgtTcpUdpSrcPort OBJECT-TYPE SYNTAX Integer32(0..65536) MAX-ACCESS read-create STATUS current DESCRIPTION "The source port to match. 65536 matches any value in the TCP or UDP source port field." DEFVAL { 65536 } ::= { docsSubMgtTcpUdpFilterEntry 1 } docsSubMgtTcpUdpDstPort OBJECT-TYPE SYNTAX Integer32(0..65536) MAX-ACCESS read-create STATUS current DESCRIPTION "The destination port to match. 65536 matches any value in the TCP or UDP destination port field." DEFVAL { 65536 } ::= { docsSubMgtTcpUdpFilterEntry 2 } docsSubMgtTcpFlagValues OBJECT-TYPE SYNTAX BITS { urgent(0), ack(1), push(2), reset(3), syn(4), fin(5) } MAX-ACCESS read-create STATUS current DESCRIPTION "The value of the flags of interest. The value of this object MUST always be a subset (proper or otherwise) of docsSubMgtTcpFlagMask. An attempt to violate this constraint returns an inconsistentValue error for an SNMPv2 or v3 agent and a badValue error for an SNMPv1 agent." DEFVAL { {} } Expires August 2002 [Page 17] INTERNET-DRAFT DOCSIS Subscriber Management MIB February 2002 ::= { docsSubMgtTcpUdpFilterEntry 3 } docsSubMgtTcpFlagMask OBJECT-TYPE SYNTAX BITS { urgent(0), ack(1), push(2), reset(3), syn(4), fin(5) } MAX-ACCESS read-create STATUS current DESCRIPTION "This bit set indicates the flags of interest in the TCP header for the packet to be matched. For example to match all packets where the urgent bit is set, but that are not either syn or fin, the value of docsSubMgtTcpFlagValues would be { urgent }, and the value of this object would be { urgent, syn, fin }" DEFVAL { {} } ::= { docsSubMgtTcpUdpFilterEntry 4 } docsSubMgtTcpUdpStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "Standard row object for this table. Any object in the conceptual row may be modified regardless of whether this row is active or not." ::= { docsSubMgtTcpUdpFilterEntry 5 } docsSubMgtCmFilterTable OBJECT-TYPE SYNTAX SEQUENCE OF DocsSubMgtCmFilterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Binds filter groups to modems. This table identifies for each modem the upstream and downstream filter groups that apply to packets for that modem. Zero is used as a distinguished value to mean no filter group." ::= { docsSubMgtObjects 8 } docsSubMgtCmFilterEntry OBJECT-TYPE SYNTAX DocsSubMgtCmFilterEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Expires August 2002 [Page 18] INTERNET-DRAFT DOCSIS Subscriber Management MIB February 2002 "Binds a filter group to each direction of traffic for a modem. The filters in this entry apply if docsSubMgtCpeControlActive is true." AUGMENTS { docsIfCmtsCmStatusEntry } ::= {docsSubMgtCmFilterTable 1 } DocsSubMgtCmFilterEntry ::= SEQUENCE { docsSubMgtSubFilterDownstream Integer32, docsSubMgtSubFilterUpstream Integer32, docsSubMgtCmFilterDownstream Integer32, docsSubMgtCmFilterUpstream Integer32 } docsSubMgtSubFilterDownstream OBJECT-TYPE SYNTAX Integer32(0..1024) MAX-ACCESS read-write STATUS current DESCRIPTION "The filter group applied to traffic destined for subscribers attached to the referenced CM. This is set upon row creation to either the default (docsSubMgtSubFilterDownDefault), or to the value in the provisioning object sent upstream from the CM to the CMTS during registration. The value of this object is a pointer into the docsSubMgtPktFilterTable and refers to all filter rows with matching docsSubMgtPktFilterGroup indices. If there are no matching filter rows in that table, or if this object is set to zero, no filtering is applied to traffic destined to hosts attached to this CM." ::= { docsSubMgtCmFilterEntry 1 } docsSubMgtSubFilterUpstream OBJECT-TYPE SYNTAX Integer32(0..1024) MAX-ACCESS read-write STATUS current DESCRIPTION "The filter group applied to traffic originating from subscribers attached to the referenced CM. This is set upon row creation to either the default (docsSubMgtSubFilterUpDefault), or to the value in the provisioning object sent upstream from the CM to the CMTS. The value of this object is a pointer into the docsSubMgtPktFilterTable and refers to all filter rows with matching docsSubMgtPktFilterGroup indices. If there are no matching filter rows in that table, or if this object is set to zero, no filtering is applied to traffic originating from hosts attached to this CM." ::= { docsSubMgtCmFilterEntry 2 } docsSubMgtCmFilterDownstream OBJECT-TYPE SYNTAX Integer32(0..1024) MAX-ACCESS read-write STATUS current Expires August 2002 [Page 19] INTERNET-DRAFT DOCSIS Subscriber Management MIB February 2002 DESCRIPTION "The filter group applied to traffic destined for the referenced CM itself. This is set upon row creation to either the default (docsSubMgtCmFilterDownDefault), or to the value in the provisioning object sent upstream from the CM to the CMTS during registration. The value of this object is a pointer into the docsSubMgtPktFilterTable and refers to all filter rows with matching docsSubMgtPktFilterGroup indices. If there are no matching filter rows in that table, or if this object is set to zero, no filtering is applied to traffic destined to this CM." ::= { docsSubMgtCmFilterEntry 3 } docsSubMgtCmFilterUpstream OBJECT-TYPE SYNTAX Integer32(0..1024) MAX-ACCESS read-write STATUS current DESCRIPTION "The filter group applied to traffic originating from the referenced CM itself. This is set upon row creation to either the default (docsSubMgtCmFilterUpDefault), or to the value in the provisioning object sent upstream from the CM to the CMTS. The value of this object is a pointer into the docsSubMgtPktFilterTable and refers to all filter rows with matching docsSubMgtPktFilterGroup indices. If there are no matching filter rows in that table, or if this object is set to zero, no filtering is applied to traffic originating from this CM." ::= { docsSubMgtCmFilterEntry 4 } docsSubMgtSubFilterDownDefault OBJECT-TYPE SYNTAX Integer32(0..1024) MAX-ACCESS read-write STATUS current DESCRIPTION "Upon a row creation in docsSubMgtCmFilterTable, docsSubMgtSubFilterDownstream is set to this value if no provisioning object is present to override it. This object is persistent across CMTS reboots. Upon initial CMTS initialization, this defaults to 0." ::= { docsSubMgtObjects 9 } docsSubMgtSubFilterUpDefault OBJECT-TYPE SYNTAX Integer32(0..1024) MAX-ACCESS read-write STATUS current DESCRIPTION "Upon a row creation in docsSubMgtCmFilterTable, docsSubMgtSubFilterUpstream is set to this value if no provisioning object is present to override it. This object is persistent across CMTS reboots. Upon initial CMTS initialization, this defaults to 0." ::= { docsSubMgtObjects 10 } Expires August 2002 [Page 20] INTERNET-DRAFT DOCSIS Subscriber Management MIB February 2002 docsSubMgtCmFilterDownDefault OBJECT-TYPE SYNTAX Integer32(0..1024) MAX-ACCESS read-write STATUS current DESCRIPTION "Upon a row creation in docsSubMgtCmFilterTable, docsSubMgtCmFilterDownstream is set to this value if no provisioning object is present to override it. This object is persistent across CMTS reboots. Upon initial CMTS initialization, this defaults to 0." ::= { docsSubMgtObjects 11 } docsSubMgtCmFilterUpDefault OBJECT-TYPE SYNTAX Integer32(0..1024) MAX-ACCESS read-write STATUS current DESCRIPTION "Upon a row creation in docsSubMgtCmFilterTable, docsSubMgtCmFilterUpstream is set to this value if no provisioning object is present to override it. This object is persistent across CMTS reboots. Upon initial CMTS initialization, this defaults to 0." ::= { docsSubMgtObjects 12 } docsSubMgtNotification OBJECT IDENTIFIER ::= { docsSubMgt 2 } docsSubMgtConformance OBJECT IDENTIFIER ::= { docsSubMgt 3 } docsSubMgtCompliances OBJECT IDENTIFIER ::= { docsSubMgtConformance 1 } docsSubMgtGroups OBJECT IDENTIFIER ::= { docsSubMgtConformance 2 } docsSubMgtBasicCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for CMTS devices that implement CMTS centric subscriber management." MODULE MANDATORY-GROUPS { docsSubMgtGroup } OBJECT docsSubMgtCpeIpAddressType -- SYNTAX InetAddressType { ipv4(1) } DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT docsSubMgtCpeIpAddr Expires August 2002 [Page 21] INTERNET-DRAFT DOCSIS Subscriber Management MIB February 2002 SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT docsSubMgtPktFilterSrcAddrType -- SYNTAX InetAddressType { ipv4(1) } DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT docsSubMgtPktFilterSrcAddr SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT docsSubMgtPktFilterSrcMaskType -- SYNTAX InetAddressType { ipv4(1) } DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT docsSubMgtPktFilterSrcMask SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT docsSubMgtPktFilterDstAddrType -- SYNTAX InetAddressType { ipv4(1) } DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT docsSubMgtPktFilterDstAddr SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT docsSubMgtPktFilterDstMaskType -- SYNTAX InetAddressType { ipv4(1) } DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT docsSubMgtPktFilterDstMask SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 addresses." Expires August 2002 [Page 22] INTERNET-DRAFT DOCSIS Subscriber Management MIB February 2002 ::= { docsSubMgtCompliances 1 } docsSubMgtGroup OBJECT-GROUP OBJECTS { docsSubMgtCpeControlMaxCpeIp, docsSubMgtCpeControlActive, docsSubMgtCpeControlLearnable, docsSubMgtCpeControlReset, docsSubMgtCpeMaxIpDefault, docsSubMgtCpeActiveDefault, docsSubMgtCpeLearnableDefault, docsSubMgtCpeIpAddressType, docsSubMgtCpeIpAddr, docsSubMgtCpeIpLearned, docsSubMgtPktFilterSrcAddrType, docsSubMgtPktFilterSrcAddr, docsSubMgtPktFilterSrcMaskType, docsSubMgtPktFilterSrcMask, docsSubMgtPktFilterDstAddrType, docsSubMgtPktFilterDstAddr, docsSubMgtPktFilterDstMaskType, docsSubMgtPktFilterDstMask, docsSubMgtPktFilterUlp, docsSubMgtPktFilterTosValue, docsSubMgtPktFilterTosMask, docsSubMgtPktFilterAction, docsSubMgtPktFilterMatches, docsSubMgtPktFilterStatus, docsSubMgtTcpUdpSrcPort, docsSubMgtTcpUdpDstPort, docsSubMgtTcpFlagValues, docsSubMgtTcpFlagMask, docsSubMgtTcpUdpStatus, docsSubMgtSubFilterDownstream, docsSubMgtSubFilterUpstream, docsSubMgtCmFilterDownstream, docsSubMgtCmFilterUpstream, docsSubMgtSubFilterDownDefault, docsSubMgtSubFilterUpDefault, docsSubMgtCmFilterDownDefault, docsSubMgtCmFilterUpDefault } STATUS current DESCRIPTION "The objects use to managed host-based cable modems via a set of CMTS enforced controls." ::= { docsSubMgtGroups 1 } END 4. Acknowledgments This document is based on work by Michael St.Johns, then at Expires August 2002 [Page 23] INTERNET-DRAFT DOCSIS Subscriber Management MIB February 2002 Excite@Home. Thanks to Guenter Roeck and Julie McGray for reviewing early drafts. 5. References [1] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [2] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [5] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of Management Information for Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [6] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [7] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Management Protocol", STD 15, RFC 1157, May 1990. [9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. [10] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996. [11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [13] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. Expires August 2002 [Page 24] INTERNET-DRAFT DOCSIS Subscriber Management MIB February 2002 [14] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC 2573, April 1999. [15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [16] "Data-Over-Cable Service Interface Specifications: Cable Modem Radio Frequency Interface Specification SP-RFIv1.1-I07-010829", DOCSIS, August 2001, available at http://www.cablemodem.com/. [17] StJohns, M. , "Cable Device Management Information Base for DOCSIS Compliant Cable Modems and Cable Modem Termination Systems", RFC2669, August 1999. [18] StJohns, M. , "Radio Frequency (RF) Interface Management Information Base for MCNS/DOCSIS compliant RF interfaces", RFC2670, August 1999. [19] "Data-Over-Cable Service Interface Specifications: Baseline Privacy Interface Specification SP-BPI-I03-010829", DOCSIS, August 2001, available at http://www.cablemodem.com/. [20] "Data-Over-Cable Service Interface Specifications: Baseline Privacy Plus Interface Specification SP-BPI+-I07-010829", DOCSIS, August 2001, available at http://www.cablemodem.com/. [21] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC2570, April 1999. [22] Ziemba, G., Reed, D., and P. Traina, "Security Considerations for IP Fragment Filtering", RFC1858, October 1995. [23] Miller, I., "Protection against a Variant of the Tiny Fragment Attack". RFC3128, June 2001. 6. 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 [16], [19], and [20] 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 [22] and [23] for discussion of these attacks. Expires August 2002 [Page 25] INTERNET-DRAFT DOCSIS Subscriber Management MIB February 2002 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. SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [12] and the View- based Access Control Model RFC 2575 [15] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 7. Author's Address Wilson Sawyer ARRIS 6 Riverside Drive Andover, MA 01810 USA Phone: +1 978 946 4711 Email: wsawyer@ieee.org 8. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary Expires August 2002 [Page 26] INTERNET-DRAFT DOCSIS Subscriber Management MIB February 2002 rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 9. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Expires August 2002 [Page 27]