INTERNET-DRAFT IGMP Proxy MIB August 1998 Cable Device IGMP Proxy MIB for DOCSIS compliant Cable Modems draft-ietf-ipcdn-igmp-proxy-mib-00.txt Jonathan Fellows General Instrument jfellows@gi.com Status of this Memo This document is an Internet-Draft. 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 a "work in progress". To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), or ftp.isi.edu (US). 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 basic set of managed objects for SNMP-based management of conditional access to IP multicast groups by DOCSIS compliant cable modems. This memo specifies a MIB module in a manner that is compliant to the SNMPv2 SMI. The set of objects is consistent with the SNMP framework and existing SNMP standards. This memo does not specify a standard for the Internet community. Expires February 1999 [Page 1] INTERNET-DRAFT IGMP Proxy MIB August1998 1. The SNMPv2 Network Management Framework The SNMPv2 Network Management Framework presently consists of three major components. They are: o the SMI, described in RFC 1902 [1] - the mechanisms used for describing and naming objects for the purpose of management. o the MIB-II, STD 17, RFC 1213 [2] - the core set of managed objects for the Internet suite of protocols. o the protocol, RFC 1157 [3] and/or RFC 1905 [4], - the protocol for accessing managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 2. Object Definitions Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) defined in the SMI. In particular, each object type is named by an OBJECT IDENTIFIER, an administratively assigned name. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we often use a textual string, termed the descriptor, to refer to the object type. Expires February 1999 [Page 2] INTERNET-DRAFT IGMP Proxy MIB August 1998 3. Overview This MIB provides a set of objects required for the management of conditional access to IP multicast groups. The subjects of this policy are the set of Customer Premises hosts connected to an IPCDN network by a DOCSIS compliant Cable Modem. The basic principle of operation is that a Cable Modem implements an IP multicast table which is used to filter IP multicast addressed datagrams received on either the cable modem HFC interface or the cable modem CPE interface. This filter serves two purposes: (1) only IP multicast traffic for currently subscribed group addresses is passed into the CPE environment, reducing the bandwidth consumed in the CPE environment by multicast traffic. (2) SNMP network management stations can define a conditional access policy based on enterprise specific data of any kind (such as pay- per-group, for example). It is traditional in access control systems to distinguish between potential access to a resource and actual or current access to resources. Potential access is often represented in the form of Access Control Lists (ACLs) associated with controlled resources. Actual access is often represented in the form of an entry in an address resolution, translation, or filtering mechanism that stands between a subject and a resource. For this IGMP Proxy specification, the authoritative definition of potential access resides in one or more SNMP management stations. Consistency of this information between multiple management stations is beyond the scope of this specification. The Permission Cache Table is the local representation of potential access to IP multicast groups in a cable modem. It is an object in the cable modem IGMP Proxy MIB that is used to cache access rules resulting from previous mediation decisions by the management system. A single rule may match a range of IP multicast addresses. This cache serves to reduce the mediation workload on the SNMP infrastructure. Entries in this table are only created or destroyed by explicit SNMP management action via SET commands. The IGMP Proxy MIB defines current accesses for a cable modem in a separate table, the Current Filters Table. Each entry specifies access rights (none, send, receive, send and receive) to a single IP multicast address. The local agent, as part of IGMP Proxy protocol processing, creates entries in this table. Entries in the Current Filters table are periodically rechecked against both permissions and current CPE group membership, and deleted when necessary. Explicit deletion by SNMP management action is also allowed. The IGMP Proxy protocol is based on the interception of CPE IGMP JOIN requests (Host membership reports) by the cable modem, which then generates an SNMP trap to its designated SNMP management station. An entry is created in the IGMP Proxy MIB Pending Request Table. When an SNMP SET is made to the Permission Cache Table, the new rule is checked against all pending IGMP request. For those that match, new entries are created in the Current Filters Table, and the original IGMP JOIN message is propagated upstream. Since SNMP traps are not acknowledged and may be lost in transmission, the IGMP Proxy protocol provides for retransmission of SNMP traps after a suitable timeout. Expires February 1999 [Page 3] INTERNET-DRAFT IGMP Proxy MIB August 1998 3.1. Structure of the MIB This MIB is structured in a single group with three tables: Permission_Cache_Table Mcast_address ip_address Address_mask ip_address Access-Rights: (none | send | receive | send_and_receive) Time_To_Live: seconds Current_Filters_Table Mcast_address ip_address Access-Rights: (none | send | receive | send_and_receive) Max_hops counter Recheck_timer seconds Pending_Requests_Table Mcast_address ip_address Join message: opaque igmp message Retry_timer seconds Max_retries: counter 3.2 Events and Traps This section needs work to define the IGMP Proxy trap generated when a CPE IGMP JOIN message is received at the CPE LAN/ CM’s CMCI interface. The definition and coding of events is vendor-specific. In deference to the network operator who must troubleshoot multi-vendor networks, the circumstances and meaning of each event should be reported as human-readable text. Vendors SHOULD provide time-of-day clocks in CMs to provide useful timestamping of events. For each vendor-specific event that is reportable via TRAP, the vendor must create an enterprise-specific trap definition. Trap definitions MUST include the event reason encoded as DisplayString and should be defined as: trapName NOTIFICATION-TYPE OBJECTS { ifIndex, eventReason, other useful objects } STATUS current DESCRIPTION "trap description" ::= Object Id Note that ifIndex is only included if the event or trap is interface related. The last digit of the trap OID for enterprise-specific traps must match docsDevEvId. For SNMPv1-capable Network Management systems, this is necessary to correlate the event type to the trap type. Many Network Management systems are only capable of trap filtering on an enterprise and single-last-digit basis. Expires February 1999 [Page 4] INTERNET-DRAFT IGMP Proxy MIB August 1998 4. Definitions gi OBJECT IDENTIFIER ::= { iso(1) org(3) dod(6) internet(1) private(4) enterpresis(1) 1166 } giproducts OBJECT IDENTIFIER ::= { gi 1 } sb2100 OBJECT IDENTIFIER ::= { giproducts 19 } McastProxyMIBObjects ::= { sb2100 63 } -- Permission Cache Table object definitions mcastPermissionCacheTable OBJECT-TYPE SYNTAX SEQUENCE OF McastPermissionCacheEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Permission Cache Table defines potential access to IP multicast group addresses by CPE hosts. (It does not define actual current access – which is defined in a different table – the Current Filters Table.) Permission Cache Table entries are derived from authoritative information stored by one or more management stations. Entries in this table can match a range of IP multicast addresses that share the same access rights. A Holding Time attribute specifies the length of time that a Permission Cache Table entry is held in the table before being aged out." ::= { mcastProxyMIBObjects 1 } mcastPermissionCacheEntry OBJECT-TYPE SYNTAX McastPermissionCacheEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines potential access to IP Multicast groups by CPE hosts. For each entry in this table, the contents are not readable unless the management station has read-write permission." INDEX { mcastPermissionCacheIndex } ::= { mcastPermissionCacheTable 1 } Expires February 1999 [Page 5] INTERNET-DRAFT IGMP Proxy MIB August 1998 McastPermissionCacheEntry ::= SEQUENCE { mcastPermissionCacheIndex INTEGER, mcastPermissionCacheIp IpAddress, mcastPermissionCacheIpMask IpAddress, mcastPermissionCacheAccessControl INTEGER, mcastPermissionCacheHoldingTime INTEGER, mcastPermissionCacheStatus RowStatus } mcastPermissionCacheIndex OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Index used to order the application of access entries." ::= { mcastPermissionCacheEntry 1 } mcastPermissionCacheIp OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The IP multicast address (or address range) controlled by this rule. By convention, the IP address is ‘0’ in those fields not covered by the accompanying mask value.[is this accurate in the multicast scenario ?] At the boundaries of this convention, if the mask is 0.0.0.0 then a fully specified IP address is in this field (matches a single address), while if the mask is 255.255.255.255, then the address field would be 0.0.0.0 (matches any address)" DEFVAL { 'ffffffff'h } ::= { mcastPermissionCacheEntry 2 } mcastPermissionCacheIpMask OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The IP subnet mask of the IP multicast address or address range." DEFVAL { 'ffffffff'h } ::= { mcastPermissionCacheEntry 3 } Expires February 1999 [Page 6] INTERNET-DRAFT IGMP Proxy MIB August 1998 mcastPermissionCacheAccessControl OBJECT-TYPE SYNTAX INTEGER { none(1), send(2), receive(3), sendReceive(4), } MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the type of access allowed for IP multicast addresses that match this rule. Setting this object to none(1) causes all matching IGMP join requests to be rejected. Send(2) allows only sending of IP datagrams from the CPE LAN with a matching IP multicast address. Receive(3) allows only reception of IP datagrams from the HFC interface with a matching IP multicast address. SendReceive(4) allows both sending and receiving of IP datagrams with a matching IP multicast address." DEFVAL { none } ::= { mcastPermissionCacheEntry 4 } mcastPermissionCacheHoldingTime OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS read-create STATUS current DESCRIPTION "Indicates the time in seconds for which this table entry should be held in the permission cache table before being aged (deleted) by the agent. A short time indicates that authoritative access control data changes often at the management station(s), and new requests should be remediated against authoritative data. A long time indicates stable authoritative access control data which can be cached for long periods of time. A value of zero indicates a permanent cache entry which never ages out." DEFVAL { 86400 } ::= { mcastPermissionCacheEntry 5 } mcastPermissionCacheEntry Status OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "Controls and reflects the status of rows in this table." ::= { mcastPermissionCacheEntry 6 } Expires February 1999 [Page 7] INTERNET-DRAFT IGMP Proxy MIB August 1998 -- Current Filters Table object definitions mcastCurrentFiltersTable OBJECT-TYPE SYNTAX SEQUENCE OF McastCurrentFiltersEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Current Filters Table defines the current access rights to IP multicast addresses by CPE hosts. A CM only forwards an IP multicast datagram if a matching entry is found in this table." ::= { mcastProxyMIBObjects 2 } mcastCurrentFiltersEntry OBJECT-TYPE SYNTAX McastCurrentFiltersEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Controls filtering of access to IP Multicast groups by CPE hosts. For each entry in this table, the contents are not readable unless the management station has read-write permission." INDEX { mcastCurrentFiltersIp } ::= { mcastCurrentFiltersTable 1 } McastCurrentFiltersEntry ::= SEQUENCE { mcastCurrentFiltersIp IpAddress, mcastCurrentFiltersAccessControl INTEGER, mcastCurrentFiltersMaxHops INTEGER, mcastCurrentFiltersRecheckTime INTEGER, } mcastCurrentFiltersIp OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IP multicast address controlled by this rule." DEFVAL { 'ffffffff'h } ::= { mcastCurrentFiltersEntry 1 } mcastCurrentFiltersAccessControl OBJECT-TYPE SYNTAX INTEGER { none(1), send(2), receive(3), sendReceive(4), } MAX-ACCESS read-write STATUS current DESCRIPTION "Specifies the type of access allowed for IP multicast addresses that match this rule. Setting this object to none(1) causes deletion of this row in the table, which results in immediate revocation of access rights to the IP multicast address involved. Send(2) allows only sending of IP datagrams from the CPE LAN with a matching IP multicast address. Receive(3) allows only reception of IP datagrams from the HFC interface with a matching IP multicast address. SendReceive(4) allows both sending and receiving of IP datagrams with a matching IP multicast address." DEFVAL { none } ::= { mcastCurrentFiltersEntry 2 } mcastCurrentFiltersMaxHops OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the maximum value of the IP hop count value in an outgoing IP datagram. The datagram is discarded if it’s hop count exceeds this value. This is intended as a way to control the scope of multicast from a CPE LAN." ::= { mcastPermissionCacheEntry 3 } mcastCurrentFiltersRecheckTime OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the time in seconds for which this table entry should be held in the current filter table before being revalidated. Revalidation involves: (1) remediation against the Permission Cache Table, and (2) checking for group membership on the CPE LAN with an IGMP host membership query ( IGMP type 1 message addressed to the all hosts group address 224.0.0.1) message. If remediation is successful and there are still active CPE group members, then the timer is reset to the value specified in this entry. Failure of either of these checks results in deletion of the entry. " ::= { mcastCurrentFiltersEntry 4 } -- Pending Requests Table object definitions mcastPendingRequestsTable OBJECT-TYPE SYNTAX SEQUENCE OF McastPendingRequestsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Pending Requests Table tracks outstanding SNMP Multicast Proxy Join traps. Since IGMP JOIN messages are not automatically regenerated by CPE hosts, and SNMP trap messages are not reliably transmitted to management stations, a positive acknowledgement protocol with timeouts and retries is needed. This table maintains the state for this protocol." ::= { mcastProxyMIBObjects 3 } mcastPendingRequestsEntry OBJECT-TYPE SYNTAX McastPendingRequestsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Defines pending requests for access to IP Multicast groups by CPE hosts. For each entry in this table, the contents are not readable unless the management station has read- write permission." INDEX { mcastPendingRequestsIp } ::= { mcastPendingRequestsTable 1 } McastPendingRequestsEntry ::= SEQUENCE { mcastPendingRequestsIp IpAddress, mcastPendingRequestsTrapMsg OPAQUE, mcastPendingRequestsRetryTimer INTEGER, mcastPendingRequestsMaxRetries INTEGER, } mcastPendingRequestsIp OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IP multicast address for which the IGMP JOIN message of this entry was generated." DEFVAL { 'ffffffff'h } ::= { mcastPendingRequestsEntry 1 } Expires February 1999 [Page 8] INTERNET-DRAFT IGMP Proxy MIB August 1998 mcastPendingRequestsTrapMsg OBJECT-TYPE SYNTAX OPAQUE STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The complete original IGMP JOIN message." ::= { mcastPendingRequestsEntry 2 } mcastPendingRequestsRetryTimer OBJECT-TYPE SYNTAX INTEGER (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates the time in seconds for which the agent should wait to receive an SNMP SET on the Permission Cache Table that matches the IP multicast entry in this table before regenerating the IGMP JOIN trap." DEFVAL { 60 } ::= { mcastPendingRequestsEntry 3 } mcastPendingRequestsMaxRetries OBJECT-TYPE SYNTAX INTEGER {0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "Specifies the number of times to resend the IGMP JOIN trap if no SNMP response is received. Subject to rate controls on SNMP trap generation defined elsewhere." DEFVAL { 6 } ::= { mcastPendingRequestsEntry 4 } Expires February 1999 [Page 9] INTERNET-DRAFT IGMP Proxy MIB August 1998 5. Acknowledgments This document was produced by TBD. It reflects comments by Steve Keller, Poornima Lalwaney, and Victor Hou. 6. References Need to add IGMP references [1] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, January 1996. [2] McCloghrie, K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, Hughes LAN Systems, Performance Systems International, August 1991. [3] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "A Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, SNMP Research, Performance Systems International, MIT Lab for Computer Science, May 1990. [4] SNMPv2 Working Group, 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. [5] McCloghrie, K. and F. Kastenholz, "Evolution of the Interfaces Group of MIB-II", RFC 1573, Hughes LAN Systems, FTP Software, January 1994. [6] "MCNS Data Over Cable Services Cable Modem Radio Frequency Interface Specification SP-RFID01-970326", MCNS, August 1997. [7] L. Steinberg, "Techniques for Managing Asynchronously Generated Alerts", RFC 1224, May 1991. [8] "MCNS Data Over Cable Services Operations Support System Interface Specification SP-OSSII01-970403", MCNS, August 1997. Expires February 1999 [Page 10] INTERNET-DRAFT IGMP Proxy MIB August 1998 7. Security Considerations The basic service supported through this MIB is conditional access for IP multicast groups, which is a security related service. Operational security for this MIB is for further study. 8. Author's Address Jonathan Fellows General Instrument 6450 Sequence Drive San Diego, CA 92121 U.S.A. Phone: +1 619 404 3720 Email: jfellows@gi.com Expires February 1999 [Page 11]