idnits 2.17.00 (12 Aug 2021) /tmp/idnits1583/draft-rajan-policy-framework-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 8 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 927: '... SHOULD be used in conjunction with ...' RFC 2119 keyword, line 930: '...ch communication SHOULD be secured, wi...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 944, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 947, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 952, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 971, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 975, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 979, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 985, but no explicit reference was found in the text == Outdated reference: draft-ietf-policy-core-schema has been published as RFC 3703 -- No information found for draft-ietf-ipsec-doi - is the name correct? -- Possible downref: Normative reference to a draft: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' == Outdated reference: draft-ietf-rap-cops has been published as RFC 2748 ** Obsolete normative reference: RFC 1777 (ref. '6') (Obsoleted by RFC 3494) -- Possible downref: Normative reference to a draft: ref. '7' == Outdated reference: draft-ietf-rap-framework has been published as RFC 2753 ** Downref: Normative reference to an Informational draft: draft-ietf-rap-framework (ref. '8') -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- No information found for draft-ietf-ipsec-policy-ldapschema - is the name correct? -- Possible downref: Normative reference to a draft: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' == Outdated reference: A later version (-01) exists of draft-strassner-policy-terms-00 -- Possible downref: Normative reference to a draft: ref. '13' ** Obsolete normative reference: RFC 2401 (ref. '14') (Obsoleted by RFC 4301) Summary: 11 errors (**), 0 flaws (~~), 13 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Authors 2 INTERNET DRAFT R. Rajan 3 AT&T 4 S. Kamat 5 IBM 6 23/ May/ 1999 8 A Simple Framework and Architecture for Networking Policy 9 draft-rajan-policy-framework-00.txt 11 Status of Memo 13 This document is an Internet-Draft and is in full 14 conformance with all the provisions of Section 10 of RFC2026 15 except for the right to produce derivative works. 17 Internet-Drafts are working documents of the Internet 18 Engineering Task Force (IETF), its areas, and its working 19 groups. Note that other groups may also distribute working 20 documents as Internet- Drafts. 22 Internet-Drafts are draft documents valid for a maximum of 23 six months and may be updated, replaced, or obsoleted by 24 other documents at any time. It is inappropriate to use 25 Internet-Drafts as reference material or to cite them other 26 than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be 32 accessed at 33 http://www.ietf.org/shadow.html 35 Discussion of this draft will be carried on the policy 36 mailing list (policy@raleigh.ibm.com). Suggestions for 37 improvement may also be sent to rajan@research.att.com. 39 Distribution of this memo is unlimited. 41 Abstract 43 Many new protocols defined in the IETF have a regulatory 44 component, i.e., network administrators have to decide what 45 users, applications or hosts should have access to what 46 resources/services under what conditions. Large-scale 47 deployment of services using such protocols is critically 48 dependent on the presence of a network-wide policy 49 infrastructure that allows Internet Service Providers (ISPs) 50 and corporate administrators to regulate the network rather 51 than configure individual devices. A key component of this 52 effort is to evolve standards-based means of representing 53 and storing policy information in a unified manner, 54 with a focus on schema for storing policy information in 55 directories. This document presents concepts, terminology, 56 a policy framework and requirements for such a definition. 58 1. Introduction 60 Given the wide and varied usage of the term "policy", it is 61 imperative that the word be clearly defined in the networking 62 context. As a starting point, we shall use policy to denote 63 the unified regulation of access to network resources based on 64 administrative criteria. Policy is driven by the need to create 65 multiple services over a shared IP infrastructure melding together 66 different protocols. A complementary perspective on policy is to 67 think of it in terms of (relatively) static performance goals or 68 operational rules for a dynamic network environment supporting a 69 variety of services. A policy infrastructure is the collection 70 of information models, protocols and mechanisms through which the 71 intentions of administrators can be represented, stored, communicated 72 and translated into operations carried out at various network 73 elements that encounter packet streams. 75 In order to motivate the domain of policy as defined in this 76 document, consider the following examples: 78 (1) An ISP operator wishes to offer an ``extranet'' service to 79 interconnect some company's campuses spread across the United States. 80 Such a service includes assurances of traffic isolation, privacy, 81 as well as bandwidth availability for traffic carried across the 82 extranet. Such a service is pieced together from a variety of 83 different protocols and components, e.g., network address translation 84 to ensure connectivity, firewalls to ensure campus isolation, IPSec 85 for encryption and authentication, MPLS for QoS provisioning across 86 the backbone, etc. The regulatory components of such a service, to 87 be provided by a policy infrastructure, include regulation of address 88 translation to ensure connectivity, policies to prevent security 89 violations at the firewall, and policies to automatically encrypt 90 data from confidential servers across the extranet. 92 (2) In addition to the above ``extranet'' service, the operator 93 wishes to offer 4 different QoS services, priced differently. 94 The ISP allows customers to indicate their service preference 95 on a packet-by-packet basis by setting DS codepoint in IP header 96 appropriately. The added regulatory component of such a service 97 is traffic volume verification through policing at network access 98 points. 100 (3) A reputed telecommunications company wishes to offer unified 101 voice and data services over cable modems. The billing and 102 processing requirements for voice are different from data. The 103 regulatory components of such a service include bandwidth management, 104 prioritization of voice traffic, account verification and call 105 routing. 107 (4) An administrator of an RSVP-capable intranet wishes to restrict 108 individual Controlled Load reservations from engineering staff during 109 the day (9am to 5pm) to a certain token rate and also limit the total 110 bandwidth of such reserved flows. 112 (5) A network operator interfaces with another network operator at a 113 peering point to support communication within their network. Network 114 operator A supports 4 service levels within network A, while network 115 operator B only supports two service levels. Network operator B maps 116 the first two service levels of A to one type of its own service 117 levels, and the remaining two into its second type of service level. 118 The policy component of such a service is to configure and enforce 119 the mapping between the service categories and enforce traffic 120 contracts. 122 It is clear from the above examples that policy, i.e., the regulatory 123 aspect of service provision, is very wide in scope. Obviously, the 124 entire policy infrastructure cannot be unified and standardized all 125 at once. Instead, standardization efforts must be aimed at protocols 126 and representations that allow devices potentially belonging to 127 multiple vendors to interoperate by distributing, sharing and 128 interpreting policy information in a consistent manner. Further, 129 while some mechanisms for regulation of services are best provided 130 within protocols themselves, it is very unsatisfactory to completely 131 isolate policy definition for different protocols from one another, 132 for several reasons. 134 - Different services may benefit by using common policy transport 135 mechanisms and semantics. 137 - Policies regarding different services are defined using 138 common categories such as users, applications, hosts, etc. 139 Administering these separately for each service could be time 140 consuming and messy. 142 - Policies for different protocols may have interaction effects. 143 For instance, network resources are wasted if a QoS policy 144 reserves bandwidth for a flow that another security policy 145 forbids. 147 - ISPs and corporate administrators would prefer to define new 148 hybrid services, such as combining network access with other 149 security and QoS features. These higher level services need to 150 be administered in a uniform manner, which would be best done 151 given a common policy infrastructure. 153 However, given the diverse needs of different environments and the 154 heterogeneity of information availability and functionality in 155 network devices, the evolution of a single ubiquitous policy solution 156 is very ambitious. Instead, we take a gradual approach which is 157 aimed at well defined policy needs at first, working out to a more 158 ambitious framework as newer policy requirements emerge. Our first 159 aims are: 161 - 1. Derive a common terminology and conceptual framework for 162 policy-based network control, with a few carefully selected 163 services and protocols as the first targets. 165 - 2. Develop an appreciation for the policy needs of current 166 services, with an emphasis on QoS and security services. 168 - 3. Distill from these a simple, common architecture that 169 illuminates our workspace, 171 - 4. Present an overview of existing and proposed "pieces of 172 the puzzle" that may be usefully employed to implement the 173 architecture. 175 - 5. Show that the architecture assumed does not restrict the 176 solution space by outlining different feasible enhancements and 177 extensions. 179 - 6. Obtain requirements for and constraints on a common policy 180 representation that may be stored in a directory ("directory 181 schema") with a focus on Quality of Service. 183 - 7. Define an associated policy information base (PIB) and 184 management information base (MIB) that could be usefully employed 185 in controlling and managing heterogenous devices. 187 A key motive for this effort is the drive to evolve standards-based 188 means of representing information ("schema") in a unified manner, 189 and storing such information in LDAP-accessible directories [6]. 190 This document presents concepts, terminology, a policy framework and 191 requirements for such a definition. 193 2. Requirements 195 2.1. Policy Requirements for QoS 197 In order to obtain some insight into the semantics of policy rules 198 required for QoS and other services, we present an over-view of the 199 policy needs of integrated and differentiated services. 201 Integrated services with RSVP signaling approach seeks to provide 202 per-flow QoS assurances with dynamic resource reservation. A flow 203 is defined by the 5-tuple (source address, destination address, 204 protocol, source port, destination port). RSVP is a protocol for 205 reserving network resources for unicast or multicast flows, with 206 stringent requirements satisfied by a guaranteed service, and more 207 flexible requirements by a relaxed controlled load service. In this 208 context, there is need to provide policy control of individual flows, 209 and regulate their ability to reserve network resources. RSVP is 210 capable of opaquely transporting policy-objects which may be used 211 by policy-aware nodes to derive more information about the user, 212 application or end-points of communication. The role of policy 213 allows for highly granulated interactions with billing, accounting 214 or accreditation systems resulting in informed control over the 215 size and nature of the QoS reservations in the network. (See [8] 216 for a discussion of policy based admission control framework and 217 sample policies). Differentiated services (DiffServ), on the other 218 hand, are aimed at traffic aggregates that may not correspond to 219 fine-grained flows. The frequency of signaling is much coarser, 220 and may occur through a variety of mechanisms (bandwidth brokers, 221 off-line communication, service level agreements, etc.). The 222 DiffServ approach relies more on administrative control of bandwidth, 223 delay or dropping preferences, rather than per-flow signaling 224 protocols to communicate service level information to network 225 elements. For such services we wish to enable flexible definition 226 of class-based packet handling behaviors and class-based policy 227 control. See [7] for a discussion of DiffServ framework and sample 228 behavior/service descriptions). 230 While these mechanisms address the issue of how to provide quality of 231 service, the complementary issue of which packets are eligible for 232 what services is a policy issue. For instance, an e-tailer may wish 233 to provide preferential treatment to real-time transaction oriented 234 web-traffic. Or an ISP may seek to ensure that voice-over-IP is 235 assigned to a low-loss, low-delay class of service, while limiting 236 the number of simultaneously supported voice calls. Or consider 237 a network administrator of an RSVP capable intranet who wishes to 238 restrict individual Controlled Load reservations from certain sources 239 during the day to a certain token rate and also limit the total 240 bandwidth of such reserved flows. In these and other examples, the 241 utility of QoS services depends heavily on the presence of mechanisms 242 for administering them. In fact, large-scale deployment of QoS 243 services is critically dependent on the presence of a network-wide 244 policy infrastructure that allows Internet Service Providers (ISPs) 245 and corporate administrators to control the network rather than 246 configure individual devices. 248 Speaking broadly, the policy needs of QoS administrators are of three 249 kinds. First, administrators would like to be able to provision 250 networks, i.e., earmark resources for use by certain types of 251 traffic. Second, they would like to control the terms and conditions 252 under which users are able to reserve bandwidth in the network. 253 Third, they would like to substitute one QoS service for another; 254 for instance, require that integrated service categories be provided 255 using comparable differentiated service categories. More elaborately 256 the policy needs for QoS are as follows: 258 Integrated services using RSVP: RSVP has been devised to explicitly 259 carry and process policy objects together with reservation requests 260 and responses. In its simplest form, policy may be used to control 261 the number, size and the nature of RSVP reservation requests 262 depending on the information in the header of RSVP Path and Resv 263 messages, or the TSpec and RSpec parameters. This use of policy 264 in such an environment allows enterprises to be able to police 265 QoS requests on a per- flow, per-user or per-application basis. 266 However, a number of interesting and important forms of policy may 267 only be expressed using policy objects carried with RSVP signaling 268 messages These include objects that identify and authenticate users, 269 applications or hosts, define the relative (reservation) priorities, 270 carry accounting and charging information, etc. 272 Proxy RSVP: This refers to the use of policy to control the 273 establishment of RSVP tunnels between routers or other intermediate 274 devices within the network, and the use of these QoS tunnels by 275 traffic flowing through these intermediate devices. There are three 276 common proxy instances: RSVP tunnels for best effort traffic, RSVP 277 aggregation, i.e., combining multiple RSVP tunnels into one, and 278 Other QoS protocol to RSVP translation. 280 Differentiated services secured through provisioning: This includes 281 the case of using policy to specify and control DiffServ within 282 a domain, and, in an inter-domain scenario, control bilateral 283 agreements across peer network boundaries. In such cases, policies 284 are used to map across the two domain specific semantics, and enforce 285 access control restrictions, such as ensuring that the amount of 286 in-profile traffic is within the specified contractual limits. 288 Multiple QoS Protocols Tunneling through DiffServ: RSVP or other 289 QoS protocols may be used within a domain, being mapped onto 290 differentiated services across domains. In such cases, policies 291 are needed at the domain boundary to translate between signaled and 292 differentiated service semantics, to enforce traffic monitoring and 293 to exercise access control over network resources. 295 2.1.1. Policy Requirements for Security 297 IPSec [14] is a suite of protocols standardized for the purpose of 298 ensuring secrecy and trust across the public internet. It is a 299 complex protocol requiring participating hosts to negotiate a number 300 of configuration parameters. The main issues that arise in IPSec 301 regulation are outlined below: 303 1. End-to-End security configuration: In the interests of corporate 304 policy, enhanced security requirements or ease of operation, 305 administrators may wish to override protocol configuration 306 defaults specified in IPSec documents, using alternative 307 parameters or algorithms. There is a host of parameters 308 including ISAKMP/Oakley exchange mode, authentication method, 309 perfect forward secrecy requirement, hashing, authentication and 310 encryption algorithms for the two phases of IPSec, timeouts, etc. 311 Administrators must be able to configure the nature of security 312 based on users, end-hosts, servers being accessed, time of day, 313 path of communication, etc., as part of IPSec policy. 315 2. Gateway access: Often, multiple security gateways have to be 316 traversed for two end hosts to communicate. Depending on the 317 end host application, a gateway may either deny or permit the 318 connection or require an IPSec tunnel from either the end host or 319 another gateway acting as a IPSec proxy for the end host. Access 320 through the use of gateways must be supported through policy. 322 3. Intranet access: Firewalls and security gateways are required 323 to selectively admit inbound traffic based on the communication 324 users, hosts, applications, the presence of authentication 325 tickets (certificates), etc. 327 4. Proxy IPSec: In some cases, end-to-end IPSec may be deemed 328 too burdensome, and administrators may configure firewalls to 329 dispatch specified traffic within secure tunnels across the 330 Internet. In this case, the policy language must be rich enough 331 to allow for the classification of traffic based on end-users, 332 hosts, communication path, time of day, etc. 334 In addition to policy requirements of IPSec, there are other 335 protocols that have regulatory components. We wish to ensure that 336 policy representation is compatible with the needs of: 338 - IP Filtering: Schema should be able to describe simple IP 339 filters that may be used to configure access devices. 341 - IP Address Space Management: Address assignment and translation 342 services provided by DHCP and NAT could also be regulated through 343 policy. 345 - Network Access Control: Certain users and applications may not 346 access intranets or certain servers/hosts. Their access must be 347 proscribed through policy. 349 3. Policy : Terminology and Conceptual Framework 351 So far, we have seen the policy needs of QoS and security protocols. 352 In this section, we develop some basic terms and concepts that 353 will allow a shared understanding of the requirements for a policy 354 infrastructure. 356 3.1. Conceptual Hierarchy 358 At the risk of simplifying several intricate features of policy, 359 we present a conceptual model that describes different levels of 360 abstraction at which regulation may be expressed and exercised. 362 Network Level View 364 This is a high-level perspective that incorporates topology, 365 connectivity, end-to- end performance objectives, expressed in 366 terms of static and dynamic resources in the network. The human 367 administrator interacts with the network usually through a human 368 friendly language or intuitive representation such as a GUI. Such 369 a representation may also contain aspects of network monitoring, 370 where the current state of the network is represented so that 371 the administrator may ascertain the extent to which policy is 372 enforced in the network. As an instance of a network level view, 373 an administrator may require that all http traffic from server 374 A to managers in campus B be transmitted through a gold- QoS, 375 high-security tunnel with a 2 MBps reservation. The definition of 376 "gold-QoS" and "high-security" may be deterministic or probabilistic, 377 but we assume that these are fairly well defined in-context, and not 378 vague and fuzzy. Note that the network level view is integrally 379 tied to the services being administered. For instance, the network 380 view presented by a tool used for administering remote access 381 to a corporate campus would be very different from another used 382 to dynamically modify peering agreements between two large ISPs. 383 Consequently, the network view cannot be standardized, and we 384 must look towards a slightly lower level of the hierarchy where 385 standardization efforts may be directed. 387 Role or Group Level View 389 A network level policy injunction requires different behaviors at 390 various network nodes depending on their roles within the network. 391 For instance, with respect to the above example, all firewalls and 392 access routers in campus B have a similar role to play. They must 393 be instructed to permit encrypted traffic from server A into campus 394 B. Thus, the network view may be resolved into distinct role or 395 policy group level views, which correspond to the policy objectives 396 and requirements at like network nodes or interfaces. A particular 397 network element may play several roles, and several such elements 398 may play the same role. Each network element is controlled by 399 the policies corresponding to all the roles that it plays. The 400 role level policy view is resolvable into a collection of atomic 401 injunctions called policy rules. Each policy rule corresponds to a 402 statement of the form 404 If (PolicyRuleCondition) then (Action) 406 where (PolicyRuleCondition) is expressed in terms of administrative 407 categories such as users, hosts, applications, etc., and (Action) 408 identifies the associated privileges or deserved treatment. A simple 409 policy rule for a firewall in campus B that would allow all IPSec 410 packets from server A would have the condition "Host: Server A; 411 Protocol: IPSec" associated with the action "ALLOW". 413 Device-specific or Configuration Level View 415 Each network node has vendor-specific resource allocation mechanisms 416 and packet forwarding paths, and role level rules need to be 417 ultimately translated into device-specific instructions. One 418 aspect of a device specific view is the maintenance of caches, 419 filters or classifiers to be placed in the datapath to identify the 420 treatment associated with individual packets. A second aspect is the 421 reservation of resources and the delivery policy mandated services. 422 For instance, to ensure that http traffic from server A is assured of 423 bandwidth, it may be necessary to insert a classifier in an access 424 router, and set the WFQ weights appropriately. It must be clear that 425 device architectures, capabilities and configuration vary highly from 426 vendor to vendor, and that there cannot be a common language for 427 representing or unifying such configuration. 429 3.2. Policy Standardization 431 In order to evolve a schema, it is necessary to identify the level 432 at which policy is to be standardized. The network level view 433 of policy is intimately tied with the to the remaining network 434 management infrastructure, and it is unclear what would constitute 435 an intuitive and yet flexible object model. Further, it involves 436 an implicit knowledge of topology, and it is difficult to automate 437 the translation of such a view to the device level. Consequently, 438 the network level view is best left to different network management 439 vendors to design and customize. At the other extreme, the device 440 level view is too vendor-specific and scales poorly to large 441 networks. In the rest of this document, we assume that role level 442 views are sought to be standardized in schema, and that these are 443 composed of "policy rules". 445 Given that standardization effort in policy should address policy 446 definitions at the Role level, the next issue is to decide on a 447 language framework to define policies. There are several design 448 considerations and trade-offs to make in this respect. 450 1. On one hand, we would like a policy definition language to 451 be reasonably human-friendly for ease of definitions and 452 diagnostics. On the other hand, given the diversity of devices 453 (in terms of their processing capabilities) which could act 454 as policy decision points, we would like to keep the language 455 somewhat machine-friendly, i.e., relatively simple to automate 456 the parsing and processing in network elements. 458 2. An important decision to make is the semantic style of the 459 language, e.g., procedural or declarative. 461 - The procedural approach would model network behavior that 462 is to be regulated through policy in terms of states and 463 pertinent events. In this model, policy directives are 464 statements that control the state transitions and thereby 465 regulate the network behavior. An example of state is 466 installing or removal of packet classification filters 467 and the appropriate configuration actions for traffic 468 conditioning. Examples of events include device boot-up, 469 packet arrival, etc. 471 - The declarative approach would simply describe the desired 472 network behavior in terms of certain actions that should 473 happen when specific conditions hold. For example, a policy 474 directive that states that packets matching a specific 475 traffic profile must be conditioned in a certain way is 476 formulated in terms of conditions that describe the traffic 477 profile and actions that describe the traffic conditioning 478 behavior. A policy rule in this approach is written as if 479 (policy condition) then 481 The declarative approach has the benefit of simplicity, and 482 facilitates hiding implementation differences, making it a 483 suitable candidate for the policy definition language standard. 485 3. It is important to control the complexity of the language 486 specification trading off richness in terms of features for ease 487 of implementation. It is important to acknowledge the collective 488 lack of experience in the field of networking policies and hence 489 avoid the temptation of aiming for "completeness". We should 490 strive to facilitate definition of the common policies that 491 customers require today (e.g. VPN, QoS) and allow migration 492 paths towards supporting complex policies as customer needs and 493 our understanding of networking policies evolves with experience. 494 Specifically, in the context of the declarative style language 495 discussed above, it is important to avoid having full blown 496 predicate calculus as the language as it would render many 497 important problems such as consistency checking and policy 498 decision point algorithms intractable. It is useful to consider 499 a reasonably constrained language from these perspectives. 501 3.2.1. Policy Categories 503 Starting with the broad aim that administrators require mechanisms 504 to control access to QoS resources, we are drawn to describe the 505 specific bases or criteria for discrimination in QoS networks. These 506 would include: 508 1. The end-points of communication: The source and destination IP 509 addresses may be directly obtained from the IP packet, as long as no 510 intermediate proxies that encapsulate packets are involved. Other 511 information, such as source/destination MAC addresses or other layer 512 2 end-point information may be used to regulate communication. 514 2. The route or path of communication: The treatment of packets and 515 the availability of reservable resources depend on the route along 516 which the data packets flow. For instance, packets flowing over 517 a dedicated line may require no particular reservation, while the 518 same packets routed over a backup public network would need special 519 treatment. Simplistic routing-based policies may be described based 520 on the incoming or outgoing interfaces of devices at which the policy 521 is enforced. 523 3. Communicating users or groups: The identity and organizational 524 status of people involved in communication plays a large role in 525 determining their access to network resources. Rich and versatile 526 policy solutions are made possible by the availability of this 527 information is available within the network, for instance, using 528 signaling protocols such as RSVP. 530 4. Application information: The characteristics of the particular 531 application generating traffic, whether it has real-time 532 requirements, for instance, will determine the quality and nature 533 of resources allocated to the traffic. While some such information 534 may be deduced from the port and protocol numbers in IP packets, a 535 more comprehensive solution that does not involve laborious content 536 inspection and state maintenance is possible only if the traffic 537 generating host is involved in signaling application requirements. 539 5. Dynamic Network Characteristics: It is often useful to take 540 the availability of resources in the network, or their scarcity, 541 into account while allowing or denying the use of resources by a 542 particular flow or group of flows. 544 6. Accounting information: The ability to base resource access 545 decisions on the availability of credits or tokens is seen as an 546 important application of policy. 548 3.3. Processing Policy Rules 550 --------------------- 551 Network Level 552 --------------------- 553 | 554 | 555 | Vendor/Service specific mapping 556 | 557 | 558 --------------------- 559 Role Level 560 If (Policy Category based) Condition 561 then Action 562 --------------------- 563 | 564 | 565 | Mapping by policy decision point 566 | 567 | 568 ---------------------------- 569 Device Configuration Level 570 ---------------------------- 572 Figure 1: Hierarchy of Abstractions 573 If we conceptualize policy control in terms of an infrastructure 574 designed to translate administrative intentions into transformations 575 effected on packet streams, then its complexity arises from the need 576 for mechanisms that gather spatially dispersed, dynamic network 577 information and process them to make policy decisions. Consider 578 a policy that allows traffic from certain users to be granted 579 preferential QoS treatment. The complexity of implementing such 580 a policy depends on a variety of factors. On a policy capable 581 end-host, it may be relatively easy to map the login id of the user 582 to their name, and based on a table lookup, mark packets with the 583 ToS pattern that connotes preferential service in the rest of the 584 provisioned network. In the fortuitous case that users are tied 585 to their workstations, network nodes may access a table that maps 586 users to host addresses, and then use source or destination addresses 587 in packet headers to grant preferential QoS treatment. Or a QoS 588 protocol such as RSVP may be used to carry user information as policy 589 objects, used to deny or grant bandwidth requests. Or, in the case 590 of users dialing up from home, user information may be obtained 591 from a protocol such as Radius, and then used by the access router 592 to mark ToS bits of the packet stream. In any event, policies are 593 expressed in terms of categories such as users, hosts, applications, 594 account balances, etc. Network elements that handle packets need to 595 (a) associate the information in the packet header with the policy 596 category, (b) evaluate the policy conditions to see if they hold, and 597 (c) carry out appropriate operations on the packet. 599 3.3.1. Associating policy categories with packet information 601 The mapping of policy categories to header information present in 602 data packets may be static or dynamic; and may be made in a variety 603 of different ways. 605 - If policy categories are identical to, or can be immediately 606 deduced from data packets, the mapping of high level policy to 607 enforcement is direct and static. An simple example of this is 608 when policy is expressed in terms of source IP addresses. Direct 609 mechanisms do not require state. 611 - Sometimes, is suffices to refer to lookup tables for resolving 612 policy categories into packet header based conditions. The 613 example is when users are tied to host addresses, but for 614 administrative convenience policies are expressed in terms of 615 users than host addresses. In this case the mapping is static, 616 but indirect. 618 - Policy categories may be obtained in context, through state 619 that has been established in the operational environment. This 620 is a very important case, as with user names or application 621 information that can be obtained directly at an end host. 623 - The mapping between policy categories and header fields may 624 be dynamic, in which case intermediary packets are used to 625 communicate mapping information. For instance, policy category 626 information may be transmitted by signaling protocols, and 627 used to control the associated data stream. One example is 628 the use of RSVP policy objects to ascertain the identity of a 629 dial-up user in order to accept or deny a reservation. Note 630 that this identity may now be used to put the data stream in a 631 secure (proxy) IPSec tunnel. This latter use of information 632 presented through one protocol to deliver a different service 633 (cross-service policy function) considerably expands the utility 634 of policy. Another instance of the use of intermediaries is when 635 dynamic port number information (say for FTP data) is obtained by 636 examining the content of signaling packets. 638 - In addition to obtaining information directly and through 639 intermediary packets, a network device may contact a centralized 640 network location to obtain information on the policy category a 641 particular flow belongs to. An example of such indirect methods 642 is when IP address to FQDN information is obtained from a DHCP 643 server, triggered perhaps by an unfamiliar packet stream in an 644 access router 646 3.3.2. Evaluating the Policy Condition 648 Once the policy categories associated with a packet or packet 649 stream have been ascertained, any policy condition involving 650 those categories must be evaluated. Typically, conditions involve 651 checking set membership -- does "John Doe" belong to the group 652 "Pseudonym-users", or is a certain account balance positive. Now, 653 this stage of policy processing is relatively straightforward 654 if the condition or relation being evaluated changes slowly or 655 never. User and host groups are good examples of such stable policy 656 conditions. However, certain other policy categories, such as 657 account balances, are volatile and it is customary to use specialized 658 servers and protocols to track their state. So the evaluation of 659 the condition is outsourced or specialized information solicited 660 from an external entity. An extreme example of spatially dispersed, 661 volatile information is the evaluation of conditions based on network 662 congestion. (Such a condition would, however, need precise semantics 663 -- where is this state measured and how -- to be meaningfully 664 implemented.) In this case, information regarding packet losses, 665 queue lengths or delays must be solicited from multiple network 666 elements and combined in order to evaluate the policy condition. 668 3.3.3. Executing Policy Actions 670 There is tremendous diversity of capabilities and execution 671 environments across network devices, and the ambitious goal of 672 controlling them through a policy infrastructure has to strike the 673 right tradeoff among design objectives. On one hand, it is important 674 for policy actions to be clearly specified directives that different 675 machines would interpret and execute in a comparable manner, i.e., 676 policy must be implementable uniformly across the network. On the 677 other hand, policy cannot be specified at the machine instruction 678 or configuration levels, even though this would make for precise 679 control. One reasonable compromise is to suggest that policy should 680 control standard protocols and behaviors; and not be used to define 681 new protocols. This does not preclude the use of policy as a glue to 682 define new services by configuring and combining existing mechanisms, 683 but it does move away from defining state machines of arbitrary 684 complexity. In short, policy actions should parameterize existing 685 protocols or behaviors. 687 4. A Simple Policy Architecture 689 Considering the great heterogeneity of large networks -- varying 690 device processing and storage capabilities, the differential 691 availability of information regarding policy categories, as well 692 as different policy requirements, control mechanisms and network 693 protocols -- it is improbable that an entire policy infrastructure 694 can be based on one single design. In keeping with the more 695 restricted aim of this framework document of unifying policy 696 representation, we first address architectural requirements for the 697 creation, storage and communication of policy rules. 699 The administrator must be able to view and express requirements at 700 the network level. At a minimum this requires a management tool that 701 is capable of creating policy rules and storing them in the common 702 format. 704 The policy repository is at the core of the architecture for unified 705 policy representation. It acts as the memory of the network, 706 and stores policy rules for easy retrieval. As policy rules are 707 expressed in terms of relatively static categories, and the frequency 708 of information retrieval is expected to far exceed update frequency, 709 a directory is well suited to be a repository. 711 The policy enforcement function (PEF) is the functional entity in the 712 data path that delivers network resources to packets. For example, 713 in terms of QoS services, the enforcement function may perform 714 policing, buffer management scheduling, etc. The PEP queries the 715 policy decision function (PDF) regarding specific actions that are to 716 be applied in conditioning the packet stream. Thus, the PDP performs 717 the key functions of mapping policy categories to information in 718 data packet headers, and of determining which policy rules after 719 evaluating the conditions. Note that the PDP is entity that brings 720 together static rules and dynamic information required for their 721 enforcement. 723 o o 724 | ------------ | 725 / \ / \ Administrator 727 Administrative Function 729 ----- ----- 730 | | | | 731 | * | | * | 732 ----- ----- Management tool 734 Management Function 736 - - 737 --- --- 738 ----- ----- 739 ------- ------- Policy Repository 740 Policy Storage Function 742 ??? ??? 743 ??? ??? 744 ??? ??? Policy Decision Point (PDP) 746 Policy Decision Function 748 ----- ----- 749 |&*&| |&*&| 750 | * | | * | 751 ----- ----- Policy Enforcement Point (PEP) 752 Policy Enforcement Function 754 Figure 2 755 Policy Functional Model 757 4.1. The Role of Existing or Proposed Standard Protocols 759 As shown in the above figure, each of the functions described above 760 may be implemented in a distributed or even replicated manner. 762 The management function may be spread across multiple management 763 tools, or several tools may simultaneously be used to populate the 764 repository. Likewise, the policy repository may be replicated or 765 distributed across several directories. In many cases, the policy 766 decision function may be substantially located at a specialized 767 policy server that communicates with multiple network devices at 768 which policy enforcement occurs. The policy decision function may 769 also be split across several policy decision points which collaborate 770 in making decisions. If multiple functions are not co-located, or 771 if the same function is distributed across multiple devices, it 772 is necessary to define standardized protocols for communication 773 between different boxes. There are a number of existing and proposed 774 protocols and mechanisms that may be usefully employed to realize 775 the above architecture, which we discuss in this section. In the 776 next section we discuss enhancements to the basic model to provide 777 enhanced functionality. 779 Directories make good policy repositories, and are commonly accessed 780 using LDAP, a lightweight protocol used extensively to communicate 781 information about users, hosts and applications. Traditional 782 databases, using a language such as SQL provide greater functionality 783 in the repository, at the cost of being more heavyweight. While 784 there are many choices of protocols for directory/database access 785 from the management tool and PDF, LDAP appears to be favored by 786 a number of vendors and users for its ubiquity, versatility and 787 flexibility. LDAP schemas are versatile and allow considerable 788 flexibility in choice of back-end directory management. Further, 789 the LDAP client-server protocol is widely implemented and used for 790 supporting a wide range of directory enabled applications. However, 791 there are a number of shortcomings of LDAP that must be clearly 792 understood by implementers. (Para on shortcomings of LDAP to be 793 added -- asynchronous notification, replication support, security, 794 referential integrity, support for "templates", limitations of query 795 language.) 797 The RAP working group has recently moved to standardize the COPS 798 [5] protocol for outsourcing RSVP decision making from a PEF to 799 PDF. This protocol is modular and may be extended for other policy 800 outsourcing requirements. More recently, the Diameter protocol has 801 been proposed for outsourcing authentication and security decision 802 making. Extensions have been proposed to enhance Diameter to handle 803 QoS outsourcing as well. Another outsourcing protocol that is 804 currently proposed is the Security Policy Protocol in the IPsec WG. 806 SNMP is likely to continue as an integral component of the network 807 management infrastructure. It can play many roles in implementing 808 the above policy architecture. SNMP can be used at the PDF and PEF 809 to record errors, policy usage and notify administrators of unusual 810 occurrences within the network. It may be used by the management 811 tool to notify the PDF of a policy update (as such an asynchronous 812 notification feature is not yet available with LDAP). A number 813 of other protocols such as telnet or SSH with CLI (Command Line 814 Interface) and TFTP (could be combined with IPsec) are complementary 815 to SNMP or COPS. 817 4.2. Enhanced Functionality 819 The basic functions described above may be extended by vendors 820 seeking to enhance flexibility, ease of use, scalability or security. 821 In this regard, there are multiple logical functions at which the 822 same enhancement may be usefully provided. For instance, it is 823 conceivable that some form of "sanity checking" for policy rules 824 is part of each of the above pieces. The "correct" placement 825 of extended functionality depends on access to information. For 826 instance, if there are multiple administrators in a network, but one 827 physical directory server, then the repository function is perhaps 828 best enhanced to handle network level sanity checking. Below, we 829 describe some obvious enhancements to each of the functions, with the 830 caveat that the list is neither necessary nor exhaustive. 832 Apart from being a simple input device for policy definition, 833 management tools can use intuitive user interfaces to bring together 834 network topology, connectivity and performance, with a language for 835 expressing policy categories and goals. In this case, management 836 tools function as translators of the network level view into a role 837 level view. Such translation ensures that policy is uniform across 838 the network, and reduces the need for expensive uniformity checks. 839 (As an example for the need for uniformity, consider two firewalls 840 in peer campuses that cannot communicate, being configured to use 841 different IPSec encryption methods for the same traffic.) Further, 842 management tools can perform several sanity checks on rules. They 843 ensure that policy objects are syntactically correct, that objects 844 referred to in policy definition exist, that policies are uniform 845 across the network, and that multiple rules defined for each role are 846 consistent. To the extent that the management tool has access to 847 network device functionality and resource availability information, 848 these may be included in consistency checking. 850 Policy repositories vary in their ability to be reliable, secure 851 and distributed. They support query languages of differing 852 complexity. Repositories enhanced to provide native support for 853 policy categories would be natural locations to optimize a variety of 854 policy consistency and sanity checks. 856 The policy decision function is the merging and processing point for 857 static and dynamic information. A variety of protocols different 858 information exchange protocols may be supported here, especially 859 those for gathering volatile data required for decision making. 860 PDPs may talk to different servers and devices in the network, or 861 even to other PDPs, in order to collect billing and accounting 862 information, group membership, addressing and routing information, as 863 well as resource availability and usage. In addition, a PDF may be 864 aware of the resources and capabilities of the PEPs it is connected 865 to, and hence able to flag policy rules that cannot be applied 866 because of device conditions. Some of the shortcomings of existing 867 mechanisms, such as the lack of asynchronous notification in LDAP, 868 may be addressed by defining specialized protocols between functional 869 entities. 871 5. Policy Representation Requirements 873 The directory provides a convenient repository of the resource 874 regulation policies, which may be accessed by a number of different 875 policy decision points. The following considerations must guide the 876 evolution of standardized means of representing policy (see [1] for 877 instance,) also known as policy schema: 879 - The schema must be defined at the role or policy group level 880 view, and not at the network level nor at the level of device 881 configuration. 883 - It is assumed that the policy repository will not store volatile 884 information required for policy decision making. Hence, the 885 schema must be devised to express administrative intent in terms 886 of relatively static categories. The policy decision point will 887 map policy categories to identify packet streams that need to be 888 regulated. 890 - The schema definition should be generic enough to support a wide 891 range of resource control environments. 893 - Policy schema must be used to configure and control standardized 894 protocols and services, and not as a low-level programming 895 language for networking devices. These schema must support the 896 needs of QoS and security as discussed earlier in this document. 898 - The schema shall be designed to be extensible to the needs of 899 other network services. 901 - From this perspective, it is desirable that the schema 902 facilitates definition of a wide range of policies varying in 903 their complexity. Simple policies (the common case) should be 904 easy to specify, and there should be sufficient hooks to define 905 sophisticated policies within the schema. Using the language 906 analogy, an administrator's ability to define complex resource 907 regulation policies should not be limited by the structure 908 of the schema, although it may be limited by the available 909 implementation of the policy enforcement environment. 911 - The schema should facilitate simple addition and deletion 912 of new rules, automated checks for rule ambiguities, and 913 allow for diverse methods (varying in efficiency and ease of 914 implementation) to be employed in the policy decision entity to 915 search through rules. 917 - While compactness of representation is of concern, it is 918 subordinate to the needs of expressiveness and extensibility 919 listed above. 921 6. Security Considerations 923 There are two potential security considerations, both of which may 924 be addressed through standards compliant mechanisms. The first is 925 the unauthorized access to read or change policy rules and related 926 objects in the directory repository. The schema in this document 927 SHOULD be used in conjunction with an LDAP access control mechanisms, 928 see for instance [12]. The second exposure for violation of security 929 lies in the communication between policy decision point and the 930 directory repository. Such communication SHOULD be secured, with 931 both ends mutually authenticated using SSL/TLS or IPSec. 933 Acknowledgments 935 Thanks to Partha Bhattacharya and Skip Booth for useful discussion 936 and suggestions in this problem space. We also thank many others who 937 have read and commented on this draft in various forms. 939 References 941 [1] J. Strassner and E. Ellesson, Policy Framework Core Information 942 Model", draft-ietf-policy-core-schema-01.txt, February 1999. 944 [2] D. Piper, ``The Internet IP Security Domain Of Interpretation 945 for ISAKMP'', draft-ietf-ipsec-doi-07 947 [3] Bhattacharya, P., and R. Adams, W. Dixon, R. Pereira, R. Rajan, 948 "An LDAP Schema for Configuration and Administration of IPSec 949 based Virtual Private Networks (VPNs)", Internet-Draft work in 950 progress, October 1998 952 [4] R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin, 953 Resource ReSerVation Protocol (RSVP) Version 1 Functional 954 Specification. RFC2205, Sept. 1997. 956 [5] S. Herzog, A. Sastry, R. Rajan, R. Cohen, J. Boyle, and 957 D. Durham, The COPS (Common Open Policy Service) Protocol 958 Internet-Draft, draft-ietf-rap-cops-00.txt, Jan. 1998. 960 [6] W. Yeong, T. Howes and S. Kille, Lightweight Directory Access 961 Protocol, RFC1777, Mar. 1995. 963 [7] K. Nichols and S. Blake, Differentiated Services 964 Operational Model and Definitions, Internet-Draft, 965 draft-nichols-dsopdef-00.txt, Feb. 1998. 967 [8] R. Yavatkar, R. Guerin and D. Pendarakis, A Framework 968 for Policy-based Admission Control Internet Draft, 969 draft-ietf-rap-framework-00.txt, Nov. 1997. 971 [9] S. Judd and J. Strassner, Directory Enabled Networks - 972 Information Model and Base Schema - Draft v3.0c5 DEN 973 Specifications, Sep. 1998. 975 [10] P. Bhattacharya et. al., An LDAP Schema for Configuration and 976 Administration of IPSec-based Virtual Private Networks, Internet 977 Draft, draft-ietf-ipsec-policy-ldapschema-00.txt, Oct. 1998. 979 [11] Desktop Management Task Force, Common Information Model (CIM) 980 Specification, Version 2.0, Mar. 1998. 982 [12] E. Stokes, D. Byrne, B. Blakeley and P. Behera, Access Control 983 Requirements for LDAP, Internet Draft, Sep. 1998. 985 [13] J. Strassner and E. Ellesson, Terminology for describing network 986 policy and services Internet draft, draft-strassner-policy-terms-00.txt, 987 Aug. 1998. 989 [14] S. Kent and R. Atkinson Security Architecture for the Internet 990 Protocol RFC 2401 Nov. 1998. 992 AUTHOR'S ADDRESS 994 Raju Rajan AT&T Labs Research 180 Park Avenue, PO Box 971 Florham 995 Park, NJ 07932 email: rajan@research.att.com 997 Sanjay Kamat IBM T. J. Watson Research Center 30 Saw Mill River Road 998 Hawthorne, NY 10532 email: sanjay@watson.ibm.com 1000 Full Copyright Statement 1002 Copyright (C) The Internet Society (1997). All Rights Reserved. 1004 This document and translations of it may be copied and furnished to 1005 others, and derivative works that comment on or otherwise explain it 1006 or assist in its implementation may be prepared, copied, published 1007 and distributed, in whole or in part, without restriction of any 1008 kind, provided that the above copyright notice and this paragraph 1009 are included on all such copies and derivative works. However, 1010 this document itself may not be modified in any way, such as by 1011 removing the copyright notice or references to the Internet Society 1012 or other Internet organizations, except as needed for the purpose 1013 of developing Internet standards in which case the procedures 1014 for copyrights defined in the Internet Standards process must be 1015 followed, or as required to translate it into languages other than 1016 English. The limited permissions granted above are perpetual and 1017 will not be revoked by the Internet Society or its successors or 1018 assigns. 1020 This document and the information contained herein is provided on an 1021 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1022 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1023 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1024 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1025 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.