OPES Working Group A. Barbir Internet Draft N. Bennett Document: draft-barbir-opes-spcs-03.txt R. Penno Nortel Networks H. T. Pham R. Menon Alcatel Intel J. Mysore S. Sengodan Motorola Nokia March 2003 Requirements for an OPES Service Personalization Callout Server Status of this Memo This document is an Internet-Draft and is subject to 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 (2003). All Rights Reserved. Abstract This document provides the requirements for implementing a Framework for Service Personalization (FSP) in OPES intermediaries. This document provides a summary of modifications and required protocols that need to be supported by OPES intermediaries in order to allow for the development, deployment, and execution of a Service Personalization (SP) call-out server. Internet-Draft draft-barbir-opes-spcs-03.txt March 2003 OPES Service Personalization Callout Server Table of Contents Status of this Memo................................................1 Abstract...........................................................1 Conventions used in this document..................................3 1. Introduction....................................................3 2. Definitions and Terminology.....................................4 3. Overview of Service Personalization............................9 3.1 Subscriber Profile............................................10 3.2 Content Profile...............................................10 3.3 Content Selection.............................................11 3.4 Quality of Delivery (Origin Server Selection).................11 4. OPES Personal Content Services Call-out Server.................12 4.1 Requirements for an OPES SP Call-out Server...................14 4.1.1 Ability to identify a client/subscriber.....................14 4.1.1.1 Subscriber Sessions.......................................14 4.1.2 Protocol to communicate Subscriber Profile..................14 4.1.3 Protocol to communicate Content Profile.....................15 4.1.4 Storage Requirements for Subscriber/Content Profile.........16 4.2 OPES SP Physical Boundary.....................................17 4.3 OPES SP Sequence of Operations................................17 4.4 Content Services..............................................18 4.4.1 Service Characterization....................................19 4.4.2 Service Availability........................................19 4.4.3 In-Path Services............................................19 4.4.4 Out-of-Path Services........................................19 4.4.5 Service Selection...........................................19 4.4.6 Service Reliability/Service Failure.........................19 4.5 Privacy and Security..........................................19 5. Example of a SP Call-out Server................................20 5.1 Personalization Requirements from OPES Framework..............21 5.1.1 User Profile Integrity and Security.........................21 6. Security Considerations........................................21 6.1 Security Considerations for SP Scenario.......................22 7. Acknowledgments................................................22 8. References.....................................................23 9. Authors' Addresses.............................................23 10. Full Copyright Statement......................................25 Barbir, et al. Expires September 2003 [Page 2]
Internet-Draft draft-barbir-opes-spcs-03.txt March 2003 OPES Service Personalization Callout Server Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119]. 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 help to identify the subscriber. Portals perform subscriber profiling by tracking their habits and preferences. In order to be able to create accurate subscriber profiles, the portals rely on co-located subscriber identification and profiling from participating web sites. Major drawbacks of current personalization schemes are their reliance on origin web servers to perform the personalization tasks. The approach requires content providers to store and manage different content for different subscribers. Current schemes lead to scalability and optimality issues. This is because the personalization task is done based on incomplete information about the subscriber. In particular, content provider may not be aware about many types of information about the subscriber. Such information includes: geographic location, QoS policy, device type, and access rate. The lack of such information could dramatically decrease the efficiency of any personalization task undertaken on behalf of the subscriber. A potential solution to the above problem is to shift the 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. In particular, performing personalization at the edge of the network has the following advantages: 1) Devices are closer to the edge, whereby better control over Quality of Service (QOS) can be achieved. 2) Personalization can occur on cached objects thus reducing the traffic across the network. 3) The subscriber may have better trust when dealing with the local Internet provider. 4) The same service provider can handle authorization and accounting. 5) Content transformation and adaptation functions are off-loaded from the content source, reducing server load. In [OPES-FSP], a Framework for performing personalization services (FSP) was introduced. It aims to provide a Framework and Protocols for the delivery of optimal content variant for a given request Barbir, et al. Expires September 2003 [Page 3]
Internet-Draft draft-barbir-opes-spcs-03.txt March 2003 OPES Service Personalization Callout Server based on subscriber profile and policies, and content profile and policies. FSP defines the essential components and mechanisms that are needed in order to provide high quality personalized services to subscribers in a secure and reliable manner. This document establishes the requirements for developing an OPES Service Personalization (SP) call-out server. The document is organized as follows: section 2 defines the terms used throughout the document; section 3 provides a summary of SP, while section 4 discusses the implementation of an OPES SP call-out server. GENERAL NOTES: - How to get SP to know which services are available/configured for a given OPES intermediary, and how to invoke them? (rule module generation) - Does the user have any say on which services providers are used for which services? Does the content provider? What are the security issues if we do allow such configurability? 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] and [RFC-3040], 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 [RFC-3040] 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 [ESFNEP] of the party, or it may be a collection of administrative domains in which the party rights have been delegated. CACHE (REFERENCE DEFINITION [RFC-2616]) 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 September 2003 [Page 4]
Internet-Draft draft-barbir-opes-spcs-03.txt March 2003 OPES Service Personalization Callout Server CACHING PROXY (REFERENCE DEFINITION [RFC-3040]) 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 [RFC-2616]) A program that establishes connections for the purpose of sending requests. CONDITION A form of a policy condition [POLICY] that is an expression, which is used to determine whether a 'rule' 'action' should be executed. CONFIGURATION PATH 'Rule modules' and 'OPES service modules' are downloaded into an 'OPES admin server' from 'rule authors' and 'proxylet providers', respectively, and then distributed to the 'OPES intermediary'. This flow is referred to as the configuration path, since the data being transferred along this path is used to provision the 'OPES intermediaries' for service. 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'. Barbir, et al. Expires September 2003 [Page 5]
Internet-Draft draft-barbir-opes-spcs-03.txt March 2003 OPES Service Personalization Callout Server EDGE SERVICE NETWORK An 'overlay network' of 'intermediaries' layered onto an underlying content network [C-MODEL] that incorporate 'content services' that operate on messages flowing through the 'content path'. 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 [C-MODEL]. 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. 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'. Barbir, et al. Expires September 2003 [Page 6]
Internet-Draft draft-barbir-opes-spcs-03.txt March 2003 OPES Service Personalization Callout Server ORIGIN SERVER (REFERENCE DEFINITION [RFC-2616]) The server on which a given resource resides or is to be created. 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. OVERLAY NETWORK A set of connected network elements layered onto existing underlying networks, and presented as a virtual application layer to both 'clients' and 'origin servers'. 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 [POLICY]) A logical entity that makes policy decisions for itself or for other network elements that request such decisions. POLICY ENFORCEMENT POINT (REFERENCE DEFINITION [POLICY]) 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'. Barbir, et al. Expires September 2003 [Page 7]
Internet-Draft draft-barbir-opes-spcs-03.txt March 2003 OPES Service Personalization Callout 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. ROLE (REFERENCE DEFINITION [POLICY]) 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 [POLICY] 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 [POLICY] that contains a set of 'rules' and information about the rule module owner. Barbir, et al. Expires September 2003 [Page 8]
Internet-Draft draft-barbir-opes-spcs-03.txt March 2003 OPES Service Personalization Callout Server SP 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'. 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 [RFC-3040]) 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. Where close co-operation between origin servers and surrogates exists, this enables modifications of some protocol requirements, including the Cache-Control directives in [RFC-2616]. 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 [RFC-2616] 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. Overview of Service Personalization Barbir, et al. Expires September 2003 [Page 9]
Internet-Draft draft-barbir-opes-spcs-03.txt March 2003 OPES Service Personalization Callout Server The details of FSP are given in [OPES-FSP]. In this section a brief overview of the Framework for Service Personalization (FSP) is provided. The end goal of any personalization effort is to enable content services on network traffic in a personalized manner. Content services are application-level services that provide added value to content over simple content delivery. 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 either directly or indirectly which services should be applied to their traffic stream, and under what circumstances. In general, personalization can occur at any point in the network that has access to the request, the content, the content profile, and the subscriber profile. Essentially, any point in the content path is a potential point at which personalization decisions could be made. The next sub-sections summarize the basic components of FSP. 3.1 Subscriber Profile In order for SP to be able to deliver to the subscriber an 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 network, including the user agent. The set of elements that comprise a subscriber's profile includes among others a description or a reference to 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. 3.2 Content Profile 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). A content provider may provide hints to a personalization intermediary in choosing the most Barbir, et al. Expires September 2003 [Page 10]
Internet-Draft draft-barbir-opes-spcs-03.txt March 2003 OPES Service Personalization Callout Server 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. 3.3 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. 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 [OPES-FSP]. 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. Editor Note: Expand the notion to the case when there is no content variant. 3.4 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. Editor Note: This section needs a bit of rewrite. Here, QoD has more than just availability of a variety of content sources with the same content represented in different quality levels - example: streaming media content at different bit rates and encoding quality levels. It also has to do with other parameters like (1) what is a subscriber's best access bandwidth (2) is there a cost issue (free vs. paid content) (3) policies in place by content source/provider vs. those Barbir, et al. Expires September 2003 [Page 11]
Internet-Draft draft-barbir-opes-spcs-03.txt March 2003 OPES Service Personalization Callout Server by the subscriber (4) device characteristics - same subscriber accessing same content from different user agent devices etc.) 4. OPES Personal Content Services Call-out Server The Open Pluggable Edge Services (OPES) framework enables the creation and provisioning of services executed on application data by participating transit intermediaries. The OPES system architecture supports the definition of a SP call-out server that could be responsible for performing personalization tasks. Such a server would overcome most of the technical challenges mentioned as barriers in [ESFNEP], and would be able to provide extensible services such as virus scanning, ad insertion, caching of personalized web pages, limited client bandwidth adaptation, request filtering, and creation of subscriber profiles on a per-subscriber basis. Figure 1 shows a diagram of the main components of the OPES framework, with the addition of a SP call-out server. In the diagram, the SP call-out server is represented as a separate entity. This arrangement allows a SP call-out server to perform personalization services for multiple OPES Engines, or for a single OPES Engine to balance personalization traffic between multiple SP call-out servers. From an architectural standpoint, it would also be possible for the OPES Engine and/or the OPES admin server to be modified to act as a SP call-out server. This option would, however, severely limit the scalability of the SP call-out server from an implementation perspective. Editor note 1:(1) the way components are laid out below, it appears as if the communications between the user agent and the SP call-out server is direct (i.e., after initial request made through the OPES Engine, someone (OPES Engine?) redirects the user agent to the SP callout server. This may be OK, as the OPES Engine does not need to be in the "data path" for every user agent after the initial request is made for content. Editor note 2: The notion that SP callout server may be implemented in the same "box" (system) as the OPES Engine is fine with a small number of subscribers and no other/few other callout services or proxylets running on the OPES Engine. For scalability, a separate SP callout server makes sense, depending on the complexity of personalization processing. NOTE: We need to clarify this diagram to explicitly show potential locations for the implementers of the supplementary services, with examples. Also, we need to modify this and/or add a new diagram which shows the control path connections between the OPES engine/admin server and the SP call-out server. Barbir, et al. Expires September 2003 [Page 12]
Internet-Draft draft-barbir-opes-spcs-03.txt March 2003 OPES Service Personalization Callout Server +-----------+ +--------------+ | Rule | | Proxylet | | Owner | | Vendor | +-----------+ +--------------+ A | | A | | | | | V V | +--------------------+ | OPES | | Admin Server | +--------------------+ UPIF A | +-----------+ | | | +-------+ | | V | | | | +------------------+ | | | V | OPES | | | +-----------+ | Engine | CPIF +------------+ | | | User |----->|--- --------------|----->| Content | | | | Agent |<-----| |<-----| Server | | | +-----------+ | | +------------+ | | | Intermediary | | | +-----------+ | | | | | Call-out | | | | | | Server | | | | | | | +------------------+ | | +-----------+ A | A | | | A | | | | | | | | +------------+ | | | | | +---------------------+ | V | | +-------------------------------+ | | | SP Call-out Server | | | | | | | | +------------------+ | | | | | SP Rule | | | | | | Owner/Generator | | | | | +------------------+ | | | +-------------------------------+ | | A | | +--------------------------+ | +-------------------------------+ Figure 1 - OPES SP System Architecture Components NOTE: The components in Figure 1 may belong to different administrative domains. Some modifications to the original OPES architecture must be made to enable support of a SP call-out server. The next sub-sections summarize the requirements on the OPES framework. Barbir, et al. Expires September 2003 [Page 13]
Internet-Draft draft-barbir-opes-spcs-03.txt March 2003 OPES Service Personalization Callout Server 4.1 Requirements for an OPES SP Call-out Server This section discusses the added features that must be supported by the OPES framework to support a SP call-out server. An OPES SP call-out server performs the task of generating dynamic rules that are either encoded in, or extracted from a subscriber and content profile. The server must be capable of retrieving a subscriber profile from centralized or distributed locations across the Internet. The server must be capable of loading the rules onto an OPES engine in a dynamic fashion. The server may be capable of downloading of proxylets and rules from other parties at a higher trust level. The server must perform authorization and authentication for services, and other administrative tasks specific to personalized services on OPES intermediaries. 4.1.1 Ability to identify a client/subscriber In order for the OPES framework to support personalization, it is required that an OPES engine be able to identify the beginning of a traffic stream that is SP-enabled. It is assumed that the personalization of data streams is performed on a per session basis. Thus, at the beginning of a session, the OPES engine must recognize that the traffic is SP-enabled. The rules within the OPES engine must be able to relate the traffic to a certain subscriber and assign a special tag that uniquely associates the traffic with the subscriber. The SP call-out server uses this tag to locate and retrieve the subscriber profile. Editor Note: What about Session-less? The draft by Penno et al. [UID] proposes various schemes for identifying a subscriber on the Internet. This draft can be used as a starting point in developing a uniform scheme that can be used by OPES engines to identify the beginning of a personalized session for a given subscriber. The draft entitled "User Profile Information Protocol" [UPIF] addresses this issue from an implementation perspective. Much of the work contained in the draft is applicable to the SP effort. 4.1.1.1 Subscriber Sessions The OPES engine must be able to identify the beginning and end of a personalized subscriber session. At the session startup and termination, the OPES engine must inform the SP call-out server about the subscriber identity. At the termination of the session and at the command of the SP call-out server, the OPES engines must delete any dynamic rules related to the subscriber. 4.1.2 Protocol to communicate Subscriber Profile Barbir, et al. Expires September 2003 [Page 14]
Internet-Draft draft-barbir-opes-spcs-03.txt March 2003 OPES Service Personalization Callout Server In order for a SP call-out server to be able to provide personalization services, a protocol is needed that can retrieve the subscriber profile in a reliable and secure fashion. The protocol must meet the following requirements: 1) The protocol must provide several security services - including user authentication for read/write purposes, integrity of request/response messages, user non-repudiation for write purposes, and data confidentiality of request/response messages. 2) The protocol must be reliable. 3) The protocol must be able to retrieve a subscriber profile that is stored in a distributed fashion across the Internet. 4) The protocol may be able to support accounting services. In this regard, the draft by Penno et al. [UPIP] proposes a User Profile Information Protocol (UPIP) that could be used by the OPES SP call-out server to retrieve the subscriber's profile. The UPIF protocol could be defined as an extension of RADIUS [RFC-2866] or Diameter [DIAMETER] in order to provide the needed security, authorization and accounting capabilities. The work that Penno et al. have done on the "User Profile Information Protocol" (UPIP) in [UPIF] represents one possible implementation of these ideas, which may be applicable to an OPES based personalization call-out server (SPCS). 4.1.3 Protocol to communicate Content Profile In order to perform personalization services some content may need to be adapted to better suit a given subscriber preferences. However, certain content can exist in various variants. The quality of the adaptation of the content is highly dependent on the original format of the content. Additionally, not all content may be adapted or modified. This is due to the digital rights that are associated or imposed on the content by the original providers and authors. NOTE: These remarks are applicable to the underlying OPES framework, and perhaps are best addressed there, since Digital Rights Management (DRM) will form an essential part of any architecture that proposes to perform any modifications or adaptation on original content. Editor Note 1: Should DRM issues specific to personalization be mentioned? For instance, a user A who has viewed some content on one device type (say, a PC) could have the rights to view it on a different device type (say, a mobile phone). But, a user B may not have such privileges. When users are classified into categories, this can be included in the content profile. I.e., the content Barbir, et al. Expires September 2003 [Page 15]
Internet-Draft draft-barbir-opes-spcs-03.txt March 2003 OPES Service Personalization Callout Server profile could state that if the user is a gold user, some things can be done. But if the user is a silver user, a more restricted set of personalization can be done. Editor Note 2: Need to describe in more detail what Content Profile (Content Metadata) is; what the various representations of Content Profile are in use today (little?), which proprietary or standard forms exist etc.) In order to perform high quality personalization of the content, the adaptation process must be able to match the subscriber requirements or preferences with the availability of various content variants, and the policies regarding their use. Only then the needed set of transformations on the content could be fully identified. Therefore, an OPES engine must support a Content Profile Information Protocol (CPIF) that is capable of retrieving content profile that encapsulates this information. Requirements for this protocol are similar to those for the UPIF protocol. The support of CPIF by content providers requires changes be made to the way content is stored on servers. It is most probable that the rate of adoption of any new content storage scheme by content providers will be slow. For this reason, the SP framework will proceed with the assumption that the CPIF protocol for the immediate future will be non-existent, and that only a limited subset of the information that could potentially be encoded in a content profile will be available. It is likely that a large part of this content information will have to be inferred during the content retrieval process. On the other hand, it is possible for content providers to publish content profiles and store them in a unique location on the Internet. The profiles can then be accessed by the OPES based personalization call-out server. OPES based authorization schemes can be used to restrict access to legitimate entities to the content profiles. 4.1.4 Storage Requirements for Subscriber/Content Profile The subscriber/content profile may be stored partially or completely in the terminal or the network. The entity that is responsible for the storage may be a third-party entity _ especially when the profile is stored in the network. Some desirable features of such storage include: - The entity that owns the storage does not have access to the subscriber/content profile. This implies that the entity does not have to be trusted. - The entity that owns the storage does not have to store the password (or any shared secret) associated with the subscriber/content owner. This requirement is automatically implied when the first requirement is needed. However, this Barbir, et al. Expires September 2003 [Page 16]
Internet-Draft draft-barbir-opes-spcs-03.txt March 2003 OPES Service Personalization Callout Server requirement is desirable even when the first requirement is not needed, i.e., in the presence of a trusted third party. 4.2 OPES SP Physical Boundary The OPES admin server, OPES engines and SP call-out servers represent separate logical components in the SP architecture. The OPES admin server is off the content path. The involvement of the SP call-out server in the data flow is limited to the beginning of a personalized session, with the occasional involvement when the subscriber preferences are modified within an active session. The SP call-out server is also involved in the termination of the session, whereby the subscriber related rules are deleted from the OPES engine. There are no assumptions made regarding the physical boundary between the SP call-out server and other OPES functional components. In particular, the following physical configurations are possible: - Appliance Model: The OPES admin server, OPES device and SP call- out server are built into a single appliance. - Toolbox Model: The OPES admin server, OPES devices including SP call-out server are physically separate boxes. In this case, a few admin servers can administer a large number of OPES devices and SP engines. 4.3 OPES SP Sequence of Operations This section describes the sequence of operations that are performed by the OPES SP framework as described in Figure 1 in order to support personalization. The process is described in the steps below: Editor Note: The current OPES model is not necessarily built on any "lengthier" notion of a session _ each session is merely an HTTP request/response sequence; every request from the user agent and every response from the content source to be delivered to the user agent are "tracked" and there are associated processing points (4 explicitly defined ones in the current OPES model) where potential for rule match/actions exist. 1) At the beginning of a session, the user agent must identify itself as being SP-enabled to the OPES engine. In effect, there must be some characteristic of a subscriber request which can be identified by a standard OPES rule as requiring personalization services (this may be accomplished by some request header information rule match and associated action). 2) Once a SP-enabled request is identified, the OPES engine must assign a unique identifier to the subscriber which will be used Barbir, et al. Expires September 2003 [Page 17]
Internet-Draft draft-barbir-opes-spcs-03.txt March 2003 OPES Service Personalization Callout Server to "tag" all subsequent traffic from that subscriber. This may involve transfer of identifier information back to the user agent for incorporation into subsequent communications, similar to existing key-exchange mechanisms. 3) The incoming subscriber request is then routed (using an OPES rule or rule module) to the SP call-out server for processing. 4) The SP call-out server recognizes the subscriber based on the identifier that is provided by the OPES engine. The SP call-out server will establish direct communications using UPIF or a similar protocol with the user agent to get the appropriate information on the location of the subscriber profile. Appropriate authentication schemes between the SP call-out server and the user agent may be needed. In the event that the subscriber profile is distributed across various locations on the Internet, the SP call-out server must be able to authenticate itself and any entity that is involved in the process. 5) The SP call-out server parses the subscriber's profile to either extract or derive the appropriate personalization rule module. 6) The SP call-out server then sends the personalization rule module that is associated with this subscriber to the OPES engine. The OPES engine dynamically loads and invokes the rules on subsequent traffic from the subscriber. (To make this happen, subsequent traffic needs to contain the "SP-enabled" magic word, since there is no notion of state maintained in the OPES Engine on each user agent beyond any active request/response pair.) 7) At the end of the session, the OPES engine informs the SP call- out server about the termination of the session. The SP call-out server invokes any accounting processing that is needed on the subscriber profile and then sends a command to the OPES engine to fully delete any rules that are associated with the subscriber. Editor Note: How do we exactly know when a session ends? Again, given the current HTTP request/response model, each request/response sequence is a session; or, do we unload/delete the dynamic rules the first request from a user agent that does NOT contain the "SP_enabled" magic word in the header? 8) NOTE: We haven't mentioned anything about how we know what other services are available, how we write the rules to route traffic to them as appropriate, or what happens if the subscriber profile changes in mid-session. Also, we need to address the security of the communication between the OPES intermediary and the Personalization call-out server. 4.4 Content Services Barbir, et al. Expires September 2003 [Page 18]
Internet-Draft draft-barbir-opes-spcs-03.txt March 2003 OPES Service Personalization Callout Server 4.4.1 Service Characterization This is an OPES problem, but we need to know how to characterize services in general. Perhaps it's enough to merely state that we need some form of service characterization? Perhaps use the OPES definition for service characterization wholesale? 4.4.2 Service Availability How do we know which content services are available for use from a specific SP platform? Perhaps some of these questions are best stated here, and discussed in detail within the context of OPES. 4.4.3 In-Path Services Need to figure out how to route traffic to In-Path services. 4.4.4 Out-of-Path Services How to route traffic to slower services, and how does this differ from in path services? 4.4.5 Service Selection Given one or more content services that perform a specific function, what are the criteria used to select a specific service? Is this decision-making process in any way configurable by the subscriber? Or is it configurable by the content provider? What metrics are used to make a selection between multiple providers of the same content service? 4.4.6 Service Reliability/Service Failure What happens when a service fails? How do we know? What are the expected actions to be taken by a SP service in light of service failure? What sorts of reliability guarantees are in place, and how are they enforced? 4.5 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 [W3C-P3P] 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 SP may play a role in strengthening the enforcement of privacy policies. Editor NOTE 1: What I'm thinking here is that through request anonymization, we may be able to prevent the content source from Barbir, et al. Expires September 2003 [Page 19]
Internet-Draft draft-barbir-opes-spcs-03.txt March 2003 OPES Service Personalization Callout Server 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 2: OPES framework must address the privacy issue from the point of view of the content provider and the intermediaries. Basically, the intermediaries must be able to inform to the User Agent about their policies. This is because the privacy policies of the intermediaries may be different from the privacy policy of the content provider. In this case the intermediary must negotiate the superset. 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. There should be a mechanism that authorizes any entity that is interested in accessing a subscriber profile. The subscriber must be able be informed about the request to access the profile and must be able to accept or reject the request. In general, security considerations for personalization must address the following issues: 1) Subscriber Profile Integrity: SP must ensure that a subscriber profile is unadulterated in whole or in part when it reaches a decision point. 2) Content Profile Integrity: SP must ensure that a content profile is unadulterated in whole or in part when it reaches a decision point. 3) 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. 4) Non-repudiation of request: Non-repudiation of any subscriber profile configuration/update/change/deletion may be required. 5) Data Confidentiality: Preventing eavesdroppers from gaining access to a subscriber profile is important. Note that this requirement is different from subscriber privacy. 5. Example of a SP Call-out Server Barbir, et al. Expires September 2003 [Page 20]
Internet-Draft draft-barbir-opes-spcs-03.txt March 2003 OPES Service Personalization Callout Server Here it would be useful to put a real example video on-demand or anti-virus. 5.1 Personalization Requirements from OPES Framework OPES architecture must meet the following requirements in order to support the personalization services as specified by the SP framework. 1) The OPES admin server must be able to communicate with the SP call-out server to dynamically load the appropriate rules that are needed to perform the personalization services. 2) The OPES engine must be able to identify a subscriber. 3) The OPES engine must be able to associate a given rule module with a unique subscriber. 4) The OPES engine must be able to accept dynamic rules that are generated by the SP call-out server. 5) The OPES engine must be able to inform the SP call-out server about changes in the subscriber profile within an active session. 6) The OPES engine must be able to identify the end of a subscriber session and must be capable of communicating this information to the SP call-out server. 7) The OPES SP call-out server must be able to instruct the OPES engine to delete all the rules that are associated with a unique subscriber. 5.1.1 User Profile Integrity and Security The SP call-out server is the only owner of the dynamic rules that are associated with a given subscriber. For this reason, the OPES admin server must have very limited and secure capabilities for accessing any information that is related to a particular subscriber. The rules that are associated with any subscriber on an OPES engine must be protected and secure from any illegal access by any entity on the Internet. 6. Security Considerations All security considerations applicable to the general OPES framework are applicable here as well. In the case of SP, the additional component that is introduced is the subscriber profile. Consequently, certain security considerations apply in this regard: Barbir, et al. Expires September 2003 [Page 21]
Internet-Draft draft-barbir-opes-spcs-03.txt March 2003 OPES Service Personalization Callout Server 1) Subscriber profile configuration/modification/deletion needs authorization 2) Subscriber profile access needs authorization 3) Non-repudiation needs to be provided for subscriber profile configuration/modification/deletion 6.1 Security Considerations for SP Scenario In this section, we consider the OPES SP sequence of operations described in Section 4.3, and discuss the security considerations therein. The steps below correspond to the steps in Section 4.3. 1. When the subscriber indicates the need for personalization, this request may need to be authenticated. Lack of authentication could result in the successful launching of a denial-of-service (DOS) attack. For instance, a malicious entity could send several spurious requests indicating the need for personalization, and this could consume resources at the OPES engine as well as the SP call-out server. Rapid authentication schemes are needed in this case. Such authentication schemes also need to be combined with integrity - in other words, Message Authentication Codes (MAC) are preferred. Providing integrity takes care of the case where a malicious entity tampers with a genuine request in transit. 2. When the unique tag assigned to the subscriber is conveyed to the subscriber, such notification needs to be authenticated and integrity protected. Else, a malicious entity could either generate a spurious response, or could tamper with a genuine response, e.g. to change the tag to that of a different subscriber. 3. Authentication and integrity needs to be provided when the subscriber request is routed from the OPES engine to the SP call out server. 4. Protocol to communicate between the SP Call-out server and the subscriber's user agent needs to be secure. 5. Confidentiality may be needed when the rule module is sent back to the SP Call-Out server. 6. Similarly, confidentiality may be needed here as well. 7. Authentication and integrity are needed here. 7. 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. [O-MODEL]. This contribution is gratefully acknowledged. Barbir, et al. Expires September 2003 [Page 22]
Internet-Draft draft-barbir-opes-spcs-03.txt March 2003 OPES Service Personalization Callout Server The authors wish to acknowledge the comments and suggestions contributed by the members of the FSP mailing list. These people include: Nalin Mistry, Raffi Uddin, Wil Walkoe, Ram Dantu.(Please, any others that I've missed, add yourselves in...) 8. References [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [OPES-FSP] Barbir et al., "A Framework for Service Personalization", draft-barbir-opes-fsp-03.txt, work in progress, March 2003. [RFC-2616] Fielding, R., et al., "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC-3040] Cooper, I., Melve, I. and G. Tomlinson, "Internet Web Replication and Caching Taxonomy", RFC 3040, January 2001. [ESFNEP] A. Beck et al, "Example Services for Network Edge Proxies", draft-beck-opes-esfnep-01.txt (work in progress), June 2001. [POLICY] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Perry, J., Herzog, S., Huynh, A., Carlson, M. and S. Waldbusser, "Policy Terminology", RFC 3198, November 2001. [C-MODEL] Day, M., Cain, B., Tomlinson, G. and P. Rzewski, "A Model for Content Internetworking", draft-ietf-cdi-model-02.txt (work in progress), May 2002. [UID] Penno, R., "Identification of Users on the Internet", draft- penno-uid-00.txt, work in progress, January 2001. [UPIF] Penno, R., and H. T. Pham, "User Profile Information Protocol", draft-penno-cdnp-nacct-userid-05.txt. Work in progress, July 2001. [UPIP] Penno, R and G. Boissonnard, "Framework User Profile Information Protocol", draft-framework-upif-00.txt. Work in progress, June 2001. [RFC-2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [DIAMETER] Calhoun, P., Rubens, A., Akhtar, H., and Guttman, E., "The DIAMETER Base Protocol," draft-calhoun-diameter-17.txt, work in progress. [W3C-P3P] Platform for Privacy Preferences (P3P1.0) Specification, http://www.w3.org/TR/2000/CR-P3P-20001215. 9. Authors' Addresses Abbie Barbir, Ph.D. Nortel Networks 3500 Carling Avenue Nepean Ontario K2H 8E9 Canada Email: Abbieb@nortelnetworks.com Nicholas Bennett Nortel Networks Barbir, et al. Expires September 2003 [Page 23]
Internet-Draft draft-barbir-opes-spcs-03.txt March 2003 OPES Service Personalization Callout Server 3500 Carling Avenue Nepean Ontario K2H 8E9 Canada Email: nbennett@nortelnetworks.com Reinaldo Penno Nortel Networks, Inc. 600 Technology Park Drive Billerica MA 01821 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 Editor: (Please send comments to Editor) Paul Knight Nortel Networks 600 Technology Park Drive Billerica, MA USA Email: paknight-at-nortelnetworks.com Barbir, et al. Expires September 2003 [Page 24]
Internet-Draft draft-barbir-opes-spcs-03.txt March 2003 OPES Service Personalization Callout Server 10. Full Copyright Statement Copyright (C) The Internet Society (2003). 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 September 2003 [Page 25]