INTERNET-DRAFT Joerg Ottensmeyer Category: Informational Siemens file: draft-otty-cops-pr-filter-pib-00.txt Martin Bokaemper Unisphere Networks Kai Roeber T-Nova A Filtering Policy Information Base (PIB) for Edge Router Filtering Services and Provisioning via COPS-PR 17. November 2000 Status of this Memo Comments about this draft should be submitted to the rap@iphighway.com mailing list. 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 document introduces a Filtering Policy Information Base, which is necessary for a filtering service in routers. The Filtering PIB allows service providers or operators to control user access to networks or services for both dial-in and always-on customers. The provisioning of the Filtering PIB is done by COPS-PR; some enhancements for COPS and COPS-PR are also described in this document. Ottensmeyer, et. al. [Page 1] INTERNET-DRAFT Filtering PIB Model and Provisioning October 2000 1. Introduction A packet filtering service is offered on many routers and includes functionality such as: * classifying packets based on interface, source-/destination address, protocol type and other parameters, * dropping classified packets, * counting the number of packets and their payload in bytes, * explicit forwarding of a packet based on a classifier, * limiting the rate of packets matching a classifier, * marking the packets for DiffServ or MPLS forwarding, and * traffic shaping and queuing profiles for marked packets. Use of this functionality has already been described specifically for DiffServ [DSPIB]. In this draft the filtering functionality is used to define and control services for individual users or small groups of users dynamically, using all the packet-manipulation means the router offers. This functionality can be used in many scenarios: * A prepaid billing model could require semi-real-time policy changes if a subscriber account balance is exceeded. The policy could be e.g. to move from Internet Gold to Internet bronze with minimum bandwidth, or even policy-route all traffic from this user to a Web- based subscription utility allowing to refill the account with a new deposit. A charging/billing tool would then trigger policy changes. * A small percentage of "always-on" users tend to eat an unreasonable proportion of bandwdith. Some NSPs would like to put limits on such "bad guys" strongly limiting their available bandwidth if they use more than a given volume over a given period of time. A statistical tool would then trigger policy changes. * A game server could require quasi-real-time policy changes for a given user depending on the phase of the game, e.g. modify the maximum bandwidth, require low-latency multimedia-oriented queuing for a while. * Self-provisioning applications could force unrecognized users to a web-based subscription utility and not let them go to the Internet until they subscribed. This implies control over the policy of routing. * An anti-intrusion detection system could detect some bad guys (e.g. identified by their IP address) and protect (policy filtering) users having subscribed to a service with a high-level of security. Here the intrusion detection system triggers the policy changes. * A scheduling system operated by a service provider could prioritize Ottensmeyer, et. al. [Page 2] INTERNET-DRAFT Filtering PIB Model and Provisioning October 2000 traffic depending on the time of day. For example, FTP has a low priority during the day, high during the night. Such policy prioritization rules may be different for each enterprise outsourcng to a given service provider enforcing the policies. * A child protection system could force the Web traffic of kids through a web-proxy enforcing filtering of "inappropriate" sites. Adults might not wish such filtering, but could benefit from going through a Web caching device ... if they paid for such enhanced performance. This can be achieved by the combination of policy- routing rules with an advanced subscriber management system. * A portal service controls the access to servers or the network itself for both dial-in and always-on customers. To enable a service, the user request a service from the portal server; this may require an authtication of the user and the start of accounting procedures as well. Therefore, the portal server downloads new fitering rules to the PEP. As can be seen from the previous examples, filtering augments policy control for QoS (DiffServ) or security in a natural way. In order to enable the service provider or operator to use such a filtering function, a methods to control the operation of the router is needed. The approach proposed in this document (as depicted in Fig. 1) is conform to the IETF's policy framework [Policy]. The Policy Server of the operator or service provider acts as the Policy Decision Point. It receives information about attached users from the Edge Router and generates filter entries for these users - triggered by events in the PEP (e.g. login/logout of users) and by external events. By reading packet or byte counters attached to filter entries, the Policy Server can collect usage data. The (Edge) Router is the check-point for the packets from the customer or user and acts as the Policy Enforcement Point. The PEP takes its information from a Filtering Policy Information Base. Since PDP needs to keep a consistent list of currently active users and services on the PDP, COPS-PR is the natural choice to provision this PIB. Ottensmeyer, et. al. [Page 3] INTERNET-DRAFT Filtering PIB Model and Provisioning October 2000 Access +---------------+ Network | |----- Core | Edge Router |----- Network Dial-In --->| (PEP) |----- User | | Service or Always-On --->| |-----> Content Provider User +-------+-------+ ^ | v +-------+-------+ | Policy Server | | (PDP) | +---------------+ Figure 1: Application Scenario with a Policy Server Note: This draft describes the model used in an actual existing implementation, compliance with the filter object definitions in [DSPIB] or [FWPIB] was not realized at the time of this writing. The implementation uses XDR encoding for the filtering objects instead of BER. A migration of these objects to comply with the current work on COPS-PR, SPPI and FRAME-PIB is expected. 1.1 Terminology 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 RFC 2119. 2. Summary of the Filtering PIB 2.1 The Service Model The key component of the services described in the introduction is a filter located on the interfaces of a Router. The model of this filter and the objects used to control this filter are described in the following. A Router can be modeled as shown in Fig. 2 as a number of interfaces interconnected by a routing entity. For the purpose of controlling packet flows, we have to distinguish the in (ingress) and out (egress) direction of an interface. However, it is sufficient, that only the user side interfaces implement the filtering function introduced in this document. Ottensmeyer, et. al. [Page 4] INTERNET-DRAFT Filtering PIB Model and Provisioning October 2000 +--------------------------------+ |============== +-------+ | | Interface A | | | | |-------------| | | | ------->| F | in +->| | |---> |-------------| | | |<--- <-------| out | F +<-+ | | |============== | | | | |routing| | user |============== |entity |- .... | (core) side | Interface B | | |- .... | network |-------------| | | | side ------->| F | in +->| | | |-------------| | | | <-------| out | F +<-| | |---> |============== +-------+ |<--- | ... | +--------------------------------+ Figure 2: Interface Model of an Edge Router For each packet arriving at an user side interface (either from the outside as well as from the routing entity), the filter (F) determines if, where and possibly when (i.e. traffic conditioning) to forward a packet. The forwarding policy is retrieved from the Filtering PIB. This is done as follows: The filter checks the list of filter rules which is ordered by priority. Associated with each filter rule is a ClassifierObject, which specifies some classification criteria for packets such as source and destination address or port numbers. Once the packet is matched, it is treated according to the filter rule. There are different types of rules. A "RuleFilter" has the semantic to allow/deny packet forwarding to user side or routing engine (depending on the actual direction); a "RuleNextInterface" directly specifies the interface where to forward a packet; a "RuleRateLimit" involves a traffic condtioner before forwarding the packet; a "RuleMarking" checks and potentially re-sets the DiffServ Codepoint. Additionally, the accounting record associated with this filter rule is updated. Finally, the Filtering PIB contains some data which is opaque to the PEP. This storage space is used to store session and user information for the current sessions and is only meaningful to the PDP. In case the PDP fails and the PEP is still in a good condition, a backup PDP can retrieve and use this data to seamlessly continue the control of the PEP without interrupting any existing service session. Ottensmeyer, et. al. [Page 5] INTERNET-DRAFT Filtering PIB Model and Provisioning October 2000 2.2 The Filtering PIB classes The Filtering Policy Information Base uses four main classes. These are Filter Rule Objects, Classifier Objects, Accounting Objects and Session Specific Objects. These classes are described below. Filter Rule Objects This object describes the action which is performed on a packet. There are several types possible such as forward to the Routing Entity or forward to a specific Interface directly (i.e. bypass the Routing Entity). These rules have an assigned priority level which are used to determine the evaluation sequence once a packet is received. The filter rules refer to a Classifier Object which allows to identify the packets which have to be treated according this filter rule. There can be multiple filter rules at the same priority level; if so the evaluation order of these filter rules is an implementation choice. A Filter Rule also references to its own Accounting Object. Classifier Objects These objects are referenced by Filter Rules and describe how the packets intended for that rule can be recognized. The classifier object attributes cover (among others) source and destination addresses and may have a network masks to allow the recognition of multiple adresses with one rule. Accounting Objects Once a packet is identified to belong to a filter rule, the associated accounting object is updated. The accounting object attributes include byte as well as packet count fields. Session Objects Session objects contain information about the current users and/or sessions. These objects are sent to the PEP once a session is opened and will be removed by the PDP when the session is closed. This data is not used by the PEP - it's only purpose is to allow the PDP, in the event of a COPS synchronization, to restore PDP- specific session information. This is useful when the PDP goes down and the PEP switches to an alternate PDP. Then this new PDP can retrieve those objects to gain a full picture of the current situation (users and sessions) being active on the PEP. Example for PDP-specific information: timestamp of creating a set of filter rules that represent a specific service. Such a timestamp is not part of the filter objects since it has no meaning for the PEP, but it is necessary for the PDP to keep track of rule Ottensmeyer, et. al. [Page 6] INTERNET-DRAFT Filtering PIB Model and Provisioning October 2000 generation time to allow for proper usage recording. 2.2.1 Auxiliary Classes The Interface object The interface object is passed with the REQ message from the PEP to the PDP when an interface comes up. It contains the interface parameters (configuration information). 2.3 Filtering Examples For a portal service it is necessary that the portal server is always reachable. All the other packtets should be dropped until another service is enabled. To realize this scenario, a policy server needs to install three default rules on the PEP: at highest priority: Classifier: if destination_address = address of portal server Action: allow at lowest priority + 1: Classifier: All packets to tcp port 80 Action: forward to portal server at lowest priority: Classifier: All packets Action: Drop The first rule ensures that the portal server is always reachable, whatever else will be configured on that interface. The next rule will forward HTTP requests directed to other servers to the portal server too. All other packets will be dropped by the last rule. Now, to enable a service, a filter rule at an intermediate priority is installed: Classifier: Source_Address = client address, DA = *, Action = allow Since this filter rule has a higher priority than the default deny filter rule, packets received from the customer for that service will be forwarded. Hence, the service is enabled. If the rule has byte and packet counters attached, this information can be used to generate per-user per-service accounting information. This example only states the filter rules for the ingress direction. Ottensmeyer, et. al. [Page 7] INTERNET-DRAFT Filtering PIB Model and Provisioning October 2000 Of course, analog rules have to be installed for the egress direction of the interfaces. 3. COPS-PR Enhancements The provisioning of a Fitering PIB is analog to the provisioning of any other PIB. The only difference for operating the service as outlined in this document is the need for own objects and some protocol operations to retrieve data from the PEP. To describe these, there are two options: o rewrite the existing COPS-PR spec with a new client-type number and add the desired features o reference the existing COPS-PR spec and simply describe the necessary protocol objects and changed and/or updated data formats with unique numbering and naming. For this first draft the second approach is taken. 3.1 New Objects For the purpose of realizing the filtering service outlined in this document, it is proposed to introduce two new commands for the COPS Decision Object (C-Num = 6; C-Type = 1), namely: 3 = Accounting 4 = List 3.2 DEC-command: Accounting Accounting data is normally send in RPT messages from the client, either in response to a DEC message that deletes a policy object or can be carried by periodically generated RPT messages. For this application it is highly desirable for the PDP to be able to query for specific accounting information on demand. When the PDP wants to retrieve accounting data from the PEP it send a Decision (DEC) message with the COPS Decision Object's (C-Num = 6; C- Type = 1) Command field set to ACCOUNTING and the PRID(s) of the desired accounting object(s). In response to such an accounting decision, the PEP returns the requested data in a report (RPT) message, containing the called Accounting PRI(s). Ottensmeyer, et. al. [Page 8] INTERNET-DRAFT Filtering PIB Model and Provisioning October 2000 3.2 DEC-command: List For (re-)synchronization the PDP needs to retrieve not only the interface objects, which will be sent automatically by the PEP, but also some of the objects created by the previous PDP. To achieve this, a Decision (DEC) message with the COPS Decision Object's (C-Num = 6; C-Type = 1) Command field set to LIST and the PRID of the desired class of data objects. In response to such a list decision, the PEP returns all instances of the specified classes in report (RPT) messages. 4. The Filtering PIB module FILTERING-PIB PIB-DEFINITIONS ::= BEGIN IMPORTS Unsigned32, MODULE-IDENTITY, OBJECT-TYPE FROM COPS-PR-SPPI InstanceId FROM COPS-PR-SPPI-TC InetAddress FROM INET-ADDRESS-MIB; filteringPib MODULE-IDENTITY CLIENT_TYPE { all } LAST-UPDATED "18092000" ORGANIZATION "IETF RAP WG" CONTACT-INFO " Joerg Ottensmeyer Siemens AG Phone: +49 89 722 43239 Email: joerg.ottensmeyer@icn.siemens.de Martin Bokaemper Unisphere Networks Inc. Phone: (613) 271-8440 Email: mbokaemper@unispherenetworks.com Kai Roeber T-Nova Phone: +49 4121 808-114 Email: Kay.Roeber@Telekom.de DESCRIPTION "The PIB module containing the set of filtering rule classes that are required for support of filtering policies" Ottensmeyer, et. al. [Page 9] INTERNET-DRAFT Filtering PIB Model and Provisioning October 2000 ::= { tbd } -- -- The root OID for PRCs in the Filtering PIB -- filteringPibClass OBJECT IDENTIFIER ::= { filteringPib 1 } -- -- The Interface classes -- filteringInferfaceTable OBJECT-TYPE SYNTAX SEQUENCE OF FilteringInferfaceEntry POLICY-ACCESS notify STATUS current DESCRIPTION "This class contains the parameters of the Interfaces" ::= { filteringPibClass 1 } filteringInferfaceEntry OBJECT-TYPE SYNTAX FilteringInferfaceEntry STATUS current DESCRIPTION "An instance of this class specifies all the parameters of an Interface." ::= { filteringInferfaceTable 1} FilteringInferfaceEntry ::= SEQUENCE { ipAddress InetAddress, ipMask InetAddress, broadcastAddress InetAddress, mtuSize Unsigned32, interfaceName OCTET STRING, interfaceDirection Integer32 } ipAddress OBJECT-TYPE SYNTAX InetAddress STATUS current DESCRIPTION "This is the IP address assigned to the Interface" ::= { filteringInferfaceEntry 1 } Ottensmeyer, et. al. [Page 10] INTERNET-DRAFT Filtering PIB Model and Provisioning October 2000 ipMask OBJECT-TYPE SYNTAX InetAddress STATUS current DESCRIPTION "This is the mask assigned to the Interface" ::= { filteringInferfaceEntry 2 } broadcastAddress OBJECT-TYPE SYNTAX InetAddress STATUS current DESCRIPTION "This is the broadcast address assigned to the Interface" ::= { filteringInferfaceEntry 3 } mtuSize OBJECT-TYPE SYNTAX Unsigned32 STATUS current DESCRIPTION "This is the MTU size used at the Interface" ::= { filteringInferfaceEntry 4 } interfaceName OBJECT-TYPE SYNTAX OCTET STRING STATUS current DESCRIPTION "This is the name assigned to the Interface" ::= { filteringInferfaceEntry 5 } interfaceDirection OBJECT-TYPE SYNTAX Integer { ingress(1), egress(2) } STATUS current DESCRIPTION "This is the direction packets flow through the Interface" ::= { filteringInferfaceEntry 6 } -- -- The Classifier Table -- Ottensmeyer, et. al. [Page 11] INTERNET-DRAFT Filtering PIB Model and Provisioning October 2000 classifierTable OBJECT-TYPE SYNTAX SEQUENCE OF ClassifierEntry POLICY-ACCESS install STATUS current DESCRIPTION "The PDP installs this information on the PEP, which describes how to identify packets. The filtering rules refer to it." ::= { filteringPibClass 2 } classifierEntry OBJECT-TYPE SYNTAX ClassifierEntry STATUS current DESCRIPTION "An instance of this class describes how a packet can be identified. Below is the list of parameters our classifier needs. Potentially, there is great overlap with the classieferes of the FrameworkPIB, the details need to be checked." ::= { classifierTable 1} ClassifierEntry ::= SEQUENCE { action Integer, /* permit = 1, deny = 2 (8bits)*/ protocol Integer, /* protocol being matched (8bits) */ srcIpAddress InetAddress, /* source ip and mask */ srcIpMask InetAddress, srcOper Integer, /* port operation, lt(0),gt(1),eq(2),neq(3),rnge(4)*/ srcFromPort Interger, /* source port or begin if range 16b*/ srcToPort Integer, /* source port end if range 16b*/ destIpAddr Integer, /* destination ip and mask */ destIpMask Integer, destOper Integer, /* port operation 16b*/ destFromPort Integer, /* destination port/beg for rng 16b */ udestToPort Integer, /* dest port end if range 16b */ icmpType Integer, /* icmp type 16b */ icmpCode Integer, /* icmp code 16b */ igmpType Integer, /* igmp type 16b */ fromPrec Integer, /* prec value or begin if range 16b */ toPrec Integer /* last prec value if range 16b */ } #and here go the new attributes, a description will be #provided later, when it is clear which and how to build #upon the framework PIB ... Ottensmeyer, et. al. [Page 12] INTERNET-DRAFT Filtering PIB Model and Provisioning October 2000 -- -- The Filtering Rules Classes. -- filteringRulesBaseTable OBJECT-TYPE SYNTAX SEQUENCE OF FilteringRulesEntry POLICY-ACCESS install-notify STATUS current DESCRIPTION "This is the base class of the filtering rules. It linkes the rule with a classifier and the interface where this rule belongs. The specific action to be taken is defined by the classes inherited from this class." ::= { filteringPibClass 3 } filteringRulesBaseEntry OBJECT-TYPE SYNTAX FilteringRulesEntry STATUS current DESCRIPTION "This base class augments our the filtering rules. All filtering rules are derived from this base class an have the attributes of this class." ::= { filteringRulesBaseTable 1 } FilteringRulesEntry::= SEQUENCE { priority Integer, classifierName InstanceId, interfaceUid InstanceId } priority OBJECT-TYPE SYNTAX Integer STATUS current DESCRIPTION "This is the priority assigned to a rule" ::= { FilteringRulesEntry 1 } classifierName OBJECT-TYPE SYNTAX InstanceId STATUS current DESCRIPTION "This is the classifier which belongs to this rule" ::= { FilteringRulesEntry 2 } interfaceUid OBJECT-TYPE SYNTAX InstanceId Ottensmeyer, et. al. [Page 13] INTERNET-DRAFT Filtering PIB Model and Provisioning October 2000 STATUS current DESCRIPTION "This is the interface to which this rule belongs to" ::= { FilteringRulesEntry 3 } -- -- The Filtering Rule "NextInterface". -- filteringRulesNextInterfaceTable OBJECT-TYPE SYNTAX SEQUENCE OF FilteringRulesNextInterfaceEntry POLICY-ACCESS install-notify STATUS current DESCRIPTION "This rule indicates that once a packet is matched, it is forwarded to the interface to the interface referred to by this rule. This class extends the filteringRulesBaseTable. The use of EXTENDS implies that whenever an instance of filteringRulesNextInterfaceTable is created, a corresponding instance of filteringRulesBaseTable is also created." ::= { filteringPibClass 4 } filteringRulesNextInterfaceEntry OBJECT-TYPE SYNTAX FilteringRulesNextInterfaceEntry STATUS current DESCRIPTION "An instance of this class describes the specific actions which is triggered when a packet is matched." ::= { filteringRulesNextInterfaceTable 1 } FilteringRulesNextInterfaceEntry ::= SEQUENCE { serviceSessionDataName OCTET STRING, userSessionDataName OCTET STRING, nextHopAddr InstanceId } serviceSessionDataName OBJECT-TYPE SYNTAX OCTET STRING STATUS current DESCRIPTION "...???..." ::= { FilteringRulesNextInterfaceEntry 1 } Ottensmeyer, et. al. [Page 14] INTERNET-DRAFT Filtering PIB Model and Provisioning October 2000 userSessionDataName OBJECT-TYPE SYNTAX OCTET STRING STATUS current DESCRIPTION "...???..." ::= { FilteringRulesNextInterfaceEntry 2 } nextHopAddr OBJECT-TYPE SYNTAX InstanceId STATUS current DESCRIPTION "This is the interface to which this rule belongs to" ::= { FilteringRulesNextInterfaceEntry 3 } -- -- all the other "Filtering Rules" needed go here -- -- -- The accounting table. -- accountingTable OBJECT-TYPE SYNTAX SEQUENCE OF EAcctPolAceStatsEntry POLICY-ACCESS install-notify STATUS current DESCRIPTION "The class contains some additional timestamps for packets that are matched with a classifier. This class augments filteringRulesBaseTable. The use of AUGMENTS implies that whenever an instance of FilteringRulesBaseEntry is created, a corresponding instance of accountingEntry is also created." ::= { filteringPibClass 5 } accountingEntry OBJECT-TYPE SYNTAX AccountingEntry STATUS current DESCRIPTION "An instance of this class describes the packet and byte counts for each ACE. " AUGMENTS( FilteringRulesBaseTable ) Ottensmeyer, et. al. [Page 15] INTERNET-DRAFT Filtering PIB Model and Provisioning October 2000 ::= { acctPolAceStatsTable 1 } AccountingEntry::= SEQUENCE { acctStatsPacketCount Unsigned32, acctStatsByteCount Unsigned64, } acctStatsPacketCount OBJECT-TYPE SYNTAX Unsigned32 STATUS current DESCRIPTION "The count of packets matching the classifier during the reporting interval." ::= {AccountingEntry 1} acctStatsByteCount OBJECT-TYPE SYNTAX Unsigned64 STATUS current DESCRIPTION "The byte count of packets matching the classifier during the reporting interval." ::= { AccountingEntry 2} -- -- The opaque ServiceSession and UserSessiontable. -- sessionTable OBJECT-TYPE SYNTAX SEQUENCE OF sessionEntry POLICY-ACCESS install-notify STATUS current DESCRIPTION "The class contains data which is relevant for the PDP only it is stored on the PEP make sure that at synchonization (e.g. after reconnectiong to another PDP, that PDP knows all about the established sessions on this PEP and need not interupt/close existing sessions." ::= { filteringPibClass 5 } sessionEntry OBJECT-TYPE SYNTAX SessionEntry Ottensmeyer, et. al. [Page 16] INTERNET-DRAFT Filtering PIB Model and Provisioning October 2000 STATUS current DESCRIPTION "see above" ::= { sessionTable 1 } SessionEntry::= SEQUENCE { sessionData OCTET STRING } sessionData OBJECT-TYPE SYNTAX OCTET STRING STATUS current DESCRIPTION "This syntax and semantic of this data is opaque to PDP" ::= {sessionEntry 1} END 6. Security considerations The ability to set filtering policies on a router introduces several potential risks to user service sessions on this router. Therefore, it must be ensured that only authorized managers are able to set these policies. The security features of the COPS protocol [COPS] fulfills this requirement. The use of COPS for Policy Provisioning [COPS-RP] introduces no new security issues over the base COPS protocol. The security mechanism described in that document should also be deployed in the Filtering PIB provisioning environment. 7. References [COPS] J. Boyle, R. Cohen, D. Durham, S. Herzog, R. Rajan, A. Sastry., "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000 [COPS-PR] Reichmeier, F. et. al., "COPS usage for Provisioning", work in progress, , October 1999 [Policy] Stevens, M., et. al., "Policy Framework" work in progress, , September 1999 Ottensmeyer, et. al. [Page 17] INTERNET-DRAFT Filtering PIB Model and Provisioning October 2000 [SPPI] K. McCloghrie, et. al., "Structure of Policy Provisioning Information", work in progress, , July 2000. [FRW-PIB] M. Fine, et.al., "Framework Policy Information Base", work in progress, , Sept. 2000 [ACCT-PIB]D. Rawlins, et. al., "Framework of COPS-PR Policy Information Base for Accounting Usage", work in progress, , July 2000 [XDR] Srinivasan, R., "External Data Representation Standard", RFC 1832, August 1995 8. Author Information Joerg Ottensmeyer Martin Bokaemper Siemens AG Unisphere Solutions Inc. Hofmannstr. 51 Kanata K2K 2M5 Munich, Germany, D-81359 Ontario, Canada Phone: +49 89 722-43239 Phone: (613) 271-8440 Email: Joerg.Ottensmeyer@icn.siemens.de Email: mbokaemper@unispherenetworks.com Kai Roeber T-Nova Phone: +49 4121 808-114 Email: Kay.Roeber@Telekom.de 9. Full Copyright Notice Copyright (C) The Internet Society (1997). 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 Ottensmeyer, et. al. [Page 18] INTERNET-DRAFT Filtering PIB Model and Provisioning October 2000 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. Annex A - XDR definition of Filter Information Base Objects This Annex lists the XDR description for the objects shared between the PDP and the PEP as used in our implementation. A detailed description of these attributes will be provided in a future version of this draft. /********************************************************************* * enumeration of all F-PIB classes (main and auxiliary) that are needed */ enum F_PIBObjectIdentifier { /* miscellaneous objects */ oidInterfaceObject=1, /* interface info passed from PEP->PDP*/ /* subsidiary objects */ oidClaclObject=2, /* Access Control List */ oidTrafficClassObject=3, /* TC */ oidRateLimitObject=4, /* rate limit parameters */ /* rules */ oidRuleNextInterface=5, /* next interface rule */ oidRuleNextHop=6, /* next hop rule */ oidRuleFilter=7, /* filter rule */ oidRuleTrafficClass=8, /* traffic class rule */ oidRuleRateLimit=9, /* rate limiting rule */ oidRuleMarking=10, /* marking rule */ /* rule accouting for each of the above rules 1:1 mapping */ Ottensmeyer, et. al. [Page 19] INTERNET-DRAFT Filtering PIB Model and Provisioning October 2000 oidRuleNextInterfaceAcct=12, oidRuleNextHopAcct=13, oidRuleFilterAcct=14, oidRuleTrafficClassAcct=15, oidRuleRateLimitAcct=16, oidRuleMarkingAcct=17, /* PEP opaque data */ oidServiceSessionData=19, oidUserSessionData=20, oidEnd=21 }; /********************************************************************* the FRID class ********************************************************************/ struct FilterRuleId { /* object identifies the object that is being talked about */ /* it also implies the data type of the object to follow */ F_PIBObjectIdentifier object; /* the name is unique per object identifier, and must uniquely */ /* define a given object */ string name<>; }; /********************************************************************* the Interface class ********************************************************************/ struct Interface { unsigned int ipAddress; unsigned int ipMask; unsigned int broadcastAddr; unsigned int mtu; string virtualRouterName<>; string interfaceName<>; unsigned int interfaceUid; /* for RuleNextInterface */ unsigned int interfaceDirection; /* ingress = 1, egress = 2 */ /* ppp information */ /* only if the interface is used by only one user; */ /* otherwise, pppLoginName has length zero, */ /* and userIpAddress is set to zero */ string pppLoginName<>; unsigned int userIpAddress; Ottensmeyer, et. al. [Page 20] INTERNET-DRAFT Filtering PIB Model and Provisioning October 2000 }; /********************************************************************* the classifier class ********************************************************************/ struct Classifier { /* PolicyManagerClassifierControlRuleGroup */ unsigned int action; /* permit = 1, deny = 2 (8bits)*/ unsigned int protocol; /* protocol being matched (8bits) */ unsigned int srcIpAddress; /* source ip and mask */ unsigned int srcIpMask; unsigned int srcOper; /* port operation (16 bits)*/ /* lt(0),gt(1),eq(2),neq(3),rnge(4) */ unsigned int srcFromPort; /* source port or begin if range 16b*/ unsigned int srcToPort; /* source port end if range 16b*/ unsigned int destIpAddr; /* destination ip and mask */ unsigned int destIpMask; unsigned int destOper; /* port operation 16b*/ unsigned int destFromPort; /* destination port/beg for rng 16b */ unsigned int destToPort; /* dest port end if range 16b */ unsigned int icmpType; /* icmp type 16b */ unsigned int icmpCode; /* icmp code 16b */ unsigned int igmpType; /* igmp type 16b */ unsigned int fromPrec; /* prec value or begin if range 16b */ unsigned int toPrec; /* last prec value if range 16b */ }; struct TrafficClassObject { /* to be defined */ }; struct RateLimitProfileObject { /* to be defined */ }; /******************************************************************* the filter rule classes ******************************************************************* each rule has "priority", which is for placement within the policy list for the interface each rule has "sessionDataName", which is the name of the opaque session data that the rule is using ********************************************************************/ struct RuleNextInterface { Ottensmeyer, et. al. [Page 21] INTERNET-DRAFT Filtering PIB Model and Provisioning October 2000 unsigned int priority; string serviceSessionDataName<>; string userSessionDataName<>; string ClassifierName<>; unsigned int interfaceUid; /* from InterfaceObject */ unsigned int nextHopAddr; /* IP address, 0 is use-none */ }; struct RuleNextHop { unsigned int priority; string serviceSessionDataName<>; string userSessionDataName<>; string sessionDataName<>; unsigned int nextHopAddr; /* IP address*/ }; struct RuleFilter { unsigned int priority; string serviceSessionDataName<>; string userSessionDataName<>; string sessionDataName<>; string ClassifierName<>; }; struct RuleTrafficClass { unsigned int priority; string serviceSessionDataName<>; string userSessionDataName<>; string sessionDataName<>; string ClassifierName<>; string trafficClass<>; }; struct RuleRateLimit { unsigned int priority; string serviceSessionDataName<>; string userSessionDataName<>; string sessionDataName<>; string ClassifierName<>; string rateLimitName<>; }; struct RuleMarking { unsigned int priority; string serviceSessionDataName<>; string userSessionDataName<>; Ottensmeyer, et. al. [Page 22] INTERNET-DRAFT Filtering PIB Model and Provisioning October 2000 string sessionDataName<>; string ClassifierName<>; unsigned int markValue; /* 0..7 */ }; /************************************************************************* * the accounting classes *************************************************************************/ struct RuleNextInterfaceAcct { unsigned int bytes; unsigned int gigawords; unsigned int packets; }; struct RuleNextHopAcct { unsigned int bytes; unsigned int gigawords; unsigned int packets; }; struct RuleFilterAcct { unsigned int bytes; unsigned int gigawords; unsigned int packets; }; struct RuleTrafficClassAcct { unsigned int bytes; unsigned int gigawords; unsigned int packets; }; struct RuleRateLimitAcct { unsigned int bytes; unsigned int gigawords; unsigned int packets; }; struct RuleMarkingAcct { unsigned int bytes; unsigned int gigawords; unsigned int packets; }; /************************************************************************* * the session classes *************************************************************************/ Ottensmeyer, et. al. [Page 23] INTERNET-DRAFT Filtering PIB Model and Provisioning October 2000 struct ServiceSessionData { opaque data<>; }; struct UserSessionData /* also called access session data */ { opaque data<>; }; Ottensmeyer, et. al. [Page 24]