Network Working Group L. Rafalow Internet Draft IBM Expires: January 2002 L. Yang Intel A. Beck Lucent July 2001 Policy Requirements for Edge Services draft-rafalow-opes-policy-requirements-00.txt 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 Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract The framework for application-level services at the edge of a network enables applying selected services to web application traffic at OPES intermediary systems. This document describes the requirements for the control of the selection of and parameters for the services that are to be applied to a given content flow. The objective of this document is to clearly describe the intended capabilities and constraints in calling services from an OPES intermediary. There has already been work done to develop a policy language and this requirements analysis is both based upon and extends that work; of course, the intention is to guide the further development of the policy language and the underlying information model. Rafalow, et al. Informational [Page 1] Internet Draft OPES Policy Requirements July 2001 Table of Contents 1. Introduction.....................................................2 1.1. Terminology....................................................3 2. Policy Scope of Control..........................................3 3. Policy Architecture..............................................3 3.1. Policy Components..............................................3 3.1.1. Functional Decomposition.....................................4 3.1.2. Policy Decision Point........................................5 3.1.3. OPES Intermediary Rule Engine................................5 3.1.4. Rule Processing Points.......................................6 3.2. Called Services................................................7 3.2.1. Service Bindings.............................................7 3.2.2. Environment Variables........................................8 3.2.3. Preventing Unnecessary Calls.................................9 3.2.4. Passing Information Between Services........................10 4. Rule Management.................................................10 5. Rules...........................................................10 5.1. Rule Formats and Protocols....................................10 5.2. Conditions....................................................11 5.3. Actions.......................................................12 6. Security Considerations.........................................12 7. Acknowledgments.................................................12 8. References......................................................12 9. Authors' Addresses..............................................13 10. Full Copyright Statement.......................................13 1. Introduction OPES intermediary systems such as proxies and gateways may participate in a distributed application system by providing authorized services to customize the users' experience or to otherwise distribute the content services of a content provider. Policies express the goals for these intermediary participants in the distributed system "as a set of rules [used] to administer, manage and control access to network resources" [4]. The requirements in this document and the resulting solutions govern the behavior of an application-level OPES intermediary in determining which, if any, of available services are to be applied to a given message. This draft of this document is an initial stake-in-the-ground in an effort to develop a consensus on requirements. The requirements in this document are organized as follows: 2. Policy Scope of Control requirements specify the applicability scope of the policies; 3. Policy Architecture requirements deal with the functional decomposition of the policy system and nature of the interfaces between the various components of the policy system; Rafalow, et al. Informational [Page 2] Internet Draft OPES Policy Requirements July 2001 4. Rule Management requirements deal with the relationship between rule providers and the management of those policies; and 5. Rules requirements deal with the specific semantics required in expressing policies for application-level intermediaries. 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]. Other terminology used in this document is (intended to be) consistent with that defined and used in [4], [5], [6], [7] and [8]. 2. Policy Scope of Control The OPES intermediary policies described in this document are limited to those that describe which services to call and, if appropriate, with what parameters. These policies do not include those that prescribe the behavior of the called services. The services that may be invoked from an OPES intermediary can be quite varied. Although it is desirable to enable a common management framework for specifying policies for both the calling of and the behavior of a service, the integration of such function is the domain of policy administration user interaction applications. Where possible, a common policy framework for both the calling OPES intermediaries and the called services will facilitate integration at the policy management tools. Further, a common policy framework will also facilitate integration of the OPES policy with other policies such as QOS and security policy which, from an administrator's perspective, may be closely related. Therefore, the Policy Core Information Model [3] SHOULD be used where it aids in the development of the OPES policy model. 3. Policy Architecture This section describes the functional decomposition requirements and general requirements for the interfaces between the components. 3.1. Policy Components The following requirements are intended to enable both high performance implementations as well as describe the interface requirements. Rafalow, et al. Informational [Page 3] Internet Draft OPES Policy Requirements July 2001 3.1.1. Functional Decomposition +--------+ +--------+ | Rule | | Rule | | Author | ... | Author | +--------+ +--------+ | | | | | +----------+ | | | Policy | | <- PDP Interface +--------->| Decision |<----------+ | Point | +----------+ | ^ | | | | <- PEP Interface | | V | +--------------+ ... ---> | Policy | ---> | Enforcement | Data Traffic <--- | Point | <--- +--------------+ Figure 1 Policy Components The policy functions are decomposed into three components: a Rule Author, a Policy Decision Point (PDP) and a Policy Enforcement Point (PEP) [4]. The Rule Author (which has the role defined as a Policy Management Tool in [4]) provides the rules to be used by an OPES intermediary; these rules control the invocation of services on behalf of the rule author. Together, the PDP and the PEP interpret the collected rules and appropriately enforce them. The architectural decomposition into a PDP and a PEP permit the offloading of some tasks to an administrative service that MAY be located on a separate server from the real-time enforcement services of the PEP that reside on the OPES intermediary. The PDP provides for the authentication and authorization of rule authors and the validation and compilation of rules. The PEP is composed of a rule engine (called OPES Intermediary Rule Engine) that evaluates the data traffic against the compiled rules and then executes appropriate calls to the requested services. Interfaces between these architectural components are points of interoperability. The interface between rule authors and the policy decision points (labeled "PDP Interface" in Figure 1) MUST use the standard that results from these requirements. Since the interface between the policy decision points and the policy enforcement points (labeled "PEP Interface" in Figure 1) MAY be internal to a computer system (i.e., they may be internal to a vendor implementation), Rafalow, et al. Informational [Page 4] Internet Draft OPES Policy Requirements July 2001 implementations MUST use the standard interface only if the PDP and the PEP reside on different computer systems. (As a result of further analysis, these two interfaces may be merged into one interface if the syntax and semantics warrant only a single protocol and set of formats.) 3.1.2. Policy Decision Point For the purposes of this requirements discussion, the Policy Decision Point is essentially a policy compiler. The PDP is one of a set of services that provide administrative support to the enforcement points that also include authenticating the rule authors and assuring that rules specified by these origins are within their scope of authority. The PDP is a component of the OPES Admin Server [8]. See section 4. "Rule Management." 3.1.3. OPES Intermediary Rule Engine Editors note: The authors seem to have a disagreement about the following requirements; this will get hashed out in the working group discussions. Since the OPES intermediary is on the data path, it must be able to classify traffic very efficiently. The design of the policy rule language and the underlying information model MUST NOT require a procedural execution model and SHOULD be expressed as declarative statements to facilitate table-driven classification implementations. One implication of this requirement is that the evaluation of conditions MUST NOT have side effects that might alter the result of evaluating other conditions on the same pass through the rule engine. Thus, implementations may order the evaluation of conditions to optimize the data path as long as the policy semantics and the order of action execution are preserved. Similarly, the execution of an action (i.e., the calling of a requested service) also MUST NOT have side effects that alter the result of evaluating other conditions on the same pass through the rule engine. Rules MAY chain actions together, that is, they can specify a series of services to be called, but they cannot have the output of one service be evaluated to determine if another service is to be called. This performance requirement does not, however, obviate the need for passing information from one called service to another nor does it prohibit re-evaluating a message to determine if another service or set of services should be called. However, solutions SHOULD enable implementations that minimize the performance penalty for multiple passes through a rule engine and certainly MUST have clear rule evaluation termination criteria. Editors note: vs... Rafalow, et al. Informational [Page 5] Internet Draft OPES Policy Requirements July 2001 The execution of an action (i.e., the calling of a requested service) MAY lead to the modification of message property values. For example, an OPES service that under some circumstances converts JPEG images to GIF images modifies the content type of the requested web object by doing so. Such modifications of message property values MAY change the behavior of subsequently called OPES services. The rule engine MUST therefore act on matched rules (i.e. execute the triggered OPES service) BEFORE it evaluates subsequent rules unless the rule engine can determine in advance that the execution of a triggered service cannot have side effects on the evaluation of subsequent rules. In order to determine this, it would be desirable if registered OPES services provided the rule engine with a list of message properties which they may modify. This would allow the rule engine to minimize the number of cases where it must take side effects into consideration and thus improve the overall performance of the rule engine. Editors note: Structured rules (i.e., one set of rules for "wire- speed" path and another set for "slow speed" path) may be an appropriate solution that should be permitted in the requirements? These may be specified in the same language but parsable into their constituent parts. 3.1.4. Rule Processing Points An OPES intermediary rule engine may evaluate messages several times in the course of handling messages flowing through it. These rule processing points are both architecture and implementation defined. These processing points may be identified by administratively-defined names that serve as a selector for policy rules to determine the applicability of a rule or set of rules at the processing point. In the Policy Framework, [3] and [4], policy roles are used to name that relationship between a set of rules and a processing point, thus, in keeping with section 2. "Policy Scope of Control," policy roles SHOULD be used where it aids in the development of the OPES policy model. Figure 2 shows the typical message data flow between a client, an intermediary and an origin server and with four commonly used processing points identified by the numbers 1 through 4. These four commonly used rule processing points, discussed further below, MUST be supported by the rule language, the underlying information model and implementations of the rule engine. Other policy selectors that may be vendor or administratively defined MUST also be supported by the rule language and the underlying information model and SHOULD be supported by implementations of the rule engine. The OPES Admin Server PDP implementations MUST support these commonly used processing points as well as vendor and administratively defined policy selectors. Rafalow, et al. Informational [Page 6] Internet Draft OPES Policy Requirements July 2001 +--------+ +-----------+ +--------+ | |<------|4 3|<------| | | Client | | Inter- | | Origin | | | | mediary | | Server | | |------>|1 2|------>| | +--------+ +-----------+ +--------+ Figure 2 Rule Processing/Service Execution Points 1. User Request handling role Request processing when received from user agent-side; for example, prior to a cache lookup; generally, user-specific processing Example service: URL-based content filtering 2. Intermediary Request handling role Request processing when forwarding to origin server; generally, user-independent processing Example service: Request redirection 3. Origin Server Response handling role Response processing when received from origin server-side; for example, prior to being stored in a cache; generally, user- independent processing Example service: Virus scanning 4. Intermediary Response handling role Response processing when forwarding to user agent; generally, user-specific processing; can occur on messages from origin server or from cached information Example service: Language translation 3.2. Called Services The both the call and the return interface between the policy system and the called OPES services needs to include the ability to pass system state information as well as the subject message. 3.2.1. Service Bindings The called OPES services MUST be able to be specified in a location- independent fashion. That is, the rule authors need not know and need not specify the instance of an OPES service module in rules. Instead, the rule author SHOULD only need to identify the service at the level of specificity at which it is concerned. A Rule Author may want a specific type of service or it may only care that any service that fits a general category of service is applied to its traffic. So, the range of specifications that SHOULD be supported in the rule Rafalow, et al. Informational [Page 7] Internet Draft OPES Policy Requirements July 2001 language goes from the very detailed (i.e., a specific installation, vendor and version of a content adaptation service, e.g., a service provider's installation of a brand and release of a virus scanner) to the very general (i.e., a general class of content adaptation service, e.g., a virus scanner). The binding of this range of OPES service names to specific service modules MAY be distributed between the PDP and the PEP. As rules are compiled and validated by the PDP, they MUST be resolved to a specific installations' set of homogeneous OPES service modules. The selection of a specific instance MAY be postponed and left to PEP to select at either rule installation-time or at run-time. Thus, to achieve interoperability, a PEP MUST support resolving a generic name to a specific instance. An implication of this set of requirements is that the rule language (as expressed on the PDP Interface, i.e., between the rule author and the PDP) MUST NOT require the use a scheme name (e.g., proxylet://...) in a rule specification of an OPES service. A possibility is to use services such as SLP [14] and/or UDDI [15] to resolve generic service names to specific OPES service module instances. Similarly, the policy system MAY support dynamic discovery of service bindings. The specific service bindings (e.g., protocol, parameters) may not be known by the rule author when a rule (as specified on the PDP Interface) is general in nature. The required binding information MUST be provided by the PDP and conveyed on the PEP Interface. A service description methodology (e.g., OMML [12], WSDL [13]) must be present in the policy system; it is to be determined whether an OPES standard is required. 3.2.2. Environment Variables There is a need to define and support a set of local system environment variables to maintain state information that can be used in both condition evaluation and action execution. For example, a certain service may be only executed during the off-peak hours (evenings or weekends). This example shows the need to support variables like system date and time. Another example is to invoke a service remotely only if the local system is experiencing a higher than usual load. This calls for the need to support variable like system load. Similarly, state information such as the available bandwidth for a network connection or the assigned quality of service for a flow might be useful in either a condition evaluation or as information passed to a called OPES service. While many examples would show the need to support different kinds of variables, we have to consciously distinguish a set of commonly required variables and other variables that serve a more limited set of services. Therefore, the rule language, the underlying information Rafalow, et al. Informational [Page 8] Internet Draft OPES Policy Requirements July 2001 model and implementations of the rule engine MUST support the following environment variables: - date and time; - a generally useful load metric for the local execution environment (perhaps just a small set of threshold enumeration values, e.g., "cycle-intensive-ok", "low-cycle-use-ok", "overloaded"); and - generally useful metrics of local link bandwidth and available bandwidth on a per link basis. In addition, however, the rule language and the underlying information model MUST support specifying other environment variables and implementations of the rule engine SHOULD support a general capability to define state variables that can be used by both rule authors and OPES services. Note that, depending on the execution environment, the OPES services may have the freedom to define variables that are needed and use these variables to further define their service behavior without the rule engine's support. Note that some of the environment variables may be numeric and, therefore, require some arithmetic operations. It is possible that comparison operators for "less than" and "greater than" will be required, but the intent is to not require other arithmetic operations. 3.2.3. Preventing Unnecessary Calls Policy rules are relatively static. That is, they are changed based on administrative changes in the system goals. Network state information, however, changes quite frequently. Policy rules may, of course, specify that state information be evaluated as part of the evaluation of the rules against a given message. The policy system SHOULD support the maintenance of groups that can be used in evaluating rule conditions. Membership in such groups, then, can be used as terms in the rule language; called services SHOULD be able to set values in these sets to optimize when the service should and should not be called. However, called services MUST NOT be able to modify group memberships for which they are not explicitly authorized. So, for example, an authorized site-blocking service might conclude that a particular user shouldn't be permitted access to a certain web site. Rather than calling the service for each request sent by such a user, a rule might have the following semantic. If user is a member of blocked-users and requested site is a member of blocked-sites then call a local, "wire-speed" service to return a 403 message. The blocked-users group membership and the blocked-sites group membership can then be maintained by a service that runs in a slower or even remote execution environment. Rafalow, et al. Informational [Page 9] Internet Draft OPES Policy Requirements July 2001 3.2.4. Passing Information Between Services Environment variables can also be used to pass state information between services or invocations of a service. For example, analysis of the request or modifications to the request may need to be captured as state information that can be passed to other services on the request path or to services on the response(s) associated with that request. The solution SHOULD enable setting variables when returning from a service call and passing variables to other called services based on policy. A logical extension of passing state information between services called from a given intermediary might be to pass information between services called from different intermediaries along the content path. Such a function, although useful, is considered out of scope. 4. Rule Management Editors note: This section is still to be written. The following list provides an outline for the materials to be covered in this section. o Rule providers fall into two categories: User (or User agent) and Content Provider (or Content Management agent) o Rule providers must be authenticated and authorized for rules that apply to their network role. Rule providers must not be able to specify rules that are not within their scope of authority. o Rule providers should not need to specify anything that they would not naturally be interested in specifying, e.g., service location. o Compilation of rules from different sources inevitably leads to conflicting rules. The resolution of such conflicts is out of scope, but mechanisms for resolution of such conflicts are in scope including determining the action priority associated with rules. o Rule modules are identifiable groups of rules provided by a rule author (this appears to be a precompilation requirement, i.e., for rules received by an Admin Server but not for rules processed by an OPES Intermediary Rule Engine) o Rule are assumed to be static and applied to current network state. Are there cases that cannot be covered with this policy model? 5. Rules 5.1. Rule Formats and Protocols It is desirable to choose standard technologies like XML to specify the rule language format. The current proposal on rule language, Rafalow, et al. Informational [Page 10] Internet Draft OPES Policy Requirements July 2001 Intermediary Rule Markup Language (IRML), is indeed XML-based and is defined by DTD. It may be necessary to move IRML to XML schema. Like any other XML-based documents, it is possible that there will exist graphical tool to aid the process of rules authoring. However, the nature of XML document also allows rules be authored directly with a text editor, as long as tools exist to validate the correctness of such rule document preferably on the rule authors' platform, or at the very least, on the OPES administrative servers. It is necessary to transmit the IRML document from the rule authors to the OPES administrative server for service authorization, rule validation and compilation. Once it is authorized, validated and compiled at the administrative server, the rules also need to be transmitted down to the OPES intermediary to be effective at run time. Currently there is no proposal on how to transmit the IRML document from the rule authors to the OPES administrative server, or from the administrative server to the OPES intermediary. Can COPS be applicable here? Or do we need to define our own protocol for that? 5.2. Conditions Rule conditions must be matched against attribute values of the encapsulated protocol as well as environment variable values. Attribute values of the encapsulated protocol include protocol header values and possibly also protocol body values. Environment variables MUST be supported for use in conditions; see section 3.2.2 "Environment Variables." Editors note: All matching is assumed thus far, what about first matching? We also need to consider priority. Performance is critical for the matching of rule conditions and attribute values. Therefore, all rule conditions as well as attribute values MUST be treated as string values so that the rule matching can be done by simply comparing the string values of rule condition and attribute value. The string compare should be case insensitive by default, but rule authors SHOULD be able to force a case sensitive string compare if necessary. Rule authors SHOULD also be allowed to use regular expressions in rule conditions. The use of regular expressions enables rule authors to cover a variety of different cases with a single rule condition. Regular expressions are also well known and widely supported in programming languages. While it may also be desirable to add support for some arithmetic operations to the rule system, for instance in order to specify a rule condition that is true for a range of values, the intent is to minimize the required support. Some OPES services may need to be invoked for all user requests or server responses, e.g. services with logging functionality. The rule system SHOULD therefore allow unconditional rules rather than Rafalow, et al. Informational [Page 11] Internet Draft OPES Policy Requirements July 2001 requiring rule authors to specify rule conditions that are always true. 5.3. Actions The rule system must also allow for the specification of rule actions that are triggered if the conditions of a rule are met. Matched rules typically lead to the invocation of local or remote services. Rule actions MUST therefore identify the OPES service that is to be executed for the current message request or response. See 3.2.1 "Service Bindings" for a discussion of the specification of the called OPES services in OPES policy actions. Rule actions may also contain additional run-time parameters which can be used to control the behavior of OPES service modules. If specified, these parameters must be passed to the executed service module. The run-time parameters passed to OPES services do not necessarily have to be pre-defined values. They could also refer to any of the environment variables as described in 3.2.2 "Environment Variables," e.g. system time. The executed OPES services could then dynamically change their behavior according to the values of the passed environment variables. 6. Security Considerations TBD 7. Acknowledgments TBD 8. References [1] Bradner, S., "The Internet Standards Process -- Revision 3," BCP 9, RFC 2026, October 1996 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, RFC 2119, March 1997. [3] Moore, B., et al., "Policy Core Information Model -- Version 1 Specification," RFC 3060, February 2001. [4] Westerinen, A., et al. "Policy Terminology," Work in Progress Internet Draft, draft-ietf-policy-terminology-03.txt, April 2001 [5] Fielding, R., et al., "Hypertext Transfer Protocol -- HTTP/1.1," RFC2616, June 1999 [6] Carpenter, B., et al., "Middleboxes: taxonomy and issues," Work in Progress Internet Draft, draft-carpenter-midtax-01.txt, April 2001 [7] Erickson, R., et al., "OPES Network Taxonomy," Work in Progress Internet Draft, draft-erickson-opes-taxonomy-00.txt, February 2001 [8] Tomlinson, G., et al., "A Model for Open Pluggable Edge Services," Work in Progress Internet Draft: draft-tomlinson- opes-model-00.txt, July 2001. Rafalow, et al. Informational [Page 12] Internet Draft OPES Policy Requirements July 2001 [9] Beck, A., et al., "Example Services for Network Edge Proxies," Work in Progress Internet Draft, draft-beck-opes-esfnep-01.txt, November 2000 [10] Yang, G., et al., "OPES Architecture for Rule Processing and Service Execution," Work in Progress Internet Draft, draft-yang- opes-rule-processing-service-execution-00.txt, February 2001 [11] Beck, A., et al., "IRML: A Rule Specification Language for Intermediary Services," Work in Progress Internet Draft, draft- beck-opes-irml-00.txt, February 2001 [12] Maciocco, C., et al., "OMML: OPES Meta-data Markup Language," Work in Progress Internet Draft, draft-maciocco-opes-omml- 00.txt, March 2000 [13] Christensen, E., et al., "Web Services Description Language," Work in Progress W3C Draft, http://www.w3.org/TR/wsdl, March 2001 [14] Guttman, E., et al., "Service Location Protocol, Version 2," RFC 2608, June 1999 [15] McKee, B, et al., "UDDI Version 2 API Specification," Work in Progress, http://www.uddi.org/pubs/ProgrammersAPI-V2.00-Open- 20010608.pdf, June 2001 9. Authors' Addresses Lee M. Rafalow IBM Corporation, BRQA/502 4205 S. Miami Blvd. Research Triangle Park, NC 27709 USA Phone: +1 919 254-4455 Fax: +1 919 254-6243 Email: rafalow@raleigh.ibm.com Lily Y. Yang Intel Corporation, JF3-206 2111 N.E. 25th Avenue Hillsboro, OR 97124-5961 USA Phone: +1 503 264-8813 Email: lily.l.yang@intel.com Andre Beck Bell Labs Research Lucent Technologies 101 Crawfords Corner Rd. Holmdel, NJ 07733 USA Phone: +1 317 322-6069 Email: abeck@bell-labs.com 10. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. Rafalow, et al. Informational [Page 13] Internet Draft OPES Policy Requirements July 2001 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. Rafalow, et al. Informational [Page 14]