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 <policy action>




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]