Network Working Group A. Barbir Internet-Draft N. Bennett Document: draft-barbir-opes-fsp-00.txt R. Penno Expires: May, 2002 Nortel Networks R. Menon Intel H.T. Pham Alcatel S. Sengodan Nokia J. Mysore Motorola November, 2001 A Framework for Service Personalization draft-barbir-opes-fsp-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as 'work in progress.' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Specification of Requirements The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [1]. Barbir, et. al. Expires May 10, 2002 page [1] Internet-Draft OPES FSP November 2001 Abstract This document and its companion document [17] discuss a Framework for Service Personalization (FSP) defined within the bounds of the Open Pluggable Edge Services (OPES) Framework [14]. The work described here aims to provide a Framework and Protocols for the delivery of the optimal content variant for a given requestor based on subscriber profile and policies, content profile and its associated policies. This document provides a general outline of FSP that could be used as a vehicle for performing personalization services in edge and intermediary devices or at Content origins. While FSP is defined within the scope of OPES, some effort is made within this document to provide insight into general and abstract requirements for such a framework. Detailed discussion of the implementation of this framework, including analysis of the integration of the proposed framework into the larger OPES scope is covered in the companion document given in [17]. It should be noted that at this stage, these documents are not intended to completely define an abstract, implementation-independent FSP, but rather one, which builds on, and functions within the scope of the continuing work of the OPES. 1. Introduction In the Internet today, personalization and profiling services are provided to subscribers by portals. Portals require subscribers to log on to their sites, which helps to identify the subscriber. Furthermore, portals perform subscriber profiling by tracking their habits and preferences. In order to be able to create accurate subscriber profiles, the portals must rely on co-located subscriber identification and profiling from participating web sites. Current schemes for providing personalization services rely on piecemeal subscriber identification and profiling. The schemes require the subscriber to repeatedly log on to various portals or web sites, since each portal has a finite number of web sites with which it has arrangements to share subscriber information. As a consequence, subscriber information gets duplicated in various locations across the Internet, in a number of different formats. Editor Note: What about Microsoft Passport, Liberty Alliance etc? A major drawback of current personalization schemes is their reliance on origin web servers to perform the personalization tasks. As a consequence content providers need to store and manage different content for different subscribers, or alternately, there is no storage of content on a per-user basis, but rather a large collection of content to choose from based on personal profiles and other criteria. This approach leads to scalability and optimality issues. This is because the personalization task is done based on incomplete information about the subscriber. The content provider may not be aware of many types of information about the subscriber, including geographic location, QoS policy, device type, and access rate, which could dramatically increase the efficiency of any personalization task undertaken on their behalf. A potential solution to this problem is to shift responsibility for personalizing content to an intermediary device. This has many advantages over current solutions, and represents an important value add service that could be provided by network edge caching proxies or other intermediary devices. Barbir, et. al. Expires May 10, 2002 page [2] Internet-Draft OPES FSP November 2001 Network edge caching proxies are currently deployed in the Internet in order to accelerate web content delivery and reduce the load on origin servers. Since these intermediaries function as gateways between subscribers and content providers it is possible to use them for intelligent services beyond simple caching. Examples of such services include among others [2] virus scanning, ad insertion, caching of personalized web pages, limited client bandwidth adaptation, request filtering, and creation of uniform subscriber profiles. In the IETF, OPES [2] is standardizing the task of extending the scope of caching proxies to perform extended services at the edge of the network. This document defines the scope of personalization and introduces the concept of A Framework for Service Personalization (FSP). The framework defines the essential components and mechanisms that are needed in order to provide consistent personalization services to subscribers, delivering high quality personalized content to subscribers in a secure and reliable manner. This document establishes a framework and requirements for developing an OPES FSP call-out server. The document is organized as follows: section 2 defines the terms used throughout the document, section 3 provides an overview of FSP, while section 4 discusses security threats and mechanisms. 2. Definitions and Terminology This section consists of the definitions of a number of terms used to refer to the roles, participants, and objects potentially involved in FSP implementations. Although the following uses many terms used in RFC 2616 [10] and RFC 3040 [13], there is no necessary connection to HTTP or web caching technology. FSP and this vocabulary are applicable to other protocols and content networks. Words enveloped within 'single quotes' are defined terms within this document. ACTION An action is a form of a policy action [13] that results in the execution of a'service module' when 'conditions' of a 'rule' are met. AUTHORITATIVE DOMAIN A logical domain in which the network elements have rights, either delegated or inherited to act authoritatively on behalf of a party. This logical domain may be wholly contained within the administrative domain [2] of the party, or it may be a collection of administrative domains in which the party rights have been delegated. CACHE (REFERENCE DEFINITION [10]) A program's local store of response messages and the subsystem that controls its message storage, retrieval, and deletion. A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent requests. Any client or server may include a cache, though a cache cannot be used by a server that is acting as a tunnel. Barbir, et. al. Expires May 10, 2002 page [3] Internet-Draft OPES FSP November 2001 CACHING PROXY (REFERENCE DEFINITION [13]) A proxy with a cache, acting as a server to clients, and a client to servers. Caching proxies are often referred to as "proxy caches" or simply "caches". The term "proxy" is also frequently misused when referring to caching proxies. CLIENT (REFERENCE DEFINITION [10]) A program that establishes connections for the purpose of sending requests. CONDITION A form of a policy condition [12] that is an expression, which is used to determine whether a 'rule' 'action' should be executed. CONTENT CONSUMER The 'client' that is the final destination of content delivery. CONTENT PATH The content path describes the path that content requests and responses take through the network. Typically, content requests and responses flow between a client, and/or an 'intermediary', and a 'content server'. CONTENT PROFILE A content profile consists of a set of elements that describe available variants for given content. The profile also includes policy information about allowable transformations, adaptations, and Digital Rights Management that are applicable for that content. The profile can be applicable to a specific piece of content, a set or class of content, or an aggregation of content from several locations. CONTENT SERVER The server on which content is delivered from. It may be an 'origin server', replica server, 'surrogate' or parent proxy. CONTENT SERVICE A service operating on and providing a value-add to content. DELEGATE A 'caching proxy' located near or at the network access point of the 'user agent', delegated the authority to operate on behalf of, and typically working in close co-operation with a group of 'user agents'. IN PATH In-Path Content Services are naturally within the message path of The application they are associated with. This may be an Application proxy, gateway, or in the extreme case, one of the end-hosts, that is party to the application [15]. INTERMEDIARY Intermediaries are application gateway devices located in the 'content path' between 'client' and 'origin server'. 'Caching proxies' and 'surrogates' are probably the most commonly known and used intermediaries today. Barbir, et. al. Expires May 10, 2002 page [4] Internet-Draft OPES FSP November 2001 OPES ADMIN SERVER An OPES admin server performs authentication, authorization and accounting (AAA) functions for an OPES 'edge services network'. These functions include, but are not limited to downloading of 'proxylets' and 'rule modules' from trusted parties, authorization and authentication of 'OPES services', the collection of accounting and log data, and other administrative tasks. It must be a member of the 'authoritative domain' of the parties it is authorizing 'content services'. It must be a member of the party's 'authoritative domain' in whose behalf it is provisioning 'content services'. OPES ENGINE An OPES engine allows new services to be defined and executed on 'OPES intermediaries' according to the policies set up by an 'OPES admin server'. OPES Engine contains a message parser, and a rule processor that reside in the flow of content passing through the 'OPES intermediary' collectively form a 'PEP'. The 'OPES engine' calls actions, which reside in either the 'proxylet run-time system' or as 'remote call-out stubs'. OPES INTERMEDIARY An "intermediary" device integrating a compliant 'OPES engine'. OPES intermediaries are typically hosted on 'delegates' or 'surrogates'. OPES SERVICE An OPES service is an authorized 'content service' performed on a message flowing through the 'content path' by a 'OPES service module'. OPES SERVICE MODULE OPES service modules are executable code modules that are executed ether on the local 'proxylet run-time system' or on the 'remote call-out server'. ORIGIN SERVER (REFERENCE DEFINITION [10]) The server on which a given resource resides or is to be created. PCS CALL-OUT SERVER A 'remote call-out server' that performs the task of generating dynamic 'rule modules' that are either encoded or could be extracted from a 'subscriber profile', and which represent a 'subscriber's personalization preferences and subsequently loading them onto the appropriate 'OPES admin servers' or 'OPES Engines'. PDP See 'policy decision point'. PEP See 'policy enforcement point'. POLICY DECISION POINT (REFERENCE DEFINITION [12]) A logical entity that makes policy decisions for itself or for other network elements that request such decisions. Barbir, et. al. Expires May 10, 2002 page [5] Internet-Draft OPES FSP November 2001 POLICY ENFORCEMENT POINT (REFERENCE DEFINITION [12]) A logical entity that enforces policy decisions. PROXYLET A proxylet is 'OPES service module' that runs on the 'OPES intermediary' within the 'proxylet run-time system' and provides a service on 'content path' requests or responses. PROXYLET LIBRARY Proxylet library is a library provided to support runtime services in the 'proxylet runtime system'. PROXYLET META-DATA Proxylet meta-data describes the characteristics, features and requirements associated with a proxylet. Examples for such meta-data are the name of the 'proxylet', its functionality, its version number, where to get it, license related information, execution environments, etc. The meta-data can physically be separated from the 'proxylet' code, but it must be possible to uniquely associate meta-data with 'proxylets' and vice versa. PROXYLET PROVIDER Proxylet provider is the party that provides the 'proxylet' 'OPES service module' to the 'OPES admin server'. PROXYLET RUN-TIME SYSTEM The local execution environment on an 'OPES intermediary'. 'Proxylets' execute as local (as opposed to 'remote call-out') 'actions' within this environment. REMOTE CALL-OUT A remote procedure call made via a 'remote call-out protocol" to a 'remote call- out server' that is invoked as the result of an 'action'. REMOTE CALL-OUT PROTOCOL The network protocol that encapsulates and transports a 'remote call-out' between an 'OPES intermediary' and a 'remote call-out server'. REMOTE CALL-OUT STUB A remote procedure call stub running on the 'OPES intermediary' that binds a 'remote call-out' to the 'OPES engine' as 'actions'. The stub marshals the 'action' to/from the 'remote call-out protocol'. REMOTE CALL-OUT SERVER A cooperating server that runs 'OPES service modules' as the result of a 'remote call-out'. RESOURCE A network data object or service that can be identified by a URI. Resources may be available in multiple representations ('variants') (e.g. multiple languages, data formats, size, resolutions) or vary in other ways. Barbir, et. al. Expires May 10, 2002 page [6] Internet-Draft OPES FSP November 2001 ROLE (REFERENCE DEFINITION [12]) An administratively specified characteristic of a managed element (for example, an interface). It is a selector for policy rules and 'rule modules', to determine the applicability of the rule/'rule module' to a particular managed element. Note: Provisioning Class has been substituted with 'rule module' in this definition, as 'rule modules' are instances of Provisioning Classes within the OPES application domain. RULE Rules are forms of policy rules [12] that contain 'conditions' and 'actions' that are to be executed if the 'conditions' are met. RULE AUTHOR The rule author is the party that authors and provides a 'rule module' to the 'OPES admin server'. RULE MODULE A rule module is a form of a policy Provisioning Class [12] that contains a set of 'rules' and information about the rule module owner. OUT-OF-PATH Out-of-Path Content Services are not natively in the transport path of an application. In other words, they are not necessarily resident (or co-resident) on entities that are natively in the path of application flows. SUBSCRIBER A human being, or user, using a 'client' or 'user agent' to connect to a network in order to make requests for personalized content or services. SUBSCRIBER PROFILE A subscriber profile consists of a set of elements that define a 'subscriber's personalization preferences. This includes, but is not limited to a description of the device capabilities, Quality of Service (QOS), access rate, accounting information, content type preferences, and policies regarding allowable content. A 'subscriber profile' may also include 'rule modules' that allow an OPES engine to perform personalization. SURROGATE (REFERENCE DEFINITION [13]) A gateway co-located with an origin server, or at a different point in the network, delegated the authority to operate on behalf of, and typically working in close co-operation with, one or more origin servers. Responses are typically delivered from an internal cache. Surrogates may derive cache entries from the origin server or from another of the origin server's delegates. In some cases a surrogate may tunnel such requests. Barbir, et. al. Expires May 10, 2002 page [7] Internet-Draft OPES FSP November 2001 Where close co-operation between origin servers and surrogates exists, this enables modifications of some protocol requirements, including the Cache-Control directives in [10]. Such modifications have yet to be fully specified. Devices commonly known as "reverse proxies" and "(origin) server accelerators" are both more properly defined as surrogates. TRIGGER See 'condition'. USER AGENT [10] The client that initiates a request. These are often browsers, editors, spiders (web-traversing robots), or other end user tools. VARIANT (ALSO: CONTENT VARIANT) A specific representation of a network data object or service (resource) identifiable by a URI. A 'variant' is differentiable from other representations of a resource due to language, data format, size, resolution or other distinguishing characteristics. 3. What is Service Personalization? The end goal of any personalization effort is to enable content services on network traffic in a personalized manner. (i.e. "end user content that is delivered to clients") Content services can be further categorized as being in path services and out-of-path services. Examples of such services include: virus scanning, content translation, packet filtering, content adaptation, and others. What is desired is some means of allowing subscribers to specify explicitly or implicitly which services should be applied to their traffic stream, and under what circumstances. The goal of this draft is to define an open, extensible means of encoding these subscriber preferences, as well as similar preferences on behalf of the content owner, and provide a generalized architecture for the application of these preferences to subscriber content streams. If necessary, one or more languages will be specified or supplied to express these preferences. In this regard, such options are already considered within OPES. Traditionally, in dial-up and other narrowband applications, the process of user identification and authentication is closely tied with the process of machine identification and participation in a network. As a result, many current content services are designed in such a way as to perpetuate this link. In the general case (and certainly in the broadband case), these two functions are separate and distinct, and represent differing characteristics of a user session. There are, in fact, four different categories of information upon which content services are based. These are: * Subscriber Profile Information -- Here a subscriber refers to the human being in the interaction making use of content services. Barbir, et. al. Expires May 10, 2002 page [8] Internet-Draft OPES FSP November 2001 * Device Information -- This includes access device capabilities, machine identification, and other factors. * Network Topology/Identification Information -- This can include information regarding the network path from Subscriber to Content. Editor Note: Can this info be considered as the "dynamic" piece of "device information"? * Content Profile Information -- This includes content metadata and other content-related information. There are several levels of differentiated experience that can be defined in which the customization of content or content services is performed based on knowledge of information or influence in some subset of these categories. These levels can be represented in the following matrix format: ED. NOTE: This is preliminary and needs more work! These categorizations are merely an example and need to be hashed out more rigorously. Subscriber Device Network Content Basic X Moderate X X Advanced X X X Total X X X X It should be noted that not all forms of differentiated content or content services constitute personalization. Service Personalization MUST involve differentiation of content and/or services based on user or subscriber information. That is, in order for a given form of differentiation of content or content services to be called personalized, the differentiation must be performed based at least on subscriber information. The precise level of service personalization that can be achieved depends on where in the network these personalization functions are deployed, how much access to information those functions have and the scope of influence these functions have over various aspects of these information categories. Editor Note 1: Check for consistency in terminology - should we say "personalization of content" or "service personalization"? Or is it truly just "personalization" as it may apply to "services" and "content"? Editor Note 2: More here on how different places in the content path & placement of personalization functions will limit or allow certain functions in terms of the level of personalization achieved. In general, service personalization can occur at any point in the network that has access to the request, the content, the content profile, and the subscriber profile (content and subscriber profiles are discussed in a subsequent section). Essentially, any point in the content path is a potential point at which personalization decisions could be made. Logically, the points in the content path reduce to the following scenarios for implementing a personalization service: Barbir, et. al. Expires May 10, 2002 page [9] Internet-Draft OPES FSP November 2001 3.1 Service Personalization at the Content Source The first option is to perform service personalization at the content source. This is akin to the current technique of using portal sites to personalize content. A subscriber logs in to the portal site, which allows the content source to retrieve the subscriber's personal profile and preferences. Content is then dynamically constructed at the content source and delivered to the subscriber based on those preferences. For relatively small sets of content, with a reasonably low number of subscribers, this is a cost-effective solution. There are, however several major drawbacks to this approach: Editor Note: We need to bring out one very critical factor here û the extra demands put on content creators/authors to be creative enough in ensuring that the content that is delivered in various personalized forms will contain, after all, relevant content components. The authoring process becomes essentially more complex and time consuming. 1. This solution does not scale well. As the number of concurrent subscribers increases, performance and reliability degrade rapidly. This is because the same computing resources that are used to generate the content are also being used to deliver the content. Determining which data is required for a given dynamic content variant, accessing and aggregating the required data, invoking any application-specific computing required, and appropriately formatting the content for delivery to a subscriber is highly compute and I/O intensive. In effect, the content source becomes the bottleneck in the content path. 2. Personalized content can only be delivered from sites that have a working agreement with the portal. Since explicit registration of content sources with the portal is required, the applicability of the subscriber profile is severely limited. 3. Since many such portals exist in the Internet today, subscribers are required to authenticate themselves with multiple portals, duplicating and maintaining personal preferences in diverse locations, which are stored in largely incompatible, un-standardized formats, with little or no data sharing between portals. Editor Note: Should we allude to the MS Passport etc. 4. Because subscriber profiles are stored on the portal, subscribers have little or no real control over where information relating to their preferences is kept, what information is gathered about their usage habits, or what parties have access to that information and what they choose to do with it. This raises some rather serious privacy concerns. 5. Since content is personalized at the content source, the applicability of delivered content is severely restricted to at best a tiny fraction of the overall subscriber audience. This restriction is due to the fact that compromises are made in representing a relatively huge subscriber base with a small number of parameters that represent each subscriber. This means that Barbir, et. al. Expires May 10, 2002 page [10] Internet-Draft OPES FSP November 2001 the increase in performance nominally provided by caching proxies and other intermediaries is largely negated. 6. As usage increases, the incremental cost in infrastructure at the content source to maintain acceptable levels of performance and reliability increases rapidly. Such infrastructure includes replication of servers and content storage bolstered with load balancers and other "data center"/networking equipment to cater to increased capacity requirements needed to meet the performance and reliability criteria. 3.2 Service Personalization at the User Agent On the other end of the spectrum (and the content path), one could consider personalizing content strictly at the user agent. This has some advantages over the first option. Subscriber preferences and other information are stored at the user agent, addressing some of the more serious privacy concerns of the first option. Also, delivered content will be generic in nature, allowing for more efficient use of cache technologies. However, these advantages are offset by several critical drawbacks: 1. Little or no subscriber information is available at the content source. This precludes virtually any subscriber-specific application layer functionality from being used on delivered content at the content source. This is potentially crippling for the content owners, as it prevents them from providing even the most basic level of subscriber awareness to the back-end application layer. This restriction alone makes this a trivially valuable and unrealistic option. 2. The content services available to the subscriber are entirely determined by the available functionality and capabilities of their access device. In many cases (e.g. mobile phones and handheld PDAs being prime examples), this restriction is prohibitive. Not only do such devices have extremely limited computing and display capabilities, but also they are often unable to make use of large parts of delivered content. A mobile phone, for example, may not even be able to display straightforward HTML, let alone high quality images, streaming media, or active content technologies. This means that the subscriber is left with virtually useless content. Since the rest of the content path is completely oblivious to the limitations of such access devices, very large quantities of useless data will be transferred across the network, increasing congestion, and adversely affecting the performance and reliability of the network as a whole. 3. Should the personalization solution be restricted to those access devices that are capable of providing meaningful content services, a large segment of potential subscribers will be unable to take advantage of the added value that personalization delivers. Consequently, such a solution would be of marginal value. NOTE: Perhaps some commentary about benefits of this scenario should be added. Example on benefits: In the case of a certain subset of the subscriber class - user agents on powerful desktops/laptops with enough compute, storage and network connectivity û bandwidth etc û resources, personalization at the access Barbir, et. al. Expires May 10, 2002 page [11] Internet-Draft OPES FSP November 2001 device may not be a bad option. In fact, many of the personalization functions can be "offloaded" to these user agents from the content portals; think of these user agents as running extensions/"avatars" of the portal/content source. Then, these user agents can transmit relevant subscriber information back to the portals/sources providing them with subscriber information. 3.3 Service Personalization at the Network Edge The network edge, where the subscriber access network meets the rest of the Internet, presents a somewhat more promising potential location for the implementation of personalization services. Several clear advantages exist over the scenarios previously discussed. 1. A trust relationship already exists between the subscriber and their ISP. The ISP is already responsible for authenticating the user, authorizing their access to the Internet, and gathering accounting data related to their service usage. Furthermore, by necessity, the ISP has pre-existing facilities for storing and securing subscriber-specific data, and for guaranteeing an agreed-upon level of privacy. 2. Since content is personalized at the network edge, subscribers will benefit from the increased performance provided by caching proxies and other acceleration technologies. This will significantly reduce network traffic and congestion. 3. The applicability of cached content when servicing requests from multiple subscribers is increased because personalization occurs after content is retrieved from source. 4. Content sources will be able to provide higher levels of throughput at reduced costs because the computations required to personalize content have been off-loaded, and content output required from the content source may be greatly diminished as there are fewer clients (network edge devices) that need to be served than the typically large numbers of end user devices. 5. Because personalization services are being provided on network devices located at the network edge, better control over Quality of Service (QoS) can be achieved. NOTE: In scenarios where the access network is invariably the bottleneck link (e.g. wireless telecom networks where a combination of mechanisms [diffserv] and over provisioning are used to provide service assurances in the wired part of the end-to-end path), if the edge device is located one network hop away from the wireless client, it will enable the device to learn the status of the network and take appropriate actions in a timely manner. Editor Note: we need to be consistent on the use of "intermediary" vs "edge device"; the section 3.4 below defines intermediaries as different from edge devices; however, there are usages of these terms which are interchangeable elsewhere in the document? Barbir, et. al. Expires May 10, 2002 page [12] Internet-Draft OPES FSP November 2001 Editor Note 1: Satisfying the QoS requirements of a user requires network-wide mechanisms as the bottlenecked link can be anywhere on the content path. Therefore, in general, we need a feedback loop running between a client and server of a flow. However, it is possible in some engineered scenarios, especially in networks with wireless links that the bottlenecked link is in the last hop. In such cases alone, the above point may be valid. One interesting deployment would be to install two intermediaries, one near the client and one near the server, in effect establishing an edge-to-edge feedback system providing a range of services that impact the perceived QoS by the client. (Note: There are multiple "edges" in the network and every content "hop" is potentially an edge location. As such, there are opportunities to position intermediaries at these multiple edges along the way). This idea deserves more careful examination. Editor Note 2: It could be argued that QoS assurance or guarantees is a content service and as such is not a part of core personalization functionality. 3.4 Service Personalization at Intermediaries Editor Note:This is where we need to draw attention to the existing/proposed work and drafts in OPES, centered around proxy caches etc. ) Network devices on the content path between the client and the content source are known as intermediaries. Network edge devices, while technically intermediaries are covered separately in the previous section. The remaining intermediaries include two types of commonly used devices that are of particular interest as potential personalization service platforms. These are caching proxies, and surrogates. Both of these types of intermediaries have certain advantages over previously discussed alternatives. However, they also present added complications, most noticeably in the areas of privacy and security. 3.4.1 Service Personalization at Caching Proxies Caching proxies, due to their role and placement in the network, have some added advantages over network edge devices as platforms for personalization services. Specifically: 1. Because caching proxies reside at various points in the "core" of the Internet, but close to the network edge, they are ideally placed to provide personalization services which are not tied to a specific service provider, while still minimizing network traffic to content sources. 2. Caching proxies, by their very nature, already have built-in functionality for examining network traffic and making decisions based on the nature of that traffic (i.e. deciding whether or not to cache a given piece of content). 3. Standardized, well-defined interfaces exist for controlling the lifecycle of cached content, including deletion, replacement, and expiry of cached content. Barbir, et. al. Expires May 10, 2002 page [13] Internet-Draft OPES FSP November 2001 4. Because caching proxies potentially service subscribers from many ISPs, their audience is much larger. This means that algorithms for selectively caching certain personalized variants of content can be contemplated since a larger audience increases the probability that multiple subscribers will express similar or identical preferences. For example, if a caching proxy is located in France, the likelihood that multiple subscribers will request content translation into French is quite high. This fact has the potential to allow for significant increases in performance and overall quality of the subscriber experience. Editor Note: Contrast these with the statements made in Sec 3.1, item 5. 5. Well-understood network engineering techniques and technologies exist to scale the capacity of caching proxies to handle very large numbers of concurrent subscriber requests efficiently. The return on investment in such equipment is significantly higher than for either content sources or network edge devices, and the incremental improvements in performance and reliability are effective for a larger audience of subscribers. These added advantages are offset by some complications and considerations that must be addressed: 0. Caches are meant to speed up delivery of content to the devices and any additional processing at these devices impact in the content delivery process. Since personalization is performed per subscriber, the performance impact is potentially large enough to raise concerns on the very purpose caches are meant for û web acceleration. 1. There is no pre-existing trust relationship between subscribers and caching proxies. Because caching proxies do not necessarily fall under the administrative domain of the ISP or access network, the facilities provided by the network edge for authentication and authorization do not cover these devices. Because personalization services require subscriber-specific information as to their preferences and policies, there is an increased risk of tampering and/or invasion of subscriber privacy in transferring such information to a caching proxy. 2. This means that a mechanism must exist for authenticating a caching proxy's identity and authorizing its access to subscriber profile information. 3. No matter what the type of connectivity between the access network and the caches, steps must be taken to ensure that any transfer of subscriber profile information is secure. 4. Caching proxies, by design, are intended to operate transparently to the end user. Since personalization involves the potential modification, filtering, or other adaptation/alteration of content received in response to a subscriber request, any personalization service that resides on a caching proxy must have a mechanism whereby the subscriber's explicit authorization is required to enable content adaptation. Barbir, et. al. Expires May 10, 2002 page [14] Internet-Draft OPES FSP November 2001 5. Since caching proxies' primary function is to cache data, subscribers must have some means of controlling what (if any) information contained in the subscriber profile persists on the device at any time during or after a subscriber session. 6. Once the caching proxy has retrieved subscriber information, a mechanism must exist to ensure that no access to that information is allowed by any entity save by the explicit authorization of the subscriber. 3.4.2 Service Personalization at Surrogates Surrogates exhibit many of the same characteristics as caching proxies, and present similar opportunities for optimization of personalization services as caching proxies. They also pose comparable challenges. Because of their placement near the content source, however, the specific advantages and complications are different enough to warrant closer examination. The placement of surrogates in the content path presents some unique characteristics that make them well suited to the implementation of certain kinds of personalization services: 1. Because surrogates are delegated to operate on behalf of, and often in close co-operation with one or more content sources, they provide an ideal platform for the aggregation of related content from a select set of origins. Personalization services at this point in the content path can take advantage of more efficient and practical access to back-end application layer functionality, allowing for the creation of more dynamic aggregated content, while allowing for balancing incurred load that such dynamic content incurs. 2. While the benefits that personalization services enjoy when co-located with caching proxies with respect to decreased network traffic are less significant in this scenario, surrogates do provide the widest possible audience of subscribers for a given set of content. This means that the odds of certain types personalized content variants having applicability beyond a single subscriber request or session are maximized. 3. One very common form of surrogate is the reverse proxy. Implementation of personalization services on such devices will allow for potentially large numbers of related content sources to take advantage of personalization while also leveraging existing load-balancing and scalability solutions for content sources. Because reverse proxy network topologies are themselves scalable, personalization service capacity can be scaled appropriately to meet subscriber demand for even very high traffic content sources. As with all other potential platforms for personalization services, surrogates present their own challenges and issues to be addressed. Among these are: 1. Because surrogates are closely tied to content sources, subscriber information will have to be transmitted across a significant portion of the content path over the public Internet. This makes the requirement for a secure mechanism for subscriber profile transfer, and other security and privacy considerations discussed in Section 3.4.1 even more important. Barbir, et. al. Expires May 10, 2002 page [15] Internet-Draft OPES FSP November 2001 2. Because surrogates tend to be deployed very near the content source, the incremental cost in network traffic and bandwidth significantly offsets the benefits of this approach. 3.5 Hybrid approaches to Service Personalization It is possible to envision personalization services that are distributed. That is, ones which reside on more than one of the previously discussed points in the content path. Such hybrid systems might allow for more sophisticated decision- making algorithms to be implemented. For example: If one were to install personalization services on both the network edge devices (or even the caching proxies) and the surrogates, one could establish a feedback loop, or edge-to-edge system, providing a variety of services that could affect the perceived QoS of subscriber sessions. There are many other possible combinations and benefits which could arise from such hybrid systems. Further investigation of the possibilities is recommended. 3.6 Goals of FSP FSP aims to provide a Framework and Protocols for the delivery of the optimal content variant for a given request to the requestor based on the subscriber profile and policies, and the content profile and its associated policies. The next sub-sections discuss the basic components of FSP. 3.7 Subscriber and Content Profiles Editor Note: CPExchange and its applicability to FSP. In order for FSP to be able to deliver to the subscriber the optimal content variant for their request based on the subscriber profile and policies, these profiles and policies must be able to completely describe a subscriber's personalization preferences. To this end, a precise definition must be developed that allows for the creation of a subscriber profile that also includes associated policies. The subscriber profile must also be able to be stored either in a centralized location, or be distributed across multiple locations in the Internet, including the user agent. The Composite Capabilities/Personal Preferences (CC/PP) [3] work establishes a framework for defining how subscribers may codify their device capabilities and their preferences about the use of these capabilities. CC/PP defines an RDF [3] schema and associated vocabularies for describing device capabilities and user preferences. However, a subscriber's profile may also include other components such as the QoS expected by the user and the capabilities of the access network through which the device is connected to the rest of the Internet. In addition, mobile users may have an elaborate description of how they would like their service to be adapted as resource levels change during the course of a long- running network session. A subscriber's profile must completely encapsulate all of the information about a subscriber that is needed to make any of the Barbir, et. al. Expires May 10, 2002 page [16] Internet-Draft OPES FSP November 2001 personalization decisions required for a given content request. This implies that there is the need to develop a vocabulary for encoding policies within a subscriber's profile, as well as additional preference information unrelated to device capabilities. This vocabulary forms a superset of that defined in the existing CC/PP work. The set of elements that comprise a subscriber's profile includes among others a description of the device capabilities, Quality of Service (QOS), access rate, accounting information, and content type preferences. A subscriber profile also includes policies that define what constitutes acceptable content (e.g. topic, explicit content, linked content origin, acceptable manipulations, filtering policies) that the subscriber is willing to receive. It may also contain information related to the level of service that a subscriber considers adequate; for example, trading off cost of service vs response time, accuracy etc. (Subscriber A may want to get language translation free of cost while accepting poor quality, accuracy, response time; subscriber B may be willing to pay for better accuracy, response time etc. for translation) Content profiles and policies, on the other hand, encapsulate information about the content. This includes information such as available variants at the content source, encoding method, dimensions (for graphics), etc. Content profiles and policies also include information about what is and is not allowed in terms of use or manipulation of that content (e.g. do not allow legal documents to be translated into another language, do not perform "down sampling" of higher quality multimedia/streaming content). A content provider may provide hints to a personalization intermediary in choosing the most suitable transformations to apply in some form (e.g. INFOPYRAMID provides one such representation). Content policies are an integral part of the content profile for a given piece of content. A content profile must encapsulate all of the information about the content which is needed to make any of the personalization decisions required for that content, including whether or not a given personalization transformation is allowed. RFC 2295 [4] provides the means for automatically and efficiently retrieving the best content variant from a content source in HTTP. This specification defines transparent content negotiation as an extension on top of the HTTP/1.1 protocol [10]. This work, combined with a schema and vocabulary for defining a content profile that is similar to, and consistent with the subscriber profile, could provide a sound basis for defining a more generalized, protocol-independent process for retrieving the appropriate content variant from the content source. More work will be needed to incorporate content policy enforcement into this process. 3.8 Content Selection Content selection involves choosing the most appropriate or optimal available content variant from a content source for transmission back to the subscriber. The choice of optimal content source in this context is restricted to the task of identifying the best content variant that could be adapted to suit the subscriber. This task is separate and distinct from the process of choosing the content source that is optimal from a network perspective, based on network delay, server load, or other such metrics. Barbir, et. al. Expires May 10, 2002 page [17] Internet-Draft OPES FSP November 2001 There are various criteria that can be used to determine the most appropriate content variant to retrieve from the content source. The simplest of these is choosing a variant that completely or most closely fits the subscriber's preferences. This is, however, only one possible form of content selection. In the event that there is no content variant that completely fits the subscriber's preferences, alternate content selection criteria may apply. The task of selecting the most appropriate content variant may be performed as a function of the ease of translation of the content into the appropriate format provided that the content policy allows for the needed adaptation. Here, it is important to note the distinction between "most appropriate" content to retrieve from the content source and the "optimal content" to deliver to the subscriber. In HTTP Web sites, authors are allowed to store multiple versions of the same information under a single URL. In RFC 2295 [4], Transparent Content Negotiation (TCN) is proposed as a mechanism to select the best appropriate variant of the content. The TCN mechanism is layered on top of HTTP, and provides a mechanism for automatically selecting the best content variant when the URL is accessed. However, as is discussed in section 3.7 above, further work will be needed to enhance and generalize the existing TCN architecture to leverage the capabilities enabled by the content profile. Some complementary technologies are aimed at enabling the aggregation of distributed content fragments into a customized whole at the network edge through the specification of inclusion mechanisms. Edge Side Includes (ESI) [16] represents one such technology. ESI provides a means to embed inclusion instructions into content for execution at the network edge. It also provides mechanisms for specifying conditions under which such inclusions should be made, and for invalidating content fragments that are cached at network intermediaries. This work could be enhanced to allow the specification of conditions and policies for inclusion within a subscriber profile, maximizing the effectiveness of ESI for personalization purposes. Further investigation into this area is required. 3.9 Quality of Delivery (Origin Server Selection ?) This criterion only applies in the case where there are multiple sources from which content can be obtained, and the personalization framework has some influence over the content source selection. In this case, it makes some sense to define a quality of delivery (QOD). In the case where there is only one content source from which content can be obtained, or where the personalization framework has no influence over which site gets chosen, quality of delivery reduces to whatever quality the chosen content source can deliver. Within the scope of an OPES implementation of this framework, there have been discussions on "late binding" of Rules to Actions and the Policy framework to allow essentially to select from a variety of content sources. The selection will be influenced by policies/rules stipulated on behalf of the end user/subscriber. At this point this topic will be left unexplored in the interests of clarity of discussion within OPES. Barbir, et. al. Expires May 10, 2002 page [18] Internet-Draft OPES FSP November 2001 3.10 Privacy and Security Privacy issues are an important component of personalization. In this regard, the issues of privacy that are related to shopping habits, the willingness to accept or refuse certain type of advertisement, and subscriber profiling are already addressed by the Platform for Privacy Preferences (P3P) [11] at W3C. It is important to note that while P3P provides a technical mechanism to ensure that the subscriber is informed of the privacy policy of a content source, it does not specify any mechanism for policy enforcement. This is an area in which FSP may play a role in strengthening the enforcement of privacy policies. Editor Note: Through request anyonymization, we may be able to prevent the content source from gathering metrics that are undesirable to the subscriber. We have to be careful here, however, because this will not make some content providers happy. Additionally, anonymization is really more of a content service than it is core personalization. Maybe what we have is a selective anonymization based on privacy policy enforcement during personalization. We may wish to investigate the technical feasibility of this idea. Editor Note: The above should not be a major issue as (1) P3P will be a fact of life. (2) Personalization can be denied for anonymous requests? In performing personalization, there should be a mechanism that ensures that the transition of a subscriber profile across the Internet is done in a secure and reliable manner. Furthermore, there should be a mechanism that authorizes any entity that is interested in accessing a subscriber profile. In general, security considerations for personalization must address the following issues: - Subscriber Profile Integrity: FSP must ensure that a subscriber profile is unadulterated in whole or in part when it reaches a decision point. - Content Profile Integrity: FSP must ensure that a content profile is unadulterated in whole or in part when it reaches a decision point. - Trust Relationships: There must be a proper mechanism that decides the entity that is authorized to configure, update, change, and delete a subscriber profile. There must be a proper mechanism that authorizes any entity that will perform personalization across the content adaptation chain. This includes trusted third parties and repositories. - Non-repudiation of request: Non-repudiation of any subscriber profile configuration/update/change/deletion may be required. Barbir, et. al. Expires May 10, 2002 page [19] Internet-Draft OPES FSP November 2001 - Data Confidentiality: Preventing eavesdroppers from gaining access to a subscriber profile is important. Note that this requirement is different from subscriber privacy. 4. Security Threats and Mechanisms Section 3.10 described several security requirements for FSP. In this section, we provide a threat analysis for FSP, and discuss trade-offs between different security mechanisms/solutions. 4.1 Threat Analysis In this section, we describe a set of threats, their effect on the system, and the corresponding requirement in order to combat the threat. 4.1.1 Malicious entity accesses subscriber profile Threat: A malicious entity is able to access a subscriber profile. Effect: A subscriber's privacy is compromised. Requirement: Any access to subscriber profile has to be authorized. 4.1.2 Malicious entity modifies subscriber profile Threat: A malicious entity is able to configure/modify/delete a subscriber profile. Effect: The stored subscriber profile is different from that which the subscriber desires. Requirement: There are two scenarios by which a malicious entity may modify a subscriber profile - one in which the configuration/modification/deletion request is originated by the malicious entity, and the other in which an authorized entity issues the configuration/modification/deletion request which gets modified by the malicious entity in transit. In order to tackle the first scenario, any configuration/modification/deletion of subscriber profile has to be authorized. To tackle the latter case, additionally, integrity protection of such requests also needs to be provided. 4.1.3 Eavesdropping on a subscriber profile in transit Threat: An unauthorized entity eavesdrops on a request to configure/update/modify a subscriber profile Effect: The subscriber's privacy is compromised. Requirement: Data confidentiality of such requests is needed. Barbir, et. al. Expires May 10, 2002 page [20] Internet-Draft OPES FSP November 2001 4.1.4 Malicious entity accesses content profile Threat: A malicious entity is able to access a content profile. Effect: Certain content meta-data that the content owner does not wish to divulge to unauthorized entities may be divulged. Potential attackers may also be able to exploit such information to launch more sophisticated attacks. Requirement: Any access to content profile has to be authorized. 4.1.5 Malicious entity modifies content profile Threat: A malicious entity is able to configure/modify/delete a content profile. Effect: The stored content profile is different from that which the content owner desires. Requirement: There are two scenarios by which a malicious entity may modify a content profile - one in which the configuration/modification/deletion request is originated by the malicious entity, and the other in which an authorized entity issues the configuration/modification/deletion request which gets modified by the malicious entity in transit. In order to tackle the first scenario, any configuration/modification/deletion of content profile has to be authorized. To tackle the latter case, additionally, integrity protection of such requests also needs to be provided. 4.1.6 Eavesdropping on a content profile in transit Threat: An unauthorized entity eavesdrops on a request to configure/update/modify a content profile Effect: Certain content meta-data that the content owner does not wish to divulge to unauthorized entities may be divulged. Potential attackers may also be able to exploit such information to launch more sophisticated attacks. Requirement: Data confidentiality of such requests is needed. 4.1.7 Authorized entity later repudiates a request Threat: An entity that is authorized to make a certain request claims at a later time that it did not make that request. Effect: The maintainer of the database of subscriber profiles may be held liable for unauthorized changes to a subscriber profile. Similarly, the maintainer of the database of content profiles may be held liable for unauthorized changes to a content profile. Requirement: Non-repudiation of requests for configuring/modification/deletion of subscriber and content profile needs to be provided. Barbir, et. al. Expires May 10, 2002 page [21] Internet-Draft OPES FSP November 2001 4.2 Security Mechanisms One or more appropriate security mechanisms need to be employed in order to combat the various threats to a FSP system, and to meet the requirements described earlier. Below, we give a comparison of some of these mechanisms: 4.2.1 Application layer security designed for FSP Application layer mechanisms have the advantage of being tailor-made for the purpose, and hence can be more efficient than other general-purpose mechanisms. However, care needs to be taken to ensure that the mechanisms devised are indeed secure. 4.2.2 S/MIME and PGP Mechanisms such as S/MIME and PGP could be used for providing security services to the application. These mechanisms provide a wide range of security services - authentication, integrity, confidentiality and non-repudiation. 4.2.3 TLS The Transport Layer Security (TLS) may be used when the underlying transport is a reliable one. Hence, TLS can be used with TCP but not with UDP. 4.2.4 IPSec IPSec provides two headers - Authentication Header (AH) and Encapsulating Security Payload (ESP) - in order to provide several security services at the IP layer. Since these security services are provided at the IP layer, the transport protocol or the application itself is immaterial to IPSec. 5. Acknowledgments The majority of the definitions contained in this document have been obtained from the document entitled: "A Model for Open Pluggable Edge Services", by G. Tomlinson, et al. [14]. This contribution is greatfully acknowledged. The authors wish to acknowledge the comments and suggestions contributed by the members of the FSP mailing list. These people include: Raffi Uddin, Wil Walcoe, Ram Dantu. 6. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March, 1997. [2] A. Beck et al, "Example Services for Network Edge Proxies", draft-beck-opes- esfnep-01.txt (word in progress), June 2001 [3] G. Klyne, F. Raynolds, C. Woodrow, H. Ohto, "Composite Capabilities/Preferences Profiles (CC/PP): Structure and Vocabularies", March 15, 2001. http://www.w3.org/Mobile/CCPP/. Barbir, et. al. Expires May 10, 2002 page [22] Internet-Draft OPES FSP November 2001 [4] K. Holtman and A. Mutz, "Transparent Content Negotiation in HTTP", RFC 2295, March 1998. [5] Penno, R., "Identification of Users on the Internet", draft-penno-uid- 00.txt. Work in progress, January 2001 [6] Penno, R and G. Boissonnard, "Framework User Profile Information Protocol", draft-framework-upif-00.txt. Work in progress, June 2001 [7] Penno, R., and H. T. Pham, "User Profile Information Protocol", draft-penno- cdnp-nacct-userid-05.txt. Work in progress, July 2001 [8] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [9] Calhoun, P., Rubens, A., Akhtar, H., and Guttman, E., "The DIAMETER Base Protocol," draft-calhoun-diameter-17.txt, a work in progress. [10] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997. [11] Platform for Privacy Preferences (P3P1.0) Specification, http://www.w3.org/TR/2000/CR-P3P-20001215. [12] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Perry, J., Herzog, S., Huynh, A., Carlson, M. and S. Waldbusser, "Policy Terminology", draft-ietf-policy-terminology-03.txt (work in progress), April 2001, http://www.ietf.org/internet-drafts/draft-ietf-policy-terminology-03.txt. [13] Cooper, I., Melve, I. and G. Tomlinson, "Internet Web Replication and Caching Taxonomy", RFC 3040, January 2001, http://www.ietf.org/rfc/rfc3040.txt. [14] Tomlinson, G., Chen, R. and M. Hofmann, "A Model for Open Pluggable Edge Services", draft-tomlinson-opes-model-00.txt (work in progress), July 2001, http://www.ietf.org/internet-drafts/draft-tomlinson-opes-model-00.txt. [15] Day, M., Cain, B., Tomlinson, G. and P. Rzewski, "A Model for Content Internetworking", draft-day-cdnp-model-06.txt (work in progress), June 2001, http://www.ietf.org/internet-drafts/draft-day-cdnp-model-06.txt. [16] Tsimelzon, M., Weihl, B. and L. Jacobs, "ESI Language Specification 1.0", (M. Nottingham, ed.), 2001, http://www.esi.org/language_spec_1-0.htm. [17] Barbir et al, "Requirements for an OPES Service Personalization Callout Server, draft-barbir-opes-spcs-00.txt (work in progress) November 2001. Barbir, et. al. Expires May 10, 2002 page [23] Internet-Draft OPES FSP November 2001 7. Author's Addresses Abbie Barbir, Ph.D. Nortel Networks 3500 Carling Avenue Nepean Ontario K2H 8E9 Canada Email: Abbieb@nortelnetworks.com Nicholas Bennett Nortel Networks 3500 Carling Avenue Nepean Ontario K2H 8E9 Canada Email: nbennett@nortelnetworks.com Reinaldo Penno Nortel Networks, Inc. 2305 Mission College Boulevard Building SC9-B1240 San Jose, CA 95134 Email: rpenno@nortelnetworks.com Rama R. Menon Intel Corporation 2111 NE 25th Avenue M/S JF3-206 Hillsboro, OR 97124 Email: rama.r.menon@intel.com Hien-Thong Pham Alcatel Bell Francis Wellesplein 1 B-2018 Antwerp BELGIUM Phone: 3-2408630 Email: hien-thong.pham@alcatel.be Senthil Sengodan, Ph.D. Nokia Research Center 5 Wayside Road Burlington, MA 01803 Tel: 781-993-3789 Fax: 781-993-1907 Email: senthil.sengodan@nokia.com Jayanth P. Mysore Network and Infrastructure Research Laboratory Motorola Labs 1301 E. Algonquin Road Schaumburg, IL 60196 Email: jayanth@labs.mot.com Barbir, et. al. Expires May 10, 2002 page [24] Internet-Draft OPES FSP November 2001 8. Full Copyright Statement Copyright (C) The Internet Society (2001). 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. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. Barbir, et. al. Expires May 10, 2002 page [25]