Internet Engineering Task Force Authors INTERNET DRAFT R. Rajan AT&T S. Kamat IBM 23/ May/ 1999 A Simple Framework and Architecture for Networking Policy draft-rajan-policy-framework-00.txt Status of Memo This document is an Internet-Draft and is in full conformance with all the provisions of Section 10 of RFC2026 except for the right to produce derivative works. 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 Discussion of this draft will be carried on the policy mailing list (policy@raleigh.ibm.com). Suggestions for improvement may also be sent to rajan@research.att.com. Distribution of this memo is unlimited. Abstract Many new protocols defined in the IETF have a regulatory component, i.e., network administrators have to decide what users, applications or hosts should have access to what resources/services under what conditions. Large-scale deployment of services using such protocols is critically rajan, kamat Expires 23/ November/ 1999 [Page i] Internet Draft draft-rajan-policy-framework-00 23/ May/ 1999 dependent on the presence of a network-wide policy infrastructure that allows Internet Service Providers (ISPs) and corporate administrators to regulate the network rather than configure individual devices. A key component of this effort is to evolve standards-based means of representing and storing policy information in a unified manner, with a focus on schema for storing policy information in directories. This document presents concepts, terminology, a policy framework and requirements for such a definition. rajan, kamat Expires 23/ November/ 1999 [Page ii] Internet Draft draft-rajan-policy-framework-00 23/ May/ 1999 1. Introduction Given the wide and varied usage of the term "policy", it is imperative that the word be clearly defined in the networking context. As a starting point, we shall use policy to denote the unified regulation of access to network resources based on administrative criteria. Policy is driven by the need to create multiple services over a shared IP infrastructure melding together different protocols. A complementary perspective on policy is to think of it in terms of (relatively) static performance goals or operational rules for a dynamic network environment supporting a variety of services. A policy infrastructure is the collection of information models, protocols and mechanisms through which the intentions of administrators can be represented, stored, communicated and translated into operations carried out at various network elements that encounter packet streams. In order to motivate the domain of policy as defined in this document, consider the following examples: (1) An ISP operator wishes to offer an ``extranet'' service to interconnect some company's campuses spread across the United States. Such a service includes assurances of traffic isolation, privacy, as well as bandwidth availability for traffic carried across the extranet. Such a service is pieced together from a variety of different protocols and components, e.g., network address translation to ensure connectivity, firewalls to ensure campus isolation, IPSec for encryption and authentication, MPLS for QoS provisioning across the backbone, etc. The regulatory components of such a service, to be provided by a policy infrastructure, include regulation of address translation to ensure connectivity, policies to prevent security violations at the firewall, and policies to automatically encrypt data from confidential servers across the extranet. (2) In addition to the above ``extranet'' service, the operator wishes to offer 4 different QoS services, priced differently. The ISP allows customers to indicate their service preference on a packet-by-packet basis by setting DS codepoint in IP header appropriately. The added regulatory component of such a service is traffic volume verification through policing at network access points. (3) A reputed telecommunications company wishes to offer unified voice and data services over cable modems. The billing and processing requirements for voice are different from data. The regulatory components of such a service include bandwidth management, prioritization of voice traffic, account verification and call routing. rajan, kamat Expires 23/ November/ 1999 [Page iii] Internet Draft draft-rajan-policy-framework-00 23/ May/ 1999 (4) An administrator of an RSVP-capable intranet wishes to restrict individual Controlled Load reservations from engineering staff during the day (9am to 5pm) to a certain token rate and also limit the total bandwidth of such reserved flows. (5) A network operator interfaces with another network operator at a peering point to support communication within their network. Network operator A supports 4 service levels within network A, while network operator B only supports two service levels. Network operator B maps the first two service levels of A to one type of its own service levels, and the remaining two into its second type of service level. The policy component of such a service is to configure and enforce the mapping between the service categories and enforce traffic contracts. It is clear from the above examples that policy, i.e., the regulatory aspect of service provision, is very wide in scope. Obviously, the entire policy infrastructure cannot be unified and standardized all at once. Instead, standardization efforts must be aimed at protocols and representations that allow devices potentially belonging to multiple vendors to interoperate by distributing, sharing and interpreting policy information in a consistent manner. Further, while some mechanisms for regulation of services are best provided within protocols themselves, it is very unsatisfactory to completely isolate policy definition for different protocols from one another, for several reasons. - Different services may benefit by using common policy transport mechanisms and semantics. - Policies regarding different services are defined using common categories such as users, applications, hosts, etc. Administering these separately for each service could be time consuming and messy. - Policies for different protocols may have interaction effects. For instance, network resources are wasted if a QoS policy reserves bandwidth for a flow that another security policy forbids. - ISPs and corporate administrators would prefer to define new hybrid services, such as combining network access with other security and QoS features. These higher level services need to be administered in a uniform manner, which would be best done given a common policy infrastructure. However, given the diverse needs of different environments and the heterogeneity of information availability and functionality in rajan, kamat Expires 23/ November/ 1999 [Page iv] Internet Draft draft-rajan-policy-framework-00 23/ May/ 1999 network devices, the evolution of a single ubiquitous policy solution is very ambitious. Instead, we take a gradual approach which is aimed at well defined policy needs at first, working out to a more ambitious framework as newer policy requirements emerge. Our first aims are: - 1. Derive a common terminology and conceptual framework for policy-based network control, with a few carefully selected services and protocols as the first targets. - 2. Develop an appreciation for the policy needs of current services, with an emphasis on QoS and security services. - 3. Distill from these a simple, common architecture that illuminates our workspace, - 4. Present an overview of existing and proposed "pieces of the puzzle" that may be usefully employed to implement the architecture. - 5. Show that the architecture assumed does not restrict the solution space by outlining different feasible enhancements and extensions. - 6. Obtain requirements for and constraints on a common policy representation that may be stored in a directory ("directory schema") with a focus on Quality of Service. - 7. Define an associated policy information base (PIB) and management information base (MIB) that could be usefully employed in controlling and managing heterogenous devices. A key motive for this effort is the drive to evolve standards-based means of representing information ("schema") in a unified manner, and storing such information in LDAP-accessible directories [6]. This document presents concepts, terminology, a policy framework and requirements for such a definition. 2. Requirements 2.1. Policy Requirements for QoS In order to obtain some insight into the semantics of policy rules required for QoS and other services, we present an over-view of the policy needs of integrated and differentiated services. rajan, kamat Expires 23/ November/ 1999 [Page v] Internet Draft draft-rajan-policy-framework-00 23/ May/ 1999 Integrated services with RSVP signaling approach seeks to provide per-flow QoS assurances with dynamic resource reservation. A flow is defined by the 5-tuple (source address, destination address, protocol, source port, destination port). RSVP is a protocol for reserving network resources for unicast or multicast flows, with stringent requirements satisfied by a guaranteed service, and more flexible requirements by a relaxed controlled load service. In this context, there is need to provide policy control of individual flows, and regulate their ability to reserve network resources. RSVP is capable of opaquely transporting policy-objects which may be used by policy-aware nodes to derive more information about the user, application or end-points of communication. The role of policy allows for highly granulated interactions with billing, accounting or accreditation systems resulting in informed control over the size and nature of the QoS reservations in the network. (See [8] for a discussion of policy based admission control framework and sample policies). Differentiated services (DiffServ), on the other hand, are aimed at traffic aggregates that may not correspond to fine-grained flows. The frequency of signaling is much coarser, and may occur through a variety of mechanisms (bandwidth brokers, off-line communication, service level agreements, etc.). The DiffServ approach relies more on administrative control of bandwidth, delay or dropping preferences, rather than per-flow signaling protocols to communicate service level information to network elements. For such services we wish to enable flexible definition of class-based packet handling behaviors and class-based policy control. See [7] for a discussion of DiffServ framework and sample behavior/service descriptions). While these mechanisms address the issue of how to provide quality of service, the complementary issue of which packets are eligible for what services is a policy issue. For instance, an e-tailer may wish to provide preferential treatment to real-time transaction oriented web-traffic. Or an ISP may seek to ensure that voice-over-IP is assigned to a low-loss, low-delay class of service, while limiting the number of simultaneously supported voice calls. Or consider a network administrator of an RSVP capable intranet who wishes to restrict individual Controlled Load reservations from certain sources during the day to a certain token rate and also limit the total bandwidth of such reserved flows. In these and other examples, the utility of QoS services depends heavily on the presence of mechanisms for administering them. In fact, large-scale deployment of QoS services is critically dependent on the presence of a network-wide policy infrastructure that allows Internet Service Providers (ISPs) and corporate administrators to control the network rather than configure individual devices. rajan, kamat Expires 23/ November/ 1999 [Page vi] Internet Draft draft-rajan-policy-framework-00 23/ May/ 1999 Speaking broadly, the policy needs of QoS administrators are of three kinds. First, administrators would like to be able to provision networks, i.e., earmark resources for use by certain types of traffic. Second, they would like to control the terms and conditions under which users are able to reserve bandwidth in the network. Third, they would like to substitute one QoS service for another; for instance, require that integrated service categories be provided using comparable differentiated service categories. More elaborately the policy needs for QoS are as follows: Integrated services using RSVP: RSVP has been devised to explicitly carry and process policy objects together with reservation requests and responses. In its simplest form, policy may be used to control the number, size and the nature of RSVP reservation requests depending on the information in the header of RSVP Path and Resv messages, or the TSpec and RSpec parameters. This use of policy in such an environment allows enterprises to be able to police QoS requests on a per- flow, per-user or per-application basis. However, a number of interesting and important forms of policy may only be expressed using policy objects carried with RSVP signaling messages These include objects that identify and authenticate users, applications or hosts, define the relative (reservation) priorities, carry accounting and charging information, etc. Proxy RSVP: This refers to the use of policy to control the establishment of RSVP tunnels between routers or other intermediate devices within the network, and the use of these QoS tunnels by traffic flowing through these intermediate devices. There are three common proxy instances: RSVP tunnels for best effort traffic, RSVP aggregation, i.e., combining multiple RSVP tunnels into one, and Other QoS protocol to RSVP translation. Differentiated services secured through provisioning: This includes the case of using policy to specify and control DiffServ within a domain, and, in an inter-domain scenario, control bilateral agreements across peer network boundaries. In such cases, policies are used to map across the two domain specific semantics, and enforce access control restrictions, such as ensuring that the amount of in-profile traffic is within the specified contractual limits. Multiple QoS Protocols Tunneling through DiffServ: RSVP or other QoS protocols may be used within a domain, being mapped onto differentiated services across domains. In such cases, policies are needed at the domain boundary to translate between signaled and differentiated service semantics, to enforce traffic monitoring and to exercise access control over network resources. rajan, kamat Expires 23/ November/ 1999 [Page vii] Internet Draft draft-rajan-policy-framework-00 23/ May/ 1999 2.1.1. Policy Requirements for Security IPSec [14] is a suite of protocols standardized for the purpose of ensuring secrecy and trust across the public internet. It is a complex protocol requiring participating hosts to negotiate a number of configuration parameters. The main issues that arise in IPSec regulation are outlined below: 1. End-to-End security configuration: In the interests of corporate policy, enhanced security requirements or ease of operation, administrators may wish to override protocol configuration defaults specified in IPSec documents, using alternative parameters or algorithms. There is a host of parameters including ISAKMP/Oakley exchange mode, authentication method, perfect forward secrecy requirement, hashing, authentication and encryption algorithms for the two phases of IPSec, timeouts, etc. Administrators must be able to configure the nature of security based on users, end-hosts, servers being accessed, time of day, path of communication, etc., as part of IPSec policy. 2. Gateway access: Often, multiple security gateways have to be traversed for two end hosts to communicate. Depending on the end host application, a gateway may either deny or permit the connection or require an IPSec tunnel from either the end host or another gateway acting as a IPSec proxy for the end host. Access through the use of gateways must be supported through policy. 3. Intranet access: Firewalls and security gateways are required to selectively admit inbound traffic based on the communication users, hosts, applications, the presence of authentication tickets (certificates), etc. 4. Proxy IPSec: In some cases, end-to-end IPSec may be deemed too burdensome, and administrators may configure firewalls to dispatch specified traffic within secure tunnels across the Internet. In this case, the policy language must be rich enough to allow for the classification of traffic based on end-users, hosts, communication path, time of day, etc. In addition to policy requirements of IPSec, there are other protocols that have regulatory components. We wish to ensure that policy representation is compatible with the needs of: - IP Filtering: Schema should be able to describe simple IP filters that may be used to configure access devices. rajan, kamat Expires 23/ November/ 1999 [Page viii] Internet Draft draft-rajan-policy-framework-00 23/ May/ 1999 - IP Address Space Management: Address assignment and translation services provided by DHCP and NAT could also be regulated through policy. - Network Access Control: Certain users and applications may not access intranets or certain servers/hosts. Their access must be proscribed through policy. 3. Policy : Terminology and Conceptual Framework So far, we have seen the policy needs of QoS and security protocols. In this section, we develop some basic terms and concepts that will allow a shared understanding of the requirements for a policy infrastructure. 3.1. Conceptual Hierarchy At the risk of simplifying several intricate features of policy, we present a conceptual model that describes different levels of abstraction at which regulation may be expressed and exercised. Network Level View This is a high-level perspective that incorporates topology, connectivity, end-to- end performance objectives, expressed in terms of static and dynamic resources in the network. The human administrator interacts with the network usually through a human friendly language or intuitive representation such as a GUI. Such a representation may also contain aspects of network monitoring, where the current state of the network is represented so that the administrator may ascertain the extent to which policy is enforced in the network. As an instance of a network level view, an administrator may require that all http traffic from server A to managers in campus B be transmitted through a gold- QoS, high-security tunnel with a 2 MBps reservation. The definition of "gold-QoS" and "high-security" may be deterministic or probabilistic, but we assume that these are fairly well defined in-context, and not vague and fuzzy. Note that the network level view is integrally tied to the services being administered. For instance, the network view presented by a tool used for administering remote access to a corporate campus would be very different from another used to dynamically modify peering agreements between two large ISPs. Consequently, the network view cannot be standardized, and we must look towards a slightly lower level of the hierarchy where standardization efforts may be directed. rajan, kamat Expires 23/ November/ 1999 [Page ix] Internet Draft draft-rajan-policy-framework-00 23/ May/ 1999 Role or Group Level View A network level policy injunction requires different behaviors at various network nodes depending on their roles within the network. For instance, with respect to the above example, all firewalls and access routers in campus B have a similar role to play. They must be instructed to permit encrypted traffic from server A into campus B. Thus, the network view may be resolved into distinct role or policy group level views, which correspond to the policy objectives and requirements at like network nodes or interfaces. A particular network element may play several roles, and several such elements may play the same role. Each network element is controlled by the policies corresponding to all the roles that it plays. The role level policy view is resolvable into a collection of atomic injunctions called policy rules. Each policy rule corresponds to a statement of the form If (PolicyRuleCondition) then (Action) where (PolicyRuleCondition) is expressed in terms of administrative categories such as users, hosts, applications, etc., and (Action) identifies the associated privileges or deserved treatment. A simple policy rule for a firewall in campus B that would allow all IPSec packets from server A would have the condition "Host: Server A; Protocol: IPSec" associated with the action "ALLOW". Device-specific or Configuration Level View Each network node has vendor-specific resource allocation mechanisms and packet forwarding paths, and role level rules need to be ultimately translated into device-specific instructions. One aspect of a device specific view is the maintenance of caches, filters or classifiers to be placed in the datapath to identify the treatment associated with individual packets. A second aspect is the reservation of resources and the delivery policy mandated services. For instance, to ensure that http traffic from server A is assured of bandwidth, it may be necessary to insert a classifier in an access router, and set the WFQ weights appropriately. It must be clear that device architectures, capabilities and configuration vary highly from vendor to vendor, and that there cannot be a common language for representing or unifying such configuration. 3.2. Policy Standardization In order to evolve a schema, it is necessary to identify the level at which policy is to be standardized. The network level view rajan, kamat Expires 23/ November/ 1999 [Page x] Internet Draft draft-rajan-policy-framework-00 23/ May/ 1999 of policy is intimately tied with the to the remaining network management infrastructure, and it is unclear what would constitute an intuitive and yet flexible object model. Further, it involves an implicit knowledge of topology, and it is difficult to automate the translation of such a view to the device level. Consequently, the network level view is best left to different network management vendors to design and customize. At the other extreme, the device level view is too vendor-specific and scales poorly to large networks. In the rest of this document, we assume that role level views are sought to be standardized in schema, and that these are composed of "policy rules". Given that standardization effort in policy should address policy definitions at the Role level, the next issue is to decide on a language framework to define policies. There are several design considerations and trade-offs to make in this respect. 1. On one hand, we would like a policy definition language to be reasonably human-friendly for ease of definitions and diagnostics. On the other hand, given the diversity of devices (in terms of their processing capabilities) which could act as policy decision points, we would like to keep the language somewhat machine-friendly, i.e., relatively simple to automate the parsing and processing in network elements. 2. An important decision to make is the semantic style of the language, e.g., procedural or declarative. - The procedural approach would model network behavior that is to be regulated through policy in terms of states and pertinent events. In this model, policy directives are statements that control the state transitions and thereby regulate the network behavior. An example of state is installing or removal of packet classification filters and the appropriate configuration actions for traffic conditioning. Examples of events include device boot-up, packet arrival, etc. - The declarative approach would simply describe the desired network behavior in terms of certain actions that should happen when specific conditions hold. For example, a policy directive that states that packets matching a specific traffic profile must be conditioned in a certain way is formulated in terms of conditions that describe the traffic profile and actions that describe the traffic conditioning behavior. A policy rule in this approach is written as if (policy condition) then rajan, kamat Expires 23/ November/ 1999 [Page xi] Internet Draft draft-rajan-policy-framework-00 23/ May/ 1999 The declarative approach has the benefit of simplicity, and facilitates hiding implementation differences, making it a suitable candidate for the policy definition language standard. 3. It is important to control the complexity of the language specification trading off richness in terms of features for ease of implementation. It is important to acknowledge the collective lack of experience in the field of networking policies and hence avoid the temptation of aiming for "completeness". We should strive to facilitate definition of the common policies that customers require today (e.g. VPN, QoS) and allow migration paths towards supporting complex policies as customer needs and our understanding of networking policies evolves with experience. Specifically, in the context of the declarative style language discussed above, it is important to avoid having full blown predicate calculus as the language as it would render many important problems such as consistency checking and policy decision point algorithms intractable. It is useful to consider a reasonably constrained language from these perspectives. 3.2.1. Policy Categories Starting with the broad aim that administrators require mechanisms to control access to QoS resources, we are drawn to describe the specific bases or criteria for discrimination in QoS networks. These would include: 1. The end-points of communication: The source and destination IP addresses may be directly obtained from the IP packet, as long as no intermediate proxies that encapsulate packets are involved. Other information, such as source/destination MAC addresses or other layer 2 end-point information may be used to regulate communication. 2. The route or path of communication: The treatment of packets and the availability of reservable resources depend on the route along which the data packets flow. For instance, packets flowing over a dedicated line may require no particular reservation, while the same packets routed over a backup public network would need special treatment. Simplistic routing-based policies may be described based on the incoming or outgoing interfaces of devices at which the policy is enforced. 3. Communicating users or groups: The identity and organizational status of people involved in communication plays a large role in determining their access to network resources. Rich and versatile policy solutions are made possible by the availability of this rajan, kamat Expires 23/ November/ 1999 [Page xii] Internet Draft draft-rajan-policy-framework-00 23/ May/ 1999 information is available within the network, for instance, using signaling protocols such as RSVP. 4. Application information: The characteristics of the particular application generating traffic, whether it has real-time requirements, for instance, will determine the quality and nature of resources allocated to the traffic. While some such information may be deduced from the port and protocol numbers in IP packets, a more comprehensive solution that does not involve laborious content inspection and state maintenance is possible only if the traffic generating host is involved in signaling application requirements. 5. Dynamic Network Characteristics: It is often useful to take the availability of resources in the network, or their scarcity, into account while allowing or denying the use of resources by a particular flow or group of flows. 6. Accounting information: The ability to base resource access decisions on the availability of credits or tokens is seen as an important application of policy. 3.3. Processing Policy Rules --------------------- Network Level --------------------- | | | Vendor/Service specific mapping | | --------------------- Role Level If (Policy Category based) Condition then Action --------------------- | | | Mapping by policy decision point | | ---------------------------- Device Configuration Level ---------------------------- Figure 1: Hierarchy of Abstractions rajan, kamat Expires 23/ November/ 1999 [Page xiii] Internet Draft draft-rajan-policy-framework-00 23/ May/ 1999 If we conceptualize policy control in terms of an infrastructure designed to translate administrative intentions into transformations effected on packet streams, then its complexity arises from the need for mechanisms that gather spatially dispersed, dynamic network information and process them to make policy decisions. Consider a policy that allows traffic from certain users to be granted preferential QoS treatment. The complexity of implementing such a policy depends on a variety of factors. On a policy capable end-host, it may be relatively easy to map the login id of the user to their name, and based on a table lookup, mark packets with the ToS pattern that connotes preferential service in the rest of the provisioned network. In the fortuitous case that users are tied to their workstations, network nodes may access a table that maps users to host addresses, and then use source or destination addresses in packet headers to grant preferential QoS treatment. Or a QoS protocol such as RSVP may be used to carry user information as policy objects, used to deny or grant bandwidth requests. Or, in the case of users dialing up from home, user information may be obtained from a protocol such as Radius, and then used by the access router to mark ToS bits of the packet stream. In any event, policies are expressed in terms of categories such as users, hosts, applications, account balances, etc. Network elements that handle packets need to (a) associate the information in the packet header with the policy category, (b) evaluate the policy conditions to see if they hold, and (c) carry out appropriate operations on the packet. 3.3.1. Associating policy categories with packet information The mapping of policy categories to header information present in data packets may be static or dynamic; and may be made in a variety of different ways. - If policy categories are identical to, or can be immediately deduced from data packets, the mapping of high level policy to enforcement is direct and static. An simple example of this is when policy is expressed in terms of source IP addresses. Direct mechanisms do not require state. - Sometimes, is suffices to refer to lookup tables for resolving policy categories into packet header based conditions. The example is when users are tied to host addresses, but for administrative convenience policies are expressed in terms of users than host addresses. In this case the mapping is static, but indirect. - Policy categories may be obtained in context, through state that has been established in the operational environment. This rajan, kamat Expires 23/ November/ 1999 [Page xiv] Internet Draft draft-rajan-policy-framework-00 23/ May/ 1999 is a very important case, as with user names or application information that can be obtained directly at an end host. - The mapping between policy categories and header fields may be dynamic, in which case intermediary packets are used to communicate mapping information. For instance, policy category information may be transmitted by signaling protocols, and used to control the associated data stream. One example is the use of RSVP policy objects to ascertain the identity of a dial-up user in order to accept or deny a reservation. Note that this identity may now be used to put the data stream in a secure (proxy) IPSec tunnel. This latter use of information presented through one protocol to deliver a different service (cross-service policy function) considerably expands the utility of policy. Another instance of the use of intermediaries is when dynamic port number information (say for FTP data) is obtained by examining the content of signaling packets. - In addition to obtaining information directly and through intermediary packets, a network device may contact a centralized network location to obtain information on the policy category a particular flow belongs to. An example of such indirect methods is when IP address to FQDN information is obtained from a DHCP server, triggered perhaps by an unfamiliar packet stream in an access router 3.3.2. Evaluating the Policy Condition Once the policy categories associated with a packet or packet stream have been ascertained, any policy condition involving those categories must be evaluated. Typically, conditions involve checking set membership -- does "John Doe" belong to the group "Pseudonym-users", or is a certain account balance positive. Now, this stage of policy processing is relatively straightforward if the condition or relation being evaluated changes slowly or never. User and host groups are good examples of such stable policy conditions. However, certain other policy categories, such as account balances, are volatile and it is customary to use specialized servers and protocols to track their state. So the evaluation of the condition is outsourced or specialized information solicited from an external entity. An extreme example of spatially dispersed, volatile information is the evaluation of conditions based on network congestion. (Such a condition would, however, need precise semantics -- where is this state measured and how -- to be meaningfully implemented.) In this case, information regarding packet losses, queue lengths or delays must be solicited from multiple network elements and combined in order to evaluate the policy condition. rajan, kamat Expires 23/ November/ 1999 [Page xv] Internet Draft draft-rajan-policy-framework-00 23/ May/ 1999 3.3.3. Executing Policy Actions There is tremendous diversity of capabilities and execution environments across network devices, and the ambitious goal of controlling them through a policy infrastructure has to strike the right tradeoff among design objectives. On one hand, it is important for policy actions to be clearly specified directives that different machines would interpret and execute in a comparable manner, i.e., policy must be implementable uniformly across the network. On the other hand, policy cannot be specified at the machine instruction or configuration levels, even though this would make for precise control. One reasonable compromise is to suggest that policy should control standard protocols and behaviors; and not be used to define new protocols. This does not preclude the use of policy as a glue to define new services by configuring and combining existing mechanisms, but it does move away from defining state machines of arbitrary complexity. In short, policy actions should parameterize existing protocols or behaviors. 4. A Simple Policy Architecture Considering the great heterogeneity of large networks -- varying device processing and storage capabilities, the differential availability of information regarding policy categories, as well as different policy requirements, control mechanisms and network protocols -- it is improbable that an entire policy infrastructure can be based on one single design. In keeping with the more restricted aim of this framework document of unifying policy representation, we first address architectural requirements for the creation, storage and communication of policy rules. The administrator must be able to view and express requirements at the network level. At a minimum this requires a management tool that is capable of creating policy rules and storing them in the common format. The policy repository is at the core of the architecture for unified policy representation. It acts as the memory of the network, and stores policy rules for easy retrieval. As policy rules are expressed in terms of relatively static categories, and the frequency of information retrieval is expected to far exceed update frequency, a directory is well suited to be a repository. The policy enforcement function (PEF) is the functional entity in the data path that delivers network resources to packets. For example, in terms of QoS services, the enforcement function may perform policing, buffer management scheduling, etc. The PEP queries the rajan, kamat Expires 23/ November/ 1999 [Page xvi] Internet Draft draft-rajan-policy-framework-00 23/ May/ 1999 policy decision function (PDF) regarding specific actions that are to be applied in conditioning the packet stream. Thus, the PDP performs the key functions of mapping policy categories to information in data packet headers, and of determining which policy rules after evaluating the conditions. Note that the PDP is entity that brings together static rules and dynamic information required for their enforcement. o o | ------------ | / \ / \ Administrator Administrative Function ----- ----- | | | | | * | | * | ----- ----- Management tool Management Function - - --- --- ----- ----- ------- ------- Policy Repository Policy Storage Function ??? ??? ??? ??? ??? ??? Policy Decision Point (PDP) Policy Decision Function ----- ----- |&*&| |&*&| | * | | * | ----- ----- Policy Enforcement Point (PEP) Policy Enforcement Function Figure 2 Policy Functional Model 4.1. The Role of Existing or Proposed Standard Protocols As shown in the above figure, each of the functions described above may be implemented in a distributed or even replicated manner. rajan, kamat Expires 23/ November/ 1999 [Page xvii] Internet Draft draft-rajan-policy-framework-00 23/ May/ 1999 The management function may be spread across multiple management tools, or several tools may simultaneously be used to populate the repository. Likewise, the policy repository may be replicated or distributed across several directories. In many cases, the policy decision function may be substantially located at a specialized policy server that communicates with multiple network devices at which policy enforcement occurs. The policy decision function may also be split across several policy decision points which collaborate in making decisions. If multiple functions are not co-located, or if the same function is distributed across multiple devices, it is necessary to define standardized protocols for communication between different boxes. There are a number of existing and proposed protocols and mechanisms that may be usefully employed to realize the above architecture, which we discuss in this section. In the next section we discuss enhancements to the basic model to provide enhanced functionality. Directories make good policy repositories, and are commonly accessed using LDAP, a lightweight protocol used extensively to communicate information about users, hosts and applications. Traditional databases, using a language such as SQL provide greater functionality in the repository, at the cost of being more heavyweight. While there are many choices of protocols for directory/database access from the management tool and PDF, LDAP appears to be favored by a number of vendors and users for its ubiquity, versatility and flexibility. LDAP schemas are versatile and allow considerable flexibility in choice of back-end directory management. Further, the LDAP client-server protocol is widely implemented and used for supporting a wide range of directory enabled applications. However, there are a number of shortcomings of LDAP that must be clearly understood by implementers. (Para on shortcomings of LDAP to be added -- asynchronous notification, replication support, security, referential integrity, support for "templates", limitations of query language.) The RAP working group has recently moved to standardize the COPS [5] protocol for outsourcing RSVP decision making from a PEF to PDF. This protocol is modular and may be extended for other policy outsourcing requirements. More recently, the Diameter protocol has been proposed for outsourcing authentication and security decision making. Extensions have been proposed to enhance Diameter to handle QoS outsourcing as well. Another outsourcing protocol that is currently proposed is the Security Policy Protocol in the IPsec WG. SNMP is likely to continue as an integral component of the network management infrastructure. It can play many roles in implementing the above policy architecture. SNMP can be used at the PDF and PEF to record errors, policy usage and notify administrators of unusual rajan, kamat Expires 23/ November/ 1999 [Page xviii] Internet Draft draft-rajan-policy-framework-00 23/ May/ 1999 occurrences within the network. It may be used by the management tool to notify the PDF of a policy update (as such an asynchronous notification feature is not yet available with LDAP). A number of other protocols such as telnet or SSH with CLI (Command Line Interface) and TFTP (could be combined with IPsec) are complementary to SNMP or COPS. 4.2. Enhanced Functionality The basic functions described above may be extended by vendors seeking to enhance flexibility, ease of use, scalability or security. In this regard, there are multiple logical functions at which the same enhancement may be usefully provided. For instance, it is conceivable that some form of "sanity checking" for policy rules is part of each of the above pieces. The "correct" placement of extended functionality depends on access to information. For instance, if there are multiple administrators in a network, but one physical directory server, then the repository function is perhaps best enhanced to handle network level sanity checking. Below, we describe some obvious enhancements to each of the functions, with the caveat that the list is neither necessary nor exhaustive. Apart from being a simple input device for policy definition, management tools can use intuitive user interfaces to bring together network topology, connectivity and performance, with a language for expressing policy categories and goals. In this case, management tools function as translators of the network level view into a role level view. Such translation ensures that policy is uniform across the network, and reduces the need for expensive uniformity checks. (As an example for the need for uniformity, consider two firewalls in peer campuses that cannot communicate, being configured to use different IPSec encryption methods for the same traffic.) Further, management tools can perform several sanity checks on rules. They ensure that policy objects are syntactically correct, that objects referred to in policy definition exist, that policies are uniform across the network, and that multiple rules defined for each role are consistent. To the extent that the management tool has access to network device functionality and resource availability information, these may be included in consistency checking. Policy repositories vary in their ability to be reliable, secure and distributed. They support query languages of differing complexity. Repositories enhanced to provide native support for policy categories would be natural locations to optimize a variety of policy consistency and sanity checks. rajan, kamat Expires 23/ November/ 1999 [Page xix] Internet Draft draft-rajan-policy-framework-00 23/ May/ 1999 The policy decision function is the merging and processing point for static and dynamic information. A variety of protocols different information exchange protocols may be supported here, especially those for gathering volatile data required for decision making. PDPs may talk to different servers and devices in the network, or even to other PDPs, in order to collect billing and accounting information, group membership, addressing and routing information, as well as resource availability and usage. In addition, a PDF may be aware of the resources and capabilities of the PEPs it is connected to, and hence able to flag policy rules that cannot be applied because of device conditions. Some of the shortcomings of existing mechanisms, such as the lack of asynchronous notification in LDAP, may be addressed by defining specialized protocols between functional entities. 5. Policy Representation Requirements The directory provides a convenient repository of the resource regulation policies, which may be accessed by a number of different policy decision points. The following considerations must guide the evolution of standardized means of representing policy (see [1] for instance,) also known as policy schema: - The schema must be defined at the role or policy group level view, and not at the network level nor at the level of device configuration. - It is assumed that the policy repository will not store volatile information required for policy decision making. Hence, the schema must be devised to express administrative intent in terms of relatively static categories. The policy decision point will map policy categories to identify packet streams that need to be regulated. - The schema definition should be generic enough to support a wide range of resource control environments. - Policy schema must be used to configure and control standardized protocols and services, and not as a low-level programming language for networking devices. These schema must support the needs of QoS and security as discussed earlier in this document. - The schema shall be designed to be extensible to the needs of other network services. - From this perspective, it is desirable that the schema facilitates definition of a wide range of policies varying in rajan, kamat Expires 23/ November/ 1999 [Page xx] Internet Draft draft-rajan-policy-framework-00 23/ May/ 1999 their complexity. Simple policies (the common case) should be easy to specify, and there should be sufficient hooks to define sophisticated policies within the schema. Using the language analogy, an administrator's ability to define complex resource regulation policies should not be limited by the structure of the schema, although it may be limited by the available implementation of the policy enforcement environment. - The schema should facilitate simple addition and deletion of new rules, automated checks for rule ambiguities, and allow for diverse methods (varying in efficiency and ease of implementation) to be employed in the policy decision entity to search through rules. - While compactness of representation is of concern, it is subordinate to the needs of expressiveness and extensibility listed above. 6. Security Considerations There are two potential security considerations, both of which may be addressed through standards compliant mechanisms. The first is the unauthorized access to read or change policy rules and related objects in the directory repository. The schema in this document SHOULD be used in conjunction with an LDAP access control mechanisms, see for instance [12]. The second exposure for violation of security lies in the communication between policy decision point and the directory repository. Such communication SHOULD be secured, with both ends mutually authenticated using SSL/TLS or IPSec. Acknowledgments Thanks to Partha Bhattacharya and Skip Booth for useful discussion and suggestions in this problem space. We also thank many others who have read and commented on this draft in various forms. References [1] J. Strassner and E. Ellesson, Policy Framework Core Information Model", draft-ietf-policy-core-schema-01.txt, February 1999. [2] D. Piper, ``The Internet IP Security Domain Of Interpretation for ISAKMP'', draft-ietf-ipsec-doi-07 rajan, kamat Expires 23/ November/ 1999 [Page xxi] Internet Draft draft-rajan-policy-framework-00 23/ May/ 1999 [3] Bhattacharya, P., and R. Adams, W. Dixon, R. Pereira, R. Rajan, "An LDAP Schema for Configuration and Administration of IPSec based Virtual Private Networks (VPNs)", Internet-Draft work in progress, October 1998 [4] R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin, Resource ReSerVation Protocol (RSVP) Version 1 Functional Specification. RFC2205, Sept. 1997. [5] S. Herzog, A. Sastry, R. Rajan, R. Cohen, J. Boyle, and D. Durham, The COPS (Common Open Policy Service) Protocol Internet-Draft, draft-ietf-rap-cops-00.txt, Jan. 1998. [6] W. Yeong, T. Howes and S. Kille, Lightweight Directory Access Protocol, RFC1777, Mar. 1995. [7] K. Nichols and S. Blake, Differentiated Services Operational Model and Definitions, Internet-Draft, draft-nichols-dsopdef-00.txt, Feb. 1998. [8] R. Yavatkar, R. Guerin and D. Pendarakis, A Framework for Policy-based Admission Control Internet Draft, draft-ietf-rap-framework-00.txt, Nov. 1997. [9] S. Judd and J. Strassner, Directory Enabled Networks - Information Model and Base Schema - Draft v3.0c5 DEN Specifications, Sep. 1998. [10] P. Bhattacharya et. al., An LDAP Schema for Configuration and Administration of IPSec-based Virtual Private Networks, Internet Draft, draft-ietf-ipsec-policy-ldapschema-00.txt, Oct. 1998. [11] Desktop Management Task Force, Common Information Model (CIM) Specification, Version 2.0, Mar. 1998. [12] E. Stokes, D. Byrne, B. Blakeley and P. Behera, Access Control Requirements for LDAP, Internet Draft, Sep. 1998. [13] J. Strassner and E. Ellesson, Terminology for describing network policy and services Internet draft, draft-strassner-policy-terms-00.txt, Aug. 1998. [14] S. Kent and R. Atkinson Security Architecture for the Internet Protocol RFC 2401 Nov. 1998. rajan, kamat Expires 23/ November/ 1999 [Page xxii] Internet Draft draft-rajan-policy-framework-00 23/ May/ 1999 AUTHOR'S ADDRESS Raju Rajan AT&T Labs Research 180 Park Avenue, PO Box 971 Florham Park, NJ 07932 email: rajan@research.att.com Sanjay Kamat IBM T. J. Watson Research Center 30 Saw Mill River Road Hawthorne, NY 10532 email: sanjay@watson.ibm.com Full Copyright Statement 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 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. rajan, kamat Expires 23/ November/ 1999 [Page xxiii]