Internet Engineering Task Force John Strassner INTERNET DRAFT Stephen Schleimer 17 November 1998 Cisco Systems Policy Framework Definition Language draft-ietf-policy-framework-pfdl-00.txt Status of 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 "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract Recently, the IETF has developed protocols that classify packets in order to treat certain classes or flows of packets in a particular way compared to other classes or flows of packets. The successful wide-scale deployment of these protocols depends on the ability to administer and distribute consistent policy information to different types of network devices as well as hosts and servers that participate in policy decision making, administration, distribution and control. There is a clear need to develop a scalable framework for policy administration and distribution that will enable interoperability among multiple devices and device types that must work together to achieve a consistent implementation of policy. This document defines a language, called the Policy Framework Definition Language (PFDL), that maps requirements for services to be provided by the network as defined in a business specification (e.g., an SLA) to a common vendor- and device-independent intermediate form. This enables policy information and specifications to be shared among the heterogeneous components that comprise the policy framework, and allows multiple vendors to use multiple devices to implement that framework. The PFDL is the common 'currency' that is exchanged between these heterogeneous components to enable them all to perform their function in providing, securing, distributing, and administering policy. The PFDL becomes the way to ensure that multiple vendors interpret the policy the same way while enabling vendors to provide value-added services. Strassner and Schleimer Expires 5 March 1999 [Page 1] INTERNET DRAFT draft-ietf-policy-framework-pfdl-00.txt 17 Nov 98 Definition of Key Word Usage The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in RFC 2119 [TERMS]. These words will be capitalized to ensure that their intent in this context is easily discernible. Table of Contents Status of this memo Abstract 1. Introduction 2. Difference Between the PFDL and Other Languages 3. The Structure of Policies in the PFDL 3.1 Policy Component Hierarchy 3.1.1 The ComplexPolicy class 3.1.2 The SimplePolicy class 3.1.3 The PolicyRule class 3.1.4 The PolicyCondition class hierarchy 3.1.5 The PolicyAction class 3.2 Policy Conflict Detection 3.2.1 Types of Policy Conflicts 3.2.2 Intra-Policy Conflicts 3.2.3 Inter-Policy Conflicts 3.3 Service and Usage Policies 3.3.1 Service Policies 3.3.2 Usage Policies 3.4 Collective Aspects of Policy 3.4.1 Roles 3.4.2 Groups 4. The Grammar of the PFDL 5. Examples of Using the PFDL 6. Security Considerations 7. Acknowledgements 8. References 9. Author's Addresses APPENDICES Appendix A: PFDL Syntax in BNF Strassner and Schleimer Expires 5 March 1999 [Page 2] INTERNET DRAFT draft-ietf-policy-framework-pfdl-00.txt 17 Nov 98 1. Introduction and Motivation A policy is a named object that represents an aggregation of Policy Rules. The policy describes the overall business function(s) to be accomplished, while the set of policy rules defines how those business functions will be met. A policy rule defines a sequence of actions to be initiated when a corresponding set of conditions is satisfied. It should be noted that a condition may be negated (e.g., NOT (user IN GoldSLAGroup) ). Therefore, this policy condition is satisfied when the specified user is NOT a member of the GoldSLAGroup. Policies are the link between a high-level business specification of desired services and low-level device configurations that provide those services. The Policy Framework Working Group will define a secure framework for policy administration, representation and distribution for multiple devices and device types. This includes devices whose primary job is to enforce the policy (e.g., a network element) as well as other devices that have one or more of the following roles: policy storage, distribution, decision-making, conflict detection, conflict resolution, administration, and management. A framework that is comprised of heterogeneous components requires a common definition of policy. Furthermore, policy MUST be able to be represented and managed in an unambiguous, interoperable manner within a single network administrator's domain. Here, interoperability means providing a vendor- and device-independent specification of what the device configuration must do in order to provide the desired services. The Policy Framework Definition Language (PFDL) quantifies this link as a formal grammar. The purpose of the language is to translate from a business specification, such as those found in a Service Level Agreement, to a common vendor- and device-independent intermediate form. This enables policy information and specifications to be shared among the heterogeneous components that comprise the policy framework, and allows multiple vendors to use multiple devices to implement that framework. The PFDL is the common "currency" that is exchanged between these heterogeneous components to enable them all to perform their function in providing, securing, distributing, and administering policy. The PFDL becomes the way to ensure that multiple vendors interpret the policy the same way while enabling vendors to provide value-added services. The PFDL will first address the needs of expressing QoS policies for the Differentiated Services, Integrated Services, RAP, and ISSLL Working Groups. The design will be iterated as necessary while the Policy Framework itself matures, and then further iterated to ensure that the needs of detailed schemata are fulfilled. This draft represents the initial design of the PFDL. 2. Difference Between the PFDL and Other Languages < to be supplied > Strassner and Schleimer Expires 5 March 1999 [Page 3] INTERNET DRAFT draft-ietf-policy-framework-pfdl-00.txt 17 Nov 98 3. The Structure of Policies in the PFDL In addition to the requirements listed in Section 1 above, the Policy Framework architecture must be scalable, interoperable and reusable. Here, scalability refers to the ability to build reusable arbitrarily complex policies from a set of simple ones. Interoperability means that the PFDL must be expressed in a way that enables essential information to be communicated between different vendors' policy management systems and the devices of different vendors that are controlled by the policy management systems of different vendors. Specifically, a policy management system should be able to be constructed from multiple vendors, and it should be able to convey policy information to multiple vendors' devices. This requires a canonical definition of the structure of a policy. Reusability means that each component of a policy should be reusable by other policies. 3.1 Policy Component Hierarchy The design of the PFDL is based on satisfying the Policy Information Model being designed in the DMTF [PLYMDL]. The class and relationship hierarchies of the Policy Information Model help define the structure of the PFDL grammar. Accordingly, this section will provide a brief overview of the components that define a policy in the Policy Information Model that require specific constructs to be defined in the PFDL. 3.1.1 The ComplexPolicy class A ComplexPolicy can contain one or more SimplePolicies. This enables reusability at the policy level. For example, when a user logs on to the network, many different policies must be combined. Some of the different policies that could be assigned to a user include: - Security policies to enable proper access to network resources, as well as possible accounting and auditing functions - A DHCP lease policy that allocates an IP Address depending on who the user is, what services the user is contracted for (which in turn can depend on the role of the user), how the user is logging in (e.g., Ethernet vs. PPP), and other factors - QoS policies that get activated when the user logs on as well as other QoS policies that get activated on demand A ComplexPolicy is modeled as an aggregation of SimplePolicies. This represents reusability at the highest (policy) level. The PFDL MUST be able to express the aggregation of simple policies into a more complex policy. Both of these concepts must be able to be identified as named elements. Strassner and Schleimer Expires 5 March 1999 [Page 4] INTERNET DRAFT draft-ietf-policy-framework-pfdl-00.txt 17 Nov 98 3.1.2 The SimplePolicy class A SimplePolicy can contain one or more PolicyRules. Each SimplePolicy (a.k.a., a PolicyRule class) contains a SET of PolicyConditions and a SET of PolicyActions. The reason for this is that a PolicyRule is itself domain-specific. There are PolicyRules that define security mechanisms (e.g., authentication methods and ACL settings), QoS mechanisms (e.g., PHBs that will manage traffic), and other mechanisms for other related services. Each of these has its own definitions that are specific to its domain of knowledge, requiring a set of domain-specific conditions and actions. However, at a more abstract level, certain policies need one or more of these policy rules to be aggregated in order to provide the service(s) requested by a client. For example, when a user logs on, the Policy Information Model can describe the binding between the user and the services that a network provides by aggregating a set of policy rules. This might consist of an overall Security Policy that governs how the user will be authenticated and what services the user is authorized to utilize based on a number of factors (time of day, method of login, etc.). There might be a set of QoS policies that get activated based on the user's SLA. There might be a DHCP Lease Policy that controls what dynamic IP address the user is assigned. There might be separate accounting and auditing policies that get triggered on an as-needed basis. It is essential that these diverse policy rules get aggregated into a single consistent policy that can be associated with the user. The PFDL MUST be able to specify and support the aggregation of multiple policy rules into a single policy class. Furthermore, it must be able to treat policy rules and policy classes as discrete named objects. The concepts of order and priority are also needed. For example, assume that a Policy is comprised of multiple PolicyRules, where one of the PolicyRules expresses security restrictions. If the conditions of the security policy rule are not satisfied, then it is irrelevant if the conditions of the other policy rules are satisfied - the actions of all policy rules will not be executed. Thus, the concept of rule ordering is needed. Visually: IF SecurityPolicyRule is satisfied THEN IF DHCPLeasePolicy is satisfied THEN Execute QoSPolicies Execute AuditingPolicies ENDIF ENDIF Similarly, rule priority is a useful concept. For example, this provides one mechanism for resolving policy conflicts. Therefore, the PFDL MUST be able to express relational and logical operators, along with priority and ordering concepts. Strassner and Schleimer Expires 5 March 1999 [Page 5] INTERNET DRAFT draft-ietf-policy-framework-pfdl-00.txt 17 Nov 98 3.1.3 The PolicyRule class The PolicyRule class expresses a set of conditions that, when satisfied, triggers a set of actions to be performed. A set of conditions is used as part of a canonical template within each policy knowledge domain. That is, security, QoS, DHCP, IPSEC, and other policy knowledge domains will in general have their own specific templates that define a particular set of conditions and an associated actions that must be executed if those conditions are satisfied. A "canonical template" is prescribed for interoperability reasons. It is a fact that multiple vendors will be supplying multiple components as part of any general policy architecture. Therefore, a common communication methodology is needed. An extensible, canonical definition of what constitutes the conditions and actions of a given knowledge domain is offered as the solution to this interoperability requirement. Therefore, the PFDL MUST support modeling a set of conditions and a corresponding set of actions as an extensible template. Note that in addition to the above, a set of actions could be executed if the set of conditions are not satisfied. However, this can be modeled as a separate policy rule. This is preferred to complicating the model and the resulting grammar. The PFDL MUST be able to model a policy rule as an extensible template. The template consists of a set of conditions that, when satisfied, triggers the execution of an associated set of actions. 3.1.4 The PolicyCondition class hierarchy A policy condition, in the context of the Policy Framework Working Group, is defined as testing one or more aspects of users of the network and/or traffic flowing through the network, in order to see if either the correct policy state can be maintained, or if a newly desired policy state can be achieved. A PolicyRule is comprised of one or more policy conditions. Each policy condition is represented by a PolicyConditionList. For simplicity, if there are multiple PolicyConditionLists within a given PolicyRule, this version of the PFDL requires that the PolicyConditionLists are logically ORed together. A PolicyConditionList aggregates one or more PolicyConditionStatements. For simplicity, this version of this draft requires that each of the PolicyConditionStatements within a given PolicyConditionList are logically ANDed together. A PolicyConditionStatement consists of two parts, called a PolicyConditionCategory and a PolicyConditionValue. A PolicyConditionStatement defines a relation between a PolicyConditionCategory and a PolicyConditionValue. Strassner and Schleimer Expires 5 March 1999 [Page 6] INTERNET DRAFT draft-ietf-policy-framework-pfdl-00.txt 17 Nov 98 PolicyConditionCategories are predefined elements that are specific to a particular knowledge domain. They form the structure of the condition half of the policy rule template. For example, concepts like user, location, application type, and service are all categories of conditions that can be tested for a QoS policy, and hence are QoS PolicyConditionCategories. PolicyConditionValues represent the value that a given PolicyConditionCategory can take. Some of the limits and other general parameters of a PolicyConditionValue are pre-defied (e.g., a valid network address must be entered), but only to enforce validation of a specific value to be tested. PolicyConditionValues are the means to represent user- and application-specific values of the category of elements that are to be tested as part of this policy rule. The PFDL MUST support the representation and structuring of policy conditions as defined in this section. 3.1.5 The PolicyAction class hierarchy The PolicyAction class is in reality a list of one or more policy action statements. These policy action statement may be executed either in any order (default case) or in a prescribed order, through the use of specially defined attributes. A policy action, in the context of the Policy Framework Working Group, is defined as the changing of the configuration of one or more network elements in order to achieve a desired policy state. This (new) policy state provides one or more (new) behaviors. A PolicyRule is comprised of one or more policy actions. Each policy action is represented by a PolicyActionList. In contrast with PolicyConditionLists, the PolicyActionLists are not by default ORed together. In fact, the default relationship between a set of PolicyActionLists is that they are all executed in ANY order. To accommodate special situations, facilities exist for imposing an ordering of the PolicyActionLists as well as conditional execution of one or more PolicyActionLists based on the outcome (e.g., success or failure) of a previously executed PolicyActionList. A PolicyActionList aggregates one or more PolicyActionStatements. The PolicyActionStatements within a given PolicyActionList are by default executed in ANY order. However, facilities exist for imposing an ordering of the PolicyActionStatements within a given PolicyActionList as well as conditional execution of one or more PolicyActionStatements based on the outcome (e.g., success or failure) of a previously executed PolicyActionStatement. A PolicyActionStatement is comprised of two parts, a PolicyActionCategory and a PolicyActionValue. A PolicyActionStatement defines a relation between a PolicyActionCategory and a PolicyActionValue. However, the PolicyActionValue is dependent on the type of PolicyActionCategory. Therefore, the PFDL combines these. Strassner and Schleimer Expires 5 March 1999 [Page 7] INTERNET DRAFT draft-ietf-policy-framework-pfdl-00.txt 17 Nov 98 The PolicyActionCategory defines a canonical set of operations or treatments that can be given to traffic flowing into and out of a network element (e.g., deny, change code point, etc.) in a vendor- and device-independent manner. The PolicyActionValue specifies the type of mechanism to be used to provide the specified operation or treatment. PolicyActionCategories are predefined elements that are specific to a particular knowledge domain. They form the structure of the action half of the policy rule template. For example, concepts like providing a specific service for a particular application or class of traffic are categories of actions that can be performed for a QoS policy, and hence are QoS PolicyActionCategories. A PolicyActionValue represents the value that a given PolicyActionCategory can take. Some of the limits and other general parameters of a PolicyActionValue are pre-defied (e.g., a valid network address must be entered), but only to enforce validation of a specific action to be performed. PolicyActionValues are the means to represent user- and application-specific values of the category of services that are to be provided by a specified network element as part of this policy rule. The PFDL MUST support the representation and structuring of policy actions as defined in this section. 3.2 Policy Conflict Detection Policy conflict detection is crucial to the design of a scalable and deployable policy framework. The concept of policy detection is actually fairly straightforward. However, the implementation of policy conflict detection can be quite complicated in the general case. Therefore, this proposal explicitly limits the power and flexibility of the PFDL in order to ensure that conflict detection and resolution is both doable and implementable. 3.2.1 Types of Policy Conflicts There are two fundamental types of policy conflicts: those caused by within a policy (either a SimplePolicy or a ComplexPolicy) and those that cause a conflicting action to be taken in the network. These are referred to as Intra- and Inter-Policy conflicts. 3.2.2 Intra-Policy Conflicts An intra-policy conflict occurs when the conditions of two or more policies can be simultaneously satisfied, but the actions of at least one of the policies can not be simultaneously executed. This implies several things: - one or more policy rules of each of the policies is satisfied by the same request - each condition of each of the conflicting policy rules is satisfied by the same request Strassner and Schleimer Expires 5 March 1999 [Page 8] INTERNET DRAFT draft-ietf-policy-framework-pfdl-00.txt 17 Nov 98 - one or more actions specified by one policy conflict with one or more actions specified by the other policy Intra-policy conflicts can be resolved in a number of different ways. The simplest is to change the conditions and/or actions of one of the policies so that it no longer conflicts with the other policies. However, if the policies must remain inherently conflicting, then there are a number of ways to resolve the conflict on an individual event basis, including the following: - apply a "match-first" criteria, wherein conflicts are resolved by matching the first policy that is found - apply a priority order criteria, wherein conflicts are resolved by finding all policy rules which match a given event and selecting only the rule with the highest priority - use additional metadata to determine which rule or rules should be applied. The difference between this and straight priority is that priority is inherently linear, whereas metadata enables non- linear solutions, such as branching, to be used. The PFDL MUST support facilities to resolve conflicts. 3.2.3 Inter-Policy Conflicts An inter-policy conflict is defined as two or more policies that, when applied to the network, result in conflicting configuration commands and/or mechanisms to be specified for one or more network devices. It is important to note that in this case, the two (or more) conflicting policies do not conflict when compared to each other, but do conflict when applied to a specific network device or devices. For example, two policies could specify conflicting configurations on a given interface, or specify that a certain number of queues be used in one network device and a different number of queues be used in another network device for the same traffic flow. The PFDL must support constructs that enable such conflicts to be resolved. 3.3 Service and Usage Policies There are two different types of policies. They are called Service Policies and Usage Policies. It is not mandatory for the PFDL to support explicit identification of whether a policy is categorized as a service or a usage policy - this is really more for the convenience of an associated UI and for the implementation of a Policy Server. However, the PFDL should not prevent the optional specification of whether a policy is categorized as a service or usage policy. Strassner and Schleimer Expires 5 March 1999 [Page 9] INTERNET DRAFT draft-ietf-policy-framework-pfdl-00.txt 17 Nov 98 3.3.1 Service Policies Service policies describe the creation of services in the network. They organize the facilities that the network provides into services that may be used later to satisfy the requirements of users of the network. For example, creating various QoS service classes (VoiceTransport, VideoTransport, ..., BestEffort) is done using service policies. This is accomplished, for example, by establishing the PHBs needed on backbone interfaces over which the traffic to be afforded the specific service is to flow. The application of a service policy results in the creation of one or more named objects that represents network services that are available for usage policies. 3.3.2 Usage Policies Usage policies describe how to allocate the services created by Service policies to requestors of services. Usage policies describe particular mechanism(s) employed to either maintain the current state of the object, or to transition an object from one state to a new state, in order to utilize the specified services. Usage policies associate services that are provided by the network to clients of the network (e.g., users and applications). This can include services provided indirectly (e.g., mark packets of this type with this DS value) as well as directly (use this set of reservation parameters for this class of traffic). Usage policy actions are specifically limited to associating a service with a particular PolicyActionCategory. For example, all users in the QuarterEndFinance group are assigned Gold Service for the SAP application under the following conditions. Put another way, service policies describe what the network is capable of providing, and usage policies describe how to configure the network in order to take advantage of one or more services that the network provides. 3.4 Collective Aspects of Policy An essential attribute of policy is its collective nature. That is, policies are created in order to control many possibly heterogeneous objects of the system that are under the control of a policy management infrastructure. For example, when we create a particular PHB, we want to be able to apply it to all the interfaces to which it is appropriate. Two mechanisms are provided for the collective aspects of policy: roles and groups. Strassner and Schleimer Expires 5 March 1999 [Page 10] INTERNET DRAFT draft-ietf-policy-framework-pfdl-00.txt 17 Nov 98 3.4.1 Roles A role is a label. A role indicates a function that an interface or device in the network serves. For example, an interface in the core of the network connecting to another interface in the core of the network provides "backbone" services (it aggregates a large number of flows; it is very high speed; etc). We assign to this interface the role "BackBone". When we create a policy appropriate to interfaces serving a backbone role, we assign the role "BackBone" to that policy. Another important use of roles is to explicitly differentiate the functions provided by a device. Continuing the above example, an "Edge" role could be defined that describes the various services provided by interfaces at the edge of the network (e.g., filtering, traffic shaping, rate limiting, etc.). These services together describe the functionality of an edge interface, but also serve to differentiate it from the functionality of a core interface. Roles enable an administrator to group the interfaces of multiple devices into common groups. This enables the administrator to apply the same policy to each of these interfaces collectively, as opposed to individually. A role may be associated with, at most, a single Policy (where a single Policy may be as complex as necessary. Policies associated with a role are specifically intended to apply to interfaces or devices that are assigned the role. An interface may be assigned multiple roles. When an interface is assigned multiple roles, the policies designated by those roles are intended to apply to that interface. Roles may be parameterized. This is to enable the definition of more complex policies that define configurations that contain values that depend on the combination of type of interface, media being used, protocol being used, and other factors. For example, a policy might be applied to all Frame Relay interfaces. Depending on the actual network topology, the types of congestion experienced in these interfaces might be different. The parameterized policy offers a way to group these Frame Relay interfaces together (to simplify administration) while providing an inherent flexibility to accommodate the particular semantics of interfaces that are identified by this role. For example, some kind of conditional expression associated with a Role which partitions the space of interfaces. Those interfaces included by the conditional would take the role; those interfaces not included by the conditional would not take the role. When there are several roles assigned to an interface, inter-policy conflicts may occur. They are resolved as described in section 3.2.2. Strassner and Schleimer Expires 5 March 1999 [Page 11] INTERNET DRAFT draft-ietf-policy-framework-pfdl-00.txt 17 Nov 98 3.4.2 Groups Grouping is a fundamental concept of aggregation. In most systems, a group is a named object that contains individual objects as well as possibly additional (sub-)groups of objects. The key point here is that group membership is statically determined. Unfortunately, networks are inherently dynamic in nature. This means that the ability to "group" objects whose membership is determined dynamically (e.g., a s a function of the state of the system) is required. We will call this a "Dynamic Group". The most important characteristic of a Dynamic Group is that its membership is determined dynamically when a reference to the Dynamic Group is evaluated. Dynamic Group objects can therefore represent either individual objects or other groupings of objects. For example, a Dynamic Group ranging over users may be used to limit which users on a certain set of interfaces have a certain kind of QoS assigned to packets they generate. A Dynamic Group is only used as a value part of a condition of a policy. If a PolicyConditionValue uses a grouping construct, then that policy is satisfied if the object specified in the PolicyConditionCategory satisfies the relationship specified in the policy between the object in the PolicyConditionCatgegory and the membership of the Dynamic Group specified in the PolicyConditionValue. For example, suppose that a logon is in progress. Further suppose that a policy tests for users who are engineers belonging to a group that is to receive Gold QoS. Then, at the instant of the testing of the condition, the set of user objects that the Dynamic Group specifies (people that are entitled to receive Gold QoS) is determined. If the object representing the user logging in is in the set specified by the Dynamic Group, then this condition of the policy is satisfied. The objects of a Dynamic Group are always determined by the range of objects that the PolicyConditionCategory can specify. For example, there are several ways in which the type can specify the objects that it contains. These same methods can be used by other types of PolicyConditionCategories, but the different semantics of each type of PolicyConditionCategory result in different memberships being built for PolicyConditionCategory. There are several ways in which a Dynamic Group can specify the objects It designates: by characterization, by enumeration, or by a combination of the two. A Dynamic Group uses characterization in order to be able to explicitly define acceptable values for the attributes of the object. For example, suppose that a object has the attributes name, job title, and supervisor. A group, LucasEngineers, might be characterized as follows: Strassner and Schleimer Expires 5 March 1999 [Page 12] INTERNET DRAFT draft-ietf-policy-framework-pfdl-00.txt 17 Nov 98 Group over named LucasEngineers: Job Title = "engineer", Supervisor = "Luca". Then, a condition might be written as follows: IN LucasEngineers This condition would be satisfied in the user designated by the object being tested in the above had a supervisor attribute named "Luca" and job title attribute named "engineer". A Dynamic Group may also specify the objects that are its members using enumeration. That is, the individual objects that the Dynamic Group is to specify may simply be explicitly listed. For example, a Dynamic Group of type can refer to the objects it contains, (e.g., LucasEngineers) by explicitly listing its members as opposed to characterizing attributes or behaviors of those objects. If the membership of the LucasEngineers Dynamic Group was explicitly defined, it might look as follows: {, , , } where each of the bracketed entities refers to a user object. Finally, a group may specify the object it designates by both characterization and enumeration. The above examples could easily be combined to yield such a group. 4. The Grammar of the PFDL 5. Examples of Using the PFDL 6. Security Considerations Security and denial of service considerations are not explicitly considered in this memo, as they are appropriate for the underlying policy architecture. However, the policy architecture must be secure as far as the following aspects are concerned. First, the mechanisms proposed under the framework must minimize theft and denial of service threats. Second, it must be ensured that the entities (such as PEPs and PDPs) involved in policy control can verify each other's identity and establish necessary trust before communicating. 7. Acknowledegments Many thanks to the useful discussions and suggestions from the Internet Community at large but especially to . Strassner and Schleimer Expires 5 March 1999 [Page 13] INTERNET DRAFT draft-ietf-policy-framework-pfdl-00.txt 17 Nov 98 8. References [TERMS] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", Internet RFC 2119, March 1997. 9. Authors' Addresses John Strassner Cisco Systems 170 West Tasman Drive, Building 1 San Jose, CA 95134 Phone: +1-408-527-1069 Fax: +1-408-527-1722 E-mail: johns@cisco.com Stephen Schleimer Cisco Systems 170 West Tasman Drive, Building D San Jose, CA 95134 Phone: +1-408-527-3291 Fax: +1-408-???-???? E-mail: sschlmr@cisco.com Strassner and Schleimer Expires 5 March 1999 [Page 14] INTERNET DRAFT draft-ietf-policy-framework-pfdl-00.txt 17 Nov 98 Appendix A: BNF of the PFDL ::= []+ ::= []+ | ':' []+ ::= 'IF' 'THEN' /* still have to put in priority */ ::= ]* ::= ['AND' ]* ::= | 'NOT' ::= | | | | | | | | ::= USER_CATEGORY_REFERENCE /* the values for are all either email addresses or a Distinguished Name */ /* the following are all DNs */ ::= | | /* "division" */ | ::= APPLICATION_CATEGORY_REFERENCE Strassner and Schleimer Expires 5 March 1999 [Page 15] INTERNET DRAFT draft-ietf-policy-framework-pfdl-00.txt 17 Nov 98 ::= | 'SOURCE:' | 'DESTINATION:' ::= DEVICE_CATEGORY_REFERENCE ::= | | ::= INTERFACE_CATEGORY_REFERENCE ::= ::= PROTOCOL_CATEGORY_REFERENCE ::= []* | []* ::= ADDRESS_CATEGORY_REFERENCE ::= 'SOURCE:' | 'DESTINATION:' | 'BOTH:' ::= TRAFFIC_CATEGORY_REFERENCE ::= | | | | ::= SLA_CATEGORY_REFERENCE Strassner and Schleimer Expires 5 March 1999 [Page 16] INTERNET DRAFT draft-ietf-policy-framework-pfdl-00.txt 17 Nov 98 ::= 'SLA NAME:' SLA_VALUE []* ::= TIME_CATEGORY_REFERENCE ::= | ::= | ::= 'IN' | 'NOT IN' | 'EQUALS' | 'NOT EQUALS' | 'GREATER THAN' | 'GREATER THAN OR EQUAL TO' | 'LESS THAN' | 'LESS THAN OR EQUAL TO' ::= []+ ::= [] [] ::= 'PERMIT' | 'DENY' | 'REMARK PACKET' | 'START USING' | 'STOP USING' | 'Table Definition' ::= '{' "}" ::= 'RED_THRESHOLDS' | 'TAIL_DROP' | ... ::= '{' '}' ::= INTEGER Strassner and Schleimer Expires 5 March 1999 [Page 17] INTERNET DRAFT draft-ietf-policy-framework-pfdl-00.txt 17 Nov 98 ::= '{' INTEGER* '}' ::= '{' * '}' ::= '{' * '}' | '{' * '}' ::= INTEGER | ':' INTEGER ::= INTEGER ::= INTEGER Strassner and Schleimer Expires 5 March 1999 [Page 18]