Network Working Group G. Tomlinson Internet-Draft CacheFlow Expires: January 10, 2002 R. Chen AT&T M. Hofmann Lucent July 12, 2001 A Model for Open Pluggable Edge Services draft-tomlinson-opes-model-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. This Internet-Draft will expire on January 10, 2002. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Intellectual Property Existence The authors are aware of the existence of intellectual property associated with certain edge service implementations. However, we do not believe this document refers to any of their works and as such isn't pertinent to them. Tomlinson, et. al. Expires January 10, 2002 [Page 1] Internet-Draft OPES Model July 2001 Abstract Content Networks, also known as Content Distribution Networks or Content Delivery Networks (CDNs), are of increasing importance to the overall architecture of the web. Both content providers and content consumers are increasingly looking for additional services beyond basic content networking. In particular, they are interested in services that operate on and provide a value-add to the content to be delivered from a content network. This document introduces Open Pluggable Edge Services (OPES), an infrastructure for adding such value added service to a content network. A common vocabulary helps the process of discussing such an edge services infrastructure. This document introduces elements for such a common vocabulary. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 2. OPES Model Terms . . . . . . . . . . . . . . . . . . . . . 6 3. Overlay Networks . . . . . . . . . . . . . . . . . . . . . 12 3.1 Packet Networks . . . . . . . . . . . . . . . . . . . . . 12 3.2 Content Networks . . . . . . . . . . . . . . . . . . . . . 13 3.3 OPES Edge Service Networks . . . . . . . . . . . . . . . . 15 3.3.1 OPES: Edge Service Networks . . . . . . . . . . . . . . . 16 4. OPES System Relationships . . . . . . . . . . . . . . . . 18 4.1 Core Component Relationships . . . . . . . . . . . . . . . 18 4.1.1 Deployment Scenarios Supported by this Model . . . . . . . 20 4.1.2 OPES Intermediary . . . . . . . . . . . . . . . . . . . . 21 4.1.2.1 OPES Engine . . . . . . . . . . . . . . . . . . . . . . . 22 4.1.2.2 Local Execution Environment: The Proxylet Run-time System 23 4.1.2.3 Remote Execution Environment: The Remote Call-out System 23 4.2 Remote Call-out Servers . . . . . . . . . . . . . . . . . 24 4.3 OPES Admin Server . . . . . . . . . . . . . . . . . . . . 24 4.3.1 Authentication Services . . . . . . . . . . . . . . . . . 25 4.3.2 Authorization (Policy) Services . . . . . . . . . . . . . 25 4.3.3 Accounting Services . . . . . . . . . . . . . . . . . . . 25 4.4 Surrogate Overlays . . . . . . . . . . . . . . . . . . . . 25 4.5 Delegate Overlays . . . . . . . . . . . . . . . . . . . . 27 5. Security Considerations . . . . . . . . . . . . . . . . . 29 5.1 Threats to the underlying Content Network . . . . . . . . 29 5.2 Threats to the OPES Edge Services Network . . . . . . . . 29 5.3 Threats to the Local Execution Environment . . . . . . . . 29 5.4 Threats to the Remote Execution Environment . . . . . . . 30 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 31 References . . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 33 Full Copyright Statement . . . . . . . . . . . . . . . . . 35 Tomlinson, et. al. Expires January 10, 2002 [Page 2] Internet-Draft OPES Model July 2001 1. Introduction Content Networks, also known as Content Distribution Networks or Content Delivery Networks (CDNs), are of increasing importance to the overall architecture of the web. Content Networks can be seen as an overlay network on top of the traditional packet network infrastructure. They are composed of several functional elements such as distribution services, request-routing services, accounting services, and billing services. Content networks support improving the delivery of content from an origin server to content consumers. Both content providers and content consumers are increasingly looking for additional services beyond basic content delivery. In particular, they are interested in services that operate on and provide a value-add to the content to be delivered. We will refer to such services as "Content Services". Examples of content services include dynamic content assembly, content personalization, virus scanning, and content adaptation for different device types [12]. While some such services are already being offered by web serves or by client software, there are good reasons to extend the basic idea of content networks and to develop an overlay infrastructure supporting the provisioning of content services in a distributed manner. We will refer to such an infrastructure as Edge Service Network. There are several reasons for the development of edge service networks. Providing content services only at a central web server, for example, entails the well-known risk of server overload, increased network load and high service latency. Providing content services only at the client might not always be an option, as some user agents like Personal Digital Assistants (PDA) and mobile phones may not have the processing power required to run the software for providing such services. Furthermore, most Internet users want to take advantage of content services without having to worry about technical matters like software installations or updates. Besides, some Internet appliances may only be capable of running hard coded software so that software upgrades would not be possible at all. As content services operate on and provide a value-add to the content being delivered through a content network, edge service networks are layered onto an underlying content network. Services being incorporated in edge service networks operate on messages flowing through the underlying content network. This document presents a vocabulary for use in developing edge service networks and describes the core components of such, and their relationships. Section 2 introduces the terms used for elements of an edge service network and explains how those terms are used. Section 3 explains the concept of overlay networks and how Tomlinson, et. al. Expires January 10, 2002 [Page 3] Internet-Draft OPES Model July 2001 different types of such are built upon each other. The core OPES components and their relationship are introduced in Section 4, followed by security considerations in Section 5. Tomlinson, et. al. Expires January 10, 2002 [Page 4] Internet-Draft OPES Model July 2001 2. OPES Model Terms This section consists of the definitions of a number of terms used to refer to the roles, participants, and objects involved in OPES service overlay networks. Although the following uses many terms used in RFC 2616 [4] and RFC 3040 [6], there is no necessary connection to HTTP or web caching technology. OPES networks 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[11] that results in the execution of an 'OPES 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. AVATAR Deprecated, see 'delegate'. CACHE (reference definition [4]) 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. CACHING PROXY (reference definition [6]) 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 [4]) A program that establishes connections for the purpose of sending requests. CONDITION A form of a policy condition[11] that is an expression which is used to determine whether a 'rule' 'action' should be executed. Tomlinson, et. al. Expires January 10, 2002 [Page 5] Internet-Draft OPES Model July 2001 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, an 'OPES intermediary', and a 'content server'. 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'. EDGE SERVICE NETWORK An overlay network of 'intermediaries' layered onto an underlying content network[7] that incorporate 'content services' that operate on messages flowing through the 'content path'. FAST PATH 'Content services' that can be completed in time to maintain 'wire speed'. These operations can be performed without stalling the pipeline of the underlying content network. 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'. Tomlinson, et. al. Expires January 10, 2002 [Page 6] Internet-Draft OPES Model July 2001 These function 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 DEVICE Deprecated, see 'OPES intermediary'. 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 [4]) The server on which a given resource resides or is to be created. 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'. PDP See 'policy decision point'. PEP See 'policy enforcement point'. Tomlinson, et. al. Expires January 10, 2002 [Page 7] Internet-Draft OPES Model July 2001 POLICY DECISION POINT (reference definition [11] ) A logical entity that makes policy decisions for itself or for other network elements that request such decisions. POLICY ENFORCEMENT POINT (reference definition [11] ) 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'. Tomlinson, et. al. Expires January 10, 2002 [Page 8] Internet-Draft OPES Model July 2001 REMOTE CALL-OUT SERVER A cooperating server which runs 'OPES service modules' as the result of a 'remote call-out'. ROLE (reference definition [11] ) 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: PRovisiong 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[11] 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[11] that contains a set of 'rules' and information about the rule module owner. SLOW PATH 'Content services' that can not be completed in time to maintain 'wire speed'. These operations by definition will stall the pipeline of the underlying content network and therefore must be performed after the flow is taken out of the pipeline. SURROGATE (reference definition [6]) 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 [4]. Such modifications have yet to be fully specified. Tomlinson, et. al. Expires January 10, 2002 [Page 9] Internet-Draft OPES Model July 2001 Devices commonly known as "reverse proxies" and "(origin) server accelerators" are both more properly defined as surrogates. TRIGGER See 'condition'. USER AGENT [4] The client which initiates a request. These are often browsers, editors, spiders (web-traversing robots), or other end user tools. WIRE SPEED The effective transmission rate of a given flow along the 'content path' of the underlying content network. Thus, wire speed used in this context is virtual, however it is possible for it to approach the speed of the physical links being traversed. Tomlinson, et. al. Expires January 10, 2002 [Page 10] Internet-Draft OPES Model July 2001 3. Overlay Networks 'Edge Service networks', of which OPES is a form, rely on underlying Content Networks as a platform on which to host themselves. Both Content Networks and 'edge service networks' utilize the relatively new 'overlay network' paradigm. Overlay networks are a powerful abstraction that create a virtual network of connected devices layered onto an existing underlying network in order to present application level services. Since OPES is predicated upon 'overlay network' architectures, we will begin with a discussion of them. 3.1 Packet Networks We begin with a quick tutorial of Packet Networks. Packet Networks are physical networks comprised of routers and other network elements including link devices. The packet network type we are interested in for OPES usage is IP[1] protocol based, including the Internet itself. IP networks form the base infrastructure onto which 'overlay networks', including OPES Edge Service Networks will be layered. Tomlinson, et. al. Expires January 10, 2002 [Page 11] Internet-Draft OPES Model July 2001 Figure 1 contains a diagram of an IP Packet Network. Note: underlying links and internetwork boundaries are omitted for simplicity. +--------+ / Client / +--------+ ^ / v __________________(X)___________________ / Router / / / +--------+ / IP / +--------+ / Client /<->(X) Packet Network (X)<->/ Origin / +--------+ / / / Server / / / +--------+ /____________________(X)_________________/ ^ / v +--------+ / Client / +--------+ Figure 1 IP Packet Network In this, the classic Internet model, each application device is connected to the IP packet network via router elements (X). 'Clients' establish a session with 'servers' and communicate via packets that are routed transparently[5] through the packet network. This communication relationship between the 'client' and 'server' is known as the end-to-end [3] model and is a fundamental principle of the Internet architecture. What this means is, the packet network doesn't process any application content, it simply transits it to the end points, where all of the application intelligence exists. This model has proven to be very successful, however as we shall see in the next section, there are a class of applications, namely the world wide web and streaming media for which it doesn't perform adequately in an increasing number of instances. 3.2 Content Networks As the scale and reach of IP packet networks, particularly the Tomlinson, et. al. Expires January 10, 2002 [Page 12] Internet-Draft OPES Model July 2001 Internet, has grown; a number of applications, particularly content delivery applications, such as the world wide web and streaming media don't always scale with it. There are a couple of primary causes for this, network congestion and the cumulative latency of internetworking. Essentially, this latency can cause too much jitter and packet loss for acceptable stream viewing and listening. It also adds to the wait times for web applications, often to the point of being unacceptable to the human waiting for it. In order to address these problems and others including scaling up an origin site, a new type of virtual network, the content network[7] has emerged for content delivery applications. Content networks create a virtual overlay on top of IP packet networks, known as a "content layer", that via 'intermediaries' enables the necessary network infrastructure to service these kinds of content delivery applications. Figure 2 contains a diagram of Content Network Overlay. +--------+ / Client / +--------+ ^ / v ____________________(e)____________________ / edge / / server / +--------+ / /____ / Client /<->(e) Content Network Overlay / / +--------+ / / / / / / +--------+ /_____________________(e)___________________/ (X)<->/ Origin / / ^ / / Server / / | Packet Network / +--------+ /_____________________(X)___________________/ ^ / v +--------+ / Client / +--------+ Figure 2 Content Network Overlay In this model in which edge server 'intermediaries' (e) are added, each application device continues to be connected to the IP packet network via router elements (X). The edge servers collectively Tomlinson, et. al. Expires January 10, 2002 [Page 13] Internet-Draft OPES Model July 2001 form a content network overlay in which they service requests on behalf of 'origin servers'. In this model, the 'Clients' establish a session with an edge server (e) in the virtual content layer that is located near them rather than with the 'origin server', and communicate with it via packets that are routed through the packet network. The edge servers establish sessions with the 'origin server' and act as an intermediary in the 'content path'. This model retains the end to end nature, however it introduces application gateways between independent end to end sessions. The 'intermediaries' logically add intelligence to the network infrastructure in the form of an 'overlay network'. By placing edge servers topologically disperse through out the IP packet network and in close proximity with 'clients', the impediments of network congestion and network latency are removed. This enables web and streaming media applications to deliver content in a timely and scalable manner. Note: other content network elements including request-routing, distribution and accounting have been omitted from this discussion for simplicity. The interested reader is referred to [7] for additional information about content networks. Fundamentally there are two forms of edge servers, the 'delegate' and the 'surrogate'. 'Delegates', are authorized 'intermediaries' that act on behalf of 'clients'. Surrogates on the other hand, are authorized 'intermediaries' that act on behalf of 'origin servers'. Edge servers are strategically placed in the 'content path' and as such are ideal platforms to for 'content services'. We will discuss how they are used as the base infrastructure upon which edge service networks are overlaid in the next section. 3.3 OPES Edge Service Networks Edge service networks extend the capabilities of content networks with services that process the content flowing through the 'content path'. This value-added processing of the content is known as 'content services'. The edge service network is a specialized form of an application network overlay that is constrained to provide services only on the 'content path', as opposed to general applications. Edge service networks provide a mechanism for vectoring the content flow to service modules for processing. This vectoring is accomplished with a message parser and 'rules' that set 'conditions' to trap on the content flowing through the 'content path'. This process is a classic example of a policy 'PEP'. Tomlinson, et. al. Expires January 10, 2002 [Page 14] Internet-Draft OPES Model July 2001 Figure 3 contains a diagram of Edge Services Network Overlay. +--------+ / Client / +--------+ ^ / v _____________________(i)______________________ / intermediary / / content services / +--------+ / /____ / Client /<->(i) Edge Services Network Overlay / / +--------+ / / / / / /____ /______________________(i)_____________________/ / / / . / / / . Content Network / / +--------+ /______________________(e)_____________________/ (X)<->/ Origin / / ^ / / Server / / | Packet Network / +--------+ /______________________(X)_____________________/ ^ / v +--------+ / Client / +--------+ Figure 3 Edge Services Network Overlay In this model, the 'clients' continue establish a session with an edge server (e) in the virtual content layer that is located near them rather than with the 'origin server', and communicate with it via packets that are routed through the packet network. Messages that 'trigger' a 'condition' registered by a 'rule author' as a 'content service' (i) are vectored to the service module for content processing. The results are returned from the service module and placed back in the content flow. The rest of the system behaves like the previous example Figure 2. 3.3.1 OPES: Edge Service Networks OPES is a form of an 'edge service network'. OPES utilizes 'surrogates' and 'delegates' as 'OPES intermediaries' that provide pluggable edge services. It also adds additional network elements to its overlay that include administration and 'remote call-out' Tomlinson, et. al. Expires January 10, 2002 [Page 15] Internet-Draft OPES Model July 2001 processing. Additionally, an OPES 'edge service network' is constrained to be authorized by the party for which 'content services' are being performed, either the 'origin server' or the 'content consumer'. OPES employs a security trust model for establishing delegated authority to act on behalf of a principal party. In this security trust model there is a principal party ('content consumer' or 'origin server'), the party has rights, and the rights can be delegated to or inherited by the OPES 'edge services network'. When such effective rights are granted to the OPES 'edge services network' via a negotiated relationship, it is said to be in the 'authoritative domain'. Tomlinson, et. al. Expires January 10, 2002 [Page 16] Internet-Draft OPES Model July 2001 4. OPES System Relationships In this section, we propose an OPES system model that allows us to examine the core components of an OPES 'edge service network' and the relationships among them in detail. We also apply this model to two edge service overlay networks: the surrogate overlay network that represents the interests of content providers and the delegate network that represents the interests of content consumers. 4.1 Core Component Relationships In this section, we propose an OPES system model that allows us to examine the core components of an OPES 'edge service network' and the relationships among them in detail. We also apply this model to two edge service overlay networks: the surrogate overlay network that represents the interests of content providers and the delegate network that represents the interests of 'content consumers'. Tomlinson, et. al. Expires January 10, 2002 [Page 17] Internet-Draft OPES Model July 2001 Figure 4 contains a diagram of the network elements involved in the OPES Edge Service System Model. +-----------------+ | Remote Call-out | | Server | +-----------------+ ^ | | v +--------------------------+ | +----------+ +---------+ | | | Local | | Remote | | | | Exec. | | Exec. | | | | Env. | | Env. | | +-------+ | +----------+ +---------+ | +---------+ | User | | +----------------------+ | | Content | | Agent |<----->| | OPES Engine/PEP | |<----->| Server | +-------+ | +----------------------+ | +---------+ | OPES | | Intermediary | +--------------------------+ ^ | | v +-----------------------+ | OPES Admin | | Server | | +-------------------+ | | | Authentication | | | +-------------------+ | | | Authorization/PDP | | | +-------------------+ | | | Accounting | | | +-------------------+ | +-----------------------+ Figure 4 OPES Edge Service System Model Components The 'OPES intermediary', an 'intermediary' that hosts the 'OPES Engine', is located on the 'content path' between the 'user agent' and 'content server'. The device consists of three logical components: the 'OPES engine', the local execution environment, and the remote execution environment. The 'OPES engine' provides 'content services' on the requested content before its delivery by Tomlinson, et. al. Expires January 10, 2002 [Page 18] Internet-Draft OPES Model July 2001 invoking appropriate 'actions' on the content in one of the two execution environments. The 'OPES intermediary' also interacts with other logical components not on the 'content path': the 'OPES admin server' and the 'remote call-out servers'. The 'OPES admin server' provides authentication services to identify trusted parties within an OPES 'edge services network', authorization services to determine if a 'content service' is authorized, and accounting services to log the usage of the 'OPES intermediary'. The 'OPES admin server' may or may not be physically located on the same 'OPES intermediary', but they should belong to the same administrative domain[2]. 'Remote call-out servers' are invoked through the remote execution environment for services on messages which are not available locally. We first give examples of deployment scenarios supported by this model, then we examine each logical component and the relationships among the components in detail. 4.1.1 Deployment Scenarios Supported by this Model Our model document attempts to support a wide range of OPES deployment scenarios, including, but not limited to the following: o 'OPES intermediary' is the 'client' device: A 'content consumer' may decide to install an 'OPES intermediary' on his or her desktop for personal 'content services'. In this case, the 'OPES intermediary' serves only one user. The 'OPES admin server' may degenerate to a simple service that denies requests from any other IP addresses and allows the user full control on the 'rule modules'. o 'OPES intermediary' is owned by an enterprise and deployed on the intranet: In this case, any one who can connect to the 'OPES intermediary' is already on the intranet. Many OPES services such as virus checking and URL filtering provided by this box may not require authentication or authorization of the users at all. On the other hand, the enterprise owner may elect to reuse the company's existing administration services to provision 'OPES services' that require unique user identification to personalize the services. o 'OPES intermediary' is owned by a "Middleware Service Provider" (MSP): In this case, the MSP may not be the access provider, but it provides middleware services for anyone who registers to become a user. It provides service provisioning and charges fees for its services. For example, an ISP user may use middleware services such as language translation or location-aware services provided by an MSP even though that MSP does not provide any Tomlinson, et. al. Expires January 10, 2002 [Page 19] Internet-Draft OPES Model July 2001 internet access services. o 'OPES intermediary' is owned by an ISP: One or multiple 'OPES intermediaries' may be deployed in the access provider's network. ISPs are more likely to be interested in value-added services that they can resell to their subscribers and in services that would simplify their general administrative tasks. o 'OPES intermediary' is owned by a CDN: CDN providers can deploy 'OPES engines' on 'surrogates' that provide CDN services on behalf of content providers (i.e. the customers of the CDN). CDN providers are likely to be more interested in services that they can offer to content providers, in particular to enable secure, scalable, and profitable distribution of valuable content. For more detailed discussions on the OPES deployment scenarios, see [12]. 4.1.2 OPES Intermediary An 'OPES intermediary' should consist of minimally the 'OPES engine' and a local execution environment for 'actions' that are 'triggered' by the 'rules'. It may optionally consist of a remote execution environment for interactions with remote call-out servers. The 'intermediary' may consist of other logical components (such as a cahce) not described in this document. Figure 5 contains a diagram of the three core components of an 'OPES intermediary' and their internal structure. We examine each component in detail in the following subsections. Tomlinson, et. al. Expires January 10, 2002 [Page 20] Internet-Draft OPES Model July 2001 Figure 5 contains a diagram of the core components of an 'OPES Intermediary' and their internal details. Remote Call-out Protocol(s) ^ ^ : : : : +------------------------+ v v | +----------+---------+ | +----------+----------+ | | Proxylet | Proxlet | | | Remote | Remote | | +----------+---------+ | | Call-out | Call-out | | | Proxylet Library | | | Stub | Stub | | +--------------------+ | +----------+----------+ | Proxylet Run-time | | Remote Call-out | | System | | System | +------------------------+ +---------------------+ Local Exec. Env. Remote Exec. Env. +------------------------------------------------+ | +-------------+-------------+ | | | Rule Module | Rule Module | | C S A | +---------------------------+ | o e U g Responses | Rule Processor | Responses n r s e <============4== +---------------------------+ <=3=========== t v e n Requests | Message Parser | Requests e e r t =============1=> +---------------------------+ ==2==========> n r s | OPES Engine | t s +------------------------------------------------+ Figure 5 System Model Components 4.1.2.1 OPES Engine The 'OPES engine' consists of the following logical components: a message parser, a rule processor, and 'rule modules', which collectively constitute a 'PEP', policy enforcement point. The message parser examines the request and response messages. The rule processor evaluates the parsed results against 'rule modules' described with a policy language such as the proposed IRML [8]. The 'OPES engine' controls insertion of 'content services' into the flow via it's 'PEP' and policy 'roles'. There is a 'role' associated with each of the logical points in the message flow (currently predefined points 1 thru 4 in Figure 5): o Point 1: A request is received from the 'user agent'. Tomlinson, et. al. Expires January 10, 2002 [Page 21] Internet-Draft OPES Model July 2001 o Point 2: A request is about to be forwarded to the 'origin server'. o Point 3: A response has just arrived from the 'origin server'. o Point 4: A response is about to be delivered to the 'user agent'. Each 'role' has its associated 'rules' and it relies on the 'PEP' to determine whether certain 'actions' should be taken. The 'PEP' may be authorized to make a decision for certain rules, otherwise it must interact with the 'OPES admin server', which acts as a policy decision point, 'PDP' to obtain authorization. [Note: for more information on policy within an OPES 'edge services network' see [13]. 4.1.2.2 Local Execution Environment: The Proxylet Run-time System The 'proxylet run-time system' provides a local execution environment or 'actions' that can be performed on the 'OPES intermediary'. The system consists of intrinsic functions known as the 'proxylet library' and loadable extensions known as 'proxylets' that invoke the library functions. Local operations typically run in the 'fast path' of the 'OPES engine', since they generally can be performed at 'wire speed'. Similar to 'rules', a 'proxylet' is downloaded from a 'proxylet provider' to an 'OPES admin server'. In addition to the authentication process, the 'OPES admin server' also performs proxylet "sandbox" validation to make sure that the 'proxylet' conforms to local policies (e.g. what resource it is allowed to access, etc.). Only after successful validation, the 'proxylet' code would be loaded into the targeted 'OPES intermediary' and be 'triggered' by the 'rules'. Typical 'proxylet library' functions might include an HTML parser, an HTML tree walker, cache read/write operators, archiving functions, and logging operators. Typical 'proxylets' might include a link replacement tool (e.g., mapping company names to live stock quotes), a service menu insertion tool, a log analysis tool, and a page synthesis tool. A 'proxylet' may invoke 'proxylet library' functions or other 'proxylets' to complete an 'action'. 4.1.2.3 Remote Execution Environment: The Remote Call-out System The 'remote call-out system' provides a remote an execution environment that allows content requests and responses to be transformed or adapted by a 'remote call-out server'. Each 'remote call-out stub' provides the protocol interface between the Tomlinson, et. al. Expires January 10, 2002 [Page 22] Internet-Draft OPES Model July 2001 'OPES engine' and a 'remote call-out server'. Typical call-out protocols include ICAP[9] and SOAP[10]. Remote operations run in the 'slow path' of the 'OPES engine' since they can not be performed at 'wire speed'. Note: Large numbers of these operations running concurrently have the potential to adversely impact the provisioned service capacity of the underlying 'intermediary' device. Unlike 'proxylets', which are validated and executed in a local environment, the 'remote call-out services' may be executed in a different 'authoritative domain' and must be used with caution. For example, an enterprise deploying 'OPES intermediaries' on the intranet must make sure that no unauthorized 'remote call-out services' are used on sensitive internal documents. End-to-end encryption also precludes the use of any value-added services through a 'remote call-out server' [9]. Examples of remote call-out services include URL filtering, language translation, regional ad insertion, and content transformation for mobile devices, etc. 4.2 Remote Call-out Servers 'Remote call-out servers' are usually employed in an OPES framework to either offload the 'OPES intermediary' for better scalability or to provide value- added services not available on either the 'origin server' or the 'OPES intermediary'. Both the 'OPES admin server' and the 'remote call-out servers' are not on the 'content path'. The 'OPES admin server' and the 'OPES intermediary', however, usually belong to the same 'authoritative domain', while the placement of the 'remote call-out servers' may depend on the design of the overlay networks. Section 4.4 and Section 4.5 describe a surrogate overlay and an delegate overlay respectively, that place 'remote call-out servers' in the same 'authoritative domain' with the 'OPES intermediary' and also the 'origin server' or the 'client', respectively. Such overlay networks simplify the administration and improve the security of 'actions' that involve 'remote call-out servers'. 4.3 OPES Admin Server The 'OPES admin server' consists of the following logical components: an authentication service, an authorization service, and an accounting service. Collectively these services form the operational control plane of an OPES 'edge services network'. Tomlinson, et. al. Expires January 10, 2002 [Page 23] Internet-Draft OPES Model July 2001 4.3.1 Authentication Services Authentication services provide authentication of devices comprising an OPES 'edge service network'. Minimally this includes OPES authenticating 'OPES intermediaries' with an 'OPES admin server'. Additionally, it includes 'remote call-out servers' with 'OPES intermediaries', 'rule author' with the 'OPES admin server' and 'proxylet providers' with an 'OPES admin server'. Authentication of 'content consumers' and 'origin servers' is not provided by this service. This responsibility falls upon the underlying content network. It is assumed 'OPES service modules' will utilize the underlying content network authentication service for these needs. 4.3.2 Authorization (Policy) Services Authorization services as provided by the 'OPES admin server' constitute a policy 'PDP' capability. This includes the authorization of 'rule author' and 'proxylet providers' to provide 'rule modules' and 'proxylets' to the 'OPES admin server'. Additionally, it includes the provisioning (i.e. downloading) of validated 'rule modules' and 'proxylets' to 'OPES intermediaries'. In addition to rules being provisioned via the 'OPES admin server', they can be embedded within the content itself. An example of this is Edge Side Includes[14]. Provisioning of these kind of 'rules' with an 'OPES engine' 'role' and the resultant insertion of 'content services' in the message flow are subject to authorization by the 'OPES engine' 'PEP'. 4.3.3 Accounting Services Accounting services provide collection of accounting and log data from 'OPES intermediaries'. Such accounting and log data contains measurement and recording of 'content service' activities, especially when the information recorded is ultimately used as a basis for the subsequent transfer of money, goods, or obligations. 4.4 Surrogate Overlays A surrogate overlay is a specific type of 'edge service network', which is delegated the authority to provide 'content services' on behalf of, and typically in close co-operation with, one or more 'origin servers'. Surrogate overlays can be seen as logical extension of 'origin servers'. The elements of surrogate overlays (e.g. the 'OPES intermediaries' or the 'remote call-out servers') act on behalf of 'origin severs' Tomlinson, et. al. Expires January 10, 2002 [Page 24] Internet-Draft OPES Model July 2001 and logically belong to the 'authoritative domain' of the respective 'origin servers' (see Figure 6). In particular, services in surrogate overlays are authorized by the content owner through the 'OPES admin server'. ********************************************* * * * +--------+ Authoritative * * | Origin | Domain * * | Server | * * +--------+ +------------+ * * | | OPES Admin | * * | | Server | * * | +------------+ * * | / * * | / * * +--------------+ +-----------------+ * * | OPES |----- | Remote Call-out | * * | Intermediary | | Server | * * +--------------+ +-----------------+ * * | * ********************************************* | | | +--------+ | Client | +--------+ Figure 6 Authoritative Domains for Surrogate Overlays Surrogate overlays provide services that would otherwise be run by the content provider at the 'origin server'. Such services include, but are not limited to, dynamic assembling of web pages, watermarking, and content adaptation. For illustration purposes, we will consider a content provider offering web pages that include a local weather forecast based on the client preferences (which can be transmitted in form of a cookie or any other suitable form). Typically, the content provider would run such a service at the 'origin server'. The service would analyze received requests and associated user preferences, select appropriate templates, insert the corresponding local weather forecasts, and would then deliver the content to the 'client'. This is all done at the 'origin server' and authorized/controlled by the content provider. In case of surrogate overlays, the same service can be run on either an 'OPES intermediary' (local execution) or a 'remote call-out server' (remote execution). For this purpose, the content provider contacts Tomlinson, et. al. Expires January 10, 2002 [Page 25] Internet-Draft OPES Model July 2001 the 'OPES admin server' and explicitly authorizes 'OPES intermediaries' in the 'content path' to perform the service on its behalf (or to commission a call-out server to perform the service on its behalf). Note: for more information on Surrogate scenarios see [12]. 4.5 Delegate Overlays An delegate overlay is a specific type of 'edge service network', which is delegated the authority to provide 'content services' on behalf of, and typically in close co-operation with, one or more 'content consumers'. Delegate overlays can be seen as logical extension of 'user agents'. The elements of delegate overlays (e.g. the 'OPES intermediary' or the 'remote call-out servers') act on behalf of 'content consumers' and logically belong to the 'authoritative domain' of the respective 'clients' (see Figure 7). In particular, services in delegate overlays are authorized by the 'content consumer' through the 'OPES admin server'. Tomlinson, et. al. Expires January 10, 2002 [Page 26] Internet-Draft OPES Model July 2001 +--------+ | Origin | | Server | +--------+ | | | ********************************************* * | * * +--------------+ +-----------------+ * * | OPES |----- | Remote Call-out | * * | Intermediary | | Server | * * +--------------+ +-----------------+ * * | \ * * | +------------+ * * | | OPES Admin | * * | | Server | * * | +------------+ * * +--------+ * * | Client | Authoritative * * +--------+ Domain * * * ********************************************* Figure 7 Authoritative Domains for Delegate Overlays Delegate overlays provide services that would otherwise be run by the 'content consumer' on his local machine. Such services include, but are not limited to, virus scanning and content filtering. For illustration purposes, we will consider a 'content consumer' taking advantage of virus scanning software. Typically, the 'content consumer' would run the virus scanning software on his local machine. The service would scan received content for viruses and block infected files to protect the user. This is all done at the 'client' and authorized/controlled by the 'content consumer'. In case of delegate overlays, the same service can be run on either an 'OPES intermediary' (local execution) or a 'remote call-out server' (remote execution). For this purpose, the 'content consumer' contacts the 'OPES admin server' and explicitly authorizes 'OPES intermediaries' in the 'content path' to perform the service on its behalf (or to commission a call-out server to perform the service on its behalf). Note: for more information on Delegate scenarios see [12]. Tomlinson, et. al. Expires January 10, 2002 [Page 27] Internet-Draft OPES Model July 2001 5. Security Considerations Security concerns with respect to 'edge service networks' can be generally categorized into trust within the system and protection of the system from threats. The trust model utilized within OPES is predicated largely on transitive trust between the underlying Content Network, 'OPES Intermediaries', 'OPES admin servers', and 'remote call-out servers'. Network elements within the OPES 'edge service network' are considered to be "insiders" and therefore trusted. Given the transitive trust afforded to "insiders", it is necessary to mutually authenticate the identities of network elements belonging to an OPES 'edge service network'. 5.1 Threats to the underlying Content Network The OPES 'edge service network' is predicated upon an underlying Content Network to secure the 'content path'. Thus, threats to the content network pose threats to the OPES 'edge services network'. The principal threat being the compromising of an edge server hosting an OPES Intermediary. Threats to content networks are discussed in [6] and [7]. 5.2 Threats to the OPES Edge Services Network If an 'OPES admin server' is breached, the attacker can gain control of the entire OPES 'edge services network'. If the communication channel between the 'OPES admin server' and the 'OPES intermediary' is breached, the attacker can gain control of a subset of the OPES 'edge services network'. If the 'OPES admin server' fails to authenticate and/or authorize either 'rule authors' or 'proxylet providers', rights of the principal parties could be violated along with unintentional or malicious interference. 5.3 Threats to the Local Execution Environment If 'rules' are not prevented from triggering on unauthorized contents flows, rights of the principal parties will likely be violated, including but not limited to copyright and privacy. If a 'proxylet' is able to access system resources outside of its authorized "sandbox", unintentional or malicious interference could occur, including not only rights violations but the possibility of compromising the 'OPES intermediary'. Tomlinson, et. al. Expires January 10, 2002 [Page 28] Internet-Draft OPES Model July 2001 5.4 Threats to the Remote Execution Environment If a 'remote call-out server' is compromised, rights of the principal parties could be violated, including but not limited to copyright, privacy and confidentiality. 'Remote call-outs' may inadvertently or maliciously expose private information (passwords, buying patterns, page views, credit card numbers) as it transits to and from 'remote call-out servers'. If the communication channel between the 'OPES intermediary' and the 'remote call-out server' is snooped, the attacker may gain access to sensitive information. In this case, sensitive content should always be encrypted between these two parties, even if they trust each other. Tomlinson, et. al. Expires January 10, 2002 [Page 29] Internet-Draft OPES Model July 2001 6. Acknowledgements The authors acknowledge the contributions of influential precursor works done by Andre Beck, Michael Condry, Rob Erickson, Dave Farber, James Kempf, Christian Maciocco, Hilarie Orman and Lily Yang. Tomlinson, et. al. Expires January 10, 2002 [Page 30] Internet-Draft OPES Model July 2001 References [1] Postel, J., "Internet Protocol", RFC 791, September 1981, . [2] Hares, S. and D. Katz, "Administrative Domains and Routing Domains A Model for Routing in the Internet", RFC 1136, December 1989, . [3] Carpenter, B., "Architecture Principles of the Internet", RFC 1958, June 1996, . [4] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999, . [5] Carpenter, B., "Internet Transparency", RFC 2775, February 2000, . [6] Cooper, I., Melve, I. and G. Tomlinson, "Internet Web Replication and Caching Taxonomy", RFC 3040, January 2001, . [7] 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, . [8] Beck, A. and M. Hofmann, "IRML: A Rule Specification Language for Intermediary Services", draft-beck-opes-irml-00.txt (work in progress), February 2001, . [9] Elson, J. and A. Cerpa, "ICAP the Internet Content Adaptation Protocol", ICAP Forum http://www.circlemud.org/~jelson/icap-1.72.txt, June 2001, . [10] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn, N., Frystyk Nielsen, H., Thatte, S. and D. Winer, "Simple Object Access Protocol (SOAP) 1.1", W3C Note http://www.w3.org/TR/2000/NOTE-SOAP-20000508/, May 2000, . Tomlinson, et. al. Expires January 10, 2002 [Page 31] Internet-Draft OPES Model July 2001 [11] 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, . [12] McHenry, S., Condry, M. and G. Tomlinson, "Open Pluggable Edge Services Use Cases and Deployment Scenarios", draft-mchenry-opes-deployment-scenarios.txt (work in progress), November 2000, . [13] Rafalow, L., Yang, L. and A. Beck, "Policy Requirements for Edge Services", draft-rafalow-opes-policy-requirements-00.txt (work in progress), July 2001, . [14] Nottingham, M., Tsimelzon, M., Weihl, B. and L. Jacobs, "ESI Language Specification 1.0", EDGE SIDE INCLUDES http://www.edge-delivery.org/language_spec_1-0.html, May 2001, . Authors' Addresses Gary Tomlinson CacheFlow Inc. Suite 201 12034 134th Ct. NE Redmond, WA 98052 US Phone: +1 425 820 3009 EMail: garyt@cacheflow.com Robin Chen AT&T Research Room E219 180 Park Avenue Florham Park, NJ 07932 US Phone: +1 973 360 8653 EMail: chen@research.att.com Tomlinson, et. al. Expires January 10, 2002 [Page 32] Internet-Draft OPES Model July 2001 Markus Hofmann Bell Labs/Lucent Technologies Room 4F-513 101 Crawfords Corner Road Holmdel, NJ 07733 US Phone: +1 732 332 5983 EMail: hofmann@bell-labs.com Tomlinson, et. al. Expires January 10, 2002 [Page 33] Internet-Draft OPES Model July 2001 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. Tomlinson, et. al. Expires January 10, 2002 [Page 34]